报表模板里有一块三乘三的数据区，旁边留了个汇总格。业务人员不想记 SUM 的语法和区域写法，但希望汇总方式可以自己切换——有时算两列之和，有时算整个九宫格。让用户在下拉框里点一下，单元格里就直接出现计算结果，这个效果不需要自定义单元格类型，SpreadJS 现成的 ComboBox 就能做到。
为什么这个细节重要
大多数下拉框场景是"选一个值存进去"，这个场景反过来：用户选的是"要执行的计算"，存进去的是一条公式。它考验的是控件对"显示文本"与"数据模型里的实际值"这两层的分离程度。如果控件只能把选中的文字原样塞进单元格，这条路就走不通。
对使用者来说，价值是把公式输入这种易错操作变成一次点击：不用记括号、逗号、引用格式，也不会出现 A1:B2 手滑写成 A1;B2 之类的错误。对开发者来说，值得看清的是 ComboBox 的 editorValueType 机制，以及公式字符串进入数据模型后由谁接管。SpreadJS 是带完整公式引擎的 JavaScript 电子表格控件，这正是它能接住这条链路的前提。
SpreadJS 的实现思路
先铺一块数据，再做一个选项即公式的下拉框：
sheet.setArray(0, 0, [[1, 2, 3], [4, 5, 6], [7, 8, 9]]);
var combo = new GC.Spread.Sheets.CellTypes.ComboBox();
combo.items([
{ text: "=SUM(A1:B2)", value: "=SUM(A1:B2)" },
{ text: "=SUM(A1:C3)", value: "=SUM(A1:C3)" }])
.editorValueType(GC.Spread.Sheets.CellTypes.EditorValueType.value);
sheet.getCell(0, 3, GC.Spread.Sheets.SheetArea.viewport).cellType(combo);
核心在 editorValueType 这个开关。EditorValueType 有三种取值：text 表示把选中项的显示文本写入数据模型，index 写入选中项索引，value 写入选项携带的关联值。这里设为 value，用户选中某一项后，进入单元格数据模型的就是 value 字段里那条以等号开头的字符串。
接下来是 SpreadJS 替你完成的部分：以 = 开头的字符串作为值写入后，会被公式引擎识别并解析成真正的公式，单元格立即重算，显示的是计算结果而不是公式文本。也就是说，代码里没有任何"调用求值"的动作，选择动作本身就把公式激活了。这也是本例最值得注意的一点——显示给用户的下拉列表内容、写入数据模型的内容、最终渲染出来的内容，三者各司其职。
想再进一步，有两个自然的扩展方向。其一，text 与 value 不必相同：value 存短小的标准公式，text 显示"前六项合计"这类人类可读的名称，界面上看到的就是业务语言，落库的是规范表达式。其二，选项不必硬编码，ComboBox 还支持 dataBinding 绑定表、公式或单元格范围作为数据源，公式清单可以集中维护，甚至按角色下发不同的可选集合。需要注意的边界是：公式里引用的区域是写死在选项字符串里的，如果要适配动态变化的表格尺寸，就得在生成选项时把区域一并算好。
可以扩展到哪些场景
同样的做法适合所有"从预设算法里挑一个"的场合：财务底稿里在小计、累计、占比之间切换；库存表在月度汇总和季度汇总之间切换；考核表让部门主管从几个口径固定的评分公式里选；报价单按客户等级选用不同的折扣公式。凡是公式集合有限且相对稳定的模板，都可以收敛成一个下拉框。
给开发者的关键词
GC.Spread.Sheets.CellTypes.ComboBox、items、editorValueType、EditorValueType.value、getCell().cellType()、setArray、setColumnWidth、公式字符串、公式引擎自动解析、JavaScript 电子表格。
小结
这个模式的巧妙之处在于借力：ComboBox 只负责把选中的 value 送进数据模型，公式引擎负责剩下的全部工作。理解了 editorValueType 在 text、index、value 三种取值之间的分工，就能把"选择"和"计算"干净地接到一起，让不会写公式的用户也能安全地使用公式。
