Univer SDK：可嵌入的开源文档引擎架构解析

1. 项目概述：Univer 是什么，它解决的不是“又一个在线文档”问题

Univer 这个名字乍一听容易让人联想到“universe”（宇宙），但实际它指向的是一套完全开源、可私有化部署、面向开发者深度集成的现代办公套件核心引擎。它不是某个大厂推出的 SaaS 服务，也不是一个给终端用户直接点击使用的网页应用——它本质上是一个 SDK（Software Development Kit），一套被设计成“嵌入式组件”的底层能力集合。我第一次在 GitHub 上看到 univer 仓库时，第一反应是：“这玩意儿居然没被做成闭源商业产品？”后来在几个金融和政务类客户的定制化项目里反复用它，才真正理解它的定位：它不卖界面，它卖的是‘文档能力’的原子化封装。

核心关键词里，“spreadsheets, documents, presentations”已经说得很清楚：它覆盖电子表格、文字处理、演示文稿三大核心办公场景；而“SDK”这个标签，则彻底划清了它和 WPS Online、腾讯文档、石墨文档这类成品服务的界限。你不会去“注册一个 univer 账号”，而是会把它像 React 组件一样 import 进你的内部系统——比如把一个带公式的财务报表编辑器，嵌进你们公司自研的 ERP 系统里；或者把一份带审阅批注的合同文档模块，无缝集成到法务部门的案件管理系统中。它解决的从来不是“怎么在线协作”，而是“如何让我的业务系统，原生具备专业级文档处理能力”。

我见过最典型的落地场景，是一家做智慧园区的客户。他们原有系统里所有设备巡检报告都是 PDF 填写后上传，流程僵硬、无法动态校验、历史版本难追溯。引入 univer 后，我们只用了 3 天时间，就把他们的巡检表单从静态 PDF 改造成可公式计算、条件高亮、多人协同批注的在线表格，并且所有数据仍走他们原有的权限体系和数据库。整个过程没有动他们主系统的任何一行 UI 代码，只是在需要展示表格的地方，加了一段 React 的 useUniverSheet hook 和几行配置。这才是 univer 的真实价值：它不试图替代你的系统，而是成为你系统里那个“突然会写公式、会画图表、会自动校验”的聪明模块。

对开发者来说，它意味着你可以绕过 Electron 打包、绕过 Office COM 接口兼容性噩梦、绕过 WebAssembly 渲染性能瓶颈，直接拿到一套经过千锤百炼、支持 Excel 兼容函数、支持复杂样式与分页、支持实时协同冲突检测的底层渲染与计算引擎。而对技术决策者来说，它意味着一次投入，就能获得长期可控的文档能力演进路径——不用再看某家云厂商的 API 文档更新节奏，也不用担心某次大版本升级导致你三年前写的插件全部失效。它不是一个“工具”，而是一块可以焊死在你技术栈里的、可靠的基础设施砖。

2. 核心架构拆解：为什么 Univer 不是“另一个 Monaco 编辑器”？

2.1 它的底层不是“渲染器”，而是“状态机 + 插件总线”

很多开发者第一眼看到 univer 的 demo，会下意识认为：“哦，又是基于 Canvas 或 SVG 渲染表格的前端库”。这种理解偏差非常危险，会直接导致后续集成走弯路。Univer 的核心抽象层根本不在视图层，而是在文档模型的状态管理与变更传播机制上。它的核心不是“怎么画格子”，而是“怎么定义一个单元格的值、样式、依赖关系、历史快照、协作状态”。

举个具体例子：当你在 univer 表格里输入=SUM(A1:A10)，这个公式不会立刻被解析执行。它首先被存为一个FormulaData对象，进入一个统一的WorkbookModel中；然后由FormulaEngine模块监听该对象变化，触发依赖图构建；接着CalculationService根据依赖图决定计算顺序；最后结果才推送到RenderController进行视觉更新。整个链条里，WorkbookModel是唯一可信数据源（Single Source of Truth），所有插件、UI 组件、协同服务都只能通过CommandService发送指令来修改它，而不能直接操作 DOM 或 Canvas。

