const、volatile、mutable 这三个关键字，我每次带新人都要单独拎出来拆一遍。原因不复杂：很多人写了两年 C++，依然把它们当成同一类东西——都是"修饰符"，加在变量前面就完事了。实际上这三个词压根不在一个维度上工作。const 处理的是接口契约和类型系统的问题，它决定了"谁有资格改这块内存";volatile 处理的是编译器和硬件之间的信任问题，它决定了"编译器敢不敢对你的读写做手脚";mutable 处理的是 const 语义在逻辑层面留下的一个补丁,它决定了"一个被声明为 const 的对象，到底还有没有内部可变空间"。这三者的边界一旦搞混，写出来的代码要么编译不过，要么编译过但在高并发、嵌入式、性能敏感场景里悄悄地错。下面我把这三个关键字从本质到实操一层层拆开，代码示例全是能直接编译运行的，坑也都是真实会遇到的。
1. 先划清边界：三个关键字根本不在一个层面上
1.1 const 管的是"接口契约"，不是"内存不可写"
很多人对 const 的第一反应是"这块内存不能改"。这个理解在语义层面是对的，但在实现层面容易走偏。const 的本质是类型系统层面的一种承诺：当你把一个对象声明为 const，你是在告诉编译器"从这个名字出发，我不会对它做写操作"。注意措辞——是"从这个名字出发"，不是"这块内存永远不变"。
这就解释了一个经典现象：同一个对象，通过 const 引用看到的是只读视图，通过非 const 引用看到的却是可写视图。看这段代码：
int value = 42; const int& cref = value; // 通过 cref 不能写 int& mref = value; // 通过 mref 可以写 mref = 100; std::cout << cref << "\n"; // 输出 100cref声明的时候value是 42，mref改完之后cref读出来变成 100 了。这不矛盾，因为 const 约束的是访问路径，不是存储实体。编译器看到cref时不会去读内存，它可能在优化阶段把cref直接替换成 42，因为"const 对象不会变"是它被授权的假设。但如果你用非 const 路径改了，这个假设就破了，程序进入未定义行为。
所以有一条铁律要刻在脑子里：不要用 const_cast 去掉 const 之后去写一个原本就是 const 的对象。原文是 const 的，你强转之后写它，标准管这叫 UB，编译器怎么优化都合法。原文不是 const、只是通过 const 引用传进来的，强转之后写是允许的——但这种设计本身就很脏，工程里应该尽力避免。
1.2 volatile 管的是"编译器别自作聪明"，和线程安全没关系
volatile 的中文常被翻成"易变的"，这个翻译害了不少人。它真正表达的是"这个对象的每一次访问都必须真实发生，不许被优化器合并、删除、缓存"。
来看优化器会干什么坏事。假设有这么一段轮询代码：
bool flag = false; void wait_for_flag() { while (!flag) { // 空循环等待 } }如果flag不是 volatile，编译器看到循环体里没有任何东西修改flag，完全可以把!flag提到循环外面只读一次，变成"如果 flag 一开始是 false，就死循环"，甚至整个循环被优化成if (!flag) while(true);。这在单线程里没问题——逻辑上flag确实不会变。但如果有另一个执行流（中断处理、信号处理、硬件 DMA）会改它，这个优化就是致命的。
加上 volatile 之后：
volatile bool flag = false; void wait_for_flag() { while (!flag) { // 每次循环都必须重新从内存读取 flag } }编译器被强制每次都生成真实的内存读取指令。注意，它只保证"读发生"，不保证"读是原子的"，更不保证"读和读之间有内存屏障"。这一点是新手最容易踩的坑，我在第 3 节会详细展开。
1.3 mutable 管的是"逻辑常量不等于物理常量"，是给 const 打的补丁
mutable 的场景特别具体：你有一个成员函数被声明为 const，从外部看这个对象不会改变，但函数内部确实需要改某个成员。这时候怎么办？标准给的答案是：把这个成员声明为 mutable。
class QueryResult { public: // 从外部看，这个函数不改变对象状态 const std::string& get_text() const { if (!cached_) { text_ = expensive_compute(); // 编译错误！const 函数里不能改成员 cached_ = true; } return text_; } private: std::string text_; bool cached_ = false; };上面这段代码编译不过，因为get_text()是 const 成员函数，里面的this指针类型是const QueryResult*，所有非 mutable 成员都被视为 const，text_ = ...直接报错。把text_和cached_声明为 mutable 就好了——从外部视角看，get_text()依然是一个"不改变对象可观察状态"的操作，缓存只是内部实现细节。
这三个关键字的定位用一句话概括：const 是给接口看的，volatile 是给编译器看的，mutable 是给 const 成员函数内部用的。接下来逐个深挖。
2. const 的全貌：从变量到成员函数的六种变形
2.1 const 变量的编译期与运行期两条命
const int a = 10;这一行里，a到底是不是编译期常量？答案取决于初始化表达式。规则在 C++ 标准里写得很清楚：只有整型或枚举类型的 const 变量，且初始化表达式本身是常量表达式时，它才是编译期常量。
const int a = 10; // 编译期常量，可以用作数组大小 const int b = a + 5; // 也是编译期常量 int x = 3; const int c = x; // 运行期只读，不能当数组大小 const double d = 3.14; // 浮点 const 不是整型常量表达式，不能当数组大小const int c = x;这一行，c的值在编译期未知，编译器给它分配了存储，只是标记成只读。你在函数内部拿它当数组维度，编译器会报"不是常量表达式"。
到了 C++11 之后，想要明确"我就是要编译期常量"，请用constexpr：
constexpr int a = 10; // 明确编译期 constexpr int square(int n) { return n * n; } constexpr int s = square(5); // 编译期求值constexpr隐含 const，但 const 不隐含 constexpr。这是两件事：const 说的是"我不能被改"，constexpr 说的是"我在编译期就能算出来"。C++20 又加了constinit，管的是"静态存储期对象必须在编译期完成初始化"，那是另一个话题，这里不展开。
实操里有个高频误区：把const当成性能优化开关。const本身不带来任何运行时性能收益，它的价值在于——给编译器更多信息以做优化（比如把常量传播到使用点）、给调用方明确契约、帮你提前发现 bug。真正能吃到的性能红利来自constexpr，因为那才把计算从运行期搬到了编译期。
2.2 顶层 const 与底层 const：指针这块必须掰清楚
指针和 const 组合会产生三种写法，加上"顶层/底层"的概念，这是 C++ 面试里出镜率最高的组合之一。先看形式：
| 写法 | 含义 | 能改指针指向 | 能改所指内容 |
|---|---|---|---|
const int* p | 指向常量的指针 | 可以 | 不可以 |
int* const p | 常量指针（指针本身是 const） | 不可以 | 可以 |
const int* const p | 指向常量的常量指针 | 不可以 | 不可以 |
记忆口诀是"const 在*左边管内容，在*右边管指针"。const int*和int const*完全等价，都是 const 修饰int，不是修饰指针。
现在引入"顶层/底层"的术语。顶层 const 指的是对象本身是 const，底层 const 指的是指针或引用所指的对象是 const。看：
int i = 0; int* const p1 = &i; // 顶层 const：p1 本身不能改 const int ci = 42; // 顶层 const：ci 本身不能改 const int* p2 = &ci; // 底层 const：p2 指向的内容不能改，但 p2 可以改 const int* const p3 = p2; // 左边底层，右边顶层 const int& r = ci; // 用于声明引用的 const 都是底层 const这个概念为什么重要？因为它决定了拷贝操作是否合法。规则是：顶层 const 在拷贝时被忽略，底层 const 必须匹配。
int* p = &i; const int* p2 = p; // 合法：int* 可以转 const int* int* p3 = p2; // 非法：const int* 不能转回 int* int* p4 = p1; // 合法：p1 的顶层 const 被忽略函数参数传递时这条规则天天在起作用。一个void f(const std::string&)的接口，传进去std::string和const std::string都行；但一个void g(std::string&)的接口，传const std::string就报错，因为底层 const 不匹配。
2.3 const 成员函数：this 指针的底层 const 化
成员函数后面跟个 const，究竟改变了什么？答案很简单：它把this指针的类型从T* const变成了const T* const。也就是说，原本 this 是一个"本身不能改、指向可改对象"的指针，加了 const 之后变成"本身不能改、指向也不可改对象"的指针。
class Counter { public: int get() const { // this 类型：const Counter* const return count_; // 只读访问，OK } void inc() { // this 类型：Counter* const ++count_; // 可写，OK } void bad() const { ++count_; // 编译错误：不能通过 const this 修改成员 } private: int count_ = 0; };这个机制带来的最重要能力是基于 const 的重载：
class Buffer { public: char& operator[](size_t i) { return data_[i]; // 非 const 版本返回可写引用 } const char& operator[](size_t i) const { return data_[i]; // const 版本返回只读引用 } private: std::vector<char> data_; };调用方拿到的对象如果是 const 的，就只能调 const 版本，拿到的引用也是 const 的；非 const 对象就调用非 const 版本。这套机制让"只读访问"从运行期检查前移到了编译期检查。
这里有个经典坑：const 成员函数返回成员的非 const 引用。
class Holder { public: std::vector<int>& get() const { return data_; } // 编译通过，但很危险 private: mutable std::vector<int> data_; // 只有 mutable 才能这样写 };更常见的是没加 mutable 但返回了指针的情况：
class Bad { public: int* get() const { return ptr_; } // 编译通过 private: int* ptr_; // 指针本身不是 const，指向的内容可以透过 const 函数改 };get()是 const 成员函数，ptr_的类型是int* const（因为 this 是 const 的），你返回int*就是把一个 const 视图变成了可写视图。调用方拿到指针之后，可以把整个对象的数据改得面目全非，而"函数是 const"这个承诺就形同虚设。所以工程里约定：const 成员函数返回的指针或引用，要么指向 const，要么只返回由值语义管理的数据。
2.4 const 修饰返回值：什么时候有用、什么时候是噪音
const修饰函数返回值，对内置类型基本是噪音：
const int f(); // 返回值是右值，加 const 没意义但对自定义类型，它可以阻止一种特定的错误：
class Rational { /* ... */ }; const Rational operator*(const Rational& a, const Rational& b); // 使用方： Rational a, b, c; (a * b) = c; // 如果返回值是 const，这行编译报错a * b产生一个临时对象（右值），正常情况下你不该给它赋值。返回const Rational之后，这种手滑就被编译器拦住了。不过 Google 的 C++ 规范明确建议不要给返回值加 const，理由是它会破坏移动语义（const Rational无法被移动，只能拷贝）。我个人倾向这条建议：用现代 C++ 的右值引用和std::move更彻底，返回值加 const 是旧时代的补丁。
2.5 constexpr、consteval、constinit 三兄弟的分工
| 关键字 | 引入版本 | 作用 | 典型用法 |
|---|---|---|---|
const | C++98 | 只读承诺，运行期或编译期 | 接口参数、成员函数 |
constexpr | C++11 | 可参与编译期求值 | 常量表达式、编译期计算函数 |
consteval | C++20 | 强制编译期求值 | 只能在编译期调用的函数 |
constinit | C++20 | 强制静态初始化 | 全局对象初始化顺序控制 |
举个constexpr实用例子——编译期计算哈希，避免运行期字符串比较开销：
constexpr uint32_t fnv1a(const char* s, uint32_t h = 2166136261u) { return *s ? fnv1a(s + 1, (h ^ static_cast<uint8_t>(*s)) * 16777619u) : h; } constexpr uint32_t tag = fnv1a("player_id"); // tag 的值在编译期就算出来了，运行时零开销这段代码在 switch 语句里做字符串分发特别实用，比运行期算哈希快一个数量级。const在这里是不够的，因为const uint32_t tag = fnv1a("player_id");里fnv1a不是 constexpr 函数的话，编译期根本算不出来。
3. volatile 的正确打开方式：它不是万金油
3.1 编译器到底会怎么"优化"你的代码
理解 volatile 之前，先得知道优化器会干什么。以一个典型场景为例：
// 硬件状态寄存器，假设映射到 0x4000'0000 uint32_t* status_reg = reinterpret_cast<uint32_t*>(0x40000000); void poll() { while ((*status_reg & 0x1) == 0) { // 空转等待硬件置位 } }这段代码在-O2下会被优化成无限循环。因为编译器看到status_reg指向的内容在循环体内没有任何修改语句，它有理由认为这个表达式的值不变，于是把读取提到循环外面。硬件那边确实会改这个地址的值，但编译器不知道也不关心。
正确的写法是：
volatile uint32_t* status_reg = reinterpret_cast<volatile uint32_t*>(0x40000000); void poll() { while ((*status_reg & 0x1) == 0) { // 每次循环都会真实读一次内存 } }加上 volatile 之后，每次*status_reg都会被翻译成一条真实的内存读取指令。这是 volatile 存在的唯一核心理由：告诉编译器"这个地址的内容可能被编译器看不到的力量修改"。
优化器在 volatile 面前会收敛的三种行为：
- 不合并重复读取。连续两次读同一个 volatile 变量，会生成两条读取指令，不会合并成一条。
- 不删除看似无用的写入。写一个 volatile 变量，哪怕后面没人读，编译器也保留这次写。
- 不跨 volatile 访问重排有依赖的读写。注意是"有依赖的"，无依赖的读写顺序标准也不保证（这是下一小节的重点）。
3.2 经典误用：volatile 不等于 atomic，更不等于内存屏障
这是我在实际项目里踩过的最深的坑。先看一段错误代码：
volatile int counter = 0; void worker() { for (int i = 0; i < 100000; ++i) { ++counter; // 多线程下这是错的！ } }++counter是"读-改-写"三步，volatile 只保证每一步都真实发生，不保证三步之间的原子性。两个线程同时执行这一步，存在指令交错窗口，最终结果会小于预期。正确的做法：
#include <atomic> std::atomic<int> counter{0}; void worker() { for (int i = 0; i < 100000; ++i) { counter.fetch_add(1, std::memory_order_relaxed); } }还有一个更隐蔽的误用：拿 volatile 当"线程间标志位"。
volatile bool ready = false; int data = 0; // 线程 A void producer() { data = 42; ready = true; // 想让 B 看到 data 的新值 } // 线程 B void consumer() { while (!ready) {} use(data); // data 真的是 42 吗？不一定 }问题在于：volatile 的ready = true不构成内存屏障，CPU 或编译器可以把data = 42重排到ready = true之后。B 看到ready变 true 时，data可能还没写进去。这段代码的正确写法必须用 atomic 加 release/acquire：
#include <atomic> std::atomic<bool> ready{false}; int data = 0; void producer() { data = 42; ready.store(true, std::memory_order_release); } void consumer() { while (!ready.load(std::memory_order_acquire)) {} use(data); // 一定能看到 42 }release 语义保证了 store 之前的所有写操作对 acquire 的读取方可见，这是 volatile 给不了的。所以工程上的硬规矩：跨线程同步一律用std::atomic或互斥量，volatile 只在编译器优化边界有意义，绝不能用它做线程间通信。
3.3 volatile 真正适用的三类场景
抛开多线程这个高频误区，volatile 真正有不可替代价值的地方其实就三类：
第一类是内存映射 I/O 寄存器，也就是上面说的硬件状态轮询。这类场景的特点是你读写的是一个真实存在的硬件地址，它的变化不受程序控制。嵌入式、驱动开发里天天用。
第二类是信号处理函数里访问的变量。标准里专门规定：信号处理函数（signal/sigaction注册的那种）能安全访问的，只有volatile sig_atomic_t类型的变量。
#include <csignal> volatile sig_atomic_t g_stop = 0; void on_signal(int) { g_stop = 1; } int main() { std::signal(SIGINT, on_signal); while (!g_stop) { // 主循环 } }第三类是setjmp/longjmp 之间被修改的局部变量。这条比较冷门，标准规定那些在 setjmp 和 longjmp 之间被改过的非 volatile 局部变量，longjmp 之后值是不确定的。不过现代 C++ 基本不用这套东西，用异常或 RAII 替代，这条基本只剩考古价值。
除了这三类，其他任何场景下看到 volatile，大概率是写错了。特别是"防止编译器优化掉变量"这种说法——编译器不会优化掉你有实际可观察行为的代码，真正被"优化掉"的，都是以你的视角看没有副作用、但从硬件或信号视角看有副作用的访问，那才是 volatile 该出场的场合。
3.4 volatile 对象拷贝语义的特殊限制
volatile 对象在拷贝上有额外的坑。标准里规定，类的拷贝构造函数和拷贝赋值运算符的参数不能是 volatile 引用，因为标准库和编译器默认生成的版本都没有考虑 volatile 场景。
volatile int a = 10; int b = a; // 合法：整型可以直接读 // volatile std::string s = "..."; // std::string t = s; // 编译错误：没有接受 volatile 的拷贝构造对自定义类型，你得手动为 volatile 场景写重载，或者显式逐成员读取。这也是为什么容器类型、智能指针这类模板类里，你几乎看不到 volatile 支持——几乎没人需要把智能指针声明成 volatile，需要的话一般也是对裸指针本身加 volatile。
4. mutable 的边界：不是"随便改 const 成员"
4.1 mutable 的语义本质：用逻辑常量性换物理常量性
const 成员函数的契约是"从外部观察，对象状态不变"。这个"观察"是逻辑层面的，不是物理层面的。mutable 就是官方承认的一个漏洞：允许对象在物理上改变某个成员，只要改变不影响外部可观察的状态。
经典场景有三个，我把代码都写出来对照着看。
场景一：缓存计算结果。
class ExpensiveData { public: double average() const { if (!avg_valid_) { double sum = 0; for (auto v : values_) sum += v; cached_avg_ = sum / values_.size(); avg_valid_ = true; } return cached_avg_; } void append(double v) { values_.push_back(v); avg_valid_ = false; // 非 const 函数里正常失效缓存 } private: std::vector<double> values_; mutable double cached_avg_ = 0; mutable bool avg_valid_ = false; };average()是 const 的，外部看起来对象没变，但内部缓存被填上了。为什么这个设计合理？因为"有没有算过缓存"对外不可观察——第一次调用和第二次调用返回的值完全一样，副作用藏在内部。如果cached_avg_不加 mutable，average()就没法声明成 const，调用方拿到的 const 对象就无法求平均值，整个接口的完整性就破了。
场景二：mutable 互斥量。这是标准库里std::mutex的官方用法：
class ThreadSafeCounter { public: void increment() { std::lock_guard<std::mutex> lock(mutex_); ++count_; } int get() const { std::lock_guard<std::mutex> lock(mutex_); // 需要锁住 mutable 的 mutex return count_; } private: mutable std::mutex mutex_; // 不加 mutable 这里编译不过 int count_ = 0; };get()是 const 的，但从外部看它是"读取当前计数"，锁的获取和释放属于内部同步细节，不改变对象的逻辑值。std::mutex::lock()是非 const 的，所以mutex_必须声明为 mutable。
场景三：调试计数器、访问追踪。
class ApiEndpoint { public: void handle() const { ++call_count_; // 只用于统计，不影响业务状态 // ... } size_t call_count() const { return call_count_; } private: mutable size_t call_count_ = 0; };这个场景要慎重——如果把这种"副作用"暴露给了外部（比如call_count被外部读取并改变行为决策），那严格来说它就破坏了 const 语义，不该用 mutable 打补丁，而应该重新设计。
4.2 mutable 的两个硬限制
第一，mutable 不能修饰 static 成员。标准明确禁止这个用法：
class A { mutable static int x; // 编译错误 };原因很好理解——static 成员不属于任何对象，const 成员函数约束的是 this 指针，跟 static 成员毫无关系，所以没理由也没法用 mutable 破例。
第二，mutable 不改变对象的物理布局之外的任何东西。它只影响编译器在 const 成员函数内部是否允许你修改那个成员。它不会让对象"变成非 const"，也不会改变整个对象的只读性。
class A { public: void bad() const { x_ = 1; // 编译错误 y_ = 2; // 编译通过（mutable） } int x_ = 0; mutable int y_ = 0; }; const A a; a.y_ = 3; // 编译错误：a 本身是 const 对象注意最后一行——mutable 只在 const 成员函数内部有效，对外部 const 对象没有任何特权。很多人以为声明了 mutable 就能从外部改，那是误解。
4.3 mutable 的滥用信号
mutable 一旦用得不对，就会变成"为了通过编译而加的补丁"。临时的几个滥用信号，看到就该警觉：
- const 成员函数里做了业务操作。比如
commit()、flush()、close()这类明显是修改状态的函数被声明成 const，然后靠 mutable 硬塞。这说明 const 修饰本身是错的。 - mutable 成员被外部读取。缓存是内部实现细节，如果外部代码需要读
cached_avg_这种字段来判断什么逻辑，说明你在把一个本该是物理状态的成员伪装成逻辑状态。 - mutable 成员在多线程里没加锁。这是最隐蔽的一类 bug。
get_text() const内部改缓存，如果两个线程同时调它，就是数据竞争。上面的ThreadSafeCounter之所以安全，是因为 mutex 挡住了。缓存场景里，如果你没给缓存加锁，就得保证调用方都在单线程环境，或者用std::once_flag、atomic 变量之类的机制。
5. 三者交叉场景与实战踩坑
5.1const volatile组合：只读硬件寄存器
const 和 volatile 可以同时修饰一个对象，语义是"我读它，但不能写它，而且每次读都必须真实发生"。这个组合在嵌入式里极其常见，用于映射只读的状态寄存器：
// 只读的硬件状态寄存器 const volatile uint32_t* status = reinterpret_cast<const volatile uint32_t*>(0x40001000); uint32_t read_status() { return *status; // 每次都真实读取，且不允许写 }这种组合下，*status的读取不能被优化掉，也不能透过这个指针写入。注意不能写成reinterpret_cast<volatile uint32_t*>再让调用方读——那样就少了一层写保护。这个场景里 const 和 volatile 各司其职，一个负责访问权限，一个负责优化边界，没有任何冲突。
5.2 用 mutable 成员实现 const 成员函数的线程安全
上面ThreadSafeCounter的例子展开讲讲。很多人在设计 const 成员函数时容易忘掉"const 函数也可能被多线程同时调用"这件事：
class Config { public: std::string get(const std::string& key) const { // 没有加锁的话，下面这个缓存会被并发写坏 if (cache_.count(key) == 0) { cache_[key] = fetch_from_disk(key); } return cache_[key]; } private: mutable std::map<std::string, std::string> cache_; };这段代码在单线程下跑得好好的，上了多线程就会在cache_的插入和读取之间出数据竞争。修复方案有两个：给 cache 加mutable std::shared_mutex（C++17 起可用），读操作走 shared_lock，写操作走 unique_lock；或者更简单，在调用层就不共享这个 Config 对象。我倾向于后者——如果缓存真的是每线程私有的，那就干脆别做共享，避免不必要的锁开销。
5.3 const 成员函数与非 const 成员函数的重载陷阱
const 与非 const 版本的重载可以正常工作的前提是：你确实有两个版本。有些场景下两个版本的行为不一致会导致意外：
class Data { public: std::string& name() { return name_; } const std::string& name() const { return name_; } private: std::string name_; };这本身是标准做法。但如果你在 const 版本里返回了成员的非 const 引用（前面举过的坑），重载就变成了摆设。还有一种更隐蔽的情况：通过const_cast在 const 版本里复用非 const 版本，这也是标准库里经常用的技俩：
class TextBlock { public: const char& operator[](size_t pos) const { // 各种边界检查 return text_[pos]; } char& operator[](size_t pos) { // 复用 const 版本，省去重复的边界检查 return const_cast<char&>( static_cast<const TextBlock&>(*this)[pos] ); } private: std::string text_; };这里的const_cast是安全的，因为调用的是非 const 版本，*this本身不等于 const 对象，强转之后的写操作是允许的。这个技巧在标准库实现里大量使用，但要写两层 cast（先 static_cast 加 const 调 const 版本，再 const_cast 去掉返回值上的 const），写错一个就出 UB。
5.4 一张表总结三者的选择依据
| 你的需求 | 该用的关键字 | 关键理由 |
|---|---|---|
| 接口只读，不允许调用方修改 | const | 类型系统检查，编译期拦截 |
| 编译期计算，零运行时开销 | constexpr | 把计算搬到了编译期 |
| 变量被编译器看不到的力量修改 | volatile | 阻止优化器合并、删除访问 |
| 硬件寄存器只读 | const volatile | 两者职责独立，各管一面 |
| const 成员函数内部需要修改成员 | mutable | 用逻辑常量性换物理可变性 |
| 多线程间同步数据 | std::atomic | volatile 不保证原子性和内存序 |
| const 对象里缓存计算结果 | mutable+ 加锁 | 缓存是内部实现，锁保护并发访问 |
6. 常见问题速查与排查实录
6.1 编译错误速查
| 报错信息关键词 | 大概率原因 | 修法 |
|---|---|---|
assignment of read-only variable | 改了一个 const 变量或 const 引用 | 检查声明，确需修改就改设计 |
passing 'const X' as 'this' argument discards qualifiers | const 对象调了非 const 成员函数 | 给成员函数加 const，或者对象本不该 const |
invalid conversion from 'const char*' to 'char*' | 底层 const 不匹配 | 用 const 版本接收，或复制一份再改 |
no matching function for call to 'X::X(volatile X&)' | 拷贝构造不接受 volatile | 逐成员读取，或显式强转后拷贝 |
binding reference of type 'int&' to 'const int' | 想用非 const 引用绑定 const 值 | 改成 const 引用 |
6.2 运行期行为异常的排查思路
现象一：加了 volatile 还是偶发死循环。先确认 volatile 加对了位置——volatile int* p和int* volatile p完全是两回事，前者才是"指向 volatile 的指针"。再看循环体的其他变量，如果循环条件依赖了多个变量，每个都必须处理。
现象二：多线程下读取到的值"是旧的"。这是典型的缺内存屏障。volatile 不解决这个问题，换成 atomic 加正确的 memory_order。如果数据是一个结构体而不是单变量，典型做法是和版本号或者 atomic 标志配合使用。
现象三：const 成员函数返回的对象被意外修改。检查函数返回的是不是非 const 指针或引用，尤其是成员里有裸指针的时候。建议一律返回 const 引用或按值返回。
现象四：mutable 缓存偶发数据竞争。-fsanitize=thread是排查这类问题的利器，编译加参数-fsanitize=thread -g -O1，跑一遍多线程测试用例，能直接定位到具体的内存访问冲突位置。
6.3 几条踩坑实录
第一条：const_cast之后写 const 对象是 UB，编译器不会报错，跑起来可能一切正常。这是最坑的地方——UB 不保证立刻崩溃，它可能在某个特定优化等级下暴露，比如-O3之后突然输出错误结果。在调试构建下怎么测都对，上线之后偶发崩溃，定位成本极高。所以const_cast要当"手术刀"用，看到就审查。
第二条：volatile 会让编译器放弃某些向量化优化，但不会带来你想要的多线程安全。曾经在一个图像处理项目里，有人把所有共享的像素缓冲区指针声明成 volatile 来"防止数据竞争"，结果性能掉了 40%，数据竞争依然存在。后来全部改成std::atomic加无锁队列，问题才解决。
第三条：mutable 缓存不要和浅拷贝类混用。如果类自己管理了堆内存又写了自定义拷贝构造，把缓存成员声明成 mutable 会导致拷贝时缓存状态不一致。要么缓存不参与拷贝（写默认值），要么在拷贝构造里显式重置，别指望默认行为正确。
6.4 一个完整的判据清单
每次决定要不要加这三个关键字时，我心里过一遍这个清单：
- 这个接口承诺"不改变对象状态"吗？是——加
const到成员函数上，参数统一用 const 引用。 - 这个函数内部需要修改某个成员来实现缓存或同步吗？需要——那个成员加
mutable，同时想想它会不会被多线程共享，会不会被外部读到。 - 这个内存地址的内容会被编译器之外的力量改变吗？会——加
volatile，并且想清楚是读还是写，还是两者都有。 - 这个变量要做跨执行流同步吗？是——用
std::atomic或者互斥量，volatile完全不参与。 - 这个函数/表达式需要在编译期求值吗？需要——用
constexpr或 C++20 的consteval，不要用const凑合。
这套判据我用了几年，基本没在 const 和 volatile 上犯过类型错误。剩下的都是设计层面的取舍——比如缓存到底该不该用 mutable——那个没有标准答案，得看你对"逻辑常量性"的定义边界划在哪里。我自己在实际使用中的一个体会是：mutable 用得越少越好，每加一个就说明你的对象承担了越多职责；真正设计得好的类，往往根本用不上 mutable。
