C++编译期多态全解析：模板、特化与静态分派实战

我最早意识到“多态”这个词在 C++ 里有多容易让人产生误解，是几年前给一个网络网关程序做性能剖析的时候。当时有个数据字段需要按类型分发给不同的处理函数，第一版图省事用了基类加虚函数，结果用 perf 一量，发现这个分派点占了不少开销。改成模板加特化之后，同样逻辑跑出来快了接近一倍。从那时候起我在代码评审里就格外关注一个问题：这里的分派，真的必须发生在运行期吗？

C++ 的编译期多态，简单说就是把“调用谁、用哪个实现、走哪个分支”这些决策，尽量提前到编译阶段定死。它跟运行期多态（虚函数）是两条完全不同的技术路线：前者靠模板、重载决议、constexpr、特化这些机制，后者靠 vtable 和 vptr 在运行时查找。两者没有绝对的好坏，但各有各的适用场景。这篇文章我打算把编译期多态的核心手段、选型理由、实际写法和踩过的坑完整梳理一遍，适合刚接触模板元编程的读者，也适合那些已经在用但还没系统整理过这套思路的朋友。

1. 运行期多态的“隐藏成本”：虚表、间接跳转和优化盲区

1.1 虚函数调用到底慢在哪

很多初学者以为虚函数只是“多一次指针跳转”，这个认知不能说错，但严重低估了它对编译器优化的影响。我们来看一个典型场景：

cpp复制class Shape {
public:
    virtual double area() const = 0;
    virtual ~Shape() = default;
};

class Circle : public Shape {
    double r_;
public:
    explicit Circle(double r) : r_(r) {}
    double area() const override { return 3.14159265358979 * r_ * r_; }
};

class Square : public Shape {
    double s_;
public:
    explicit Square(double s) : s_(s) {}
    double area() const override { return s_ * s_; }
};

double total_area(const std::vector<Shape*>& shapes) {
    double sum = 0.0;
    for (auto* s : shapes) {
        sum += s->area();
    }
    return sum;
}

这段代码每次执行 s->area()，CPU 都要做这样几步：

1. 从对象地址取出 vptr（虚表指针），通常偏移在对象起始位置。
2. 根据 vptr 找到 vtable。
3. 在 vtable 里按偏移取函数地址。
4. 间接跳转并调用。

也就是说，一个 area() 调用背后实际发生了“取指针 -> 寻址 -> 再取指针 -> 跳转”这么一串动作。比起直接 call _ZN6Circle4areaEv 这种静态调用，指令数多了好几条，还会打断 CPU 的分支预测管线。

但真正致命的影响在于优化。编译器看到 s->area() 时，由于 s 可能是任意派生类的对象，它没办法把 area() 的内联版本塞进来。虚函数几乎无法跨编译单元内联，这是运行期多态在性能敏感场景里最大的软肋。反过来，模板在编译期实例化之后，编译器看到的是一份普通函数，内联、常量折叠、循环展开这些优化全部可以正常做。

1.2 哪些场景必须用运行期多态

这不是说虚函数一无是处。我自己在项目里对“必须用虚函数”的判断标准很简单：类型集合在运行时才能确定，或者需要在运行时动态加载新的实现。

典型场景包括：

• 插件体系：主程序在启动时扫描 .so / .dll，通过统一接口调用插件实现。这组接口的类型集合编译期根本不知道，只能用虚函数。
• 消息/事件分发：消息类型可能由配置或外部输入决定，前置类型空间无法枚举完整。
• 运行时依赖注入：某些框架里组件之间的绑定关系是在启动阶段根据配置文件决定的。
• 跨语言边界（比如 C ABI 包装 C++）：需要一组稳定不变的接口，模板无法直接跨边界暴露。

在这些场景下，虚函数的那点性能开销完全可以接受，因为“灵活”本身就是刚需。

1.3 编译期多态的优势清单

我把两种方案摊开对比一下，不光是性能，还包括代码表达层面：

一句话总结：编译期多态解决的是“在设计期就知道类型全集”情况下的高效分派问题。写出来的代码更贴近“类型安全”和“零开销抽象”这两个 C++ 的核心设计目标。

2. 模板实例化与重载决议：编译器手里的双王牌

2.1 函数模板：编译器在编译期为你“定制”函数

