烂人不配爱C++的constexpr是个很奇妙的东西——写对了，编译器替你把脏活累活全干了；写错了，报错信息能把你看懵半天。前阵子接手一个老模块，启动时要初始化一张包含几万条记录的映射表，热加载路径上每次启动都白白浪费几十毫秒。后来把表的生成逻辑改成constexpr，启动时间直接降了一个数量级。这也是我写这篇东西的动机：constexpr不是C++语法里的冷门点缀，而是实打实能压到运行成本的东西。这篇文章会把编译期求值的前世今生、底层机制、经典场景、关键写法和踩过的坑一次讲透，适合已经把constexpr当关键字用过、但没系统摸过它边界的人。
如果你以为constexpr就是“给函数加个前缀让它跑得快一点”，那这篇文章能帮你补上很多认知。它到底是什么，什么时候能编译期计算，什么时候不能，边界条件在哪，优化空间有多大——我会从编译器的视角、语言标准演进的视角、还有实际工程交付的视角各说一遍。
1. 从C++11到C++20：constexpr能力演进的四个关键节点
很多C++开发者对constexpr的理解是断裂的，因为不同版本的C++标准下它完全是两样东西。你在网上搜到的老教程，可能还停留在C++11时代“函数体只能写一条return语句”的阶段，而现实项目早已用上了C++17的if constexpr和C++20的consteval。不搞清这条演进线，很多写法就会奇怪——为什么老代码里全是三元表达式嵌套？为什么新代码能直接写for循环？
1.1 C++11：从零到一，但限制极其严苛
C++11是constexpr的诞生时刻。设计目标很纯粹：让编译器能在编译期对表达式求值，从而支持数组大小、枚举值、模板非类型参数这些需要常量表达式的场景。但初版非常“骨感”，一个constexpr函数体内只允许一条return语句，不允许定义局部变量，不允许循环，不允许if分支，只能靠嵌套三元运算符和递归来顶。
cpp复制// C++11 风格：阶乘
constexpr int factorial(int n) {
return n <= 1 ? 1 : n * factorial(n - 1);
}
这个写法在C++11下能编过，但你要算个费波那契数列，就得写出一长串递归表达式，可读性差到离谱。C++11的constexpr是形式大于实用的——它证明了这条路走得通，但工程上真用它写复杂逻辑的人不多。
1.2 C++14：真正的分水岭，constexpr开始能“写代码”了
C++14拆掉了大部分枷锁。constexpr函数体内允许声明局部变量、允许for/while循环、允许if/switch分支、允许修改局部变量。这意味着几乎一切普通函数的计算逻辑都能平移到编译期，只要你保证传入参数是常量。
cpp复制// C++14 风格：同样的阶乘，逻辑非常直白
constexpr int factorial(int n) {
int result = 1;
for (int i = 2; i <= n; ++i) {
result *= i;
}
return result;
}
C++14这一版的放开是革命性的。从这时起，constexpr才算真正具备了“工程可用性”。我所在的项目组大概是从C++14标准切换之后开始大量使用constexpr处理配置表和哈希计算的，因为写起来和普通函数已经没有太大区别。
1.3 C++17：if constexpr与constexpr lambda
C++17给constexpr家族带来了两个重要成员。第一个是if constexpr——它让模板代码在编译期就能裁剪掉不需要的分支；第二个是允许lambda表达式声明为constexpr，让编译期计算可以以匿名函数的形式内联在表达式里。
cpp复制template <typename T>
std::string_view type_name() {
if constexpr (std::is_same_v<T, int>) {
return "int";
} else {
return "unknown";
}
}
if constexpr的核心价值在于：未采用的else分支在模板实例化时会整个丢弃，不会参与编译。这意味着你可以放心大胆地写只有特定类型才能编译的代码，而完全不用担心其他类型实例化时报错。这一点后面第五节还会展开讲。
1.4 C++20：consteval与constexpr虚函数
C++20把constexpr的版图推向了更深的区域：
consteval：强制函数只能在编译期求值，任何运行期调用都是编译错误。constexpr虚函数：虚函数也能参与编译期计算了。constexpr的new/delete：编译期可以动态分配内存（前提是编译期必须释放干净）。- 允许
try/catch：但编译期不允许异常被实际抛出，否则报错。
这三步扩展解决了两个实际问题：第一，有些函数一旦编译期算完结果就固化了，漏掉constexpr导致运行时重算损失很大，consteval可以把这种错误直接从编译层面堵死；第二，编译期做字符串处理、构建容器时常常需要临时分配，C++20补上了这个能力。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 编译期求值的底层机制：编译器到底在干什么
理解了标准演进后，下一个关键问题是：编译器是怎么做编译期求值的？很多人把constexpr想象成“某种高级优化”，但实际上它和普通优化完全是两码事——constexpr是C++语言规范承诺的“保证在编译期能算出来”，而不是编译器顺手做的“优化”。
2.1 常量表达式求值器是一个“抽象解释器”
GCC、Clang、MSVC在处理constexpr时都实现了一个常量表达式求值器（constant expression evaluator）。它不是直接执行机器码，而是像解释器一样逐条解释AST（抽象语法树）节点，模拟变量的状态、递归深度和调用栈，最终得出确定值。
这个求值器有自己的“内存模型”，能管理对象的生命周期、指针引用，但所有操作都发生在编译器进程内。所以它和支持宏展开是本质不同的东西——constexpr走的是完整的类型检查和语义分析，比#define安全得多。
2.2 什么场景会触发编译期求值
不是所有constexpr变量都会在编译期求值的。这是很多人最大的误区。编译期求值只发生在需要“常量表达式”的语境下：
static_assert中的表达式- 数组的维度，比如
int arr[SIZE]; - 模板非类型参数，比如
std::array<int, N> constexpr变量初始化时的初始化器enum的枚举值、case标签、alignas参数等
如果constexpr函数在普通运行时上下文里被调用，它完全可以退化成普通函数，在运行时才执行。下面的代码不会在编译期生成任何东西：
cpp复制int runtime_input() {
int x;
std::cin >> x;
return x;
}
int main() {
int n = runtime_input(); // 运行时输入
int c = factorial(n); // 编译期不可能求值，只能在运行时算
}
所以准确的说法是：constexpr函数是“能”在编译期求值，但“不一定”会在编译期求值。需要常量表达式的地方，编译器强行求值；不需要的地方，一切照旧。
2.3 求值失败与编译期代价
编译期求值不是免费的午餐。每次解释执行都要消耗编译器的前端时间和内存。GCC和Clang提供了不少控制参数：
| 编译器 | 常用控制选项 | 默认限制（大致） |
|---|---|---|
| GCC | -fconstexpr-steps |
33554432步 |
| GCC | -fconstexpr-loop-limit |
262144次循环迭代 |
| Clang | -fconstexpr-steps |
1048576步 |
| MSVC | /Zc:constexpr |
深度1024左右（历史版本） |
如果递归深度或循环迭代超过限制，编译直接报错。这也是我为什么建议“能用循环就不用递归”——循环有明确的上限控制，递归一多很容易触发编译器的步数上限。
2.4 编译期求值和普通优化的区别
普通优化里的常量传播（constant propagation）和常量折叠（constant folding）是编译器在生成机器码时的“顺手动作”，不保证一定发生，也没有语言级承诺。constexpr则在语言标准层面规定了“这个表达式必须在编译期可求值”，这是规范性保证，不止是性能优化。
实际工程中这两者是叠加的。即便你写的代码没有被放在常量表达式语境里，只要编译器发现constexpr函数在运行时被调用、参数是字面量，它大概率也会直接算出结果并折叠成常量。但你不能依赖这个——语言不保证。
3. 把运行时开销焊死在编译期：典型应用场景拆解
讲了一堆理论，来看实打实的应用。以下四个场景是我在实际项目里反复用到的，能直观地体现constexpr的收益。
3.1 编译期生成查找表：CRC表、正弦表、质数表
查表法在协议解析、加密、图形学里无处不在。通常的做法是程序启动时初始化一张表，但这至少造成两个问题：一是启动路径上的初始化耗时不等人；二是如果表的内容是纯数据，那它本质上就应该直接躺在二进制文件里。来看CRC32表的生成：
cpp复制#include <cstdint>
#include <array>
constexpr std::uint32_t crc32_byte(std::uint32_t poly, std::size_t idx) {
std::uint32_t c = static_cast<std::uint32_t>(idx);
for (int k = 0; k < 8; ++k) {
c = (c & 1u) ? poly ^ (c >> 1u) : c >> 1u;
}
return c;
}
template <std::size_t... Idx>
constexpr auto make_crc32_table(std::index_sequence<Idx...>) {
return std::array<std::uint32_t, sizeof...(Idx)>{
crc32_byte(0xEDB88320u, Idx)...
};
}
static constexpr auto crc32_table =
make_crc32_table(std::make_index_sequence<256>{});
这段代码里，crc32_table在编译期就会生成完整的256项查找表，最终进入只读段，运行时连一条初始化指令都不用执行。
3.2 编译期字符串哈希：实现高效的switch字符串分发
C++的switch只能匹配整型，遇到字符串匹配要么写一长串if/else if，要么用std::string做map。但如果我们有一个constexpr哈希函数，就能把字符串映射成size_t，再配合switch实现“字符串分发”：
cpp复制constexpr std::uint32_t fnv1a(const char* s) {
std::uint32_t h = 2166136261u;
while (*s) {
h = (h ^ static_cast<unsigned char>(*s)) * 16777619u;
++s;
}
return h;
}
void handle(const std::string& cmd) {
// cmd 本身是运行时变量，但字面量在编译期就哈希完了
switch (fnv1a(cmd.c_str())) {
case fnv1a("save"):
// 保存逻辑
break;
case fnv1a("load"):
// 加载逻辑
break;
case fnv1a("quit"):
// 退出逻辑
break;
default:
break;
}
}
函数fnv1a是完全合法的constexpr函数。cmd来自运行时，所以fnv1a(cmd.c_str())是在运行时执行；但四个case标签右侧的fnv1a("save")等表达式在编译期就会被求值成整数常量。两件事平行发生，互不干扰。这段代码的好处是既有switch的高效，又有字符串字面量的可读性。
3.3 编译期配置计算：把“永远不变的量”固化成常量
项目里经常有一类常量：不是直接写死，而是由几个基础参数推导出来的。比如一个图像处理模块，输出缓冲区大小依赖于位深、通道数和对齐规则。这些值在编译时完全确定，但直接手算容易出错，不如让编译器算：
cpp复制constexpr int kChannels = 4;
constexpr int kBitDepth = 12;
constexpr int kAlign = 16;
constexpr int round_up(int value, int align) {
return (value + align - 1) / align * align;
}
constexpr int kRowBytes = round_up(kChannels * kBitDepth / 8, kAlign);
constexpr int kBufferBytes = kRowBytes * 4096;
思路就是：能交给编译器算的，人不要手动算。 手算四个数字可能看不出问题，但如果配置有20个参数，手算出来的结果一旦写错，排错成本远大于让编译器算一下。
3.4 编译期类型特征计算：让静态断言更有表达力
std::type_traits里的很多判断本身是基于模板特化的，但我们在项目里会写一些自己的“类型特征”。比如判断一个类型是否可平凡拷贝，这在序列化框架里很关键：
cpp复制#include <type_traits>
template <typename T>
constexpr bool is_trivially_copyable_but_small() {
return std::is_trivially_copyable_v<T> && sizeof(T) <= 16;
}
static_assert(is_trivially_copyable_but_small<int>());
static_assert(is_trivially_copyable_but_small<double>());
static_assert(!is_trivially_copyable_but_small<std::string>());
static_assert在编译期触发求值，这比写一堆注释、写文档更靠谱——因为约束是编译器强制检查的，不是靠人记。
4. 写好constexpr代码的关键姿势：迭代、递归与布骤化
同样是实现一个算法，constexpr版本的工程写法和运行时版本有不少差异。这里梳理几条关键的经验，能让你少走很多弯路。
4.1 能用循环就别用递归
C++11时代被迫用递归是因为没有循环指令；C++14以后循环已经全面放开，这带来一个显著的好处：递归深度受编译器求值步数限制，而循环有独立的迭代上限，且更容易控制。递归很容易写出一个“逻辑上正确但编译器跑不过来”的函数：
cpp复制// 危险：递归深度 = n，n=10000 时大概率触发编译上限
constexpr int sum_recursive(int n) {
return n <= 0 ? 0 : n + sum_recursive(n - 1);
}
// 安全：循环迭代可控
constexpr int sum_loop(int n) {
int result = 0;
for (int i = 1; i <= n; ++i) {
result += i;
}
return result;
}
原则上，凡是能用循环表达的算法，就不要在constexpr里写递归。如果算法天然适合递归（比如树的递归遍历），也要评估最坏深度，超过几百层的要谨慎。
4.2 拆小函数，编译期报错才可能定位
编译期求值不是调试器能单步跟踪的。某个constexpr函数一旦求值失败，GCC/Clang的报错往往是一大片实例化堆栈，定位起来非常痛苦。我的经验是：把复杂逻辑拆解成多个小而专注的constexpr函数，每个函数都单独用static_assert验证。这样报错时能直接定位到具体子函数，而不是在一堆模板展开里大海捞针。
cpp复制constexpr int clamp_brightness(int value) {
return value < 0 ? 0 : (value > 255 ? 255 : value);
}
constexpr int transform_pixel(int r, int g, int b) {
// 拆成好几个小函数，分别验证
return clamp_brightness(r * 3 / 2)
+ clamp_brightness(g * 5 / 4)
+ clamp_brightness(b * 7 / 8);
}
static_assert(transform_pixel(100, 200, 50) == 415);
4.3 调试技巧：维护一份非constexpr副本
编译期求值没法打断点，这是几乎所有人在实际工程里遇到的最大痛点。我常用的调试套路是：先把一个constexpr函数“降级”为普通函数，用单元测试把逻辑跑通、跑对；之后加上constexpr关键字，再用static_assert做一组编译期验证。这样做的好处是，逻辑错误在运行时阶段就暴露了，编译期报错则大概率是语法/能力边界问题，两种问题不会搅在一起。
C++20还有一个选择：同时维护一个普通版本和一个consteval版本，开NDEBUG时用编译期版本，调试模式下用普通版本。
4.4 consteval：从“能编译期求值”升级为“必须编译期求值”
C++20引入的consteval适合那些“如果不在编译期算，就完全没意义”的函数。一个典型例子：生成某个配置项的哈希值，如果它被漏掉在运行时计算，代价虽小但已经破坏了意图。用consteval后，任何运行期调用都是编译错误。
cpp复制consteval std::uint32_t config_hash(const char* key) {
std::uint32_t h = 2166136261u;
while (*key) {
h = (h ^ *key) * 16777619u;
++key;
}
return h;
}
constexpr auto h1 = config_hash("server"); // ok
auto h2 = config_hash("client"); // 运行期调用 -> 编译错误
这个约束很强硬，但也逼着你确保调用点真的都能编译期求值。在大型代码库里，consteval的好处是让“编译期才能算”的意图显式化，团队协作时其他人不容易误用。
4.5 结构化绑定和编译期计算的配合
C++17以后，constexpr上下文里也能用结构化绑定，这让编译期处理std::pair、std::tuple变得非常方便。比如需要从一组编译期配置中解出多个关联值时：
cpp复制constexpr std::pair<int, int> get_minmax() {
return {3, 42};
}
constexpr auto [lo, hi] = get_minmax();
static_assert(lo == 3 && hi == 42);
这种写法让编译期计算的代码更接近普通代码，心智负担小很多。也是在同样的版本里，std::array、std::tuple的constexpr支持也相当完善。
5. 模板与constexpr的化学反应：if constexpr与编译期分支裁剪
constexpr家族里最容易被低估的是if constexpr。它表面上看是“编译期分支”，实际影响远不止于此——它直接重塑了模板编程的方式，让很多原本只能靠SFINAE硬刚的做法变得简单直白。
5.1 if constexpr：让类型分发的代码像普通代码一样写
在if constexpr出现之前，模板里要按类型走不同逻辑，常见做法是标签分发（tag dispatch）或SFINAE，代码又绕又长。有了if constexpr，直接写在函数体里就行：
cpp复制template <typename T>
void print_value(const T& value) {
if constexpr (std::is_same_v<T, std::string>) {
std::cout << "str: " << value << '\n';
} else if constexpr (std::is_integral_v<T>) {
std::cout << "int: " << value << '\n';
} else {
static_assert(!sizeof(T), "unsupported type in print_value");
}
}
关键在于：当T是int时，std::is_same_v<T, std::string>分支会整体被丢弃，不会实例化，所以value上不会调用operator<<字符串版本。当T是其他不支持的数时，会触发static_assert给出自定义错误。
5.2 丢弃分支带来的“编译期安全”
if constexpr最强大的地方是“未采用的分支不参与编译”。这个特性可以用来做很多以前做不了的事，比如在同一个模板里对不同类型调用不同的接口，而这些接口之间没有任何交集：
cpp复制template <typename T>
auto process(T& obj) {
if constexpr (requires { obj.load(); }) {
return obj.load();
} else {
return obj.read();
}
}
这里用了C++20的requires表达式做约束。如果类型只有read()没有load()，则第一分支不会实例化，编译器不会报错。这在序列化库或插件框架里特别实用，可以避免大量繁冗的SFINAE表达式。
5.3 TMP与constexpr：谁负责类型，谁负责值
模板元编程（TMP）和constexpr在能力上有重叠，但各自侧重点很不一样。TMP是基于模板特化与递归实例化的计算模型，擅长在类型层面做组合与选择；constexpr则直接用普通C++语法处理值计算。两者的最佳配合是：模板负责类型推导与分发，constexpr负责具体数值的编译期计算。
举个综合例子，编译期生成一个类型到哈希值的映射表，哈希值用constexpr算，类型到索引的映射用模板特化：
cpp复制template <typename T>
struct type_index;
template <>
struct type_index<int> { static constexpr int value = 0; };
template <>
struct type_index<double> { static constexpr int value = 1; };
template <>
struct type_index<std::string> { static constexpr int value = 2; };
// 编译期组合：索引与名称关联
template <typename T>
constexpr const char* 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 "other";
}
这种组合在运行时零开销，同时保留了类型安全的编译期检查。
6. 常见陷阱与实战踩坑：这些坑我踩过，希望你没有
constexpr看起来简单，真写起来坑还是挺多的。我把这些年踩过的坑做了一个清单，按照“出现频率”和“排查耗时”排序。这里每个都是真实项目里遇到过的。
6.1 “加上constexpr就能编译期优化”的错误预期
第一个坑也是最大的认知误区：很多人以为给函数加上constexpr，编译器一定会做编译期优化。但实际上，只有当函数被用于常量表达式语境（数组维度、static_assert、模板参数等）时，编译期求值才会强制发生；在其他普通调用点，编译器是否优化是“不确定行为”，完全看编译器的常量传播能力。
所以判断要不要加constexpr，正确的问题是：这个函数有没有可能被用在常量表达式语境里？ 如果可能，加；如果只是普通运行时调用，加了也不会带来性能提升。
6.2 编译期生成全局数组时的ODR与链接问题
在C++17之前，constexpr的全局数组如果定义在头文件里，并且被多个翻译单元包含，很容易触碰到ODR（单一定义规则）问题。C++17引入的inline变量彻底解决了这个麻烦：
cpp复制// 头文件里，C++17：
inline constexpr auto kCrcTable = make_crc32_table(...);
如果还在C++14，就必须在类内部定义静态constexpr成员（每个编译单元各自生成一份），或者用函数包裹来规避链接问题。
6.3 constexpr函数里不能用的东西
constexpr函数不是万能的，以下这些常规写法在编译期求值时是禁止的：
goto跳转- 未初始化的局部变量（C++20放宽了一部分）
- 静态/线程局部变量（C++23才允许局部
static constexpr，普通static依旧不行） throw表达式（C++20允许try块，但抛出的行为仍是错误）- 直接调用非
constexpr函数 - 传统循环中的
reinterpret_cast等危险操作
其中最容易踩的是静态局部变量。假设你在constexpr函数里写了个static std::uint32_t seed = 42;，在较新标准下不一定报错，但语义可能不符合预期，建议一律不用。
6.4 递归步数撞上编译器上限
前面提过，编译期递归的深度受-fconstexpr-steps等参数限制。实际遇到过的情况是：一个合法的constexpr函数，运行时明明一切正常，但加上static_assert后编译器直接不干了，报出“constexpr evaluation depth exceeds limit of 512”之类的错误。
解决方案有三个：一是改成循环实现；二是拆分多个小函数逐层调用，避免单一函数深度爆炸；三是调用编译器参数调整限制（但要谨慎，编译时间会显著上升）。我强烈建议优先采用第一种和第二种，而不是用调参掩盖问题——因为编译期求值的深度往往反映的是算法本身的递归深度，递归深了后面代码维护也会头疼。
6.5 调试体验差：定位问题全靠“二分法”
编译期求值没有断点，不能step，只能通过static_assert一步步验证。遇到比较复杂的constexpr函数报错，我的排查流程一般是：
- 把所有子表达式拆开，逐个赋给
constexpr局部变量。 - 对每个局部变量写
static_assert确认预期值。 - 如果某个
static_assert失败，说明那一行出了逻辑或能力问题。 - 如果全部通过但函数整体失败，检查最外层返回表达式是否越过了允许的
constexpr边界（比如调用了非constexpr函数）。 - 还是不行就把函数临时改成非
constexpr，写个单测跑一遍——往往问题就清楚了。
这套“二分法”我从C++14用到现在，应该能覆盖九成以上的constexpr疑难杂症。
7. 实测性能对比：constexpr到底省了多少时间
前面讲了不少原理，这节给几组我和团队实际测量的数据。虽然不同项目差异很大，但量级能说明问题。
7.1 查找表初始化：启动时间对比
一个图像算法模块，需要一张1024 x 1024的正弦值预计算表（float类型）。老代码在启动时循环生成：
cpp复制static float g_sin_table[1024 * 1024];
// 启动阶段：for (i...) g_sin_table[i] = std::sin(i * 0.0001);
实际测量结果：启动阶段在该循环上消耗约30~40毫秒（取决于CPU和优化等级）。改成constexpr生成后，二进制文件里直接嵌入这张表，启动阶段时间为0毫秒（表中数据直接映射到内存，无需初始化）。磁盘体积增加4MB（102410244字节），但这个模块本来就加载数百MB资源，4MB完全可接受。
这是constexpr最典型的收益：用二进制体积换取运行时间。如果你对二进制体积极其敏感（嵌入式），需要权衡；但在服务器、桌面应用里，这个交换通常是划算的。
7.2 哈希分发：运行时性能对比
协议名分发，原来用std::map<std::string, Handler>做查找，每处理一条消息平均大概几百纳秒；改成constexpr哈希+switch后，哈希计算在编译期完成，运行时只是一个整数比较，耗时收敛到几十纳秒以下，量级提升明显。而且代码可读性不降反升——case fnv1a("save"):比if (cmd == "save")更有结构和跳跃感。
7.3 编译时间代价：必须正视的副作用
constexpr不是没有代价的。还是那张1024×1024的正弦表，编译时间从原来的约8秒增加到约18秒（GCC 12，-O2，单文件）。这是因为编译期的解释执行本质上是一次额外的“程序运行”，只是运行者是编译器前端。
所以在工程里我的建议是：
- 小表、关键路径上的常量计算：毫不犹豫上
constexpr。 - 大表、编译时间敏感的项目：先评估编译时间牺牲是否可接受，再决定用不用。
- 构建系统缓存：把
constexpr密集的代码集中到少量Translation Unit里，靠增量编译消化编译时间。
7.4 真实项目收益的参考数据
以一个实际通信中间件项目为例，总共找到约30个可以在编译期完成的查表/哈希/配置计算点。改造前后对比：
- 启动时间：从约220毫秒降到约80毫秒，省下的140毫秒里有80%来自
constexpr表。 - 运行时消息分发：平均单条消息处理耗时从约1.2微秒降到约0.9微秒，哈希分发起到了明显作用。
- 二进制体积：增加约3.2%（原因是嵌入的查表数据）。
- 编译时间：单文件最长编译时间从3分钟增加到6分钟，但由于分散在多个模块，日常开发影响不大。
这个数据可能不算惊艳，但很少有什么改动能同时带来启动和热路径的双重改善。如果你的项目里也有这种“永远不变的运行时计算”，constexpr大概率也能帮你省下同样的时间。
8. 最后的实践体会
说了这么多，最后聊点个人体会。我在实际项目里踩过的最大的一个坑，是试图把所有“看起来不变量”的东西都一股脑改成constexpr。后来发现，有些计算虽然理论上是常量，但代码被频繁改动、参数处于快速迭代期。这时候用constexpr反而拖累开发效率——每次改参数都要重新做编译期求值，编译器报错变得频繁，调试成本飙升。
我现在的判断标准很简单：如果一个值在接下来三个月内基本不会变，且生成逻辑不复杂，就放心用constexpr；如果它可能频繁调整，或者计算逻辑涉及大量用户输入，就保持运行时计算。
另外还想提一点：如果你刚开始接触constexpr，不要一上来就挑战那种几千行的编译期算法。从小处入手——先做一张查找表、一个字符串哈希、一个配置计算，跑通后再逐步扩大边界。constexpr的学习曲线其实不陡，但它和运行时编程的思维方式确实有微妙差异——多写几次，你就会慢慢掌握那种“把程序跑在编译器里”的感觉。