老旧包无go.mod时，Go Modules默认打+incompatible标签，可用commit hash精确拉取（如go get github.com/old/lib@abc1234），或fork后添加go.mod并replace指向该fork以实现版本可控。
老旧包没 go.mod 怎么拉进来？
没有 go.mod 的包（比如 2018 年前发布的、只在 $GOPATH/src 里维护的老库），Go Modules 默认会打上 +incompatible 标签，表示它不遵守语义化版本规则，也不保证 v1/v2 路径隔离。这不是错误，是 Go 的兼容性兜底机制。
实际表现是：go get github.com/old/lib 会成功，但 go.mod 里写的是 github.com/old/lib v1.2.3+incompatible；后续 go mod tidy 可能悄悄升级到更高 patch 或 minor 版本，因为 Go 不知道它是否真兼容。
- 验证方式：运行
go list -m github.com/old/lib，若输出含+incompatible，说明该包无模块声明 - 锁定版本最稳做法：用 commit hash 替代 tag，例如
go get github.com/old/lib@abc1234—— hash 不受 tag 删除或重打影响 - 别信
@v1.2.3：老包常没规范打 tag，Go 会 fallback 到 latest 并只 warn，go list -m才是唯一真相
老包和新包共存时 import 路径怎么写？
关键不是“怎么写”，而是“不能怎么写”。如果老包被你手动加了 /v2 后缀（比如 import "github.com/old/lib/v2"），但它的源码里根本没 go.mod 声明 module github.com/old/lib/v2，Go 就会报错：invalid version: module contains a go.mod file, so major version must be compatible。
真实约束只有一条：老包的 import 路径必须和它原始发布时完全一致。哪怕它实际代码支持 v2 接口，只要没发过 v2 模块，你就只能用根路径 github.com/old/lib。
- 绝对不要手动改 import 路径加
/v2或/v3—— 这不是版本切换，是模块路径变更，老包不认 - 如果新包依赖
github.com/old/lib/v2，而你只有老包的github.com/old/lib，说明二者不是同一模块，无法替代 - 想桥接？用
replace是唯一选择，但仅限开发：在go.mod里写replace github.com/old/lib/v2 => ./vendor/old-lib-v2-fork，且 fork 里必须有合法go.mod
CI 构建失败，提示 cannot find module providing package xxx
典型现象：本地 go run main.go 成功，CI 上 go build 报这个错。根本原因不是包丢了，而是 CI 环境没启用 Modules 模式，或者用了 GO111MODULE=off。
老包本身不触发这个问题 —— 它的问题是版本漂移；这个错只发生在 Modules 模式下找不到模块提供者时，比如你删了 go.mod 但没清掉 go.sum，或误把老包放进了 vendor/ 却没配 -mod=vendor。
- 先查模式：CI 脚本开头加
go env GO111MODULE，确保输出on，不是auto或off - 再查路径：执行
go list -m，如果报go: not in a module，说明当前目录没go.mod或不在模块根目录 - vendor 不是免死金牌：有
vendor/目录 ≠ 自动离线，必须显式加go build -mod=vendor，否则 Go 仍走GOPROXY
如何让老包的 patch 修复不破坏现有逻辑？
老包没 go.mod，意味着它没有 go.sum 校验，也没有版本约束能力。你今天 go get 下来的 v1.2.3，明天可能因 proxy 缓存更新变成另一个 commit，行为已变但版本号没动。
真正可控的做法只有一种：fork 它，加 go.mod，打 tag，并用 replace 指向你的 fork。这样你才拥有对版本、哈希、API 兼容性的完全控制权。
- fork 后第一件事：在根目录运行
go mod init github.com/yourname/old-lib，然后go mod tidy - 打 tag 时严格按语义化版本：比如修复 bug 就打
v1.2.4，别打v1.2.3-fix—— Go 不认非标准 tag -
replace行要提交进go.mod：它不是临时 hack，而是你项目对老包的事实标准 - 注意
go.sum会包含你 fork 的哈希，一旦改代码就必须重跑go mod tidy，否则校验失败