模板并不是一套“运行时会自己判断类型”的魔法，它的本质是代码生成模板。当你在代码里写出：

cpp复制template <typename T>
T my_max(T a, T b) {
    return a > b ? a : b;
}

然后分别调用 my_max(3, 5) 和 my_max(3.14, 2.71) 时，编译器实际上生成了两份不同的函数，一份参数是 int，一份参数是 double。你在汇编层面看到的，跟手写 int my_max(int, int) 和 double my_max(double, double) 没有任何区别。这就是“零开销抽象”的底气：不用的抽象不留痕迹，用到的抽象全部展开成直接代码。

这里有个新手常忽略的细节：模板的实例化是按需进行的。你写了模板不调用，编译器通常不会真正生成代码。只有遇到具体调用时，才会去实例化对应类型版本。所以模板函数和类模板的声明、定义通常要放在同一个头文件里，否则链接阶段会报“undefined reference”。

2.2 重载决议规则：精确匹配优先与 SFINAE

除了模板，函数重载也是编译期多态的重要工具。编译器在做重载决议时有一套复杂的匹配规则，核心顺序大致是：

1. 精确匹配（类型完全一致或仅含顶层 const、引用等无害转换）。
2. 模板推导（如果可以生成一个匹配的模板实例）。
3. 提升/标准转换（比如 int 到 long、派生类到基类）。
4. 用户自定义转换。

你可能会问：模板和普通函数同时存在时会选谁？答案是：如果非模板函数参数类型完全匹配，非模板优先。这个规则在很多库里被用来做“特化钩子”——提供一个普通函数作为默认行为，再用模板处理其他类型。例如：

cpp复制void handle(int x);                 // 完全匹配 int
template <typename T>
void handle(T x);                   // 兜底

handle(42);    // 调用非模板版本
handle(3.14);  // 调用模板版本

更进阶的玩法是 SFINAE（Substitution Failure Is Not An Error，替换失败不是错误）。它允许你在模板参数推导过程中，如果某个类型不满足特定条件，就让这个模板直接出局，从而让重载决议选到另一个更合适的版本。C++11 之后常用 std::enable_if 配合实现：

cpp复制template <typename T>
auto process(T v) -> std::enable_if_t<std::is_integral_v<T>, void> {
    // 整数类型走这里
}

template <typename T>
auto process(T v) -> std::enable_if_t<std::is_floating_point_v<T>, void> {
    // 浮点类型走这里
}

process(1);       // 整数版本
process(2.5);     // 浮点版本
process("abc");   // 两个版本都替换失败，编译报错

这段代码的精髓在于：std::enable_if_t 后面的 bool 条件如果不成立，模板参数推导就会失败，但注意这种失败不会引发编译错误，而是让这个候选被悄悄移除。两个候选都不是，编译器才会报 no matching function 的错误。

2.3 模板 + 重载组合的实战写法

实际项目里，模板和重载经常是配合着用的。拿我自己做序列化库的例子来说明。需求是：一个 serialize 函数，对于内置类型、std::string、自定义类型分别走不同的逻辑。

第一版我用的是 if constexpr（后面会详细讲），但早期代码用了 enable_if：

cpp复制template <typename T>
std::enable_if_t<std::is_arithmetic_v<T>>
write_value(Buffer& buf, T value) {
    buf.append(reinterpret_cast<const char*>(&value), sizeof(T));
}

void write_value(Buffer& buf, const std::string& str) {
    buf.append(str.data(), str.size());
}

template <typename T>
std::enable_if_t<!std::is_arithmetic_v<T> && !std::is_same_v<T, std::string>>
write_value(Buffer& buf, const T& obj) {
    obj.serialize(buf);
}

注意第三个模板的 enable_if 条件，必须把前两个版本排除掉，否则调用 write_value(buf, std::string("hello")) 时，第三个模板也会参与重载决议，导致歧义。这类因模板参与过度而导致的编译歧义，是我见过最多的模板 bug 之一。排查时一旦看到“ambiguous call to overloaded function”，优先检查是不是某个模板的约束条件没有排除掉不该它管的类型。

3. if constexpr 与 constexpr 函数：让分支在编译期就尘埃落定

3.1 constexpr 家族的演进与用法边界

