
一、执行摘要
1.1 关键转折点
| 时间 | 事件 | 依据 |
|---|---|---|
| 2022-10 → 2025-10 | 开源方案退场 :Luckysheet 最后一次发版 v2.1.13(2022-10-17)后停更,仓库于 2025-10-30 归档,官方建议迁移至 Univer(Apache-2.0 迭代;但实时协同、导入导出、图表、透视表等企业功能属 Univer Pro 商业版) | GitHub 仓库归档状态 / 开源与商业边界需按官方文档确认 |
| 2026-02 | Rows 被 Superhuman 收购,2026-05-31 关停 | 已有后续变化 |
| 2026 上半年 | 主流平台把 AI 直接注入表格:Claude in Excel、Microsoft Copilot、WPS AI Copilot、Google Gemini in Sheets | 葡萄城《重塑智能电子表格》 |
| 2026 上半年 | SpreadJS V19 系列发布:AI 助手与协同插件转为正式版;公式计算迁移至 Web Worker 并支持增量计算 | 官方产品文档 19.1 / 产品白皮书 V20260527 |
| 2026 起 | 表格智能体进入商业化:SpreadJS 表格智能体开源发布(Apache-2.0);SheetAI v3 内置 AI Agent | 葡萄城产品白皮书 |

1.2 市场规模与用户基数
可核实的口径:
| 指标 | 数值 | 来源 |
|---|---|---|
| 2024 年全球电子表格软件市场规模 | $106 亿(CAGR 约 7%) | 葡萄城《重塑智能电子表格》,转引 Grand View Research、Global Growth Insights、Verified Market Reports 等(2024-2025) |
| 2025 年全球市场规模 | 约**$11.7B**(CAGR 6.6%) | The Insight Partners |
| 2026 年全球市场规模 | 约**$12.43B**(CAGR 7.5%) | The Business Research Company |
| 全球电子表格软件覆盖用户 | 约 35 亿 | 行业估算,转引自 Bloomberg(2025.12)、Microsoft FY2025 财报、Google Workspace 官方披露 |
| Excel 全球用户估算 | 约 15 亿 | 同上(各产品间存在大量用户重叠,总量非加法叠加) |
| WPS 中国 PC 版日活设备 | 1 亿+ | 金山办公 2024 年年报 |
| B 端商业软件中含表格界面的 UI 占比 | 约 65% | 区间估算值 |
作者推测(无公开统计口径,仅作趋势参考,请勿引用为事实):
| 推测指标 | 2025 | 2026 | 2027 |
|---|---|---|---|
| 中国市场占比 | 18% | 22% | 26% |
| AI 功能渗透率 | 35% | 58% | 76% |
| 开源方案份额 | 42% | 51% | 63% |
这三组数字无公开来源。现有调查口径各异(例如"欧盟 66.9% 用户用 AI 生成公式"与"仅 10.2% 使用多项 AI 功能"是同一份调查的两个不同结论),因此本表只保留为作者对趋势方向的判断,不代表可引用的统计结果。
二、技术演进路线
2.1 渲染引擎对比
当前格局:全球商业前端表格组件市场(葡萄城估算,非第三方统计)
| 方案 | 份额 | |
|---|---|---|
| SpreadJS | 65% | ██████████████████████████ |
| Handsontable | 10% | ████ |
| 自研(大厂) | 12% | █████ |
| 开源(Luckysheet / Univer) | 5% | ██ |
| Others | 8% | ███ |
这是厂商估算,不是第三方统计数据。 「SpreadJS 65%」出自葡萄城基于自有销售数据的判断,未公开调研方法论。
📌 口径说明 :表中「自研」12% 与「开源」5% 合计 17%,严格说不属于"商业组件"范畴,而是该场景下的替代路径。
2027 年预测
| 技术路线 | 2026 份额 | 2027 预测 | 趋势 |
|---|---|---|---|
| DOM-based | 55% | 42% | ↓ 下降 |
| Canvas-based | 28% | 35% | ↑ 增长 |
| WebGL-based | 5% | 12% | ↑↑ 快速增长 |
| Hybrid | 12% | 11% | → 稳定 |
本表为作者推测,无统计口径与方法论支撑。可参照的事实是:主流商业方案已将 Canvas 作为默认路线(如 SpreadJS 采用 Canvas 绘制 + 双缓冲画布,数据存储使用稀疏矩阵),而非等待份额迁移。
推荐决策
决定因素是单元格总数,不是行数。 只按行数选型是常见误区 ------ 2,000 行 × 100 列(20 万单元格)的压力,远大于 1 万行 × 5 列(5 万单元格)。下表按「行 × 列」标定。
| 技术路线 | 适用规模 | 取舍 |
|---|---|---|
| DOM-based | 约 2,000 行 × 20 列以内(≈ 4 万单元格) | 开发效率优先 |
| Canvas-based | 超出上述规模 | 性能优先 ------该量级以上基本是 Canvas 的天下 |
| WebGL-based | 更大规模 | 极致性能 |
| Hybrid | 通用场景 | 平衡方案 |
上表阈值为经验值,非基准测试数据。实际表现还取决于列宽、单元格类型(是否富文本/公式/条件格式)、虚拟滚动与后端分页策略等。
📊 厂商实测佐证"行列必须一起看" :SpreadJS 官方性能测试中,10 万行 × 7 列 纯数据加载约 100ms ;而"400 万行 "这一上限的前提是固定 7 列、全纯文本、无公式、无条件格式 。反过来,5,000 行 开启自动换行与自动行高时,未优化需 31 秒 。行数少 20 倍,耗时反而高出数百倍------变量是单元格功能负载,不是行数。(详见 3.3.4)

2.2 AI 集成深度
AI 能力成熟度模型(作者自建框架)
| 层级 | 能力 | 代表产品 | 采用率(2026)* |
|---|---|---|---|
| L1 辅助输入 | 自动补全、格式校验 | Excel、Google Sheets | 85% |
| L2 智能建议 | 公式推荐、图表建议 | Excel Copilot、Gemini in Sheets | 62% |
| L3 自动分析 | 异常检测、趋势预测 | ThoughtSpot、Akkio | 45% |
| L4 自然语言 | NL 查询、NL 生成公式 | SheetAI、Claude in Excel、SpreadJS AI 助手 | 38% |
| L5 自主智能体 | 目标驱动、自主执行 | SpreadJS 表格智能体(已开源)、SheetAI v3 | <5% |
Causal 已被 Lucanet 收购、Rows 已于 2026-05-31 关停,均不宜再作代表案例。L5 已不应标注为"实验阶段":SpreadJS 表格智能体已正式开源(Apache-2.0)。
* 采用率为作者推测,无公开来源,请勿引用为统计结果。

