当 go 函数从外部包导入时结果错误（如返回 1 而非预期的 16），但内联到主文件中却正常，这通常不是逻辑错误，而是因 go 构建缓存未更新导致旧版编译包被复用。
在 Go 项目中，尤其是像 Project Euler 这类多文件、多工具函数复用的练习场景下，开发者常将通用工具函数（如 SumOfDivisors、GetPrimeFactors）提取到独立包（如 util）中以提升可维护性。然而，一个极易被忽视却影响深远的问题是：Go 的构建系统默认会复用已缓存的 .a 归档文件（即已编译的包），而不会自动检测源码变更并重新编译依赖项。
例如，你在 util/util.go 中修改了 SumOfDivisors 的实现逻辑或修复了 GetPrimeFactors 的边界条件（如对 val == 0 或质数本身的处理），但若仅执行 go run 023.go，Go 工具链会直接链接之前构建好的 util.a——哪怕 util.go 已被编辑多次。这就导致：
- 新增的 fmt.Println("TEST") 完全不输出（因为调用的是旧二进制）；
- 逻辑修正无效，始终返回陈旧结果（如恒为 1）；
- 函数签名更改（如重命名）也不报错——旧包仍存在，链接成功。
✅ 正确做法是强制重建所有依赖：
go build -a -v 023.go # 或直接运行（同样触发强制重建） go run -a -v 023.go
其中：
- -a（--force）标志强制重新编译所有依赖包，无视缓存；
- -v（verbose）显示正在构建的每个包，便于确认 util 是否被重新编译（输出中应包含 util）。
? 补充建议：
- 日常开发中，可在修改 util/ 后主动执行 go install util，确保本地包始终最新；
- 使用 Go Modules（Go 1.11+）可更可靠地管理依赖版本，避免 GOPATH 下的隐式缓存陷阱（本例中 GOPATH 结构易加剧该问题）；
- 在 util.go 顶部添加 import "math" 并确保已声明（你代码中使用了 math.Pow 却未显式导入，这本身会导致编译失败——若能编译通过，说明你正链接的是一个不含该 math 调用的旧版本，这是缓存问题的强证据）。
? 总结：这不是代码 bug，而是构建语义问题。Go 的缓存机制在大型项目中提升效率，但在小型实验性项目中，需主动干预以保证一致性。牢记 -a 是调试“函数行为不一致”问题的第一检查项。
