go 1.17起module懒加载默认生效，依赖图修剪后go mod graph仅显示可达路径上的module，剔除未被实际import的间接依赖，go mod tidy据此动态精简require列表。
Go 1.17 起，module 懒加载（lazy module loading）不是可选行为，而是默认生效的构建机制；它依赖于 module 依赖图修剪（graph pruning），且对 go mod tidy、go build 和 go list 的行为有实质性影响——不理解这点，很容易误判依赖缺失或版本冲突。
module 依赖图修剪如何改变 go mod graph 输出
修剪前，go mod graph 显示所有 transitive 依赖，包括未被主模块代码实际 import 的 module；修剪后，只保留「可达路径」上的 module——即从 main module 的 .go 文件中 import 链能真正触达的那些。
- 常见错误现象：升级到 Go 1.17+ 后，
go mod graph突然少了某些 module，但go build仍能成功，开发者误以为依赖丢失 - 本质原因：这些 module 属于「未使用分支」，比如某个依赖 module 的某个 package 被另一个未被引用的 package 间接 import，该路径被修剪
- 验证方式：用
go list -deps -f '{{.ImportPath}}' ./...查看实际参与编译的 import 路径，结果与修剪后的 graph 一致 - 注意：
go mod graph不再反映「require 声明的全部依赖」，而只是「当前构建实际需要的依赖子图」
go mod tidy 在懒加载下的行为变化
go mod tidy 不再无条件保留所有 indirect 依赖，而是根据 import 图动态决定哪些 module 必须出现在 go.mod 的 require 块中。
Colly 是一个用于 Go 语言的快速开源爬取和爬虫框架。它适用于从简单的页面提取到异步爬虫处理大量页面集合，支持请求回调和结构化解析。
- 典型场景：你
require了 module A v1.2.0，它内部require了 module B v0.5.0；但你的代码没 import A 中任何用到 B 的 package → B 不会被写入你的go.mod - 风险点：若 module A 的某个新版本悄悄把原本「未使用」的 B 功能暴露为 public API，并被你代码间接调用，
go mod tidy可能漏掉 B 的显式声明，导致构建失败 - 兼容性影响：Go 1.16 及更早版本的
go.mod升级到 1.17+ 后，go mod tidy会自动删减冗余require行，需人工确认删减是否合理 - 强制保留某 module：用
go get example.com/b@v0.5.0（即使没 import）可将其加回require，并标记为// indirect
懒加载对 replace 和 exclude 的实际约束
replace 和 exclude 仅对「进入依赖图」的 module 生效；被修剪掉的 module，其 replace 规则不会触发，exclude 也不会起作用。
- 容易踩的坑：你在
go.mod里写了replace example.com/c => ./c2，但发现./c2根本没被构建 —— 因为example.com/c已被图修剪剔除 - 调试技巧：运行
go mod graph | grep c为空，就说明该 module 未进入图；此时replace是无效配置，可安全删除 - exclude 的局限性：它只能排除「本应进入图但被显式禁止」的 module；如果某 module 根本没被 import 链触达，
exclude完全不参与决策 - 性能影响：懒加载减少了 module 解析和 checksum 验证的范围，
go build在大型 monorepo 中启动更快
何时必须关闭懒加载（以及怎么关）
极少数场景下，你需要还原到 Go 1.16 的「全图解析」行为，比如：静态分析工具依赖完整依赖图、CI 中需预检所有 indirect 依赖的 license、或你手动维护的 vendor 目录要求包含全部 require 的 module。
- 关闭方式：设置环境变量
GOWORK=off并配合GO111MODULE=on，或在命令前加GOFLAGS=-mod=mod（注意这不是关闭懒加载，而是强制走老式 module 模式） - 真正等价于旧行为的 flag 是：
GOFLAGS=-mod=readonly go mod graph仍显示全图，但go build仍走懒加载；目前没有官方 flag 彻底禁用图修剪 - 替代方案：用
go list -m all获取所有require的 module（含 indirect），它不受懒加载影响，适合做 license 扫描 - 关键提醒：不要在生产构建中关闭懒加载——它不是 bug，而是为减少噪声、提升确定性而设计的收敛机制
最易被忽略的一点是：懒加载不改变语义版本选择逻辑（MVS），它只改变「哪些 module 参与 MVS 计算」；也就是说，version selection 还是那套规则，只是输入集合变小了。如果你的依赖树里存在隐式版本冲突（比如两个路径引入同一 module 的不同 minor 版本），懒加载可能让你根本看不到那个冲突——因为冲突路径被修剪了。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