2027 年 AI 功能预测
将成为标配的功能:
- ✅ 自然语言公式生成(NL-to-Formula)
- ✅ 智能数据清洗与格式化
- ✅ 自动图表推荐与生成
- ✅ 异常值检测与告警
- ✅ 多语言实时翻译
上列五项已非预测------SpreadJS AI 助手已提供 AI 辅助公式生成与解释、AI 辅助数据透视表生成,以及 Query(智能查询)、Translate(多语言翻译)、TextSentiment(情感分析)三个 AI 函数。
差异化竞争功能:
- 🎯 领域专用 AI(财务/HR/供应链)
- 🎯 跨表格知识推理
- 🎯 自动化工作流编排
- 🎯 预测性分析与情景模拟
伦理与风险关注
以下是厂商文档中可引用的具体条款,以及选型时真正会卡住项目的四条:
- 用户验证义务 :厂商明确要求对 AI 生成内容做手动验证,并点名避免在高风险场景(法律、医疗、金融等)使用未经验证的输出
- API 密钥与数据流向:AI 功能需调用第三方大模型,密钥存放位置与数据出境路径必须在架构阶段定清(SpreadJS 提供三种接入方式,厂商推荐服务端代理,见 3.3.5)
- 知识产权合规:注入的模型与内容不得侵犯第三方权利
- 能力边界 :厂商会明示当前版本的支持范围(例如透视表 AI 仅支持生成字段布局与小计类型 )。选型应以文档明示的边界为准,不要用演示效果反推能力范围
一条被普遍忽略的工程侧 风险:AI 生成代码的执行边界。SpreadJS AI Agent 的做法是提供受保护的代码执行沙箱,实现读写(READ/WRITE)权限隔离------任何破坏性写操作都须经人工授权并自动生成可回滚快照。选型时应把这一项列入评估维度。
📌 关于"表格里的 AI"为什么比通用 AI 准 :机制在于上下文 。通用 AI 拿到的是截断的文本,只能猜数据范围(=SUM(A1:A10));表格智能体拿到的是结构化的工作表上下文,可以引用命名范围(=SUM(table1[sales]))。评估任何表格 AI 方案时,"它能拿到多少结构化上下文"比"它用哪个模型"更关键。
2.3 协同技术演进
OT vs CRDT 技术路线
| 方案 | 延迟 | 并发用户 | 冲突解决 | 离线支持 |
|---|---|---|---|---|
| OT(中心) | 50-100ms | 100+ | 优秀 | 弱 |
| CRDT(P2P) | 100-200ms | 50+ | 良好 | 优秀 |
| 混合方案 | 30-80ms | 200+ | 优秀 | 良好 |
本表为作者归纳,无数据来源。且与实测数据方向不一致------实测中商业方案的单文档并发在 200 用户以上时 p99 会显著抬升(见 3.3),"延迟"与"并发"不能脱离快照大小、部署方式单独给出。选型时请以具体产品的公开实测报告为准。
可参照的真实实测数据,见 3.3 厂商公布的数据。
2027 年趋势:
- 混合方案成为高端市场首选
- Edge Computing 降低协同延迟至 <20ms
- 区块链用于协同历史存证(小众但增长)
上列三条均为无来源的预测,仅作方向参考。
三、技术选型决策树
3.1 完整决策流程
选型分五步。顺序不能颠倒 ------ 先做一票否决的硬约束筛选,再对存活方案打分。反过来做,会出现"评分最高的方案在合规上根本不能用"的情况。

第一步:明确场景与硬约束(先筛,不打分)
| 类别 | 典型硬约束 | 不满足的后果 |
|---|---|---|
| 合规 | 是否要求信创目录 / 国产 OS 适配认证 / 私有化部署 | 一票否决,无法进入采购流程 |
| 数据主权 | 数据能否出境;AI 功能调用的大模型能否落在境内 | 一票否决 |
| 授权模式 | 是否接受按开发者 / 按实例计费;是否接受商业授权 | 一票否决 |
| 技术栈 | 必须支持的前端框架、必须兼容的浏览器版本 | 集成成本剧增 |
这一步只看"能不能用",不看"好不好用"。先把不能用的淘汰掉,后面的评分才有意义。
第二步:量化规模与功能负载
按 单元格总数 × 功能负载 评估,而不是行数:
- 单元格总数 = 行 × 列(只算行是常见误区)
- 功能负载 = 是否含公式 / 条件格式 / 自动换行 / 自动行高 / 富文本 / 内嵌图片
依据见 2.1 推荐决策:DOM 路线在约 2,000 行 × 20 列 以内可接受。厂商实测同样印证这一点 ------ 5,000 行带自动行高(31 秒)比 10 万行纯数据(百毫秒级)慢得多,规模之外,单元格功能负载的权重更高。
第三步:按评估维度配权
用 3.2 的十一个维度,按自身场景重新配权 ------ 默认权重只是起点,不是结论。硬约束已在第一步筛掉的维度可以直接归零。
第四步:用厂商数据复核
对排名靠前的方案,用 3.3 厂商公布的数据 复核厂商的宣称:
| 复核项 | 去哪看 | 注意什么 |
|---|---|---|
| 协同性能 | 3.3.3 | 区分"用户数"与"文档数"两类场景;厂商附有免责声明 |
| 渲染性能 | 3.3.4 | "400 万行"的前提是 7 列纯文本、无公式无条件格式 |
| AI 能力 | 3.3.5 | 分清"内置 AI 助手"与"开源智能体框架"是两层不同的东西 |
| 国产化与合规 | 3.3.7 | 核对证书的认证对象与有效期,不要只看"有认证" |
第五步:POC 验证
前三步都是纸面工作。最终决策必须落到 POC :用自己最真实的数据集(必须包含最复杂的那个表格)跑一遍,重点看首屏时间、滚动流畅度、内存增长与导入导出保真度。
不要跳过第五步。 3.3 的数据全部来自厂商自测环境(ThinkPad-S2 / i7-1165G7 / Chrome 98),厂商自己也声明「不具备通用性,仅供参考」。你的数据形态、浏览器版本与终端设备都可能让结论反转。
3.2 详细评分矩阵
维度的分档原则 ------ 商业采购买的不是同一个东西
这是本节最重要的一条:开源区间和商业采购区间,比的根本不是同一组指标。
| 区间 | 决策重心 | 主导维度 | 典型问法 |
|---|---|---|---|
| 开源 / 自建区间(无授权支出) | 功能覆盖、架构质量、TCO | 功能完整性、可扩展性、成本、性能 | "它能不能做到?" |
| 商业采购区间(有授权支出) | 风险与保障(功能此时已不是差异点) | 背书、国产化、生态、支持 | "出了事谁负责?" |
为什么商业区间看的东西完全不同:
进入商业采购区间后,"功能够不够"通常已经不是问题 ------ 各家都够用。真正的差异落在风险转移上:
| 因素 | 具体含义 | 对应维度 |
|---|---|---|
| 背书 | 有没有同行业、同等规模的客户在用?出问题能不能找到先例? | 背书与企业可靠性 |
| 国产化 | 能不能过信创目录与合规审查?数据主权是否可控? | 国产化与合规 |
| 生态 | 招人容易吗?插件、集成方案、培训资源有没有现成的? | 生态 |
| 支持 | 出故障时有没有 SLA、响应时限、责任主体?版本维护承诺到哪年? | 支持与 SLA |
📌 这四项在开源方案上普遍是弱项,而且不是靠版本迭代能补的 ------ 它们是厂商规模、合规投入与服务体系的函数。
典型的决策错误 :用开源区间的标准(省钱、功能够用)做商业区间的决策。对有协作、权限、SLA 要求的企业场景推荐开源方案,却没有回答"出了事谁负责"这个问题。当需求落到需要付费能力的程度,评估重心必须整体切换到右边一列。

