Go 不会自动重新编译已安装的依赖包，当 server 包被 go install 缓存到 pkg/ 目录后，后续 go build main.go 会直接链接旧版 .a 文件，导致代码修改不生效、符号未定义等错误。
go 不会自动重新编译已安装的依赖包，当 `server` 包被 `go install` 缓存到 `pkg/` 目录后，后续 `go build main.go` 会直接链接旧版 `.a` 文件，导致代码修改不生效、符号未定义等错误。
在 Go 的构建体系中，go build 默认仅编译当前命令（如 main.go）及其直接依赖的 源码，但若某个依赖包（如 server）已被 go install 编译并缓存为 .a 归档文件（位于 GOPATH/pkg/linux_amd64/server.a），则 go build 会优先复用该缓存版本，而非重新编译其源码。这正是你遇到 undefined: foo.MyName 的根本原因：你修改了 server/server.go 中的 MyName 函数，但 go build main.go 仍链接了旧的、不含该函数的 server.a。
✅ 正确的构建方式（推荐）
避免手动指定单个 .go 文件（如 go build main.go），而应使用 模块化路径构建：
# 进入项目根目录（即包含 main.go 的目录，建议为 GOPATH/src/your-project/） cd $GOPATH/src/your-project # 构建整个项目（含所有子包），强制刷新依赖 go build -o ./bin/main ./... # 或更规范地安装（生成二进制到 GOPATH/bin，同时更新 pkg 缓存） go install ./...
? ./... 表示递归匹配当前目录下所有包（包括 server/, models/ 等），确保所有依赖源码均被重新编译并更新缓存。
? 常见误区与修复方法
- ❌ 错误：go build main.go（孤立编译主文件，忽略包结构与缓存一致性）
- ❌ 错误：修改 server/server.go 后未触发依赖重建
- ✅ 修复：执行 go install server 或 go install ./...，强制重编译并更新 pkg/ 中的 .a 文件
? 项目结构最佳实践（Go 1.11+ 推荐模块模式）
虽然问题源于 GOPATH 模式，但现代 Go 已普遍采用 Go Modules（无需 GOPATH）。强烈建议升级迁移：
# 初始化模块（在项目根目录执行） go mod init github.com/yourname/yourproject # 自动发现并管理依赖 go mod tidy # 构建（完全绕过 GOPATH 缓存，基于 go.sum 精确控制） go build -o bin/main .
此时 go build 始终基于当前源码，无隐式缓存干扰，彻底规避此类问题。
? 快速诊断技巧
- 查看是否缓存了旧包：ls $GOPATH/pkg/linux_amd64/server.a（存在即可能被复用）
- 强制清除缓存（谨慎）：go clean -cache -modcache（重置构建缓存与 module cache）
- 验证实际编译来源：go build -x ./...（显示详细编译命令，可观察是否引用 pkg/ 中的 .a）
总结：Go 的设计哲学是“显式优于隐式”——它不会为你自动刷新已安装的依赖。每次修改底层包（如 server）后，必须显式执行 go install 或 go build ./... 来同步变更。遵循标准项目布局与模块化构建，即可彻底告别“改了代码却不生效”的困扰。
