php cs fixer 不自动修复版本兼容性问题，需手动启用如 @php80migration 等规则及 pow_to_exponentiation、array_syntax 等具体规则，并严格限定 finder 范围排除 vendor 等目录，避免静默跳过或崩溃。
PHP CS Fixer 本身不“自动修复版本兼容性问题”，它只按你明确配置的规则去改代码；想让它把 pow($a, 2) 换成 $a ** 2、把 array() 换成 []，必须主动启用对应规则——否则它默认只做 PSR-12 风格整理，完全不管 PHP 版本迁移。
怎么启用 PHP 8+ 语法升级规则
PHP CS Fixer 的版本兼容性修复能力藏在具体规则里，不是靠“选个 PHP 8.2 规则集”就能触发。比如：
-
@PHP80Migration：启用后会把is_countable()替换为is_iterable()（仅当 PHP 8.0+ 环境下安全）、把mb_strpos($s, '', 0, 'UTF-8')简化为mb_strpos($s, '') -
@PHP81Migration：启用后会把array_key_exists($k, $arr)改为isset($arr[$k])（仅当键非 null/数组时） -
@PHP82Migration：启用后会把str_starts_with()替换为str_starts_with()（注意：这是保留原调用，但确保函数存在；实际是启用modernize_str_*_functions类规则）
这些规则集不能单独使用，必须和基础规则合并。正确写法是：
return PhpCsFixer\Config::create()
->setRules([
'@PSR12' => true,
'@PHP81Migration' => true,
'pow_to_exponentiation' => true, // 显式启用：把 pow($a, 2) → $a ** 2
'array_syntax' => ['syntax' => 'short'], // 把 array() → []
])
->setFinder($finder);
为什么开了 @PHP80Migration 却没改任何代码
常见原因有三个，且 PhpStorm 或 CLI 都不会报错，只会静默跳过：
- 目标代码本身不匹配规则触发条件——比如
@PHP80Migration中的no_unused_imports只在有use语句且未使用时才删，空use不处理 - PHP 解释器版本低于规则要求——
@PHP81Migration中部分规则依赖 PHP 8.1+ 的反射能力，若 PhpStorm 后台调用的是 PHP 7.4，规则直接被忽略 - 配置中未声明
setParallelConfig()且文件数超阈值——PHP CS Fixer v4 默认对单文件启用全部规则，但扫描整个src/时若未显式启用并行或设置 finder 范围，部分迁移规则可能因性能策略被跳过
项目级配置文件必须排除 vendor 和测试桩
如果你在 .php-cs-fixer.php 里用了 in(__DIR__) 但没 exclude vendor 或 tests/fixtures，会出现两种后果：
- 修复过程极慢，因为工具会尝试解析所有第三方包的源码（哪怕它们根本不用你的规则）
- 某些迁移规则（如
modernize_types_casting）遇到vendor/symfony/console里的老写法，可能因类型推断失败而崩溃，报Cannot process file: TypeError
正确做法是严格限定范围：
$finder = PhpCsFixer\Finder::create()
->in(__DIR__.'/src')
->in(__DIR__.'/app')
->in(__DIR__.'/config')
->name('*.php')
->notName('*.blade.php') // Laravel 模板跳过
->exclude('vendor')
->exclude('node_modules')
->exclude('tests/fixtures');
CLI 执行时 --dry-run 不等于安全预览
php-cs-fixer fix --dry-run 只检查“是否需要改”，不验证“改了会不会破坏逻辑”。比如：
- 启用
strict_param后，它会强制给所有函数参数加类型声明，但如果原函数被动态调用（call_user_func_array），加了类型后运行时直接 fatal error - 启用
no_superfluous_phpdoc_tags会删掉@param string|null $id，但如果 Doctrine ORM 依赖这个注解生成 schema，删掉就导致 migration 失败
真正安全的做法是：先用 --diff 看改动，再挑关键文件手动验证行为，最后批量跑。别信 --dry-run 的“0 files changed”提示——它只统计格式差异，不校验语义。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
