能迁，但必须先解决路径一致性问题——否则go build会持续报cannot find module providing package或no go files in current directory；需显式执行go mod init github.com/your-org/your-project，确保go.mod中module声明与所有import路径完全一致，删净旧vendor后运行go mod tidy和go mod vendor，并配置goproxy/gosumdb以保障ci构建稳定。
能迁，但必须先解决路径一致性问题——否则 go build 会持续报 cannot find module providing package 或 no Go files in current directory。
go mod init 必须显式指定模块路径
别指望 Go 自动猜出模块名。老项目往往没 Git 配置、路径不规范（比如放在 /home/user/myproj），go mod init 不带参数大概率失败或生成错误路径。
- 执行
go mod init github.com/your-org/your-project（哪怕项目还没开源，路径也得是合法域名格式） - 检查生成的
go.mod第一行：module github.com/your-org/your-project—— 它必须和所有import语句开头完全一致 - 如果旧代码里写的是
import "utils"或import "server"，现在必须改成import "github.com/your-org/your-project/utils"，否则编译直接失败 - 本地子目录引用（如
import "./config"）不用改，点号路径始终有效
vendor 目录必须删干净再重建
旧 vendor/ 是 dep/glide 时代的产物，和 Go modules 不兼容。残留它会导致 go build 表面成功，实际却绕过 go.mod 读取旧依赖，版本更新完全失效。
- 迁移前先执行
rm -rf vendor - 确认
GO111MODULE=on（Go 1.16+ 默认开启，但旧 shell 环境可能仍为auto或off） - 运行
go mod tidy整理依赖，再跑go mod vendor生成新vendor/ - 若要用
vendor构建，必须显式加-mod=vendor参数：go build -mod=vendor，漏写就等于没生效
replace 指令容易写错且静默失效
调试时想把某个依赖替换成本地修改版，replace 是标准做法，但路径或版本写错，go build 会照常拉远端包，毫无提示。
-
replace github.com/foo/bar => ../bar要求../bar目录下必须有合法go.mod，否则被忽略 - 别写相对路径如
./local-fix，必须是相对于当前模块根目录的路径 - 如果依赖本身没打语义化 tag（比如只用
master分支），go mod tidy会报unknown revision，此时需手动指定 commit：replace github.com/foo/bar => github.com/foo/bar v0.0.0-20240501123456-abcdef123456 - 验证是否生效：运行
go list -m github.com/foo/bar，输出应含=>和本地路径
CI/CD 环境最容易忽略 GOPROXY 和 GOSUMDB
本地能过，CI 却卡在 go get 或报 checksum mismatch，八成是流水线没配代理和校验开关。
- CI 脚本里显式设置：
export GOPROXY=https://proxy.golang.org,direct（国内可换为https://goproxy.cn） - 若用私有仓库，必须同时配
GOPRIVATE=git.example.com/*，否则 Go 会跳过 proxy 直连失败 -
GOSUMDB=off仅限内网无校验服务场景；生产环境建议保留，但确保GOPROXY可达且 checksum db 可访问 - 检查
go env GOMOD输出是否指向项目内go.mod，不是则说明当前工作目录不被识别为 module 根（常见于在子目录里触发构建）
最麻烦的不是命令怎么敲，而是 import 路径改漏了一处——它不会报错，只会让某个包永远走本地缓存或 fallback 到 GOPATH，直到某天依赖升级突然崩掉。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
