Go本地热更新本质是快速重启而非真正热加载，因Go无运行时字节码重载能力，每次修改均杀旧进程启新实例，连接、goroutine与全局状态均丢失。
Go本地热更新 ≠ 真正热加载，本质是快速重启
Go 没有运行时字节码重载能力，所谓“热更新”在本地开发中实际就是 go run 或构建后自动重启。别指望改个函数就原地生效——它每次都是杀掉旧进程、启动新实例。这点必须先认清，否则你会反复踩坑：比如以为连接能保持、goroutine 会延续、全局状态能复用，结果全丢了。
真正影响体验的不是“能不能热”，而是“重启够不够快、中断够不够少、触发够不够准”。本地开发追求的是改完保存 → 1–2 秒内看到效果，而不是零中断或内存保留。
-
go run main.go启动快但不接管进程生命周期，无法优雅关闭 HTTP 连接，SIGINT信号也收不到 - 用
air或gin工具封装后，才能控制编译命令、二进制路径、重启时机和文件监听范围 - Windows 下常见
fork/exec: permission denied或access is denied错误，本质是旧进程还没释放.exe文件锁，新版本写不进去 - 监听路径不对（比如
root = "."却在子目录改代码）、忽略扩展名（没加tmpl或yaml）、build.bin和build.cmd输出路径不一致，都会导致“改了没反应”
用 air 实现可靠本地热重启
air 是目前最轻量、配置最直白的本地热重启工具，比 gin 更少侵入业务代码，比手写 fsnotify + exec.Command 更健壮。它不依赖 socket 复用或 fd 传递——那些是生产平滑重启才需要的。
关键不是装上就行，而是配对三个字段：
立即学习“go语言免费学习笔记（深入）”；
-
root：必须设为项目根目录（即含go.mod的路径），留空或填.最安全；填绝对路径容易跨机器失效 -
build.bin：必须和build.cmd输出的二进制路径完全一致，例如./tmp/main，否则air找不到可执行文件，报错exec: "./tmp/main": file does not exist -
watch.extensions：默认只监听.go，如果你用template渲染 HTML 或.yaml改配置，得手动加上"yaml", "tmpl"
示例 .air.toml 片段：
root = "." tmp_dir = "tmp" [build] cmd = "go build -o ./tmp/main ." bin = "./tmp/main" include_ext = ["go", "yaml", "tmpl"] exclude_dir = ["vendor", "tmp", "assets"] [log] time = true
调试时热重启与 Delve 共存怎么做
VS Code 调试器（Delve）和 air 不能同时接管同一个进程：你一按 F5，VS Code 就用 dlv 启动并挂起；而 air 在后台监听、编译、重启，两者冲突。强行共存会导致断点失效、进程被意外 kill、甚至 dlv 报 connection refused。
正确做法是分场景使用：
- 日常逻辑验证、接口跑通 → 用
air，改保存就跑，响应最快 - 查并发问题、看 goroutine 栈、跟踪变量生命周期 → 关掉
air，用 VS Code 的launch.json直接调dlv，断点稳、观察准 - 不想来回切？可以配两个 launch 配置：
Run with Air（仅终端输出）和Debug with Delve（带断点），通过 VS Code 的启动配置下拉菜单切换
launch.json 中确保 mode 为 exec，指向 air 编译出的二进制（如 ./tmp/main），而不是源码：
{
"name": "Debug with Delve",
"type": "go",
"request": "launch",
"mode": "exec",
"program": "./tmp/main",
"env": {},
"args": []
}
配置热更新要单独做，别指望 air 自动 reload config.yaml
air 只负责“代码改了重启进程”，它不会帮你解析新配置、校验字段、原子替换指针。如果你改了 config.yaml 但没写监听逻辑，服务里读到的还是旧值——哪怕进程已经重启，也只是用了上次启动时加载的配置快照。
真正可靠的配置热更新，得自己用 viper + fsnotify 实现：
- 必须在
viper.ReadInConfig()之后调用viper.WatchConfig()，否则监听不生效 -
viper.AddConfigPath("./configs")的路径必须真实存在，哪怕为空目录；路径不存在时WatchConfig()静默失败，毫无提示 - 回调里别直接改全局变量，要用
sync.RWMutex保护配置指针，或用atomic.Value原子替换整个结构体 - 配置变更后，记得通知依赖组件（如重置
rate.Limiter、刷新数据库连接池），否则业务逻辑仍按旧参数跑
最容易被忽略的一点：配置热更新和进程热重启是两层事。前者发生在单次运行周期内，后者是整个进程生命周期的替换。混在一起想，就会误判问题来源——比如改了 config 但没生效，先查是不是 viper.WatchConfig() 漏了，而不是怀疑 air 没触发重启。
