Go module 速查
依赖管理 / 私有仓库 / 工作区 · 点击复制
第一节
关于本工具
About拉下一个 Go 项目，`go mod tidy` 报错，`go.sum` 不匹配——排查依赖版本冲突，手动翻 go.mod 文件很累。这个工具把 go.mod 和 go.sum 解析成结构化列表，并画出依赖关系图，一眼看清谁依赖了谁、版本号是否一致。解析全部在浏览器内完成，go.mod 内容不会上传到任何服务器。
使用场景
拉新依赖版本冲突
接手一个遗留 Go 项目，go.mod 里锁了 github.com/gin-gonic/gin v1.7.4，但新写的中间件依赖 v1.9.0 的 Context.Request.Body 方法。直接改 go.mod 版本号，其他依赖（如 gin-contrib/sessions）可能不兼容。把当前 go.mod 和 go.sum 拖进工具，生成完整依赖图，在图上定位 gin 的直接依赖链，发现 sessions 模块最新版已适配 v1.9.0。确认后只改 gin 版本，sessions 跟着升级，编译通过。
审计上游库引入的传递依赖
安全团队扫描发现项目引入了 logrus v1.8.1，该版本依赖的 golang.org/x/crypto 有一个中等风险 CVE。但项目代码里没有直接 import logrus，怀疑是某个第三方库（如 kratos）间接引入的。把 go.sum 解析后，工具输出以 kratos 为根的子树，发现 kratos 通过 3 层传递依赖拉入了 logrus。截图发给上游仓库维护者，精确到具体版本路径，沟通换库或打补丁。
验证 vendor 目录是否完整
CI 流水线里配置了 go mod vendor，但某次提交后构建报 missing go.sum entry for module。排查发现有人手动改了 vendor/modules.txt 但没同步更新 go.sum。把当前 go.sum 与 vendor/modules.txt 同时粘贴进工具，对比两个列表的 module 版本号，工具标出 vendor 里多了 github.com/stretchr/objx v0.5.0 但 go.sum 里没有。回退那个文件，重新 go mod tidy 后 vendor 一致。
Go 1.18 升级后模块兼容性检查
项目从 Go 1.16 升级到 1.18，go.mod 里的 go 指令从 1.16 改成 1.18。但有些旧依赖（如 golang.org/x/net v0.0.0-202102）在 1.18 下可能因泛型语法报错。把整个 go.mod 粘贴进工具，工具按 go 指令版本过滤出所有依赖的 go 版本要求，发现 github.com/klauspost/compress v1.13.6 的 go.mod 里写的是 1.17，而实际代码里用了 reflect.SliceHeader，在 1.18 下被弃用。提前锁定该库的 v1.15.0 版本。
多人协作时 go.sum 合并冲突解决
团队 A 加了 pkg/errors，团队 B 加了 github.com/pkg/errors v0.9.1，两人同时改 go.sum 导致合并冲突。git merge 后 go.sum 出现重复行，go mod verify 报 hash mismatch。把冲突后的 go.sum 和两份原始 go.sum 分别贴进工具，工具列出每个 module 的 hash 值，发现同一 module 有两个不同 hash。按工具输出的 hash 差异表，保留 git 上最新提交的 hash，删掉旧行，go mod tidy 后冲突解决。
第二节
使用指南
Getting Started使用步骤
- 1在输入框粘贴 go.mod 文件内容，右侧预览区同步显示解析后的模块列表与版本号
- 2点击「生成依赖图」按钮，画布区域自动渲染出模块间的依赖关系拓扑图
- 3鼠标悬停任意节点，弹出该模块的 go.sum 哈希值及间接依赖数量
- 4拖动画布空白区域平移视图，滚动滚轮缩放，便于查看深层依赖链路
输入输出示例
| 输入 | 输出 | 说明 |
|---|---|---|
| module example.com/myapp go 1.21 require ( github.com/gin-gonic/gin v1.9.1 github.com/go-sql-driver/mysql v1.7.1 ) | 依赖图： - example.com/myapp (root) ├── github.com/gin-gonic/gin v1.9.1 └── github.com/go-sql-driver/mysql v1.7.1 解析结果： - Module Path: example.com/myapp - Go Version: 1.21 - Direct Dependencies: 2 - Indirect Dependencies: 0 | 常规：最简单的单层依赖，验证基本解析和依赖图结构 |
| module github.com/user/project go 1.22 require ( github.com/gin-gonic/gin v1.10.0 github.com/gin-gonic/gin v1.9.1 ) | 错误：go.mod 中存在重复的 require 条目：github.com/gin-gonic/gin 同时指定了 v1.10.0 和 v1.9.1。请合并或删除重复项。 | 边界：重复依赖条目，工具应检测并报错，而非静默取第一个或最后一个 |
| module example.com/empty go 1.20 | 依赖图： - example.com/empty (root) （无依赖） 解析结果： - Module Path: example.com/empty - Go Version: 1.20 - Direct Dependencies: 0 - Indirect Dependencies: 0 | 边界：空 go.mod（无 require 块），验证工具对最小输入的处理 |
| module example.com/indirect go 1.21 require ( github.com/gorilla/mux v1.8.1 // indirect ) | 依赖图： - example.com/indirect (root) └── github.com/gorilla/mux v1.8.1 (indirect) 解析结果： - Module Path: example.com/indirect - Go Version: 1.21 - Direct Dependencies: 0 - Indirect Dependencies: 1 | 常规：显式标记为 indirect 的依赖，验证工具能正确识别并归类 |
| module example.com/badver go 1.21 require ( github.com/foo/bar v0.0.0-20200101000000-abcdef123456 ) | 警告：依赖 github.com/foo/bar 使用伪版本 v0.0.0-20200101000000-abcdef123456，该版本可能不存在或已过时。建议使用正式版本。 依赖图： - example.com/badver (root) └── github.com/foo/bar v0.0.0-20200101000000-abcdef123456 (pseudo-version) | 易错：伪版本（pseudo-version）格式正确但 commit hash 可能无效，工具应给出警告而非直接解析 |
| module example.com/invalid go 1.21 require ( github.com/foo/bar v1.0.0 github.com/foo/bar v1.0.0 ) | 错误：go.mod 中存在重复的 require 条目：github.com/foo/bar v1.0.0 出现了 2 次。请删除重复项。 | 边界：完全相同的重复条目（版本也相同），工具应识别为重复而非忽略 |
| module example.com/malformed go 1.21 require ( github.com/foo/bar v1.0.0 github.com/baz/qux v1.2.3 github.com/baz/qux v1.2.3 ) | 错误：go.mod 中存在重复的 require 条目：github.com/baz/qux v1.2.3 出现了 2 次。请删除重复项。 | 易错：混合正常和重复依赖，工具应只报重复错误，不影响其他依赖解析 |
常见错误对照
1.go.sum 行格式错误：缺少 hash 算法前缀
✗ 错误
github.com/gin-gonic/gin v1.9.1 h1:abcd...✓ 修复
github.com/gin-gonic/gin v1.9.1 h1:abcd...go.sum 每行第三字段必须以 'h1:' 开头（表示 SHA-256），否则 Go 工具链会忽略该行，导致校验失败。
2.go.mod 中 require 块内版本号写成了 tag 名而非 semver
✗ 错误
require github.com/foo/bar v1.2.3-beta✓ 修复
require github.com/foo/bar v1.2.3-beta.1Go 模块版本必须严格遵循 semver 规范，预发布版本需要附加预发布标识符（如 -beta.1），纯 tag 名会被视为无效版本。
3.go.mod 中 indirect 注释缺失或位置错误
✗ 错误
require github.com/indirect/dep v1.0.0 // indirect✓ 修复
require github.com/indirect/dep v1.0.0 // indirectindirect 注释必须紧跟在版本号后、同一行内，且前面有空格。缺失或换行会导致 go mod tidy 报错或自动补全。
4.go.sum 中版本号与 go.mod 不一致
✗ 错误
go.mod 里是 v1.2.3，go.sum 里却是 v1.2.4✓ 修复
go.mod 和 go.sum 中同一模块的版本号必须完全一致go.sum 是对 go.mod 中每个 require 版本的 hash 校验，版本不匹配会触发 'go: verifying module: checksum mismatch' 错误。
5.go.mod 中 replace 指令路径写成了相对路径但缺少 ./
✗ 错误
replace example.com/old => ../local/module✓ 修复
replace example.com/old => ./../local/moduleGo 模块 replace 的本地路径必须以 ./ 或 ../ 开头，否则会被当作模块路径而非文件系统路径，导致 'not a valid module path' 错误。
6.go.mod 中 exclude 指令版本写成了范围而非精确版本
✗ 错误
exclude github.com/foo/bar v1.2.x✓ 修复
exclude github.com/foo/bar v1.2.3exclude 只接受精确的 semver 版本，不支持通配符或范围。Go 工具链在解析时会直接报 'invalid version'。
7.go.sum 中 hash 值长度不对（非 64 字符）
✗ 错误
h1:abc123（长度不足）✓ 修复
h1:abc123...（完整 64 字符 hex）go.sum 的 hash 值是 SHA-256 的 base64 编码，固定 64 字符。长度不符会被 Go 工具链判定为格式错误，跳过校验。
第三节
工作原理
How It Works核心公式
依赖版本选择 = max(满足约束的语义版本) 按 semver 比较
变量说明
依赖版本选择最终选定的模块版本号满足约束的语义版本符合 go.mod require 约束的所有版本semver 比较语义化版本号大小比较规则
示例
go.mod 中 require example.com/lib v1.2.0，实际仓库有 v1.2.0、v1.3.0、v2.0.0。约束为 ^v1.2.0（兼容 v1.x），满足的版本有 v1.2.0、v1.3.0。按 semver 比较，v1.3.0 > v1.2.0，最终选择 v1.3.0。
用户输入
本地处理
输出结果
第五节
常见问题
Q & A问这个工具能解析我自己写的 go.mod 文件吗，还是只能用标准格式？＋
答
只要你的 go.mod 文件是 Go 官方工具生成的合法格式就能解析。工具按 Go 官方语法逐行解析，不依赖文件来源。如果你手动编辑过导致格式错误（比如依赖版本号不符合语义化版本规范），解析会中断并在结果区提示具体行号和错误原因。建议先用 `go mod tidy` 修复后再粘贴。
问为什么我贴入 go.mod 后依赖图是空的，只显示了 module 名字？＋
答
依赖图需要 go.mod 文件里有 `require` 块。如果你的 go.mod 只有 `module` 和 `go` 两行，没有列任何依赖，图就是空的。另外注意：间接依赖（// indirect）也会显示在图上，但会标灰；如果只有直接依赖，只会画出直接依赖的节点。检查一下 `require` 块是否完整粘贴。
问这个工具能解析 go.sum 文件吗？它和 go.mod 有什么区别？＋
答
本工具主要解析 go.mod 的依赖声明结构，不解析 go.sum 的哈希校验内容。go.sum 是依赖包的哈希列表，用于防篡改验证，而 go.mod 是依赖声明文件。如果你需要验证 go.sum 的哈希值，建议用 `go mod verify` 命令。本工具只展示 go.mod 中的依赖关系图。
问我的 go.mod 里有 replace 和 exclude 指令，工具能识别吗？＋
答
能。本工具完整支持 `require`、`replace`、`exclude` 和 `retract` 指令。`replace` 会在依赖图上用虚线箭头标注替换关系，并显示替换后的版本号或本地路径。`exclude` 的依赖不会出现在图中，但会在结果区的备注栏列出。如果你的 replace 指向本地路径（如 `./local/pkg`），工具会显示该路径而非版本号。
问这个工具是纯浏览器运行的，我的 go.mod 内容会上传到服务器吗？＋
答
不会。本工具是纯前端实现（FE），所有解析和绘图都在浏览器本地完成。你粘贴的 go.mod 内容不会离开你的设备，也不需要网络请求。即使断网，只要页面已加载，也能正常使用。这是与其他在线 Go 工具（如需要后端处理）的核心区别。
问为什么有些依赖在图上显示为灰色？＋
答
灰色节点代表间接依赖（即被标注为 `// indirect` 的依赖）。这些依赖不是你的项目直接引用的，而是由你的直接依赖所引入的。Go 的依赖管理会自动分析并标记它们。本工具用灰色区分，方便你快速识别哪些是直接依赖（彩色），哪些是传递来的间接依赖。
问这个工具能处理大型项目的 go.mod 吗，比如上百个依赖？＋
答
可以，但不建议贴入超过 200 个依赖的 go.mod。虽然纯前端解析没有服务器压力，但依赖图渲染在浏览器中，过多节点会导致页面卡顿。如果依赖超过 100 个，建议只粘贴你关心的子模块的 go.mod，或者使用页面的搜索功能过滤特定依赖。实测 50 个依赖以内的图渲染最流畅。
问我贴入的 go.mod 里版本号带 +incompatible 是什么意思？＋
答
`+incompatible` 是 Go 模块系统的特殊标记，表示该依赖的主版本号（如 v2.x.x）没有对应的 go.mod 文件或模块路径没有按语义化版本规范调整（如缺少 `/v2` 后缀）。这通常意味着该依赖是旧项目升级到 Go modules 时留下的。本工具在图上会标注 `[incompatible]` 标签，不影响解析，但建议考虑替换为更规范的版本。
隐私保证所有计算与处理均在你的浏览器本地完成，输入数据不会上传服务器，也不会保存或共享。