Composer不支持也不应自动发群聊消息，因其职责仅为解析安装依赖；依赖变更通知需靠Git+CI+Webhook组合实现，且仅packages中name/version变化才值得告警。
不能靠 Composer 命令自动把依赖变更发到群聊里——它压根没这个功能，也不该有。想“同步信息”，得靠流程和工具链补位，不是在 composer 上硬加钩子。
为什么 composer install / update 不会、也不该发消息到群聊
Composer 是一个本地依赖解析与安装工具，设计上不耦合任何外部通信能力。它的职责边界非常清晰：读 composer.json 和 composer.lock，算依赖树，下包，写 autoload，完事。强行给 composer update 加个 curl 发钉钉/企微的脚本，既不可靠（网络失败、token 过期、权限不足），又破坏可重现性（同一命令在不同机器行为不一致）。
更关键的是：谁该收到这条消息？什么时候发？发什么粒度？这些都不是 Composer 能回答的问题。
- CI 构建成功后发？那应该由 CI 系统（如 GitHub Actions、GitLab CI）触发，不是
composer install - 有人提交了新的
composer.lock？那属于 Git 事件，该由 webhook 或代码托管平台的集成来捕获 - 只通知“monolog 升级了”？但真正影响业务的可能是它间接带进来的
psr/log版本变更——这需要解析 lock diff，不是简单日志
真正能落地的“自动同步”方案：用 Git + CI + Webhook 组合拳
依赖变更的信息同步，本质是「代码变更 → 可观测 → 可响应」的过程。Composer 只负责前半段（生成变更），后半段必须交出去。
- 把
composer.lock提交进 Git 是前提——没提交，连变更都不存在，更别说通知 - 在 CI 流水线中加入
composer install --dry-run校验步骤，失败即阻断 PR，避免“改了 json 没更新 lock”的静默不一致 - 配置 Git 平台（如 GitHub）的 webhook，监听
composer.lock文件变动，推送到指定群聊（需自建轻量中转服务或用现成集成如 Zapier） - 用
git diff HEAD~1 -- composer.lock | composer show --lock --format=json类工具提取变更包列表，再格式化为易读消息（例如：“↑ monolog/monolog 2.8.0 → 2.9.1；↓ symfony/polyfill-php81 已移除”）
容易被忽略的协作盲点：lock 文件变更 ≠ 业务影响变更
很多人以为“lock 文件变了就该发消息”，但实际中大量变更毫无业务影响：时间戳更新、JSON 格式重排、dist hash 因 PHP 版本微调而变……这些都会导致 Git diff 出来一大片，却根本不该打扰任何人。
-
composer update后 lock 文件重写是常态，但只有packages数组里name和version字段变化才值得告警 - CI 中建议用
composer show --lock --format=flat生成稳定排序的版本快照，再做 diff，避开无关字段干扰 - 若团队使用 monorepo 或共享包，还要额外检查
packages-dev变动——测试工具升级（如 phpunit 从 10.5→10.6）可能让 CI 突然失败，但常被忽略
最常出问题的地方不在命令怎么写，而在于把“谁改了依赖”和“谁该知道”混为一谈。Composer 只管前者；后者得靠 Git 权限模型、PR 描述规范、CI 分类日志，以及人对变更意图的明确表达——比如在 commit message 里写清楚 “chore(deps): upgrade monolog for log context support”，比任何自动消息都管用。
