go-licenses仅生成许可证报告而不检查合规性，需配合licenser验证license文件存在性及自定义脚本过滤高风险许可证，并注意ci缓存、构建约束和私有模块配置。
go-licenses 工具能自动提取依赖许可证，但默认不检查合规性
它只是把 go list -json -deps 的结果转成 HTML 或 JSON 报告，本身不判断「MIT 是否允许商用」「GPLv3 是否污染项目」。真要 enforce license policy，得自己加规则层或接其他工具。
实操建议：
- 用
go-licenses生成基础报告：运行go-licenses csv ./...或go-licenses html ./...，输出含License字段的表格 - 注意它对
go.mod中 replace / exclude 不敏感——被 replace 掉的模块仍会出现在依赖树里，可能误报已移除的许可证 - 若项目用了
//go:build条件编译，go-licenses会按默认构建约束扫描，可能漏掉某些平台专用依赖
用 licenser 检查 license 文本是否存在且可读
licenser（不是 license）专注验证每个依赖是否真有 LICENSE 文件、内容是否非空、是否在常见路径（如 /LICENSE, /LICENSE.txt）。它不分析条款，只解决「找不到文件」或「文件是空的」这类硬性缺失。
常见错误现象：
立即学习“go语言免费学习笔记（深入）”；
- 执行
licenser check ./...报错no license file found for github.com/some/pkg，但该包go.mod里声明了BSD-3-Clause——说明作者没放 LICENSE 文件，仅靠声明不可信 - 有些包把 license 放在
/docs/LICENSE或/assets/license.md，licenser默认不扫这些路径，需用--search-paths手动加 - Go 1.21+ 的
go mod download -json输出中Info字段可能指向一个 .info 文件而非真实 LICENSE，licenser会跳过这种“伪 license”
自定义脚本过滤高风险 license 类型（AGPL/GPL）
没有现成命令一键标红 AGPL，得写短脚本结合 go list -json -deps 和许可证关键词匹配。别依赖 go.mod 里的 // License 注释——那只是作者单方面声明，不可审计。
实操建议：
- 用
go list -json -deps -f '{{with .Module}}{{.Path}} {{.Version}} {{.GoMod}}{{end}}' ./...提取所有依赖元数据，再 grepagpl\|gplv3路径中的go.mod内容 - 注意
github.com/hashicorp/go-plugin这类包虽声明 MIT，但实际依赖了github.com/golang/protobuf（已归档，含隐式 BSD），得顺藤摸瓜查透依赖树 - CI 中跑检查时加
GOOS=linux GOARCH=amd64前缀，避免本地 macOS 下扫出golang.org/x/sys/unix这种无 license 声明但实际不参与构建的包
GitHub Actions 中集成要避开缓存导致的 license 漏检
GitHub Actions 默认缓存 ~/.cache/go-build 和 ~/go/pkg/mod，但 go-licenses 和 licenser 都依赖完整 module cache。如果缓存里混进了旧版依赖（比如上周的 golang.org/x/net@v0.14.0），新版本里新加的 LICENSE 文件就扫不到。
关键动作：
- 在 workflow 中显式加
steps: - uses: actions/cache@v3并设key: ${{ runner.os }}-go-${{ hashFiles('**/go.sum') }}，确保 go.sum 变更时缓存失效 - 不要用
go mod download后直接跑检查——它可能只下部分依赖；改用go list -m all确保全量解析 - 若项目启用了
GOPRIVATE，记得在 CI job env 里也配置，否则私有模块会被跳过，对应 license 检查就断了
真正麻烦的是那些没声明 license、也没放 LICENSE 文件、但代码里写了「Copyright 2023」的包——它们法律状态模糊，自动化工具根本没法打勾，只能人工盯住 import 路径列表定期复查。
