C++ constexpr从入门到实战：编译期计算、查找表与字符串哈希

写constexpr之前，我先说一个可能颠覆认知的事实：constexpr 在 C++ 里带给你的最大价值，不是“让你的程序运行得更快”，而是“让你的程序在开始运行之前就已经把答案算好了”。这两件事听起来差不多，但代码形态、调试方式、可维护性完全是两码事。

我最早接触编译期计算，是在一个游戏引擎项目里。那时候要维护一张很大的技能伤害衰减表，运行时算需要查表插值，表是用 Python 脚本预生成再拷进工程里的。后来表结构一变，脚本和 C++ 代码对不上，定位了很久才发现是生成脚本里一个浮点舍入的差异。接手这事儿之后我就想：要是表能在编译期直接算出来，脚本那一步不就彻底干掉了吗？于是我开始认真折腾 constexpr，从 C++11 一路用到 C++20，这篇文章就当作这些折腾的记录吧。

如果你正在学 C++，或者工作中经常写算法、写 SDK、写引擎工具链，这篇文章会帮你真正理解“编译期计算”能干什么、不能干什么，以及怎么把它用到实际项目里，而不是停留在面试八股文的层面。

1. 理解 constexpr 的第一性原理：它到底改写了什么游戏规则

1.1 先破除一个常见误区：constexpr 不是“快一点的函数”

很多人第一次接触 constexpr，会把它理解成“编译器会对这个函数做优化，让它更快”。这个理解方向上就歪了。

constexpr 的本质是：它允许这个函数/变量出现在常量表达式（constant expression）中，从而在编译期就被求值。换句话说，它改变的不是运行时的速度，而是“计算发生的时机”。

运行时计算的程序长这样：

cpp复制int factorial(int n) {
    int result = 1;
    for (int i = 2; i <= n; ++i) result *= i;
    return result;
}

int main() {
    int x = factorial(10);  // 运行时算
    return 0;
}

编译期计算的程序长这样：

cpp复制constexpr int factorial(int n) {
    int result = 1;
    for (int i = 2; i <= n; ++i) result *= i;
    return result;
}

int main() {
    constexpr int x = factorial(10);  // 编译期算完，x 就是字面量 3628800
    return 0;
}

注意看，函数体几乎一模一样，区别在于调用处的限定符。constexpr int x 是一个约束：我要求 factorial(10) 必须在编译期可求值，如果求不出来，编译直接报错。而 factorial(10) 作为普通函数调用时，如果参数不是编译期常量，编译器也完全可以（在优化时）提前算出来，但这只是“优化”，不是“保证”。

constexpr 的价值在于：把“最好能算出来”变成“必须在编译期算出来，否则不让你编译通过”。这是一种契约，而不是一种性能优化提示。理解了这一点，后面所有应用场景才能想明白。

1.2 从宏到模板再到 constexpr：编译期计算工具的进化逻辑

在 constexpr 之前，C++ 程序员并不是完全没有编译期计算的手段，只是非常别扭。

早期最原始的手段是宏。宏在预处理阶段做文本替换，可以算一些简单的东西，比如 #define MAX(a, b) ((a) > (b) ? (a) : (b))。但宏的问题一大堆：没有类型检查、不能调试、多层嵌套的时候可读性灾难。用宏实现阶乘、斐波那契这种递归计算，写出来的代码基本是给后人挖坑。

后来出现了模板元编程（Template Metaprogramming）。模板是在编译期实例化的，所以你可以用模板递归实现编译期计算：

cpp复制template <int N>
struct Factorial {
    static constexpr int value = N * Factorial<N - 1>::value;
};

template <>
struct Factorial<0> {
    static constexpr int value = 1;
};

// 用法
int x = Factorial<10>::value;  // 编译期算好

这段代码能用，但它有个致命问题：写的不是“正常代码”。你用 struct、模板特化、静态成员变量去模拟函数调用，可读性一塌糊涂。一旦计算逻辑复杂起来（比如编译期做一个字符串哈希），模板元编程版本的代码会让你怀疑人生。

