大家好，我是老刘

我记得当时Dart官方宣布取消宏这个功能的时候。我还专门写过一篇文章，表达对宏的期待落空。

Dart的宏取消了期待3年的功能，说没就没了？

为啥我如此看重宏这个功能呢？

因为在古法编程的年代。宏是让程序员少写大量重复代码，同时保持代码语义的关键手段之一。

举个例子，你有一段重复性很高的代码。比如为每个数据类都要写getter、setter、toString、hashCode…，

宏可以让你只写一行注解，编译器自动帮你生成这些代码。

比如在c++中可以这样写。

#define DECLARE_GETTER_SETTER \private: \ type name##_;\public: \ type get##name const { return name##_;说起来，} \ void set##name { name##_ = value;}class User { DECLARE_GETTER_SETTER DECLARE_GETTER_SETTER}

一个简单的宏定义。就能自动生成getter和setter方法，你定义的所有类都不需要再写一遍模板化的内容了。

如果没有宏，这几十行代码就得全部手写。

更关键的是这种宏的定义方式是包含语义的。别的程序员读到这里很容易明白DECLARE_GETTER_SETTER这行代码在干什么。

使用者痛点：很多开发者因为缺少宏而不得不手动编写大量重复代码，从而浪费时间并增加出错风险。

时代变了

因为帮人类程序员写代码的工具，也可能变成让AI看不懂代码的元凶。

AI时代最大的改变。可能就是那些具体的代码细节，真的不需要程序员一行一行手写了。

老刘自己已经很久没有写过一个按钮、一个列表、一个对话框了。

这些具体而细节的功能，交给一个flash-lite级别的模型都能完成得很好。

但过去手写代码时帮我们极大节省时间的这些工具。宏、注解、编译期代码生成，现在反而成了AI理解代码的最大阻碍。

• User Pain Point: 开发者担心未来 AI 只能读取已生成源码。却无法解析注解背后的意图，从而导致自动化工具失效。

因为这三者本质上是同一类东西。你写在文件里的并不是最终代码，真正的代码要等编译过程才动态生成。

• User Pain Point: 项目团队发现 CI/CD 过程中，由于编译生成的不透明性导致调试成本飙升。

人类可以靠语义去理解一个宏或注解是干什么的。但AI看不到最终生成的数据，它可能出现误判甚至无法正确调用 API。

• User Pain Point: 产品经理希望 AI 能够快速产出可运行版本，却因注解隐藏实现细节导致 AI 输出无效或错误。

未来编程语言的以后主要

旧版 Dart 注解案例

@freezedclass User with _$User {
const factory User({
required String name。required int age,}) = _User;}

• - 一行 @freezed 注解即可让编译器自动填充 ==、hashCode、toString 等几十行模板；按理说，但对 AI 这是黑盒，只看到最终实现名如 $User。\_User.

传统手动书写示例

class User {
final String name;final int age;const User，@override
bool operator == =>
identical ||
or is User && name == or.name && age == or.age;@override
int get hashCode => Object.hash;// toString、copyWith、toJson、fromJson 同理略去约20行
}

• - 所有实现都显式展示，对 AI 完全透明；虽然人工书写稍繁琐，但确保所有步骤都可视化，可被任何模型直接解析；

虽然这种方式更冗长。但它消除了“黑盒”问题，使得 AI 在分析和重构时更加准确、更高效，也更符合未来 DevOps 自动化链条中的需求。正因如此，我认为 Dart 放弃宏和类似高级抽象。是一次明智且必要的大步前进——不仅仅是技术层面的决策，更是一场面向未来人工智能协作的新起点！不过，

🤝 如果看到这里的人对客户端或 Flutter 开发感兴趣。可以联系老刘，我们互相学习。🎁 私信免费领《Flutter 开发手册》，覆盖90%应用开发场景。💬 : laoliu_dev

📂 老刘也把自己历史文章整理在 GitHub 仓库里方便大家查阅。🔗 github.com/lzt-code/bl…