公式编辑器公共素材

使用说明

• 公式编辑器怎么讲得像亮点项目 统一从本页引用公共口径。
• 如果要改亮点表达、短讲法或追问答法，优先改本页。

一句话定性

公式编辑器不要讲成“我做了个输入框”，要讲成“我把用户输入的业务表达式，安全地转成可执行逻辑”。

30 秒版本

我做公式编辑器时，重点不是 UI，而是怎么在不使用 eval 的前提下，让用户像写 Excel 一样写表达式，同时还能保证安全性、正确性和可维护性。所以我最后做的不是一个普通输入框，而是一套从词法分析、语法分析、AST 到安全执行的表达式引擎，前端只是它的交互外壳。

1 分钟版本

如果让我讲公式编辑器，我会先讲它为什么难。因为用户希望的是像 Excel 一样直接写公式，但平台又不能直接 eval，否则安全风险和可控性都很差。

所以我的解决思路不是去拼字符串执行，而是自己做表达式解析。也就是先做词法分析，把字符串切成 token；再做语法分析，生成 AST；最后再基于 AST 去调用一组预定义的安全函数完成计算。这样既能避免执行任意代码，又能把表达式逻辑稳定地控制在平台规则里。

对我来说，这个项目最值得讲的地方不只是“能算”，而是它把安全性、可扩展性和用户体验放到一起考虑了。

2 到 3 分钟版本

公式编辑器这个项目，如果只讲“我做了一个表达式输入框”，其实会浪费掉它的价值。因为它真正难的地方不在输入，而在表达式引擎。

业务上用户希望的是，像在 Excel 里一样写类似 A = B + C 这样的公式，把字段之间的逻辑关系表达出来。但技术上我们又不能直接 eval，因为那样会带来安全风险，也很难限制执行边界。

所以我最后的思路是自己做一套可控的表达式解析流程。第一步做词法分析，把原始字符串拆成 token；第二步做语法分析，把 token 组织成 AST；第三步基于 AST 做解释执行，只允许调用平台预先定义好的安全函数和运算规则。这样用户看到的是比较友好的公式表达体验，平台拿到的是一棵可控、可校验、可执行的语法树。

这个设计有几个好处。第一是安全，避免了直接执行任意字符串。第二是可扩展，后面新增函数、运算符、校验规则都可以在语法层和执行层扩展。第三是可调试，因为 AST 本身就比字符串更适合做错误定位、提示和后续优化。

如果再往前端体验上讲，我会补充两点。一个是实时提示，比如函数信息、参数提示、错误位置提示；另一个是测试驱动开发。因为这种引擎很容易被边界条件打崩，所以我会用 TDD 去覆盖解析和执行的最小单元，让后续扩函数和重构更稳。

所以如果总结这个项目，我会说它不是一个输入框组件，而是一套把业务表达式安全落地的前端表达式引擎。

结合项目的 1 分钟讲法

如果结合我做过的公式编辑器项目来讲，我一般会把它讲成一个服务低代码平台的表达式引擎，而不是一个输入框组件。业务希望像写 Excel 一样写公式，去完成字段计算、显示隐藏、校验规则和审批条件配置，但平台又不能直接 eval。所以我主导做了从词法分析、语法分析、AST 到安全执行的整套链路，再把它包装成带函数提示、参数提示和错误定位的编辑体验。这个项目最能体现前端深度的地方，是我把语言解析、安全执行、交互体验和测试稳定性串成了一套平台能力。

结合项目的 2 分钟讲法

我当时做公式编辑器，场景不是单纯给用户一个输入框，而是服务低代码平台里的字段联动、公式计算、显示隐藏和校验规则配置。业务希望能像 Excel 一样写表达式，但平台不能直接 eval，所以真正难点不是输入，而是表达式怎么安全、可控、可扩展地运行起来。

我主导做的第一块是表达式解析主链路。先定义表达式支持的运算符、函数、字段引用等语言边界，再通过词法分析和语法分析把字符串转成 AST。这样平台拿到的就不是一串难以处理的字符，而是一棵结构化语义树。

第二块是执行和扩展机制。我们基于 AST 做解释执行，只允许命中平台预定义的安全函数和运算规则，避免直接执行任意字符串。这样既保证了安全性，也让后续扩函数、扩运算符、做静态校验和错误定位都更容易。

第三块是可用性和稳定性。因为表达式能力如果只有引擎没有体验，业务也很难真正用起来，所以我补了函数提示、参数提示、错误定位和实时校验这些能力；同时通过 TDD 和测试用例覆盖解析、执行以及边界场景，让后续扩展和重构更稳。

所以这个项目我一般不会讲成“做了一个公式输入框”，而会讲成“做了一套服务低代码平台的安全表达式引擎，并把它做成业务可用的编辑体验”。

代表性工作

• 主导表达式语言模型与解析链路设计，明确运算符、函数、字段引用等语法边界，并完成词法分析、语法分析到 AST 的主链路建设。
• 设计并实现基于 AST 的解释执行机制，在不使用 eval 的前提下完成表达式计算、规则判断和安全执行。
• 建设函数提示、参数提示、错误定位和实时校验等编辑体验能力，提升业务侧编写公式的可用性和准确性。
• 沉淀函数注册与扩展机制，让新增函数、运算规则和校验规则可以沿着统一边界演进，而不是零散写死在页面逻辑里。
• 通过 TDD 和测试用例覆盖解析、执行和边界场景，提升表达式引擎在持续扩展过程中的稳定性。

价值为什么不只是输入框

我在这个项目里真正做的不是一个输入组件，而是把业务表达式抽象成平台可承接的语言模型和执行机制。输入框只是交互外壳，真正的价值在于解析、校验、执行、提示和扩展机制这一整套底层能力。

为什么不用 eval

因为 eval 的问题不只是安全，还有可控性。你很难限制用户到底能执行什么，也很难对表达式做静态校验、错误提示和平台级扩展。自己做 AST 解析虽然前期重一点，但边界更清楚。

AST 的价值

AST 的价值在于把一维字符串变成结构化语义模型。这样表达式优先级、函数调用、字段引用都会变得明确，后面做执行、校验、报错定位和扩展都更容易。

最亮的点

我觉得最亮的点，是我没有把它当成一个输入组件去做，而是把它当成一个语言处理问题来做。也就是从表达式语法、AST、安全执行到交互体验，整套都串起来了。

最后一句收尾

所以这个项目最适合的讲法，不是“我做了一个公式编辑器”，而是“我做了一套安全可控的表达式引擎，并把它包装成可用的编辑体验”。