constexpr 的意义在于：让编译期计算用“普通函数”的语法来写。同样是阶乘，C++11 的 constexpr 版本虽然还有限制（只能写单条 return 语句），但至少看起来像函数了；C++14 放宽到可以写循环和局部变量之后，编译期计算和运行时计算的代码几乎可以完全共用一套逻辑。

这条进化路线的内在逻辑是：编译期计算需要一种“可被编译器理解和验证的确定性代码”，而普通函数是最自然的形式。宏太弱，模板太丑，constexpr 刚刚好。

1.3 编译期求值模型：constexpr 到底在什么时机被求值

这里有一个很微妙的问题：constexpr 函数是“一定在编译期求值”吗？

答案是：不一定。

constexpr 函数既能用于编译期，也能用于运行时。当你写下：

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

int a = square(5);       // 很可能编译期就算完了，但技术上不保证
constexpr int b = square(5);  // 一定在编译期算完

第一种情况下，square(5) 是“常量表达式吗”？是。但编译器不一定会真的在编译期去求值——它在语义上允许编译期求值，但具体做不做看编译器的优化决策。而第二种情况，b 是 constexpr 变量，它的初始化器必须是常量表达式，所以编译器必须在编译期算出来。

要真正“强迫”函数在编译期求值，C++20 给了你 consteval。这个关键字声明的是“立即函数”（immediate function），它只能在编译期求值。如果一个 consteval 函数被调用时参数不是编译期常量，直接编译错误，没有任何运行时兜底。

所以实际工程里，我建议的分类是：

理解了这个求值模型，你才能判断：什么时候该用 constexpr 变量去“锁定”编译期求值，什么时候用普通函数就行，什么时候该上 consteval。

2. 编译期查找表：最经典且最容易上手的实战场景

2.1 为什么查找表值得搬到编译期：运行时查表 vs 编译期算表

查找表是 constexpr 最典型的应用场景。游戏开发和嵌入式里经常会有这种需求：预先算好一张正弦表、反正切表、伽马校正表，运行时直接查。

传统做法分两种：

1. 运行时初始化：程序启动时循环算一遍，填满数组。坏处是启动时有一小段 CPU 时间被占掉；如果表很大（比如 1MB），还可能影响启动速度。
2. 离线脚本生成：如前面说的，用 Python 脚本算好，生成 .cpp 或 .h 文件。坏处是维护两套代码，脚本和 C++ 逻辑脱节。

constexpr 做法就是把表直接写在 C++ 里，由编译器算。它的好处：

• 没有运行时初始化开销，数据直接躺在二进制文件的只读段里。
• 只有一份代码，改算法只改一处。
• 表的大小、精度完全由编译期常量控制，编译器帮你算。

它真正解决的问题是：“这个数据反正是不变的，能不能别让它占用运行时的计算时间？”

2.2 实操：用 constexpr 生成正弦查找表

直接上一个我实际用过的例子。假设我们在写一个音频合成器，需要一张 4096 点的正弦波表，每帧都能快速查表而不是反复调用 std::sin。

C++14 之后写起来非常直接：

cpp复制#include <array>
#include <cmath>

constexpr int kTableSize = 4096;

constexpr std::array<double, kTableSize> make_sine_table() {
    std::array<double, kTableSize> table{};
    for (int i = 0; i < kTableSize; ++i) {
        table[i] = std::sin(2.0 * 3.14159265358979323846 * i / kTableSize);
    }
    return table;
}

// 全局只读表，编译期完成初始化
constexpr auto gSineTable = make_sine_table();

这里有两个细节值得注意。

第一，std::array 是 C++17 之前就能在 constexpr 函数里用的容器（C++20 才支持 std::vector 的编译期构造）。我用的编译标准是 C++14 以上，std::array 的 operator[] 本身是 constexpr 的，所以可以正常读写。

第二，make_sine_table() 函数体里用了局部变量 table、for 循环、i++，这在 C++11 下是不允许的——C++11 的 constexpr 函数体只能是一条 return 语句。到了 C++14，这些限制全部放宽，这也是为什么我说 C++14 是 constexpr 真正可以“用起来”的版本。

std::sin 在 C++11 里不是 constexpr 的（因为浮点环境依赖平台），所以上面的代码在某些严格编译器下可能报错。实际工程里我一般用整数多项式近似来替代标准库三角函数，或者用第三方提供的 constexpr 数学库。这里为了示例简洁用了 std::sin，你如果要复制到项目里，建议先验证一下目标编译器是否支持。

