Composer无内置健康检查，需组合composer validate、composer show --outdated --direct、git status --porcelain composer.lock和composer audit（2.5+）判断依赖状态，异常时触发精准通知。
如何用 shell 脚本检查 Composer 依赖状态
Composer 本身没有内置的「健康检查」命令，但 composer show --outdated 和 composer validate 足以覆盖大多数状态判断场景。关键不是「汇报什么」，而是「什么时候算异常」——比如有未锁定的 dev 分支、存在安全警告、或 composer.json 与 composer.lock 不一致。
实操建议：
- 优先用
composer validate --no-check-publish验证配置合法性（跳过 Packagist 检查，快且稳定） -
composer show --outdated --direct只看直接依赖的更新项，避免被间接依赖刷屏 - 用
git status --porcelain composer.lock判断 lock 文件是否干净——若有输出，说明composer install后没提交，是典型运维隐患 - 把
composer audit（需 Composer 2.5+）加入检查链，它能捕获已知 CVE，比单纯看 outdated 更贴近安全需求
推送通知该在哪个环节触发
不是所有状态变更都值得通知。盲目推送 composer update 成功消息反而会降低警觉性。真正该告警的是「异常态持续存在」或「人工干预失败」。
推荐触发点：
-
composer validate返回非 0：说明composer.json语法错误或字段非法，CI 必须中断 -
composer audit输出含Critical或High级别漏洞：需立即推送到运维群，附上--format=json解析后的包名和 CVE 编号 -
git status显示composer.lock已修改但未提交：发内部提醒（不钉钉/飞书），只写「lock 文件未提交，请确认是否遗漏git add composer.lock」 - 避免对
composer install成功做推送——它本就不该失败；若频繁失败，应查网络或镜像源，而非加通知
用 curl 发送钉钉/飞书通知的最小可行脚本
通知脚本的核心是「不依赖额外 PHP 扩展」，纯 shell + curl 即可。重点在于错误处理和内容裁剪，否则容易因 JSON 格式错误导致整个请求静默失败。
关键细节：
- 钉钉 Webhook 必须带
timestamp和sign（用openssl生成），飞书则需timestamp+nonce+body三者哈希，不能省 - 通知内容里禁用换行符
\n（JSON 字符串内转义），否则飞书会解析失败 - curl 加
-f -s -o /dev/null：-f 确保 HTTP 非 2xx 时返回错误码，-s 屏蔽进度条，-o 避免输出污染日志 - 示例片段：
curl -X POST "$WEBHOOK_URL" -H 'Content-Type: application/json' -d "{"msg_type":"text","content":{"text":"[Composer] audit found Critical: $PKG_NAME ($CVE_ID)"}}"
为什么不用 GitHub Actions 自带的 notify 功能
GitHub Actions 的 notify 或第三方 action（如 appleboy/slack-notification-action）看似省事，但实际埋了三个坑：
- 它们默认把整个
composer audit输出当文本塞进去，CVE 描述动辄几百行，淹没关键信息 - 无法区分「当前 commit 引入新漏洞」和「历史遗留漏洞首次被扫描到」——后者不该触发告警
- Webhook 调用失败时，多数 action 默认忽略，而自研脚本可用
if ! curl ...; then echo "notify failed" >&2; exit 1; fi主动报错中断流程 - CI 环境变量（如
GITHUB_HEAD_REF）和本地调试环境不一致，用 action 容易在 pre-commit 钩子中失效
复杂点往往藏在「谁来判定这条通知是否必要」——这没法交给通用工具，得自己写逻辑。比如只对主干分支推送漏洞通知，或跳过 dev- 前缀的包。