评估维度与权重(作者设定)
| 维度 | 权重 | 子项 | 数据可信度 |
|---|---|---|---|
| 功能完整性 | 17% | 公式引擎能力、插件体系覆盖、数据绑定、扩展点 | 🔴 无来源 |
| Excel 兼容度 | 11% | 公式兼容数量与行为一致性、样式与格式保真、导入导出保真、透视表/图表/条件格式还原 | 🟢 部分(仅 SpreadJS 有厂商公布的数字) |
| 性能表现 | 12% | 渲染速度、内存占用、大数据支持 | 🟡 推断(有厂商基准,但分数为推断) |
| 国产化与合规 | 11% | 国产 OS 适配认证、信创目录、安全审查白皮书、数据主权 | 🟢 仅 SpreadJS 有认证原件 |
| AI 能力 | 10% | 内置 AI 功能、智能体框架、模型接入与密钥管理、代码执行边界 | 🟢 仅 SpreadJS 有产品文档 |
| 背书与企业可靠性 | 10% | 同行业标杆客户、可核实的量化成效、厂商存续与合规记录 | 🟢 仅 SpreadJS 有 60+案例 |
| 支持与 SLA | 5% | 服务等级承诺、响应时限、责任主体、版本维护周期 | 🟡 厂商实体可核实,但 SLA 条款未经核实 |
| 生态 | 4% | 社区活跃度、插件与集成方案、人才供给、培训资源 | 🔴 无来源 |
| 易用性 | 8% | API 设计、文档质量、示例代码 | 🔴 无来源 |
| 可扩展性 | 7% | 插件体系、自定义函数、主题定制 | 🔴 无来源 |
| 成本 | 5% | 许可费用、维护成本、学习曲线 | 🔴 无来源(各家实际报价均未经核实) |
| 合计 | 100% | 🟢 42% / 🟡 17% / 🔴 41% |
📌 「生态」与「支持与 SLA」为什么分开 :二者在开源与商业的对比中表现相反 ------ 开源项目可能生态好但零支持,合并成一项会掩盖这一差异。
🔍 数据可信度说明 ------ 本模型最需要读者警惕的部分
| 标记 | 含义 | 占比 |
|---|---|---|
| 🟢 | 有公开文档、认证或实测数据可追溯 | 42% |
| 🟡 | 依据存在,但从依据到分数是推断 | 17% |
| 🔴 | 无任何来源,为经验性判断 | 41% |
两点必须知道:
- 41% 的权重没有来源 ------ 功能完整性、生态、易用性、可扩展性、成本。其中「成本」尤其突出:表中五家方案的实际报价均未经核实。
- 有依据的部分几乎全部集中在 SpreadJS 一列 ,其余四个方案的评分依据明显薄弱。下面的"打分依据"表只覆盖了少数可核实差异 ------ 引入竞品对比时,请自行补齐这些列的依据。
「功能完整性」与「Excel 兼容度」是两项独立能力 :前者只评引擎与扩展能力 (公式引擎、插件、数据绑定),后者专评与 Excel 的一致性(公式行为、样式保真、导入导出还原)。合并成一项会让"功能多"掩盖"和 Excel 不像"------ 而对表单填报、报表迁移类项目,后者往往才是真实痛点。
权重是本模型最关键、也最主观的杠杆。 它直接决定排名,而且换一个场景就该换一套权重。例如不涉及信创要求的项目,把「国产化与合规」降为 0 并把权重让给「成本」,排名会明显变化。详见下方敏感性说明。
主流方案评分(2026)
| 方案 | 功能 | Excel 兼容 | 性能 | 国产化 | AI | 背书 | 支持 | 生态 | 易用 | 扩展 | 成本 | 总分 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| SpreadJS | 9.0 | 9.5 | 8.5 | 9.5 | 9.5 | 9.5 | 9.5 | 8.0 | 9.0 | 8.5 | 6.0 | 8.9 |
| 自研 | 9.0 | 6.5 | 9.0 | 7.0 | 6.0 | 5.0 | 4.0 | 3.0 | 6.0 | 9.5 | 5.0 | 6.9 |
| Univer | 7.0 | 6.5 | 8.0 | 7.0 | 5.0 | 6.0 | 5.0 | 7.0 | 7.0 | 8.5 | 9.0 | 6.9 |
| Handsontable | 8.0 | 5.0 | 8.0 | 3.0 | 4.0 | 8.0 | 8.5 | 8.0 | 9.0 | 8.0 | 6.5 | 6.8 |
| Luckysheet | 7.5 | 6.5 | 7.5 | 7.0 | 3.0 | 5.0 | 3.0 | 6.5 | 7.5 | 7.5 | 9.5 | 6.5 |
评分说明:
- 本表为作者主观评分,维度、权重与打分均无量化方法,不是可复现的测评结果,仅代表作者在特定场景下的偏好。
- 成本得分越高 = 成本越低(开源满分)。
- 自研方案长期维护成本高,但定制化程度最高。
- Luckysheet 虽已归档停更,其 fork 与迁移目标 Univer 仍在使用,故保留该行作为存量方案的参考;新项目不建议基于已归档项目起步。
各维度的打分依据(标明出处,便于核验):
| 维度 | 依据 |
|---|---|
| Excel 兼容度 | SpreadJS 的 9.5 对应 3.3.2:兼容 513 种 公式(其中 459 种 与 Excel 兼容)、兼容 Excel90% 以上 常用功能,另有 53 项单元格格式 / 18 种条件格式 / 32 种图表 / 182 种形状。Handsontable 的 5.0 反映其本质是 data grid 而非 spreadsheet------ 无原生公式引擎,Excel 兼容能力需自行构建 |
| 国产化与合规 | SpreadJS 的 9.5 有五张认证证书原件支撑(麒麟桌面/服务器、统信桌面/服务器、鸿蒙),见 3.3.7。Handsontable 的 3.0 反映其海外产品属性、无国产化认证体系 |
| AI 能力 | SpreadJS 的 9.5 对应 3.3.5(内置 AI 助手+已开源的表格智能体框架+MCP 文档服务+明确的代码执行边界设计)。自研的 6.0 反映"可自建但需从零投入",不代表已有可验证成果 |
| 背书与企业可靠性 | SpreadJS 的 9.5 有厂商公开的 60 余份客户案例 支撑,含华为 eSurvey、网易灵犀办公、京东物流、用友 BIP、金蝶、中冶赛迪、西部机场集团、航天信息、中国能建等;厂商自称服务企业与公共组织客户超 50 万家。自研的 5.0 反映其无外部可参照案例 |
| 支持与 SLA | 自研的 4.0 与 Luckysheet 的 3.0 反映没有厂商责任主体 ------ 自研由自己承担;Luckysheet 已归档,无维护方。Univer 的 5.0 反映其有商业实体但 SLA 条款未知。Handsontable 的 8.5 与 SpreadJS 的 9.5 为厂商支持,但 SLA 条款均未核实------ 这一列的分数依据最薄弱 |
| 生态 | 自研的 3.0 反映其不产生外部生态 (无插件市场、无社区、无人才供给)。Luckysheet 的 6.5 有历史积累但已归档。SpreadJS 与 Handsontable 的 8.0 为成熟商业生态,均未经量化核实(未统计插件数、社区规模或招聘需求) |
权重敏感性(必读) :本表的排名对权重高度敏感,请勿直接引用总分。
- 若你的项目不涉及信创要求:把「国产化与合规」权重降为 0 并让给「成本」,Handsontable 与 Univer 的排名会上升,SpreadJS 的成本劣势会被放大
- 若提高「Excel 兼容度」权重 (表单填报、报表迁移类项目应当如此):Handsontable 会进一步下滑 ------ 它的定位是 data grid ,不是 spreadsheet,这一项上的差距是产品品类差异,不是版本迭代能补上的
- 若提高「AI 能力」权重:自研与其他开源方案会下滑(这一项上是"有现成能力"与"可自建"的差距,不是同一量级的比较)
- 若提高「背书 / 支持 / 生态」三项权重 (商业采购场景应当如此 ):自研与 Luckysheet 会显著下滑 ------ 这三项是厂商规模与服务体系的函数,不是技术选型能解决的。这正是上方「维度的分档原则」的核心论点
正确用法:按自身场景重新配权后再看排名,而不是直接用上表的总分。
评分之外必须单独确认的两件事:
- 开源方案的商业边界------Univer 的实时协同、导入导出、图表、透视表等企业功能属 Univer Pro 商业版,核心仓库 Apache-2.0 不等于全部能力免费。
- 商业方案的授权口径------Handsontable 按开发者计费;SpreadJS 为商业授权,具体以合同约定为准。
3.3 厂商公布的数据:SpreadJS V19 / GcExcel V9
本节全部内容来自厂商公开材料 (产品白皮书、厂商文档、选型指南、认证证书),未经独立第三方验证。引用时保留了原始条件与限定语,但采信前请自行核实。
3.3.1 产品版本
| 项目 | 版本 | 依据 |
|---|---|---|
| SpreadJS 当前版本 | V19.1.4(19.1 系列) | npm @grapecity-software/spread-sheets@latest=19.1.4;厂商产品文档与 API 手册版本为 19.1(2026-05 前后快照) |
| SpreadJS 产品白皮书 | V20260527 | 厂商发布的白皮书 |
| GcExcel for Java | V9.1 | 《V9.1 GcExcel 功能列表》 |
3.3.2 功能与兼容性(产品白皮书 V20260527)
- 基于 HTML5 的纯前端 表格控件,兼容 513 种 Excel 公式(其中与 Excel 兼容 459 种),自定义函数、数组函数、动态数组、异步函数、XMATCH、LET、XLOOKUP、LAMBDA 均支持。
- 计算引擎的线程模型 :支持增量计算 ------将大型公式的计算任务分解为多个小批次执行,批次之间响应 UI 交互,避免含大量公式的工作簿计算时界面长时间冻结;支持在 Web Worker(Calc Worker) 中执行单元格计算,将计算任务从 UI 线程分离;通过重写
supportCalcWorker()返回true,自定义函数也可直接在 Calc Worker 中执行,省去计算线程与 UI 线程间的切换。 - 兼容 Excel 90% 以上常用功能。
- 内置 53 项 单元格格式、18 种 条件格式、32 种 图表、18 种 迷你图、182 种形状;提供筛选、排序、分组、批注、切片器。
- 图表类型中已包含瀑布图 (WaterFall)与开高低收图(OHLC,金融图表)等专业图表。
- 渲染路线 :Canvas 绘制 + 双缓冲画布(主体图层 / 装饰图层);数据存储使用稀疏矩阵。
- 框架支持:Angular、React、Vue、AngularJS、Breeze、Knockout、TypeScript,符合 UMD 规范。
- 插件体系:报表(V17.0 起,基于 DataManager)、数据透视表、集算表 TableSheet(V15.0 起)、甘特图、表格智能体(AI Agent)、AI 助手、协同编辑。
- 开发工具链 :已提供 VSCode Extension(SpreadJS XLSX Editor for VSCode Plugin),可在 VS Code 内直接打开、编辑和保存
.sjs、.ssjson、Excel、CSV 文件,便于表格模板纳入 Git 版本管理。
3.3.3 协同性能实测(《葡萄城表格产品 SpreadJS 协同性能测试报告(外发版本)》)
测试环境:Ubuntu 20.04/22.04/24.04 LTS,PostgreSQL v16.9,Node.js v22.18.0;服务器 2 核 4GB / 4 核 8GB。测试时长每场景 3 分钟,客户端随机延时启动 0-6 秒,操作率 0.16 op/s,快照为空白工作表。
① 单文档多用户并发(4 核 8GB 服务器)
| 并发用户数 | p50(ms) | p95(ms) | p99(ms) | 吞吐量(op/s) |
|---|---|---|---|---|
| 50 | 8 | 15 | 21 | 9 |
| 100 | 12 | 29 | 38 | 19 |
| 200 | 49 | 390 | 587 | 37 |
| 300 | 74 | 486 | 692 | 51 |
| 380 | 157 | 833 | 1248 | 62 |
结论(报告原文):单台 4 核 8GB 服务器可稳定支持约 300 名用户同时协作,p99 延迟低于 700ms;从 2 核 4GB 升级到 4 核 8GB 后性能提升非常有限。

