composer 无法通过 composer.json 配置启用依赖版本监控通知，因其无相关配置项且不运行后台服务；实际需结合外部工具、钩子脚本与 ci 规则，以 composer.lock 变更为核心触发点，在 ci 层实现可观测、可审计的通知流程。
Composer 本身无法通过 composer.json 配置实现“启用依赖版本监控通知”——它没有这类配置项，也不运行后台服务。所谓“配置启用”，实际是组合外部工具、钩子脚本和 CI 规则，把被动命令变成可观测流程。
composer.json 里根本没 monitor 或 notify 字段
别在 config 或 scripts 里搜 monitor、notify、watch 这类关键词——它们不会生效。Composer 的配置体系里不存在版本监控开关。所有试图往 composer.json 里塞“自动检查更新”逻辑的写法，比如：
"config": {
"auto-outdated": true
}
纯属无效。Composer 不解析这种字段，也不会因此多发一次 HTTP 请求。
post-update-cmd 发通知？CI 里基本不可靠
很多人在 scripts 里加 post-update-cmd 调用 curl 或邮件脚本，指望每次 composer update 后发消息。但问题很现实：
Pandas 配置文件报告生成器
下载
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
- CI 流水线绝大多数跑的是
composer install，不是update，钩子根本不会触发 - 本地开发时手动
update才会走这个钩子，但没人真在本地等通知 - 钩子里做网络请求（如调 webhook）容易超时或失败，拖慢整个安装过程，且无重试机制
- 输出日志混在 Composer 日志里，难提取、难过滤、难告警
真正能落地的通知，得靠 CI + lock 文件变更监听
稳定、可审计、易集成的通知路径只有一条：把通知逻辑提到 CI 层，绑定 composer.lock 变更事件。这不是“配置”，而是工作流设计：
- GitHub Actions 中用
paths: ['composer.lock']触发 job；GitLab CI 用changes: [composer.lock] - job 内先执行
git diff HEAD~1 -- composer.lock | composer show --lock --format=json提取真实变更包名和版本 - 再调
composer audit --severity=high,critical --no-dev检查是否引入高危漏洞 - 最后用
gh issue create或企业微信机器人发结构化消息，内容含包名、旧/新版本、CVE 编号（如有）
注意：composer.lock 变更才是真实信号源——outdated 只告诉你“能升”，而 lock 文件提交才代表“已升”，后者才有通知价值。
audit 和 outdated 必须分开用，不能互相替代
安全漏洞和版本更新是两件事，命令行为完全不同：
-
composer outdated查的是满足当前约束的最新兼容版，退出码为3表示有更新，但它完全不看 CVE -
composer audit查的是已安装包是否匹配 Packagist 安全通告库，退出码为1表示发现漏洞，但它不关心版本号是否最新 - 两者输出格式不同：
outdated --format=json返回包列表；audit --format=json返回 advisory 列表，字段结构不兼容 - 私有包必须显式配置
repositories，否则audit对它们静默跳过，outdated也查不到
最容易被忽略的一点：安全元数据只在直连 https://packagist.org 时完整。国内镜像源普遍不同步 security-advisories 数据，用镜像跑 audit 等于没审。