constexpr 这个关键字从 C++11 引入，C++14 大幅放宽（允许循环、局部变量），C++17 加入 if constexpr，C++20 又补上了 consteval 和 constinit。它族的边界在于：所有在编译期可求值的表达式，都可以用 constexpr 标记，从而让编译器在编译阶段就算出结果。

一个最常见的误解是：constexpr 函数必须所有参数都在编译期常量时才能调用。不对。constexpr 函数在运行期和编译期都可用，区别在于如果所有实参都是常量表达式，且在编译期能求出结果，就会被编译期求值；否则退化为普通函数调用。举例：

cpp复制constexpr int square(int x) { return x * x; }

constexpr int a = square(5);   // 编译期算好，a 是常量
int b = 5;
int c = square(b);             // 运行期调用，因为 b 不是常量表达式

这个双态行为非常实用。我们在写数学工具时，经常用 constexpr 函数同时满足“编译期常量表”和“运行期快速计算”两种需求，一份代码两个用途。

3.2 if constexpr 的求值机制与非选中分支的“不实例化”

if constexpr 是 C++17 给模板编程带来的最大礼物。它的核心特性是：条件在编译期求值，未选中的分支不参与实例化。这意味着你可以把一些“类型不合法”的代码写进 false 分支，编译器不会去管它——这在普通 if 里是做不到的。

举个例子，这是典型的“递归终止”写法：

cpp复制template <typename T>
std::string type_name() {
    if constexpr (std::is_same_v<T, int>) {
        return "int";
    } else if constexpr (std::is_same_v<T, double>) {
        return "double";
    } else {
        return "unknown";
    }
}

如果这里用普通 if，三个分支的返回语句都会被编译，std::is_same_v<T, int> 只是个运行期 bool，两个分支的代码照常生成。但由于返回值类型都是 std::string，这个例子不会报错。真正体现威力的是下面的场景：

cpp复制template <typename T>
void print_value(const T& v) {
    if constexpr (std::is_pointer_v<T>) {
        std::cout << *v;   // 解引用操作
    } else {
        std::cout << v;
    }
}

int x = 42;
print_value(&x);  // 实例化时只编译 if 分支
print_value(x);   // 实例化时只编译 else 分支

当 T = int* 时，else 分支的 std::cout << v 其实也合法（会打印指针地址），所以这个例子不够震撼。换成 T = int 时，if 分支的 *v 是非法的，但编译器照样放过，因为整个分支根本没被实例化。这就是 if constexpr 和运行期 if 最本质的区别。

3.3 用 if constexpr 写类型分派：一个数据序列化例子

我在前面的序列化库最终改成了 C++17 的 if constexpr 写法，比 enable_if 版本可读性好太多：

cpp复制template <typename T>
void write_value(Buffer& buf, const T& value) {
    if constexpr (std::is_arithmetic_v<T>) {
        // 内置数值类型直接按二进制写
        buf.append(reinterpret_cast<const char*>(&value), sizeof(T));
    } else if constexpr (std::is_same_v<T, std::string>) {
        buf.append(value.data(), value.size());
    } else if constexpr (requires { value.serialize(buf); }) {
        // C++20 requires 表达式检测是否有 serialize 成员函数
        value.serialize(buf);
    } else {
        static_assert(sizeof(T) == 0, "unsupported type");
    }
}

requires { value.serialize(buf); } 是 C++20 的写法，用来在编译期检测某个表达式是否合法。如果类型没有 serialize 方法，就会走到最后的 static_assert，给一个明确的编译错误提示。这比 enable_if 那一大串 ! 和 && 容易读多了。

我在生产环境用这个函数处理了几种类别差异很大的配置结构体，编译期就能确定每种类型走哪个分支，运行时零决策开销。同时因为所有分支都内联展开，编译器还能进一步优化掉不必要的拷贝和临时对象。

4. 模板特化与类型萃取：给编译器一本“类型决策手册”

4.1 全特化、偏特化与主模板的三层关系

模板编程的另一个关键能力是特化。类模板和变量模板可以“针对特定类型给出不同实现”，这实际上也是编译期多态的一种描述方式。它和运行期多态的对应关系大概是这样：主模板相当于基类的默认实现，特化相当于派生类对虚函数的覆写。

全特化和偏特化的区别要分清：

• 全特化：指定模板参数中的全部类型。例如 template <> struct Traits<int>。
• 偏特化：只限定部分类型或结构特征。例如 template <typename T> struct Traits<T*> 表示“指针类型走这个版本”。

