go build 找不到本地包主因是模块模式下未将本地目录识别为可导入源；应通过replace、同模块子目录或临时GOPATH方式解决，且需用go list或panic验证是否真正链接。
go build 时找不到本地包的常见原因
直接报错 cannot find package 或 import "xxx" is a program, not an importable package，基本不是路径写错，而是 Go 没把你的本地目录识别为可导入的包来源。
现代 Go（1.16+）默认启用 module 模式，go build 不再从 GOPATH/src 自动查找本地包，而是只认当前模块根目录下的子目录（即 go.mod 所在位置及其下级）。
- 如果你用
go mod init myproj初始化了模块，但把待引用的本地包放在了~/mylib这种外部路径，go build就完全看不到它 -
import "./localpkg"这种相对路径写法只在go run临时编译时有效，不能用于正式构建或被其他模块引用 - 即使设置了
GOPATH，只要项目有go.mod，Go 就忽略GOPATH/src下的包
让 go build 正确链接本地包的三种方式
核心原则：所有被 import 的路径，必须能被 go list -m all 列出，且对应一个有效的模块路径。
-
方式一（推荐）：本地模块 + replace
在本地包目录（如~/code/myutils）里执行go mod init github.com/you/myutils；然后在主项目go.mod中加一行：replace github.com/you/myutils => ../myutils。这样import "github.com/you/myutils"就能指向本地源码，且go build会直接编译它 -
方式二：同一模块内组织
把本地包作为子目录放在主项目下，比如./pkg/db、./internal/auth，然后import "./pkg/db"改成import "myproj/pkg/db"（前提是主项目go.mod的module名是myproj） -
方式三：临时 GOPATH 模式（仅调试）
删掉项目里的go.mod，把本地包放到$GOPATH/src/github.com/you/myutils，再用go build—— 但这会失去 module 版本控制，不适用于协作或 CI
go build -o 输出路径与链接行为的关系
-o 只控制最终可执行文件的落盘位置，不影响包解析过程。但容易误以为“指定输出路径就能绕过模块约束”，其实完全无关。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
-
go build -o ./bin/app ./cmd/main.go：只要main.go里 import 的路径合法，编译就成功；-o不参与依赖查找 - 如果
main.goimport 了未声明的本地路径（如import "mylib"且没replace），无论-o怎么写，都会卡在 “cannot find package” - 注意：Windows 下路径分隔符用
/即可（Go 内部自动转换），不要写\，否则replace规则可能失效
验证本地包是否真正被链接进二进制
光看 go build 不报错还不够，得确认代码确实被编译进去，而不是被静态链接器优化掉或路径映射失败。
- 运行
go list -f '{{.ImportPath}} {{.Dir}}' myproj/pkg/db，输出应为实际磁盘路径，不是vendor或缓存路径 - 用
go tool objdump -s "MyFunc" ./bin/app查看符号表，能搜到你本地包里导出函数名，说明已链接 - 故意在本地包里加个 panic("debug local")，再
go build && ./bin/app，看是否触发 —— 这是最直白的验证
模块路径和 replace 规则一旦写错，Go 不会提示“路径可能不对”，而是静默跳过或 fallback 到 proxy 下载同名远程包。这是最容易被忽略的陷阱。
