在去年春节，Flutter 官方发布了宏（Macros）编程的原型支持， 同年的 5 月份在 Google I/O 发布的 Dart 3.4 宣布了宏的实验性支持，但是对于 Dart 内部来说，从启动宏编程实验开始已经过去了几年，但是从目前的推进趋势看，完全的宏功能支持并不理想，结论大概是：
能用是能用，但是质量和性能都达不到一开始的预期。
具体原来在于 Dart 的静态语言提前编译和有状态的热重载等方面 ，对于元编程而言，需要建立在强大的内省基础支持之上，但是对于 Dart 目前来说，运行时内省（例如反射）会让 tree-shaking 优化变得困难 ，而 tree-shaking 优化是 Dart 在二进制优化的重要指标之一。
一开始 Dart 的目标是构建一个完整的宏系统，从而让该系统支持在编译时对程序进行深度语义内省，但是在实现语义内省时引入了大量的编译时成本，而这让有状态的热重载保持变得困难。
目前的宏编程还让 Flutter 开发时的 IDE 编辑与补全体验下降。
同时带来的还有依赖项里的宏循环依赖等问题，例如在 IDE 中输入".foo" 可能需要重新处理所有宏，从而执行正确的代码，目前来看要么处理得太频繁，要么给出的结果不正确。
在过去的测试里，宏在小型库上的性能非常好，但是在真实应用的大周期开发里，会让 Dart 的体验变得很差，例如在顶层编辑（声明、方法头、字段等）时，基本上每次键入都需要重新运行整个宏构建。
而针对当前宏支持采用缓存的提议，也存在宏生成的代码的整个版本适配问题，例如：
现在有一个依赖于 foo 和 bar 的 my_app 包，如果你只在 foo 上运行 pub get，解析器可能会给你 bar 1.2.3；而当你在 my_app上运行 pub get 时，也许会得到 bar 2.3.4，大概可能是 @doStuff 宏内省的 type from bar 在这些版本之间不同。
虽然也可以通过限制内省来避免这种深层依赖，但带来的一些其他负面，例如你可能正在为 foo 生成 JSON 序列化代码，并且宏正在尝试判断其类型来自 bar 的字段是否支持 JSON 序列化，甚至前面提到的循环依赖问题。
当然针对和这个可能还有其他解决方案，相比较目前带来的编译时间、静态分析和整个程序的优化问题，对于 Dart 来说运行时方法并不现实。
所以最终 Dart 团队决定，由于宏的性能具体目标还太遥远，团队决定把当前的实现回归到编辑（例如静态分析和代码完成）和增量编译（热重载的第一步）上。
具体在于重新投资Dart 中的数据支持**，因为这也是Dart & Flutter issue 里请求最多的问题，事实上一开始 Dart 对宏支持的主要动机也是提供更好的数据序列化和反序列化，但是目前看来，通过更多定制语言功能来实现这一点更加实际。
另外通过缩短构建时间和整体代码生成体验来弥补宏的确实，也是未来目标之一，目前 Dart 已经确定了 build_runner 的改进支持。
另外还计划提供 augmentations 功能，这是作为宏的一部分制作原型的功能，例如增加修饰符 augment 作为扩充声明，而该功能也是独立的部份，并将改进现有的代码生成。
通过 augment 实现将一个功能部署到多个文件里，同时可以添加新的顶级声明，将新成员注入类，并将函数和变量包装在其他代码中。
相信宏支持停止这个消息会让大家感到失望，尽管从长远来看 Dart 仍然对通用元编程感兴趣，因为它在数据之外还有许多潜在的用例，但是在短期之内，Dart 应该是不会发布宏支持。
对于包开发者来说，比如之前的 equatable 在 3.0.0-dev.1 就发布过宏的实验性版本，体验还不错，但是现在看来只能继续"实验"下去。
最后，祝大家 2025 新春快乐～