看个标准库里的原型，std::is_pointer 的实现思路大致是：

cpp复制template <typename T>
struct is_pointer : std::false_type {};

template <typename T>
struct is_pointer<T*> : std::true_type {};

is_pointer<int>::value   // false
is_pointer<int*>::value  // true，匹配偏特化版本

std::false_type 和 std::true_type 是标准库提供的空结构体，继承它们之后，这个 traits 类就可以被当作编译期布尔值使用。

4.2 类型萃取 traits 的经典实现思路

Traits（萃取）的用处是把“类型特征”变成“编译期可查询的值或类型”。它的经典实现套路分两步：

1. 定义主模板，给一个默认答案。
2. 针对特定类型特化，覆盖答案。

我自己设计过一个简单的 serialization traits：

cpp复制// 主模板：默认不支持二进制序列化
template <typename T>
struct BinarySerializable : std::false_type {};

// 对内置算术类型特化
template <>
struct BinarySerializable<int> : std::true_type {};
template <>
struct BinarySerializable<double> : std::true_type {};
// ...

// 对 std::string 特化
template <>
struct BinarySerializable<std::string> : std::true_type {};

然后序列化函数可以这样写：

cpp复制template <typename T>
void serialize(const T& value, Buffer& buf) {
    static_assert(BinarySerializable<T>::value,
                  "This type does not support binary serialization");
    // 具体实现...
}

由于 static_assert 的断言失败会直接给出类型名和错误信息，比模板内部爆出一堆无关报错要友好得多。写库给团队其他人用时，这类显式断言几乎是必备的——它把复杂的模板错误压缩成一个可读的提示。

4.3 定制自己的类型特征：一个缓存策略的案例

类型萃取并不只能跟标准库的 is_xxx 绑定。我们项目里有一个缓存组件，不同数据类型需要不同的缓存策略：int 用 LRU + 固定容量，std::string 用容量按需扩展，自定义结构体默认拷贝存储。用 traits 来表达这种差异特别自然：

cpp复制template <typename T>
struct CachePolicy {
    static constexpr bool fixed_capacity = false;
    static constexpr size_t init_capacity = 16;
};

template <>
struct CachePolicy<int> {
    static constexpr bool fixed_capacity = true;
    static constexpr size_t init_capacity = 1024;
};

template <typename T>
class Cache {
    static constexpr size_t capacity = CachePolicy<T>::init_capacity;
    // 根据 fixed_capacity 选择内部容器
};

这种以“类型 -> 策略”映射的方式，跟虚函数相比省掉了对象里的 vptr，也省掉了每次查询策略时的跳转。策略之间的差异是在编译期直接“写死”在类型里的，后续逻辑全凭模板查询。

5. CRTP：不花一分钱虚表开销的“静态继承”

5.1 CRTP 的形态与绑定时机

CRTP（Curiously Recurring Template Pattern，奇异递归模板模式）是这么一种形态：

cpp复制template <typename Derived>
class Base {
public:
    void interface() {
        static_cast<Derived*>(this)->implementation();
    }
};

class DerivedA : public Base<DerivedA> {
public:
    void implementation() { /* A 的实现 */ }
};

关键在于：Base<DerivedA> 实例化时，Derived 被确定成 DerivedA，所以 static_cast<Derived*>(this) 在编译期就能解析出 DerivedA 的 implementation 地址。这跟虚函数的区别在于——整个过程不需要 vptr，不需要 vtable，不需要运行期跳转。调用 interface() 时，编译器看到的是一个对内联友好的直接调用链。

5.2 用 CRTP 实现编译期接口约束与代码复用

CRTP 最常见的用途是“模板方法模式”的静态版本。运行期版本大概长这样：

cpp复制class Base {
public:
    void execute() {
        step1();
        step2();
    }
    virtual void step1() = 0;
    virtual void step2() = 0;
};

子类必须实现 step1 和 step2。换成 CRTP 后：

cpp复制template <typename Derived>
class ExecuteBase {
public:
    void execute() {
        static_cast<Derived*>(this)->step1();
        static_cast<Derived*>(this)->step2();
    }
};

class JobA : public ExecuteBase<JobA> {
public:
    void step1() { /* ... */ }
    void step2() { /* ... */ }
};

