如何通过Composer快速生成符合PSR-12标准的类库？（标准化）

composer 不生成代码也不校验 psr-12，仅负责装包；psr-12 兼容需组合 php-cs-fixer 等工具链，模板项目多滞后于 2019 年定稿的标准，须手动配置规则并警惕格式化引发的测试失效。

Composer 本身不生成代码，也不校验 PSR-12；它只管装包。想快速产出合规类库，得靠组合工具链，不是靠 composer create-project 按个按钮就完事。

用 composer create-project 初始化骨架时，为什么默认不 PSR-12？

因为 Composer 的模板项目（比如 php-library-skeleton）大多停留在 PSR-2 或干脆没约束。PSR-12 是 2019 年才定稿的，很多老模板没更新，而且“标准”这事没法靠 composer.json 自动注入到源码里。

常见错误现象：composer create-project vendor/skeleton 后跑 phpcs 直接报十几处 PSR12.Classes.ClassDeclaration 错误——类花括号换行、public 前空格、方法间空行数都不对。

• 别指望模板自带 PSR-12 兼容，先查它的 phpcs.xml 或 .php-cs-fixer.dist.php 是否存在且启用 psr12 规则集
• 优先选明确声明支持 PSR-12 的骨架，比如 php-mock/php-mock-phpunit-skeleton（带预置 php-cs-fixer 配置）
• 如果骨架没配好，立刻删掉 src/ 下自动生成的类，手写或用 ide 生成——现代 phpstorm 新建类时可设“PSR-12 模板”，比依赖模板更可靠

本地强制 PSR-12 的最小可行配置：php-cs-fixer + composer script

不用装全局工具，也不用改 IDE 设置，靠 composer.json 绑定就能让所有人（包括 CI）统一格式。

使用场景：新项目初始化后第一件事就是加格式化守门员，避免队友提交不一致代码。

• 运行 composer require --dev friendsofphp/php-cs-fixer
• 在 composer.json 的 "scripts" 里加："fix": "php-cs-fixer fix --rules=@PSR12 --using-cache=false"
• 加 --using-cache=false 是为了防止 CI 环境因缓存路径问题跳过修复（尤其 docker 容器里）
• 执行 composer fix 后会直接重写 src/ 和 tests/ 下所有 PHP 文件，注意提前 commit 当前修改

phpcs 报 PSR12.Methods.MethodDeclaration 但 php-cs-fixer 不修？

因为两个工具规则粒度不同：php-cs-fixer 默认启用的 @PSR12 规则集其实略保守，比如它不强制函数参数每行一个（PSR-12 允许单行多参数），而 phpcs 的 Squiz.WhiteSpace.FunctionSpacing 类规则更细。

性能影响：同时装 phpcs 和 php-cs-fixer 会多占 20MB 依赖，但开发机上几乎无感；CI 中建议只保留 php-cs-fixer --dry-run 做检查，省去 phpcs 解析开销。

• 若要严格对齐 phpcs 的 PSR-12 判定，改用 php-cs-fixer 的完整规则数组：--rules='{"psr12":true,"method_argument_space":{"keep_multiple_spaces_after_comma":false}}
• 别把 phpcs 当修复工具用——它只报错，不改代码；phpcbf 才是它的自动修复兄弟，但兼容性不如 php-cs-fixer
• 检查是否误启了 Squiz 标准：PSR-12 是独立标准，phpcs -i 输出里看到 Squiz 就说明配置混用了，得清掉 phpcs.xml 里的非 PSR 规则

真正卡住人的地方不是工具不会装，而是第一次跑 composer fix 后发现 composer test 失败了——因为 PSR-12 调整了 use 语句顺序、移除了多余空行，导致某些测试里用 ReflectionClass 读取 docblock 的逻辑崩了。这种边界情况，得手动看 diff，不能无脑信任格式化结果。