Composer script 不能替代健康度监控，它只是执行后即退出的 shell 命令别名，缺乏持续监听与自动告警能力，仅适合作为 CI 巡检脚本的一部分；真正可落地的是通过 Composer Plugin 在 install/update 后生成可追溯、可联动的健康快照。

Composer 自身不提供包健康度实时监控能力，所谓“自定义指令”只能做快照式检查，无法替代真正的运行时监控。

composer script 能否替代健康度监控？

不能。composer script 本质是 shell 命令别名，执行完即退出，不具备持续监听或自动告警能力。它适合做巡检脚本的一部分，但不是监控方案本身。

• 常见错误现象：composer run health-check 执行后只输出一次结果，没人看就等于没监控
• 典型使用场景：CI 流水线中校验依赖是否含已知 CVE、是否使用弃用包（如 symfony/console v4.x）
• 参数差异：需配合 composer show --outdated --direct 或调用 security-advisories 数据源，而非仅靠 composer status
• 性能影响：每次执行都会解析 vendor/autoload.php 和锁文件，频繁调用会拖慢 CI

如何用 composer plugin 实现轻量健康快照？

真正可落地的方式是编写一个 Composer Plugin，在 install / update 后自动生成健康报告，而非“实时”轮询。

Academic Composer Upload

辅助学术写作，包括查找资料、生成大纲、引用扩写及润色风格，同时确保引用规范。

下载

• 核心逻辑应聚焦在 EventSubscriberInterface 监听 PackageEvents::POST_INSTALL_CMD 等事件
• 不要尝试 hook autoload.php——Composer 的 autoloader 不暴露运行时包状态
• 推荐复用 roave/security-advisories 的数据源，或调用 https://security.symfony.com/api/check（需注意限流）
• 示例关键代码片段：

  public static function getSubscribedEvents(): array
  {
      return [PackageEvents::POST_UPDATE_CMD => 'onPostUpdate'];
  }
  public function onPostUpdate(Event $event): void
  {
      $io = $event->getIO();
      $io->write("✅ Checking package security advisories...");
      // 调用外部 API 或本地 JSON 文件比对
  }

为什么别硬凑“实时”二字？

PHP 是无状态语言，没有常驻进程模型支撑“实时”。强行用 watch -n 30 'composer run health' 只会掩盖三个问题：

• 无法感知运行时动态加载的包（比如插件系统通过 require_once 加载的第三方模块）
• 忽略 vendor-bin 或 phar 引入的工具链依赖（如 phpstan、psalm）
• 混淆“依赖声明健康”和“实际运行健康”——一个包没 CVE，不代表它在你的 PHP 版本下不会 segfault

健康度监控的关键不在“实时”，而在“可追溯”和“可联动”：把扫描结果写入 health-report.json，再由 Prometheus 抓取，或触发 Slack 告警。否则，再漂亮的自定义命令也只是个高级 echo。