Dart/Flutter中是否需为方法参数标记final并显式指定类型？重写方法有何规范？

三种build方法写法的性能与体积对比 #

从实际编译产物、运行性能、安装包体积的维度看，以下三种写法没有任何可观测的差异：

• @override build(context)
  该写法没有显式标注参数类型，但因为存在@override注解，Dart静态分析器会自动匹配父类的方法签名，将context的类型自动推断为BuildContext，不会出现参数类型为dynamic的情况。
• @override build(BuildContext context)
  该写法显式标注了参数类型，和第一种写法的源码差异仅在于是否手动书写类型标注，编译生成的字节码、机器码完全一致。
• @override build(final BuildContext context)
  该写法在参数前加了final修饰，对Dart的编译器而言没有任何优化提示作用。Dart的JIT、AOT编译器会通过静态分析自动识别函数内未被重新赋值的参数、局部变量，自动完成对应的优化，完全不需要依赖开发者手动添加的final标注。因此加不加final不会对编译产物、运行性能造成任何影响，仅在源码层面起到“该参数不会被重新赋值”的可读性提示作用。

重写方法的签名匹配要求 #

Dart的类型系统不要求重写方法的源码写法和父类逐字完全一致，只要满足类型兼容规则即可：

• 参数类型的标注可以省略，只要通过@override触发签名校验，分析器会自动关联父类的参数类型完成检查，不会出现类型不匹配的静默问题。
• 参数前是否加final修饰，不属于函数类型签名的组成部分，完全不影响重写的合法性。

Flutter官方代码不标注参数final的原因 #

结合Dart和Java的语法差异、Flutter的代码维护实践，官方不对方法参数加final的核心逻辑如下：

1. 语法层面无依赖：Java中给参数加final的一个核心历史收益是允许参数被匿名内部类直接引用，而Dart的语法本身就支持闭包直接引用外层函数的参数、局部变量，完全不需要final修饰来解锁这类能力。
2. 编译优化无收益：和Java不同，Dart编译器不会因为参数加了final就生成更优的代码，自动静态分析已经覆盖了未赋值变量的优化场景，手动加final不会带来性能提升。
3. 维护成本过高：Dart的官方代码规范从未将“给方法参数标注final”列为强制推荐实践。绝大多数函数的参数从语义上就是传入的不可变输入，如果逐行给参数加final，在Flutter这类超大规模的代码仓库中会产生大量无意义的冗余书写，造成diff噪音、提升维护成本。

你提到的_flingDistancePenetration函数中，参数t全程没有被重新赋值，编译器会自动识别到这个不可变属性，生成的优化代码和手动加了final的版本完全一致，手动标注没有任何实际价值。

另外需要纠正一个常见误解：只有非重写场景下的无类型参数，才会被默认推断为dynamic类型；重写场景下因为有@override的签名校验逻辑，无类型参数会自动继承父类的参数类型，和显式标注类型的版本没有实际差异。

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