答案：replace不能删除旧require行，因其仅做路径映射，不提供版本信息，require仍需声明版本以满足go.sum校验和依赖解析。
replace 为什么不能直接删掉旧 require 行
Go 模块系统要求 require 行必须存在，即使你用 replace 指向了本地路径或新仓库。删掉 require github.com/old/repo v0.1.0 会导致 go mod tidy 报错：「missing go.sum entry」或「require statement not found」——因为 replace 不提供版本信息，它只做路径映射，版本仍由 require 声明。
常见错误是以为加了 replace github.com/old/repo => github.com/new/repo v2.0.0 就能删掉旧 require，结果构建失败。正确做法是保留原 require，再加 replace，或显式升级 require 到新模块并用 replace 修正导入路径。
- 如果新模块路径与旧模块不同（如从
github.com/old/repo迁移到github.com/new/repo），需同时保留旧require+replace，否则 import 语句会找不到包 - 如果只是版本升级但路径不变（如
v0.1.0→v2.0.0），可先go get github.com/old/repo@v2.0.0更新require，再用replace指向 fork 或镜像（如私有 registry） -
replace右侧若为远程模块（如github.com/new/repo v2.0.0），目标模块的go.mod中module名必须和左侧完全一致，否则导入时 panic：「cannot find module providing package」
废弃模块还在被间接依赖怎么办
执行 go mod graph | grep old/repo 能看到谁在拉废弃模块。如果输出里出现 your-module github.com/old/repo@v0.1.0，说明它是直接依赖；如果只有 some-dep github.com/old/repo@v0.1.0，那就是间接依赖——此时仅在你项目 go.mod 中写 replace 是不够的，因为 some-dep 自己的 go.mod 仍硬编码着旧路径。
解决路径只有两条：
一是让 some-dep 发版修复（不现实时跳过）；
二是用 replace 在顶层强制接管，并确保该 replace 覆盖所有可能路径（包括带版本后缀的完整路径）。
- 检查是否有多条匹配路径：运行
go list -m all | grep old/repo，看是否出现github.com/old/repo v0.1.0和github.com/old/repo v0.1.1两种——需为每个版本单独写replace，或统一 replace 到同一新路径 - 避免循环替换：比如
A replace B，而B的go.mod里又写了replace A，会导致解析失败 - 验证是否生效：运行
go list -m -f '{{.Replace}}' github.com/old/repo，输出应为非空路径；若为空，说明没命中
本地替换后 CI 构建失败怎么定位
replace 指向 ./local/repo 在本地跑得通，CI 却报 cannot find module providing package，根本原因是 CI 环境没有那个相对路径，或者路径下缺少 go.mod 文件。
这不是 bug，而是设计预期：Go 不会自动 clone 或生成缺失模块。CI 机器上 ./local/repo 不存在，replace 就静默失效，退回到原始远程依赖——但如果原始模块已 404，就会卡在 go mod download 阶段。
- CI 中禁止使用
./xxx类本地路径replace，必须改用远程目标（如github.com/new/repo v2.0.0）或环境变量注入（通过go mod edit -replace动态生成） - 若必须保留本地调试能力，建议用 Go Workspaces（
go work init && go work use ./local/repo），它不修改go.mod，且可通过GOFLAGS=-mod=readonly在 CI 中禁用 workspace - CI 启动前加校验：
test -d ./local/repo && test -f ./local/repo/go.mod || exit 1，避免静默 fallback
replace 和 go mod vendor 如何配合避免线上风险
go mod vendor 会把 replace 后实际使用的代码拷进 vendor/ 目录，而不是原始模块。这意味着：如果你 replace 到本地路径，vendor 就会包含你本地修改的代码；如果 replace 到远程 fork，vendor 就包含 fork 的 commit。
这既是优势也是坑——优势是构建可复现；坑在于，一旦忘记清理 replace，vendor/ 就悄悄混入未审计的代码。
- 每次
go mod vendor后，检查vendor/modules.txt里对应模块的路径是否为你期望的目标（比如github.com/old/repo v0.1.0 => ./local/repo） - 上线前执行
git diff vendor/，确认没有意外引入的本地 patch - CI 流程中增加
go mod verify，防止go.sum与vendor/内容不一致 - 团队规范：所有
replace行必须加注释说明用途和有效期，例如// replace: temp fix for CVE-XXXX until v2.1.0 release, remove after 2026-09
replace，而是它生效时悄无声息，失效时也悄无声息——没人告诉你哪条规则被忽略了，除非你主动查 go list -m -f '{{.Replace}}'。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
