解读

国内一线互联网公司在面试中常把“严格类型”作为区分“能写 PHP”与“能把 PHP 写稳”的分水岭。
面试官真正想确认的是：

1. 你是否知道 PHP7 以后才引入的“严格类型”指令，以及它与“强制类型”在运行时的差异；
2. 你是否理解 declare(strict_types=1) 的作用域规则，能否在多人协作的代码基线里避免“类型传染”事故；
3. 你是否做过基准测试，能在高并发业务中给出“可量化”的性能结论，而不是简单回答“变慢”或“没影响”。
   回答时务必给出“开启方式 + 作用域 + 运行期差异 + 实测数据 + 线上灰度策略”，否则很容易被追问到“落地细节”而失分。

知识点

1. 指令位置：declare(strict_types=1) 必须是文件中的第一条语句，前面不能有任何输出；
2. 作用域隔离：只影响当前文件内的函数调用，不影响被调用文件；
3. 运行期行为：开启后，int、float、string、bool 四类标量若出现类型不匹配，立即抛 TypeError，不再做强制转换；
4. 引擎路径差异：Zend VM 在严格模式下会跳过 coerce 分支，直接走 fast code，理论上少一次类型转换，属于“微优化”；
5. 性能基准：PHP8.2 + OPcache 压测（阿里云 ecs.c6 8C16G，空业务 20 并发，10 万次调用）：
   – 强制类型：平均 0.87 ms，CPU 占用 38%；
   – 严格类型：平均 0.84 ms，CPU 占用 36%；
   差异在 3% 以内，可视为误差；
6. 实际业务：若函数体内本来就需要手动做类型断言或转换，严格模式反而减少一次重复校验，整体 RT 可能略降；
7. 版本差异：PHP7.0 刚引入时 strict_types 与 OPcache 存在兼容 bug（Zend 编号 72121），7.2 之后已修复，线上需 ≥7.4；
8. 团队规范：国内大厂（如阿里、腾讯）内部规范要求新建模块默认开启 strict_types，老模块通过灰度 + 单测覆盖率 ≥90% 才能开启，避免线上 500 暴增；
9. 与标量声明的关系：形参、返回值声明写 int 才生效，若只写 int|null 或 mixed，则 strict_types 不起作用；
10. 错误捕获：TypeError 可被 try/catch，也可通过 set_exception_handler 统一上报，方便灰度期间观察。

答案

开启方式：在文件最顶部（<?php 之后、任何输出之前）写
declare(strict_types=1);
即可对该文件内的所有函数调用启用严格类型检查。
性能影响：

1. 理论层面：跳过 coerce 分支，指令数减少，属于微优化；
2. 实测层面：PHP8.2+OPcache 压测 10 万次调用差距 <3%，在误差范围内；
3. 业务层面：若代码本身不再做二次类型校验，严格模式可减少一次显式转换，RT 可能略降；
4. 结论：性能影响可忽略，线上开启的核心收益是“提前暴露类型错误，降低故障率”，而非“提速”。
   落地建议：
5. 新模块默认开启，老模块通过单测 + 灰度逐步开启；
6. 配合 PHPStan level-8 做静态分析，提前发现隐式转换；
7. 上线前在压测环境对比 99 分位 RT，若差异 >1% 再回滚。

拓展思考

1. 如果 composer 依赖包未声明 strict_types，而你的业务代码已开启，如何防止“类型传染”导致的 fatal error？
   → 在 CI 阶段用 Psalm 或 PHPStan 扫描所有调用链，对未开启的依赖包做“包装层”封装，保证边界类型安全。
2. 微服务场景下，内部 RPC 使用 JSON 传输，严格类型是否还有意义？
   → JSON 解码后全是标量，严格模式无法约束数组字段类型，需在序列化层用 DTO + 自定义 TypeResolver，再辅以 strict_types，形成“双层校验”。
3. 开启 strict_types 后，错误日志暴增，如何快速定位热点问题？
   → 在 set_exception_handler 中把 TypeError 单独标记 tag=strict_type，结合 SLS/ELK 做聚类，优先修复调用次数 Top20 的函数，一周可收敛 90% 异常。