Dart中向可空元素列表添加null时的类型异常及代码必要性疑惑

这个问题的核心其实藏在你初始化列表的那一行代码里，加上Dart泛型的协变特性和运行时类型检查的细节，才导致了这种看似矛盾的现象，我来一步步拆解清楚：

1. 问题的根源：初始化时的类型不匹配 #

你声明的变量类型是List<Offset?>，但初始化代码是：

List<Offset?> _points = <Offset>[];

右边的<Offset>[]创建的是一个运行时类型为List<Offset>的实例——也就是这个列表底层只能存储Offset类型，完全不接受null。而Dart允许把List<Offset>向上转型为List<Offset?>（泛型协变特性），所以静态检查（VS Code的语法提示）不会报错，但这个列表的实际运行时类型还是List<Offset>。

这就导致了一个矛盾：静态类型检查认为你可以给_points添加null（因为变量类型是可空的），但运行时这个列表的底层实现会严格校验元素类型，拒绝null，所以当你直接调用_points.add(null)时，就会抛出type 'Null' is not a subtype of type 'Offset'的异常。

2. 为什么_points = List.from(_points)能解决问题？ #

当你执行_points = List.from(_points)时，Dart会根据变量_points的类型（List<Offset?>）来推断List.from的泛型参数，相当于你写了：

_points = List<Offset?>.from(_points);

这行代码会创建一个全新的List<Offset?>实例，这个列表的运行时类型就是支持存储Offset?（包括null）的。之后再调用_points.add(null)，运行时检查就会通过，因为这个列表确实允许null元素。

你觉得这行是“无意义的复制”，但实际上它完成了两个关键操作：

• 把原来的List<Offset>实例，转换成了真正的List<Offset?>实例，解决了类型不匹配的问题；
• 生成了一个新的列表引用，这也正好满足了shouldRepaint的检查逻辑（原代码通过比较列表引用是否变化来决定是否重绘，新引用会触发重绘）。

3. 怎么避免这种问题？ #

最直接的修复是初始化时就创建正确类型的列表，把初始化代码改成：

List<Offset?> _points = <Offset?>[]; // 明确声明列表的元素类型为可空的Offset

这样一来，你完全可以去掉_points = List.from(_points)这行代码，直接添加null也不会报错，因为列表的静态类型和运行时类型一致，都是List<Offset?>。

关于你提到的其他实现思路 #

你说用List<List<Offset>>代替null作为分段标记确实是更现代的写法，避免了可空类型带来的陷阱。不过理解这个问题的核心，能帮你更好地掌握Dart泛型的协变特性和运行时类型检查的细节——这也是Dart里很容易踩坑的点之一。

内容来源于stack exchange