C const 这个关键字恐怕是不少人的“熟悉的陌生人”。我第一次接触时以为它只是给变量加一道只读限制写代码时随手加个 const等编译器报错再删掉。直到一次重构类接口因为成员函数少了 const 限定整个类在 const 对象场景下完全没法用我才意识到 const 的语义远不止“不能改”三个字。这篇文章我打算把 const 的常见用法、底层含义和工程里的正确姿势完整串一遍const 变量、const 指针、const 引用、const 成员函数、constexpr、const_cast以及它们组合起来后的行为。想把 C 的 const 彻底吃透的开发者或者面试前需要把相关点过一遍的朋友应该都能从这里找到需要的东西。1. const的核心语义从“只读”到“不可修改”的边界问题1.1 const 变量编译期约束不是运行时保护先回到最基础的定义。const int a 42;意味着变量a在程序的逻辑语义上不可修改。这是一种编译期约束编译器看到a 43;会直接报错。但这里有个很容易被忽略的前提const不等于“只读存储区”更不等于“运行时防篡改”。它只是要求开发者不能通过这个名字去修改它至于底层物理存储是不是真的只读标准并不关心。const int x 42; x 43; // 编译错误: assignment of read-only variable这个约束能带来两层价值。第一层是防止误写比如把写成在比较条件里经常靠 const 来兜底。第二层是给编译器优化提供依据因为编译器在可见的翻译单元内可以假定const对象不会被修改从而做常量折叠。但需要明确如果通过某些手段真的去改了它这是未定义行为不是“系统会阻止”或“运行时报错”。这就像签了一张承诺不修改的合同编译器相信你行为就按照“你没改”来假设一旦违约后果自负。命名空间作用域的const变量还有一个容易踩的细节默认是内部链接。如果你在头文件里写const int kValue 10;每个包含这个头文件的编译单元都会得到自己的一份副本。想让它变成外部链接需要显式写extern// a.cpp extern const int kGlobal 2048; // b.cpp extern const int kGlobal;这种“全局常量”的方案在跨文件共享时很常用。但我们也要知道带有外部链接的 const 变量并不会破坏“编译期常量”的能力只要初始化式是常量表达式它依然可以在数组大小、模板参数等场景中使用。1.2 const 和 constexpr一个看初始化时机一个看初始化方式很多人会把const和constexpr混为一谈因为它们经常同时出现在同一个声明里。实际上两者解决的问题不同。const描述的是“不可修改”constexpr描述的是“可以在编译期求值”。一个const变量可以是编译期常量也可以是运行时才确定的值完全取决于初始化式const int compile_time_known 100; // 常量表达式编译期可知 const int runtime_value rand(); // 运行时初始化合法但并非编译期常量而constexpr int x rand();是非法的因为编译器的要求更苛刻必须在编译期就能确定值。反过来constexpr变量默认也有 const 的属性C11 之后constexpr变量是 const 的constexpr 非静态成员函数不是 const 成员函数这里要分清一个constexpr int n 42;可以当普通const int使用但多了“必须在编译期求值”的保证。实战中一个典型问题是“const int 能用作模板参数吗”答案是只有当它是常量表达式时才可以。const int n get_n();不能作为std::arrayint, n的模板参数因为n的初始化发生在运行时。这种区分在日常写模板时非常关键初始化时机的选择直接决定了变量能不能参与编译期计算。1.3 理解 const 的“承诺”本质少踩很多坑把 const 理解成“不可修改的承诺”而不是“只读锁”对后面理解 const_cast、mutable 以及编译器优化都很有帮助。举个例子若一个函数接收const std::string s它承诺的是“我不会通过这个引用去修改 s 的本体”而不是“s 这个对象天生不可变”。如果调用方传入的是普通非常量字符串那该对象内部依然可以变只是这个函数内部不通过这个引用去变它。这个区别非常重要。因为它决定了 const_cast 的合法性判断如果原始对象本身是 const那么去掉 const 再去修改就是未定义行为如果原始对象本来就不是 const只是当前被 const 引用或指针“看着”那去掉 const 修改是合法的尽管代码味道仍然不好。这个点我在后面 const_cast 那部分会展开但先在这里埋下伏笔const 是“接口层的契约”不是“对象物理属性”。2. 组合类型里的const指针、引用、数组与顶层/底层限定2.1 指针的两种 const顶层 const 和底层 constconst 一旦和指针组合就出现了一个让无数人记混的点const int *p和int *const p到底哪个是指针不能变哪个是指向的值不能变我的记法是“从右往左读”或者直接记住两类限定const int *p指向 const int 的指针也就是“底层 const”。它可以指向别处但不能通过 p 修改所指对象。int *const pconst 指针即“顶层 const”。指针本身不能重新赋值但可以修改它指向的对象。const int *const p两层都有指针不可变指向的值也不可变。用代码验证int a 1, b 2; const int *p1 a; p1 b; // 可以指针本身可以改 // *p1 3; // 错误不能通过 p1 修改值 int *const p2 a; // p2 b; // 错误指针本身是 const *p2 3; // 可以a 不是 const可以通过 p2 修改这种区分在函数参数里尤其重要。比如void f(const int* p);和void f(int* p);是两个不同的函数签名因为它们对参数的“权限”不同。但注意顶层 const 在按值传参时会被忽略void f(int* p);和void f(int* const p);是同一个函数声明不能靠它来重载。这是个非常容易踩的坑我见过有人尝试用int* const区分重载结果编译直接提示“重定义”。2.2 const 引用没有“const 引用”这个复合词但大家都懂严格来说C 引用本身没有“顶层 const”一说因为引用一旦初始化就不能再绑定别的对象所以const T里的 const 实际上修饰的是被引用对象。大家说“const 引用”时通常指的是“对 const 对象的引用”reference to const。int a 10; const int ref a; // 不能通过 ref 修改 a a 20; // 可以a 本身不是 const std::cout ref; // 输出 20更关键的是const T能绑定到右值和临时对象而非常量左值引用不行。例如const std::string s std::string(hello);是合法的临时对象的生命周期会延长到引用结束。这给了我们一种避开拷贝的传参方式形参写成const std::string实参传临时字符串也不会产生额外拷贝。但这里有个隐藏陷阱生命周期延长规则并不总是适用。把临时对象作为实参传给const std::string参数时临时对象会活到完整表达式结束即函数调用结束后立刻销毁。如果函数内部只是读取安全如果函数把这个引用保存到成员变量或全局容器里调用返回后引用就成了“悬垂引用”。我在实际项目里见过有人把 C 库函数返回的字符串直接绑到 const 引用上存起来结果在高层模块里读出了乱码。2.3 const 数组和字符串字面量字符数组的历史包袱数组也能加 constconst int arr[] {1, 2, 3};表示数组每个元素不可修改。这在声明只读表、查找表时非常常见比如棋盘的初始布局表或 CRC 查表。字符串字面量在 C 里的类型其实是const char[N]例如hello的类型是const char[6]。正因为它是 const 的直接写char* p hello;在 C 中是不合法的因为这会丢到 const 限定。虽然一些老编译器只给 warning但在新代码里请务必写const char* msg hello;如果你需要把这种字面量传给一个参数为char*的旧函数别硬转先确认函数不会修改缓冲区再用const_castchar*(msg)。一旦函数内部真的写了结果就是未定义行为。在嵌入式或国产化适配场景中这类字符串字面量往往被放在只读段写入会直接触发段错误调试起来非常痛苦。3. const 成员函数逻辑常量性与 mutable 的妥协3.1 末尾 const 到底修饰了什么成员函数声明末尾的 const 修饰的是this指针。对于普通成员函数this的类型是T*对 const 成员函数this的类型是const T*。因此在这个函数内部所有成员变量都被视为 const不能修改且不能调用其他非 const 的成员函数。class Counter { int value_ 0; public: int get() const { return value_; } // 可以只读 void reset() { value_ 0; } // 非 const };const 和非 const 版本可以同时存在形成重载。调用哪个版本取决于对象的常量性const 对象只能调用 const 版本非 const 对象更偏向调用非 const 版本。这是标准库迭代器的常见设计class Text { public: char at(size_t i) { return data_[i]; } const char at(size_t i) const { return data_[i]; } };这个设计让 const 对象能读但不能改非 const 对象既能读又能改。如果你在写类时破了这个对称性比如只有非 const 版本读者一旦拿到 const 对象连读取都做不到这就是我在文章开头说的“整个类在 const 场景下没法用”的根源。3.2 mutable给 const 成员函数留一扇符合逻辑的后门mutable关键字允许 const 成员函数修改某些特定成员。它适用的场景是那些“不改变对象对外可观察状态”的成员典型包括缓存、调整锁、引用计数、日志标记。举个例子一个类要对外提供“只读查询”同时内部想把上次计算结果缓存起来class Config { mutable std::once_flag init_flag_; mutable std::vectordouble cache_; public: double lookup(int key) const { std::call_once(init_flag_, [this] { // 这里在 const 函数里修改了 cache_ cache_ fetch_from_disk(); }); return cache_[key]; } };这里lookup是 const 的因为它不改逻辑状态但对调用者是“只读”的内部用 mutable 缓存来加速完全合理。反过来如果把真正的业务核心状态标成 mutable比如允许const函数修改用户看到的成员那基本就是在自欺欺人。mutable 是“逻辑 const”的实现工具不是绕开 const 的逃生通道。3.3 const 对象调用非 const 成员函数的报错链路编译器在 const 成员函数内遇到非 const 调用报错信息通常很长但核心意思是“丢弃了 const 限定”。比如struct Service { int compute() { return 1; } int get() const { return compute(); } // 编译错误 };原因是this是const Service*而compute()需要Service*无法从 const 转换到非 const。当你看到这样的错误应该立刻意识到要么这个函数本来就该是 const要么设计上确实需要修改状态那它就不该从 const 函数里调用。标准库里最适合说明这个问题的例子是std::map::operator[]。operator[]非常容易在查找时误用因为遇到不存在的键它会把键插入进去。所以std::map对 const 对象不提供operator[]只提供at()和find()。如果你在 const 成员函数里顺手写了map_[key]编译器会直接报错改用map.find(key)才能保持只读。4. constexpr 与 const两兄弟不是一回事4.1 constexpr 变量的硬性要求编译期必须有值constexpr变量要求初始化式是常量表达式而且变量本身具备 const 语义。这意味着它可以在编译期被用于模板非类型参数、std::array大小、switchcase 标签等需要常量值的场景。constexpr int kBufferSize 1024; std::arrayint, kBufferSize buffer; // 没问题而const int只有在初始化式是常量表达式时才能做到同样的事情。比如下面的代码就不行int n; std::cin n; const int size n; // 合法但是运行时值 std::arrayint, size arr; // 编译错误所以“const 变量一定能当编译期常量”是完全错误的。我有时候在模板代码里看到有人用const int已经能在编译期使用是因为那个初始化式本身就是常量表达式编译器做了常量折叠而不是 const 带来的能力。C14 之后 constexpr 函数大大放宽支持局部变量和循环C17 引入了if constexpr让我们能在编译期按条件裁剪代码C20 又引入了consteval和constinit。这些工具逐渐把“编译期计算”变成了独立的编程范式。4.2 constexpr 函数与 const 函数的行为差异constexpr和 const 并不互斥一对典型的组合是“constexpr 成员函数 const 成员函数限定”struct Point { int x, y; constexpr int sum() const { return x y; } };这个sum()既可以在运行时像普通 const 函数一样调用也可以在编译期对 constexpr 对象求值。但要注意constexpr 函数不一定是成员函数也不一定是 const。比如一个constexpr int square(int x)是自由函数参数是普通的 int调用方式取决于实参是否为常量表达式。一个需要留意的点constexpr函数被调用时如果传入的参数不是常量表达式它也可以退化成普通函数在运行时执行在 C11/14 里是这样。如果你真的希望“只能编译期调用”那要用 C20 的consteval。这种退化的行为初看有点奇怪但它恰恰让同一套数学代码既能用于编译期元编程又能用于运行时计算减少了重复实现。4.3 C20 的 consteval 与 constinit更精确的初始化控制consteval声明的函数叫“立即函数”每次调用都必须产生编译期常量不允许在运行时调用consteval int triple(int x) { return x * 3; } constexpr int a triple(3); // 正确 int b 3; int c triple(b); // 编译错误非常量表达式它解决的是 constexpr 函数“既能编译期又能运行时”的模糊地带。如果某个算法为了性能必须编译期求值直接用consteval让编译器替你保证。constinit则是用来标记“静态存储期变量必须在编译期初始化”。它不要求变量本身是 const只是把初始化时机固定在编译期避免动态初始化顺序问题。比如constinit int g_counter 100; // 编译期初始化 // constinit int g_wrong rand(); // 编译错误在涉及全局变量初始化的老项目中constinit是很好的“契约声明”阅读代码时一眼就知道这不是运行时才赋值的。5. const_cast类型系统的“后门”与滥用边界5.1 什么时候才应该用 const_castconst_cast的唯一作用是去除表达式上的 const或 volatile。它不能做其他类型转换。但“能不能用”和“该不该用”是两个问题。我认为合法的使用场景非常有限主要分为两类第一类调用某个老旧 C 接口接口形参是char*或void*但函数语义上不会修改缓冲区。此时传入const_castchar*(str.c_str())是常见妥协。第二类在类的非 const 重载里复用 const 版本的逻辑这个我会在 5.3 细讲。除此之外大多数情况下使用const_cast都说明接口设计出了问题。尤其是在 C 新代码里如果你发现必须用const_cast才能编译先回头检查函数签名是否应该改成const T、const T*或者返回值是否应该改为 const 版本。5.2 修改“真正 const 对象”是未定义行为这是 const_cast 最容易被误解的地方。很多人以为const_cast可以像“撕掉封条”一样把 const 去掉然后随便改。实际上修改一个“原始对象本身就是 const”的对象是未定义行为。const int x 42; int* p const_castint*(x); *p 100; // 未定义行为 std::cout x; // 可能仍是 42也可能变还可能崩溃为什么是未定义行为因为编译器可能把x放进只读段也可能把x的所有读取都替换成常量 42。去掉 const 再写只是“骗过了类型系统”并没有改变编译器有权做的假设。但如果原始对象不是 const只是当前通过 const 引用访问那修改是合法的尽管不推荐void aura(const int v) { const_castint(v) 200; // 只有当实参本来就是非 const int 时合法 } int a 1; aura(a); // 合法但代码味道极差所以判断是否合法的标准不是“有没有 const_cast”而是“被指向的原始对象本质上是不是 const”。在项目里如果非用不可务必用注释标明“原始对象非 const这里仅去除参接口的 const”让后续维护者能快速判断风险。5.3 在重载函数中安全使用 const_cast 的设计模式当我们写一个同时提供 const 和 non-const 版本的接口时很容易陷入代码重复。比较优雅的方式是在 non-const 版本里调用 const 版本再用 const_cast 去掉返回值的 constclass Buffer { char* data_; public: const char at(size_t i) const { return data_[i]; } char at(size_t i) { return const_castchar( static_castconst Buffer(*this).at(i)); } };这里有两个关键点。第一static_castconst Buffer(*this)是为了让this变成 const 对象从而调用到 const 版本第二const_castchar负责去掉返回值的 const把它转成可变引用。这个模式是否安全安全。因为调用 non-constat的this本身不是 const所以原始对象不是 const返回的引用指向可变数据合法。反过来在 const 版本里调用 non-const 版本再试图通过 const_cast 改回来就非常危险因为你不知道这个 const 对象背后的原始对象是否真 const。我见过有人为了省事这么写结果某个 const 对象成员被意外修改整个模块的状态全乱了。记住这个安全方向non-const 版本去调用 const 版本而不是反过来。6. const 正确性在实际项目中的落地策略6.1 接口签名设计参数优先 const T返回要分清所有权工程上“const 正确性”的第一站就是函数签名。如果一个函数只需要读取参数不需要拷贝也不修改原对象那么参数写成const T通常是性价比最高的选择。它既能避免不必要的拷贝也能向调用者传递“我保证不会改你传进来的东西”的语义。std::string format(const std::string pattern) { // 只读 pattern不会修改外部对象 }但要注意不是所有场景都适合const T。对于int、double、指针这种便宜类型直接按值传反而更清晰。对于需要保留副本并修改的场景按值传入再 move 也是 C11 之后的惯用法。我在真实项目里见过一种糟糕的写法函数参数是const std::vectorint但函数内部要修改这个 vector于是事后再拷贝一份。这种情况下应该直接按值接收让调用方用std::move转移所有权内部直接用参数省掉一次深拷贝。返回值方面如果返回的是“指向内部成员”的引用const 版本返回const T可以保护封装性非 const 版本返回T则允许修改。如果返回的是临时对象或通常不指向成员那返回值本身不要加 const否则 C17 之前会影响移动语义而且调用者拿到的是 const 临时对象有时无法调用非 const 方法。6.2 const 与移动语义的隐藏冲突const 对象 move 不出来“const 会阻碍移动”这一点可以说是现代 C 里最容易翻车的地方。道理很简单移动本质上要修改原对象把它的资源“掏空”而 const 对象不允许修改。所以对 const 对象做std::move不会真的移动它会退化成一次拷贝。void take(std::vectorint v); const std::vectorint heavily_computed compute(); take(std::move(heavily_computed)); // 不是零成本而是深拷贝这是因为std::move本质是“无条件的右值转换”但heavily_computed的类型是const std::vectorint转换后是const std::vectorint匹配不到std::vectorint的移动构造函数只能匹配const std::vectorint的拷贝构造函数。所以如果你有一个大对象后续不再需要它请不要用const去绑定它。正确做法是让变量保持非 const然后直接std::move出去。反过来说如果你的函数就是需要“读取但保留”那 const 没有错但别指望 move 能带来优化。这个坑在返回容器、缓存结果、临时拼接字符串时非常容易出现。6.3 常见 const 误用模式与检查清单我把项目里常见的 const 误用分成四类大家可以对号入座。忘记给成员函数加 const对象被 const 引用传递时连读操作都做不了调用方只能被迫去掉 const 复杂度。用 mutable 掩盖真正的状态修改缓存和锁可以用 mutable但把用户可见的业务字段标 mutable 就是拆自己的防线。用 const_cast 绕开 const 来“省事”一旦绕开编译器就不再信任你的承诺后续优化和行为都不可控。返回值加 const 导致移动失效比如const std::string get_name();会让auto name obj.get_name();发生拷贝虽然可能不是每次都错但肯定不如去掉 const 干净。我在团队里推行过一个简单自测写一个成员函数时先问“这个函数会不会被 const 对象调用如果不能是因为它内部修改了成员还是只是忘了加 const”如果是前者保持非 const如果是后者立刻补上。这个习惯能减少特别多编译期错误和运行时隐患。静态分析工具也能帮上忙。像 clang-tidy 有一组检查专门提示“能否将函数标记为 const”“是否误用了 const_cast”等。把它们接入 CI比靠人肉 review 可靠得多。但工具只是辅助最重要的还是建立“const 是接口契约”这一认知。7. 编译器视角const 对优化和 ABI 的影响7.1 const 真的能带来性能提升吗这个问题常被简化成“加 const 就快”。实际上要看场景。局部const变量的优化收益往往来自常量折叠和后续使用时的直接替换。比如const double pi 3.14159265358979; double area pi * r * r;如果编译器能看到pi的初始化且确认它不会变完全可能把pi直接替换成立即数减少加载内存的开销。但注意前提是“编译器能看到且确认不会变”。一旦对象的地址传到了外部或者被某个可能修改它的函数使用编译器就不能做激进假设。全局const变量有可能被放进只读数据段并允许更多跨函数的优化但它们大多数情况下不开洞。用const_cast去修改这个只读变量轻则无效重则段错误。所以从优化角度讲const 的真正价值更多是“使代码的意图明确让编译器有更多自由发挥的空间”而不是一个可以量化的性能开关。把 const 当成优化手段不如把它当成设计手段。7.2 const 成员函数与线程安全const 不等于 thread-safe很多人以为 const 成员函数可以安全地并发调用因为“只读”嘛。这个想法很危险。const 只保证“不修改逻辑可观察状态”但不保证内部没有共享的可变状态。典型例子是使用了 mutable 缓存的类两个线程同时进入 const 函数其中一个正在写缓存另一个在读缓存这就是数据竞争行为未定义。正确的做法是如果 const 函数内部会修改 mutable 成员必须自己加锁或使用原子操作。C 标准库容器的 const 成员函数通常允许并发读取比如两个线程同时调用vector::begin() const没问题但只要有一个线程通过非 const 版本修改结构就立刻产生竞争。所以在多线程代码里“const 接口”只是参与线程安全设计的其中一环线程安全需要额外的同步注释和实现保障。class SharedCache { mutable std::mutex mtx_; std::unordered_mapint, int cache_; public: int get(int key) const { std::lock_guardstd::mutex lk(mtx_); auto it cache_.find(key); return it cache_.end() ? -1 : it-second; } };这个类的get虽然是 const但因为内部有互斥锁所以它可以安全地被多个线程并发调用。const 在这里只负责“接口只读”锁负责“数据同步”。7.3 const 与虚函数、继承的冲突比想象中多当 const 参与虚函数重写时const 限定是函数签名的一部分也就是说基类里的virtual void describe() const;和派生类里的void describe();不是同一个函数。如果你在派生类里写了非 const 版本大概率是新增了一个同名函数而不是覆写基类虚函数。更隐蔽的是通过 const 引用调用时会走到基类的 const 版本通过非 const 引用调用会走到派生类的非 const 版本两个版本各自干各自的事行为非常分裂。struct Base { virtual void describe() const { std::cout base const\n; } }; struct Derived : Base { void describe() { // 注意没有 override std::cout derived non-const\n; } }; const Base b Derived{}; b.describe(); // 输出 base const如果你希望派生类同时覆盖“const 版本”和“非const 版本”必须成对地重写。而现代 C 里用户在派生类签名上漏掉 const 是很常见的事好在只要加上override关键字编译器就会立刻告诉你哪里不匹配。所以我建议所有需要覆写的派生类虚函数一律写 override编译报错时先检查 const 限定是否与基类完全一致。从 ABI 角度看const 非 static 成员函数的 this 指针类型不同符号修饰会带上 const所以两个重载在底层是不同符号。这也是为什么 const 重载可以存在于导出库中不会导致符号冲突。了解这一点在排查动态库链接错误时会有帮助。我自己在实际开发里的体会是不要等到编译报错才想起 const要在写类和函数签名时就把 const 当成接口契约来设计。每次加完一个成员函数都问一遍“这个函数应该允许 const 对象调用吗”。如果答案是不应该就明确保持非 const如果应该就立刻补上 const。这个习惯坚持几个月你会发现自己写出来的接口在 const 场景下稳如磐石重构时不再被“为什么这里过不了编译”折磨。最后再分享一个小技巧遇到复杂的 const 指针声明不要凭记忆猜直接丢到decltype和static_assert里验证意图编译器会告诉你真正的类型。这个做法虽然听起来笨但在维护遗留代码时特别管用。