Composer audit 默认不缓存，每次全量扫描导致性能瓶颈；优化关键是避免重复扫描，可通过复用 Composer 全局 HTTP 缓存、自定义脚本替代或异步执行审计来提升效率。
Composer 的依赖审计（composer audit）默认不缓存结果，每次执行都重新扫描全部已安装包——这意味着在 CI/CD 或高频安全检查场景下，它会成为性能瓶颈。优化关键不是“加速扫描”，而是避免重复扫描。
为什么 composer audit 会慢？
它底层调用 Packagist 的安全告警 API（https://packagist.org/advisories），并逐个比对 vendor/composer/installed.json 中所有包的 name + version。没有本地缓存层，也没有增量校验逻辑。尤其当项目含 100+ 包时，HTTP 请求 + JSON 解析 + 版本匹配耗时明显。
- 不走 Composer 全局缓存目录（
cache-dir），也不读取composer.lock的哈希快照 - 即使
composer.lock没变，composer audit仍全量重查 - 无法跳过 dev-only 包（除非先用
--no-dev安装，但 audit 本身不接受该参数）
用 COMPOSER_CACHE_DIR 强制复用 HTTP 响应
虽然 composer audit 不直写缓存，但它底层用的 Guzzle HTTP 客户端会尊重系统级的缓存配置。只要把 Composer 的全局缓存指向本地磁盘，并确保 HTTP 层能复用响应，就能显著减少网络请求。
- 在 CI 环境中设置：
export COMPOSER_CACHE_DIR=/tmp/composer-cache - 搭配
composer config --global cache-dir /tmp/composer-cache确保一致 - Guzzle 默认启用基于文件系统的响应缓存（需
ext-curl+ext-zlib），路径落在$COMPOSER_CACHE_DIR/http下 - 注意：首次运行仍需全量请求；后续相同包版本组合会命中缓存，耗时可从数秒降至 200ms 内
用 composer show --format=json + 自定义脚本替代原生命令
官方 audit 命令不可配置、不可跳过已知漏洞包、也不支持静默模式。更可控的方式是导出已安装包清单，再用轻量脚本查 Packagist API 或本地缓存的 advisory DB。
- 生成精简输入：
composer show --format=json --no-dev | jq -r '.[] | "\(.name) \(.version)"' > packages.txt - 用
curl -s "https://packagist.org/advisories.json?packages=$(cat packages.txt | paste -sd, -)"批量查询（需自行处理分页与限流） - 或预先下载
advisories.json快照到 CI 缓存目录，用jq本地匹配（避免实时网络依赖） - 这样能跳过 dev 包、控制超时、添加重试、甚至过滤低危项（如仅关注
critical和high）
CI 流水线里别让 audit 成为阻塞点
安全审计不该拖慢构建，更不该因临时网络抖动失败导致部署中断。它适合异步触发或作为独立 job 运行，而非和 composer install 绑定。
- GitHub Actions 示例中，不要放在
buildjob 里，改用单独的security-auditjob，并设if: github.event_name == 'pull_request' - 加
--no-interaction --quiet避免意外等待输入或输出刷屏 - 用
|| true让非零退出不中断流水线（审计失败应发通知，而非直接 fail） - 真正关键的是：确保
composer.lock提交前已通过audit，而不是靠 CI 补救
最常被忽略的一点：Composer 审计结果的有效期其实只有几小时——Packagist 的 advisory 数据每 4 小时更新一次，但本地缓存不会自动刷新。如果你依赖缓存却没定期清理 $COMPOSER_CACHE_DIR/http，可能漏掉新公布的高危漏洞。