这种设计带来的直接好处是：插件可以完全脱离 UI 存在。比如你可以写一个纯后台的AuditPlugin，它不渲染任何东西，只监听SetRangeValueCommand命令，当检测到某列输入了身份证号格式的数据时，自动调用你们公司的实名认证 API 进行核验，并将结果以Comment形式写回模型。这个插件在浏览器里运行，也可以在 Node.js 环境里作为服务端校验中间件运行——因为它的逻辑完全基于模型状态，而非 DOM 结构。

提示：不要试图用 jQuery 或原生 DOM 操作去“优化” univer 的单元格渲染。它的渲染层（RenderEngine）是高度定制化的，直接操作 DOM 会破坏其内部的 diff 算法和事件绑定，轻则样式错乱，重则导致协同状态不同步。所有交互必须走CommandService.executeCommand()。

2.2 插件体系不是“锦上添花”，而是“唯一入口”

Univer 的插件机制（Plugin System）不是传统意义上的“扩展市场”，而是一套强制性的、不可绕过的架构约束。它的整个应用启动流程是：加载 Core Plugin → 加载 Sheet Plugin → 加载 UI Plugin（如 Toolbar、Formula Bar）→ 加载 Custom Plugin。没有任何一个功能模块是“内置不可拆卸”的。连最基础的“复制粘贴”功能，都是由ClipboardPlugin实现的；连“撤销重做”历史栈，也是HistoryPlugin在维护。

这意味着什么？意味着你可以精准控制能力边界。比如在给某银行做风控系统集成时，我们禁用了全部网络协同插件（CollaborationPlugin），并重写了ClipboardPlugin，使其粘贴时自动过滤掉所有外部链接和图片，只保留纯文本和数值——这个改动只影响粘贴行为，不影响公式计算、样式渲染等任何其他功能。而在给某教育平台做课件编辑器时，我们则强化了ImagePlugin，增加了本地裁剪、滤镜预设、版权水印自动添加等能力，这些能力全部通过插件注入，不影响核心表格引擎的稳定性。

这种设计的代价是学习曲线稍陡：你必须理解Plugin、Command、Observer、Dependency四个核心概念才能开始写第一个插件。但回报是巨大的——所有功能都可测试、可替换、可灰度发布。我们团队内部有个不成文规定：任何新功能上线前，必须先写一个最小可行插件（MVP Plugin），验证其与核心模型的交互是否符合预期，然后再考虑 UI 层包装。这个习惯让我们避开了至少三次因 UI 层耦合导致的线上事故。

2.3 协同不是“加个 WebSocket”，而是“状态向量时钟 + OT 算法融合”

提到在线协同，很多人第一反应是“接个 Socket.IO 就完事”。Univer 的协同方案远比这复杂。它采用的是RGA（Replicated Growable Array）+ Lamport Clock 的混合算法，而不是简单的 Operational Transformation（OT）或 Conflict-free Replicated Data Type（CRDT）。原因很实际：Excel 兼容性。

Excel 的公式引用、跨表链接、命名区域等功能，天然存在强依赖关系。如果单纯用 CRDT，虽然能保证最终一致性，但在中间状态可能出现“引用不存在的单元格”这种非法状态，导致公式引擎崩溃。而纯 OT 在高并发编辑同一区域时，冲突解决逻辑极其复杂。Univer 的方案是：对结构变更（如插入行、删除列）用 RGA 保证顺序，对内容变更（如修改单元格值、设置样式）用带时间戳的 OT 进行合并。所有变更都被序列化为一个带向量时钟（Vector Clock）的Operation对象，由CollaborationService统一调度。

