Go 不会自动重编译已安装的依赖包，而是优先复用 pkg/ 下缓存的 .a 归档文件；若修改了 server/ 等本地包却未重新 go install，go build main.go 仍将链接旧版本，导致“未定义标识符”等静默错误。
go 不会自动重编译已安装的依赖包，而是优先复用 `pkg/` 下缓存的 `.a` 归档文件；若修改了 `server/` 等本地包却未重新 `go install`，`go build main.go` 仍将链接旧版本，导致“未定义标识符”等静默错误。
在 Go 的传统 GOPATH 工作流中，构建行为高度依赖包安装状态与构建路径语义，而非简单的文件时间戳比对。你遇到的 undefined: foo.MyName 错误，并非 Go 编译器“漏编译”，而是它忠实地复用了上次 go install server 生成并缓存在 pkg/linux_amd64/server.a 中的旧二进制包——即使你已修改 server/server.go 并注释了 MyName 函数，只要未显式触发重新安装，go build main.go 就不会重建该依赖。
? 根本原因：Go 构建的两级缓存机制
Go 在 GOPATH 模式下采用两层确定性构建：
- 源码级：src/ 下的 Go 源文件；
- 产物级：pkg/ 下预编译的 .a 归档（如 pkg/linux_amd64/server.a），供后续构建直接链接。
当执行 go build main.go 时：
- Go 解析 main.go 的 import 路径（如 "server"）；
- 查找 src/server/ 源码 ✅；
- 但默认跳过重新编译——转而检查 pkg/ 是否存在对应平台的 .a 文件；
- 若存在且签名有效（基于源码哈希），则直接链接旧包，完全忽略 src/server/ 中的最新修改。
这就是你注释掉 server/server.go 中全部代码后仍报错的原因：编译器根本没读新文件，它链接的是磁盘上早已存在的、含旧符号的 server.a。
✅ 正确做法：用 go install 强制刷新依赖
要使修改生效，必须显式重建并安装依赖包：
# 方式 1：进入 server 目录单独安装（推荐用于调试） cd $GOPATH/src/server go install # 方式 2：从项目根目录（如 src/main）批量安装全部依赖 cd $GOPATH/src/main go install ./...
? go install 不仅编译，还会将 .a 文件写入 pkg/、将可执行文件（如 main）放入 bin/，是 GOPATH 模式下唯一能强制更新依赖缓存的命令。go build 默认只构建当前主包，不处理依赖的重新编译。
? 推荐项目结构（符合 Go 官方约定）
避免路径歧义，严格遵循 How to Write Go Code：
$GOPATH/
├── bin/
│ └── main # go install 后生成于此
├── pkg/
│ └── linux_amd64/
│ └── server.a # 依赖包缓存
└── src/
└── github.com/yourname/myproject/ # 项目根目录（按域名组织）
├── main.go
├── server/
│ └── server.go
└── models/
└── user.go
然后在 $GOPATH/src/github.com/yourname/myproject 下执行：
go install # 构建 main 并安装到 bin/ # 或 go install ./... # 同时安装所有子包（含 server/）
⚠️ 注意事项与最佳实践
- 不要直接 go build main.go：它无法感知或重建 src/ 下的本地依赖变更；
- go build ./... ≠ go install ./...：前者仅编译输出到当前目录，不更新 pkg/；后者才真正刷新依赖缓存；
- 清理缓存（紧急时）：go clean -i server 可删除 pkg/ 中的 server.a 和 bin/server，迫使下次 go install 全量重建；
- 现代替代方案：强烈建议升级至 Go Modules（go mod init），它通过 go.sum 和本地 vendor/（可选）提供更可靠、无需 GOPATH 的依赖管理，彻底规避此类缓存混淆问题。
归根结底，这不是 Go 的“bug”，而是其设计哲学的体现：构建可重现性优先于开发便利性。理解并尊重这一机制，才能写出稳定、可协作的 Go 项目。
