2.1 时间维度分类

2.1 时间维度分类

本节摘要：同样叫"生成代码"，发生在编译期和发生在运行期是两门完全不同的技术。本节把程序生命周期切成编译、链接、加载、运行四个窗口，逐一说明每个窗口里能做哪些元操作、受什么约束，并论证一条贯穿全书的不对称规则：编译期可做的事，运行期未必能做；运行期可做的事，编译期往往做得更早、更省、更安全。

为什么时机是第一属性

给元技术分类有很多切法，但"发生在哪个阶段"必须排第一，原因在于：时机决定了代码表示的精细程度。越早的阶段，代码越接近结构化形态（语法树、符号表、类型信息）；越晚的阶段，代码越固化成机器友好的形态（字节码、机器码），可安全改造的空间越小。时机还决定了错误的暴露成本——编译期发现的展开错误零运行代价，运行期的动态生成错误则直接砸在生产环境里。

图：程序生命周期中的四个元操作窗口

一、编译期：信息最少、自由度最大的窗口

编译器工作在源码世界：它能看到全部语法树、类型声明、常量定义，看不到任何运行时输入。这个窗口的元操作围绕"在编译时算出结果或生成代码"展开。

C++ 模板实例化是代表。编译器遇到 Factorial<5>，会真的执行一轮递归实例化把值算出来，产物直接写进目标文件。Zig 把这条路推平了：任何标记为编译期已知的参数都能参与任意计算，普通函数即可在编译期调用，不再需要独立于语言之外的模板子系统。

编译期窗口的约束同样清楚：所有决策必须只依赖编译时可见的信息。想根据"用户登录时传了什么参数"来生成校验代码？编译器一无所知。这条约束决定了编译期元编程的用武之地——它擅长消灭"随类型、随平台、随配置而重复"的代码，对"随运行时数据而变化"的逻辑无能为力。

二、链接期与加载期：两个容易被忽略的中间窗口

链接器把多个编译产物拼装成可执行文件，工作对象是符号。这个窗口的元操作比较克制但相当实用：符号替换（用测试桩替换真实实现）、插桩（链接时把每个函数入口换成带统计的版本）、按配置裁剪（把未选中的实现模块直接排除出最终产物）。它的粒度粗——只能整体替换符号，不能改写函数内部逻辑——但正因粒度粗，风险也小。

加载期属于带虚拟机或运行时的语言。Java 的类加载机制是最典型的舞台：类从字节码读入内存时，代理与增强框架会趁机改写字节码，为方法织入事务、日志、权限检查逻辑。Python 的 import 系统同理，import 钩子可以在模块加载时替换或包装模块内容。

加载期窗口的价值在于折中：它既见得到全局结构（哪些类、哪些方法），又发生在业务流量到来之前。代价是字节码改写技术门槛高、调试困难，且改写产物必须通过虚拟机校验器，否则直接拒绝加载。这个窗口是第五章 AOP 的主战场，届时会拆开细讲。

三、运行期：信息最全、代价最高的窗口

运行期窗口里，程序手里握着一切：当前对象的真实类型、参数的实际值、调用栈的完整轨迹。反射 API、动态代理、eval、元类都工作在这里。它的不可替代性也很明确——凡是依赖运行时数据才能决策的元操作，只能发生在这里。

一个对照实验可以说明时机差异的实际影响。需求：根据配置文件里列出的类名，构造对象并调用其处理方法。

# 运行期方案：Python 反射，配置一来就生效
import importlib

def run(handler_name, payload):
    module_path, _, cls_name = handler_name.rpartition(".")
    cls = getattr(importlib.import_module(module_path), cls_name)  # 运行期查类
    handler = cls()                 # 运行期构造
    return handler.handle(payload)  # 运行期调用
​

同样的需求若要在编译期解决（以 C++ 为思路参照），类名清单必须写死在源码里，编译器据此生成注册代码——新增处理器必须重新编译。两种方案没有绝对优劣，取舍维度恰好是时机的三笔账：灵活性（运行期改配置即生效，编译期要重编译）、安全性（编译期能在构建阶段验证类名合法性，运行期拼写错误要到线上才炸）、性能（编译期产物零查询开销，运行期反射有固定成本）。

解读这组对照可以提炼出本节的收束规则：元操作能放多早就放多早，运行期窗口留给真正需要运行时信息的操作。团队代码评审里，看到一个"其实编译期常量就能解决"的运行期反射调用，就值得问一句：这笔灵活性利息，我们真的在用吗？

一个工程现场的时机误用与纠正

一次真实的归因复盘能说明"选错窗口"的代价。某网关项目为支持动态路由规则，把规则匹配逻辑做成了运行期表达式求值——每条请求都要走一遍字符串解析与求值。压测时吞吐只有预期的一半，团队起初怀疑是网络与序列化，性能剖析显示热点竟在表达式求值器里。

排查→纠正：规则其实"每次部署才变一次"，却按"每条请求都可能变"来设计——把本可放到编译与部署期的东西推迟到了最贵的运行期窗口。改造分两步：把规则编译成匹配函数的动作挪到部署时刻（相当于预生成），运行期只查路由表直调；确需热更新的少量规则保留求值路径但加缓存。改造后吞吐回到预期。

这个案例的推论值得记牢：判断时机选得对不对，只需问"这个决策的输入，最频繁多久变一次"。输入按部署变的，别按请求处理；输入按请求变的，也别逞强放到编译期。三个窗口的选型纠结，几乎都能用这条频率匹配原则裁决。

本节要点回顾

• 时机决定表示：越早的窗口代码越结构化、可安全改造的空间越大，越晚越固化。
• 编译期：消灭"随类型与配置重复"的代码，代价是拿不到任何运行时信息。
• 链接期与加载期：符号替换与字节码织入，是粒度与灵活性的中间地带，业务流量前完成是它的最大优势。
• 运行期：唯一能基于运行时数据决策的窗口，灵活性、安全、性能三笔账都要现场付。
• 选型规则：元操作能放多早就放多早，推迟到运行期必须有运行时信息依赖作理由。

时间轴立完了。下一节转到能力轴：同样是"操作代码"，只读地看一眼和动手改一刀，是两种强度完全不同的元能力。