实操中这意味着：你不需要自己实现协同逻辑，但必须理解它的约束。比如，我们曾遇到一个需求——允许用户在协同编辑时“锁定某列禁止他人修改”。最初想用权限控制实现，结果发现这会破坏 RGA 的线性顺序保证。最终方案是：在SetRangeStyleCommand执行前，由自定义插件检查当前用户是否有该列的writeLock权限，如果没有，则拦截命令并抛出特定错误。这个锁信息本身也作为一个LockState对象，纳入协同状态同步范围。整个过程没有修改 univer 的协同内核，只是在命令流上加了一道策略门。

3. 开发者实操指南：从零开始集成一个可编辑表格

3.1 环境准备与依赖安装：避开那些“看似正常”的坑

Univer 的官方文档推荐使用@univerjs/core作为入口包，但实际项目中，我强烈建议你从@univerjs/start这个“开箱即用启动器”开始。原因很简单：它已经帮你处理了 Webpack 配置里最头疼的两件事——Worker 线程加载路径和Monaco Editor 的 AMD 模块兼容。

很多团队第一次集成失败，不是代码写错了，而是卡在Uncaught Error: Cannot find module 'monaco-editor'。这是因为 univer 内部的公式编辑器、代码高亮等功能重度依赖 Monaco，而 Monaco 默认打包方式与现代前端构建工具（Vite、Webpack 5+）存在模块解析冲突。@univerjs/start内置了monaco-editor-webpack-plugin的正确配置，并且将 Worker 文件自动注入到public/目录下，避免了手动配置new Worker(new URL('./worker.js', import.meta.url))这种易错写法。

安装步骤如下（以 Vite 项目为例）：

npm install @univerjs/start @univerjs/protocol @univerjs/sheets @univerjs/ui # 注意：不要单独安装 @univerjs/core，start 包已包含它

然后在main.ts中：

import { createUniver } from '@univerjs/start'; import { UniverSheetsPlugin } from '@univerjs/sheets'; import { UniverUIPlugin } from '@univerjs/ui'; // 创建 Univer 实例 const univerInstance = createUniver(); // 注册核心插件 univerInstance.registerPlugin(UniverSheetsPlugin); univerInstance.registerPlugin(UniverUIPlugin); // 启动（传入容器 DOM 元素） univerInstance.start(document.getElementById('univer-container')!);

注意：createUniver()返回的实例是全局单例，不要在多个组件里重复调用。如果你需要多个独立表格实例（比如一个页面里放两个不关联的表格），应该使用univerInstance.createUnitId()创建新工作簿 ID，而不是新建 univer 实例。

3.2 自定义插件开发：三步写出第一个“自动求和”按钮

假设你需要在工具栏里加一个“一键对选中区域求和”的按钮。这不是简单地调用SUM()函数，而是要实现：用户选中 A1:C5 区域 → 点击按钮 → 在 C6 单元格自动填入=SUM(A1:C5)并聚焦编辑。

第一步：定义命令（Command）

// commands/auto-sum.command.ts import { ICommand, ICommandService, IUniverInstanceService } from '@univerjs/core'; import { IAccessor } from '@univerjs/core'; import { SheetsSelectionsService } from '@univerjs/sheets'; export const AutoSumCommand: ICommand = { id: 'sheet.auto-sum', type: 'command', handler: async (accessor: IAccessor) => { const commandService = accessor.get(ICommandService); const univerInstanceService = accessor.get(IUniverInstanceService); const selectionService = accessor.get(SheetsSelectionsService); // 获取当前活动工作表和选区 const workbook = univerInstanceService.getCurrentUniverSheetInstance(); const worksheet = workbook?.getActiveSheet(); const selections = selectionService.getSelections(); if (!worksheet || selections.length === 0) return false; const range = selections[0].range; const sumFormula = `=SUM(${range.toA1()})`; // 执行设置值命令（注意：这是异步命令，需 await） await commandService.executeCommand('SetRangeValueCommand', { unitId: worksheet.getUnitId(), subUnitId: worksheet.getSheetId(), range: { startRow: range.endRow + 1, startColumn: range.endColumn, endRow: range.endRow + 1, endColumn: range.endColumn }, value: sumFormula, }); // 设置焦点到新单元格 await commandService.executeCommand('SetSelectionsCommand', { unitId: worksheet.getUnitId(), subUnitId: worksheet.getSheetId(), selections: [{ range: { startRow: range.endRow + 1, startColumn: range.endColumn, endRow: range.endRow + 1, endColumn: range.endColumn } }], }); return true; }, };

