mutable修饰的成员变量可在const成员函数中修改，用于缓存、引用计数等不影响对象逻辑状态的场景；它仅适用于非静态数据成员，不可与const/static/reference共用，滥用会破坏const-correctness。
mutable 修饰的成员变量可以在 const 成员函数中被修改
const 成员函数承诺不改变对象的逻辑状态，但编译器默认把所有成员都视为“物理状态”。mutable 的作用就是显式告诉编译器：这个成员例外，它不参与对象的逻辑状态判断，允许在 const 函数里读写。
典型使用场景是缓存、引用计数、日志标记等——它们的修改不影响对象对外表现，却需要在只读接口中更新。
-
mutable只能用于类的非静态数据成员，不能用于局部变量、全局变量或 static 成员 - 不能与
const、static、reference同时修饰同一成员（引用本身不可重绑定，mutable int&是非法的） - 即使对象本身是
const对象，mutable成员仍可被修改
常见错误：试图用 mutable 绕过 const 正确性检查
有人误以为 mutable 是“给 const 成员变量开后门”的通用手段，结果写出语义错误的代码。比如把表示核心业务状态的 balance 或 is_valid 标记为 mutable，导致 const 函数意外改变对象逻辑行为。
这类错误不会触发编译错误，但会破坏 const-correctness，引发难以调试的并发问题或逻辑不一致。
- 不是所有“想改的变量”都适合加
mutable——必须满足“修改不影响对象可观测行为”这一前提 - 如果一个
const函数修改了非mutable成员，编译器直接报错：assignment of member 'X::y' in read-only object - 滥用
mutable会让 const 接口失去信任基础，后续优化（如编译器缓存返回值）可能失效
实际例子：带缓存的 const getter
下面是一个典型的 mutable 使用模式：延迟计算并缓存结果，同时保持接口 const。
classExpensiveComputation { private: int input_; mutable int cached_result_; // 允许在 const 函数中更新 mutable bool is_cached_; // 同上
public: ExpensiveComputation(int x) : input_(x), cachedresult(0), iscached(false) {}
int get_result() const { if (!is_cached_) { cached_result_ = input_ * input_ + 2 * input_ + 1; // 模拟耗时计算 is_cached_ = true; } return cached_result_; }};
注意：
get_result()是const成员函数，但它内部修改了cached_result_和is_cached_——这只有在二者被声明为mutable时才合法。替代方案：什么时候不该用 mutable
如果修改的是对象的关键状态，或者你需要在 const 上下文中真正地“突破 const”，
mutable就不是正确选择。这时候应考虑：
- 是否本就不该把该函数声明为
const？比如reset()、mark_as_used()这类明显改变语义的操作 - 是否应该拆分接口？例如提供
get_cached_result()（const）和force_recompute()（non-const） - 是否需要用
const_cast？这是危险操作，仅限极少数底层场景（如封装 C API），且要求原始对象确实非 const。对真正 const 对象用const_cast修改成员是未定义行为
真正容易被忽略的是：mutable 成员的线程安全性。它本身不提供任何同步机制，多个线程同时调用 const 成员函数并修改 mutable 成员时，必须手动加锁或使用原子类型。
