mutable是唯一合法出口，因为const成员函数中this指针为const X*，非mutable成员只读，强行修改触发编译错误，而mutable显式声明例外，不破坏逻辑常量性。
const成员函数里想改某个变量，为什么mutable是唯一合法出口
因为C++标准规定：在const成员函数中，this指针的类型是const X*，所有非mutable成员都被视为只读。强行修改会触发编译错误，比如error: assignment of member 'counter' in read-only object。而mutable显式告诉编译器：“这个成员例外，允许被const函数修改”——它不破坏对象的逻辑常量性，只绕过语法检查。
哪些变量适合加mutable：缓存、计数器、互斥锁
加mutable不是为了偷懒绕过const，而是为那些“不影响对外可见状态”的内部辅助数据留出修改通道：
-
mutable std::mutex mtx_;：多线程下const函数仍需加锁，锁本身不改变对象语义 -
mutable int call_count_ = 0;：仅用于调试或监控，调用get_value() const时顺便自增，不改变返回值 -
mutable std::optional：惰性计算缓存，cached_result_; const函数首次调用时写入，后续直接返回，外部无法感知是否已缓存
mutable不能解决所有问题：它不跨线程安全，也不掩盖设计缺陷
mutable只是解除编译器对单个成员的写保护，它不做任何同步、不保证原子性、不处理重入：
- 如果
mutable std::vector在多线程中被多个cache_; const函数并发修改，依然要自己加锁——mutable不等于线程安全 - 把本该非
const的逻辑（比如修改业务状态）硬塞进const函数并用mutable修饰对应变量，属于设计倒置，会误导调用者 -
mutable成员不能是引用或const类型（如mutable const int x;非法），也不能是未定义析构行为的类类型（需确保析构安全）
和const_cast对比：为什么mutable更安全、更意图明确
有人试图用const_cast在const函数里强转this来修改普通成员，但这是危险且不可靠的：
立即学习“C++免费学习笔记（深入）”；
- 若对象本身以
const方式创建（如const Obj o;），通过const_cast修改将触发未定义行为 -
const_cast作用域模糊，审查代码时无法快速识别“这里究竟改了什么”，而mutable声明直接挂在变量上，一目了然 - 编译器可能对
mutable成员做特殊优化（比如不参与const对象的静态初始化顺序约束），但对const_cast无此保障
真正容易被忽略的是：mutable成员的初始化必须在构造函数的成员初始化列表中完成，不能等到构造函数体里赋值；另外，序列化或反射框架若未显式支持mutable，可能漏掉这些字段——它们看起来“不该变”，但其实一直在变。
