本地安装+显式配置+Composer脚本驱动是最稳定、可复现、团队友好的方案
在PHP项目的代码格式化实践中，一个共识正在形成：本地安装、显式配置、再通过Composer脚本驱动，是当前最稳定、可复现且对团队协作最友好的方案。相比之下，全局安装基本等同于给自己埋雷——不是说完全不能用，而是每次切换项目，你都得跟PATH环境变量较劲、核对版本号、清理缓存，纯属自找麻烦。
为什么必须本地安装 friendsofphp/php-cs-fixer
很多开发者抱怨全局安装后php-cs-fixer命令找不到，其根源在于Composer的vendor/bin目录没有被加入系统的PATH。而如果强行添加，又会引发多项目间的版本冲突。本地安装则能完美规避这些痛点：
- 二进制路径确定无疑：直接指向
vendor/bin/php-cs-fixer（Linux/macOS）或vendor\bin\php-cs-fixer.bat（Windows）。 - 版本锁定：依赖版本被牢牢锁在
composer.lock文件中，CI/CD流水线可以完美复现，无需任何额外配置。 - 项目隔离：不同项目可以分别使用v3.52和v3.58版本，彼此互不干扰。
- 开箱即用：执行
composer require --dev friendsofphp/php-cs-fixer后即可使用，完全不用碰环境变量。
php-cs-fixer fix 不生效的常见原因
有没有遇到过这种情况：信心满满地运行vendor/bin/php-cs-fixer fix，结果没有任何文件被修改？大概率是踩中了下面这几个坑：
- 漏了关键参数：从v3版本开始，默认运行模式是
--dry-run（只检查，不写入）。必须显式加上--write参数，或者去掉--dry-run，工具才会真正保存修改。 - 没指定目标目录：命令默认只扫描当前目录下的
.php文件。如果想处理src/和tests/目录，需要明确写出：vendor/bin/php-cs-fixer fix src/ tests/。 - 配置文件名称错误：规则文件的名字必须是
.php-cs-fixer.php（注意开头有个点），而不是.php_cs、php-cs-fixer.php或config.php。 - 配置中缺少扫描器定义：如果在配置文件中漏掉了
setFinder()方法来定义扫描范围，工具很可能什么都不做，或者错误地去扫描vendor/目录。
如何让 composer format 真正可用
在composer.json的scripts区块中配置命令，关键目标不是“能运行”，而是“运行得精准、不出错”：
立即学习“PHP免费学习笔记（深入）”；
- 显式指定配置文件：使用
"format": "php-cs-fixer fix --config=.php-cs-fixer.php --verbose"。这能避免加载可能随版本变化的默认规则，保证稳定性。 - 为CI场景优化：配置如
"check-style": "php-cs-fixer fix --config=.php-cs-fixer.php --dry-run --diff --using-cache=no"的命令。禁用缓存能确保每次代码风格检查的结果完全一致。 - 简化命令路径：不必写冗长的
vendor/bin/php-cs-fixer。Composer会自动将项目的bin-dir加入当前进程的PATH，直接写php-cs-fixer更简洁。 - 启用详细输出：加上
--verbose参数。这样在出错时，你能看到具体是哪个文件、哪条规则导致了失败，比静默退出友好得多。
Git pre-commit 钩子怎么写才不卡提交
提交前钩子（pre-commit hook）的设计哲学不是功能越重越好，核心在于快速、稳定且允许跳过：
- 预检而非修复：使用
composer run cs:check（对应--dry-run --diff模式）进行预检。如果发现差异，就中断提交，把修复动作留给开发者手动执行composer format。这能避免自动修改代码导致Code Review时的diff混乱。 - 添加跳过逻辑：例如加入
git diff --cached --quiet || exit 0的判断。如果没有已暂存的文件，就直接通过，不浪费任何时间。 - 必须设置缓存文件：在配置中调用
setCacheFile('.php-cs-fixer.cache')。否则在大项目中，每次提交前都会进行全量扫描，耗时可能长达数秒。
最后，有一个极易被忽略但后果严重的细节：配置文件里的setFinder()方法。它不仅仅决定了要修复哪些文件，更决定了要排除哪些文件。如果漏掉了->exclude('vendor')或->notName('*.blade.php')这样的排除规则，一次composer format操作可能会“顺手”修复你依赖包里的文件，而Git会诚实地将这些改动提交上去，这无疑是灾难性的。