第二步：注册命令与快捷键

// plugins/auto-sum.plugin.ts import { Plugin, PluginType, IPluginContext } from '@univerjs/core'; import { AutoSumCommand } from '../commands/auto-sum.command'; import { IShortcutItem, ShortcutService } from '@univerjs/ui'; export class AutoSumPlugin extends Plugin { static override type = PluginType.Sheet; constructor(private readonly _config: any = {}) { super('auto-sum-plugin'); } override onStarting(context: IPluginContext): void { const commandService = context.accessor.get(CommandService); const shortcutService = context.accessor.get(ShortcutService); // 注册命令 commandService.registerCommand(AutoSumCommand); // 注册快捷键（Ctrl+Shift+S） shortcutService.registerShortcut({ id: 'auto-sum-shortcut', binding: 'ctrl-shift-s', description: 'Auto Sum Selected Range', preconditions: () => true, action: () => commandService.executeCommand('sheet.auto-sum'), }); } }

第三步：注入插件并添加 UI 按钮

// main.ts（续） import { AutoSumPlugin } from './plugins/auto-sum.plugin'; // ...前面的代码 univerInstance.registerPlugin(new AutoSumPlugin());

然后在你的 UI 组件里（比如一个自定义 Toolbar）：

<button onClick={() => univerInstance.getCommandService().executeCommand('sheet.auto-sum')}> Σ Auto Sum </button>

这个例子看似简单，但它展示了 univer 插件开发的核心范式：所有逻辑都围绕 Command 展开，UI 只是触发器，状态变更由命令驱动。这种模式让你的插件天然具备可测试性——你可以直接await commandService.executeCommand('sheet.auto-sum')来测试逻辑，而无需启动整个 UI。

3.3 样式与主题定制：不只是改个 CSS 变量

Univer 的主题系统（Theme System）是基于 CSS-in-JS 的@emotion/react实现的，但它不是简单的变量替换。它的主题对象包含三个层级：

• Base Theme：定义颜色语义（如primaryColor,errorColor）、字体族、间距比例；
• Component Theme：为每个 UI 组件（Toolbar、FormulaBar、ContextMenu）定义具体样式规则；
• Renderer Theme：直接影响 Canvas 渲染层的样式参数（如网格线粗细、选区虚线样式、滚动条宽度）。

最常被忽略的是 Renderer Theme。比如你想让表格的网格线变粗一点，很多人会去改.univer-sheets-grid-line的 CSS，结果发现没效果。正确做法是：

import { IThemeService } from '@univerjs/core'; import { SheetsRenderService } from '@univerjs/sheets'; const themeService = univerInstance.get(ThemeService); const renderService = univerInstance.get(SheetsRenderService); // 动态修改渲染主题 renderService.setRendererTheme({ gridLineWidth: 1.5, // 原来是 1 selectionBorderWidth: 2, // 选区边框加粗 scrollBarWidth: 8, // 滚动条变宽 });

更进一步，你可以创建完整的主题包：

// themes/bank-theme.ts export const BankTheme = { base: { primaryColor: '#0066cc', secondaryColor: '#3399ff', backgroundColor: '#f8f9fa', }, components: { toolbar: { backgroundColor: '#ffffff', buttonHoverBackground: '#e6f0ff', }, formulaBar: { inputBackgroundColor: '#ffffff', inputBorderColor: '#c0c0c0', }, }, renderer: { gridLineWidth: 1.2, headerHeight: 32, } }; // 应用主题 themeService.setTheme(BankTheme);

