mutable修饰的变量可在const成员函数中修改，用于标记逻辑上不改变对象状态但物理上需变更的成员（如缓存、引用计数），仅限非静态、非const、非引用类型；误用会破坏const正确性。
mutable 修饰的变量能在 const 成员函数里被修改
const 成员函数默认不能修改任何成员变量，但 mutable 提供了一个明确的例外通道。它不是绕过 const 的“后门”，而是设计上就允许你标记那些「逻辑上不改变对象状态」但「物理上需要变更」的变量，比如缓存、引用计数、日志标记等。
常见错误是把 mutable 当成“让 const 函数随便改东西”的开关——结果改了真正影响对象语义的字段，破坏了 const 正确性，调用方会因信任 const 而出错。
-
mutable只能用于非静态、非 const、非引用类型的成员变量 - 不能用于 static 成员（静态变量不属于单个对象实例）
- 不能用于 const 成员变量（
const mutable int x;是非法组合） - 不能用于引用类型（
mutable int& ref;编译报错）
典型使用场景：缓存计算结果
当某个 const 成员函数执行开销大、结果可复用，又不想让调用方感知到“内部有状态变化”时，mutable 就很自然。例如：
class ExpensiveCalc {
mutable int cached_result;
mutable bool cache_valid;
int input;
public:
ExpensiveCalc(int i) : input(i), cached_result(0), cache_valid(false) {}
int get_result() const {
if (!cache_valid) {
cached_result = heavy_computation(input); // 假设这个函数耗时
cache_valid = true;
}
return cached_result;
}
};
这里 cached_result 和 cache_valid 被标记为 mutable，使得 get_result() 能保持 const，同时支持惰性缓存。注意：如果 heavy_computation() 依赖外部可变状态（如全局时间、文件内容），那这个缓存就不安全——mutable 不解决线程安全或逻辑一致性问题。
和 const_cast 的关键区别
有人试图用 const_cast 在 const 成员函数里强行修改普通成员变量，这是危险且不可靠的：
- 如果该对象本身是 const（比如
const ExpensiveCalc obj{5};），那么通过const_cast修改其成员属于未定义行为（UB） -
mutable是语言级支持的合法机制，编译器知道你在做什么，不会优化掉对它的读写 -
const_cast绕过类型系统，容易掩盖设计缺陷；mutable则要求你显式声明“此处可变”，是种契约
简单说：要用可变状态，优先选 mutable；只有在必须穿透 const 接口调用第三方 const-unaware 函数时，才谨慎考虑 const_cast，且要确保原始对象非常量。
多线程下 mutable 成员必须加锁或用原子类型
mutable 不提供任何线程安全性。像上面的缓存例子，在并发调用 get_result() 时，cache_valid 和 cached_result 都可能被多个线程同时读写，导致竞态。
- 最直接做法：把
mutable std::mutex cache_mutex;和mutable std::atomic一起用cache_valid{false}; - 避免在 const 函数里做复杂同步（比如锁住整个对象），否则会误导调用方认为“调用 const 函数很轻量”
- 如果缓存更新本身无副作用且幂等（比如只写入一个 atomic
），可以不用锁，但务必确认读写顺序语义满足需求
很多人忽略这点，写了 mutable 缓存后一跑多线程就出错，还以为是 const 机制有问题——其实是忘了并发访问的基本约束。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
