Go模块系统在Go 1.11+后行为基本稳定，但向下兼容性取决于go.mod中go指令版本及各版本对模块解析规则的差异，如replace生效范围、+incompatible处理、私有模块认证逻辑等。
Go 模块系统本身不随 Go 语言版本“降级兼容”，但模块行为在 Go 1.11+ 后基本稳定；真正影响向下兼容的，是 go.mod 文件中声明的 go 指令版本、以及不同 Go 版本对模块解析规则的细微差异（如 replace 生效范围、+incompatible 处理、私有模块认证逻辑）。
go 指令版本不是“运行时要求”，而是模块语义约束
go 指令（如 go 1.19）写在 go.mod 开头，它不表示“必须用该版本 Go 运行”，而是告诉 Go 工具链：本模块遵循该版本起引入的模块语义规则。比如：
- Go 1.16+ 默认启用模块模式（
GO111MODULE=on），若项目go.mod写了go 1.16，但在 Go 1.15 下执行go build，会报错go: modules disabled—— 不是因为代码跑不了，而是工具链拒绝按模块方式解析 - Go 1.18 引入
go work，若go.work文件存在，Go 1.17 及更早版本直接忽略它，不会报错，但也无法使用多模块工作区功能 - Go 1.21 对
+incompatible版本的校验更严格，某些在 Go 1.19 下能通过go mod tidy的v2.0.0+incompatible依赖，在 Go 1.21 中可能因缺失/v2路径而被拒绝
不同 Go 版本对 replace 和间接依赖的处理差异
replace 在 Go 1.16–1.20 与 Go 1.21+ 的行为一致，但间接依赖的“提升优先级”逻辑有变化：
- Go 1.16–1.19：若某间接依赖被
require显式声明但带// indirect注释，go mod tidy可能仍将其降级为纯间接项，导致 MVS 选择其他版本 - Go 1.20+：显式
require行（即使带// indirect）会被 MVS 更高权重采纳；若手动删掉注释，效果更稳定 - Go 1.22（尚未发布，但已进入 dev 分支）开始限制
replace指向本地路径在远程构建中的使用，默认禁用，需显式设置GOPROXY=direct才允许 —— 这直接影响 CI 中replace ./local-fix的可用性
私有模块和 GOPRIVATE 在各 Go 版本中的实际表现
GOPRIVATE 环境变量从 Go 1.13 引入，但不同版本对其匹配逻辑和 fallback 行为有区别：
立即学习“go语言免费学习笔记（深入）”；
- Go 1.13–1.15：仅跳过 proxy 和 checksum DB，但仍尝试走 HTTPS GET 获取
go.mod；若私有仓库返回 401/404，会直接失败，不尝试 SSH 或其他 auth 方式 - Go 1.16+：支持
git@风格 URL，并在GOPRIVATE匹配时自动 fallback 到git协议（前提是git可用且配置了 SSH key） - Go 1.19+：引入
GONOSUMDB与GOPRIVATE联动机制，若两者配置域重叠，可完全跳过校验；但 Go 1.17 下即使设了GONOSUMDB，仍会尝试连接sum.golang.org，仅失败后才放弃
向下兼容最易被忽略的点：go.sum 校验和格式变更
go.sum 不是纯文本快照，它的哈希算法和格式随 Go 版本演进：
- Go 1.11–1.12：使用
h1:前缀 + base64 编码的 SHA256 - Go 1.13+：新增
h1:（SHA256）、go.sum中出现h1:和h2:（SHA512）并存，但工具链只校验当前版本支持的类型 - 关键问题：用 Go 1.21 生成的
go.sum若含h2:条目，在 Go 1.18 下执行go mod verify会报错unknown hash algorithm—— 并非内容损坏，而是解析器不认识新哈希类型 - 解决方案：团队统一 Go 版本；或 CI 中固定
GOROOT，避免混用不同版本生成go.sum
