go mod init 后必须运行 go mod tidy，因为 init 仅创建空 go.mod 文件，不分析 import、不下载依赖、不校验；tidy 才会扫描所有 .go 文件，补全缺失依赖、删除未引用模块，并同步更新 go.sum。
go mod init 之后为什么还要 run go mod tidy？
因为 go mod init 只生成空的 go.mod，不分析代码里的 import，也不会下载或校验依赖。真正让模块“活起来”的是 go mod tidy：它扫描所有 .go 文件，补全缺失的 require，删掉未被引用的依赖，并同步更新 go.sum。
常见错误现象：刚初始化完就直接 go build，报错 cannot find module providing package xxx —— 这说明依赖没拉下来，不是代码写错了，是漏了 tidy。
- 必须在每次新增/删减
import后运行go mod tidy，否则 CI 构建可能失败 -
go mod tidy -v可看到具体增删了哪些模块，适合排查意外引入的间接依赖 - 如果团队多人协作，
go.sum不一致会导致构建结果不可重现，tidy是统一校验和的前提
为什么 go.sum 文件不能手动编辑？
go.sum 是模块校验和的快照，由 Go 工具链自动生成并严格验证。手动修改会导致 go build 或 go test 直接失败，报错类似：verifying github.com/some/pkg@v1.2.3: checksum mismatch。
它的作用不是“记录用了什么”，而是“确保每次下载的字节完全一致”。一旦校验失败，Go 就会拒绝构建，防止供应链攻击或缓存污染。
Colly 是一个用于 Go 语言的快速开源爬取和爬虫框架。它适用于从简单的页面提取到异步爬虫处理大量页面集合，支持请求回调和结构化解析。
- 若需更换某个依赖版本，应通过
go get pkg@vX.Y.Z或修改go.mod中的require行，再跑go mod tidy - CI 环境中建议设置
GOSUMDB=off仅用于内网无校验源场景，但必须同步禁用GOINSECURE并严格管控代理 - 删除
go.sum后直接go mod tidy会重生成，但前提是网络可达且代理配置正确，否则会卡在 checksum 获取阶段
跨模块循环引用时 go mod 怎么报错？
Go Modules 本身不阻止 import 循环，但编译器会在 go build 阶段报错：import cycle not allowed，并列出完整的引用链，例如：example.com/a imports example.com/b imports example.com/a。
这类问题在模块化拆分初期高频出现，尤其当多个模块共享同一组 model 结构体时。根本原因不是 go mod 功能缺陷，而是接口与数据契约没提前约定好。
- 禁止不同模块间直接 import 对方的
model包，应提取公共 domain 类型到独立的example.com/domain模块 - 模块间通信必须走 interface + 依赖注入，而非 concrete type 传递
- 用
go list -f '{{.Deps}}' ./... | grep 'xxx'快速定位某包被哪些模块引用，辅助判断拆分边界
GO111MODULE=auto 在什么情况下会失效？
该模式只在当前目录或父目录存在 go.mod 时才启用模块模式；一旦项目根目录下没有 go.mod，即使子目录有，也会退回到 GOPATH 模式 —— 此时 go get 会把依赖装进 $GOPATH/src，且不生成 go.sum。
典型踩坑场景：IDE 新建项目默认不初始化模块，开发者直接写代码、加 import、run build，结果本地能过，CI 却失败，因为 CI 环境通常清空 GOPATH。
- 始终显式设
GO111MODULE=on，避免依赖环境路径判断 - CI 脚本开头加
go version && go env GO111MODULE，快速确认模块模式是否生效 - 团队应统一在项目根目录放一个空的
.gitignore和强制初始化脚本，比如./scripts/init-module.sh，内容为go mod init $(basename $(pwd)) && go mod tidy
go.mod 边界、每次变更都触发 tidy 校验、所有构建都基于 go.sum 锁定字节一致性 —— 这些动作必须变成开发流程里的硬性检查点，而不是可选步骤。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
