关于null safety（空安全）实际收益与核心作用的疑问

你这个误解的核心问题出在测试代码本身：你写的Student?语法根本就是null safety启用之后才支持的特性。
在未开启null safety的Dart环境里，类型声明后面加?是直接语法报错的，你能写出Student? s1 = null并且走到s1.foo()的编译校验环节，说明你当前环境已经开了null safety，这里的编译报错本来就是null safety的校验效果，不是非空安全模式自带的防护。

非null safety模式到底是什么样的 #

你把代码里的?去掉，放到真正未开启null safety的环境里跑一下就清楚了：

class Student
{
    void foo()
    {
    }
}

void main()
{
    Student s1 = null;  // 非空安全模式下完全合法，所有类型默认都可接收null
    s1.foo();            // 编译阶段不会报任何错
}

这段代码在非空安全模式下能顺利通过编译，只有实际运行到s1.foo()的时候，才会抛出空指针运行时异常。这也是null safety出现之前，空指针问题常年占据各类编程语言bug榜首位的原因：编译器完全不跟踪null的传递路径，哪个变量可能为null、哪个位置需要判空全靠开发者自己记，漏写一处判空就可能在线上触发崩溃。

null safety的核心设计意义 #

null safety不是简单加个“null调方法就报错”的校验，而是从类型系统层面对可空性做了完整的静态约束，核心价值有三点：

• 从类型层面明确区分可空/非空边界：非空类型的变量从声明开始就绝对不允许被赋值为null，从根源上堵死了非预期null的来源，开发者不需要靠注释、靠约定猜某个变量会不会为null。
• 基于流分析做智能类型推断：编译器会全程跟踪可空变量的赋值、判空逻辑，比如你写了if (s1 != null)的分支，编译器会自动识别分支内的s1已经是非空类型，允许直接调用方法，不需要手动做强转或者写冗余的非空断言。
• 把空指针问题的发现节点从运行时提前到编译期：所有可能触发空指针调用的位置，都会在写代码、编译阶段直接报错，不需要等程序跑起来、甚至上线之后才暴露问题，能极大降低线上空指针相关的故障概率。

说白了，你之前觉得“不开null safety也有空防护”，本质是你已经在null safety的规则体系里写代码了，切到真正的非空安全环境试一次，就能立刻感受到两者的差别。

内容的提问来源于stack exchange，提问作者Steven