strict_types=1仅对当前文件函数调用生效，不穿透include/require，不控制返回值、变量赋值及第三方库；它只强化该文件内函数参数的显式类型匹配，是局部契约而非全局保险。
strict_types 不是“建议开启”，而是你明确需要类型安全时必须手动加的开关；不加，PHP 就永远按弱类型规则隐式转换——哪怕你写了 int 参数声明。
strict_types=1 只对当前文件的函数调用生效
它不穿透 require、include、use 或类方法内部调用的其他文件。你在 A.php 里写了 declare(strict_types=1);，然后 require 'B.php';，B.php 里定义的函数被调用时，依然走弱类型逻辑。
- 常见错误现象：A.php 开了 strict，调用 B.php 的
function calc(int $n) { return $n * 2; }，传入"5"却没报错——因为 B.php 自己没声明strict_types=1 - 真实使用场景：新模块从头写，或重构旧文件时逐个补上，别指望“加一次全项目生效”
- IDE 和静态分析工具（如 PHPStan）不会因你某处加了 strict 就自动推断其他文件也该严格；它们各自按文件解析
strict_types 控制什么、不控制什么
它只强化「函数参数」的类型匹配，且仅限支持的类型： int、float、string、bool、array、callable、类名、self、parent。其他一概不管。
- 不控制返回值：写
function foo(): int { return "123"; }，即使开了 strict，也不会报错（PHP 仍会尝试转成 int） - 不控制变量赋值：
$x: int = "42";是合法的（PHP 不支持变量级类型声明，这行语法本身就不对） - 不约束
iterable、mixed、object、resource等伪类型或宽泛类型 - 字符串数字如
"123"传给int参数，在 strict 下直接抛TypeError；不开则静默转为123
第三方库基本不受你的 strict_types 影响
你自己的文件开了 strict，调用 Laravel 的 collect()、Doctrine 的 find() 或 Guzzle 的 request()，它们内部是否严格，完全取决于那些库自己有没有在对应文件顶部写 declare(strict_types=1);。
- 主流框架/库大多没开：Laravel、Symfony、Monolog 默认仍是弱类型兼容策略，为的是向后兼容老项目
- 这意味着你传
"1"给一个期望int的第三方方法参数，大概率被转成1而不是报错——你的 strict 对它无效 - 你只能靠文档、类型提示、或运行时打日志确认实际接收值，不能依赖 strict 拦截
最容易被忽略的一点：strict_types 是“局部契约”，不是“全局保险”。它只在你亲手写的函数签名和调用点之间建一道墙，墙外的代码、数据来源（HTTP 请求、数据库、缓存）、第三方依赖，全都不受这堵墙保护。真要提升质量，得配合参数验证、DTO、静态分析、以及团队对每个文件是否声明 strict 的明确约定。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
