NullReferenceException 总在运行时才报，因为C#编译器不检查null引用，仅JIT执行成员访问、索引或空条件调用时才抛出；常见原因包括未初始化实例、已释放控件、忽略返回null的方法结果及异步中UI销毁。
为什么 NullReferenceException 总在运行时才报？
因为 C# 不会在编译期检查引用是否为 null，只有真正调用 .Member、[index] 或 ?.Method() 这类操作时，JIT 才发现对象没被初始化。常见触发点包括：访问未 new 的类实例字段、调用已释放的控件属性、读取返回 null 的方法结果（如 Dictionary.TryGetValue 没检查返回值）、异步中 UI 控件被提前销毁。
怎么快速定位是哪个变量为 null？
别靠猜。启用「异常设置」→ 勾选 Common Language Runtime Exceptions 下的 System.NullReferenceException，并开启「仅我的代码」关闭。VS 会直接停在出问题的那一行，鼠标悬停看变量值；如果用了内联表达式（如 a?.b?.c?.Length），它会停在最左侧第一个 null 的位置。另外，加断点前可手动插入 Debug.Assert(obj != null, "obj is null here"); 辅助验证。
?. 和 ?? 不是万能解药，什么时候会失效？
它们只防止调用链中断，不解决根本缺失。比如：
-
list?.Add(item)：如果list是null，Add不会执行，但你可能本该初始化它，而不是静默跳过 -
config?.Timeout ?? 3000：若config为null，用默认值没问题；但如果业务逻辑强依赖config必须存在，这里就掩盖了初始化遗漏 -
user.Address?.Street?.ToUpper()：如果Address是null，整个表达式得null；但若后续代码把它当非空字符串用（比如传给string.IsNullOrEmpty()外层没包），照样崩
真正稳妥的做法是：在构造函数或 InitializeComponent 后显式初始化所有引用类型字段，尤其是集合类（List<T>、Dictionary<K,V>）和自定义配置对象。
ASP.NET Core 中 Controller/Service 里常踩的坑
这类上下文里，NullReferenceException 往往暴露依赖注入或生命周期问题：
-
HttpContext在非请求线程（如后台Task.Run）里是null—— 别在非上下文线程里直接用它 - Service 层注入了
IConfiguration，但构造函数里没判空，而实际注册时漏配了services.Configure<MyOptions>(…) - ViewBag/ViewData 赋值后，在视图里写
@ViewBag.User.Name，但 Controller 没确保User已赋值（应改用强类型 ViewModel 并初始化） - Entity Framework 查询用了
FirstOrDefaultAsync()，结果直接 .Name，没处理可能返回null的情况
var user = await context.Users.FirstOrDefaultAsync(x => x.Id == id);
if (user == null) throw new InvalidOperationException($"User {id} not found");
// 后续再用 user.Name 安全最易被忽略的是：把可空引用类型（C# 8+）设为 string? 只是编译器提醒，不阻止运行时为 null；真要杜绝，得结合构造函数强制初始化 + 非空断言 + 单元测试覆盖空路径。
