go modules 是默认模块系统，1.11内置、1.16起默认启用，无需gopath或vendor；模块路径需全局唯一且影响import和go get；依赖倒置优于导出接口；replace/exclude为临时手段，上线前须清理。
Go modules 是默认模块系统，无需额外配置
Go 1.11 起内置 go mod，1.16 后默认启用，GO111MODULE=on 已成事实标准。新建项目直接运行 go mod init example.com/myapp 即可初始化，不需要 vendor 目录或 GOPATH 约束。
常见错误是仍在 GOPATH 下手动建目录、或误删 go.mod 后用 go get 拉包导致版本混乱。只要项目根目录有 go.mod，所有 go 命令（如 go build、go test）就自动按模块解析依赖。
模块路径不是 URL，但需全局唯一且可解析
模块路径（module 行值）是导入路径前缀，不是必须能访问的网址，但建议与代码托管地址一致（如 github.com/user/project）。它影响其他项目 import 时的路径，也决定 go get 默认拉取源的位置。
- 本地开发时可用任意合法路径（如
myproject/internal），但发布到公共仓库后应与远程地址匹配，否则他人go get会失败 - 若模块路径含
v2及以上主版本号（如example.com/lib/v2），必须在 import 语句中显式带上/v2，Go 不做自动重写 - 私有模块（如公司内网 Git）需配置
GOPRIVATE环境变量，否则go命令会尝试走 proxy 或 checksum 验证，导致超时或 403
接口定义放调用方，而非实现方
Go 模块化不是靠“导出接口”来解耦，而是靠“依赖倒置”：调用方定义所需接口，实现方实现它。这样模块之间只通过稳定契约通信，不强制引入实现细节。
立即学习“go语言免费学习笔记（深入）”；
例如，payment 模块不该定义 PayService 接口并让 order 模块依赖它；而应由 order 模块声明 type PaymentProvider interface { Charge(...)}，再由 payment 模块提供满足该接口的结构体。这样 order 模块无需感知 payment 的内部路径或版本变化。
这种设计让模块升级更安全：只要实现仍满足调用方接口，go mod tidy 就不会报错，也不会意外升级破坏性变更的版本。
replace 和 exclude 是临时手段，上线前必须清理
replace 用于本地调试未发布的模块分支（如 replace github.com/x/y => ../y），exclude 用于跳过已知不兼容的间接依赖版本。但它们只在当前模块生效，无法被下游模块继承 —— 这意味着 CI 构建或他人拉取代码时可能因缺失 replace 而失败。
- CI 流水线中应禁用
replace，改用git tag+go mod edit -require锁定临时版本 -
exclude容易掩盖真实兼容性问题，优先考虑用go mod graph | grep找出冲突源头，再通过升级或降级某依赖解决 -
go mod vendor不解决根本问题，反而增加提交体积和同步成本；现代 Go 项目应信任go.sum和校验机制
模块路径拼写错误、私有域名未加 GOPRIVATE、本地 replace 忘记删除——这三类问题占实际项目构建失败的七成以上，检查时优先盯死这几处。
