清单控沙牛模板代码生成这个词，我在不同技术栈里见过完全不同的解释。前端同事嘴里，它是把重复页面结构提炼成组件；Java 后端那边，它是 MyBatis Generator 把表结构翻译成实体和 Mapper；嵌入式团队里，Simulink 模型点一下 Generate Code 就能吐出一整套 C 源码；做报表的同事更直接，FastReport 里拖一个打印模板，数据源一绑，PDF 就出来了。这些场景技术栈八竿子打不着，但底层骨架惊人地一致：用一份“带规则的结构描述”当母版，灌入数据，批量产出成品。这正是模板代码生成的本质。
这篇文章，我想把这些门派之间的墙拆掉。先讲清楚模板代码生成到底是什么、解决了什么问题，再把模板引擎的内部链路拆开来看，然后从零设计一个可自定义规则的轻量生成器，最后用跨领域对照把 FastReport、Simulink、WPF 模板这些看着完全不相关的东西串到同一条原理线上。适合谁看？后端、前端、测试、嵌入式甚至文档工程师都可以，只要你手头有重复劳动，这篇内容大概率能帮你省掉不止一晚的加班。
1. 模板代码生成到底在解决什么问题
1.1 从“复制粘贴改字段”到“参数化输出”
我以前待过一个项目组，业务模块长得几乎一模一样：一个列表接口、一个详情接口、一个新增接口、一个编辑接口，外加软删除。新人入职第一周，导师给的方向就是“照着 user 模块抄，把字段换成订单字段”。听起来高效，实际上全是坑：有人复制完忘了改 Service 里的判断逻辑，有人把另一个模块的权限注解也带了过来，代码评审直接变成连连看现场。
这种活本质上不是“写代码”，而是“套结构”。既然结构是固定的，就具备被参数化的条件。模板代码生成干的正是这件事：把固定结构固化成模板文件，把差异点声明成变量（表名、字段列表、类型映射、接口前缀），通过渲染机制把变量填充进结构，最后批量产出目标文件。从开发方式来看，这一步是从“复制粘贴”走向“声明式生产”的关键转折。
1.2 模板生成与普通工具函数的分界线
有人会问：写个脚本遍历表结构然后拼字符串，不也是生成代码吗？是，但那只是最低级的字符串拼接。真正的模板生成有几个分水岭：
- 结构的表现形式是“模板文件”，而不是埋在代码里的字符串。模板能独立修改、独立评审、独立测试；
- 生成过程有明确的“解析—渲染—输出”三阶段，而不是一次性 replace；
- 模板支持控制流（循环、条件、继承），能表达复杂结构，而不是只能填变量。
工具函数解决的是“某个节点上的差异”，模板生成解决的是“整棵结构树的差异”。下面这张表可以把三者的适用边界摆清楚。
1.3 手工、字符串拼接、模板生成三方对比
| 生产方式 | 典型表现 | 一致性 | 改动成本 | 适用规模 |
|---|---|---|---|---|
| 手工复制粘贴 | 抄代码改字段 | 靠人肉约束，极易漂移 | 改一处要全项目找同类 | 一次两次的小活 |
| 脚本字符串拼接 | Python 里用 f-string 拼出 .java 文件 | 脚本本身可复用，但结构耦合在脚本里 | 改结构要动脚本逻辑 | 单次批量、结构简单 |
| 模板引擎生成 | Jinja / FreeMarker / 自定义 DSL 驱动 | 模板是唯一事实源 | 改模板后全量重生成 | 长期、多项目、复杂结构 |
需要强调一点：三者没有绝对优劣。手工方式在“只有一次”的场景里反而最快；字符串拼接处理一次性报表导出也够用。但当你发现自己已经连续三个晚上在做同一种代码批量替换，就该考虑升级到模板生成，把“这活”变成“半天搞定的工具”。
这个判断标准很实用：同类劳动重复超过三次，就值得为它建模板。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 模板引擎的核心工作链路：解析、渲染与输出
要说原理，就得进引擎内部看一眼。无论你用 FreeMarker、Jinja、Thymeleaf 还是自己写的一个 replace 函数，完整链路都逃不开“解析、渲染、输出”三个动作。
2.1 模板里到底写了什么：变量、指令、继承
一个模板文件，表面看是普通文本加了若干特殊标记。常见标记大致分三类：
- 变量占位