2.3 查找表的扩展用法：多维表与插值系数

一维查找表只是开始。我在项目里遇到过的场景是，需要一张二维的“距离-角度”衰减表。实现方式就是用一个二维 std::array 嵌套：

cpp复制constexpr int kDistanceLevels = 64;
constexpr int kAngleLevels = 32;

constexpr std::array<std::array<double, kAngleLevels>, kDistanceLevels>
make_attenuation_table() {
    std::array<std::array<double, kAngleLevels>, kDistanceLevels> table{};
    for (int d = 0; d < kDistanceLevels; ++d) {
        for (int a = 0; a < kAngleLevels; ++a) {
            // 这里放你的衰减公式
            table[d][a] = compute_attenuation(d, a);
        }
    }
    return table;
}

constexpr auto gAttenuationTable = make_attenuation_table();

还有一种更精细的玩法：生成查找表的同时，把“相邻采样点之间的插值系数”也编译期算好。这样运行时只需要做一次线性插值，连系数都不用算。代价是表大小翻倍，但换来了运行时极致的简单和均匀。

编译期生成查找表最舒服的一点是：算法改起来特别快。以前每次调表，要么重新跑一遍 Python 脚本，要么等程序启动时重新初始化。现在改一行公式，重新编译一下，新的二进制里就是新表，根本不存在“表忘记更新”这种问题。

3. 编译期字符串处理：哈希、解析与协议验证

3.1 用 constexpr 实现编译期字符串哈希，省掉一张 map

如果说查找表是“数值计算”的编译期应用，那字符串哈希就是“文本处理”的编译期应用。它的核心需求是：把字符串映射到枚举值，但又不想在运行时遍历一堆 if-else 或维护一张 string-to-enum 的映射表。

最常见的场景是命令行参数解析、配置项匹配、协议类型判断。传统做法：

cpp复制if (strcmp(cmd, "move") == 0) {
    // ...
} else if (strcmp(cmd, "attack") == 0) {
    // ...
}

这种方式的问题：字符串比较发生在运行时，而且代码重复，一旦命令变多，就是一长串 if-else 金字塔。模板特化或者虚函数表可以解决一部分，但代码结构并不直观。

用 constexpr 字符串哈希，可以把“比较字符串”变成“比较整数”。运行时拿到一个字符串，先算它的哈希（或者用运行时版本的同款哈希函数），然后直接 switch。核心逻辑：

cpp复制// FNV-1a 哈希的 constexpr 实现
constexpr uint64_t fnv1a(const char* str) {
    uint64_t hash = 14695981039346656037ULL;
    while (*str) {
        hash ^= static_cast<unsigned char>(*str++);
        hash *= 1099511628211ULL;
    }
    return hash;
}

// 编译期定义命令对应的哈希常量
constexpr uint64_t kCmdMove   = fnv1a("move");
constexpr uint64_t kCmdAttack = fnv1a("attack");
constexpr uint64_t kCmdHold   = fnv1a("hold");

运行时只需要：

cpp复制uint64_t h = fnv1a(cmd_str);  // 或者用加速版
switch (h) {
    case kCmdMove:   // ...
    case kCmdAttack: // ...
}

这样每新增一个命令，只需要加一个 constexpr uint64_t 常量和对应的 case。编译期帮你算好哈希值，运行时一次哈希一次 switch 就完事。

3.2 编译期字符串本身：为什么 std::string 不行，怎么绕

如果你在 C++17 时代研究过 constexpr，一定会遇到一个尴尬：std::string 不是 constexpr 的。也就是说，你没法写 constexpr std::string s = "hello";。

但在很多场景里，我需要的是“编译期把多个字符串拼接起来”，或者“编译期检查一个字符串是否符合某种格式”。这时候传统 C++ 的字符串工具都用不上，只能自己造轮子。

C++17 之前常见的做法是定义一个编译期字符串类型：

cpp复制template <size_t N>
struct ConstexprString {
    char data[N];
    size_t size;

