启用 strict_types 后性能是否有变化？

strict_types 是编译期类型校验，不引入运行时开销，对 TPS 无显著影响。收益体现在减少隐式转换 CPU 周期 + 提前暴露 bug 降低回滚成本。

PHPStan level 应该设到几再开 strict_types？

建议至少 level 5，核心模块推到 level 7–8。level 每升一级都会暴露一批"原先靠 coercive 掩盖的调用"，修完再开 declare 可避免级联报错。

第三方库不支持 strict_types 怎么办？

不在 vendor 内改代码。两种做法：① 在调用第三方库的边界文件不加 declare，让 coercive 兜底；② 写 Adapter 类包裹第三方调用，Adapter 内部做类型收窄后对外暴露严格契约。

PHP8.5 弃用的 (integer)/(double) 别名，现在就要修吗？

建议在 PHP8.2–8.4 迁移阶段一并扫掉。用正则全局替换 (integer)→(int)、(double)→(float)、(boolean)→(bool)、(binary)→(string)，属无风险改动，可避免 8.5 升级时批量 deprecation 噪声。

declare(strict_types=1) 能否通过 php.ini 全局强制，不再逐文件写？

PHP8.4+ 实验性提供 zend.enable_strict_types=1，但仅对新解析文件生效，且 Opcache 配置需联动。生产环境主流做法仍是文件级 declare——更可控，且能被静态分析工具精确识别。

PHP8强类型模式实战：从弱类型到严格模式的迁移

PHP自7.0引入标量类型声明以来，类型系统逐步收紧，至PHP8系列已形成以declare(strict_types=1)为核心的严格模式能力，叠加联合类型、mixed、enum、readonly等特性，使PHP从”弱类型脚本语言”向”可静态验证的工程语言”靠拢。大量2010—2017年间建设的遗留项目仍运行在无类型声明或弱类型 coercively 模式下，”字符串'2.5' + 1 = 3.5自动转float、函数返回类型缺失、第三方库类型契约不一致”等问题在生产环境长期潜伏。下文以PHP8.2—8.4为基准（兼顾8.5已废弃的非规范标量别名），梳理从弱类型到严格模式的迁移路径。

一、弱类型模式的历史行为与风险

PHP默认处于 coercive 模式（强制类型转换）：当函数参数声明为int却传入float或可被解析为数字的string时，引擎会尝试隐式转换而非抛错。例如：

function sum(int $a, int $b): int { return $a + $b; }
echo sum(1.5, 2.5);   // 弱类型模式下输出 3（1.5→1, 2.5→2）

这种行为在快速原型阶段降低门槛，但在企业级系统中带来三类隐患：

数据精度静默丢失：金额、库存等场景的float→int截断无告警
返回类型缺失导致调用链失控：下游依赖上游返回的”实际类型”而非”约定类型”
第三方库契约不一致：A库返回string|false，B库按string消费，埋雷于边界

PHP8进一步收紧了部分隐式转换规则（如联合类型下的转换优先级：int → float → string → bool），但未启用strict_types的项目仍走 coercive 老路。

二、strict_types 机制（附行为对照）

declare(strict_types=1);必须置于文件首行、无前置空白或普通代码的位置，否则被忽略。其关键语义常被误读：

📌 严格模式仅作用于”从该文件发起的函数调用”，不作用于”在该文件中定义的函数被外部调用”。若调用方文件未启用 strict_types，即使被调函数定义在 strict 文件内，仍按 coercive 规则走。

弱类型 vs 严格模式行为对照表

下表以sum(int $a, int $b): int为例，对比两种模式对同一组入参的差异：

调用代码	弱类型（默认 coercive）	严格模式（strict_types=1）
`sum(1, 2)`	`int(3)`正常	`int(3)`正常
`sum(1.5, 2.5)`	`int(3)`截断后相加	TypeError：float given
`sum("1", "2.5")`	`int(3)`（”2.5″→2）	TypeError：string given
`sum(1, 2.5)`返回值 `float`	TypeError（返回值也校验）	TypeError

💡 唯一例外：strict 模式下 int 可传入声明为 float 的参数，这是官方保留的宽化路径，其余均严格匹配。

（此处配固定示意图：弱类型 coercive 流程 vs strict_types 调用方校验流程图，标注”校验发生在调用点而非定义点”这一关键差异）

三、PHP8 新增类型特性对迁移的影响

迁移至严格模式并非简单地在文件头加declare，需同步消化 PHP8 类型系统的新增约束：

1. 联合类型（Union Types）

2. mixed 类型

3. 非规范标量别名弃用（PHP8.5+）

(integer)、(double)、(boolean)、(binary)四类别名在8.5起抛 deprecation，参数/返回/属性声明中写function foo(integer $x): double会被解释为”类名为 integer 的类型约束”而非 int/float。迁移期应全局替换为int\|float\|bool\|string。

4. nullable 语法 `?T`与联合 `T\|null`

PHP8 两者等价，但?T更简洁；注意?T不能与T\|null混用（重复声明）。

四、遗留项目渐进迁移

一次性全量开启 strict_types 会导致调用链上层级联报错。工业界采用的路径为 文件级 → 目录级 → 全局级：

第一步：新文件先行

新建的 Service / DTO / Repository 文件首行即加declare(strict_types=1)，并补全参数类型+返回类型。新逻辑不与旧模式纠缠。

第二步：静态分析打底

引入 PHPStan（或 Psalm），从 level 0起步逐步升至 level 5+，优先修复”可能为 null 的变量””未使用的分支””参数类型缺失”等基线问题。静态分析可在不运行代码的前提下暴露 coercive 模式下隐藏的类型风险。

第三步：核心旧文件加类型声明（不加 strict）

先给参数加int\|string\|?Foo等声明但不加declare，让 coercive 模式兜底兼容旧调用方；待 PHPStan 全绿后，再加返回类型。

第四步：核心文件启用 strict_types

在 DAO / Service / Domain 三层核心文件顶部加declare(strict_types=1)，配合测试套件（单元测试+集成测试）跑回归。此时报出的 TypeError 多为”原先被隐式转换掩盖的真问题”，需逐个修数据源而非简单(int)强转。

第五步：入口文件与全局开关

PHP8.4+ 实验性提供zend.enable_strict_types=1（php.ini 级），但仅影响新解析文件，且需配合opcache.revalidate_freq=0。多数项目仍以文件级 declare 为主，ini 开关作为最终态。

⚠️ 第三方库（尤其是未维护的 legacy 包）若不支持严格模式，不要直接修改 vendor。通过其外层加 Adapter，或在 composer 层用 @抑制+手动类型收窄。

五、高频清单

strict_types 不继承：A文件（strict）调用 B文件（非 strict）中定义的函数，B 函数的定义方虽在 strict 文件内，但调用方 A 才是校验主体——这条反过来想：若 A 非 strict、B strict，B 内定义的函数被 A 调用时仍走 coercive。很多团队在此处误判。
内部函数不受 strict_types 影响：array_map/call_user_func等内部函数发起的调用，仍按 coercive 走。
联合类型隐式转换优先级：coercive 模式下，string "1"对 float\|bool转 float，"hello"对 int\|bool\|float转 bool——行为需对照表确认，否则迁移 strict 后会集体 TypeError。
PHP8.1+ enum + readonly 可与 strict_types 组合使用，值域在编译期冻结，适合替换原”魔术常量+整数状态位”的旧模式。