Go热重载不能直接反复go run，因每次启动新进程而旧进程未清理导致端口占用，且go run无文件监听能力；需借助air或fresh等工具实现构建、优雅重启与信号转发。
Go 热重载为什么不能直接 go run 反复执行？
因为 go run 每次都编译新进程，旧进程没被清理，端口会报 address already in use；同时无法监听文件变化，纯手动 Ctrl+C + 重新敲命令，效率低且易漏。
- 真实场景：改一行
main.go就得切终端、杀进程、再go run，调试 HTTP 服务时尤其烦躁 - 根本原因：Go 官方不内置热重载，得靠外部工具接管构建 + 启动 + 信号转发生命周期
- 关键约束：工具必须能捕获
SIGHUP或类似信号，优雅终止旧进程后再拉起新实例，否则 socket 资源泄漏
Air 配置文件 .air.toml 必须写的三处
air 强依赖配置文件，空跑或只改命令行参数大概率失败——它默认不扫描子目录、不重载 go.mod、甚至忽略 vendor/ 变更。
-
root = "."：显式指定项目根目录，否则可能从$PWD开始扫描，遇到嵌套模块就错位 -
tmp_dir = "tmp"：必须设为不存在的目录名（air会自动创建），否则并发多次保存时生成的临时二进制可能冲突 -
include_ext = ["go", "tpl", "tmpl", "html"]：加"env"如果用godotenv，加"sql"如果模板里拼 SQL，漏掉就等于“改了但没热重载”
示例最小可用配置：
[build] cmd = "go build -o ./tmp/main ." bin = "./tmp/main" include_ext = ["go", "env"] exclude_dir = ["assets", "node_modules", "tmp"] [watch] exclude_dir = ["tmp", "vendor"]
Fresh 启动报 fork/exec ./runner: no such file or directory
这是 fresh 的经典陷阱：它默认找当前目录下的 runner 二进制，但 Go 项目几乎不用这个名字，也不自动生成。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 错误做法：手动
go build -o runner .—— 下次改代码后fresh仍运行旧二进制，因为没触发重建 - 正确解法：在
fresh.conf里写死BuildCmd，例如BuildCmd = "go build -o tmp/app ."，再配RunCmd = "tmp/app" - 兼容性注意：
fresh不支持GOOS=js或交叉编译，Windows 上路径分隔符要用\，否则RunCmd找不到 exe
Air 和 Fresh 在 module 多级嵌套时的行为差异
当项目含 cmd/api、internal/pkg、pkg/lib 多个 go.mod 时，两者处理方式截然不同。
-
air默认只认根目录的go.mod，子模块变更不会触发重载——必须在.air.toml的watch.include_dir里手动加["cmd", "internal", "pkg"] -
fresh根本不解析go.mod，只按文件路径匹配，所以只要include_ext覆盖了所有.go文件，多模块也能 reload，但可能误触无关构建 - 性能影响：
air的模块感知更准，但配置复杂；fresh简单粗暴，小项目快，大项目 watch 文件过多会卡顿
真正容易被忽略的是：两者都不监控 go.sum 变更。升级依赖后，必须手动重启工具，否则新包代码不会生效。