    constexpr ConstexprString(const char (&str)[N]) : data{}, size(N - 1) {
        for (size_t i = 0; i < N; ++i) {
            data[i] = str[i];
        }
    }

    constexpr char operator[](size_t i) const { return data[i]; }
    constexpr size_t length() const { return size; }
};

C++20 之后有了 std::constexpr_string 之类的提案，但实际落地还在调研阶段。更重要的是 C++20 允许 constexpr std::string 的构造、析构和拷贝（在常量表达式里有限制），不过 std::vector 的 constexpr 支持更实用一些。

在我实际的项目里，编译期字符串最常用的场景是“编译期拼接”：

• 生成带前缀/后缀的错误消息。
• 生成协议头的二进制结构。
• 生成编译期日志格式。

举个编译期拼接的简单例子（这里用 C++17 风格）：

cpp复制template <size_t N1, size_t N2>
constexpr auto concat(const char (&a)[N1], const char (&b)[N2]) {
    std::array<char, N1 + N2 - 1> result{};  // 去掉两个结尾 \0，拼接成一个
    for (size_t i = 0; i < N1 - 1; ++i) result[i] = a[i];
    for (size_t i = 0; i < N2; ++i) result[N1 - 1 + i] = b[i];
    return result;
}

constexpr auto gMessage = concat("Error: ", "invalid parameter");

gMessage 在编译期就是一个完整的字符数组，运行时直接用，完全不需要堆分配。

3.3 编译期协议解析：让非法数据在编译期就暴露

写网络协议或者嵌入式通信模块的人，肯定遇到过这种需求：某个报文头部的魔数（magic number）、版本号、长度字段，你希望它“绝对正确”，否则后面一堆解析代码全是空转。

用 constexpr 可以做到：定义一个协议的二进制结构体，然后在编译期验证这个结构体的布局是否符合预期。

cpp复制#pragma pack(push, 1)
struct PacketHeader {
    uint16_t magic;     // 0x5A5A
    uint8_t  version;   // 1
    uint16_t length;    // 负载长度
    uint32_t crc32;     // 校验
};
#pragma pack(pop)

constexpr bool validate_header() {
    static_assert(sizeof(PacketHeader) == 9, "PacketHeader size mismatch");
    static_assert(offsetof(PacketHeader, magic) == 0);
    static_assert(offsetof(PacketHeader, length) == 3);
    // 还可以检查某些字段的取值
    return true;
}

// 编译期强制校验
static_assert(validate_header());

这看着像普通的 static_assert，但核心价值在于：你可以把逻辑判断全部放进 constexpr 函数里，用正常的 C++ 代码写出复杂校验规则，而不是写一堆分散的 static_assert 宏。

更进阶的玩法是，在编译期直接解析一段字节流，然后把解析结果作为常量。比如某个设备的配置数据是二进制 blob，你可以写一个 constexpr 解析器，把 blob 里的字段提取出来，在编译期就生成结构体。这样配置数据的正确性在编译期就得到了验证。

4. 语言能力演进：C++14 到 C++20，constexpr 的限制是怎么一步步放开的

4.1 C++11 的“一条 return”地狱

C++11 刚引入 constexpr 的时候，能力极其有限：函数体只能包含一条 return 语句，不能有局部变量、不能有循环、不能有 if。当时实现一个编译期阶乘要这样写：

cpp复制constexpr int factorial(int n) {
    return n <= 1 ? 1 : (n * factorial(n - 1));
}

递归是允许的，但只能通过三元运算符和递归调用实现，类似函数式编程。写个斐波那契还行，写个稍微复杂的算法（比如把数组排个序）就完全做不到。所以 C++11 时期的 constexpr 在工程界基本是“吉祥物”一样的存在——演示价值大于实用价值。

4.2 C++14：循环与局部变量解禁，constexpr 开始变成“普通代码”

C++14 对 constexpr 的放宽是革命性的：函数体里可以写局部变量、for/while 循环、if/switch，可以修改局部变量。

这意味着什么？以前只能在函数式风格下写的编译期代码，现在可以按命令式风格来写。我在 2.2 节里生成正弦表的代码，在 C++14 下就是完全合法的。定义局部 std::array、用 for 循环填值、然后返回，整个过程跟普通函数没有区别。

