编译时与运行时的分界线：静态与动态的决策

说实话，我刚入行那会儿，对「编译时」和「运行时」的边界特别模糊。写 C++ 的时候，虚函数调用到底是在哪个阶段决定的？反射又是怎么回事？这些问题困扰了我很久。

后来我慢慢明白了。这条分界线，说白了就是「什么时候做决定」的问题。

编译时确定 vs 运行时确定

先看一个最简单的例子：

int a = 10;
int b = a + 5;   // 编译时能确定 b 的值吗？

嗯，这里要注意。如果编译器足够聪明，它确实能在编译时算出 b 是 15。但如果是这样：

int a = get_user_input();
int b = a + 5;   // 编译时能确定吗？

显然不行。因为 get_user_input() 的结果只有运行时才知道。

我个人习惯把决策时机分成三类：

决策时机	特点	典型场景
编译时	确定、高效、不可变	静态类型检查、常量折叠、模板实例化
链接时	半确定、可优化	函数内联、死代码消除
运行时	灵活、动态、有开销	虚函数、反射、动态加载

典型的分界案例

1. 虚函数与动态绑定

虚函数是理解「静态 vs 动态」的绝佳案例。你想想看：

class Animal {
public:
    virtual void speak() { cout << "Animal speaks"; }
};

class Dog : public Animal {
public:
    void speak() override { cout << "Dog barks"; }
};

void make_speak(Animal* animal) {
    animal->speak();  // 这里调用哪个？

我在项目中遇到过好几次这样的 bug。有人以为 make_speak 里调用的肯定是 Animal::speak，结果传了个 Dog 对象进去，输出完全不一样。

为什么会这样？因为虚函数走的是动态绑定。编译器在编译时并不知道 animal 指向的具体类型，它只能生成一段代码：去虚函数表（vtable）里查一下，找到真正的函数地址再调用。

2. 反射

反射是另一个极端——几乎全是运行时决策。Java 的反射、C# 的反射、Python 的 getattr，本质上都是在运行时「问」对象：你有哪些方法？你有哪些属性？

// Java 反射示例
Class<?> clazz = Class.forName("com.example.MyClass");
Method method = clazz.getMethod("doSomething");
method.invoke(obj);  // 运行时才知道调用哪个方法

我记得有一次维护一个老系统，里面大量使用反射来做依赖注入。每次启动都要花 3 秒扫描所有类。后来我建议改成编译时注解处理器，启动时间降到了 0.5 秒。

反射的代价很明显：

• 类型安全没了——编译时检查不到
• 性能开销大——字符串查找、权限检查
• 代码可读性差——跳转困难

但反射也有不可替代的优势。比如写 ORM 框架、序列化工具、插件系统，没有反射几乎寸步难行。

3. 动态绑定 vs 静态绑定

除了虚函数，还有更常见的动态绑定场景：

// JavaScript 的动态绑定
function greet() {
    console.log(this.name);
}

const obj1 = { name: "Alice", greet };
const obj2 = { name: "Bob", greet };

obj1.greet();  // "Alice"
obj2.greet();  // "Bob"

你看，同一个函数，绑定到不同对象上，行为完全不同。这在编译时根本没法确定。

分界线的本质

说到底，编译时与运行时的分界线，就是「信息何时可用」的问题。

编译时能拿到全部源码信息，可以做全局优化、类型检查、代码生成。运行时才能拿到输入数据、用户交互、网络状态，这时候的决策必须灵活。

我个人的经验是：

• 框架、库、基础设施代码——尽量编译时确定，性能优先
• 业务逻辑、插件、配置——适当运行时确定，灵活性优先
• 两者之间——用接口、抽象类、策略模式做隔离

---

公众号:蓝海资料掘金营，微信deep3321