解读

国内一线互联网公司的 PHP 面试通常把“类型声明”作为区分初中高级的重要分水岭。面试官想确认三点：

1. 你是否理解 PHP7 以后“严格类型”模式对性能与可维护性的影响；
2. 你是否能在团队级代码里落地统一、可回滚的类型策略；
3. 你是否知道在 Composer、Laravel/Symfony、Swoole 等主流技术栈里，类型声明如何与单元测试、静态分析、CI 集成。
   回答时切忌只背“int、string、bool”，而要给出“可落地的规范 + 可量化的收益 + 可回滚的兼容方案”。

知识点

1. 严格类型开关：declare(strict_types=1) 的文件级作用域与调用链穿透规则。
2. 标量与复合类型：int、float、string、bool、array、object、callable、iterable、void、mixed、null、false、true、union types、intersection types、DNF types（PHP8.2）。
3. 可空语法：?Type 与 Type|null 的语义等价但风格差异。
4. 属性类型（PHP7.4）与构造函数属性提升（PHP8.0）对类型完整性的补齐。
5. 逆变与协变：继承链里参数逆变、返回值协变的 Liskov 原则。
6. 静态分析工具：phpstan、psalm、vimeo/psalm 在 level 6+ 时对未声明类型的“零容忍”。
7. 性能：开启 opcache.enable_cli=1 + declare(strict_types=1) 后，JIT（PHP8）可省掉一次运行时类型检查，QPS 提升 3%–7%。
8. 版本策略：PHP7.4 EOL 后，国内头部项目已强制要求 PHP8.0+，因此 mixed 与 union types 不再被视为“激进”。
9. 兼容层：#[\ReturnTypeWillChange] 用于在升级 8.x 时保留旧签名，避免社内组件爆炸。
10. 异常处理：TypeError、ValueError 的捕获与日志规范，阿里 SLS 与腾讯 CLS 均要求把“期望类型/实际类型”打到同一字段方便检索。

答案

“在团队级项目里，我们分三层推进类型声明。
第一，基线层：所有新文件默认 declare(strict_types=1)；老文件通过 php-cs-fixer 的 @rules 逐步灰度，每周 Review 增量。
第二，声明层：

• 公共 API（Service、Repository、SDK）必须写全参数与返回类型，禁止使用 mixed；
• 内部私有方法允许 mixed，但需在 phpstan level 7 下通过 @phpstan-assert 缩小类型；
• 对可能返回 false 的内置函数（如 strpos）统一用 false|int 并在调用侧用 === 严格比较，杜绝历史坑。
  第三，验证层：
• CI 流水线里 phpstan + psalm 双跑，level 分别设为 max 与 3，任一报错即阻断合并；
• 单元测试用 PHPUnit 的 @dataProvider 把边界类型全部覆盖，mutation testing 的 MSI 指标≥80%；
• 上线前做 7% 的灰度，开启 opcache.validate_timestamps=0，通过实时监控 QPS、TP99 验证无性能回退。
  落地三个月后，我们核心支付接口的 Fatal Error 下降 42%，日均报警量从 180 条降到 12 条，回滚次数为零。”

拓展思考

1. 如果公司仍有 20% 代码在 PHP5.6，如何设计“类型注解 + 桥接层”让老业务无缝迁移到 PHP8？
2. 在 Swoole 协程环境下，declare(strict_types=1) 与 OpenSwoole 的 Coroutine\run() 冲突吗？如何证明？
3. 当 union types 遇上 Doctrine ORM 的 Proxy 对象，psalm 会误报“LessSpecificReturnStatement”，你会写哪种 plugin 解决？
4. 如果业务方坚持“动态类型灵活”，你如何用量化的故障率、回归成本、Code Review 耗时三份数据说服管理层全面推行严格类型？