dsh-spreadjs-editor 装上之后，用户不会因为页面里出现一个网格就认为它是 Excel 编辑器。他们关心的是文件能不能正常打开，工作表好不好切换，公式和格式保不保得住，常用操作顺不顺手。这篇讲怎么在自己环境里把这些确认下来。
「能打开」和「能上线」差了什么
判断一个方案能不能用，可以先问三个问题：
- 原有的 Excel 文件能不能按用户预期呈现？
- 用户能不能完成日常编辑？
- 改完的文件能不能回到原来的存储和协作流程？
三个问题看着简单，但很多方案的演示只回答了第一个。演示时打开一个格式整齐的小文件，一切正常；换成业务里真实的文件，问题就出来了。
边界先说清：dsh-spreadjs-editor 没有修改或增强 SpreadJS 的电子表格功能。用户在 DSH 里看到的编辑体验来自原生 SpreadJS Designer，插件负责注册文件查看器、读写工作区文件、让编辑器跟随系统主题。所以下面这些验收动作，实际检验的是 SpreadJS 在你这批文件上的表现。
功能数量不适合单独拿来比。同样的能力，放在不同用户的动作里，重要性完全不一样。
用户会做的四件事
切换工作表
真实工作簿通常有多个 Sheet。用户要在明细、汇总、说明、辅助数据之间来回切，所以多个工作表都要能打开、能自由切换。验收时确认 Sheet 的数量、名称、顺序都对，切换之后单元格内容和格式没错位。
SpreadJS 本来就以工作簿为单位组织，不是把一张表渲染成网格，所以多 Sheet 是它天然支持的结构。
核对公式
很多 Excel 文件的价值不只在数据，还在公式和计算关系。在线查看时要能确认计算结果，编辑时改了输入也要能看到相应变化。
这部分别靠肉眼判断。准备一组已知结果的测试数据，先在桌面 Excel 里确认基准，再比对在线打开、修改、保存后的结果。这样得到的是能复查的结论，而不是「看着还行」。
看格式
合并单元格、数字格式、列宽、行高、边框和颜色都影响可读性。对报表和模板文件来说，格式保不保得住往往和数据本身一样重要。
如果文件有打印要求，还要单独确认打印区域、分页、页眉页脚。这在屏幕上根本看不出来，但财务报表和模板类文件躲不开这一步。
日常操作
筛选、排序、冻结窗格和单元格编辑是业务用户每天都在用的。在线编辑器要让这些操作足够自然，用户才会真的少开桌面 Excel。
这些能力不必第一版就全开。验收时先确认用户在这个页面里到底要做哪几件事，再决定哪些操作必须开、哪些可以后补。
如果结论要用来选型
验收结果要支撑选型决策时，只有功能清单不够。按四类问题整理：
| 维度 | 需要回答的问题 |
|---|---|
| 用户体验 | 用户是否可以按照熟悉的 Excel 方式完成任务 |
| 文件能力 | 目标文件的结构、公式和格式是否符合要求 |
| 集成方式 | 能否接入现有前端、权限和保存流程 |
| 长期使用 | 版本、维护、支持和扩展路径是否清晰 |
四类问题要放在一起看。单独看任何一类都容易得出偏乐观的结论：功能最强的方案可能最难集成，最容易集成的方案可能撑不住三年后的需求。
验收表要写「通过标准」
把上面的动作和维度落成一张能勾选的表，验收才有结果。表里一定要有「通过标准」这一列，否则验收时对「做到什么程度算过」会有分歧。
| 验收项 | 需要确认的问题 | 通过标准 |
|---|---|---|
| 工作簿结构 | 多 Sheet 是否可以正常切换，名称和顺序是否符合预期 | 与桌面 Excel 打开结果一致 |
| 数据和公式 | 修改输入后，关键公式结果是否正确 | 与桌面 Excel 基准结果一致 |
| 格式 | 数字、日期、合并区域、边框和列宽是否保持 | 屏幕显示与打印效果均符合模板要求 |
| 交互 | 筛选、排序、冻结和编辑是否符合用户习惯 | 业务用户无需额外培训即可完成操作 |
| 保存 | 修改后的文件能否重新打开并进入原有流程 | 保存结果可被下游流程直接消费 |
演示看不出来的几类文件
下面这些情况在小文件上完全正常，上线后最容易出问题：
- 宏。
.xlsm能作为工作簿格式导入，但涉及宏执行或保留的需求要单独验证。 - 外部链接与跨工作簿引用。文件离开原始目录后还能不能正确取值，得实测。
- 特殊对象。图表、图片、形状、数据透视表这些对象在导入、编辑并保存回原文件后是否保持。
- 超大文件。文件大小、公式数量、图片和样式复杂度都会影响加载。性能测试不用一开始就追一个抽象极限，更应该看用户能不能在可接受时间内打开、编辑和保存。
- 复杂公式与自定义函数。用了自定义函数或插件函数的文件，要确认这些函数在 Web 端怎么处理。
直接影响业务的特性，应该写进验收用例，不要只出现在宣传文案里。关键报表要验打印效果，模板文件要验合并区域和公式引用，超大文件要记录加载时间和浏览器资源占用。
拿什么文件验收
别用为演示准备的干净样例文件。
从生产文件里挑，脱敏后当样本，覆盖三类：普通办公表格用来快速体验，关键业务模板用来验收，带特殊特性的文件用来边界测试。这三类的「支持」结论不能共用，在验收表上也该有不同的通过标准。
小结
多 Sheet、公式、格式和常用交互共同决定了用户愿不愿意在浏览器里处理文件。
验收的关键是把「能打开」推到「能上线」：用真实文件、能复查的基准结果和明确的通过标准，替掉演示环节留下的印象。
要看版本要求和支持的文件范围，见《dsh-spreadjs-editor 当前支持什么》；想先看这条链路在代码层面怎么接起来的，可以看《dsh-spreadjs-editor 的集成链路》。