go-licenses 无法输出许可证列表主因是模块模式未启用或 GOPATH 混用；需确保 GO111MODULE=on、正确初始化 go.mod、避免在 $GOPATH/src 下运行，并用 --include_indirect 处理间接依赖，同时检查 replace 目标 LICENSE 文件编码与位置。
go-licenses 命令跑不出第三方许可证列表？检查 GOPATH 和 module 模式是否混用
go-licenses 默认只扫描当前 module 的依赖，如果项目还在 GOPATH 模式下、或 go.mod 未正确初始化，它会安静地返回空结果，不报错也不提示。
- 先运行
go list -m all确认能列出所有依赖；如果报错no modules found，说明没进 module 模式，得先go mod init your-module-name - 确保
GO111MODULE=on（Go 1.16+ 默认开启，但 CI 或旧 shell 环境可能关着） - 不要在
$GOPATH/src下直接跑 —— 即使有go.mod，某些旧版go-licenses会优先走 GOPATH 路径逻辑，漏掉 replace 或 indirect 依赖
生成的 LICENSES.json 里缺了某个包？重点查 indirect 和 replace 依赖
go-licenses 默认跳过 indirect 依赖（即未被直接 import、仅被其他包引入的包），而很多常见库如 golang.org/x/sys 就属于这类；replace 语句指向本地路径或 fork 仓库时，它也常无法自动抓取对应 LICENSE 文件。
- 加
--include_indirect参数强制包含间接依赖 - 对
replace项，手动确认目标路径下是否存在LICENSE、LICENSE.md或COPYING；go-licenses只认这几个文件名，且必须在模块根目录 - 若用
git@地址 replace，工具无法访问私有仓库，会静默跳过 —— 此时需先go mod download并确认缓存中已有对应版本
输出 HTML 或 JSON 格式后发现许可证文本乱码或截断？别忽略 Go 的 text/template 编码限制
go-licenses 内部用 Go 的 text/template 渲染 HTML/JSON，遇到非 UTF-8 编码的 LICENSE 文件（比如 GBK 的中文协议）会直接丢弃内容，或把二进制部分当乱码塞进 JSON 字段，导致解析失败。
- 先用
file -i path/to/LICENSE查编码；非 UTF-8 的，用iconv -f GBK -t UTF-8 LICENSE > LICENSE.utf8转换后再放回模块根目录 - HTML 模板默认不转义 license text，如果原始内容含
或 <code>&，会破坏页面结构 —— 实际使用时建议加一层{{.LicenseText | html}}自定义模板，但原生命令不支持，只能改源码或用--format=json后自己处理 - JSON 输出中
LicenseText字段可能超长，某些前端 JSON 解析器（如老版 jq）会截断 —— 用jq -r '.[] | .LicenseText' licenses.json | wc -c核实长度
CI 流程里自动生成声明却总和本地结果不一致？环境变量和 Go 版本是关键差异点
CI 环境通常用最小镜像（如 golang:alpine），缺少 git、curl 等工具，而 go-licenses 在解析某些 SCM 类型的 module（如 git.example.com/repo）时，会尝试调用 git ls-remote 获取 commit 信息，失败就跳过该依赖的许可证提取。
立即学习“go语言免费学习笔记（深入）”；
- CI 中统一用
golang:slim或完整镜像，避免 Alpine 的 musl 兼容问题 - 设
GOPROXY=https://proxy.golang.org,direct，禁用私有 proxy（如有）—— 部分企业 proxy 会过滤 LICENSE 文件路径 - 固定 Go 版本：不同 Go 小版本对
go list -m -json的输出字段有差异，go-licenses v0.5.0在 Go 1.21 下可能漏掉Indirect字段判断
真正麻烦的是那些没有标准 LICENSE 文件的私有模块 —— go-licenses 不会猜，也不会 fallback 到上游 parent repo，它只看当前模块目录。这种必须人工补全，工具帮不上忙。
