is not null 是 C# 8.0 起语义更清晰、支持流分析的 null 检查方式,优于 != null;适用于方法体内局部变量判断,可与类型模式组合用于 switch,但不能替代 ?? 或泛型约束。

用 is not null 模式匹配替代传统 != null
从 C# 8.0 开始,is not null 是语义更清晰、编译器推断更友好的 null 检查方式。它不只是语法糖,还能触发可空引用类型(NRT)的流分析,让后续代码中变量的可空性状态被正确识别。
- 写
if (obj is not null)后,编译器知道obj在该分支内非空,不会报 CS8602(可能为 null 的解引用) - 相比
obj != null,它在模式匹配上下文中更自然,比如和switch或嵌套模式一起用 - 注意:仅当项目启用
且目标框架支持(.NET Core 3.0+ / .NET 5+)时,才能发挥完整效果enable
在 switch 中结合 is not null 做类型 + 非空联合判断
单独检查 null 很常见,但更多时候你真正想表达的是“如果是某个类型,且不为 null,就执行某逻辑”。这时候把 is not null 和类型模式组合起来,比先判空再强制转型更安全简洁。
object input = GetSomething();
switch (input)
{
case string s when s.Length > 0: // s 已知非 null,Length 可直接调
Console.WriteLine($"非空字符串: {s}");
break;
case int i:
Console.WriteLine($"整数: {i}");
break;
case null: // 注意:null 是一个独立 case,必须显式写
Console.WriteLine("输入为 null");
break;
default:
Console.WriteLine("其他类型");
break;
}-
case string s本身就隐含了非 null 判断(因为string是引用类型,模式匹配成功即表示非 null) - 如果写
case string? s,则s可能为 null,后续访问需再检查 -
case null必须显式列出,否则 null 会掉进default分支
避免误用:别在泛型约束或属性初始化里硬套 is not null
is not null 是运行时模式匹配操作符,不能替代编译期约束或静态保证。强行在不合适的地方用,要么报错,要么失去意义。
- ❌ 不能用于泛型约束:
where T : not null是错误写法;正确是where T : class(引用类型)或where T : notnull(C# 9 新关键字,注意拼写是notnull,无空格) - ❌ 不要在字段/属性初始化器中依赖它做非空保证:
private readonly string _name = _input is not null ? _input.Name : "unknown";—— 若_input是字段,初始化顺序可能导致未定义行为 - ✅ 它最适合用在方法体内、明确有值可判断的局部变量或参数上
对比 ?? 和 is not null:用途完全不同
有人看到 is not null 就想替掉所有 null 合并操作符 ??,这是误解。两者解决的问题不在同一维度。
-
??是提供默认值的表达式,关注“取什么”,例如:var name = user?.Name ?? "Anonymous" -
is not null是条件判断,关注“做什么”,例如:if (user is not null) { user.LogIn(); } - 混用反而啰嗦:
if (user is not null) { Process(user); }比if (user != null) { Process(user); }更推荐;但user?.Name ?? "N/A"绝对不该改成(user is not null ? user.Name : "N/A")—— 前者简洁、短路、可读性强
真正容易被忽略的是:即使启用了可空引用类型,编译器也不会自动把 != null 升级为 is not null 的流分析能力。你得主动改写,并确保上下文中有足够的类型信息供编译器推理。










