Go开发环境迁移需守住go.mod依赖图、GOPATH/bin工具链、项目级配置三样东西：漏任何一项都可能导致CI失败、调试报错或脚本静默跳过；go.mod与go.sum必须完整同步，私有仓库需配置认证，工具须用tools.go统一重装，go.work及本地配置文件（如.env、sqlc.yaml）不可遗漏。
Go 开发环境迁移不是“换台电脑重装一遍”，而是要守住三样东西：go.mod 依赖图、本地 GOPATH/bin 工具链状态、以及项目级配置（如 go.work、.env、sqlc.yaml 等）——漏掉任何一项，都可能让 CI 失败、本地调试报错或迁移脚本静默跳过。
go.mod 和 go.sum 必须完整同步，不能只复制代码
很多开发者把项目目录整个拷过去，却忘了 go.mod 里声明的依赖版本和 go.sum 里的校验和是绑定的。如果新环境没运行过 go mod download，或者 GO111MODULE=off 被意外启用，go build 可能回退到 vendor 或 GOPATH 模式，导致行为不一致。
- 迁移前在原环境执行
go mod verify，确认无校验失败 - 新环境首次
go build前，先跑go mod download -x（加-x看实际拉取路径，排查私有模块认证问题） - 若用私有仓库（如 GitLab），确保新环境
~/.netrc或git config --global url."https://token:x-oauth-basic@your.gitlab.com/".insteadOf "https://your.gitlab.com/"已配置
go install 的二进制工具不会自动迁移
go install 安装的 CLI 工具（比如 migrate、sqlc、buf）默认落在 $GOPATH/bin，而这个路径不随项目走。新环境没装，make migrate-up 就直接报 command not found，但错误日志里往往只显示 shell 执行失败，看不出是缺工具。
- 用
go list -f '{{.BinDir}}' -m查当前$GOPATH/bin路径，然后ls $BIN_DIR列出所有已安装工具 - 推荐做法：把常用工具写进
tools.go（空文件 +//go:build tools注释 +import _ "github.com/golang-migrate/migrate/v4/cmd/migrate"），再用go install统一重装 - 避免混用
brew install migrate和go install—— 驱动 tag（如-tags 'postgres'）可能不一致，导致migrate连不上 PostgreSQL
go.work 文件和多模块配置容易被忽略
用 go work init 管理多个 module 的项目（比如 backend + proto + sdk），迁移时只复制子模块会丢掉 workspace 级别设置。没有 go.work，go run 可能找不到本地依赖，gopls 会反复报 “no packages found”。
Colly 是一个用于 Go 语言的快速开源爬取和爬虫框架。它适用于从简单的页面提取到异步爬虫处理大量页面集合，支持请求回调和结构化解析。
立即学习“go语言免费学习笔记（深入）”；
-
go.work必须和各 module 的go.mod一起拷贝，且路径相对关系不能变（比如use ./backend要求backend/目录存在） - 检查
go env GOWORK是否指向正确位置；如果设了GOWORK=off，go.work会被无视 - VS Code 的 Go 插件默认读
GOWORK，但 GoLand 默认只认单 module，需手动开启 “Enable Go Workspaces”
本地开发配置不是“可选附件”，而是迁移成败关键
像数据库 URL、密钥、生成器参数这些，常藏在 .env、local.env、sqlc.yaml、buf.yaml 或 docker-compose.override.yml 里。它们不进 git，但直接影响 go test 是否通过、migrate up 是否连库成功。
- 建立
docs/local-setup.md，明确列出所有必须手配的本地文件及其字段说明（例如：DB_URL=postgres://user:pass@localhost:5432/db?sslmode=disable中的pass必须 URL 转义） -
migrate的 URL 若含@或/，不转义就会解析失败，错误表现为unknown driver "user:pass"—— 实际是解析器把密码部分当 host 截断了 - SQLite 路径要用绝对路径（
file:///full/path/db.sqlite），相对路径在go.work下不同 module 启动时工作目录不同，极易找不到文件
最危险的不是迁移失败，而是“看似成功”：go build 通过、test 通过、甚至 migrate version 显示最新，但某次 migrate up 因 URL 解析错误静默跳过，schema_migrations 表没更新，下一次上线就触发脏库报错。环境迁移的终点不是命令跑通，而是所有自动化流程（CI、本地 make、IDE 调试）在新机器上复现原始行为。
