Go mod 好菜系列 - 0x12 air 这口热重载开发菜到底值不值
详细聊 air 作为开发期热重载工具的价值、适合什么项目节奏、怎么配置，以及为什么它该只留在开发环境。
只要你开始高频改 Go 服务，尤其是改接口、改模板、改配置再反复本地验证，很快就会烦一件事：每次改完都得重新编译、重新启动、重新切回去看效果。于是像 air 这样的热重载工具就会变得很香。
air 是来解决什么的
它解决的是开发期体验问题，不是线上运行问题。核心就是：
- 监控文件变化
- 自动重新编译
- 自动重启程序
说白了，就是减少你在本地来回手动重启服务的劳动。
为什么这类工具在 Go 里有意义
因为 Go 虽然编译很快，但它终究不是解释型语言。项目一大、依赖一多，本地反复“保存 -> build -> run”还是会让人有明显摩擦感。air 就是在削这层摩擦。
最常见的启动方式
air配好以后，你改代码，air 会自己帮你走后面的重编译和重启流程。
配置文件能做什么
它通常能让你定义：
- 监听哪些目录
- 忽略哪些文件
- 编译命令是什么
- 运行命令是什么
这意味着它很适合你本地开发场景，但不应该混进生产环境运行逻辑里。
它的价值不在技术炫耀，而在节奏
尤其在这些场景里会很舒服：
- 你在频繁改 HTTP handler
- 你在调接口返回结构
- 你在做后台服务的快速试验
- 你在本地高频联调
air 本身不改变架构，但它能改变你的开发手感。
什么时候它没那么值
如果项目本身特别小、编译秒出、改动频率也不高，那 air 的收益没那么大。再比如你在做纯库开发、不是服务开发，它的价值也会弱很多。
最重要的一句：它是开发工具，不是线上工具
别把 air 带到生产环境里当常规启动方式。它存在的意义就是在本地提速，不是让线上进程管理更花。
小结
air 这道菜不是核心业务库，但很适合提升开发体验：
- 它解决的是本地开发期的重编译重启摩擦
- 特别适合高频改服务代码时使用
- 配置层面很灵活，但价值主要在开发环境
- 别把它带上线当进程管理方案
下一篇我们用 grpc 把这一大批收个尾。它比前面的很多库都更像一种通信体系，而不只是某个小工具。