3.4 动态代码生成

3.4 动态代码生成

本节摘要：动态代码生成让程序在运行现场制造新代码并立即投入使用。本节拆解它的三条实现路径——字符串求值、字节码操作、生成源码再编译——比较三者的表达力与校验缺口，并用"运行期拼装校验器"案例走通从需求到产物到排错的完整闭环。

把生成搬进运行期的三条路径

编译期宏回答的问题是"这段代码该怎么展开"，动态生成回答的问题更进一步："程序跑起来之后，才发现需要一段还不存在的代码，怎么办"。规则由配置下发、字段结构在运行期才知道、接口要用代码现场补齐——这些场景里编译器爱莫能助，只能让程序自己当自己的代码工厂。

工厂有三条生产线，产出物的"检验严格度"依次不同。

图：三条生成路径与各自的校验缺口

一、字符串求值：最快也最危险的直线

Python 的 eval 与 exec 是路径一的代表：一个表达式字符串，交给求值器，出来一个结果或一段副作用。用它演示"运行期拼装校验器"最直观。

背景：数据接入平台要按租户下发的校验规则过滤字段，规则形如"age 介于 0 与 150 之间""email 含有效符号"，租户可以随时增删。规则的组合方式无法穷举，编译期写死不现实。

操作：把每条规则翻译成表达式字符串，运行期拼装为一个校验函数。

RULES = ["0 <= record['age'] <= 150", "'@' in record['email']"]

def build_validator(rule_strings):
    body = "\n".join(f"    if not ({r}):" for r in rule_strings)
    source = (
        "def validate(record):\n"
        + body +
        "\n        return False, " + repr(rule_strings) +
        "\n    return True, None"
    )
    namespace = {}
    exec(source, namespace)        # 编译并执行，函数进入 namespace
    return namespace["validate"]

validate = build_validator(RULES)
print(validate({"age": 30, "email": "a@b.com"}))   # True, None
print(validate({"age": 300, "email": "a@b.com"}))  # False, [规则清单]
​

结果：校验逻辑随租户配置即时变化，改规则不用发版。解读：这条直线快在"少"——没有中间产物、没有编译环节；危险也在"少"——字符串没有经过任何一道检查，语法错误、名字拼错、甚至注入的恶意表达式，全部要到执行一刻才暴露。所以工程铁律是：进入字符串的配置必须先过白名单校验（只允许字段名、比较符、数字与逻辑连接词），绝不允许把外部输入原样拼进代码。变式：把规则换成抽象条件对象、用 ast 模块先解析再放行（即 3.3 的三段式），安全边界立刻清晰——这条变式值得在真实项目里优先采用。

二、字节码操作：给方法体动手术

路径二不再生成文本，直接在指令层面构造或改写方法体。Java 动态代理是最亲民的形态：给一组接口，运行时产出实现类，方法调用被统一转发到处理器。

Handler handler = (obj, method, args) -> {
    long start = System.nanoTime();
    Object result = method.invoke(target, args);   // 转发给真实对象
    System.out.println(method.getName() + " 耗时纳秒: " + (System.nanoTime() - start));
    return result;
};
Service proxied = (Service) Proxy.newProxyInstance(
        loader, new Class[]{Service.class}, handler);   // 运行期生成实现类
​

操作→结果：proxied 是一个运行期凭空造出的类实例，它把接口的每个调用先送进统计逻辑再转发。解读：这类技术的价值在批量与无侵入——不改动任何业务类，就能为一批接口统一织入日志、事务、重试；代价是"手术"在字节码层进行，类型错误绕过了编译器，产物只能靠虚拟机校验器与测试兜底。第五章的 AOP 一节会把这条路径的工程化封装（切面声明、织入时机）完整展开。

三、生成源码再编译：留档的生成

路径三介于两者之间：程序在运行期拼出完整的源码文本，然后调用动态编译接口（或落到磁盘后纳入下一次构建）把它变成可执行产物。模板引擎按数据模型生成页面代码、协议工具按接口描述生成编解码函数，都是这条线的变体。

它的独特价值是产物可读可留档：生成的是普通源码，能进版本库、能被评审、出错时报错行号指得到——三个路径里唯一能让"生成的代码"接受与手写代码同等待遇的一条。代价也明确：要走完整编译流程，首次生成的延迟高，不适合响应单次请求的热路径。工程上常见的折中是预生成：把生成步骤从运行期提前到构建期（正是 2.3 演练里 Go 代码生成方案的思路），运行期只加载现成产物。

三条线走完，本节开头的"选线口诀"已经不需要再解释——它是三条路径特性的自然推论。

本节要点回顾

• 适用问题：规则与结构在运行期才能确定的场景，是动态生成不可替代的领地。
• 三条路径：字符串求值最快最险，字节码操作批量无侵入但绕过编译器，生成源码再编译可读可留档。
• 校验缺口：路径一零检查，路径二靠虚拟机校验，路径三延迟可捕获——缺口位置决定测试策略。
• 安全铁律：生成逻辑的输入必须与代码输入隔离，白名单校验是底线配置。
• 预生成折中：把生成提前到构建期，运行期只加载产物，兼得灵活与稳定。

生成出来的代码是对的吗？编译期有类型检查把关，运行期靠什么验证？下一节手推一次编译期计算，把"验证前移"的思想推到极致——在编译完成之前，就让结果确定下来。