哈喽，我是老刘
一个从事软件开发10年+，Flutter开发7年的程序员。
前两天有个朋友咨询升级到Flutter 3.35后的格式化问题。
简单来说就是升级到Flutter 3.35（基于Dart 3.7以上）后，格式化后的代码与之前的版本不同。
原先多行的代码，格式化工具会自动删除结尾的逗号，导致代码合并成为一行。
其实这个是Dart 3.7引入的新特性，如果代码比较短就合并成一行。
老刘自己在开发中的习惯也基本是符合这个逻辑的，短的代码一行，长的代码分行，所以没有太大的感知。
但是有人问起来我就也向团队的小伙伴们问了一下，发现还是不少人对这个新的格式化方案挺别扭的。
主要是他们不管长短都喜欢多行的样子。（话说你们强迫症挺严重的）
因此今天写篇文章来分享一下这个问题的解决方案。
Dart 3.7版本新的格式化逻辑
首先格式化的基本逻辑是如果有尾随逗号，格式化器会将其拆分为多行；如果移除尾随逗号，格式化器会将列表合并成一行。
这一点在新旧版本上是一致的。
而Dart 3.7引入了新的格式化风格，会根据代码是否超出最大页面宽度自动决定是否添加尾随逗号。
如果代码比较短，格式化器会自动移除尾随逗号，从而格式化为一行。
如果代码很多，超出了最大页面宽度，格式化器会自动添加尾随逗号。也就会自动格式化成多行。
解决方案
解决方案1：调整页面宽度
通过设置最大页面宽度，可以调整格式化器的行为。
在analysis_options.yaml文件中设置一个比较小的值就可以让大多数列表都格式化成多行。
yaml
# analysis_options.yaml
formatter:
page_width: 80
但是这种方案仍然是格式化工具自动决定是否添加结尾的逗号。
如果强迫症患者想强制格式化工具添加结尾的逗号，来看方案2。
解决方案2：
从Dart 3.8开始，你可以通过配置analysis_options.yaml文件来恢复旧的格式化行为
yaml
# analysis_options.yaml
formatter:
trailing_commas: preserve这个配置会保证格式化工具不会修改结尾的逗号，由程序员决定是否添加。
注意需要Dart 3.8以上才支持这个选项，因此为了方便下面我列出了Flutter版本对应的Dart版本，看看你是否需要升级。
Flutter对应dart版本
下表列出了 Flutter 3.0 及以上稳定版本与其对应的 Dart 版本（以主/次版本对齐，补丁用 x 表示）：
| Flutter | Dart |
|---|---|
| 3.0.x | 2.17.x |
| 3.3.x | 2.18.x |
| 3.7.x | 2.19.x |
| 3.10.x | 3.0.x |
| 3.13.x | 3.1.x |
| 3.16.x | 3.2.x |
| 3.19.x | 3.3.x |
| 3.22.x | 3.4.x |
| 3.24.x | 3.5.x |
| 3.27.x | 3.6.x |
| 3.29.x | 3.7.x |
| 3.32.x | 3.8.x |
| 3.35.x | 3.9.x |
说明：
- Flutter SDK 自带固定的 Dart 版本，随 Flutter 一起升级。
- 不同的 3.xx.y 小版本通常对应同一 Dart 主/次版本（例如 3.35.0、3.35.5 都是 Dart 3.9.x）。
- 实际本地版本以命令行输出为准：运行 flutter --version 可同时查看 Flutter 和 Dart 的具体版本。
参考：
- Flutter SDK archive（官方归档，列出每个 Flutter 版本对应的 Dart 版本）：docs.flutter.dev/install/arc...
总结："智能"的边界在哪里？
Dart 团队的初衷是好的：让短代码更紧凑，长代码自动换行，这符合一般的美学原则。
但问题在于，代码的可读性是主观的，尤其是在 Flutter 这种声明式 UI 框架中，开发者经常利用换行来组织视觉层级，即便只有两三个属性，也可能希望它们垂直对齐，以模仿最终的 UI 结构。
当工具的智能越过了开发者的习惯边界，就会产生摩擦。
这里 Dart 团队的成熟反应值得称赞，在 3.8 版本中迅速加入了 trailing_commas: preserve 选项。
这是一个成熟的开源社区和工具团队应有的表现。他们倾听了社区的声音，并认识到在这种场景下，保留开发者的明确意图比工具的自动猜测更重要。
这在自动化和控制权之间找到了一个完美的平衡点： 默认智能处理，但允许开发者自己配置。
更进一步来说，我们正在进入 AI 编程时代，AI Agent 会进行更大胆、更自动化的代码生成和修改。
这个小小的逗号问题，其实是对未来 AI 工具设计者的一个警示：
- AI 不能是一个黑盒：AI 助手不仅要完成任务，还要能让开发者理解它的决策逻辑。
- Agent必须可配置：开发者需要能够训练或配置AI，比如让Agent的代码风格、架构模式与团队现有规范保持一致。
- 永远需要一个手动微调的选项 ：AI 提供的解决方案必须是可审查、可修改的，最终的控制权必须掌握在开发者手中。
如果看到这里的同学对客户端或者Flutter开发感兴趣，欢迎联系老刘，我们互相学习。 私信免费领老刘整理的《Flutter开发手册》，覆盖90%应用开发场景。 可以作为Flutter学习的知识地图。
------ laoliu_dev