非空参数是否有必要做null检查？Flutter源码断言疑问

你观察到的现象是对的：在健全空安全开启、正常静态检查生效的场景下，非空类型参数确实不可能为null，甚至你测试的dynamic传null场景，会在参数赋值阶段先抛出TypeError，走不到断言逻辑，但这些断言依然有三个不可替代的作用：

• 报错信息的可读性、排查效率远高于原生类型错误
  健全空安全下抛出的TypeError只会提示「null值被赋值给了bool类型」，不会明确告诉你是哪个类的哪个构造参数出了问题，错误栈也只会停留在传参的位置。而构造函数初始化列表里的assert(xxx != null)触发时，会直接定位到PageRouteBuilder构造函数内的对应断言行，明确告知你违反了哪个API的参数契约，在复杂嵌套路由的场景下，排查效率差距非常明显。
• 兜底空安全的边界绕过场景
  Dart的空安全约束不是100%牢不可破的，存在不少可以绕过静态检查的场景：
  • 项目中存在未迁移空安全的遗留代码，或者用// @dart=2.x（x<12）的注解关闭了单个文件的空安全检查
  • 通过dart:mirrors反射动态构造实例、通过FFI传入参数时，静态类型检查完全不会生效
  • 极端情况下的编译产物bug、类型转换漏检
    这些场景下非空类型的参数完全可能拿到null值，此时类型层面的约束不会触发任何检查，这些断言就能在调试阶段第一时间捕获非法传参，不会等到后续路由动画、构建逻辑运行时才抛出位置更隐蔽的空指针错误。
• 对齐API契约的统一编码规范要求
  构造函数注释里标注的「xxx参数必须不为null」是公开API的正式使用契约，Flutter团队的编码规范明确要求：所有公开API的契约约束，都必须在调试模式下用断言做落地校验，不能完全依赖静态类型系统。哪怕类型系统已经能覆盖大部分场景，断言也是契约的一部分，和注释形成对应关系，避免后续代码迭代、类型约束调整时出现契约和实现不一致的问题。

补充说明：你测试的dynamic传null场景之所以先抛TypeError，是因为Dart在健全空安全模式下会自动在函数调用传参位置插入隐式类型强转检查，检查时机早于构造函数初始化列表的执行，所以走不到断言逻辑，但这只是特定场景下的表现，不代表断言没有存在价值。

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