air在go微服务中需精准配置监听范围与构建命令才能生效：默认不监听go.mod、proto等文件，且不自动扫描子模块；须显式设置root、bin路径，添加include_ext，并为多服务配置独立air.toml及环境变量。
Air 能在 Go 微服务开发中实现保存即编译、自动重启，但默认配置下它常因忽略 go.mod 依赖变化、误扫测试文件或无法捕获子模块变更而失效——关键不是装上就能用，而是配对监听范围和构建命令。
为什么 air 启动后改代码没反应？
Air 默认只监听 .go 文件，且不自动感知 go.mod 或 go.sum 变更；微服务通常含多个 cmd/xxx 子目录，若未显式指定入口，Air 会卡在旧二进制或找不到 main 包。
- 检查当前工作目录是否为项目根目录（含
go.mod），否则air无法解析模块路径 - 确认
air.toml中root和bin路径正确，例如微服务入口在cmd/user-service/main.go，则bin = "./cmd/user-service" - 避免把
air.toml放错位置：必须放在项目根目录，而非cmd/下
如何让 air 正确监听 go.mod 和 proto 生成文件？
Air 不监听 go.mod 是设计使然，需手动加入监听列表；gRPC 微服务常依赖 .proto 生成的 *_pb.go，这些文件默认不在 Go 源码路径下，也得显式添加。
- 在
air.toml的[build]段落里加args = ["-mod=mod", "./..."]，确保go build命令始终走模块模式 - 在
[monitor]下添加include_ext = ["go", "mod", "sum", "proto", "pb.go"] - 若使用
buf或protoc生成代码，建议在air.toml的build_cmd中前置执行，例如：build_cmd = "buf generate && go build -o ./cmd/user-service/app ./cmd/user-service"
air 在多服务共存项目里怎么避免端口冲突？
本地跑多个微服务（如 user-svc、order-svc）时，每个都用 Air 启动，容易因环境变量未隔离导致服务注册地址、HTTP 端口或 gRPC 端口重复绑定。
- 不要全局设
PORT=8080，改用服务专属变量，例如USER_SVC_PORT=8001，并在main.go中读取：os.Getenv("USER_SVC_PORT") - Air 的
env配置项支持 per-service 注入，在各自air.toml里写：env = ["USER_SVC_PORT=8001", "SERVICE_NAME=user-svc"] - 避免所有服务共用一个
air.toml——每个微服务应有独立配置文件，放在各自cmd/xxx/目录下，并用air -c cmd/xxx/air.toml启动
真正麻烦的不是启动 Air，而是当你的微服务开始依赖中间件（比如 etcd client 初始化失败）、健康检查接口返回 503、或者 Air 重启太快导致 DB 连接池还没关干净就重连——这些不会报错，但会让热加载看起来“生效了”，实际请求全挂。这时候得看 air 的 delay 参数和应用自身的 graceful shutdown 实现是否匹配。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