从 C++14 开始，我才真正把 constexpr 用进生产项目。原因很简单：可写的代码范围突然变大了，能表达的逻辑复杂度上了一个台阶。

4.3 C++17：if constexpr 与编译期分支

C++17 加了一个和 constexpr 强相关但作用不同的新语法：if constexpr。

它解决的是模板编程中长期以来的痛点：“用 SFINAE 或标签分发来根据类型走不同的代码分支”太绕了。if constexpr 允许你在编译期根据常量条件决定编译哪一段代码，没选中的分支甚至可以不参与模板实例化。

典型例子是编译期判断类型是否相同：

cpp复制template <typename T>
void print_impl(const T& value) {
    if constexpr (std::is_same_v<T, int>) {
        std::cout << "int: " << value << std::endl;
    } else if constexpr (std::is_same_v<T, std::string>) {
        std::cout << "string: " << value << std::endl;
    } else {
        std::cout << "unknown: " << value << std::endl;
    }
}

注意这里用的是普通的 if constexpr 而不是 if，如果写成 if，三个分支都会被编译，std::cout << value 在 T = int 的时候没问题，但在 T = 自定义类型 时可能没有 operator<<，导致编译失败。用 if constexpr 就只会编译匹配的分支。

if constexpr 和 constexpr 函数配合能产生奇妙的化学反应。比如你写一个 constexpr 函数，内部针对不同输入类型走不同分支，代码读起来像运行时逻辑，但实际编译期就完成了分支选择。

4.4 C++20：constexpr 终于可以折腾容器和动态分配了

C++20 把 constexpr 的边界推到了一个里程碑：允许在常量表达式里使用 std::vector、std::string 等动态分配容器（有限制：必须能在编译期确定分配和释放，不能泄漏）。这意味着你可以在编译期做真正的“动态”计算——比如读一个字节流，解析出数量不定的元素，塞进 std::vector，再对它们排序。

简单示例（C++20）：

cpp复制#include <vector>
#include <algorithm>

constexpr int process_data() {
    std::vector<int> v = {3, 1, 4, 1, 5, 9, 2, 6};
    std::sort(v.begin(), v.end());
    int sum = 0;
    for (int x : v) sum += x;
    return sum;
}

static_assert(process_data() == 31);  // 1+1+2+3+4+5+6+9

这个代码在 C++17 编译期绝对不行，C++20 的编译器就可以处理。当然，我实际工程里用 std::vector 做 constexpr 的情况并不多，因为编译期内存分配的开销很大，而且排查问题麻烦。但它在协议解析、代码生成工具这类场景里价值很大——以前必须在运行时准备的数据结构，现在可以直接编译期“算”出来。

4.5 关于 consteval 和 constinit：什么时候该“升级”

前面提到，C++20 还提供了 consteval 和 constinit。我的实践经验是：

• 如果某个函数只在编译期有意义，运行时不应该存在，就用 consteval。它可以防止你无意中写出“运行时调用一次但白白付出类型擦除/动态分配代价”的代码。
• 如果某个全局对象需要在静态初始化阶段完成初始化，但之后可能被运行时修改，就用 constinit。它可以避免经典的单例初始化顺序问题。

举个例子：

cpp复制constinit int gCounter = 0;  // 静态初始化，之后运行时可以改

consteval int compile_time_square(int x) { return x * x; }
static_assert(compile_time_square(10) == 100);

consteval 的好处是，如果你试图写 int y = compile_time_square(runtime_var); 编译器会直接报错，而不是偷偷在运行时调用。这比 constexpr 的“克制度”更强。

5. 编译期调试与排错：看不见的代码，怎么排查问题

5.1 把 static_assert 当成编译期断点用

constexpr 代码最大的特点是：没有调试器。你打断点没用，因为代码在编译期就跑完了，调试器根本看不到执行过程。所以排错方式必须换思路。

最简单的“断点”就是 static_assert。我调试 constexpr 函数的习惯是，在函数内部的关键位置插入一些 static_assert，验证中间结果。

但注意：constexpr 函数内部不能直接写 static_assert（C++23 之前，函数的局部 static_assert 在某些情况下不被允许，因为它在非模板上下文里无法依赖参数）。更通用的做法是把中间步骤拆成多个小函数，每个小函数配一个 static_assert。

