根本原因是当前目录未被Go识别为有效模块作用域；需在项目根目录执行go mod init并确保module声明与import路径完全匹配，且GO111MODULE=on、不在$GOPATH/src下。
为什么 go build 报错 “cannot find module providing package”
根本原因是 Go 模块系统依赖明确的 go.mod 文件和标准的导入路径，而代码没放在 $GOPATH/src 下（旧模式）或没初始化模块（新模式）时，go build 无法解析本地包路径。常见于：把项目直接放在桌面、下载 ZIP 解压后没执行 go mod init、或目录里有 vendor 但缺失 go.mod。
- 运行
go mod init <module-name></module-name>是必须的第一步，模块名建议用可解析域名（如example.com/myapp），哪怕只是本地开发——它定义了所有import路径的根 - 如果已有
import "mylib"这类无域名前缀的路径，Go 会当成远程模块去找，必然失败；必须改成匹配go mod init所设名称的相对路径（如import "example.com/myapp/mylib"） -
go build默认只认当前目录下的main包，若入口文件不在当前目录，需显式指定文件路径：go build ./cmd/myserver
本地包导入失败：路径对不上、go list 查不到
不是路径写错了，而是 Go 不会自动“向上找”父目录的模块。即使 mylib/ 和 main.go 在同一级，只要没在同一个模块声明下，就无法导入。
- 确保所有子目录都属于同一个
go.mod管理范围——go.mod必须位于项目根目录，且所有import路径以该模块名为前缀 - 用
go list -m all看当前加载了哪些模块；用go list ./...看哪些包被识别为本模块的一部分；如果某个子目录没列出来，说明它没被go.mod覆盖（可能误建了嵌套go.mod） - 禁止在子目录里手动运行
go mod init——这会创建孤立子模块，导致主模块无法引用其代码
replace 本地覆盖不生效？检查 go.mod 位置和路径拼写
replace 只在定义它的 go.mod 文件所在模块中起作用，且目标路径必须和 import 语句完全一致（包括大小写、斜杠方向）。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 替换语句写在项目根
go.mod中，例如：replace github.com/some/lib => ./local-lib，其中./local-lib是相对于go.mod的路径 - 被替换的 import 必须是完整路径：
import "github.com/some/lib"，不能是缩写或别名 - 执行
go mod tidy后，replace行不会自动加到require中——它只是重定向，不改变依赖声明 - Windows 下路径分隔符不影响，但
./local-lib里的.不能省略，否则会被当作远程模块处理
CI 或多环境编译失败：GO111MODULE=on 不能靠默认值赌
Go 1.16+ 默认开启模块模式，但某些旧 CI 镜像或 Dockerfile 仍设 GO111MODULE=auto，遇到无 go.mod 的目录就退化为 GOPATH 模式，直接报错。
立即学习“go语言免费学习笔记（深入）”；
- 在构建脚本开头强制声明：
export GO111MODULE=on，避免依赖环境变量默认行为 - Docker 构建时，
COPY必须包含go.mod和go.sum，且放在WORKDIR下——否则go build在空目录启动，找不到模块根 - 如果用
go build -mod=readonly，确保go.sum已提交，否则go mod download阶段会失败
模块路径不是命名习惯问题，是 Go 编译器解析导入语句的硬性依据。一个字母错、一级目录漏、甚至 go.mod 放错位置，都会让整个依赖链断裂——它不像其他语言能靠配置绕过。
