直接在composer.json的"scripts"中添加"format": ["@php vendor/bin/pint --test", "@php vendor/bin/pint"]可实现先检查后格式化，确保安全；使用@php vendor/bin/pint而非pint可避免PATH依赖，提升跨环境可靠性。
直接用 composer run 调用预定义的美化脚本，比手动敲命令快、稳、不易出错。前提是脚本已正确注册在 composer.json 里，且工具（如 Pint 或 PHP-CS-Fixer）已作为 dev 依赖安装。
怎么在 composer.json 里加一个 format 脚本
打开项目根目录的 composer.json，在 "scripts" 字段下加一条自定义命令：
"scripts": {
"format": [
"@php vendor/bin/pint --test",
"@php vendor/bin/pint"
]
}
这里用了两个命令组合：先跑一次带 --test 的只检查不修改模式，确认无误后再执行真实格式化。这种写法能避免误操作污染代码。
-
@php确保调用的是当前项目绑定的 PHP 版本，不是系统全局 PHP - 路径用
vendor/bin/pint而不是pint，避免依赖 PATH 环境变量，更可靠 - 如果用的是
php-cs-fixer，对应命令是@php vendor/bin/php-cs-fixer fix
为什么不能直接写 pint 而要写 vendor/bin/pint
因为 Composer 安装的二进制工具默认放在 vendor/bin/ 下，且不会自动加入系统 PATH —— 尤其在 CI 环境或 Docker 容器里，pint 命令大概率找不到，直接报 Command not found。
- 本地开发时，有些 IDE 或 shell 会把
vendor/bin加入 PATH，所以pint看似能跑，但不可移植 -
@php vendor/bin/pint是 Composer 内置语法，它会自动定位到当前项目的vendor/bin目录，跨平台、跨环境都一致 - 如果你用
php-cs-fixer，它的二进制名是php-cs-fixer，不是phpcsfixer或cs-fixer，拼错就失败
post-update-cmd 自动格式化容易踩哪些坑
想让每次 composer update 后自动格式化全部 PHP 文件？可以，但得小心副作用。
- 别在
post-update-cmd里直接调用php-cs-fixer fix全局扫描，它可能误触vendor/下的第三方代码（虽然默认会跳过，但规则文件配置错就翻车） - 推荐显式限定路径：
@php vendor/bin/pint app/ src/ tests/ --no-interaction - 加上
--no-interaction防止在 CI 中卡住；不加的话，Pint 遇到未提交变更会暂停并提示，导致构建失败 - 如果项目同时存在
.php-cs-fixer.php和pint.json，两个工具行为不一致，建议只留一个规则文件，避免团队成员执行结果不统一
最常被忽略的一点：格式化脚本本身没做错误处理，一旦某次 pint 执行失败（比如规则语法错误），整个 composer run format 会静默退出，看起来像成功了，其实什么都没干。加个 && echo "✅ Done" 或检查返回码，才能真正确认执行落地。
