strict_types=1 本身无问题，它仅暴露原有类型不匹配错误；仅作用于当前文件且必须置于首行，常见错误是未放在第一行（如前有注释或空行）。
开启 declare(strict_types=1); 后报错变多，不是 strict_types 有问题，而是它把原本被 PHP 隐式转换掩盖的类型不匹配问题暴露出来了——这些错误本就存在，只是以前没报。
strict_types 只作用于当前文件，且必须放在第一行
常见错误是把它写在注释、空行或 <?php 标签之后。只要位置不对，声明就无效，导致你以为开了却实际没生效，调试时一头雾水。
-
declare(strict_types=1);必须是文件中第一个非空白、非注释的语句（允许前导空白和 BOM） - 不能放在命名空间声明、use 语句、类定义或任何其他 PHP 代码之后
- 如果文件以
<?php开头，declare必须紧随其后（中间不能有空行或注释） - 子文件、被
include或require的文件需各自声明，不会继承
参数类型不匹配：字符串数字、浮点数传给 int 是高频雷区
比如调用 add(int $a, int $b) 时传入 "123" 或 3.14，松散模式下自动转成 123 和 3，严格模式直接抛 TypeError。
- 检查所有外部输入源：GET/POST 参数、JSON 解析结果、数据库读取值——它们几乎全是
string类型 - 不要依赖函数内做
(int)$x转换后再校验，而应在调用前显式转换，或改用更宽松的类型（如float）再内部处理 - 对可选参数或默认值也要检查类型，
function foo(int $x = 0)没问题，但function foo(int $x = "0")会报错
返回值类型声明和实际返回不一致也会触发错误
哪怕参数全对了，function countItems(array $list): int { return $list; } 这种写法在 strict_types 下照样失败——返回的是 array，不是 int。
- 注意函数内部可能提前
return出非预期类型，尤其是带条件分支或异常处理的逻辑 - 慎用
??或三元运算符返回不同类型的值，例如return $value ?? "default";在声明返回int时必然出错 - 使用 IDE 或静态分析工具（如 PHPStan）提前扫描返回路径，比运行时报错更早发现问题
最常被忽略的一点：strict_types 不影响变量赋值或运算过程中的类型转换，只约束函数调用时的参数传递和函数返回值。也就是说，你依然可以写 $x = "5" + 2;，但不能把 "5" 直接传给期待 int 的函数。这个边界模糊点，让很多人误以为“开了 strict_types 就该处处强类型”，其实它管得非常具体——仅限函数边界。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
