go mod 失效主因是 GO111MODULE 未开启或 GOPATH 干扰；go mod graph 仅显示直接依赖且不含构建约束，需配合 go list -deps 和平台变量才能获取完整依赖视图。
go env 配置错，go mod 就会失效
很多人在 go mod init 后发现依赖拉不下来、go build 报 cannot find module，根本原因不是网络或代理，而是 GO111MODULE 没开或 GOPATH 干扰了模块模式。
Go 1.16+ 默认启用模块模式，但如果你在 $GOPATH/src 下初始化项目，旧版行为仍可能被触发；更常见的是手动设了 GO111MODULE=off 或没设（某些旧 shell 配置残留）。
-
go env -w GO111MODULE=on是最稳妥的全局开启方式（写入$HOME/go/env） - 临时验证：运行
go env GO111MODULE，输出必须是on - 如果项目根目录下已有
go.mod，但go list -m all只显示本模块，说明模块模式未生效——八成是环境变量问题
go mod graph 输出的是“扁平依赖快照”，不是完整树
go mod graph 每行输出形如 a v1.2.0 b v0.5.0，它只展示直接依赖关系，且不区分 require 和 replace，也不包含条件编译（如 // +build ignore）或测试专用依赖（_test 包）。
这意味着：你看到的图里没有版本冲突提示，也没有间接依赖的传递路径——比如 A → B → C，go mod graph 只会列出 A→B 和 B→C，但不会自动合并出 A→C 的隐式路径。
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 想看完整依赖链：用
go list -deps -f '{{.ImportPath}}' . | sort -u获取所有可达包 - 要查某包被谁引用：
go list -json -deps . | jq -r 'select(.Deps[]? == "golang.org/x/net/http2") | .ImportPath' - 注意：
go mod graph不校验go.sum，哪怕校验和不匹配，它照样输出“正常”的边
生成可视化依赖图时，go mod graph 必须过滤掉标准库
直接 go mod graph | dot -Tpng -o deps.png 会把 fmt、net/http 等标准库全画进去，节点爆炸式增长，图完全不可读。
标准库路径都以 cmd/、internal/ 或无域名前缀（如 fmt）开头，而第三方模块必然含域名（github.com/、golang.org/x/ 等）。过滤是刚需。
- 安全过滤命令：
go mod graph | grep -E '^[^[:space:]]+\.(com|org|io|dev)/' | grep -v 'golang\.org/x/tools/internal/' > deps.txt - Graphviz 渲染时加
splines=true和nodesep=20能缓解连线缠绕 - 如果项目用了
replace，记得在 DOT 文件里手动标注替换关系，否则图中仍显示原始路径
交叉编译和构建约束会让 go list 结果失真
go list -m all 默认按当前平台（GOOS/GOARCH）解析依赖，但如果你的代码里有 // +build linux 或 build tag，某些包在非目标平台下根本不会被 import，go list 就看不到它们。
比如一个只在 darwin 下启用的 GUI 组件，用 go list -m all 在 Linux 上跑，它压根不会出现在结果里——这不是 bug，是设计使然：Go 的依赖图是“构建时动态确定”的，不是静态声明的。
- 要模拟目标平台：先设
GOOS=linux GOARCH=amd64 go list -m all - 若依赖中混用 cgo，还需同步设
CGO_ENABLED=0（否则go list可能 panic） -
go mod graph不受构建约束影响，但它也不反映实际编译时哪些包会被剔除
GOOS、build tag、replace 规则实时变化的视图。真正关键的不是“画出来多好看”，而是清楚知道哪一行输出对应哪个构建上下文——漏掉这个前提，图再漂亮也没法指导排查。 
