旧项目安全初始化需运行go mod init example.com/oldproject，模块路径必须与未来import路径完全一致；否则需手动修正所有import语句，清理vendor目录，并确保go build通过。
旧项目没 go.mod，怎么安全初始化
直接在项目根目录运行 go mod init example.com/oldproject 就能生成初始 go.mod，但模块路径选错等于重写一半代码。关键不是命令执行成功，而是路径必须和未来别人 import "example.com/oldproject/utils" 时的字符串完全一致。
常见错误是随手写成 go mod init oldproject，结果所有内部 import "oldproject/utils" 全报错——Go 不会自动改源码里的 import 行。
- 如果项目原本在
$GOPATH/src/github.com/user/repo下，模块路径优先用github.com/user/repo - 执行前删掉残留的
vendor/目录（除非你明确要保留 vendor 模式） - 初始化后立刻跑
go build ./，报cannot find package说明 import 路径还没对齐
go mod tidy 报 “no required module provides package” 怎么修
这不是 go.mod 的问题，是代码里 import 路径不合法。Go Modules 只认绝对路径，比如 "github.com/user/lib" 或 "example.com/oldproject/sub"，不认 "./sub"、"mylib" 这类相对或短名。
打开报错提示里提到的 .go 文件，逐行改 import：
立即学习“go语言免费学习笔记（深入）”；
- 本地子包统一改成主模块路径 + 子目录，例如
import "example.com/oldproject/utils" - 第三方包必须和它自己
go.mod第一行的module名完全一致，比如对方是module github.com/uber-go/zap，你就不能写成import "go.uber.org/zap" - 私有 Git 仓库要确保
git config或~/.netrc已配认证，否则tidy卡在 clone 阶段
vendor 目录要不要留，和 go mod 共存会怎样
Go 1.14+ 默认忽略 vendor/，除非显式加 -mod=vendor 参数。留着旧 vendor/ 看似无害，实际埋雷：
- 本地
go build走模块模式，CI 里跑go build -mod=vendor却走 vendor 模式，行为不一致 -
go mod vendor只打包go list -deps ./能发现的包，_test.go里用的测试依赖不会进 vendor - 原 vendor 里若有 fork 分支（如
github.com/user/pkg@fork-branch），go mod vendor会按go.mod记录的 commit 拉取，可能丢定制修改
推荐做法：删掉旧 vendor/，先 go mod tidy 校准依赖，再 go mod vendor 生成新 vendor，最后用 diff -r vendor/ old_vendor/ 人工核对关键包。
CI 构建失败，该查哪几个地方
老项目 CI 崩溃，八成卡在这三处：
-
go get安装工具类命令（如golint）还在用，应全换成go install golang.org/x/lint/golint@latest（Go 1.17+） - 构建命令含
CGO_ENABLED=0 go build但没加-mod=readonly，导致意外写入go.mod - Docker 多阶段构建中，
FROM golang:1.19镜像默认启用 Modules，但如果 COPY 进来的源码没有go.mod，go build会退化为 GOPATH 模式并报no Go files in
模块路径一旦发布 v1.x 就不能改，否则下游无法升级；go.sum 必须提交到 Git，它不是可选文件，而是校验快照——跳过校验等于放弃防篡改能力。
