Dart 3.7格式化工具“乱改代码”？强迫症必看

哈喽，我是老刘

一个从事软件开发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文件中设置一个比较小的值就可以让大多数列表都格式化成多行。

# analysis_options.yaml
formatter:
  page_width: 80

但是这种方案仍然是格式化工具自动决定是否添加结尾的逗号。

如果强迫症患者想强制格式化工具添加结尾的逗号，来看方案2。

解决方案2：

从Dart 3.8开始，你可以通过配置analysis_options.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