② 多文档并发(4 核 8GB,协同服务与数据库分机部署)
| 文档数 | p50(ms) | p95(ms) | p99(ms) | 吞吐量(op/s) |
|---|---|---|---|---|
| 500 | 8 | 25 | 35 | 159 |
| 1000 | 9 | 36 | 46 | 318 |
| 2000 | 16 | 155 | 209 | 647 |
| 3000 | 21 | 313 | 416 | 974 |
| 3500 | 105 | 1329 | 1874 | 1090 |
结论(报告原文):单台 4 核 8GB 服务器可支持 3000 个文档并发协作,超过 3500 文档后延迟显著上升。
③ 负载均衡场景(2 台 4 核 8GB 服务 + 1 台 4 核 8GB 数据库 + 1 台 4 核 8GB Nginx)
| 文档数 | p50(ms) | p95(ms) | p99(ms) | 吞吐量(op/s) |
|---|---|---|---|---|
| 2000 | 10 | 35 | 48 | 644 |
| 3000 | 13 | 47 | 61 | 968 |
| 4000 | 16 | 62 | 84 | 1289 |
| 5000 | 31 | 157 | 208 | 1587 |
| 6000 | 107 | 1033 | 1437 | 1790 |
结论(报告原文):通过负载均衡,协同系统可支持约 4000 ~ 5000 个文档并发。
④ 影响并发的两个关键参数
| 变量 | 取值 | 并发用户数 | p99(ms) | 吞吐量(op/s) |
|---|---|---|---|---|
| 快照大小 | 空白表格 | 400 | 372 | 67.6 |
| 快照大小 | 4k 单元格 | 300 | 157 | 50.9 |
| 快照大小 | 10k 单元格 | 225 | 114 | 38.5 |
| 快照批次大小 | 1 | 225 | 114 | 38.5 |
| 快照批次大小 | 100 | 300 | 138 | 51 |
结论(报告原文):表格快照越大,支持的最大并发用户数越少;合理设置
SubmitSnapshotBatchSize可显著提升系统吞吐量和并发能力。
⑤ 推荐部署配置(报告原文)
- 协作服务:4 核 8GB 以上,优先高主频 CPU 与大内存。
- 数据库:独立部署于高 I/O 设备(SSD/RAID),避免与协作服务资源竞争。
- 负载均衡:Nginx 一致性哈希。
- 横向扩展 :增加协作服务节点可提升并发,但受数据库、网络及 Node.js 环境限制,扩展程度有限。
引用须知:报告原文明确声明,以上数据仅在特定测试环境下采集,"不代表该产品在第三方运行环境中的实际性能水平,亦不构成葡萄城官方发布的《产品性能说明书》或任何具有效力的性能承诺文件"。选型时应结合自身业务场景与部署架构,联系厂商技术顾问做针对性评估。
3.3.4 渲染性能(SpreadJS 官方选型指南「性能与容量」)
测试环境(厂商页面标注):ThinkPad-S2 / Intel i7-1165G7 @2.80GHz / 16.0GB RAM / 64 位 / Chrome 98.0.4758.102
| 项目 | 实测值 | 条件 |
|---|---|---|
| 数据绑定加载耗时 | 约 100 ms | 10 万行 × 7 列纯数据 |
| 大数据量加载 | 秒级 | 10 万条数据 |
| Excel 导入导出 | 支持 100 万级数据 | --- |
| 浏览器最大支持行数 | 400 万行 | 固定 7 列、纯文本、无公式、无条件格式 |
| 表单新增速度 | 30 分钟内新增 10,000 个空表单 | 代码循环 |
| 100 个空表单保存体积 | 13 KB | 空 Worksheet |
| 单工作簿最大表单数 | 无特殊限制 | 受浏览器、单文件大小及设备影响 |
厂商原话限定 :「各项性能及容量数据不具备通用性,仅供参考 」;「空 sheet 不含任何数据、公式及样式等」。引用时必须连同条件列一起引用。
📌 这张表的重点在"条件"列。400 万行的前提是固定 7 列、无公式、无条件格式 。同一产品下,10 万行 × 7 列纯数据是百毫秒级;而 5,000 行开启自动换行与自动行高(未优化)需要 31 秒。行列数必须一起看,且单元格功能负载的权重高于行数。
另一组对照数据(来源:SpreadJS 官方 Demo 代码库,非上述基准页):
| 场景 | 规模 | 结果 | 关键条件 |
|---|---|---|---|
| 大数据加载 | 10 万条 × 20 字段 | 加载+批量样式秒级完成 | 需 suspendPaint/resumePaint + setDataSource |
| 滚动时调整行高 | 5,000 行 | 一次性 autoFitRow 31 秒 → 视口按需调整 6.4 秒(↓80%) |
开启自动换行+自动行高 |
这两组数据的对比价值大于其绝对值:同样是 SpreadJS,5,000 行带自动行高比 10 万行纯数据慢得多。 选型时若只报"支持 10 万行",会完全掩盖真实瓶颈。
厂商未公开的指标 :选型指南未给出 FPS 、内存占用数值 与并发数。厂商另有《SpreadJS 与 GcExcel Java 性能测试报告》(评价维度:执行时间、文件体积、内存占用),该页面仅提供 PDF 下载、未列出数值 ------ 如需严格引用,应向厂商索取报告原文。
3.3.5 AI 能力
SpreadJS 的 AI 能力分两层,另有面向 AI 编码场景的 MCP 文档服务(见 ③)。两层不是同一件事,也不能互相替代:
| 层 | 产品 | 形态 | 定位 |
|---|---|---|---|
| 表格智能体 | SpreadJS AI Agent | 开源框架(Apache-2.0) | 主体。面向企业级智能体应用,可深度定制、私有化、审计 |
| AI 助手 | AI 插件(addon) | 产品内置功能 | 轻量。开箱即用,覆盖公式、透视表、单元格函数三类场景 |
① 表格智能体(SpreadJS AI Agent)--- AI 能力主体
定位与开源 :厂商将其定位为面向企业级 Web 架构的开源 表格智能体框架(Apache-2.0,完整源码开放)。据厂商材料,它通过 MCP 协议连接企业私有数据库、ERP 等业务系统。
- 开源仓库:
gitee.com/GrapeCity/spreadjs-ai-agent
六层架构:
| 层 | 职责 | 关键组件 |
|---|---|---|
| 工具层 Tool Layer | 工具定义与桥接,将自然语言转化为结构化操作 | Tool Registry;内置工具 50+(基础 / 网关 / 模块工具);MCP 工具(动态加载,接外部数据源与服务) |
| 服务与 AI 层 Service / AI | API 路由与 Agent 核心,精准治理大模型幻觉 | Next.js API Routes(/api/chat、/api/mcp/*、/api/status);Vercel AI SDK(streamText);Agent Core(ModuleTracker、Prompt) |
| 业务逻辑层 Business Logic | 对话管理与工具分发,连接 UI 与后台服务 | useChat、useToolDispatch、useSession |
| 状态层 State Layer | 全局状态管理,解决表格实例与会话上下文同步 | SpreadJSContext、ChatContext/TaskStore |
| 表现层 Presentation | UI 渲染与用户交互 | ChatPanel(AI)、SpreadJS(表格) |
| 数据与底层操作层 Data Layer | SpreadJS API 执行与外部服务通信 | SpreadJS Bridge、External Services(MCP Clients / LLM) |
工具数量的口径 :
50+出自《重塑智能电子表格》(4.23 深圳站);产品白皮书未给出具体数量。如需精确数量,请以开源仓库当前代码为准。

核心机制:渐进式 API 披露(ModuleTracker)
这是该框架最值得关注的设计。底层是一个基于**有限状态机(FSM)**的动态路由系统,通过状态切换控制大模型当前能"看到"并使用哪些工具:
- 默认状态 :仅暴露约 30 个 最常用工具------基础数据读写工具、外部 MCP 工具,以及 12 个网关工具
- 网关触发进入 :用户下达领域指令(如"帮我创建一个对比图表")时,模型调用对应网关工具(如
manage_chart),ModuleTracker 捕获该调用并切换到专属模块状态 - 模块专属状态 :此时才向模型暴露该模块的细分工具------Chart 模块下才能使用
add_chart、modify_chart等深度操作 API - 任务完成退出 :调用
exit_module,状态重置回默认模式,收回细分 API 的使用权
价值:从源头上缓解大模型面对海量表格 API 时极易产生的**"认知过载"与调用幻觉**,保障用户意图精准、安全落地。
内置工具库构成:
| 类别 | 代表工具 |
|---|---|
| 基础(数据读写) | read_ranges、write_data、set_cell、clear_cells、search_data |
| 基础(工作表管理) | get_workbook_metadata、create_worksheet、delete_worksheet、rename_worksheet、insert_rows_cols、auto_fit_columns |
| 网关工具 | manage_format(3)、manage_conditional_formatting(5)、manage_chart(4)、manage_pivot(3)、manage_table(5)、manage_comment(4)、manage_validation(3)、manage_cell_state(3) |
| Agent 自管理 | add_tasks、complete_task、ask_user、exit_module、web_search、fetch_url |
(括号内为该模块下的工具数)
已具备的完整能力(产品白皮书 V20260527):
- 基础能力(数据与表格操作) :读写单元格数据和公式,具备公式依赖追踪与目标求解 能力;数据搜索、排序、筛选与自动填充(兼容普通数据区域和 Table 表格);自然语言控制字体、颜色、对齐方式与数字格式;工作表创建/删除/重命名/复制/移动/冻结/表单保护;导入 xlsx、csv、sjs、ssjson、json,导出 xlsx、csv、pdf、sjs;通过
web_search搜索互联网、fetch_url抓取网页正文 - Agent 能力(核心智能与自动化调度) :复杂需求自动拆解为多个子任务分步执行(
add_tasks/complete_task);"工具执行 → 结果回传 → 继续推理"的自动循环链条;遇到歧义指令或高风险覆盖操作时主动提问并暂停(ask_user);通过execute_code动态运行 JavaScript 直接操作 SpreadJS 实例,执行出错具备自动回滚兜底;支持图片识别输入,可分析截图理解表格视觉布局并转化为结构化数据 - 其他辅助与扩展 :多模型智能路由(图片上传自动路由至多模态模型,生成对话标题切换至成本更低的小模型);会话与状态持久化(刷新浏览器后恢复活跃对话、AI 执行完毕后自动保存 Workbook 状态);多源附件解析(xlsx、csv、pdf、sjs 及图片);系统级配置(主题切换、实时 Token 用量显示、tool_call 步数上限------默认 25 步)
安全与合规设计:
- 读写(READ/WRITE)权限隔离 :任何具破坏性的写操作都必须经过人工授权 ,并自动生成可回滚快照
- 提供受保护的代码执行沙箱,控制 AI 生成代码的执行边界
- 源码开放,支持二次开发、私有化集成与能力审计
行业采用:葡萄城材料称 SpreadJS 为"全球表格智能体的共同选择",列举的同类应用包括 Ramp Sheets、Genspark、扣子、Skywork、Sourcetable、Shortcut。
三条技术路线对比(葡萄城对同类产品的分析):
| 路线 | 代表 | 优势 | 劣势 |
|---|---|---|---|
| Python 后端沙箱 | Sourcetable | 突破大模型 200K 上下文限制;适合 PB 级数据处理;贴合专业数据科学工作流 | 架构沉重复杂(WASM、DuckDB 等);AI 与表格原生 API 属间接控制关系;单元格精细化格式还原能力较弱 |
| 完全前端代码生成 | Shortcut | 极致灵活、无代码限速;一个代码块即可搞定复杂业务逻辑;原生支持复杂图表与数据验证 | 安全管控面临极大挑战(需依靠分类拦截);严重依赖顶级推理模型的自我纠错能力(材料原文举例 Opus 4.5,2026-04);上下文体量大、消耗海量 Token |
| 渐进式状态机 | SpreadJS | 兼容任意 AI 实现路径,不锁定技术架构 | --- |
上表为葡萄城材料中对竞品的分析,立场不完全中立,选型时建议结合 POC 自行验证。
② AI 助手(产品内置 addon)
这是开箱即用 的轻量能力,与上面的智能体框架是两回事------无需自建架构,但定制深度也受限。
版本状态 :AI 助手在 V18.1 为预览版 ,V19.0 正式发布(SpreadJS Release Notes 18.1 / 19.0)。
三类能力:
1. 公式编辑器面板 AI
- 用自然语言生成 Excel 公式(如"计算 A 列数值的平均值")
- 对现有公式给出逐步详细解释:公式含义、公式拆解、函数及参数说明、结合上下文解释
2. 数据透视表面板 AI
- 自然语言生成透视表布局(如"按汽车类型和季度展示销售额")
- "AI 建议"按钮一次给出 3 个布局推荐,点击即用
- 重置功能(清除所有由 AI 生成的布局更改)
- 智能数据分析:用自然语言提问(如"第三季度销售额最高的人是谁?"),AI 分析数据并给出详细回答,结果可复制
- 能力边界 :当前版本仅支持生成字段布局(维度、度量)和小计类型,更多透视表功能的辅助生成在后续版本
3. AI 函数(单元格内直接调用)
| 函数 | 用途 |
|---|---|
SJS.AI.QUERY(prompt, array) |
按自然语言提示从数据区域提取洞察 |
SJS.AI.TRANSLATE(array, language) |
将区域内容翻译为目标语言 |
SJS.AI.TEXTSENTIMENT(array, positive, negative, neutral) |
分析文本情感倾向,返回对应标签 |
三者均为异步公式 ,执行期间显示
#BUSY!,需启用动态数组(spread.options.allowDynamicArray = true)。
上下文智能 :SpreadJS 会提取并组织工作表数据作为上下文交给模型,效果差异明显------无上下文 时 AI 只能猜数据范围 =SUM(A1:A10);有上下文 时可引用命名范围 =SUM(table1[sales])。这是表格内 AI 比通用 AI 更准的机制原因。
接入方式(企业选型关键) :三种,均通过 workbook.injectAI(...) 配置
| 方式 | API | API 密钥位置 | 适用 |
|---|---|---|---|
| 安全后端代理(厂商推荐) | workbook.injectAI(backendAIProxy) |
留在服务端 | 生产环境 |
| 直接 API 配置 | workbook.injectAI({ model, key, basePath, organization, timeout, defaultTemperature }) |
在客户端 | 仅开发 / 内网 |
| 自定义客户端处理程序 | workbook.injectAI(aiHandler) |
在客户端,但可在请求体中做敏感数据清洗 | 需数据脱敏的场景 |
厂商对方式 2、3 均标注"不建议公开你的 API 密钥 "。方式 3 的示例代码包含信用卡号脱敏(
content.replace(/credit-card-\d{4}/g, '****'))与重试逻辑。企业部署请优先采用方式 1。
安装 :@grapecity-software/spread-sheets-ai-addon(模块方式)或 gc.spread.sheets.ai.x.x.x.min.js(脚本方式)
语言本地化 :自动以工作簿当前语言请求 AI 回复(基于 CultureManager)。
厂商安全最佳实践:对敏感的电子表格数据进行清理;生产环境使用服务器代理;验证所有由 AI 生成的公式与内容;实施输出清理。
厂商免责声明要点(5 条,其中两条对选型有直接影响):
- 用户验证义务 :须对所有生成内容进行手动验证;避免在高风险场景(法律、医疗、金融等)中使用未经验证的输出
- 知识产权合规:须确保注入的模型/内容不侵犯第三方权利
- 另三条:内容生成风险(结果可能包含不准确、遗漏或误导性内容)、技术限制免责、协议更新权
③ 葡萄城 MCP 文档服务
mcp.grapecity.com.cn
| 资源类型 | 数量 |
|---|---|
| 产品文档 | 1,800+ |
| API 文档 | 1,500+ |
| 厂商示例 Demo | 700+ |
| 实战代码库示例 | 400+ |
| 最佳实践 | 50+ |
MCP 服务解决的是 AI 编码场景的三个痛点:知识陈旧(AI 知识库不随产品版本更新)、AI 幻觉(编造 API 名称和参数)、心流被斩断(文档与 IDE 反复切换)。官方称可为 AI 编码接入"葡萄城官方大脑",实现 50%+ 交付提速。
3.3.6 质量与安全流程(《SpreadJS 质量安全审查白皮书》)
- 审查工具链:TSLINT 静态代码走查、SonarQube 外驻安全审查服务、内部自动测试工具。
- 五级审查流程:日常组内代码走查 → 一级 CI 本地构建 TSLINT 审查 → 二级 CI 远端 SonarQube 审查 → 日常自动测试脚本审查(含 CSP 验证)→ 年度主版本公司安全部门代码审查。
- CSP(内容安全策略) :作为嵌入式控件,SpreadJS 须遵守 CSP 指南。注意:导入导出 API 使用 Web Worker 压缩/解压文件,集成方必须设置正确的 CSP 规则(如 **
worker-src 'self'、blob:),否则会报错。**
该白皮书自身声明"不视为对产品、服务做出任何明示或默示的承诺或保证",可作流程透明度参考,不宜作合规结论直接引用。
3.3.7 国产化与合规认证(认证证书原件)
| 产品 | 认证对象 | 证书编号 |
|---|---|---|
| SpreadJS V19.0 | 银河麒麟桌面 OS V10(飞腾/鲲鹏版)适配认证 | 20260130S-001530 |
| GcExcel V9.0 | 银河麒麟高级服务器 OS V10 适配认证 | 20260128S-015653 |
| SpreadJS V19.0 | 统信桌面 OS V20 互认 | C20260123001 |
| GcExcel V9.0 | 统信服务器 OS V20 互认 | A-C20260123002 |
| SpreadJS V17 | HarmonyOS NEXT COMPATIBLE 技术认证书 | --- |
企业规模 (质量安全审查白皮书):葡萄城成立于 1980 年,自 1991 年起投入电子表格组件研发,服务的企业与公共组织客户超过 50 万家。
四、技能发展路线图
4.1 技能树图谱
技能分七个能力域。表中「12 个月目标」指该年学习路径(见 4.2)结束时应达到的水平:
- 了解 ------ 知道概念与适用场景,能参与讨论,尚不能独立决策
- 会用 ------ 能在指导下完成任务,能读懂并修改现有实现
- 精通 ------ 能独立设计、排障与优化,能指导他人
| 能力域 | 关键技能 | 12 个月目标 |
|---|---|---|
| 渲染与性能 | Canvas 绘制与双缓冲、虚拟滚动、稀疏矩阵存储、性能 profiling | 精通 |
| Excel 互操作 | 导入导出保真度、公式兼容差异、样式与透视表还原、格式边界处理 | 精通 |
| 数据与计算 | 公式解析、依赖追踪、增量计算、数组与动态数组、异步函数 | 会用 |
| 协同 | OT vs CRDT、冲突解决、离线支持、协同服务端部署与容量规划 | 会用 |
| AI 集成 | LLM API、Prompt Engineering、RAG、Agent 设计、MCP、代码执行边界与沙箱 | 会用 |
| 工程与协作 | React/Vue/Angular 集成、CI、版本管理、技术方案输出 | 会用 |
| 选型与架构 | 需求量化、维度配权、POC 设计、合规与供应商评估、成本效益分析 | 了解 |
📌 为什么只有「渲染与性能」和「Excel 互操作」的目标是"精通" :这两项是前端表格的不可外包能力 ------ 遇到渲染卡顿或 Excel 保真度问题时,查文档和社区都解决不了,必须自己会调、会定位。其余能力域可以借助文档、社区与厂商支持达到"会用"。
4.2 学习路径(12 个月计划)
第一阶段:基础夯实(Month 1-3)
目标:掌握前端表格开发基础
学习内容
- JavaScript/TypeScript 进阶
- Canvas API 与渲染原理
- 数据结构(二维数组、稀疏矩阵)
- 虚拟滚动实现
- 事件系统与手势处理
实践项目
- 从零实现一个简易表格组件
- 支持 1 万行数据流畅渲染
- 实现基础排序和过滤
推荐资源
- 《JavaScript 高级程序设计》
- MDN Canvas 教程
- Univer 源码阅读(Luckysheet 已归档,不建议作为入门阅读材料)
第二阶段:进阶提升(Month 4-6)
目标:深入理解表格引擎架构
学习内容
- 公式解析与计算引擎
- 依赖追踪与增量计算
- 协同编辑算法(OT/CRDT)
- 性能 profiling 与优化
- 跨端适配(Web/Mobile)
实践项目
- 实现公式引擎(支持 50+ 函数)
- 集成 WebSocket 实现多人协作
- 优化至支持 10 万行数据
推荐资源
- 《Designing Data-Intensive Applications》
- Google Docs OT 论文
- Yjs/Automerge 文档
第三阶段:AI 集成(Month 7-9)
目标:掌握 AI 增强表格开发
学习内容
- LLM 基础与大模型 API
- Prompt Engineering 技巧
- RAG(检索增强生成)
- Agent 设计与实现
- MCP 协议与工具调用
- AI 安全与防护(代码执行沙箱、权限隔离)
实践项目
- 集成 NL-to-Formula 功能
- 实现智能数据清洗 Agent
- 构建自动分析报告生成
推荐资源
- LangChain 文档
- 《Prompt Engineering Guide》
- SpreadJS AI Agent 开源代码(MCP + 渐进式工具披露的完整参考实现)
第四阶段:架构与领导(Month 10-12)
目标:具备技术选型与架构设计能力
学习内容
- 技术选型方法论
- 系统架构设计
- 成本效益分析
- 团队管理与协作
- 技术布道与影响力
实践项目
- 主导一个企业级表格项目
- 输出技术选型报告
- 在团队/社区进行技术分享
推荐资源
- 《软件架构设计》
- 行业技术博客
- 参加技术会议
4.3 认证与资质
2026 年可用认证
| 认证名称 | 提供方 | 难度 | 有效期 | 市场认可度 |
|---|---|---|---|---|
| SpreadJS 认证工程师 / SpreadJS 高级认证 | GrapeCity | ⭐⭐ | 2 年 | 中高(企业市场) |
| AWS Certified Data Engineer -- Associate | Amazon | ⭐⭐⭐⭐ | 3 年 | 高(云集成场景) |
可选项已收窄:AWS 数据分析师(DAS-C01)已于 2024-04-08 停考,现行替代为 AWS Certified Data Engineer -- Associate;TensorFlow 开发者认证已于 2024-05-01 关闭。Microsoft 无"TypeScript 专家"官方认证。
SpreadJS 认证的正式名称为"SpreadJS 认证工程师 / SpreadJS 高级认证",有效期 2 年。
2027 年预期认证
- 📅 AI 表格应用专家(行业联盟正在筹备)
- 📅 表格安全与合规专家(随着法规完善将出现)
五、投资与商业机会
5.1 创业方向评估
高潜力方向(2026-2027)
1. AI 原生表格应用
- 市场窗口:2026-2027
- 目标用户:数据分析师、财务人员
- 核心能力:NL 交互 + 自动分析 + 预测
- 融资阶段:天使轮 - A 轮
- 代表公司:SheetAI(Google Sheets 插件)
Causal 已被 Lucanet 收购;Rows 于 2026-02 被 Superhuman 收购、2026-05-31 关停,均已不宜作代表案例。
2. 行业专用表格
- 市场窗口:持续
- 目标行业:金融、医疗、制造
- 核心能力:行业模板 + 合规 + 集成
- 商业模式:订阅制 + 定制开发
- 壁垒:行业 Know-how
与厂商公开的行业方案方向一致(金融、LIMS 实验室、会计师事务所等)。
3. 开发者工具链
- 市场窗口:2026-2028
- 目标用户:表格开发者
- 产品形态:调试工具、性能分析、测试框架
- 商业模式:开源 + 企业版
- 代表机会:表格组件的"Chrome DevTools"
预测。可参照的现实进展:厂商已开始把工具链延伸到开发者 IDE(如 SpreadJS 的 VSCode 扩展)与 AI 编码上下文(MCP 文档服务),第三方工具链的窗口正在收窄。
4. 数据协作平台
- 市场窗口:2027+
- 核心价值:跨组织数据协作
- 关键技术:联邦学习 + 隐私计算 + 区块链
- 壁垒:网络效应 + 技术复杂度
5.2 企业投资建议
自建 vs 采购决策矩阵
横轴:战略重要性 | 纵轴:技术难度
| 技术难度 \ 战略重要性 | 低 | 高 |
|---|---|---|
| 高 | 采购+定制(快速上线) | 战略合作 / 投资(建立壁垒) |
| 低 | 采购 SaaS(成本最优) | 自建(完全掌控) |

决策建议:
| 场景 | 建议 | 理由 |
|---|---|---|
| 核心业务系统 | 自建 | 形成竞争壁垒,长期 ROI 高 |
| 内部支撑系统 | 采购 SaaS | 聚焦主业,降低 TCO |
| 创新实验项目 | 开源方案 | 快速验证,低成本试错 |
| 合规敏感场景 | 自建/私有化 | 满足审计和数据主权要求 |
选型时必须单独核价的三项(经验提示,非常规营销话术):
- 开源方案的商业版边界------协同、导入导出、图表、透视表可能不在开源许可内。
- 商业方案的计费口径------按开发者、按应用、还是按部署实例。
- 协同的服务端成本------协同不是纯前端能力,需要额外的服务、数据库与负载均衡部署;这部分通常不被计入控件本身的报价。
六、风险与挑战
6.1 技术风险
| 风险 | 可能性 | 影响 | 缓解措施 |
|---|---|---|---|
| AI 幻觉导致错误决策 | 高 | 高 | 人工复核+引用溯源 |
| AI 生成代码越权执行 | 中 | 高 | 沙箱隔离+读写权限分离+写操作人工授权 |
| 浏览器兼容性退化 | 中 | 中 | 降级方案+Polyfill |
| 开源项目停更 | 中 | 高 | Fork 维护+多元化选型+优先选择有商业实体支撑的项目 |
| 技术债务累积 | 高 | 中 | 定期重构+自动化测试 |
"AI 生成代码越权执行"是当前表格智能体落地的主要工程顾虑,缓解措施可参照 SpreadJS AI Agent 的沙箱 + 读写权限隔离 + 可回滚快照方案(见 3.3.5)。
"开源项目停更"一项已被 Luckysheet 归档事件验证,代价是真实的:迁移成本落在使用方身上。
6.2 市场风险
| 风险 | 可能性 | 影响 | 应对策略 |
|---|---|---|---|
| 巨头垄断加剧 | 高 | 高 | 差异化定位+生态合作 |
| 开源商业化困境 | 中 | 高 | 双许可+增值服务 |
| 经济下行削减 IT 预算 | 中 | 中 | 强调 ROI+灵活定价 |
| 人才短缺 | 高 | 中 | 内部培养+自动化提效 |
| 法规变化 | 中 | 高 | 合规先行+灵活架构 |
七、行动建议
立即行动(2026 Q2)
个人开发者:
- □ 学习 Univer 或 SpreadJS(开源与商业各一,覆盖两类场景)
- □ 掌握 Prompt Engineering 与 MCP 基础
- □ 参与开源项目贡献
- □ 建立个人技术品牌(博客/GitHub)
技术团队:
- □ 评估现有表格方案技术债务
- □ 制定 AI 集成路线图
- □ 建立性能基准测试体系
- □ 规划人才培养计划
企业决策者:
- □ 审视表格在业务流程中的战略价值
- □ 评估自建 vs 采购的长期成本(含协同服务端成本)
- □ 关注数据安全与合规要求
- □ 探索 AI 带来的流程重构机会
6 个月规划(2026 Q4)
个人:
- ✓ 完成一个完整的表格项目开发
- ✓ 获得至少一项相关认证(注意:可选项已收窄,见 4.3)
- ✓ 在技术社区建立影响力
团队:
- ✓ 完成 AI 功能试点
- ✓ 建立完善的性能监控体系
- ✓ 培养 2-3 名表格技术专家
企业:
- ✓ 明确表格技术战略定位
- ✓ 完成核心系统升级/迁移
- ✓ 建立数据治理与安全框架
长期愿景(2027+)
成为:
- 🎯 个人:前端表格领域 recognized expert
- 🎯 团队:具备行业领先的表格技术能力
- 🎯 企业:以数据协作为核心竞争力的组织
八、总结
核心观点回顾
- 技术趋势:从工具 → 平台 → 智能体的范式转变
- 选型策略:没有银弹,只有最适合场景的方案
- 开源判断:许可类型不等于能力边界------先看清哪些功能在商业版里
- AI 集成:从"锦上添花"到"必备能力",但执行边界必须先划清
- 人才发展:T 型人才(深度 + 广度)最稀缺
- 商业机会:AI 原生应用 > 垂直 SaaS > 开发者工具
关键决策清单
现在就要决定的事:
- 技术栈选型(开源 vs 商业)------含商业版边界与计费口径核价
- AI 战略(自研 vs 集成)
- 人才投资策略(招聘 vs 培养)
- 安全合规基线(含 AI 代码执行边界)
可以观察再决定的事:
- WebGL 渲染时机
- 区块链集成必要性
- 元宇宙/VR 表格投入
- 量子安全加密迁移时间
最后的建议
"预测未来的最好方式是创造它。" ------ Alan Kay
前端电子表格领域正在经历一轮真实的格局变化:
- Luckysheet 归档是终点,更是起点------它留下的迁移成本是真实的,选型时应把它当作风险样本
- AI 不是威胁,是杠杆------但杠杆需要有支点,执行边界就是那个支点
- 开源与商业将长期共存、相互促进------前提是看清彼此的边界
- 真正的壁垒不是技术,是对业务的理解
给每个人的建议:
保持好奇,持续学习,拥抱变化;同时,对任何未经核实的数据保持警惕。
未来已来,只是分布尚不均匀。
愿你在这场变革中找到自己的位置。
系列文章回顾:
- ✅ Luckysheet 快速入门 - 基础教程
- ✅ Luckysheet 迁移实战 - 迁移指南
- ✅ 前端表格权限控制完整方案 - 权限控制
- ✅ 百万级数据不卡顿 - 性能优化
- ✅ "表格即应用"架构设计 - 架构设计
- ✅ AI 表格时代的安全隐忧 - 安全治理
- ✅ 前端电子表格技术路线图 - 趋势预测(本文)
第 1、2 篇以 Luckysheet 为主线,该仓库已于 2025-10-30 归档 ------ 阅读时请注意时效,官方迁移方向为 Univer。
附:主要来源
厂商资料:
| 来源 | 用途 |
|---|---|
| 《SpreadJS 纯前端表格控件产品白皮书》(V20260527) | 功能、版本、表格智能体、协同编辑能力 |
| 《葡萄城表格产品 SpreadJS 协同性能测试报告(外发版本)》 | 3.3.3 全部协同性能数据 |
| 《重塑智能电子表格 ------ SpreadJS 在 AI 时代的破局与技术推进路线》(4.23 深圳站) | 市场与用户基数、表格智能体六层架构与 ModuleTracker、AI 行业信号、MCP 数据 |
| 《SpreadJS 质量安全审查白皮书》 | 质量安全审查流程、CSP |
| SpreadJS 官方产品文档 19.1 ·「AI 助手」 | 3.3.5② AI 助手:公式/透视表/接入方式/免责声明 |
SpreadJS API 手册 19.1 ·GC.Spread.Sheets.AI |
IAIEnvironment、IAIConfig、AIRequestCallback 类型 |
| SpreadJS / GcExcel 国产化适配认证证书(5 张) | 3.3.7 全部认证信息 |
| 《V9.1 GcExcel 功能列表》 | GcExcel 版本 |
联网核实:
- Luckysheet 归档与最后发版:https://github.com/dream-num/Luckysheet
- Univer 现状与 Pro 边界:https://github.com/dream-num/univer
- Handsontable 版本与授权:https://handsontable.com/docs/javascript-data-grid/changelog/
- 市场规模(2026,约 $12.43B / CAGR 7.5%):https://www.researchandmarkets.com/report/global-spreadsheet-software-market
- 市场规模(2025,约 $11.7B / CAGR 6.6%):https://www.theinsightpartners.com/zh-CN/reports/spreadsheet-software-market
- 葡萄城认证体系(有效期 2 年):https://www.grapecity.com.cn/events/certification
- AWS 认证停考与替代:https://aws.amazon.com/blogs/training-and-certification/aws-certification-retirements-and-launches/
- TensorFlow 开发者认证关闭:https://www.tensorflow.org/certificate
- Rows 被收购与关停:https://rows.com/blog/post/rows-is-joining-superhuman
- SpreadJS 表格智能体:https://www.grapecity.com.cn/developer/spreadjs/ai-agent
- SpreadJS MCP 服务:https://mcp.grapecity.com.cn/
- SpreadJS AI Agent 开源仓库:https://gitee.com/GrapeCity/spreadjs-ai-agent
- SpreadJS 选型指南「性能与容量」(3.3.4 全部渲染性能数据及测试环境):https://www.grapecity.com.cn/developer/spreadjs/selection-guide/performance-and-capacity
- Univer 开源与 Pro 能力边界:https://github.com/dream-num/univer
《前端电子表格实战指南》系列完结 🎉