比如：

cpp复制constexpr int step1(int x) { return x * 2; }
constexpr int step2(int x) { return x + 1; }

constexpr int process(int x) {
    return step2(step1(x));
}

static_assert(step1(3) == 6);  // 验证中间结果
static_assert(process(3) == 7);  // 验证最终结果

另一个技巧是用“故意报错”的函数来显示中间值。比如：

cpp复制template <auto V>
struct PrintValue;  // 故意不定义

// 在 constexpr 函数里临时写：
// PrintValue<my_variable> printer;

编译器报错时会打印 my_variable 的值。这招很野，但确实有效，尤其是在看一个复杂的编译期表达式到底算出来是什么数字时。

5.2 编译错误信息的结构化阅读

constexpr 代码出错时的编译错误信息往往长到离谱，尤其是涉及模板和 STL 容器时。一屏根本放不下，如果你从头看到尾，大概率看到一半就晕了。

我的实战经验是：不要从头读，从 note: 行开始读，并且只看前几屏里最后一个 error: / fatal error: 真正的原因。

常见错误模式：

• 试图在 constexpr 函数里调用非 constexpr 函数（比如 std::sin 或普通打印函数）。错误信息会指出某个调用无法在常量表达式里执行。
• 试图用运行时变量初始化 constexpr 变量。错误信息会提示 “variable ... is not usable in a constant expression” 或者 “initializer is not a constant expression”。
• 在 C++14 之前写循环/局部变量。错误信息通常指向函数体的位置。

我的习惯是：先把出问题的行号和最小的信息抓出来，再用最小化复现的方式测试。比如把 constexpr 函数复制到一个单独的小文件里，用 g++ -std=c++20 -c test.cpp 单独编译，能更快锁定问题。

5.3 防止编译时间爆炸的工程手段

constexpr 计算不是免费的午餐。编译期要做大量计算，自然需要消耗编译时间。我在一个项目里用 constexpr 生成了 65536 项的四元数插值表之后，单文件编译时间从 3 秒涨到了 20 秒。不算灾难，但已经能感知到了。

我的经验准则：

1. 表别大到离谱。能用公式算的不要全部摊开。比如 4096 点的正弦表在编译期毫无压力，但要生成 100 万个点的随机数表，那还是运行时初始化吧。
2. 把大计算隔离在单独 TU（翻译单元）里。不要把巨大的 constexpr 计算塞进头文件里，否则每个 include 这个头文件的 cpp 都要算一遍。用 inline constexpr 导出结果，或者只在一个 cpp 里计算，然后导出常量。
3. 注意递归深度。constexpr 函数的递归在编译期是有限制的（通常几百到几千层）。如果你写了一个深度递归的算法，要留意编译器报的 “constexpr evaluation depth” 错误。这时换成循环实现会更稳妥。
4. 编译期 DS 的内存开销。C++20 的 constexpr std::vector 认真用起来，编译器的元数据内存会涨得比较快。如果发现编译进程 OOM，第一件事找找是不是编译期动态分配了太多数据。

5.4 跨编译器一致性：constexpr 求值结果可能不一样

不同编译器对 constexpr 的支持程度、默认递归深度、浮点运算舍入行为都可能不同。这里尤其要小心浮点计算：同一段 constexpr 浮点代码，在 GCC、Clang、MSVC 下算出来的值可能有微小差别（因为浮点环境和中间精度不同）。如果你的项目要跨平台发布，浮点编译期表还是要谨慎，必要时对结果做一次快照回归测试。

6. 实战工程经验：几个我踩过的坑和用顺手的模式

6.1 坑一：把大 constexpr 计算放进了头文件

刚上手 constexpr 时，我习惯把所有工具函数放在一个 common.hpp 里，到处 include。结果每个 cpp 都要把那套编译期算法算一遍，编译时间肉眼可见地涨。而且一旦修改算法，所有依赖它的 cpp 全部重编。

