C++中持续保证数据合法依赖构造后的约束机制设计：const/引用成员须在初始化列表赋值；mutable仅用于不改变可观测行为的逻辑可变成员；RAII绑定资源生命周期；constexpr构造函数确保编译期不可变。
初始化完成不等于数据永远合法——C++中对象一旦构造完毕，后续任何成员函数调用、外部赋值或并发访问都可能破坏其内部状态。真正能持续保证数据合法的，不是“初始化动作本身”，而是**构造之后的约束机制设计**。
const 成员和引用成员必须在初始化列表中赋值
这是最基础也最容易被绕过的防线。如果类里有 const int id 或 int& ref，它们在对象生命周期内不可重绑定或修改，因此必须在构造时就确定值。否则编译直接报错：error: uninitialized const member 或 error: uninitialized reference member。
- 错误写法：
MyClass(int x) { id = x; }—— 构造函数体内赋值对const和引用无效 - 正确写法：
MyClass(int x) : id(x), ref(data_) {}—— 必须出现在初始化列表 - 注意：即使
data_是私有成员，只要它已在声明顺序中靠前，就能被安全引用
mutable 修饰符只放“逻辑上可变但不影响对象语义”的成员
mutable 是个危险开关，它允许在 const 成员函数中修改某成员。常见用途是缓存、计数器、互斥锁——但前提是这些修改**不改变对象对外呈现的逻辑状态**。滥用会导致“看似 const 实则可变”的陷阱。
- 合理用法：
mutable std::mutex mtx_;、mutable int cache_hit_; - 危险用法：
mutable std::string cached_result_;却没同步更新原始数据源，导致cached_result_和真实状态不一致 - 关键判断：调用
const函数后，对象的“可观测行为”是否与调用前完全等价？如果不是，就不该用mutable
RAII 对象生命周期严格绑定资源存续期
RAII 不只是“自动释放”，它的核心价值在于**把资源有效性压缩到对象生命期内**。只要对象还活着，其所管资源（文件句柄、内存块、锁）就一定有效；一旦析构，资源必然释放。这种一对一绑定，才是持续合法的底层保障。
立即学习“C++免费学习笔记（深入）”；
- 典型例子：
std::lock_guard<:mutex></:mutex>持有锁直到作用域结束，不可能出现“已解锁却还在用”的情况 - 反例：
int* ptr = new int[100];—— 指针本身不带生命周期信息，无法自动保证后续访问时内存仍有效 - 自定义 RAII 类要注意：析构函数必须无异常（
noexcept），否则栈展开时可能中止清理
constexpr 构造函数确保编译期状态不可篡改
当对象用 constexpr 构造（如 constexpr Point p{1, 2};），它不仅是只读的，而且其整个结构在编译期就固化了。这意味着不仅运行时不能改，连链接期、模板实例化时都无法绕过约束——比 const 更强一层。
- 限制明显：不能含
new、虚函数、非字面类型成员（如std::vector） - 优势实在：可用于数组大小、模板非类型参数、
static_assert条件等需要编译期常量的场景 - 容易忽略的一点：
constexpr对象的成员函数也必须标记为constexpr才能在编译期调用，否则会退化为运行时求值
最易被忽视的其实是“不变性边界”的划定——不是所有成员都需要保护，也不是所有函数都要加 const。关键在于明确：哪些字段组合定义了对象的合法状态，然后用语言机制（const、mutable、RAII、constexpr）把它们钉死在对应层级上。一旦边界模糊，再多初始化技巧也挡不住后续的误用。
