Go 不会自动重新编译已安装的依赖包；当 go build 发现 pkg/ 下存在对应 .a 文件且源码未被显式触发重建时，会直接复用旧编译结果，导致修改不生效——这是设计使然，而非 bug。
go 不会自动重新编译已安装的依赖包；当 `go build` 发现 `pkg/` 下存在对应 `.a` 文件且源码未被显式触发重建时，会直接复用旧编译结果，导致修改不生效——这是设计使然，而非 bug。
在 Go 的传统 GOPATH 工作流中（尤其是 Go 1.11 前），构建行为严格遵循“缓存优先”原则：go build 默认仅编译当前主包（如 main.go），不会递归检查或重建其导入的本地包（如 server/）；而 go install 则会将包编译为归档文件（如 pkg/linux_amd64/server.a）并缓存。一旦 server 包被 go install 过，后续 go build main.go 就会跳过 server/ 的源码重新编译，直接链接旧 .a 文件——这正是你注释掉 server/server.go 中的 MyName 函数后仍报 undefined: foo.MyName 的根本原因：编译器仍在使用旧缓存，而非你刚修改的源码。
✅ 正确构建多包项目的推荐方式
假设你的项目结构如下（符合 Go 官方约定）：
$GOPATH/src/github.com/yourname/myproject/
├── main/
│ └── main.go // import "github.com/yourname/myproject/server"
├── server/
│ └── server.go // package server
└── models/
└── user.go✅ 应始终在项目根目录（即 myproject/）执行以下任一命令：
# 方式1：构建整个项目（含所有子包），输出二进制到当前目录 go build ./... # 方式2：安装全部包（含可执行文件到 $GOPATH/bin），强制刷新缓存 go install ./... # 方式3：精准重建特定包（如 server），再构建主程序 go install server/ # 先刷新 server.a go build main/ # 再构建 main
⚠️ 切勿在任意子目录下单独执行 go build main.go（尤其当 main.go 不在 src/ 根路径时）。你当前的 go build main.go 命令因路径混乱，既未正确解析导入路径，又绕过了依赖包的重建逻辑，极易引发“修改无效”的幻觉。
? 关键注意事项与最佳实践
- GOPATH 结构必须规范：所有代码必须位于 $GOPATH/src/ 下的子目录中，且包导入路径需与目录路径严格一致（如 import "github.com/yourname/myproject/server" → 源码必须在 $GOPATH/src/github.com/yourname/myproject/server/）。
- 清理缓存可临时排障：若怀疑缓存污染，可安全执行 go clean -cache -modcache（清模块缓存）或手动删除 pkg/ 对应 .a 文件（如 pkg/linux_amd64/github.com/yourname/myproject/server.a）。
- 强烈建议升级至 Go Modules：现代 Go（1.11+）已默认启用 modules，可彻底摆脱 GOPATH 限制。在项目根目录运行 go mod init github.com/yourname/myproject，之后 go build 会自动识别并管理依赖，无需 GOPATH 约束，且 go build 默认递归处理所有 ./... 子模块。
- 验证导入路径是否正确：在 main.go 中检查 import 语句是否匹配实际目录结构，例如 import "./server" 是非法的相对导入，必须使用绝对路径（如 import "github.com/yourname/myproject/server"）。
? 总结：Go 的“不重编译”不是缺陷，而是通过显式构建指令（go install / go build ./...）保障构建可重现性与性能的设计选择。掌握 ./... 通配符、go install 的缓存机制及 modules 的现代化工作流，即可彻底规避此类问题。
