解读

国内一线/二线公司在面试中问“PSR-12 与 PSR-2 的差异”，并不是想听你背规范条文，而是考察三件事：

1. 你是否真的在项目中用过 Composer + CI 工具（PHP-CS-Fixer、phpcs、GitLab CI、GitHub Actions）做代码风格自动化；
2. 你是否理解“向后兼容”与“渐进迁移”在国内遗留系统中的落地策略；
3. 你是否能把规范差异翻译成“可读性”“可维护性”“团队协作成本”这些老板听得懂的价值。

因此，回答时要“先结论、后场景、再落地”，让面试官瞬间捕捉到你的工程经验。

知识点

1. 发布时间与定位：PSR-2 2012 年发布，PSR-12 2019 年发布，PSR-12 是 PSR-2 的“官方扩展 + 澄清”，不是简单补丁。
2. 语言版本支持：PSR-12 强制要求 PHP 5.6+，并对 7.0 以后的新语法（返回类型声明、标量类型声明、nullables、void、iterable、object 等）给出风格规则。
3. 文件与编码：PSR-2 只规定“必须只包含 UTF-8 无 BOM”，PSR-12 追加“文件末尾必须空一行”，减少 Linux 下 diff 多出的“\ No newline at end of file”警告。
4. use 声明分组：PSR-2 没有分组概念，PSR-12 强制“类、函数、常量”必须分三列 use，且按字典序，解决国内项目 use 几十行时“找不到类”的痛点。
5. 类常量可见性：PSR-2 时代类常量可以省略 visibility，PSR-12 强制必须写 public/private/protected，避免 PHP 7.1 以前默认 public 造成的“历史包袱”。
6. 方法与属性声明顺序：PSR-12 给出“属性→常量→构造→析构→魔术→公有→保护→私有”的刚性顺序，减少 code review 时“来回滚动”。
7. 链式调用断行：PSR-12 明确“每次->必须换行且缩进一次”，而 PSR-2 只笼统说“合理提高可读性”，导致国内老项目一行 300 字符的“面条链”。
8. 运算符与括号空格：PSR-12 把“否定运算符 !、强制转换 (int)”等 12 种场景全部细化，减少团队里“空格党”与“无空格党”的争吵。
9. 闭包与匿名类：PSR-12 对 use ()、fn() 短闭包、匿名类的括号位置、逗号尾部给出精确示例，解决 PHP 7.4 以后 fn 箭头函数风格空白。
10. 迁移策略：国内存量项目 80% 仍用 PSR-2，面试官爱追问“如何灰度迁移”：先通过 php-cs-fixer 的@PSR12 规则集做 --dry-run，再按模块开 feature 分支，配合 code owner 机制，两周内完成增量文件迁移，老文件保持 PSR-2 兼容，避免一次 MR 爆炸。

答案

PSR-12 与 PSR-2 的核心差异可以概括为“语言特性全覆盖 + 风格细节无死角 + 迁移成本可量化”三句话，具体落地差异有十条：

1. 必须 PHP 5.6+，全面覆盖 7.x 与 8.x 的新类型声明；
2. 文件末尾强制空一行，消灭 Git diff 红线；
3. use 声明必须按“类、函数、常量”三列分组并字典序；
4. 类常量必须写 visibility，彻底告别默认 public；
5. 类成员顺序刚性排列，降低 code review 心智负担；
6. 链式调用每次->换行，杜绝超长行；
7. 运算符与强制类型转换共 12 处空格规则全部细化；
8. 闭包、短闭包、匿名类的括号与逗号风格首次官方定稿；
9. 抽象 final 必须放在 visibility 之前，统一团队认知；
10. 提供可自动化迁移路径：php-cs-fixer 的@PSR12 规则集 + --dry-run，配合 GitLab CI 增量检查，两周内完成灰度切换，老文件保持兼容，新业务强制 PSR-12，国内已有携程、美团、SheIn 等团队落地验证。

拓展思考

1. 国内微服务场景下，多仓库代码风格如何统一？ 可在 GitLab Group 级别创建公共模板仓库，内含 .php-cs-fixer.dist.php 与 .phpcs.xml，CI 统一引用；MR 阶段通过 GitLab CI / GitHub Actions 调用 php-cs-fixer --diff --dry-run，不合规直接阻断合并，实现“风格即门禁”。

2. 老项目迁移 PSR-12 后，如何防止“回潮”？ 在 composer.json 的 scripts 段增加 "style-check": "phpcs --standard=PSR12 --report=summary"，配合 pre-commit 钩子；同时在 README 标注“提交前请执行 composer style-fix”，新人 onboarding 成本降低 50%。

3. 面试反向提问：如果团队还有历史 PSR-2 与 Zend 混用代码，贵司如何平衡重构与业务迭代？ 可答：采用“模块 Ownership + 每周 10% 预算”策略，把风格重构任务拆成 1 人日粒度，随需求迭代带掉，既不影响版本节奏，又能持续降低技术债，CTO 与业务方都乐于接受。