有效脚本须在composer.json的scripts中显式注册，如"format": "./vendor/bin/php-cs-fixer fix"；配置文件名必须为.php-cs-fixer.php且置于根目录；CI中应使用相对路径调用并确保dev依赖已安装。
直接配 composer.json 里的 scripts 就能跑起来，但多数人卡在路径、配置文件名、执行权限这三处——不是命令不识别，就是规则没生效，或者 CI 报 command not found。
composer.json 中 scripts 怎么写才有效
脚本必须显式注册，Composer 不会自动发现或运行未声明的命令。你装了 php-cs-fixer 或 phpcbf，但没在 scripts 里写清楚，它就永远只是个躺在 vendor/bin/ 里的二进制文件。
-
"format": "php-cs-fixer fix"—— 最简可用，但依赖默认配置文件（.php-cs-fixer.php）存在且位置正确 -
"check-style": "php-cs-fixer fix --dry-run --diff"—— 用于 CI，只检查不改，输出差异 -
"cs-fix": "phpcbf --standard=phpcs.xml"—— 注意：它不读.php-cs-fixer.php，只认phpcs.xml或命令行--standard - 所有命令都应使用相对路径调用：
./vendor/bin/php-cs-fixer比裸命名单更可靠，尤其在 CI 环境中
.php-cs-fixer.php 文件名和位置不能错
v3+ 版本只认 .php-cs-fixer.php 这个确切文件名，放在项目根目录。拼成 .php_cs、php-cs-fixer.config.php 或丢进 config/ 目录，工具都会静默忽略。
- 最简可用配置必须返回
PhpCsFixer\Config实例，不能只写数组 -
$finder要明确指定扫描范围，比如->in(__DIR__ . '/src')，否则可能漏掉tests/或app/ - 规则启用要写全，
'@PSR12' => true是开关，不是别名；'array_syntax'这类子规则需带参数数组
为什么本地能跑、CI 却报 command not found
根本原因是全局安装和项目级安装混用。CI 环境默认不加载全局 Composer bin，只认 vendor/bin/ 下的可执行文件。
- 删掉所有
composer global require安装的格式化工具，它们在 CI 里根本不可见 - 确保
friendsofphp/php-cs-fixer或squizlabs/php_codesniffer是--dev依赖，且composer install已执行 - CI 脚本里统一用
./vendor/bin/php-cs-fixer fix --dry-run，避免 PATH 查找失败 - Git 钩子如果用
composer run pre-commit，得确认钩子脚本执行时的当前工作目录是项目根目录
最容易被忽略的是配置文件与工具的绑定关系：php-cs-fixer 只读 .php-cs-fixer.php，phpcbf 只读 phpcs.xml，两者规则不互通、不兼容。选一个主工具，别指望靠改个配置文件让两个命令同时生效。
