在那次联调故障之前我对“手写所有代码”一直抱着莫名的执念。当时我负责的模拟项目X里数据库有三十多张表每张表都要配一份实体类、一份查询参数类、一份返回结果类。光这些固定结构的代码就能写上一整周更折磨人的是复制粘贴之后总会漏改某个字段得等到联调阶段才暴露。那一次我盯着屏幕上的报错想了很久终于决定试试用代码生成与元编程的思路来解决问题。这篇文章就是那次尝试的完整复盘适合所有正在被重复性编码折磨、又拿不准该不该引入代码生成的开发者。我会先讲清楚代码生成和元编程到底是什么关系再结合那段真实经历说触发点然后给出三条技术路线、一个脚本的完整成长过程以及我踩过并修复的几个坑。最后分享我自己判断“要不要上代码生成”的一套标准以及一条很反直觉的经验小而可靠的生成器永远比一个看似全面却没人敢碰的“元框架”更有用。1. 代码生成与元编程先厘清这两个概念到底差在哪1.1 “程序操作程序”到底是什么很多人把代码生成和元编程当成同义词我一开始也这样。直到被同事反问“你说的元编程到底指哪一层”我才认真去辨析这两个概念。元编程的核心定义是“程序操作程序”。一个程序能够读取、分析、修改或者生成另一段程序——包括修改自己——这种能力都叫元编程。我最先接触到的元编程形态是运行时反射程序在运行过程中查看某个对象的类型、遍历它的属性、调用它的方法。那时候我觉得反射很酷但也没意识到这属于元编程的范畴。后来接触了宏和模板展开发现它们是在编译前做类似的事情把一段抽象写法展开成一段更具体的代码瞬间理解了“程序操作程序”不是一个玄学概念而是计算机里一直都在发生的事情。如果把写业务代码比作写一份菜谱那么元编程就是“根据菜谱自动写出更多菜谱”的程序。它分层级有的是运行时动态决定行为有的是编译期展开结构有的干脆是在构建前批量生成文本。这些都是元编程的不同表现只是平时我们不一定会用这个名词去称呼它们。1.2 代码生成是元编程最接地气的形态代码生成这个词更落地。它强调的是“产出一段源代码”这个动作而且是提前完成的。日常提到的代码生成大多是指写一个脚本、一个模板或者一个工具把结构高度重复的源码批量做出来。你可以把元编程理解成一个大家族代码生成是其中最容易在团队中推行的分支——因为它的结果是静态的、可见的、可以被review的。为什么说静态和可见特别重要代码生成器在编译前或者构建前运行生成的文件最终会出现在工程目录里任何人都能打开看、能断点调试、能改。相比之下运行时反射虽然灵活但行为的逻辑藏在运行机制里出现问题往往要翻调用栈才能定位。对于绝大多数业务系统而言静态生成的代码更容易被接受。1.3 它和配置化开发不是一回事我还要提醒一个容易混淆的地方代码生成不等于配置化。配置化的做法是同一套代码在不同配置项下表现出不同行为程序本体不变代码生成则是针对不同输入直接产出不同代码文件。一个是参数化一个是“复制并改写”。举个简单的例子一套规则引擎通过配置项组合出不同校验流程那是配置化但如果是根据数据库表结构生成对应的持久化类文件那就是代码生成。搞清楚这点你设计系统的时候才不会绕弯子。从实用主义出发我可以给三个形态画一个粗略的边界形态发生时机典型场景主要代价模板生成构建前批量生成DTO、接口封装、模型类模板维护与同步宏/语法树变换编译期语法扩展、自动插桩、批量改现有代码学习成本、调试难度反射/动态代理运行时通用转换、动态调用、切面逻辑性能开销、类型安全弱化这张表不是铁律但能帮你在开头就把方向定下来。我接下来要讲的亲身经历就是在“模板生成”这条路上发生的。2. 一次真实复盘我为什么从人肉复制粘贴转向生成脚本2.1 三千行重复代码下的效率陷阱模拟项目X的数据库结构其实不算复杂但表量实在多。每张表需要一套“实体类、查询参数类、返回结果类”三件套三件套里超过七成的代码长得很像字段名、类型、注释、映射注解换汤不换药。最初我打算硬写毕竟写起来没什么智力含量就是耗时间。真正让我受不了的是那类低级错误。记得有一次实体类里的字段叫 createTime而我在返回结果类里复制的时候不知道哪根筋搭错改成了 createDate。编译能过字段也存在但接口文档和实际输出对不上前后端联调时别人对着抓包数据看了快一个小时才发现。那一刻我意识到当代码的绝大部分信息都是可预测的重复内容时人肉复制的出错率会高到离谱。粗略算了笔账三十张表、每张表三份文件每份文件六十到八十行总量奔着六千行去了。用四天时间手写再用一天时间review最后还要留出修低级错误的时间性价比非常差。2.2 动手前我做的三个判断决定动手写生成脚本之前我没有急着写代码而是先回答了自己三个问题。第一个问题这些类的结构是不是足够稳定答案是肯定的。表的增删改查模型多年不变类结构几乎定型变化的只是表名、字段、类型和注释。这种结构完全符合“稳定模板变动数据”的生成模型。第二个问题生成出来的代码是不是还要长期被人维护答案也是肯定的。这些类会演进会有人来读、来改甚至加字段。这意味着生成脚本本身必须很干净模板也要写得像业务代码一样容易被理解不能图一时爽快拼一个只有自己能跑的脏脚本。第三个问题现有工具能不能覆盖这个场景我试过IDE自带的代码片段和快速重构发现它们只能逐个处理没法把几十张表的字段注释、类型映射和注解批量带出来。已经存在的通用工具往往面向特定ORM或框架换到当前项目的自定义结构上又不够贴合。于是答案很清楚自己写一个轻量脚本最好。这三个问题其实就是判断“该不该代码生成”的基础模型。任何项目只要三条都满足你就可以认真考虑自己做一个小生成器了。3. 代码生成的三条技术路线与选型原则3.1 模板字符串最快见效也最容易失控最直接的做法是拿脚本拼字符串。读入表结构循环拼接输出一个文件。代码量很小二三十行就能跑起来。但它有一个致命弱点手拼字符串很难处理缩进、引号、嵌套结构和特殊字符稍不留神生成出来的文件就是一团乱麻甚至编译不过。我的经验是哪怕脚本很简单也尽量不要用裸的字符串拼接去构造代码。稍微复杂一点的场景应该引入模板引擎。大致思路是把目标代码的骨架写在一个模板文件里在中空位置留下占位符和控制语句脚本只负责准备数据、渲染模板、写盘。这样模板本身就是“示例代码”肉眼容易检查生成结果的可控性也高得多。举个例子以下是我早期做生成器时模板的核心片段我用的是模板引擎的标准语法示意package {{ package_name }}; public class {{ class_name }} { {% for field in fields %} private {{ field.type }} {{ field.name }}; {% endfor %} }脚本要做的事就是向模板里填表名、字段名、类型映射后的结果。看着简单但它解决了手拼字符串最痛的缩进和循环问题。模板字符串路线的优点是成本极低、直观、容易退回缺点是它只适合从零生成一个结构清晰的文本文件一旦要做“修改现有代码”这种精细活它就很难胜任。3.2 AST变换改已有代码时最稳的施工方式有一类需求不是“从零生成文件”而是“批量改造已有代码”。比如给所有公开方法统一加日志或者给某个基础类统一实现一个接口。这种场景在源代码文本层面做正则替换极其危险——谁也没法保证正则能覆盖所有写法而不误伤注释和字符串。更稳的做法是把代码解析成抽象语法树在树结构里定位到需要修改的节点做精准编辑再输出完整的文本。市面上的现代语言编译器大多提供了语法树相关的接口或者有独立的解析框架能做这件事。好处是改动位置精确、对无关代码零干扰坏处是学习成本高做一次完整的解析遍历往往需要深入了解编译原理的细节。我的建议是这类需求尽量先找成熟的方案不要轻易自己写解析器如果项目里确实没有现成方案那就严格限定改动范围并为每个变换动作补一套单元测试。3.3 运行时反射最灵活但要有使用边界第三条路线是运行时反射。它不需要生成任何文件程序自己检查类型结构在运行时完成通用逻辑。典型例子是做对象映射从源对象里读出同名字段自动拷贝到目标对象的相同属性上去省去几十行手写赋值。我当时把这种思路用在消息结构转换上效果很香新增字段只要双方命名一致转换逻辑一行都不用改。但反射也有明显的代价。类型不匹配只在运行时暴露不会在编译期告诉你频繁使用反射会有性能开销另外它让代码的静态可读性变差——阅读代码的人看不到这个字段到底是怎么被赋值的。所以我的原则是能用静态生成解决的不轻易用反射反射只留给那些真正需要“运行时动态性”的场景。3.4 怎么选稳定结构用生成动态行为用反射已有代码改造用AST给个总结性的选型逻辑如果你的诉求是“为一批固定结构产出静态文件”优先考虑模板式代码生成如果诉求是“在运行时根据条件动态决定执行逻辑”优先考虑反射或动态代理如果诉求是“在大规模已有代码上做批量修改”优先考虑语法树变换。这三条路线不是非此即彼。实际系统里我见过不少组合使用的情况先用模板生成大部分静态骨架再在某一层用反射做统一处理最后用语法树工具做少量已有代码的插桩。关键是每种技术放在它最合适的时间点。4. 实操记录我的生成脚本是怎么一步步长出来的4.1 第一步先把输入的数据结构定义清楚很多人写生成器第一件事是去拼模板但真正关键的是先定义好“输入数据长什么样”。我当时的输入是表结构元数据整理成类似这样的结构{ table: user, class_name: User, fields: [ {name: id, type: bigint, comment: 主键}, {name: name, type: varchar(64), comment: 姓名}, {name: created_at, type: datetime, comment: 创建时间} ] }数据结构的质量直接决定模板的简洁程度。我一开始贪快把所有信息揉成一个大字典模板里到处是深层访问写起来晕头转向。后来改成先做一次清洗和归一化输出上面这种规整结构模板的逻辑立刻清晰起来。这里的经验是生成器脚本的复杂度应该尽量放在“数据处理”一侧模板侧保持极简。4.2 第二步设计模板骨架而不是拼接字符串输入数据稳定之后模板核心就只需要关注三件事包名、类名、字段列表。下面是一段高度简化的模板示意package {{ package_name }}; public class {{ class_name }} { {% for field in fields %} /** {{ field.comment }} */ private {{ field_type_map[field.type] }} {{ field.name }}; {% endfor %} }为了让生成结果足够“像人写的代码”我在模板里保留了字段注释用两空格缩进统一格式并且在文件顶部加了自动生成的醒目提示。这些细节看起来小但决定了生成物能不能被团队接受。一个被格式化成天书、没有任何注释的生成类review时基本没人愿意认真看。4.3 第三步类型映射、保留字、注释里的坑类型映射是最容易出错的地方。数据库里的 bigint 映射到哪种语言类型、decimal 映射到什么精度、datetime 要不要转成时间对象这些都得维护一张映射表。当时我第一版漏了 decimal导致所有带金额的表生成的字段类型都变成了整型编译不报错数据精度却悄悄丢了。这个问题在功能测试阶段才被抓回来修复成本比写脚本本身都高。字段名为保留字的情况也很坑。某张表里有个字段叫 desc生成后直接和语言关键字打架。我的处理是在生成阶段做一次重命名规则比如统一改成 descValue并保留一份映射说明。字段注释里的特殊字符同样不能忽视我遇到过注释里带着换行符和引号把生成文件的语法冲断的情况。后来在数据清洗阶段对注释做了转义和截断这类问题才彻底消失。4.4 第四步验证生成产物并把脚本固化成流程生成器写完之后我没有直接把它当成“一次性脚本”而是做了三件长期有用的事。第一保留了手工维护的参考实现用 diff 逐文件对比生成结果确认除了预期差异外没有多余变化第二每次改动生成器后都会重新生成全量文件并走一遍编译用编译期约束兜住生成代码的质量第三把重新生成的命令写进项目文档确保后面的人能复现生成过程而不是对着成品干瞪眼。还有一个对协作很重要的决定生成结果要真实落盘进版本库。我知道有团队喜欢“构建时现场生成、不提交产物”这种方式能避免生成物和脚本分叉但会让开发时看到的文件和调试器看到的文件对不上。我选择的折中是开发阶段生成物入库脚本改动时再统一重新生成至少保证调试和review的对象是一致的。5. 生成代码项目最容易翻车的三个地方5.1 生成物可读性差review变成受刑生成代码最被诟病的就是可读性。如果脚本只求正确不求美观产出的类可能缩进混乱、缺少空行、没有注释甚至夹杂调试残留。代码一旦进到库里下一个读它的人不会知道这是生成出来的只会觉得写这段代码的人不讲究。我的解法是在模板阶段就强制规范每行固定宽度、字段注释必须保留、生成后统一经过格式化工具再写盘。宁可脚本里多写几行格式逻辑也要避免把阅读成本转嫁给同事。5.2 调试时出现“幽灵代码”当生成发生在构建过程中且生成结果只停留在内存里时调试器面对的是一份“并不存在于磁盘”的代码。断点显示行号对不上、调用堆栈里出现奇怪的临时路径排查问题就像在跟幽灵吵架。我第一次遇到时一度怀疑是IDE缓存坏了。后来我把生成逻辑都改成先落盘再编译调试时就能直接打开真实文件打断点这个问题就消失了。如果你的项目坚持构建时生成那么至少要为调试器提供正确的源文件映射否则团队排障效率会受影响。5.3 生成脚本没人维护变成新的债生成脚本虽然叫“脚本”但它同样是严肃的代码需要review、需要测试、需要文档。我看到过很多生成器变成僵尸的例子最初写的人还在时跑得很顺人一走就没人敢碰遇到问题宁愿手改生成物也不去动脚本。这实际上是技术债的转移。避免的办法没有捷径就是把生成器当成一等公民对待代码风格和业务代码同一标准关键转换逻辑有单元测试保护项目文档里写明输入数据从哪来、怎么重新生成。5.4 增量构建带来的“改了没生效”幻觉还有一个特别隐蔽的坑生成脚本改了但当次构建复用了旧产物导致你看到的输出还是老样子。我花了整整一个下午排查一个“改了脚本却不生效”的问题最后发现是中间产物被缓存住了。从那以后我在本地调试生成器时习惯先清理中间目录再重建在正式流程里则保留一个校验步骤比较生成产物和源模板的哈希值不一致直接报错。简单有效但很容易被人忽略。6. 到什么程度该用代码生成我自己的判断清单6.1 四问判断法被上面这些坑教育过之后我现在遇到一个模块会用四个问题快速判断该不该上代码生成。第一问同类结构出现多少次我个人的阈值是至少三次以上且每次只是数据层面的变化。如果只出现一两次手写反而更快。第二问结构变化频繁吗如果这个模块的类结构本身还在频繁调整生成脚本也得跟着反复改生成的优势会被维护成本抵消。稳定结构才值得被自动化。第三问团队能接受多一步生成流程吗代码生成不是替换一两个文件那么简单它引入了“如何复现”的学习成本。团队里至少要有一两个人能看得懂生成脚本否则遇到问题没人兜底。第四问生成结果是否让团队愿意review如果生成出来是一坨几乎没法看的东西那即使功能正确长期协作成本也吃不消。可读性是硬指标。这四个问题对应的不是“行不行”而是“值不值”。代码生成从来不是银弹但它特别适合那些结构重复、变化收敛、团队愿意交付出少量维护成本的领域。6.2 几个正在出现的趋势和新思路最近几年元编程的落地方案明显在往“把意图交给描述、把重复交给机器”的方向走。声明式配置、领域描述语言、编译期源码生成机制都在降低代码生成的使用门槛。我观察到的一个一致趋势是很多团队不再把生成物当成“一次性的鸡肋”而是当成一份可追溯的资产配合模板、输入数据、版本管理一起维护。当然趋势归趋势落地方案还是要看项目形态。像我们这种以数据表结构为核心的场景用模板式生成永远是最直观的起点等哪天需要更精细的源码级改造再去研究语法树变换也不迟。在元编程的路上第一原则始终是让代码去写代码但最终还要保证写出来的代码能被普通人读懂。最后想分享一个小技巧别一上来就设计一个“万能生成器”。我第一次写生成脚本也只敢从最痛的两张表开始逻辑写得很直接跑了几天确认能覆盖日常场景再逐步把类型映射和特殊字段处理抽出来通用化。一个小而可靠的生成器永远比一个看起来全面但没人敢碰的“元框架”更有价值。亲手把重复代码变成模板数据之后你会对“程序操作程序”这件事有一种很奇妙的掌控感这也是我在代码生成与元编程这条路上最大的收获。 
长河君 · 2026/10/16 3:59:43 · 阅读 1.2k 代码生成与元编程实战：摆脱重复编码的困境
在那次联调故障之前我对“手写所有代码”一直抱着莫名的执念。当时我负责的模拟项目X里数据库有三十多张表每张表都要配一份实体类、一份查询参数类、一份返回结果类。光这些固定结构的代码就能写上一整周更折磨人的是复制粘贴之后总会漏改某个字段得等到联调阶段才暴露。那一次我盯着屏幕上的报错想了很久终于决定试试用代码生成与元编程的思路来解决问题。这篇文章就是那次尝试的完整复盘适合所有正在被重复性编码折磨、又拿不准该不该引入代码生成的开发者。我会先讲清楚代码生成和元编程到底是什么关系再结合那段真实经历说触发点然后给出三条技术路线、一个脚本的完整成长过程以及我踩过并修复的几个坑。最后分享我自己判断“要不要上代码生成”的一套标准以及一条很反直觉的经验小而可靠的生成器永远比一个看似全面却没人敢碰的“元框架”更有用。1. 代码生成与元编程先厘清这两个概念到底差在哪1.1 “程序操作程序”到底是什么很多人把代码生成和元编程当成同义词我一开始也这样。直到被同事反问“你说的元编程到底指哪一层”我才认真去辨析这两个概念。元编程的核心定义是“程序操作程序”。一个程序能够读取、分析、修改或者生成另一段程序——包括修改自己——这种能力都叫元编程。我最先接触到的元编程形态是运行时反射程序在运行过程中查看某个对象的类型、遍历它的属性、调用它的方法。那时候我觉得反射很酷但也没意识到这属于元编程的范畴。后来接触了宏和模板展开发现它们是在编译前做类似的事情把一段抽象写法展开成一段更具体的代码瞬间理解了“程序操作程序”不是一个玄学概念而是计算机里一直都在发生的事情。如果把写业务代码比作写一份菜谱那么元编程就是“根据菜谱自动写出更多菜谱”的程序。它分层级有的是运行时动态决定行为有的是编译期展开结构有的干脆是在构建前批量生成文本。这些都是元编程的不同表现只是平时我们不一定会用这个名词去称呼它们。1.2 代码生成是元编程最接地气的形态代码生成这个词更落地。它强调的是“产出一段源代码”这个动作而且是提前完成的。日常提到的代码生成大多是指写一个脚本、一个模板或者一个工具把结构高度重复的源码批量做出来。你可以把元编程理解成一个大家族代码生成是其中最容易在团队中推行的分支——因为它的结果是静态的、可见的、可以被review的。为什么说静态和可见特别重要代码生成器在编译前或者构建前运行生成的文件最终会出现在工程目录里任何人都能打开看、能断点调试、能改。相比之下运行时反射虽然灵活但行为的逻辑藏在运行机制里出现问题往往要翻调用栈才能定位。对于绝大多数业务系统而言静态生成的代码更容易被接受。1.3 它和配置化开发不是一回事我还要提醒一个容易混淆的地方代码生成不等于配置化。配置化的做法是同一套代码在不同配置项下表现出不同行为程序本体不变代码生成则是针对不同输入直接产出不同代码文件。一个是参数化一个是“复制并改写”。举个简单的例子一套规则引擎通过配置项组合出不同校验流程那是配置化但如果是根据数据库表结构生成对应的持久化类文件那就是代码生成。搞清楚这点你设计系统的时候才不会绕弯子。从实用主义出发我可以给三个形态画一个粗略的边界形态发生时机典型场景主要代价模板生成构建前批量生成DTO、接口封装、模型类模板维护与同步宏/语法树变换编译期语法扩展、自动插桩、批量改现有代码学习成本、调试难度反射/动态代理运行时通用转换、动态调用、切面逻辑性能开销、类型安全弱化这张表不是铁律但能帮你在开头就把方向定下来。我接下来要讲的亲身经历就是在“模板生成”这条路上发生的。2. 一次真实复盘我为什么从人肉复制粘贴转向生成脚本2.1 三千行重复代码下的效率陷阱模拟项目X的数据库结构其实不算复杂但表量实在多。每张表需要一套“实体类、查询参数类、返回结果类”三件套三件套里超过七成的代码长得很像字段名、类型、注释、映射注解换汤不换药。最初我打算硬写毕竟写起来没什么智力含量就是耗时间。真正让我受不了的是那类低级错误。记得有一次实体类里的字段叫 createTime而我在返回结果类里复制的时候不知道哪根筋搭错改成了 createDate。编译能过字段也存在但接口文档和实际输出对不上前后端联调时别人对着抓包数据看了快一个小时才发现。那一刻我意识到当代码的绝大部分信息都是可预测的重复内容时人肉复制的出错率会高到离谱。粗略算了笔账三十张表、每张表三份文件每份文件六十到八十行总量奔着六千行去了。用四天时间手写再用一天时间review最后还要留出修低级错误的时间性价比非常差。2.2 动手前我做的三个判断决定动手写生成脚本之前我没有急着写代码而是先回答了自己三个问题。第一个问题这些类的结构是不是足够稳定答案是肯定的。表的增删改查模型多年不变类结构几乎定型变化的只是表名、字段、类型和注释。这种结构完全符合“稳定模板变动数据”的生成模型。第二个问题生成出来的代码是不是还要长期被人维护答案也是肯定的。这些类会演进会有人来读、来改甚至加字段。这意味着生成脚本本身必须很干净模板也要写得像业务代码一样容易被理解不能图一时爽快拼一个只有自己能跑的脏脚本。第三个问题现有工具能不能覆盖这个场景我试过IDE自带的代码片段和快速重构发现它们只能逐个处理没法把几十张表的字段注释、类型映射和注解批量带出来。已经存在的通用工具往往面向特定ORM或框架换到当前项目的自定义结构上又不够贴合。于是答案很清楚自己写一个轻量脚本最好。这三个问题其实就是判断“该不该代码生成”的基础模型。任何项目只要三条都满足你就可以认真考虑自己做一个小生成器了。3. 代码生成的三条技术路线与选型原则3.1 模板字符串最快见效也最容易失控最直接的做法是拿脚本拼字符串。读入表结构循环拼接输出一个文件。代码量很小二三十行就能跑起来。但它有一个致命弱点手拼字符串很难处理缩进、引号、嵌套结构和特殊字符稍不留神生成出来的文件就是一团乱麻甚至编译不过。我的经验是哪怕脚本很简单也尽量不要用裸的字符串拼接去构造代码。稍微复杂一点的场景应该引入模板引擎。大致思路是把目标代码的骨架写在一个模板文件里在中空位置留下占位符和控制语句脚本只负责准备数据、渲染模板、写盘。这样模板本身就是“示例代码”肉眼容易检查生成结果的可控性也高得多。举个例子以下是我早期做生成器时模板的核心片段我用的是模板引擎的标准语法示意package {{ package_name }}; public class {{ class_name }} { {% for field in fields %} private {{ field.type }} {{ field.name }}; {% endfor %} }脚本要做的事就是向模板里填表名、字段名、类型映射后的结果。看着简单但它解决了手拼字符串最痛的缩进和循环问题。模板字符串路线的优点是成本极低、直观、容易退回缺点是它只适合从零生成一个结构清晰的文本文件一旦要做“修改现有代码”这种精细活它就很难胜任。3.2 AST变换改已有代码时最稳的施工方式有一类需求不是“从零生成文件”而是“批量改造已有代码”。比如给所有公开方法统一加日志或者给某个基础类统一实现一个接口。这种场景在源代码文本层面做正则替换极其危险——谁也没法保证正则能覆盖所有写法而不误伤注释和字符串。更稳的做法是把代码解析成抽象语法树在树结构里定位到需要修改的节点做精准编辑再输出完整的文本。市面上的现代语言编译器大多提供了语法树相关的接口或者有独立的解析框架能做这件事。好处是改动位置精确、对无关代码零干扰坏处是学习成本高做一次完整的解析遍历往往需要深入了解编译原理的细节。我的建议是这类需求尽量先找成熟的方案不要轻易自己写解析器如果项目里确实没有现成方案那就严格限定改动范围并为每个变换动作补一套单元测试。3.3 运行时反射最灵活但要有使用边界第三条路线是运行时反射。它不需要生成任何文件程序自己检查类型结构在运行时完成通用逻辑。典型例子是做对象映射从源对象里读出同名字段自动拷贝到目标对象的相同属性上去省去几十行手写赋值。我当时把这种思路用在消息结构转换上效果很香新增字段只要双方命名一致转换逻辑一行都不用改。但反射也有明显的代价。类型不匹配只在运行时暴露不会在编译期告诉你频繁使用反射会有性能开销另外它让代码的静态可读性变差——阅读代码的人看不到这个字段到底是怎么被赋值的。所以我的原则是能用静态生成解决的不轻易用反射反射只留给那些真正需要“运行时动态性”的场景。3.4 怎么选稳定结构用生成动态行为用反射已有代码改造用AST给个总结性的选型逻辑如果你的诉求是“为一批固定结构产出静态文件”优先考虑模板式代码生成如果诉求是“在运行时根据条件动态决定执行逻辑”优先考虑反射或动态代理如果诉求是“在大规模已有代码上做批量修改”优先考虑语法树变换。这三条路线不是非此即彼。实际系统里我见过不少组合使用的情况先用模板生成大部分静态骨架再在某一层用反射做统一处理最后用语法树工具做少量已有代码的插桩。关键是每种技术放在它最合适的时间点。4. 实操记录我的生成脚本是怎么一步步长出来的4.1 第一步先把输入的数据结构定义清楚很多人写生成器第一件事是去拼模板但真正关键的是先定义好“输入数据长什么样”。我当时的输入是表结构元数据整理成类似这样的结构{ table: user, class_name: User, fields: [ {name: id, type: bigint, comment: 主键}, {name: name, type: varchar(64), comment: 姓名}, {name: created_at, type: datetime, comment: 创建时间} ] }数据结构的质量直接决定模板的简洁程度。我一开始贪快把所有信息揉成一个大字典模板里到处是深层访问写起来晕头转向。后来改成先做一次清洗和归一化输出上面这种规整结构模板的逻辑立刻清晰起来。这里的经验是生成器脚本的复杂度应该尽量放在“数据处理”一侧模板侧保持极简。4.2 第二步设计模板骨架而不是拼接字符串输入数据稳定之后模板核心就只需要关注三件事包名、类名、字段列表。下面是一段高度简化的模板示意package {{ package_name }}; public class {{ class_name }} { {% for field in fields %} /** {{ field.comment }} */ private {{ field_type_map[field.type] }} {{ field.name }}; {% endfor %} }为了让生成结果足够“像人写的代码”我在模板里保留了字段注释用两空格缩进统一格式并且在文件顶部加了自动生成的醒目提示。这些细节看起来小但决定了生成物能不能被团队接受。一个被格式化成天书、没有任何注释的生成类review时基本没人愿意认真看。4.3 第三步类型映射、保留字、注释里的坑类型映射是最容易出错的地方。数据库里的 bigint 映射到哪种语言类型、decimal 映射到什么精度、datetime 要不要转成时间对象这些都得维护一张映射表。当时我第一版漏了 decimal导致所有带金额的表生成的字段类型都变成了整型编译不报错数据精度却悄悄丢了。这个问题在功能测试阶段才被抓回来修复成本比写脚本本身都高。字段名为保留字的情况也很坑。某张表里有个字段叫 desc生成后直接和语言关键字打架。我的处理是在生成阶段做一次重命名规则比如统一改成 descValue并保留一份映射说明。字段注释里的特殊字符同样不能忽视我遇到过注释里带着换行符和引号把生成文件的语法冲断的情况。后来在数据清洗阶段对注释做了转义和截断这类问题才彻底消失。4.4 第四步验证生成产物并把脚本固化成流程生成器写完之后我没有直接把它当成“一次性脚本”而是做了三件长期有用的事。第一保留了手工维护的参考实现用 diff 逐文件对比生成结果确认除了预期差异外没有多余变化第二每次改动生成器后都会重新生成全量文件并走一遍编译用编译期约束兜住生成代码的质量第三把重新生成的命令写进项目文档确保后面的人能复现生成过程而不是对着成品干瞪眼。还有一个对协作很重要的决定生成结果要真实落盘进版本库。我知道有团队喜欢“构建时现场生成、不提交产物”这种方式能避免生成物和脚本分叉但会让开发时看到的文件和调试器看到的文件对不上。我选择的折中是开发阶段生成物入库脚本改动时再统一重新生成至少保证调试和review的对象是一致的。5. 生成代码项目最容易翻车的三个地方5.1 生成物可读性差review变成受刑生成代码最被诟病的就是可读性。如果脚本只求正确不求美观产出的类可能缩进混乱、缺少空行、没有注释甚至夹杂调试残留。代码一旦进到库里下一个读它的人不会知道这是生成出来的只会觉得写这段代码的人不讲究。我的解法是在模板阶段就强制规范每行固定宽度、字段注释必须保留、生成后统一经过格式化工具再写盘。宁可脚本里多写几行格式逻辑也要避免把阅读成本转嫁给同事。5.2 调试时出现“幽灵代码”当生成发生在构建过程中且生成结果只停留在内存里时调试器面对的是一份“并不存在于磁盘”的代码。断点显示行号对不上、调用堆栈里出现奇怪的临时路径排查问题就像在跟幽灵吵架。我第一次遇到时一度怀疑是IDE缓存坏了。后来我把生成逻辑都改成先落盘再编译调试时就能直接打开真实文件打断点这个问题就消失了。如果你的项目坚持构建时生成那么至少要为调试器提供正确的源文件映射否则团队排障效率会受影响。5.3 生成脚本没人维护变成新的债生成脚本虽然叫“脚本”但它同样是严肃的代码需要review、需要测试、需要文档。我看到过很多生成器变成僵尸的例子最初写的人还在时跑得很顺人一走就没人敢碰遇到问题宁愿手改生成物也不去动脚本。这实际上是技术债的转移。避免的办法没有捷径就是把生成器当成一等公民对待代码风格和业务代码同一标准关键转换逻辑有单元测试保护项目文档里写明输入数据从哪来、怎么重新生成。5.4 增量构建带来的“改了没生效”幻觉还有一个特别隐蔽的坑生成脚本改了但当次构建复用了旧产物导致你看到的输出还是老样子。我花了整整一个下午排查一个“改了脚本却不生效”的问题最后发现是中间产物被缓存住了。从那以后我在本地调试生成器时习惯先清理中间目录再重建在正式流程里则保留一个校验步骤比较生成产物和源模板的哈希值不一致直接报错。简单有效但很容易被人忽略。6. 到什么程度该用代码生成我自己的判断清单6.1 四问判断法被上面这些坑教育过之后我现在遇到一个模块会用四个问题快速判断该不该上代码生成。第一问同类结构出现多少次我个人的阈值是至少三次以上且每次只是数据层面的变化。如果只出现一两次手写反而更快。第二问结构变化频繁吗如果这个模块的类结构本身还在频繁调整生成脚本也得跟着反复改生成的优势会被维护成本抵消。稳定结构才值得被自动化。第三问团队能接受多一步生成流程吗代码生成不是替换一两个文件那么简单它引入了“如何复现”的学习成本。团队里至少要有一两个人能看得懂生成脚本否则遇到问题没人兜底。第四问生成结果是否让团队愿意review如果生成出来是一坨几乎没法看的东西那即使功能正确长期协作成本也吃不消。可读性是硬指标。这四个问题对应的不是“行不行”而是“值不值”。代码生成从来不是银弹但它特别适合那些结构重复、变化收敛、团队愿意交付出少量维护成本的领域。6.2 几个正在出现的趋势和新思路最近几年元编程的落地方案明显在往“把意图交给描述、把重复交给机器”的方向走。声明式配置、领域描述语言、编译期源码生成机制都在降低代码生成的使用门槛。我观察到的一个一致趋势是很多团队不再把生成物当成“一次性的鸡肋”而是当成一份可追溯的资产配合模板、输入数据、版本管理一起维护。当然趋势归趋势落地方案还是要看项目形态。像我们这种以数据表结构为核心的场景用模板式生成永远是最直观的起点等哪天需要更精细的源码级改造再去研究语法树变换也不迟。在元编程的路上第一原则始终是让代码去写代码但最终还要保证写出来的代码能被普通人读懂。最后想分享一个小技巧别一上来就设计一个“万能生成器”。我第一次写生成脚本也只敢从最痛的两张表开始逻辑写得很直接跑了几天确认能覆盖日常场景再逐步把类型映射和特殊字段处理抽出来通用化。一个小而可靠的生成器永远比一个看起来全面但没人敢碰的“元框架”更有价值。亲手把重复代码变成模板数据之后你会对“程序操作程序”这件事有一种很奇妙的掌控感这也是我在代码生成与元编程这条路上最大的收获。