go-licenses csv . 可导出Go项目所有依赖的许可证清单，输出CSV格式；需在模块根目录执行，安装命令为go install github.com/google/go-licenses/v2@latest。
用 go-licenses 快速导出依赖许可证清单
直接运行 go-licenses csv . 就能生成当前模块所有依赖（含间接依赖）的许可证类型、包路径和许可证文件位置。输出是 CSV 格式，方便导入 Excel 或脚本进一步筛选。
常见错误现象：不加 . 参数时命令会失败；在非模块根目录执行会漏掉部分依赖；未安装工具时提示 command not found。
- 确保项目根目录有
go.mod，且已执行过go mod download - 安装最新版：
go install github.com/google/go-licenses/v2@latest（注意不是v2.0.0-alpha.1这类旧快照） - 若只想看直接依赖，加
--direct参数；想排除测试用依赖，加--skip-test
识别 GPL 类强传染性许可证是否混入 MIT/Apache 项目
GPLv2/GPLv3/LGPL 的“传染性”意味着：一旦你的项目静态链接或以特定方式集成 GPL 库，整个分发产物可能需按 GPL 开源。这对闭源商业项目是硬性风险点。
检查时重点关注三类情况：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
go list -m all | grep -i "gpl\|lgpl"—— 快速筛出疑似 GPL 包名 - 对照
go-licenses csv .输出中license-type列是否为GPL-3.0、LGPL-2.1等 - 特别注意
github.com/xxx/yyy这类未声明许可证的包——go-licenses会标为UNKNOWN，必须人工核查其go.mod或仓库 LICENSE 文件
跨语言混合项目中 Go 依赖的许可证兼容性盲区
当 Go 模块被 Node.js 或 Python 服务调用（如通过 gRPC 或 HTTP API），主项目许可证（如 MIT）是否受 Go 依赖许可证约束？答案取决于集成方式：
- 动态链接或进程间通信（IPC）：一般不触发 GPL 传染，LGPL 允许
- 静态链接或嵌入 Go 二进制到其他语言容器镜像中：GPLv3 仍可能要求整个镜像开源
- 若 Go 模块本身以 SaaS 形式提供服务（不发布二进制），GPL 通常不约束调用方
最容易被忽略的是：CI 流水线里只扫了 npm ls --prod --depth=10，却没对 Go 子模块单独跑 go-licenses —— 多语言项目必须分语言扫描，不能靠单一工具覆盖。
把许可证检查塞进 CI 并自动拦截高风险依赖
不要等发布前才查。在 PR 提交阶段就该卡住 GPL 引入。示例 GitHub Actions 片段：
steps:
- name: Check licenses
run: |
go install github.com/google/go-licenses/v2@latest
go-licenses csv . > licenses.csv
if grep -q "GPL" licenses.csv; then
echo "ERROR: GPL license detected!" >&2
exit 1
fi更稳妥的做法是维护一个白名单文件 allowed_licenses.txt，用 awk 或 jq 校验每行 license-type 是否在其中。AGPL、SSPL 这类禁止项必须显式列出，不能只靠黑名单匹配。
真正难处理的不是 GPL 本身，而是那些许可证声明模糊、或同时含 MIT + GPL 双许可选项的包——比如某些库允许你选 MIT，但默认构建脚本拉的是 GPL 版本。这种细节，自动化工具扫不出来，得靠人盯。
