如何高效利用Composer构建项目依赖清单？

本文共计1029个文字，预计阅读时间需要5分钟。

依赖清晰+✨+安全报告。

您真正需要的可能是可读、可存档、可用于人工复现或对接的包列表。

直接使用命令：

• composer show：默认列出所有 require + require-dev 包，格式为 vendor/name version description
• composer show --installed-only：只显示实际存在于 vendor/ 中的包（排除因 --no-dev 被跳过的 dev 包）
• composer show -N：仅输出包名（适合管道处理，如 composer show -N | sort > deps.txt）
• composer show --tree：展示依赖树，能看清谁依赖了谁，但输出较冗长，不适合归档
• 想导出 JSON 便于脚本解析？用 composer show --format=json，字段包含 name、version、source、dist 等，但不含安全状态

为什么不用 composer audit 来“生成清单”

很多人误以为 composer audit 会先列一遍包再标红漏洞——其实它根本不输出完整包列表。它的输出只有两部分：advisories（有漏洞的条目）或空结果。即使项目有 200 个包，只要没匹配到 advisories，就只打印 No security vulnerabilities found。

• 它不显示未被收录的包（比如私有包、fork 包、本地 path repo）
• 它跳过所有带 -dev、dev-、dev-main 的版本（因 advisories 数据库不收录不稳定分支）
• 它不告诉你某个包“安全”，只告诉你“当前版本没被标记为已知漏洞”——这不等于“无风险”
• 执行失败时（如网络不通），可能直接报错退出，连空提示都不给

composer show 和 composer.lock 的关系

composer show 的数据源就是 composer.lock，不是 composer.json。这意味着：

• 它反映的是**此刻 vendor/ 中真实安装的状态**，包括子依赖的实际版本（比如 monolog/monolog 被 symfony/console 带进来 3.5.0，它就会显示 3.5.0，而不是 composer.json 里写的 ^3.0）
• 如果 composer.lock 缺失或损坏，composer show 会报错或返回不完整结果（此时应先 composer install）
• 它不校验哈希，也不检查平台约束（"platform": {"php": "8.1"} 不影响输出）
• 想确认某包是否真的被装进来了？ls vendor/vendor/name + composer show vendor/name 两步验证最可靠

CI/CD 里怎么稳定产出依赖快照

在自动化流程中，不能依赖交互式命令或本地缓存。以下写法经实测在 GitHub Actions / GitLab CI 中稳定运行：

• composer show --format=json --no-ansi > deps.json：禁用 ANSI 颜色避免解析失败
• composer show --direct --no-dev --format=plain | sort > deps-prod.txt：只列顶层生产依赖，按字母排序，方便 diff
• 别用 composer list —— 它只列命令，不是包
• 不要在没 composer install 的环境下跑 composer show，否则会 fallback 到 composer.json 的约束，漏掉实际安装的子依赖
• 若需带 Git 提交信息（如 lock 文件最后更新时间），可加一行：git log -1 --format="%h %ad" --date=short composer.lock 2>/dev/null || echo "no lock file"

真正容易被忽略的是：**composer show 输出的版本号，和 composer.lock 中记录的 version 字段完全一致，但和 dist.reference（即 Git commit hash）无关**。如果你靠这个清单做合规审计，得清楚它代表的是语义化版本，不是代码快照。