post-update-cmd 脚本在 composer update 成功后自动执行，用于代码风格检查（如 php-cs-fixer –dry-run），不触发于 install 或 require；需配置在 composer.json 的 scripts 中，推荐使用 vendor/bin/php-cs-fixer 显式路径并加 –dry-run 防误改源码。
post-update-cmd 脚本能做什么
post-update-cmd 是 Composer 提供的脚本钩子，在 composer update 成功执行完依赖更新后自动触发。它不运行在 install 阶段，也不保证每次 require 都执行——只响应 update。如果你希望每次拉取新依赖后立刻检查代码风格（比如用 php-cs-fixer 或 phpcbf），这个钩子是合理入口。
在 composer.json 中配置 post-update-cmd
直接在 composer.json 的 "scripts" 字段里添加命令即可。注意：Composer 默认会把当前项目根目录设为工作目录，所以路径都基于项目根来写。
- 确保已全局或本地安装了代码检查工具，例如：
composer require --dev friendsofphp/php-cs-fixer - 命令必须可被 shell 直接执行；如果使用相对路径或自定义二进制，请用
vendor/bin/php-cs-fixer这类显式路径 - 建议加
--quiet或重定向输出，避免干扰update的正常日志流
{ "scripts": { "post-update-cmd": [ "@php vendor/bin/php-cs-fixer fix --dry-run --verbose", "echo "Code style check completed."" ] } }为什么 –dry-run 很关键
默认开启 --dry-run 是防止 update 过程中意外修改源码。一旦发现风格问题，CI 或本地开发能立刻感知，但不会自动覆盖文件。若想自动修复，需改成 fix（无 --dry-run），但要注意：
- 自动修复可能改变语义（尤其涉及空格、换行、数组语法等），和团队约定冲突
- git 会把修复后的文件标为已修改，容易误提交
- 某些规则（如
native_function_invocation）在 PHP 版本切换时行为不稳定
更稳妥的做法是：仅用 --dry-run 报错，再配合 Git hooks 或 CI 流程做拦截。
常见失败原因和绕过方式
执行失败时，composer update 默认会继续完成，除非你显式设置 "script-Error": "error"。但更常遇到的是路径或权限问题：
-
sh: vendor/bin/php-cs-fixer: not found→ 检查是否在require-dev中声明，且vendor/bin/是否存在该文件（windows 下可能是.bat） - PHP 版本不匹配导致
php-cs-fixer启动报错 → 在脚本前加版本检测，例如：php -v | grep -q '8.2' && vendor/bin/php-cs-fixer fix ... - 某些 ide 或 CI 环境禁用了 shell 扩展 → 改用 PHP 脚本封装，通过
"php scripts/check-style.php"调用
钩子本身不支持传参，也不推荐在其中启动长时间任务（如全量扫描 + 格式化整个 vendor/）。聚焦在 src/ 和 tests/ 就够了。