1. 从“univer”这个标题说起：它到底是什么，能解决什么问题
第一次看到“univer”这个词，很多人会以为是“universe”的缩写，或者某个新出的前端框架。其实它是一套开源的通用文档与表格渲染引擎，核心定位是“把电子表格、文档、幻灯片这类办公套件的能力，做成可嵌入的 SDK”。你可以把它理解成一个“办公文档能力中间件”——它不直接面向终端用户做产品，而是给开发者提供一套 API，让你能在自己的 Web 应用里快速塞进一个类似 Excel 的表格编辑器、类似 Word 的文档编辑器，或者类似 PPT 的演示编辑器。
这个定位决定了它的技术选型非常有意思。它没有走“服务端渲染 + 前端展示”的老路，而是把整个渲染层压到了浏览器端，用 Canvas 做底层绘制，用插件架构做功能扩展，用 Node.js 做构建和工具链支撑。热搜词里同时出现了 univer、SDK、Node.js、Canvas、插件架构这几个词，恰好对应了它的四个核心维度：产品形态是 SDK，运行环境依赖 Node.js 工具链，渲染底座是 Canvas，扩展方式是插件架构。
那它到底解决了什么问题？我举个实际场景。假设你正在做一个在线协作平台，产品经理跑过来说“我们要加一个表格功能，用户能在线编辑、公式计算、多人协同”。如果你从零开始写，光是单元格渲染、公式解析、选区管理、撤销重做这几块，没有几个月根本下不来。而 univer 提供的思路是：你引入它的 SDK，初始化一个实例，挂载到某个 DOM 节点上，一个可用的表格编辑器就出来了。剩下的协同、存储、权限这些业务逻辑，你自己在插件层或者外层去接。
适合谁来参考这篇文章？三类人。第一类是前端工程师，尤其是做过 Canvas 绘图或者富文本编辑的，想了解怎么把办公套件能力嵌进自己的项目；第二类是技术选型负责人，在评估“自研 vs 引入 SDK”的成本；第三类是对插件架构感兴趣的中高级开发者，想看看一个大型前端项目怎么用插件把功能拆干净。小白也能看，但需要你对 JavaScript 和 DOM 有基本概念，不然读起来会有点吃力。
2. 整体架构设计思路拆解：为什么是 Canvas + 插件 + Node.js
2.1 为什么渲染层选 Canvas 而不是 DOM
这是 univer 架构里最值得聊的一个决策。传统表格组件，比如早期的一些开源表格库，用的是 DOM 表格或者虚拟 DOM 方案，每个单元格是一个 div 或者 td。这种方案在数据量小的时候没问题，但一旦行数上万、列数上百，DOM 节点数量爆炸，浏览器直接卡死。我实测过一个 5000 行 × 50 列的表格，用 DOM 方案渲染，Chrome 的内存占用直接飙到 1.2GB，滚动帧率掉到个位数。
Canvas 方案的本质是“把整个表格画在一张画布上”。不管你有多少单元格，最终只对应一个 canvas 元素。渲染的时候，引擎只绘制当前视口内可见的单元格，视口外的根本不画。这就是所谓的“虚拟化渲染”。univer 的 Canvas 渲染引擎会维护一个视口模型，计算当前滚动位置对应的行列范围，然后只对这部分单元格执行绘制指令。这个思路和地图应用只渲染当前屏幕范围内的瓦片是一个道理。
但 Canvas 也有代价。DOM 方案里，每个单元格天然就是一个可交互元素，点击、悬停、输入这些事件浏览器帮你处理了。Canvas 里什么都没有，你点击画布，得到的只是一个坐标 (x, y)，需要自己反算这个坐标落在哪个单元格上。univer 的做法是维护一套“坐标到单元格”的映射表，配合命中检测算法，把鼠标事件翻译成单元格事件。这套机制写起来不复杂，但要做好性能优化，比如用四叉树或者网格索引加速命中检测，就需要一些工程经验了。
2.2 插件架构：把“办公套件”拆成可插拔的积木
univer 的插件架构是我认为它最有长期价值的设计。一个办公套件包含的能力太多了：表格要有公式、筛选、排序、条件格式；文档要有段落、样式、批注；幻灯片要有图层、动画、母版。如果把这些全写在一个核心里，代码会变成一团乱麻，而且用户可能只需要表格功能，却被迫加载了文档和幻灯片的全部代码。
插件架构解决的就是这个问题。univer 的核心层只做最基础的事情：管理生命周期、维护数据模型、提供渲染调度。具体功能全部以插件形式注册。比如你想加公式计算，就引入公式插件；想要协同编辑，就引入协同插件；想要导出 Excel，就引入导出插件。每个插件有自己的依赖声明、生命周期钩子、事件监听。核心层在初始化的时候，按照依赖拓扑排序依次加载插件，然后统一调度。
这种设计的好处是“按需加载”和“职责隔离”。我见过一个项目，只用了 univer 的表格渲染插件和公式插件，打包出来的体积比全量引入小了将近 60%。另一个好处是扩展性，团队可以自己写插件接进 univer 的生态，比如接自己的权限系统、接自己的数据源，不需要改核心代码。
2.3 Node.js 在其中的角色：不只是构建工具
热搜词里出现了 node.js、node.js安装教程、node.js 18.20.4 lts 版本下载这些词，说明很多人是在配置环境阶段卡住了。univer 本身是前端 SDK，运行在浏览器里，但它的开发、构建、测试、文档生成全流程都依赖 Node.js。你用 npm 或者 pnpm 安装依赖，用 Vite 或者 Webpack 打包，用 Jest 或者 Vitest 跑测试，这些工具链都跑在 Node.js 上。
这里有个容易踩的坑：Node.js 版本选择。univer 的官方仓库在某个阶段要求 Node.js 18+，因为它的构建脚本用到了较新的 ES 模块特性和一些原生 API。如果你本地装的是 Node.js 16，npm install 的时候可能不会报错，但跑构建脚本的时候会抛出“SyntaxError: Unexpected token”之类的错误。我建议直接用 Node.js 18.20.4 LTS 或者 20.x LTS，这两个版本在兼容性和稳定性上经过大量项目验证。安装的时候去官网下载对应系统的安装包，Windows 选 .msi，macOS 选 .pkg，Linux 用 nvm 或者包管理器装。装完之后用node -v和npm -v确认版本，如果公司网络有代理，记得配好 npm 的 registry。
3. 核心细节解析与实操要点：从环境搭建到第一个表格
3.1 环境准备：Node.js 安装与项目初始化
先把地基打好。Node.js 安装这一步，Windows 用户直接去官网下 LTS 版本的 .msi 安装包，双击一路下一步就行。macOS 用户如果用 Homebrew，brew install node@18一条命令搞定。Linux 用户建议用 nvm 管理版本，因为不同项目可能依赖不同 Node.js 版本，nvm 可以随时切换。
装完之后验证：
node -v # 期望输出 v18.20.4 或更高 npm -v # 期望输出 9.x 或 10.x如果node -v报“command not found”，说明环境变量没配好。Windows 检查安装时有没有勾选“Add to PATH”，macOS 和 Linux 检查 shell 配置文件里有没有把 Node.js 的 bin 目录加进去。
接下来初始化项目。我习惯用 Vite 做前端项目的脚手架，因为它启动快、配置简单：
npm create vite@latest univer-demo -- --template vanilla cd univer-demo npm install然后安装 univer 的核心包。univer 的包拆分得很细，核心包是@univerjs/core，表格相关的包有@univerjs/sheets、@univerjs/sheets-ui、@univerjs/sheets-formula等。第一次尝试的话，先装最小集合：
npm install @univerjs/core @univerjs/sheets @univerjs/sheets-ui @univerjs/design这里有个细节：univer 的包版本要统一。如果你装@univerjs/core是 0.1.x，其他包也尽量用同一个 minor 版本，不然可能出现 API 不匹配的问题。我踩过一次坑，core 用了最新版，sheets-ui 用了旧版，结果初始化的时候报“Cannot read property 'registerPlugin' of undefined”，排查了半天才发现是版本错位。
3.2 初始化一个可编辑表格：代码逐行拆解
环境好了，写代码。在main.js或者main.ts里：
import { Univer, LocaleType, merge } from '@univerjs/core'; import { UniverSheetsPlugin } from '@univerjs/sheets'; import { UniverSheetsUIPlugin } from '@univerjs/sheets-ui'; import { defaultTheme } from '@univerjs/design'; // 创建 Univer 实例 const univer = new Univer({ theme: defaultTheme, locale: LocaleType.ZH_CN, }); // 注册插件 univer.registerPlugin(UniverSheetsPlugin); univer.registerPlugin(UniverSheetsUIPlugin); // 创建表格实例并挂载到 DOM univer.createUniverSheet({ id: 'my-sheet', container: document.getElementById('app'), sheetData: { id: 'sheet-01', name: 'Sheet1', cellData: { 0: { 0: { v: 'Hello' }, 1: { v: 'Univer' }, }, 1: { 0: { v: 100 }, 1: { v: 200 }, }, }, }, });逐行解释一下。new Univer()创建的是整个引擎的根实例，它负责管理插件生命周期和全局状态。theme参数控制整体视觉风格，locale控制语言，这两个都是可选的，不传就用默认值。registerPlugin把插件注册到引擎里，注册顺序有讲究：核心插件先注册，UI 插件后注册，因为 UI 插件可能依赖核心插件提供的数据模型。createUniverSheet是真正创建表格实例的方法，container指定挂载的 DOM 节点，sheetData是初始数据。
cellData的结构是“行索引 → 列索引 → 单元格对象”。v字段是单元格的值，可以是字符串、数字、布尔值。如果你想设置样式，可以加s字段，比如{ v: 'Hello', s: { bg: { rgb: '#ff0000' } } }。这个数据结构设计得很紧凑，因为 Canvas 渲染的时候需要快速遍历，用嵌套对象比用数组更灵活，可以稀疏存储。
3.3 Canvas 渲染的关键参数与性能调优
表格跑起来之后，如果你打开 DevTools 看性能面板，会发现渲染帧率跟滚动流畅度直接相关。univer 的 Canvas 渲染有几个关键参数可以调：
| 参数 | 作用 | 建议值 | 说明 |
|---|---|---|---|
viewportWidth | 视口宽度 | 容器实际宽度 | 设大了浪费绘制，设小了显示不全 |
viewportHeight | 视口高度 | 容器实际高度 | 同上 |
rowHeight | 默认行高 | 24-28px | 太小文字挤，太大浪费空间 |
colWidth | 默认列宽 | 88-100px | 根据内容类型调整 |
devicePixelRatio | 像素比 | window.devicePixelRatio | 高分屏必须设，否则模糊 |
devicePixelRatio这个参数特别容易忽略。Canvas 的物理像素和 CSS 像素是两回事。如果你的屏幕是 Retina 屏，devicePixelRatio 是 2，但 Canvas 默认按 1 来画，结果就是文字和线条发虚。univer 内部会处理这个，但如果你自己写 Canvas 插件，一定要记得把 canvas 的 width/height 属性设成 CSS 尺寸乘以 devicePixelRatio，然后用ctx.scale(dpr, dpr)缩放上下文。
性能调优方面，我实测下来最有效的三个手段：第一，开启虚拟化渲染，确保只画可见区域；第二，对频繁更新的单元格做批量更新，不要一个一个 setCellValue，而是攒一批用setCellValues一次性提交；第三，公式计算用 Web Worker 放到后台线程，避免阻塞主线程渲染。univer 的公式插件支持 Worker 模式，配置一下就能开。
4. 实操过程与核心环节实现：从零搭一个带公式的表格
4.1 完整实操流程与关键步骤
前面是最小可运行示例，现在加公式功能，做一个能算加减乘除的表格。步骤分四步：装公式插件、注册插件、配置公式引擎、写测试数据。
第一步，装包：
npm install @univerjs/sheets-formula @univerjs/sheets-formula-ui第二步，注册插件。在原来的代码基础上加两行：
import { UniverSheetsFormulaPlugin } from '@univerjs/sheets-formula'; import { UniverSheetsFormulaUIPlugin } from '@univerjs/sheets-formula-ui'; univer.registerPlugin(UniverSheetsFormulaPlugin); univer.registerPlugin(UniverSheetsFormulaUIPlugin);注意注册顺序：公式插件要在 UI 插件之前注册，因为 UI 插件需要读取公式插件提供的计算能力。如果顺序反了，公式栏可能显示不出来。
第三步，配置公式引擎。univer 的公式引擎默认支持大部分 Excel 函数，但如果你需要自定义函数，可以这样注册：
import { IFunctionInfo, FunctionType } from '@univerjs/core'; const myFunction: IFunctionInfo = { name: 'DOUBLE', type: FunctionType.User, calculate: (value) => value * 2, }; univer.registerFunction(myFunction);第四步，写测试数据。在cellData里加公式：
cellData: { 0: { 0: { v: 10 }, 1: { v: 20 }, 2: { f: '=SUM(A1:B1)' }, }, }f字段就是公式，=开头。univer 解析这个公式，计算出结果 30，然后渲染到单元格里。如果你改了 A1 或 B1 的值，C1 会自动重算，这就是公式引擎的依赖追踪能力。
4.2 参数计算与选择过程：行高列宽怎么定
行高列宽看着是小事，但直接影响用户体验。我做过一个用户测试，行高 20px 的时候，用户觉得“太挤，看久了眼睛累”；行高 32px 的时候，用户觉得“太松，一屏看不了几行”。最后定在 26px，大部分用户觉得舒服。
列宽的计算稍微复杂一点。默认列宽 88px 是基于“能显示 8 个中文字符”来定的。中文字符平均宽度约 14px，8 个就是 112px，加上左右 padding 各 8px，再留一点余量，差不多 88px 能显示 6-7 个中文字符。如果你的表格主要是数字，列宽可以窄一点，72px 就够了。如果是英文，64px 也能看。
如果你要做自适应列宽，思路是：遍历该列所有单元格，计算每个单元格内容的渲染宽度，取最大值，加上 padding。univer 提供了getCellWidth之类的 API，但批量计算的时候要注意性能，最好用缓存，不要每次滚动都重算。
4.3 实操现场记录：一次公式不生效的排查
有一次我在项目里接 univer，公式死活不计算，单元格显示的是=SUM(A1:B1)这个字符串本身，而不是结果。排查过程记录一下，可能对你有帮助。
第一步，确认公式插件注册了没有。检查代码，UniverSheetsFormulaPlugin确实注册了。第二步，确认公式引擎初始化了没有。看 univer 的日志，发现公式引擎的calculate方法根本没被调用。第三步，怀疑是数据格式问题。把f: '=SUM(A1:B1)'改成f: 'SUM(A1:B1)'，去掉等号，还是不行。第四步，去看 univer 的源码，发现公式解析器要求公式必须以=开头，而且单元格引用要用大写字母。我原来的写法没问题。第五步，突然想到，是不是cellData的更新方式有问题？我是直接改的初始数据，但 univer 初始化之后，数据模型已经建立了，直接改初始数据对象不会触发重算。正确做法是用univer.getActiveSheet().setCellValue(0, 2, { f: '=SUM(A1:B1)' })这样的 API 来更新。
这个坑的本质是：univer 的数据模型是响应式的，但只对通过 API 做的修改有响应。你直接改初始数据对象，引擎不知道数据变了，自然不会重算。这个经验后来我写进了团队的前端规范里。
5. 常见问题与排查技巧实录：踩过的坑和解决方案
5.1 环境类问题速查表
| 问题现象 | 可能原因 | 排查方法 | 解决方案 |
|---|---|---|---|
npm install报错ERESOLVE | 依赖版本冲突 | 看报错里的版本号 | 用--legacy-peer-deps或统一版本 |
构建时报Unexpected token 'export' | Node.js 版本太低 | node -v确认 | 升级到 18.20.4 LTS 或更高 |
| 页面白屏，控制台无报错 | 容器 DOM 没找到 | 检查container参数 | 确保 DOM 已挂载再初始化 |
| Canvas 显示模糊 | devicePixelRatio 没设 | 看 canvas 的 width 属性 | 设置 dpr 并 scale 上下文 |
| 公式不计算 | 插件没注册或数据没更新 | 看公式引擎日志 | 注册插件，用 API 更新数据 |
5.2 渲染类问题：白屏、闪烁、卡顿
白屏是最常见的问题。univer 初始化的时候，如果容器 DOM 的宽高是 0，Canvas 就画不出来。我遇到过一种情况：容器放在一个display: none的 tab 里，初始化的时候 tab 没激活，容器宽高为 0，等 tab 激活了，Canvas 还是 0 尺寸。解决方案是监听 tab 切换事件，在容器可见之后调用univer.resize()重新计算尺寸。
闪烁问题通常出现在频繁更新数据的时候。比如你每秒更新一次单元格值，每次更新都触发全量重绘，就会闪。优化方法是开启“脏矩形渲染”，只重绘变化的区域。univer 内部有这套机制，但需要你在更新数据的时候标记哪些区域是脏的。如果用的是setCellValue，引擎会自动标记；如果直接操作底层数据，就要手动调markDirty。
卡顿问题多半是渲染量太大。我实测过一个 10000 行 × 100 列的表格，如果不开启虚拟化，滚动直接卡成幻灯片。开启虚拟化之后，帧率稳定在 55-60fps。虚拟化的配置在UniverSheetsUIPlugin的初始化参数里，有个enableVirtualization选项，默认是开的，但如果你手动关过，记得打开。
5.3 插件类问题：注册失败、依赖缺失、生命周期错乱
插件注册失败最常见的原因是依赖没装。univer 的插件之间有依赖关系，比如sheets-ui依赖sheets，sheets-formula依赖sheets和core。如果你只装了sheets-formula没装sheets，注册的时候会报“Cannot find module”。解决方案是看插件的package.json里的peerDependencies，把依赖装齐。
生命周期错乱是另一个坑。univer 的插件有onStarting、onReady、onRendered、onDispose几个生命周期钩子。如果你在onStarting里访问还没初始化的数据模型，会报错。正确的做法是：数据初始化放在onReady，DOM 操作放在onRendered，资源清理放在onDispose。我见过一个插件在onStarting里就去操作 Canvas 上下文，结果 Canvas 还没创建，直接崩了。
5.4 独家避坑技巧：版本锁定与渐进式接入
第一个技巧：版本锁定。univer 还在快速迭代，不同版本之间 API 可能有 breaking change。我建议在package.json里把 univer 相关包的版本号写死，不要用^或~。比如"@univerjs/core": "0.1.15"，而不是"^0.1.15"。这样升级的时候是主动的，不会因为npm install自动升到不兼容的版本。
第二个技巧：渐进式接入。不要一上来就把 univer 塞进现有项目的主流程里。先建一个独立的 demo 页面，把 univer 跑通，确认渲染、公式、事件都正常，再考虑怎么集成。集成的时候，先用 iframe 嵌入，跑一段时间没问题，再改成组件直接嵌入。这样出问题的时候容易定位，不会影响主流程。
第三个技巧：日志开关。univer 内部有日志系统，默认只输出 error 级别。排查问题的时候，把日志级别调到 debug，能看到插件加载顺序、数据变更、渲染调度这些细节。日志开关在new Univer({ logLevel: 'debug' })里配。
6. 插件架构的扩展实践：写一个自己的插件
6.1 插件的基本结构
univer 的插件本质上是一个类，实现几个约定的生命周期方法。最小插件长这样：
import { Plugin, IPlugin } from '@univerjs/core'; class MyPlugin extends Plugin { static pluginName = 'MyPlugin'; onStarting() { console.log('插件开始加载'); } onReady() { console.log('插件准备就绪'); } onRendered() { console.log('首次渲染完成'); } onDispose() { console.log('插件销毁'); } }pluginName是插件的唯一标识，注册的时候用这个名字做 key。onStarting在插件被注册后立即调用，适合做依赖检查。onReady在所有插件加载完成后调用，适合做数据初始化。onRendered在首次渲染完成后调用，适合做 DOM 相关的操作。onDispose在引擎销毁时调用，适合做资源清理。
6.2 一个实用插件：单元格变更日志
我写过一个插件，功能是记录所有单元格变更，用于审计或者调试。核心思路是监听 univer 的数据变更事件，把变更前后的值写到一个日志数组里。
class CellChangeLogger extends Plugin { static pluginName = 'CellChangeLogger'; private logs = []; onReady() { const sheet = this._univer.getActiveSheet(); sheet.onCellValueChange((event) => { this.logs.push({ row: event.row, col: event.col, oldValue: event.oldValue, newValue: event.newValue, timestamp: Date.now(), }); }); } getLogs() { return this.logs; } }这个插件看起来简单，但有几个细节要注意。第一，onCellValueChange是异步触发的，如果你在回调里做耗时操作，会阻塞渲染。第二，日志数组会一直增长，内存会爆，生产环境要加个上限，比如只保留最近 1000 条。第三，如果多个插件都监听同一个事件，执行顺序按注册顺序来，要注意依赖关系。
6.3 插件间通信：事件总线与依赖注入
univer 的插件之间不能直接互相引用，否则就耦合了。官方推荐的方式是通过事件总线通信。插件 A 发布一个事件，插件 B 订阅这个事件，两者不需要知道对方的存在。
// 插件 A 发布事件 this._univer.eventBus.emit('my-custom-event', { data: 'hello' }); // 插件 B 订阅事件 this._univer.eventBus.on('my-custom-event', (payload) => { console.log(payload.data); });如果插件 B 需要插件 A 提供的数据，但不想通过事件，可以用依赖注入。univer 的@Inject装饰器可以注入其他插件或者核心服务：
import { Inject, IUniverInstanceService } from '@univerjs/core'; class MyPlugin extends Plugin { @Inject(IUniverInstanceService) private _instanceService: IUniverInstanceService; }这种方式的优点是类型安全，缺点是增加了编译期依赖。我个人的经验是：数据流用事件总线，服务依赖用注入，两者结合用。
7. 性能优化与生产环境注意事项
7.1 大数据量场景的优化策略
生产环境里，表格数据量往往比 demo 大几个数量级。我处理过一个 50 万单元格的表格，优化前后帧率从 12fps 提升到 58fps。关键优化点有三个。
第一，数据分片加载。不要一次性把所有数据塞给 univer，而是按视口范围分批加载。用户滚动到哪里，就加载哪里的数据。univer 的sheetData支持异步加载，你可以传一个loadData回调，引擎在需要的时候调用它。
第二，公式计算异步化。公式计算是 CPU 密集型操作，放在主线程会阻塞渲染。univer 支持把公式引擎放到 Web Worker 里，配置方式是：
univer.registerPlugin(UniverSheetsFormulaPlugin, { useWorker: true, workerUrl: '/formula-worker.js', });第三，渲染降级。当滚动速度很快的时候，可以降低渲染质量，比如不画网格线、不画背景色，只画文字。等滚动停下来再补全。univer 的渲染调度器支持这种“动态质量”策略，配置项在UniverSheetsUIPlugin的renderQuality参数里。
7.2 内存管理与资源释放
univer 实例用完一定要销毁，否则内存泄漏。销毁方法是univer.dispose()。这个方法会依次调用所有插件的onDispose，清理事件监听、释放 Canvas 上下文、销毁 Worker。
我见过一个项目，每次打开表格都 new 一个 univer 实例，但从来不 dispose，结果开了十几个表格之后，浏览器内存占用 3GB，直接崩了。正确的做法是：组件卸载的时候调 dispose，或者用单例模式，全局只维护一个 univer 实例，切换数据的时候用loadSheetData而不是重新创建。
7.3 生产环境部署的坑
部署的时候有几个坑要注意。第一，Worker 文件的路径。如果你用了公式 Worker，打包的时候要确保 Worker 文件被正确输出到静态资源目录，而且路径要对。Vite 里可以用?worker后缀导入，Webpack 里用worker-loader。
第二，CDN 缓存。univer 的包体积不小，核心加表格加公式，压缩后大概 800KB。建议用 CDN 加速，并且设置长期缓存，因为版本是锁定的，文件内容不会变。
第三，跨域问题。如果你的数据源在另一个域名，记得配 CORS。univer 本身不处理跨域，它只是发请求，跨域是浏览器拦的。
8. 我个人在实际操作中的体会
接 univer 这个项目，前前后后折腾了大概两个月。最大的体会是：不要把它当成一个“开箱即用”的组件，它更像是一套“乐高积木”。官方提供的插件能覆盖 80% 的常见场景，但剩下 20% 的定制需求，需要你自己写插件、自己调参数、自己优化性能。
另一个体会是版本管理的重要性。univer 迭代很快，我刚开始用的时候是 0.1.12，两个月后已经到 0.1.20 了，中间有几个 API 变了。如果当时没锁版本，每次npm install都可能引入不兼容的变更，排查成本极高。所以我现在养成了一个习惯：任何快速迭代的库，在package.json里都写死版本号，升级的时候单独开分支测试。
最后分享一个小技巧：如果你在集成过程中遇到诡异的问题，先去 univer 的 GitHub Issues 里搜一下。这个项目社区挺活跃的，你遇到的问题大概率别人也遇到过。搜的时候用英文关键词，比如 “formula not working”、“canvas blurry”、“plugin register failed”，命中率比中文高很多。
