一眼识别间接依赖需运行go list -deps -f '{{if not .standard}}{{.path}} {{.version}}{{end}}' ./ | sort -u，再用go mod graph | grep和go mod why定位引入路径与必要性；慎用replace而非require控制版本，go mod tidy无法清理反射、插件、embed等动态引用。
怎么一眼看出谁在偷偷拉进来的间接依赖
间接依赖（indirect）不是错误，而是 go mod 的正常行为：只要某个包被你的代码或你直接依赖的库 import 过，它就会出现在 go.mod 里并标上 // indirect。真正要警惕的是那些“没人用却版本奇高”或“明显已弃用”的条目。
快速定位方式是运行：
go list -deps -f '{{if not .Standard}}{{.Path}} {{.Version}}{{end}}' ./ | sort -u
它会输出当前项目实际递归依赖的所有非标准库模块（不含重复），比 go list -m all 更贴近真实调用链。如果看到某个 golang.org/x/... 版本是 v0.0.0-2020... 或 v99.0.0，基本可以判定是上游某依赖升级后未收敛导致的孤儿版本。
更进一步，查清“谁引的”：
-
go mod graph | grep 'bad/pkg'—— 找出哪条路径把那个可疑包带进来的 -
go mod why bad/pkg—— 看是否真被业务代码触达；如果输出是(main module does not need it)，说明它只是残留，go mod tidy就能干掉
什么时候该用 replace 而不是 require 来控制间接依赖
不能靠在 go.mod 里加一行 require github.com/some/pkg v1.5.0 来“覆盖”间接依赖——Go 不会因此降级或锁定子依赖，反而可能引入冲突。唯一可靠的方式是 replace 或 exclude。
replace 适用场景：
- 上游依赖用了有严重 bug 的子依赖版本（比如
github.com/evil/log v0.1.0），而你无法推动上游修复 - 你想本地验证一个 patch，指向本地路径：
replace github.com/evil/log => ./fix-log（注意：CI 中必须同步提供该路径，否则失败） - 你想强制所有模块共用一个版本（如统一
github.com/sirupsen/logrus到v1.9.0），写成：replace github.com/sirupsen/logrus => github.com/sirupsen/logrus v1.9.0
慎用 exclude：它只阻止某版本被选中，不解决替代方案。若 exclude 后没别的版本可选，go build 会直接报错。一般只用于临时规避已知崩溃版本。
Colly 是一个用于 Go 语言的快速开源爬取和爬虫框架。它适用于从简单的页面提取到异步爬虫处理大量页面集合，支持请求回调和结构化解析。
go mod tidy 真的能删干净吗？哪些情况它会留尾巴
go mod tidy 是清理冗余依赖最安全的手段，但它只基于静态 import 分析，对以下情况无能为力：
- 反射调用的包（如
json.Unmarshal解析到未显式 import 的类型） - 插件式加载（
plugin.Open）、go:embed引用的包路径、或通过字符串拼接动态 import（Go 不支持） - 测试文件（
*_test.go）里引用的包，如果没加-mod=readonly检查，可能被误保留 -
replace指向本地路径的模块，即使代码里已删光 import，go mod tidy也不会自动删掉 replace 行
所以执行完 go mod tidy 后，建议再手动检查：
git diff go.mod —— 看有没有残留的 replace 或异常 indirect；
go list -m all | grep -v 'standard\|golang.org/x' —— 快速扫一遍第三方模块是否还存在明显过时项。
瘦身效果卡在 5MB 下不去？问题大概率不在依赖本身
很多团队花大力气删 go.mod 里的包，结果二进制体积几乎没变——因为 Go 编译器默认已做死代码消除（Dead Code Elimination）。你没 import 的函数、没调用的类型方法，根本不会进最终二进制（Go 1.22+ 默认开启，无需额外 flag）。
真正影响体积的往往是：
- CGO_ENABLED=1：引入 libc、openssl、zlib 等 C 依赖，静态链接后体积暴涨；生产环境务必设为
0 - 没加
-trimpath -ldflags="-s -w"：符号表和调试信息占体积 30%–60%，且暴露源码路径 - 基础镜像选错：用
golang:alpine构建，却 COPY 进debian:slim镜像，白费力气
验证是否真删了依赖：编译后运行 go tool nm ./binary | grep 'vendor\|third_party'，如果还有大量符号输出，说明对应包确实被引用了；如果空，那它早就不在二进制里了——别再对着 go.mod 反复删了。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
