Composer 本身不发通知，依赖更新提醒需靠外部流程实现；推荐用 composer outdated 做本地提示、CI 中监听 composer.lock 变更并结合 composer audit 做安全审计。
Composer 本身不发通知，也不该发通知。所谓“依赖更新提醒”，本质是「谁在什么时候、基于什么变更、告诉谁、以什么形式」的问题，得靠外部流程补位，不是给 composer update 塞个 curl 就算完事。
用 composer outdated 做本地可感知的更新提示
这是最轻量、最可控的“提醒”方式——它不改任何东西，只告诉你哪些包能升，且可精确控制粒度：
-
composer outdated --direct：只看composer.json里你亲手写的依赖，跳过传递依赖干扰 -
composer outdated --minor-only：过滤掉主版本升级（如 2.x → 3.x），避免误判破坏性变更 -
composer outdated --format=json：方便脚本解析，比如 CI 中用jq '.[].name'提取包名列表 - 退出码是关键：
0表示无更新，3表示有更新——别依赖输出文本做判断，CI 里直接用退出码分支逻辑
在 CI 流水线里做可靠的通知触发点
把通知逻辑提到 CI 层，比塞进 post-update-cmd 钩子稳定得多：
-
composer install或composer update成功后发消息，意味着 lock 文件已落地、环境可重现，这时通知才有意义 - 监听
composer.lock文件变更更精准：GitHub Actions 可配paths: ['composer.lock']，GitLab CI 可用changes规则 - 用
git diff HEAD~1 -- composer.lock | composer show --lock --format=json提取真实变更项，过滤掉时间戳、hash 等噪声 - 通知内容别只写“xxx 升级了”，要带上下文：比如“
monolog/monolog2.8.0 → 2.9.1（含 CVE-2023-xxxx 修复）”，否则收件人无法判断要不要跟进
安全漏洞必须单独走 composer audit 流程
composer outdated 不管安全问题，composer update 也不会自动修 CVE。真正要防住漏洞，得单独跑审计：
-
composer audit是官方命令（Composer ≥ 2.5），默认检查全部依赖，加--no-dev可跳过开发依赖 - CI 中建议用
composer audit --severity=high,critical，把中低危当警告，高危及以上直接失败 - 注意：它只查已安装的包，不预测未来风险；如果某个包被标记为
abandoned，audit不会报，但你得自己盯 - 私有镜像源可能漏掉安全元数据，核心项目务必直连
https://packagist.org，别图快用国内镜像扛审计
别碰 post-update-cmd 发通知这种方案
它看着简单，实际踩坑率极高：
-
post-update-cmd只在composer update时触发，install不触发——而多数 CI 跑的是install，通知就断了 - 钩子里调
curl或写日志，一旦网络超时、token 过期、磁盘满，整个update就卡死（除非你手动加|| true，但那就失去失败感知） - 环境变量如
$COMPOSER_EVENT在不同 Composer 版本里行为不一致，CI 和本地结果可能对不上 - 最麻烦的是：它让同一行命令在不同机器上产生副作用（发消息/写日志），彻底破坏“可重现构建”原则
真正难的不是怎么发消息，而是定义清楚“什么才算值得通知的变更”。composer.lock 里一行 hash 改了，不等于业务受影响；一个包标了 abandoned，但你压根没调它的 API，也不用立刻换。提醒的价值，在于帮人快速判断“我是否需要现在做点什么”，而不是制造噪音。
