mutable修饰的成员变量可在const成员函数中修改，用于缓存、调试标记、线程同步等不改变对象逻辑状态的场景，且无运行时开销；未加mutable则编译报错。
const 成员函数里想改某个成员变量，必须用 mutable
不是所有成员都能在 const 函数里改，只有加了 mutable 修饰的才行。它本质是告诉编译器：“这个变量逻辑上不算对象状态的一部分，改它不破坏 const 性。” 比如缓存、引用计数、日志标记这类辅助字段。
常见错误现象：error: assignment of member 'cache_valid' in read-only object —— 就是因为没加 mutable，却在 const 函数里给普通成员赋值。
-
mutable只能用于类非静态数据成员，不能用于全局变量、局部变量或 static 成员 - 不能和
const同时修饰同一个成员（mutable const int x;是错的） - 初始化列表里可以给
mutable成员赋值，但不影响其“可变”语义
mutable 常见使用场景：缓存、调试标记、线程安全辅助
最典型的是惰性计算结果缓存：比如 std::string 的 c_str() 内部可能缓存一个 C 风格字符串指针，这个指针本身不改变对象逻辑状态，但需要被更新。
另一个常见用途是调试：加个 mutable bool logged = false;，在 const 函数里记录是否已打过日志，避免重复输出。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 多线程中配合
mutable std::mutex—— mutex 必须可修改才能加锁，但它不改变对象业务状态 - 不要滥用：比如把
mutable int counter;用在本该反映对象状态的计数器上，会破坏 const 正确性 - 注意：
mutable不影响内存布局或访问权限，只是绕过编译器对 const 函数的写保护检查
为什么不用 const_cast？
const_cast 虽然也能强行去掉 const，但风险高、意图模糊，而且对真正 const 对象（比如字面量或栈上 const 实例）做这种操作是未定义行为。
而 mutable 是语言级支持的明确契约：你声明这个成员“可变”，编译器就允许你在 const 函数里动它，且不会引发 UB。
-
const_cast<int*>(&x) = 42;在 x 是 const 局部变量时会崩溃或静默出错 -
mutable成员在 const 对象中依然可安全修改，这是它被设计出来的根本原因 - 现代 C++ 代码审查中，看到
const_cast修改成员，第一反应是“这里该用mutable”
性能与兼容性要注意什么？
mutable 本身零开销：它不生成额外代码，也不影响对象大小（除非你加的是新成员）。但它的误用会影响线程安全和逻辑一致性。
- 多个线程同时调用同一个 const 函数，如果它修改了
mutable成员（比如缓存），必须自己加锁 ——mutable不提供同步保障 - 移动构造/赋值函数里，
mutable成员会被正常移动，和普通成员一样处理 - C++11 起完全支持，老项目如果还在用 C++98，得换思路（比如把缓存抽到外部 map 里）
最容易被忽略的是：mutable 成员的修改不触发 const 成员函数的“不可观察性”保证。如果你依赖某个 const 函数绝对不产生副作用（比如用于 constexpr 上下文或某些优化假设），那就别在里面动 mutable 成员 —— 它确实会改东西，只是编译器不管而已。
