不能，go-licenses仅提取归档许可证文本，不判断gpl冲突；它不分析许可证兼容性、不识别cgo隐式依赖、常漏报indirect依赖，需配合go list -m all和人工法务评审。
go-licenses 能不能直接判断 GPL 冲突？
不能。它只负责提取和归档许可证文本，不执行合规性推理。你看到 go-licenses save 输出的 GPL-3.0 或 AGPL-3.0，只是原始声明，不代表项目整体合规——关键要看你是否分发二进制、是否修改了 GPL 代码、是否链接了 GPL 库（尤其是动态链接时的传染性边界）。
常见错误现象：在 CI 中跑通 go-licenses 就认为“过了合规关”，结果上线后被法务叫停。
- 它不分析依赖树中各许可证的组合兼容性（比如
Apache-2.0+GPL-3.0在同一构建产物中是否合法） - 它不识别 Go 的
//go:linkname或 cgo 调用引入的隐式许可证依赖 - 它对
indirect依赖的许可证常漏报，需配合go list -m all手动补全
怎么用 go-licenses 抓出所有真实依赖的许可证？
默认命令 go-licenses save . --save_path=third_party_licenses 只导出直接依赖的许可证文件，但 Go 模块的 indirect 依赖（比如 golang.org/x/net 被 gorilla/mux 引入）往往才是许可证风险高发区。
实操建议：
- 先运行
go list -m all | grep -v "^\(github.com\|golang.org\|google.golang.org\)"筛出非标准域名模块，重点查它们的 LICENSE 文件 - 对每个可疑模块，手动
go mod download -x <module></module>查看缓存目录里的LICENSE或COPYING - 用
go-licenses csv . > licenses.csv导出结构化列表，再用脚本过滤含GPL、AGPL、SSPL的行
为什么 vendor 目录里找不到某些模块的 LICENSE 文件？
因为 go mod vendor 默认只复制源码，不复制 LICENSE、NOTICE 等元信息文件。而很多开源协议（如 Apache-2.0）明确要求分发时必须附带许可证副本。
解决办法只有两个：
- 用
go mod vendor -v（加-v参数）强制包含顶层 LICENSE 文件，但无法保证子依赖也带全 - 放弃 vendor，改用
go-licenses save生成独立许可证包，并在最终发布包中显式打包该目录 - 注意：Go 1.21+ 的
go mod vendor已移除-v参数，所以第一种方法在新版本失效
CI 流水线里怎么防住高风险许可证混入？
靠人工 review go.mod 不现实。必须自动化拦截。
推荐做法：
- 在
.github/workflows/ci.yml中加入步骤：go install github.com/google/go-licenses@latest，然后执行go-licenses check . --format=csv | grep -E "(GPL|AGPL|SSPL)" && exit 1 || true - 更稳妥的是用白名单机制：提前生成允许的许可证哈希列表（
sha256sum LICENSE），CI 中比对每个依赖的 LICENSE 文件哈希是否在白名单内 - 警惕
replace指令——它可能把 MIT 模块替换成内部 fork 的 GPL 版本，go-licenses仍会按原模块名报告，实际许可证已变
真正容易被忽略的点是：Go 工具链本身（go 命令、gc 编译器）和 libc 等底层依赖也有许可证，审计时只盯着 go.mod 会漏掉整个基础链。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