再看调用端：

cpp复制template <typename T>
void run_job(T& job) {
    job.execute();  // 编译期确定调用目标
}

JobA job;
run_job(job);

所有调用都在编译期完成解析，没有虚函数开销。如果你写的是高性能计算或游戏引擎的帧循环，这类场景下的函数往往会被非常频繁地调用，省掉间接跳转的收益累积下来非常可观。

5.3 CRTP 的多个派生类协作场景

CRTP 还有个常用场景是实现“静态多继承”式的功能注入。在事件系统里，我们想让多种事件类型都具备“获取类型名、克隆自身、输出日志”的能力，但每种事件实现不同。用 CRTP 注入公共逻辑：

cpp复制template <typename Derived>
class EventBase {
public:
    const char* type_name() const {
        return static_cast<const Derived*>(this)->type_name_impl();
    }

    std::unique_ptr<Derived> clone() const {
        return std::make_unique<Derived>(*static_cast<const Derived*>(this));
    }

protected:
    ~EventBase() = default;  // 防止通过基类指针删除
};

class ClickEvent : public EventBase<ClickEvent> {
public:
    const char* type_name_impl() const { return "ClickEvent"; }
    int x_ = 0, y_ = 0;
};

clone() 在这里通过 std::make_unique<Derived> 返回了精确类型，不需要基类引用的 downcast，也没有虚函数。这让事件工厂在编译期就知道每种事件实例要 creation 什么类型。

有一个坑我必须提醒：CRTP 基类的析构函数如果是 public，并且 delete 发生在基类指针上，而基类没有虚析构函数，就会触发未定义行为。我在项目里踩过一次，排查了好久。推荐做法是基类析构函数声明为 protected，从结构上杜绝通过基类指针删除派生类对象。

6. std::variant 与 std::visit：数据驱动的编译期分派

6.1 variant 替代 union 的底气

std::variant 从 C++17 进入标准库，本质是一个“类型安全的联合体”。它可以在编译期“记住”当前存储的是哪个类型，然后让访问者在编译期就知道所有可能类型的全集。

基本用法：

cpp复制#include <variant>
#include <string>

using Value = std::variant<int, double, std::string>;

Value v1 = 42;
Value v2 = 3.14;
Value v3 = std::string("hello");

它跟 C 语言 union 的区别在于：variant 会记录当前活跃类型，不会让你把 int 当 double 读出来。访问时要么用 std::get（可能抛异常），要么用 std::visit（编译期分派）。

6.2 visit 的“表驱动”本质

std::visit 的机制很有意思：编译器在遇到 std::visit(visitor, variant) 时，会生成一段根据 variant 内部索引进行跳转的代码。但注意，这个跳转和虚函数跳转不一样——visit 的跳转表是编译期生成的，而且跳转之后的代码是内联的，每个类型对应的 lambda 都会单独优化。

具体写法：

cpp复制auto print_value = [](const auto& v) {
    std::cout << v << '\n';
};

std::visit(print_value, v1);

这里用的是泛型 lambda，相当于把“所有类型都做同一件事”的访问逻辑写一份。如果不同类型要做不同事情，可以用重载技巧：

cpp复制template <typename... Fs>
struct Overloaded : Fs... {
    using Fs::operator()...;
};

// C++17 类模板参数推导，让 Overloaded 可以直接用
template <typename... Fs>
Overloaded(Fs...) -> Overloaded<Fs...>;

std::visit(
    Overloaded{
        [](int x) { std::cout << "int: " << x << '\n'; },
        [](double x) { std::cout << "double: " << x << '\n'; },
        [](const std::string& s) { std::cout << "string: " << s << '\n'; },
    },
    v1
);

这个 Overloaded 模式利用包展开和 using 声明让多个 lambda 的 operator() 变成重载集合，从而在编译期决议出匹配的版本。它跟 if-else 链相比，少了手写分支和类型判断，编译器生成的代码也更规整。

6.3 AST 节点求值器：一个真实的分派场景

我在一个简单脚本解释器项目里用过 variant + visit 做 AST 求值。AST 节点分为字面量、二元运算、变量引用等几种，分别有不同的求值逻辑：

cpp复制using Expr = std::variant<int, BinOp, VarRef>;

struct BinOp {
    char op;
    Expr left;
    Expr right;
};