后来我把真正大的编译期表集中在几个 cpp 里，只导出结果常量到头文件。比如 sine_table.cpp 里计算并定义 constexpr auto gSineTable，头文件里 extern const std::array<double, 4096>& gSineTable(); 用函数返回局部静态变量。这样编译期计算只发生一次，其他 TU 直接引用结果。

6.2 坑二：constexpr 函数里用了断言

调试阶段我喜欢在函数里写 assert(x > 0)，但 assert 不是一个 constexpr 函数，C++ 的标准库 assert 在常量表达式中是不能用的。编译期调用带有 assert 的 constexpr 函数，直接报错。

解决方式：用 if (x <= 0) std::abort(); 不行，std::abort() 也不是 constexpr。最佳实践是自定义一个编译期断言：

cpp复制constexpr void ct_assert(bool condition) {
    if (!condition) {
        // 触发编译错误
        // 可以 throw 一个异常（constexpr 函数内部允许 throw，只要不在常量表达式里实际抛出）
        throw 0;
    }
}

注意 constexpr 函数里可以写 throw，但在编译期求值里碰到 throw 会直接编译错误（而不是异常传播）。这正好符合“编译期断言”的预期。

6.3 顺手的模式：让 constexpr 函数同时编译期和运行时都能用

我写算法时，最舒服的状态是：同一个函数，编译期用来生成表，运行时用来处理动态输入。这样一套逻辑，两个场景。

典型例子是 FNV-1a 哈希函数。前面写的 fnv1a(const char*) 既能给编译期用（生成命令常量），也能给运行时用（处理用户输入字符串）。只要不做任何平台相关的优化，两边结果完全一致。

要保证这一点，有几条纪律必须遵守：

• 不要依赖 static 局部变量（C++11 起不允许在 constexpr 函数里用）；
• 不要调用任何运行时 I/O；
• 不要依赖浮点环境（如果为了可移植性，尽量用整数算法）；
• 不要用 reinterpret_cast 做类型双关。

遵守这些纪律后，统一的函数让维护成本降低一个量级。

6.4 进阶组合：constexpr + 模板 + 编译期类型分发

最后分享一个我目前最常用的组合技巧：用 constexpr 函数配合 if constexpr，实现编译期类型分发和编译期数据生成的统一框架。

例如我要写一个“任意类型数组求和”的编译期版本：

cpp复制template <typename T, size_t N>
constexpr T compile_time_sum(const std::array<T, N>& arr) {
    T sum{};
    for (size_t i = 0; i < N; ++i) {
        sum += arr[i];
    }
    return sum;
}

// 使用
constexpr std::array<int, 5> a = {1, 2, 3, 4, 5};
static_assert(compile_time_sum(a) == 15);

constexpr std::array<double, 3> b = {1.5, 2.5, 3.0};
static_assert(compile_time_sum(b) == 7.0);

如果类型是自定义的，只要保证它的 operator+= 也是 constexpr，就能无缝进入编译期世界。

另一个我很喜欢的方法是：把 constexpr 生成的数据作为模板参数。比如：

cpp复制template <uint64_t Hash>
struct Command {
    static constexpr uint64_t id = Hash;
    const char* name;
};

using MoveCommand = Command<fnv1a("move")>;

这样每个命令类型都天然携带了它的编译期哈希 ID，通过 if constexpr 做类型分发，代码可以写得极其干净。

写在最后

说一个我个人的体会：constexpr 这玩意儿，入门容易，精通难，但一旦用顺了，会彻底改变你对“常量”“配置”“初始化”这些概念的敏感度。现在我在工程里看到一张运行时填的表、一段启动时初始化数据的逻辑，第一反应都会想“这能不能挪到编译期”——不一定都要挪，但至少会权衡一下。

如果你正在入门 C++，建议先不加 constexpr 写一遍普通版本，再把它改造成 constexpr 版本，用 static_assert 验证结果一致。这个过程能帮你建立对“编译期”和“运行时”边界的感觉。如果已经工作了，挑一个项目里最无聊的查找表/映射表动手，收益最直接。

最后分享一个小技巧：在 C++20 下，试着用 consteval 定义一个“编译期平方根”函数，然后用它去验证你算法里所有魔数的合法性——编译不过就说明代码里某个数字改错了。这种“让编译器替你盯着配置”的写法，用惯了就回不去了。