实操心得：主题切换不是“换肤”，而是“重新渲染”。每次调用setTheme()，univer 会触发整个渲染树的重绘。因此，不要在用户频繁操作时（比如拖拽调整列宽）动态切换主题。我们通常的做法是：在用户登录后，根据角色（如柜员、主管、审计）一次性加载对应主题，之后不再变更。

4. 生产环境部署与性能调优：那些文档里不会写的细节

4.1 私有化部署的资源加载优化：Worker 文件必须放在 public 下

Univer 的计算引擎（尤其是公式解析和大数据量渲染）大量使用 Web Worker 来避免阻塞主线程。默认情况下，Worker 文件由 univer 动态生成并 blob URL 加载，这在开发环境没问题，但在生产环境的 CDN 或 Nginx 部署中，会导致 Worker 加载失败（CORS 或 MIME 类型错误）。

解决方案是：显式指定 Worker 脚本路径，并确保它们作为静态资源部署。

在vite.config.ts中：

export default defineConfig({ build: { rollupOptions: { output: { assetFileNames: (assetInfo) => { if (assetInfo.name === 'univer-worker.js') { return 'assets/univer-worker.[hash].js'; } return 'assets/[name].[hash].[ext]'; }, }, }, }, });

然后在初始化时：

import { createUniver } from '@univerjs/start'; const univerInstance = createUniver({ workerUrl: '/assets/univer-worker.[hash].js', // 注意：这里必须是绝对路径 });

Nginx 配置示例：

location /assets/ { alias /var/www/myapp/dist/assets/; expires 1y; add_header Cache-Control "public, immutable"; }

这个细节看似微小，但我们在某省政务云部署时，就因为没配好 Worker 路径，导致打开大表格时 CPU 占用飙升到 100%，用户反馈“卡死”。排查了两天才发现是 Worker 加载失败后，所有计算逻辑退回到主线程执行。

4.2 大数据量表格的内存控制：别让 10 万行表格吃光用户内存

Univer 默认会对所有单元格创建CellData对象，即使它是空的。一个 1000x100 的表格，就有 10 万个对象实例。当用户打开一个 5000x50 的 Excel（25 万单元格）时，Chrome 内存占用轻松突破 1.5GB。

官方提供的virtualScroll选项只能解决渲染层的性能，无法减少模型层的内存占用。我们的实战方案是：启用稀疏矩阵（Sparse Matrix）存储 + 懒加载（Lazy Load）策略。

import { Workbook } from '@univerjs/core'; import { Sheets } from '@univerjs/sheets'; // 创建工作簿时启用稀疏存储 const workbook = new Workbook({ sparse: true, // 关键！启用稀疏存储 }); // 对于超大表格，禁用自动公式计算（改为手动触发） workbook.setConfig({ autoCalculation: false, }); // 提供手动计算入口 const calculateButton = document.getElementById('calc-btn'); calculateButton?.addEventListener('click', () => { workbook.calculate(); // 只在此刻触发全量计算 });

稀疏存储意味着：只有真正有值、有样式的单元格才会被实例化，其余单元格只是占位符。配合autoCalculation: false，可以将内存占用降低 60% 以上。我们曾用这个方案，让一个 10 万行 × 30 列的财务明细表，在 4GB 内存的 Chromebook 上流畅运行。

4.3 协同服务的连接保活：心跳不是可选，而是必须

Univer 的协同插件默认使用 WebSocket 连接，但它没有内置的心跳保活机制。在企业内网或某些代理环境下，TCP 连接可能在 30 秒无数据时被中间设备静默断开，导致协同状态“假死”——用户还在编辑，但其他人看不到他的光标，自己的修改也无法同步。

解决方案是：在 WebSocket 连接层之上，叠加一个应用层心跳。

// services/collaboration.service.ts class CollaborationService { private _ws: WebSocket | null = null; private _heartbeatTimer: NodeJS.Timeout | null = null; connect(url: string) { this._ws = new WebSocket(url); this._ws.onopen = () => { // 连接成功后，启动 25 秒心跳（比服务器超时阈值小 5 秒） this._startHeartbeat(); }; this._ws.onmessage = (event) => { const data = JSON.parse(event.data); if (data.type === 'heartbeat-ack') { // 心跳响应，重置计时器 this._resetHeartbeat(); } else { // 处理业务消息 this._handleMessage(data); } }; this._ws.onclose = () => { this._stopHeartbeat(); // 触发重连逻辑 this._reconnect(); }; } private _startHeartbeat() { this._heartbeatTimer = setInterval(() => { if (this._ws?.readyState === WebSocket.OPEN) { this._ws.send(JSON.stringify({ type: 'heartbeat' })); } }, 25000); } private _resetHeartbeat() { if (this._heartbeatTimer) { clearInterval(this._heartbeatTimer); this._startHeartbeat(); } } private _stopHeartbeat() { if (this._heartbeatTimer) { clearInterval(this._heartbeatTimer); this._heartbeatTimer = null; } } }

这个心跳逻辑必须由业务方自己实现，因为 univer 的CollaborationPlugin只负责协议解析，不关心传输层可靠性。我们把这个服务封装成一个独立的UniverCollabService，在初始化 univer 时注入：

univerInstance.registerPlugin(new UniverCollabService({ wsUrl: 'wss://your-collab-server.com/ws', }));

5. 常见问题与排查技巧实录：踩过的坑，比文档还管用

5.1 “The current configured Flutter SDK is not known to be fully supported” —— 这个报错和 univer 无关！

这是近期搜索热词里最误导人的一个。The current configured flutter sdk is not known to be fully supported是Android Studio 或 VS Code 的 Flutter 插件报出的警告，与 univer 完全无关。它出现在你本地开发环境里，是因为你同时装了 Flutter SDK 和 univer 项目，IDE 错误地将 univer 的pubspec.yaml（如果存在）或某些文件名相似的配置，识别为 Flutter 项目。

解决方案极其简单：

• 在 VS Code 中，打开命令面板（Ctrl+Shift+P），输入Dart: Clear Cached Analysis Results，执行；
• 或者，在项目根目录创建.vscode/settings.json，加入：

{ "dart.enabled": false, "flutter.sdk": "" }

实操心得：这个报错出现频率极高，几乎每个同时接触 Flutter 和 univer 的前端都会遇到。我们团队内部文档第一条就是：“看到这个报错，先关掉 Dart 插件，别折腾 univer 代码”。

5.2 “Spreadsheets are all you need” —— 这不是 slogan，而是架构宣言

这句话常被误解为“univer 只做表格”。实际上，它是 univer 团队对能力复用哲学的表达：电子表格的底层能力（二维网格、公式引擎、数据透视、条件格式、图表联动）是构建所有结构化文档的基础。@univerjs/documents（文字处理）和@univerjs/presentations（演示文稿）并非独立实现，而是共享同一套核心模型与渲染管线。

例如，@univerjs/documents里的“表格”功能，直接复用@univerjs/sheets的Worksheet类；@univerjs/presentations里的“数据图表”，底层渲染器就是@univerjs/sheets的ChartRenderer。这意味着：你为表格写的插件，90% 的代码可以无缝迁移到文档或幻灯片中——只要它们涉及的是“数据”而非“布局”。

我们曾为某出版社开发一个“学术论文协作平台”，要求支持 LaTeX 公式、参考文献管理和图表联动。最终方案是：用@univerjs/documents作为主编辑器，用@univerjs/sheets作为图表数据源，用自定义插件将cite{key}语法解析为对@univerjs/sheets中参考文献表的引用。整个系统没有引入任何第三方 LaTeX 渲染库，所有公式和图表都由 univer 原生渲染。

5.3 SDK 相关热词辨析：哪些真相关，哪些纯干扰

网络热词里混杂了大量无关 SDK，必须快速甄别：

真正相关的 SDK 只有：

• @univerjs/core：核心框架，所有插件的基础
• @univerjs/protocol：协同协议定义，用于自建协同服务
• @univerjs/sheets：电子表格能力包
• @univerjs/documents：文字处理能力包
• @univerjs/presentations：演示文稿能力包

注意：@univerjs/start不是 SDK，而是启动器；@univerjs/ui是 UI 组件库，非必需（你可以用 Ant Design 或自研 UI 替代）。

5.4 “_artifacts\winui_packages\sdk\build\native\microsoft.windowsappsdk.props” —— Windows 开发者的路径幻觉

这个长路径是Windows App SDK 的 MSBuild 属性文件，属于 WinUI/UWP 开发范畴。它出现在 univer 相关搜索中，纯粹是因为某些开发者在尝试用 Electron 打包 univer 时，错误地将 Windows App SDK 的构建配置混入了项目，导致构建失败。

正确做法是：univer 的桌面端打包，应使用 Electron 官方推荐的electron-builder或Tauri，完全不需要 Windows App SDK。Electron 本身就是跨平台的 Chromium 容器，univer 的 Web 版本可直接运行。

如果你坚持要用 WinUI（比如做 UWP 应用），那应该使用WebView2控件加载 univer 的 Web 页面，而不是试图把 univer 编译成原生 WinUI 组件——这违背了 univer 的设计初衷。

6. 未来演进与能力边界：univer 不会做什么，以及为什么

Univer 的 GitHub Star 数增长很快，但它的团队非常克制。从 v1.0 到 v2.0，他们没有增加“PDF 导出”、“Word 兼容模式”、“邮件合并”这些看似诱人的功能，而是花了半年时间重构了公式引擎的依赖图算法。这种克制，恰恰定义了它的能力边界。

它不会做：

• 离线 PWA 支持：univer 的设计哲学是“协同优先”，所有状态默认中心化。离线时，它会降级为只读模式，而不是试图在 IndexedDB 里模拟完整协同状态。这不是技术限制，而是选择——他们认为真正的离线协作，应该由服务端提供断线续传保障，而非前端兜底。
• WYSIWYG 所见即所得排版：@univerjs/documents的目标是“结构化文档”，而非“出版级排版”。它不支持首字下沉、复杂分栏、脚注尾注交叉引用。如果你需要 InDesign 级别的排版，univer 不是你的工具。
• AI 原生集成：目前没有内置 LLM 接口。你可以用插件调用 OpenAI API，但 univer 不会提供@univerjs/ai这样的官方包。理由很务实：AI 能力迭代太快，固化到核心框架里会迅速过时；而插件机制让你可以随时更换模型提供商。

它正在做：

• WebAssembly 加速：将公式计算、大数据排序等 CPU 密集型任务，逐步迁移到 WASM 模块，已在 v2.3 中实验性支持。
• 微前端沙箱化：让 univer 实例能在 single-spa 或 qiankun 微前端框架中安全运行，隔离全局样式和事件监听。
• 低代码配置平台：提供可视化插件配置器，让非开发者也能通过表单配置“自动填充”、“数据校验”、“审批流触发”等常见插件。

我个人在实际使用中的体会是：univer 最大的价值，不在于它现在能做什么，而在于它清晰地知道自己不能做什么，并为此构建了足够灵活的扩展机制。它不是一个“全能选手”，而是一个“精准手术刀”——当你需要在自己的系统里，嵌入一个可靠、可控、可演进的文档能力时，它几乎是你能找到的、最接近“基础设施”级别的选择。它不追求惊艳，但每一次升级，都让你的系统更稳一分。