module path必须是类url格式（如github.com/yourname/mailer），不可用相对路径或文件系统路径；初始化后不可修改，否则导致导入失败；本地开发可用replace映射，但上线前须删除；跨模块调用时import路径须与module path完全一致，含版本号如/v2；多模块协作应使用go.work统一管理。
go mod init 时 module path 写错，后续所有导入都会失败
module path 不是随便起的名字，它直接决定别人 import 时的路径，也决定 go get 能不能定位到你的包。写成 ./mylib、mylib 或 file:///path/to/mylib 都不行。
- 正确写法必须是类 URL 格式，如
github.com/yourname/mailer（哪怕你还没 push 到 GitHub） - 如果将来要发布到私有 GitLab，也建议用
gitlab.example.com/team/mailer，保持路径可解析 - 一旦初始化完成，
go.mod里的module行就不能改——改了等于换了个新模块，旧导入路径全部失效
本地开发阶段用 replace 指令，但别忘了上线前删掉
你在项目 A 中想试用还没发布的模块 B，最安全的方式不是拷贝代码，而是用 replace 把远程路径映射到本地目录。否则 go build 会报 cannot find module providing package。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 在项目 A 的
go.mod里加一行：replace github.com/yourname/mailer => ../mailer - 确保
../mailer目录下有合法的go.mod文件，且module声明与 replace 左侧完全一致 -
replace只在当前模块生效，不会被go mod tidy推送到远程，但容易被误提交——上线前务必检查并删除
跨模块调用时，import 路径必须和 module path 完全一致
Go 不认相对路径，也不认文件系统结构。你在代码里写 import "github.com/yourname/mailer"，Go 就只认这个字符串，然后去缓存或远程找对应模块。
- 即使两个模块物理上挨着（比如
./app和./mailer），也不能写import "./mailer"或import "../mailer" - 如果模块 B 的
go.mod声明的是module github.com/yourname/mailer/v2，那调用方就必须写import "github.com/yourname/mailer/v2"，缺/v2就找不到 - 版本升级到 v2+ 后，老代码不改 import 路径就编译不过——这不是 bug，是 Go 强制的版本隔离机制
go.work 是多模块协作的必要基础设施，不是可选项
当你有多个本地模块（比如 ./api、./shared、./cli）需要一起开发调试，只靠 replace 容易漏配、难维护，go.work 才是官方推荐的工作区方案。
- 在父目录执行
go work init，再逐个添加：go work use ./api ./shared ./cli - 这样
go run ./api或go test ./shared/...时，gopls 和构建工具才知道这些模块属于同一工作区 - 没
go.work时，IDE 可能提示no module found，go build可能因路径不一致而静默失败
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
