性能

在一个非常人为的基准测试(#148261)中，ness在Moto G4上给我们带来了构建时间的13-16%的速度提升。然而，这个基准测试非常人工，我们应该用一个更接近真实世界应用的东西来测试它。我将创建一个不使用框架外任何const示例的flutter_gallery版本，并看看运行转换基准测试与const化的flutter_gallery相比如何。我会在一部中端Android手机上运行这个禁用了route snapshotting的版本。

烦人程度

通过在flutter_gallery应用程序上玩弄一下，这里最大的罪魁祸首是prefer_const_constructors和prefer_const_literals_to_create_immutables。当你在构建方法中迭代时，它们会不断触发。它们也经常反复无常，这使得它们更加恼人：你因为lint告诉你这样所以让一个东西变成const,然后以一种不能再是const的方式进行迭代，分析器又对你大喊大叫。
prefer_const_constructors_in_immutables是这个组中最不烦人的lint。事实上，它几乎不烦人，因为它相当稳定，随着代码的演变，你不必在这上面反复无常。即使我们禁用其他lints,这个lint也可能值得保留，因为它为开发者提供了一个基于具体情况决定是否更严格地启用其他const lints的机会。如果我们停止执行prefer_const_constructors_in_immutables,他们可能不再有选择const构造widget的选项，因为widget可能没有提供const构造函数。
prefer_const_declarations lint处于一个灰色地带。它并不觉得特别烦人。但它本身也没有超乎寻常的用处，除非有prefer_const_literals_to_create_immutables和prefer_const_constructors,否则就如此。所以，如果我们最终禁用了这些，我也倾向于禁用这个。

总结

使用与现实世界更接近的基准测试进行更多的性能测试。如果const ness没有带来巨大的差异(阈值待定),建议从package:flutter_lints中移除prefer_const_constructors、prefer_const_literals_to_create_immutables和prefer_const_declarations,但很可能保留prefer_const_constructors_in_immutables。如果const ness产生了影响，我们将与语言/分析器团队合作，找出是否可以使这不再烦人(例如，在分析器中引入更好的快速修复，或者调查是否可以引入类似autoconst到语言中的内容)。

FYI @mit-mit@jonahwilliams@johnpryan@srawlins

相关： dart-lang/sdk#53744