dsh-spreadjs-editor 能不能用在生产环境，除了看功能演示，还要看版本、文件和浏览器兼容边界。提前把这些确认掉，能少返工。
把边界讲清楚，团队才能定下验证范围、验收标准和后续支持，用户也能知道哪些文件适合直接丢进浏览器处理。
版本、文件范围和运行环境这几件事，这篇文章一次说清。
版本和依赖
| 项目 | 要求 |
|---|---|
| 插件版本 | 0.2.0（当前 npm 最新版） |
| Node.js | >=20 |
| DSH | 自带右侧栏的最新 release 版本 |
| 依赖 | 无。插件使用 DSH 自带的右侧栏，不需要第三方侧边栏插件 |
| 内置表格引擎 | SpreadJS 与 Designer，随插件版本一起更新 |
插件在 0.2.0 起改用 DSH 的文档系统接入，不再依赖第三方侧边栏插件。DSH 本身仍在快速迭代，所以这里不锁固定版本；遇到装不上或者行为异常时，先把 DSH 升到最新 release 再复现。
内置的 SpreadJS 与 Designer 同理，插件会持续跟进上游版本，装到哪一版就用哪一版，不单独声明引擎版本号。想确认插件版本，看 npm 页面；想确认当前实际运行的引擎版本，打开任意表格文件，Designer「设置」标签里的「关于」会显示。
需要精确锁定引擎版本的团队，应当在验收时记录下当时安装的插件版本，并在升级插件前重新跑一遍验收清单。按引擎的小版本号去对齐意义不大------插件升级时它就会变。
插件本身以预构建方式分发，安装时不执行 preinstall、install、postinstall 或 prepare 脚本。0.1.4 起发布打包改用 prepack，打包校验也会拒绝任何安装期钩子。需要通过安全审计的团队会比较在意这一点。
长期维护的项目建议锁定验证过的插件版本，升级时记下变更原因。别因为 npm 上出了新版本就直接更新生产环境。
支持哪些文件
插件当前注册并支持打开五种文件：
| 扩展名 | 导入方式 | 需要单独确认的部分 |
|---|---|---|
| .xlsx | ExcelIO 解析为工作簿 JSON | Excel 特性覆盖度 |
| .xlsm | 同.xlsx，走 ExcelIO | 宏不能保留或执行 |
| .csv | 按文本表格导入 | 编码、分隔符、是否含公式 |
| .sjs | SpreadJS 自有格式，原生打开 | 与旧版本 SpreadJS 的兼容性 |
| .ssjson | SpreadJS 自有 JSON 格式 | 与旧版本 SpreadJS 的兼容性 |
有两处要特别当心。
关于宏。 .xlsm 能作为工作簿格式导入，但这只解决了「能打开」，不等于宏能被保留或执行。业务流程依赖宏的话，需要单独验证或者换方案。
关于自有格式的版本兼容。 .sjs 和 .ssjson 是 SpreadJS 的自有格式。用本版本保存的文件，可能无法在更低版本的 SpreadJS 里打开。和旧系统交换文件时，保留原文件并确认兼容性，别用新版本覆盖唯一的副本。
请用项目里的真实文件测试，重点看多 Sheet、公式、样式、合并区域、筛选，以及保存后格式有没有保留。
按文件重要程度分组会更清楚：普通办公表格用来快速体验，关键业务模板用来验收，带特殊特性的文件用来边界测试。这三类不能共用同一条「支持」结论。
和 DSH 自带的表格预览是什么关系
DSH 自带一个只读的表格预览，覆盖 .xlsx、.xls、.csv 和 .tsv，用来看内容足够。
装上插件后，两套实现并存，由 DSH 的注册表按档位决定谁来渲染：默认档优先于内置档，插件停在默认档。所以 .xlsx、.xlsm、.csv、.sjs、.ssjson 由 SpreadJS 打开；.xls 和 .tsv 不在插件的支持清单里，继续走内置预览。
两者的定位不同：内置预览是只读的，用来查看；插件的实现带完整编辑和保存写回。流程只需要看一眼内容，不装插件也能看；要改文件并落盘，才需要插件。
写回文件时的边界
保存（Designer「文件」菜单里的「保存到工作区」）把改动写回你打开的那个文件。它有几条限制，值得在验收时逐条走一遍：
| 限制 | 表现 |
|---|---|
| 只能写会话工作区内 | 目标越出当前会话的工作区（含..逃逸）直接拒绝 |
| 单次保存有体积上限 | 默认 64MB，超出直接拒绝，不做截断 |
| 冲突会拒绝写入 | 文件在打开之后被外部改过，保存被拒绝并说明原因，不覆盖 |
| 载入完成前不能保存 | 工作簿还没读完时保存会拒绝，避免用空表覆盖原文件 |
| 局域网访问需要额外配置 | 通过非回环地址访问时，要把该地址加进 trustedHosts |
最后一条在本地体验时不会遇到，部署到局域网环境才会。如果团队通过 http://192``.168.x.x:端口 这类地址访问 DSH，而保存一直失败，先去检查这项配置。
需要一份副本时，用 DSH 自己的文件下载。Designer 的「文件」菜单已经只保留保存一个动作。
浏览器和文件规模
浏览器版本、工作簿大小、公式数量、图片和样式复杂度都会影响体验。生产上线前应该用接近真实业务的数据量做性能测试。
性能测试不用一开始就追一个抽象的极限数字，更应该看用户能不能在可接受的时间内打开文件、完成编辑和保存。超大文件可以考虑分页、拆分模板，或者调整使用流程。
有件事要提醒：开发环境里能打开一个示例文件，不等于生产环境里所有业务文件都能直接用。
从旧版本升级
升级到 0.2.0 要处理两件事。
先升级 DSH。 插件现在使用 DSH 自带的右侧栏，DSH 版本太旧时插件不会正常工作。先把 DSH 升到最新 release 版本，再升级插件。
卸掉旧的侧边栏插件。 0.2.0 不再依赖任何第三方侧边栏插件，留着不会带来功能，反而多一个需要维护的组件。
从早于 0.1.2 的版本升级的团队还多一件：0.1.2 起插件已经内置 SpreadJS 和 Designer，不再依赖旧版的前置文件查看器插件。升级前要移除那个插件及其 profile patch，否则可能出现 DSH 启动失败或浏览器里编辑器加载不出来。具体包名见仓库 CHANGELOG。
升级后，界面上会有这些差异：
| 位置 | 之前 | 现在 |
|---|---|---|
| Designer「保存」 | 弹框下载到本地 | 直接写回打开的文件 |
| Designer「文件」菜单 | 新建、打开、导入、导出、打印、信息 | 只剩「保存到工作区」 |
| 面板底部状态栏 | 常驻，显示版本与状态 | 已移除，改为右下角浮层 |
| 查看版本 | 底部状态栏 | 「设置」标签里的「关于」 |
| 深色模式 | 工具栏变深，表格仍为白底 | 工具栏与表格一起切换 |
需要保留副本的场景，改用 DSH 自己的文件下载。
升完建议重新验证代表性文件、公式结果、格式保留、保存流程和目标浏览器。生产系统还要保留可回滚的插件版本。
怎么反馈问题
在 GitHub Issue 里提供版本、浏览器、文件类型、复现步骤和必要的最小样例，信息越清楚越容易定位。
文件包含敏感业务数据的话，先脱敏，或者只提供能复现问题的结构和步骤。问题反馈越接近最小可复现样例，越容易变成可验证的修复。
哪些项目可以直接开始
综合上面的边界，下面这些情况可以直接上手：
- 以
.xlsx为主、不依赖宏的报表与数据核对场景。 - 需要人工检查 Agent 生成结果的 Agent 工作流。
- 文件规模可控（建议先用真实文件确认加载时间）的内部工具。
- 已经在用 DSH 处理文件类任务，想补上表格查看与编辑环节的团队。
下面这些要先做专项验证，不建议直接排进生产计划：依赖宏执行的流程、超大工作簿、大量使用自定义函数或特殊对象的模板、以及与旧版本 SpreadJS 双向交换自有格式文件的系统。
小结
能力边界不是发布后的附注，而是上线前的一部分。用真实文件和目标环境走完验证，才能判断插件适不适合你的系统。
把「不替代什么」和「仍需验证什么」写清楚，比笼统承诺「支持 Excel 文件」更经得起核对。