最推荐用 std::optional 表达“可能没有值”，因其从类型层面明确语义、避免哨兵值冲突、支持静态检查；次选自定义有效标志位（需严格约束访问）；慎用哨兵值和宏包装，关键在全团队统一无效状态表达方式。
用 std::optional 表达“可能没有值”的语义
直接用 std::optional 是 C++17 起最自然、最安全的方式。它不是“设个特殊值”，而是从类型层面明确告诉调用方：这个变量当前可能无效。
常见错误是试图复用原始类型的某个取值（比如用 -1 表示整数无效），这容易和合法值冲突，且调用方无法静态感知是否需判空。
-
std::optional<int> x;</int>默认构造即为“无值”状态，x.has_value()返回false - 赋值后可用
*x或x.value()访问，但x.value()在无值时抛异常，更推荐先判空或用x.value_or(0) - 注意：不能对
std::optional<t></t>直接取地址（&*x）而不确保有值，否则未定义行为
自定义类型里手动管理有效标志位
当无法使用 std::optional（比如要兼容 C++11，或需零开销抽象），就得自己加一个布尔字段控制有效性。
关键不是“怎么存”，而是“怎么约束访问”。很多实现漏掉 const 成员函数的正确性检查，导致读取未初始化值。
- 把有效标志（如
bool valid_）和数据成员一起声明，并在所有构造函数中显式初始化 - 所有非 const 成员函数（尤其是
operator=、reset()）必须同步更新valid_ - const 成员函数（如
get()）应断言valid_为真，或返回std::nullopt/ 抛异常，避免静默返回垃圾值 - 别用
mutable绕过 const 正确性 —— 那是在掩盖设计缺陷
原始类型慎用哨兵值（sentinel value）
用 INT_MIN、nullptr、"" 这类“看起来不可能出现”的值表示无效，只在极受限场景下可行。
问题在于：它把语义藏在值域里，编译器无法帮你检查，运行时也难定位谁误用了无效值。
- 仅适用于值域明显可分割的类型，例如：时间戳用
0表示“未设置”，前提是业务中0确实永不合法 - 必须在文档和命名上强提示，比如叫
last_sync_time_s而不是last_sync_time，并在注释里写死 “0= not synced” - 一旦类型变更（比如从
int换成uint32_t），原来用-1当哨兵就直接编译不过或逻辑反转
模板化包装器比宏或 typedef 更可靠
有人想用 #define INVALID_INT (-1) 或 using SafeInt = int; 来统一管理，但这不解决根本问题 —— 编译器仍允许你把任意 int 赋给它。
真正可控的是封装访问逻辑。哪怕只是轻量包装，也要阻断隐式转换和裸值暴露。
- 定义模板类
ValidatedValue<t validator></t>，构造时调用Validator检查，失败则置为无效态 - 重载
operator T()为 explicit，强制调用方显式写出转换意图，避免意外传参 - 禁止提供
get_raw()这类接口 —— 一旦开了口子，后续所有人都会绕过校验
最难的不是选哪种机制，而是让整个团队在所有层级（参数、返回值、成员变量、序列化字段）保持一致的无效状态表达方式。一旦混用 std::optional、哨兵值、空指针和未初始化变量，调试时根本分不清是逻辑 bug 还是约定没对齐。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
