go不支持原生热部署，go run每次启动新进程导致delve调试会话重置；真正可行方案是air等工具配合dlv headless模式监听文件变更、自动构建并重启带调试服务的新进程，ide通过dap协议远程attach实现类热调试。
热部署本身不是 Go 原生支持的特性，go run 会重新编译并启动新进程，但无法保留状态或复用运行时；真正可落地的“类热部署调试”，必须靠外部工具链协同 Delve 实现——不是让 Go 自己热重载，而是让调试器持续 attach 到新进程。
为什么 go run 不能直接热调试
每次 go run main.go 都生成全新进程，PID 变、内存地址变、Delve 无法复用上次连接。断点失效、变量上下文丢失、goroutine 状态清空——这不是调试中断，是调试会话彻底重置。
-
go run启动的是临时二进制，没符号表持久化，Delve attach 时可能报could not launch process: could not find executable - 即使强行
dlv attach PID，进程生命周期太短，刚连上就退出 - 修改代码后手动重启 + 手动 attach，效率低且易漏步骤
air 或 reflex 配合 dlv 的真实工作流
这类工具本质是监听文件变更，触发构建 + 启动新进程，关键在于：它们能与 Delve 协同控制生命周期，避免调试器断连。
- 用
air -c .air.toml启动，配置cmd = "dlv exec ./main --headless --listen=:2345 --api-version=2"（而非go run） -
.air.toml中设delay = 1000（毫秒），确保 dlv 完全监听后再触发下一次构建 - 本地 IDE 连接
127.0.0.1:2345，不需每次重配；断点在源码层，只要路径一致就能命中 - 注意：
air默认清理旧进程，要关掉kill_delay或设为 0，否则 dlv 进程被误杀
VS Code 调试配置必须绕开 launch 模式
VS Code 的 type: "go" + mode: "auto" 会尝试调用 go run，和热部署冲突；必须用 dlv-dap 的 remote 模式，把控制权交给外部构建工具。
-
launch.json中"type": "dlv-dap"，"mode": "attach"，"port": 2345，"host": "127.0.0.1" - 去掉
"program"和"args"字段——这些由air控制，IDE 只负责连接 - 确保
dlv版本 ≥ 1.22（DAP 协议稳定支持），旧版用dlv dap启动会失败 - 如果提示
connection refused，先netstat -an | grep 2345确认端口是否被占用，air启动失败时 dlv 可能没起来
容易忽略的兼容性陷阱
热部署 + 调试不是简单叠加两个功能，底层机制有隐含冲突点。
- Go Modules 下，
go mod vendor后air仍可能读错vendor/路径，导致 dlv 加载符号失败——建议关闭 vendor，全程走 proxy - macOS 上
air默认用fork/exec启动子进程，但 dlv 在 headless 模式下需要ptrace权限；若报permission denied，需sudo sysctl -w kern.sysv.shmmax=67108864并重启终端 - Windows 用户注意：
dlv在 headless 模式下不支持--accept-multiclient，多 IDE 同时连接会失败，只能单点调试
真正的难点不在配置本身，而在理解“热部署”在这里只是个外壳——内核仍是进程级重启 + 调试器重连。任何试图让 Go 运行时自己 reload 代码的方案，都会撞上 Go 的编译模型硬边界。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
