可空类型是专为值类型设计的 nullable 包装机制，引用类型加 ? 属于可空引用类型（nrt），二者无关；声明赋值须严格匹配基础类型或 null，取值前必须检查 hasvalue 或使用模式匹配、空合并等安全方式。
可空类型不是“能存 null 的任意类型”，而是专为值类型设计的包装机制，用 T? 语法糖封装 Nullable<t></t> 结构；引用类型本身就能为 null，加 ? 是可空引用类型（NRT），和这里无关。
声明和赋值时别混淆基础类型与可空类型
你不能写 int? x = "abc"，也不能写 int? y = null 以外的非 int 值。可空类型只接受其基础类型的值或 null：
-
int? a = 123✅ 隐式转换，合法 -
int? b = null✅ 显式赋 null -
int? c = (int?)'x'✅ char 可隐式转 int，再转 int? -
int? d = "hello"❌ 编译失败：string 无法转 int? -
int? e = new object()❌ 同样不兼容
常见错误是误以为 DateTime? 能接字符串日期，实际必须先解析：DateTime? dt = DateTime.TryParse("2026-05-14", out var d) ? d : null;
取值前必须检查 HasValue，别直接用 Value
Value 属性在 HasValue == false 时会抛 InvalidOperationException，不是 NullReferenceException —— 这点容易搞错。运行时崩溃前毫无征兆。
- 推荐写法：
if (x.HasValue) { use(x.Value); } - 更简洁安全：
if (x is int value) { use(value); }（C# 7+ 类型模式） - 想取默认值？用
x.GetValueOrDefault()，它返回default(int)（即 0），不抛异常 - 想指定默认值？用空合并：
int y = x ?? -1;
注意：x == null 在编译期被重写为 !x.HasValue，语义等价但性能略低（多一次装箱判断），生产环境建议优先用 HasValue。
运算符行为是“提升”的，不是直觉上的 null 感知
int? a = 5; int? b = null; bool result = a 这行不会报错，但结果是 <code>false，不是 null 或异常。因为比较运算符被“提升”（lifted）了：
- 底层逻辑等价于：
a.HasValue && b.HasValue ? a.Value - 所以
a == b在任一为 null 时恒为false，a != b也一样 —— 它不表示“未知”，而是“确定不相等” - 加减乘除同理：
int? c = a + b;结果为null（只要任一操作数为 null）
这点常被忽略：你不能靠 == 判断“两个可空值是否都缺失”，它只做“有值且相等”的判断。真要区分状态，得用 a.HasValue == b.HasValue 配合 a.Value == b.Value。
装箱后类型信息丢失，反射拿不到 Nullable
这是调试和序列化时最隐蔽的坑：int? x = 42; object o = x; 之后，o.GetType() 返回的是 System.Int32，不是 System.Nullable`1[System.Int32]。
- 原因：装箱时，CLR 会把有值的
Nullable<t></t>直接装箱为T；null 的Nullable<t></t>装箱为null - 所以
o is int?永远是false，o is int才是true - 想在运行时识别可空类型？只能靠原始变量声明或
typeof(int?)，不能靠GetType() - JSON 序列化（如 System.Text.Json）默认按值序列化，
null可空字段输出为null，但反序列化时需确保目标类型匹配，否则会静默失败或默认值填充
真正复杂的地方不在语法，而在于——当你把 int? 传进泛型方法、塞进 object、扔给反射 API 或跨进程序列化时，它的“可空性”会悄无声息地蒸发掉。这时候，HasValue 和显式类型标注就不是可选项，而是必选项。
