公式编辑器面试反问与陷阱题

陷阱 1：这不就是做个输入框吗

我一般会先把问题拉回本质。输入框只是交互壳，真正难的是怎么把业务表达式安全地解析、校验和执行。只讲输入体验，面试官会觉得这是个组件题；把它讲成表达式引擎，价值就完全不一样。

我不会只说安全风险，还会补一句可控性问题。eval 很难做静态校验、错误定位、执行边界限制和平台级扩展。自己做 AST 解析虽然前期重一点，但后面在提示、校验、函数扩展和调试上都会更稳。

我会说现成库当然可以参考，但业务场景里通常会有字段引用、权限边界、函数白名单、错误提示、参数联想这些平台约束。单纯拿库来算表达式，不一定能很好承接业务规则，所以核心还是要看你能不能把语法、执行边界和交互体验串起来。

我会说这个项目恰恰很能体现前端深度。因为前端在这里不只是做 UI，而是在做语言建模、交互提示、错误反馈和安全执行边界。用户看到的是编辑器，前端要承接的是表达式从输入到解释执行的整条链路。

我一般会从四层讲。第一层是 token 和 AST，第二层是安全执行，第三层是函数扩展和规则控制，第四层是提示、报错和 TDD。把这四层讲清楚，面试官就会知道你做的不是一个输入框 demo，而是一套可维护的表达式引擎。

我会说这正是为什么要做 AST、函数注册机制和测试体系。表达式复杂不可怕，可怕的是没有边界。只要语法层、执行层、函数白名单和测试覆盖是稳定的，后面扩展反而会更有秩序。

公式编辑器面试里最容易踩的坑，就是把它讲成“输入框 + 计算公式”。我的策略一直是把它拉回到表达式引擎、AST 和安全执行这三件事上。