Go 1.x 向下兼容有保障，但要求 go.mod 中 go 指令版本 ≤ 工具链版本；Go 1.21 起该指令为强制契约，低于声明版本直接构建失败，且不保证运行时行为完全一致。
Go 1.x 版本间向下兼容是默认保障的，但前提是你的 go.mod 中声明的 go 指令版本 ≤ 当前构建所用 Go 工具链版本；否则从 Go 1.21 开始，构建直接失败。
go 指令不是“建议”，而是强制行为契约
它不控制模块版本选择，只约束语言特性和工具链行为。比如你在 go.mod 里写 go 1.22，就表示你用了泛型别名、~T 类型约束等 Go 1.22 才支持的语法。若用 Go 1.21 构建，会报错：go: module requires Go 1.22 —— 不再是友好提示，而是硬性拦截。
- Go 1.21 之前：
go指令仅用于提示，工具链会尝试编译，失败时才报错 - Go 1.21 及之后：
go指令触发构建前校验，低于该版本直接退出 - 即使项目里没用新特性，只要
go指令写了高版本，就不能降级构建
向下兼容 ≠ 向前兼容，v2+ 路径才是关键分水岭
Go 1.20 项目能跑在 Go 1.22 上，这叫向下兼容；但 Go 1.22 编写的 v2 模块（路径含 /v2）可能无法被 Go 1.20 项目安全引用——因为旧工具链对 /v2 的语义解析不完整，尤其在 replace 或私有仓库场景下容易漏掉版本后缀校验。
- 主版本升级（如 v1 → v2）必须改模块路径，否则 Go 工具链无法区分，会当成同一模块导致冲突
- Go 1.19+ 对
/v2路径支持稳定；Go 1.16–1.18 存在边缘 case 解析异常，不建议生产环境混用 -
go list -m all显示github.com/x/y/v2 v2.1.0和github.com/x/y v1.5.0共存，是正常且安全的，二者路径不同
go.sum 校验和与 Go 版本无关，但校验行为受 GO111MODULE 和 GOSUMDB 控制
go.sum 文件记录的是模块内容哈希，跟 Go 工具链版本无关。但它是否被检查、如何检查，取决于环境变量：
-
GOSUMDB=off：跳过所有校验，风险极高，CI 中严禁启用 -
GOSUMDB=sum.golang.org（默认）：校验远程模块哈希，要求 Go 1.13+ - 私有模块需配合
GOPRIVATE=git.example.com/*，否则仍走公共 sumdb，导致校验失败 - Go 1.21+ 引入更严格的校验缓存策略，若本地
go.sum与远程不一致，会拒绝构建而非警告
真正容易被忽略的点是：向下兼容性只保证“能编译运行”，不保证“行为不变”。比如 Go 1.21 对 time.Parse 的时区解析做了细微调整，或 Go 1.22 优化了 runtime.GC 触发时机——这些不会破坏编译，但可能暴露原有代码中隐含的时序/边界假设。所以跨小版本升级后，务必运行完整测试，不能只看 go build 是否通过。
