go get -u 会因MVS策略盲目升级依赖导致线上服务崩溃，应改用go list -m -u查更新、逐个go get指定版本、运行测试、提交go.mod/go.sum，并启用vendor和显式major版本路径。
go get -u 为什么会悄悄毁掉你的线上服务
直接执行 go get -u 更新依赖，是生产环境崩溃最隐蔽的诱因之一。它不报错、不提示破坏性变更，只默默把 v1.2.3 升级成 v1.3.0——而后者可能删掉了你正在用的函数，或改变了 HTTP 客户端默认超时行为。
根本原因在于：Go 的 go get -u 默认采用 MVS（Minimal Version Selection）策略，它会选择“满足所有依赖的最新版本”，而非“最安全兼容的版本”。只要某个间接依赖要求更高版本，整个树就可能被拉高。
- 它不检查
go.sum校验和是否匹配新版本 - 它跳过
replace和exclude声明，直接写入go.mod - CI 构建时若未锁定模块（如没用
-mod=vendor），会重新解析依赖树，结果与本地不一致
如何让依赖更新可控、可验证、可回滚
真正安全的更新，不是“一键升级”，而是“先看、再试、后推”。关键动作必须手动触发，且留痕。
- 用
go list -m -u all查哪些包有更新，只关注方括号里标出的版本，比如github.com/sirupsen/logrus v1.9.0 [v1.10.0] - 对每个待更新模块，单独执行
go get github.com/sirupsen/logrus@v1.10.0，而非全局-u - 更新后立刻运行
go test ./...，尤其要覆盖集成测试（比如真实调用数据库或 HTTP 服务） - 确认无误后，提交
go.mod和go.sum——这两个文件就是你的依赖合约，不可省略
如果团队多人协作，建议在 CI 中加入检查：构建前比对 go mod graph 输出是否与主干一致，防止本地未 tidy 就提交。
立即学习“go语言免费学习笔记（深入）”；
Colly 是一个用于 Go 语言的快速开源爬取和爬虫框架。它适用于从简单的页面提取到异步爬虫处理大量页面集合，支持请求回调和结构化解析。
vendor 目录不是过时方案，而是生产兜底刚需
别信“vendor 已淘汰”的说法。当你需要 100% 确保线上构建与本地一致，vendor 是唯一不依赖网络、不依赖代理、不依赖 GOPROXY 缓存的方案。
- 执行
go mod vendor后，所有依赖源码都在vendor/下，编译时加-mod=vendor参数即可强制使用 - CI 构建命令应为：
go build -mod=vendor -o myapp ./cmd/myapp - 上线前可 diff vendor 目录变化，快速定位是否引入了意外模块
- 注意：
vendor不解决语义化版本冲突，它只是把已决议的依赖固化下来
major 版本跃迁必须显式声明路径
升级到 v2 或更高 major 版本（如 github.com/gorilla/mux/v2）时，仅改 go.mod 里的版本号毫无作用——Go 会忽略它，继续用 v1。
正确做法是：修改所有 import 语句，把路径末尾加上 /v2，例如：
import "github.com/gorilla/mux/v2"
否则会出现两个版本共存、接口不兼容、甚至编译失败。这不是 bug，是 Go Modules 的设计约束：不同 major 版本被视为完全独立的模块。
最容易被忽略的是：第三方库文档常只写 import "github.com/xxx"，但没注明当前版本是否需带 /vN 后缀。查它的 go.mod 文件第一行（如 module github.com/xxx/v2）才是唯一可靠依据。
