Composer 无图形化导出功能，但可通过命令组合生成依赖清单与安全审计结果：composer show 获取安装包列表，composer outdated 检查过期依赖，composer audit（2.5+）执行CVE级安全扫描，最终应以 composer.lock 为准并附加时间戳与哈希值确保可复现性。

Composer 本身不提供“导出已安装清单”的图形化界面或一键审计报告功能，但可通过内置命令组合生成可靠的依赖列表与基础安全审计结果。关键在于用对命令、理解输出差异、避开缓存与本地修改导致的偏差。

composer show 列出所有已安装包及其版本

这是最直接获取当前项目依赖清单的方式，输出包含包名、版本、描述，且默认按字母排序，适合人工查阅或简单导出。

• composer show 显示全部已安装包（含 require 和 require-dev）
• composer show --direct 只显示 composer.json 中直接声明的包（不含传递依赖）
• composer show -t 输出树形结构，能看清依赖层级关系，但对自动化处理不友好
• 若需保存为文本：运行 composer show --direct > deps-list.txt，注意该文件不含时间戳和环境信息
• ⚠️ 常见误区：composer show 读取的是 vendor/composer/installed.json，如果手动删过 vendor 或改过包内容，结果可能与实际不符

composer outdated 识别过期依赖（含安全风险提示）

它不是静态清单，而是运行时比对 Packagist 最新稳定版的结果，是轻量级审计的第一步。从 Composer 2.2 起，默认会标出已知安全问题的包（需启用 security-advisories 插件或使用 composer audit）。

• composer outdated 显示所有可更新的包（含 minor/patch 级别）
• composer outdated --direct 仅检查直接依赖，更聚焦维护范围
• composer outdated --minor-only 过滤掉 major 升级，降低升级风险判断成本
• ⚠️ 注意：它不等于 CVE 扫描——没有启用 security-advisories 插件时，不会显示安全公告编号（如 symfony/symfony 的 symfony/security-csrf 漏洞），仅靠版本号比对无法覆盖所有已知漏洞场景

composer audit 生成最小可行安全审计报告

这是 Composer 2.5+ 内置的安全检查命令，底层对接 FriendsOfPHP/security-advisories 数据库，无需额外插件即可运行。

• composer audit 默认只检查直接依赖，输出格式简洁：每行一个带 CVE 链接的漏洞项
• composer audit --all 扩展至全部已安装包（含传递依赖），但耗时明显增加，且可能报出低风险或已修复但未更新的旧版本
• composer audit --format=json 输出 JSON，适合 CI 集成或后续解析（例如提取 advisory.id 和 package 字段）
• ⚠️ 关键限制：它不检测代码中硬编码的危险调用（如 exec() 使用不当）、配置错误或自定义包漏洞，仅覆盖开源社区已收录的 PHP 包安全通告

生成可交付的依赖清单文件（lock-based + 时间戳）

真正可靠、可复现的“已安装清单”，应以 composer.lock 为准，而非运行时扫描结果。手动导出时务必附带上下文信息。

• composer show --direct --no-ansi | sed 's/^[[:space:]]*//; s/[[:space:]]*$//' > dependencies-direct.txt 清理多余空格，适配部分 CI 工具解析
• 推荐组合操作：

  echo "# Generated on $(date -u +%Y-%m-%dT%H:%M:%SZ)" > deps-report.md
  echo "## Direct dependencies" >> deps-report.md
  composer show --direct --format=markdown >> deps-report.md
  echo -e "\n## Lock file hash" >> deps-report.md
  sha256sum composer.lock | cut -d' ' -f1 >> deps-report.md

• ⚠️ 不要依赖 composer install --dry-run 生成清单：它只模拟安装，不反映当前 vendor 实际状态；也不要用 ls vendor/，它漏掉合并到根 vendor 的全局包和软链接情况

真正的依赖可信度来自 lock 文件哈希与 composer install 的确定性还原能力，而不是某次 show 或 audit 的快照。导出动作本身很简单，难的是明确“这个清单用来做什么”——交付给安全部门？做合规存档？还是用于 diff 升级前后变化？不同目的决定要不要包含 dev 依赖、是否校验签名、是否集成 SCA 工具二次扫描。