struct VarRef {
    std::string name;
};

struct Evaluator {
    std::unordered_map<std::string, int> env;

    int operator()(int v) const { return v; }

    int operator()(const VarRef& ref) const { return env.at(ref.name); }

    int operator()(const BinOp& bin) const {
        int l = std::visit(*this, bin.left);
        int r = std::visit(*this, bin.right);
        switch (bin.op) {
            case '+': return l + r;
            case '-': return l - r;
            case '*': return l * r;
            case '/': return l / r;
            default: return 0;
        }
    }
};

int eval(const Expr& expr) {
    return std::visit(Evaluator{}, expr);
}

这里 std::visit(*this, bin.left) 在编译期会展开成对每种 Expr 可能类型的调用，而 Evaluator 里每个 operator() 又构成重载决议的候选。整套逻辑没有 vtable，没有运行时类型标识（RTTI），类型集合在设计期就固定，编译器也能把整个求值过程优化得很干净。

7. 编译期多态的取舍与踩坑总结

7.1 三张表做决策：什么时候值得用

我在做技术选型时习惯拿三张表对照：

第一张表：性能敏感度。

第二张表：类型空间是否封闭。

第三张表：代码维护性。

7.2 代码膨胀与编译时间

模板实例化有代价：每一种参数组合都会生成一份独立代码。如果你在一个模板函数里使用了 n 种类型，再把这个模板组合进 m 种容器，理论上可能产生 n × m 份实例化代码。这就是所谓的“代码膨胀”。

我处理这个问题时常用的手段有几种：

• 把类型无关的逻辑抽成非模板普通函数，模板只做薄薄一层类型适配。
• 如果某个模板的二进制重复率很高，可以用 extern template 和显式实例化来控制实例化位置，减少重复编译。
• 对容器类，考虑用“类型擦除”降低泛化程度，在膨胀和灵活性之间找平衡点。

编译时间膨胀在 C++20 引入 concepts 之后有所缓解，但模板本身就是“编译期干活”，工具链花在实例化和类型检查上的时间天然比非模板代码多。大型项目里可以上分布编译缓存，或者把模板相关的改动限制在依赖链上游的少量模块里。

7.3 错误信息可读性与调试技巧

编译期多态的经典痛点就是报错信息。遇到一个深层嵌套模板里的类型不匹配，编译器能给你刷出几百行错误，最初的报错原因往往藏在第一屏之外。

我的排查经验是：

1. 先找第一条报错里的“required from here”，那通常是最终调用点。
2. 从后往前看，找出第一个真正描述类型冲突的地方，而不是中间的“in instantiation of”重复行。
3. 把模板参数逐个摘出来，小范围构造最小复现，定位是哪一层约束不满足。
4. 依赖 static_assert 在关键入口做类型前置校验，把错误提前拦在入口处。

调试方面，编译器对模板实例化了什么，可以在编译命令里加 -fopt-info（GCC 系列）看优化信息，或者用 -ftime-report 看模板实例化耗时分布。更直接的方式是在代码里临时加 static_assert(std::is_same_v<T, 期望类型>, "check"); 来验证 T 的实际推导结果。

7.4 我的选型原则

最后说点个人经验。这几年写下来的体会是：不要为了炫技而用编译期多态，但一旦确定性能敏感且类型空间封闭，就大胆用。它的收益非常实在：内联机会、零间接跳转、类型约束前置到编译期、错误能更早暴露。代价则是编译时间、代码膨胀和更陡的学习曲线。

我在实际项目里的习惯是：

• 库的公共接口尽量保持简单，把复杂的模板细节藏在内部实现里。
• 团队新成员不熟悉模板时，先用 if constexpr 和 traits 这类“局部编译期分派”过渡，等熟悉了再引入 CRTP 和 variant visit 这类更重的模式。
• 每次引入编译期多态时，都要问自己一句：如果这里从模板改成虚函数，成本是多少？如果虚函数版本的可读性和维护性明显更好，而性能差距又测不出来，我会选虚函数。多态的终极目标不是秀技术，而是用最合适的代价解决实际问题。

如果你正在优化自己的 C++ 项目，建议先从 perf 或者火焰图找出最热的调用路径，看那里有没有 vtable 间接跳转，再决定要不要替换成编译期方案。实测数据永远比理论推断更有说服力。