declare(strict_types=1) 是文件级开关，仅严格校验当前文件函数调用的参数与返回值类型，禁止隐式转换；不影响变量赋值、表达式运算、跨文件引入及类属性，且必须置于文件首行（PHP标签后无空行、BOM或注释）。
PHP 的 declare(strict_types=1) 不是“版本兼容性问题”，而是**文件级行为开关**——它从 PHP 7.0 起就已稳定支持，所有 7.0+ 版本（包括当前主流的 8.1、8.2、8.3）都完全兼容。所谓“兼容性排查”，实际是排查开发者是否误用了它的作用范围、生效条件和类型边界。
strict_types 声明位置必须绝对干净
该语句必须是 PHP 文件中第一个可执行语句，且前面不能有任何干扰内容：
- ✅ 正确写法：
<?php declare(strict_types=1);（<?php后直接跟 declare，中间无空格、空行、BOM、注释或 namespace） - ❌ 常见失效场景：开头有 UTF-8 BOM 字节（IDE 保存时默认勾选“带 BOM”）、首行写了
namespace或use、<?php后加了空格或换行、用 IDE 自动生成的文件模板带了注释头 - ⚠️ 提示：BOM 无法肉眼识别，可用 VS Code 右下角编码栏切换为“UTF-8 无 BOM”并重新保存；也可用命令行
xxd -l 10 yourfile.php查看前几个字节是否含ef bb bf
它只管函数调用，不管变量赋值或表达式
strict_types 不改变 PHP 的动态本质，仅在函数入参和返回值处插入类型校验：
- ✅ 它会拦截：
add("5", 3)（字符串传给 int 参数）→ 抛出TypeError - ✅ 它会拦截：
function foo(): int { return 3.14; }→ 返回 float 却声明 int → 报错 - ❌ 它不管：
$x = "123"; $y = $x + 45;（变量赋值和算术运算仍按弱类型规则运行） - ❌ 它不管：
if ("1" == true) { ... }（比较运算符、类型转换操作符完全不受影响）
第三方库与你自己的 strict 文件互不干涉
你在控制器里写了 declare(strict_types=1)，不代表调用的 Laravel 或 Symfony 方法也会变严格：
立即学习“PHP免费学习笔记（深入）”；
- Laravel 的
cache()->get($key, 'default')默认参数是 string，但源码没开 strict，所以你传"1"给期望 int 的地方，它照样隐式转成 1，不会报错 - 你自己的函数开启 strict 后，若内部调用了一个没开 strict 的第三方函数，那个函数仍按松散模式处理参数
- 结论：strict 是“单文件契约”，不是“项目级开关”，不要指望它能约束外部代码行为
标量类型之外，对象/数组/联合类型另有规则
strict_types 对以下类型声明**不额外增强校验逻辑**：
- 类名、接口、
array、callable等复合类型：无论 strict 是否开启，都要求精确匹配（PHP 7.0+ 已统一） - PHP 8.0+ 的联合类型（如
int|string）：strict 模式下仍允许任一匹配，不强制“完全一致”，但禁止隐式转换进联合中的某个分支（例如"123"仍不能当int用，但可当string） -
mixed和void：strict 模式下无特殊影响
不复杂但容易忽略：strict_types 是个精准、安静、只做一件事的机制——守住函数边界的类型契约。把它当成全局类型系统，或者以为开了就能杜绝所有类型隐患，反而更容易踩坑。
