air未重启因监听路径、构建配置或文件类型未正确设置：需确认root指向项目根目录、watch显式包含子目录及非go文件、构建命令匹配入口路径、禁用http长连接避免旧进程残留。
为什么改了代码服务没重启？检查 air 是否真在监听你的目录
默认情况下 air 只监听当前目录下的 .go 文件，但如果你的项目结构是 cmd/app/main.go + internal/，而你在 internal/ 里改了逻辑，air 却没反应——大概率是它压根没扫描到那个路径。
- 运行
air -c .air.toml前先确认配置里root指向项目根（不是cmd或internal） -
watch列表必须显式包含子目录，比如：["./...", "./internal/...", "./pkg/..."]，单写./...在某些版本下不递归 - macOS 上如果用 VS Code 编辑器保存时触发的是“原子写入”，
air可能漏事件；加delay = 1000能缓解
air 启动失败报 fork/exec ./main: no such file or directory 怎么办
这是 air 找不到编译产物，不是代码问题，而是构建流程没对上。它默认执行 go build -o ./main .，但你的入口可能不在当前目录，或者用了 go mod 但 GO111MODULE 环境变量被意外关闭。
- 确保当前终端工作目录是
go.mod所在根目录，不是某个子包下 - 检查
build配置块里的bin和cmd：比如入口是cmd/api/main.go，就该设bin = "./api"、cmd = "go build -o ./api cmd/api/main.go" - Windows 用户注意路径分隔符，
cmd中别写cmd\api\main.go，统一用正斜杠cmd/api/main.go
热重载后 HTTP 连接复用导致旧逻辑还在跑？关掉长连接
浏览器或 curl 默认复用 TCP 连接（HTTP/1.1 keep-alive），而 air 重启服务时旧进程可能还没完全退出，新进程刚起来，请求被内核转给残留的旧进程，造成“改了代码却没生效”的假象。
- 开发阶段在 HTTP server 启动时加
srv.SetKeepAlivesEnabled(false)，强制每次请求建新连接 - 更简单的方法：curl 测试时加
-H "Connection: close"，或者用httpie加--no-keepalive - 别依赖浏览器刷新——它缓存连接太强，换终端命令行验证最靠谱
为什么改完模板或配置文件不触发重启？air 默认不监控非 Go 文件
air 的 watch 列表默认只含 *.go，像 templates/*.html、config.yaml 这类文件改了不会触发重建，但你的程序又确实在运行时读它们——结果就是“重启了，但新模板没加载”。
- 在
.air.toml的watch下补上扩展名，比如：["*.go", "templates/**/*", "config.*"] - 如果模板是嵌入进二进制的（
embed.FS），那必须靠 Go 代码变更触发 rebuild，此时只能手动加个无用注释再保存main.go - 注意 glob 写法：
**表示递归，*只匹配当前层；config.*比config.yaml更安全，适配不同环境配置
真正麻烦的从来不是装上 air，而是它安静地“假装在工作”——监听路径错、构建命令错、文件类型没加、连接没断干净，每一步都容易静默失败。盯住日志里那句 building... 和 running... 之间的间隔，比什么都管用。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
