go-licenses不能准确识别gpl依赖，它仅提取声明的许可证文本，不解析法律效力或版本差异，且对replace/exclude场景易误报，需结合go list -m和人工核查。
go-licenses 能否准确识别 GPL 依赖？
不能直接判断“是否引用了 GPL 库”，go-licenses 只负责提取已知依赖的许可证声明文本，不解析法律效力或版本变体（比如 GPL-2.0-only 和 GPL-2.0-or-later 在合规性上差异巨大）。它输出的是元数据，不是合规结论。
常见错误现象：go-licenses csv . 报告中显示某模块许可证为 GPL-2.0，但实际该模块在 go.mod 中是通过 replace 指向一个 MIT 分叉版本——go-licenses 仍会读取原始仓库的 LICENSE 文件，导致误报。
- 务必配合
go list -m -f '{{.Path}} {{.Version}}' all确认实际加载的模块路径与版本 - 对含
replace或exclude的模块，需人工核查替换目标仓库的 LICENSE 文件 -
go-licenses不处理间接依赖的许可证继承链（例如 A → B → C，C 是 GPL，但 B 声明为 MIT），这种场景必须用go mod graph追踪调用路径
为什么 go list -m all + license-checker 组合不可靠？
因为 go list -m all 输出的是 Go 模块树，而 license-checker（JS 工具）默认只解析 package.json，两者生态隔离。强行混合使用会导致：模块名格式不匹配（如 golang.org/x/net 被当成 npm 包名）、版本号解析失败、LICENSE 文件路径找不到。
典型翻车点：执行 go list -m all | xargs license-checker --only-unknown，结果全是 UNKNOWN —— 工具根本没去读 Go 模块里的 LICENSE 文件，只是在空转。
- Go 项目必须用 Go 生态工具：
go-licenses或github.com/owen-huang/go-license-detector - 多语言项目要分环境扫描：Go 部分走
go-licenses save . --save_path=licenses/go，JS 部分走license-checker --output=licenses/js/licenses.json - 禁止用统一脚本“一把梭”，不同语言的依赖元数据结构完全不同
CI 中 license 检查为何常被绕过？
多数团队把 go-licenses 当成“有就行”的摆设命令，没设退出码校验或白名单机制。最常见的是：命令执行成功但输出含 AGPL-3.0，流水线却继续往下走。
性能影响很小（go-licenses 扫描 200+ 依赖通常
- 默认不校验许可证类型，需显式加
--check-license=AGPL-3.0,SSPL-1.0参数触发失败 - 输出目录
--save_path=若未设为只读或未清理旧文件，可能混入历史缓存，漏检新增依赖 - 没绑定
go mod verify，恶意篡改的 checksum 可能让工具读到伪造的 LICENSE 内容
go mod why 查不到 GPL 依赖怎么办？
go mod why 只回答“为什么引入某个模块”，不回答“这个模块带什么许可证”。如果你发现 go-licenses 报出一个 GPL 模块，但 go mod why golang.org/x/crypto 显示 main module does not depend on，说明它来自 transitive 依赖的 indirect 引入——go mod graph 也未必能直接定位源头。
这时得倒查：
- 运行
go list -m -u -json all | jq -r 'select(.Indirect == true) | .Path'列出所有间接依赖 - 对每个路径执行
go-licenses csv ./path/to/module单独检测（注意路径必须是模块根目录） - 重点盯
golang.org/x/和cloud.google.com/go/下的子模块，它们常因小版本升级悄悄引入新依赖
真正麻烦的不是工具跑不出结果，而是许可证声明藏在 vendor 目录外的 git submodule 里，或者被 //go:generate 脚本动态拉取——这些场景 go-licenses 完全无感，只能靠人工审计。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
