简介面向Web前端开发者、在线教育与个人学习场景这份JavaScript公式编辑器示例展示了如何在网页中实现数学公式的创建、编辑与可视化基于HTML5和原生JavaScript涵盖公式解析、LaTeX/MathML渲染、函数图像绘制以及所见即所得交互等核心逻辑适合需要快速理解交互式公式编辑原理或改造成业务模块的读者。压缩包共2个文件包含1个HTML页面与1个JavaScript文件大小仅9KB结构精简可直接打开运行或嵌入现有项目。已有1311人学习浏览可作为课程设计参考或基础模板。通过源码可掌握事件监听、Canvas绘图、公式输入实时反馈和跨浏览器兼容等关键点同时涉及性能优化、模块化组织与测试调试思路便于逐行阅读和二次扩展为开发轻量数学输入功能提供了清晰起点。1. JavaScript公式编辑器低代码报表里最容易被低估的硬骨头每个做低代码或报表平台的前端团队迟早都会接到同一个需求让用户在页面上直接写公式。表面看不过是给一个输入框加上函数提示理顺之后背后连着词法解析、语法树、实时求值和编辑器交互一整条链路。JavaScript公式编辑器做得好不好直接决定业务方敢不敢把计算逻辑从开发手里交到运营手里。这篇文章按浏览器里的公式编辑组件来写目标是让用户输入类似SUM(销售额) * 0.2 IF(利润率 0.1, 提成, 保底)这样的表达式系统能实时解析、校验、求值。适合正在做低代码、报表或数据可视化的前端开发者也适合需要做技术选型评估的负责人。先给结论公式编辑器的工程重心不在AST算法本身而在分层边界与交互稳定性。下面按选型、输入层、解析与求值、避坑、进阶的顺序展开。2. 公式编辑器选型三条路线的成本、边界与架构分层2.1 三条路线的边界与真实成本打开搜索引擎能看到很多用某个表达式解析库三行搞定公式计算的文章但真实项目里公式编辑器从来不是一个parse函数就能收尾的。选型时摆在前面的基本是三条路纯自研解析器、直接用开源表达式解析库、以及开源解析库做地基、自研UI与适配层的混合方案。三条路的成本结构和风险点完全不同。路线适合场景主要成本典型风险纯自研公式语法高度定制业务语义强解析器、测试、文档人月级语法设计失控边界case测不完开源解析库标准四则运算加少量函数接入快文档依赖社区扩展受限自定义语法难落地混合方案多数真实项目中等集中在适配层需要持续维护升级适配我一般建议走混合方案。理由很直接公式编辑器的核心价值不在AST构造算法本身而在交互体验和业务语义的贴合度。成熟的表达式解析库经过多年迭代对运算符优先级、括号嵌套、错误定位这些基础问题的处理远比临时自研稳定。而UI层的高亮、补全、参数提示、错误展示恰恰是开源方案少有着力的地方也是最需要贴合自身业务的部分自研收益最高。纯自研适合的场景是公式语法里有业务专属结构比如带维度字段的指标表达式或者公式需要直接翻译成查询语句。这种情况下开源解析库的语法约束反而碍手碍脚。但纯自研的前提是团队里至少有一个人对词法、语法分析有过实操经验否则进度很容易卡在运算符优先级和嵌套处理这类经典问题上。2.2 混合方案的三层架构与最小接口不管走哪条路组件内部建议固定拆三层。输入层负责捕获键盘和光标行为对外输出公式字符串和编辑状态解析层负责把字符串变成Token流和AST输出校验结果与错误定位求值层负责把AST结合上下文变量算出最终值输出计算结果或结构化错误。三层之间用接口隔离替换任何一层都不影响另外两层。interface FormulaEditor { mount(container: HTMLElement): void; getFormula(): string; setFormula(value: string): void; validate(): { ok: boolean; errors: FormulaError[] }; evaluate(context: Recordstring, unknown): { ok: boolean; value?: unknown; error?: string }; onStateChange(cb: (state: EditorState) void): void; }validate和evaluate都返回带ok标志的结果对象而不是直接抛异常。原因很简单UI层拿到ok为false时需要能同时展示多个错误并定位到具体字符位置而不是被第一个异常打断。公式编辑器和普通计算函数不同用户一次性输入错好几处是常态一次只报一个错会让人反复试错。还有个容易被忽略的原则公式本体始终存字符串。高亮、补全、校验、求值都把这个字符串当输入做投影互相之间不持有内部状态。后面做撤销重做、历史记录、甚至多人协同编辑时字符串是唯一数据源这个原则能省掉大量状态同步的返工。2.3 依赖选型的三个判定标准对地基级别的依赖我判断能不能用的标准有三条输入输出是否纯函数、错误信息是否结构化、是否支持自定义函数注册。纯函数意味着同一条公式、同一个上下文任何时候求值结果一致不会因内部缓存或全局状态产生玄学差异。结构化错误意味着能拿到出错位置和错误类型而不是一句笼统的表达式无效。自定义函数注册是公式编辑器业务化的关键能力。注册机制至少包含四要素函数名、参数个数约束、参数类型校验、实际执行函数。以一个文本截取函数为例registerFunction(LEFT, { arity: [1, 2], checkArgs: (args) args.every(a typeof a string || typeof a number), fn: (text, len) String(text).slice(0, len ?? 1), });arity用数组表达最少1个、最多2个参数checkArgs在求值前做一次类型白名单校验fn是纯函数只依赖入参。这套机制是公式编辑器安全性的基础也是和把公式字符串直接当代码执行划清界限的分界点。选型时如果某个库不支持这种注册模式基本可以排除。3. 公式输入层的核心实现高亮、补全与参数提示3.1 三种可编辑区域方案的本质差异公式输入区常见有三种做法textarea加覆盖层、contenteditable、以及成熟编辑器内核定制。textarea加覆盖层最容易掌控底层textarea接收键盘输入并维护光标覆盖层div负责渲染高亮两者通过透明文字和滚动同步叠在一起。contenteditable的高亮渲染最直接但光标在带嵌套标签的HTML里非常容易偏移尤其在中文输入法和浏览器撤销行为下状态维护成本极高。编辑器内核定制体验最好但引入体积和学习成本都不低。我自己的实操经验是项目早期用textarea加覆盖层把交互原型快速跑通同时验证语法设计和错误展示方案等语法稳定、反馈收敛后再评估要不要迁移到编辑器内核。这个顺序的关键收益是语法层和交互层的风险被分开了。语法没定的时候最怕被编辑器实现绑住手脚语法一旦稳定迁移只是换输入层解析层和求值层完全不用动。3.2 覆盖层高亮的最小实现与两个必做细节textarea加覆盖层的高亮核心逻辑可以浓缩成几十行function renderHighlight(formula, tokens) { let html ; let lastIndex 0; for (const token of tokens) { // 先输出token之前的普通文本避免样式串位 html escapeHtml(formula.slice(lastIndex, token.start)); // token本身按类型包上CSS类 html span classtoken-${token.type}${escapeHtml(token.value)}/span; lastIndex token.end; } // 兜底输出剩余文本 html escapeHtml(formula.slice(lastIndex)); return html; } function escapeHtml(raw) { return raw .replace(//g, amp;) .replace(//g, lt;) .replace(//g, gt;); }renderHighlight的逻辑是先用tokenizer把公式切成Token序列每个Token带start和end偏移量。然后从公式字符串里按位置切片Token之前的片段通常是空白或标点直接转义Token本身按类型包上token-number、token-identifier、token-function这类CSS类。最后把拼接的HTML写入textarea上方的覆盖层div里。这里有两个细节必须落实。第一escapeHtml不能省用户输入小于号或大于号如果不转义覆盖层DOM会被打穿。第二textarea的文本颜色要设成透明同时caret-color保留可见让用户看到的高亮来自覆盖层但光标仍是真实光标。滚动同步也别忘了textarea触发scroll时把覆盖层的scrollTop和scrollLeft设成相同值否则输入超过一屏后高亮和原文就会错位这是覆盖层方案最经典的玄学bug。提示覆盖层高亮方案只适合公式这种短文本场景。当公式长度超过几百个字符后每次输入都全量重设innerHTML会有明显卡顿届时就该考虑带增量渲染的编辑器内核了。3.3 函数补全与参数提示的触发状态机自动补全的触发逻辑建议用一个状态机管理。基本规则是光标前存在合法标识符前缀时弹出候选列表光标移出标识符字符集时关闭。过滤要基于当前光标前的完整标识符做前缀匹配而不是从头匹配整个公式字符串。比如用户输入到s时候选列表应该展示所有以s开头的函数名和字段名用户继续输入su时列表再收敛一次。参数提示相对复杂。用户在左括号后面输入时需要展示当前函数签名的参数说明但公式里常见多层嵌套调用比如ROUND(SUM(A1:A3), 2)。光标在中间逗号后面时提示应展示ROUND的第二参数而不是SUM的。实现方式是通过解析器拿到AST后按光标偏移量反查当前所在的最内层函数调用节点function findActiveCall(node, cursorOffset) { if (!node || typeof node ! object) return null; // 当前节点是函数调用且光标落在它的区间内 if (node.type CallExpr) { const start node.start ?? 0; const end node.end ?? Infinity; if (cursorOffset start cursorOffset end) { let argIndex 0; // 按参数的end位置判断光标落在第几个参数内部 for (const arg of node.args) { if (cursorOffset arg.end) argIndex; else break; } return { fnName: node.fnName, argIndex }; } } // 递归检查所有子节点找到最内层命中 for (const key of Object.keys(node)) { const child node[key]; if (Array.isArray(child)) { for (const item of child) { const found findActiveCall(item, cursorOffset); if (found) return found; } } else if (child typeof child object) { const found findActiveCall(child, cursorOffset); if (found) return found; } } return null; }argIndex的计算不要用字符串搜索数逗号因为字符串字面量里的逗号、嵌套函数的逗号都会干扰计数。正确做法是遍历当前CallExpr节点的args数组按每个参数的起止位置判断光标落在第几个参数内部。参数节点的start和end来自解析阶段的目标位置信息这样算出来的参数序号是确定性的。4. 公式的词法解析与求值从字符串到AST再到计算结果4.1 词法分析支持中文标识符的Token化词法分析的任务是把公式字符串切成Token流。典型的报表公式Token类型包括数字、字符串字面量、标识符函数名和字段名、运算符、括号、逗号。基础实现如下function tokenize(input) { const tokens []; let i 0; while (i input.length) { const ch input[i]; // 跳过空白字符 if (/\s/.test(ch)) { i; continue; } // 数字宽松匹配允许小数点格式校验放到语法阶段 if (/[0-9.]/.test(ch)) { let j i; while (j input.length /[0-9.]/.test(input[j])) j; tokens.push({ type: number, value: input.slice(i, j), start: i, end: j }); i j; continue; } // 标识符字母、下划线、中文字符开头 if (/[a-zA-Z_\u4e00-\u9fa5]/.test(ch)) { let j i; while (j input.length /[a-zA-Z0-9_\u4e00-\u9fa5]/.test(input[j])) j; tokens.push({ type: identifier, value: input.slice(i, j), start: i, end: j }); i j; continue; } // 运算符、括号、逗号 if (-*/%^(),.includes(ch)) { tokens.push({ type: operator, value: ch, start: i, end: i 1 }); i; continue; } throw new SyntaxError(无法识别的字符: ${ch}位置 ${i}); } return tokens; }注意正则里用\u4e00-\u9fa5把中文字符纳入标识符扫描。报表系统里字段名经常是销售额毛利率这样的中文词法阶段如果把中文排除后面解析和求值再想支持就非常被动。数字扫描这里刻意用宽松的[0-9.]匹配也就是说1.2.3也会被切成一个数字Token真正的数字格式校验放语法阶段做这样错误定位信息能精确到是哪个数字出问题。每个Token都携带start和end偏移量这是为三个阶段服务的高亮渲染要用偏移量做字符串切片错误定位要告诉用户第7个字符附近出错调试阶段也要用位置信息追溯。Token不带位置信息后面三块全得返工。4.2 递归下降解析器运算符优先级与嵌套处理解析阶段用递归下降法把运算符优先级拆成独立的解析函数。优先级从低到高逻辑或、逻辑与、比较、加减、乘除、一元负号、括号与函数调用。每一级一个函数函数内循环消费自己这一级的运算符更细粒度的表达式委托给下一级函数function parseComparison() { let left parseAdditive(); const operators [, !, , , , ]; while (matchAnyOperator(operators)) { const op previous().value; const right parseAdditive(); left { type: BinaryExpr, op, left, right }; } return left; } function parseAdditive() { let left parseMultiplicative(); while (matchAnyOperator([, -])) { const op previous().value; const right parseMultiplicative(); left { type: BinaryExpr, op, left, right }; } return left; }parseMultiplicative结构与parseAdditive一致只是运算符换成*、/、%。parsePrimary处理数字字面量、括号表达式、一元负号最后兜底交给parseCallOrField。函数调用分支放在最高优先级层因为函数参数里可以出现任意低优先级的表达式function parseCallOrField() { const token expectToken(identifier); if (matchOperator(()) { const args []; if (!checkOperator())) { do { args.push(parseExpression()); } while (matchOperator(,)); } expectOperator()); return { type: CallExpr, fnName: token.value, args, start: token.start, end: tokens[i - 1].end }; } return { type: IdentifierExpr, name: token.value, start: token.start, end: token.end }; }matchAnyOperator接收运算符数组逐个尝试匹配命中则消费并返回true。expectToken和expectOperator在预期类型不满足时抛出带位置的语法错误。递归下降的关键在于每一层只处理自己的优先级不越级消费。parseComparison遇到加号不会自己处理而是留给parseAdditive这样1 2 * 3必然解析成1 (2 * 3)。AST节点上要带上token的位置信息这样校验和求值报错时能说第5到第8个字符之间括号不匹配而不是笼统的公式有误。这种精确度直接决定用户在输入公式时是觉得系统聪明还是觉得系统在刁难人。4.3 求值器、函数注册表与错误翻译求值器是AST的递归遍历对每种节点类型执行对应操作。核心设计是把函数注册表独立出来求值器不硬编码任何业务函数const registry new Map(); function registerFunction(name, { arity, checkArgs, fn }) { registry.set(name.toUpperCase(), { arity, checkArgs, fn }); } function evaluate(node, context) { switch (node.type) { case NumberExpr: return node.value; case IdentifierExpr: { if (Object.prototype.hasOwnProperty.call(context, node.name)) { return context[node.name]; } throw new ReferenceError(字段不存在: ${node.name}); } case CallExpr: { const entry registry.get(node.fnName.toUpperCase()); if (!entry) throw new ReferenceError(未知函数: ${node.fnName}); const args node.args.map(a evaluate(a, context)); if (entry.arity !entry.arity.includes(args.length)) { throw new TypeError(函数 ${node.fnName} 参数个数不符); } if (entry.checkArgs !entry.checkArgs(args)) { throw new TypeError(函数 ${node.fnName} 参数类型不正确); } return entry.fn(...args); } case BinaryExpr: return applyBinary(node.op, evaluate(node.left, context), evaluate(node.right, context)); default: throw new Error(未知节点类型: ${node.type}); } }几个实现细节。函数名注册和查找统一走toUpperCase用户输入sum和SUM都能命中这个宽容度在报表场景里能少挨很多骂。参数校验用白名单思想checkArgs返回false直接抛TypeError不给函数体执行机会。这样接入用户自定义函数时安全边界是显式的。字段引用通过Object.prototype.hasOwnProperty判断避免原型链上的污染属性被当成业务字段。求值入口统一包一层错误翻译function safeEvaluate(ast, context) { try { const value evaluate(ast, context); return { ok: true, value }; } catch (err) { let message err.message; if (err instanceof ReferenceError) message 引用了不存在的名称: ${extractName(err.message)}; if (err instanceof TypeError) message 参数错误: ${extractName(err.message)}; return { ok: false, error: message }; } }错误翻译的价值在于把内部异常语言转成业务用户能理解的话。UI层拿到的永远是对齐的{ ok, value?, error? }结构不需要解析错误字符串。如果项目里同时存在公式编辑器和独立的公式计算服务端这个结构可以直接复用前后端各维护一套翻译规则即可。5. 公式编辑器避坑指南五个高频翻车现场与解法公式编辑器的坑大多不在解析算法本身而在交互边界和工程集成。下面五个问题是真实项目里出现频率最高的每一条都有血泪经验在里面。5.1 中文输入法组合态把公式打碎现象用户用拼音输入法输入中文字段名时拼音字母被当成公式内容实时解析高亮也按拼音字母上色。候选词一旦没选直接回车公式里残留一段拼音碎片解析直接报错。原因textarea的input事件在中文输入法组合过程中就会触发。组合输入指从按下第一个拼音字母到选词上屏之间的整个区间这期间textarea的值是拼音字母不是最终文本。如果input事件每次都触发tokenize和重渲染就会把组合中的拼音当正式内容处理。解决在compositionstart时置位一个isComposing标志compositionend时清除。input回调里判断标志位组合期间跳过解析和高亮更新组合结束后手动触发一次完整更新。同时高亮渲染保持无副作用不在组合状态里改写公式字符串。这个坑在中文业务系统里几乎必现不处理输入法事件基本等于上线即翻车。5.2 循环引用把页面卡死现象A字段的公式引用BB的公式引用A保存后页面直接卡住控制台报栈溢出或者CPU拉满只能强制刷新。原因求值器递归遍历AST遇到A求B、B又求A在字段引用层形成无限递归。解析层发现不了这个问题因为每个公式单独看都是语法合法的。循环依赖是跨公式的关系问题发生在依赖图层面不在语法层面。解决求值前先做一次依赖图拓扑排序。为每个公式维护它引用了哪些字段的依赖集合然后用拓扑排序检测环发现环直接返回循环依赖错误并把环里的字段名列表展示给用户。求值器内部再加一个最大递归深度兜底默认100层防止漏网之鱼把页面卡死。5.3 浮点数精度在公式求值里连锁放大现象0.1加0.2算出0.30000000000000004乘以数量后误差继续放大报表合计栏和业务方手里的表格软件对不上用户直接提故障单。原因IEEE 754浮点数的二进制表示天然不精确。公式引擎里每个数值运算都走JavaScript的Number类型单次运算误差几乎不可见但公式往往是多级嵌套运算误差逐层累积到可感知的规模。解决分两层处理。求值结果返回前统一做一次业务精度收口按业务需求保留小数位用Math.round(value * 100) / 100而不是toFixed(2)后者返回字符串参与后续运算会引入隐式类型转换。内部运算过程不干预保持原生浮点运算性能。如果业务明确要求金额级精度就引入十进制运算库重写数值分支但这是有代价的决定性能开销按十倍估不要默认开启。5.4 撤销重做与编辑器交互状态脱节现象用户输入公式后按撤销快捷键公式文本回退了但自动补全弹层还挂在页面上不消失或者高亮颜色和公式内容对不上。原因撤销栈里只存了公式字符串没存编辑器状态。自动补全弹层的开关、光标位置、滚动位置这些UI状态没有跟着撤销动作回退导致渲染层出现文本与状态不一致。解决撤销快照的粒度按一次完整编辑操作切分快照字段至少包含公式字符串、光标位置、弹层状态三项。回退时字符串和光标一起恢复弹层统一关闭。实现时输入要做防抖合并连续字符输入在一个短间隔内合并成一次快照避免撤销按单个字符粒度走那会让用户疯掉。5.5 公式字符串被直接当成代码执行现象安全测试发现公式里构造特殊表达式可以读取页面上的全局变量甚至触发网络请求。业务方紧急叫停所有表单功能全组加班排查。原因实现者图省事用动态执行的方式把公式字符串直接求值绕过了解析器。公式字符串等于获得了脚本执行权限解析、校验、沙箱全部形同虚设。解决硬性规定公式只能走AST求值任何情况下不允许对公式字符串做动态执行。自定义函数是公式接触业务数据的唯一通道入参类型、返回值类型都要过白名单校验。这条规则要写进代码评审的检查清单比写进规范文档有用。安全没有后悔药一旦上线被利用回滚成本极其难看。6. 把公式编辑器做出产品感模板插入、动态提示与三套验证方法功能链路跑通之后和成熟产品之间的差距主要在手感。模板插入是投入产出比最高的功能把IF、SUMIF这类业务高频函数做成常用公式面板用户点击后在光标处插入函数骨架光标自动定位到第一个必填参数位置用户按Tab跳到下一个参数继续填。实现时不要只做字符串拼接要用解析器提供的光标落位信息确保插入后光标位置和补全弹层状态是自洽的。动态提示服务于已经写完一段公式的用户。光标停在某个函数调用的参数列表内时编辑器根据AST反查出当前所在函数和参数序号从函数元数据表拉出参数名、类型、必填标记和说明文字渲染在小浮层里。函数元数据表必须和注册表共用同一份数据源否则会出现能算但提示文案没有的割裂状态。验证方法上我固定跑三套用例。第一套是语法合法性覆盖嵌套函数、运算符优先级、括号不匹配、多余逗号。第二套是错误信息质量故意构造至少5种非法公式人工确认每条报错都能指出具体位置和修复方向。第三套是数值边界0、负数、极大数、NaN、空值引用各来一轮确认不会有非预期输出。三套跑完再交给业务方联调真实字段。这个习惯帮我挡掉了大量回归事故也让我在交付公式编辑器这类组件时心里始终有底。希望帮到你。本文还有配套的精品资源点击获取