php 8.0 收紧 == 的字符串与数字比较逻辑：非法数字字符串（如"123a"、"0eabc"）不再转数字，直接返回false；switch中非严格数字字符串不匹配数字case；所有变更均静默生效，无警告。
PHP 8.0 对 == 的字符串与数字比较逻辑做了实质性收紧，不是“更智能”，而是“更严格”——很多原来返回 true 的松散比对，现在直接变 false，且不报错、不警告，静默失效。
为什么 '123a' == 123 在 PHP 8.0 返回 false
PHP 7.x 会尝试从字符串开头提取尽可能长的数字部分（"123a" → 123），再与数字比较；PHP 8.0 改为：只要字符串包含非数字字符（除前导空格、+/-、小数点、e/E 外），且该字符串**不构成合法数字字面量**，就拒绝转换，直接按字符串与数字规则走“类型不兼容路径”，结果为 false。
常见失效场景：
-
"123abc" == 123仍为true（因为"123abc"被当作123解析） -
"123a" == 123变为false（"123a"不是合法数字字面量，不再尝试截取） -
"08" == 8在 PHP 7.x 是true，但在 PHP 8.0 仍是true（"08"被转成整数8）；但注意："08"==08（八进制字面量）在 PHP 8.0 是false，因为08本身已非法，解析失败后当作0，而"08"转为8，8 == 0为false）
科学计数法和 '0e...' 字符串不再自动相等
PHP 7.x 中，"0e123456" == "0e789012" 为 true，因为两者都被解释为浮点数 0.0；PHP 8.0 保留该行为，但增加了前提：两个操作数都必须是**合法的数字字符串**。一旦其中一个是无效格式（如 "0eabc"），它就不会被当作数字处理，比较退回到字符串逐字节比对，结果必为 false。
这意味着你不能再依赖 == 来“模糊匹配”形如 md5 或 sha1 输出中碰巧含 0e 的字符串，尤其当输入可控时（例如 CTF 或参数校验）。
-
"0e123" == 0→true（仍成立） -
"0eabc" == 0→false（PHP 8.0 新行为） -
in_array("0e123", [0, 1, 2], false)→true（仍成立） -
in_array("0eabc", [0, 1, 2], false)→false（PHP 8.0 新行为）
switch 语句里字符串 case 不再隐式转数字
PHP 7.x 允许 switch ($str) { case 123: ... }，若 $str 是 "123" 或 "123abc"，都会命中；PHP 8.0 中，只有当 $str 是严格数字字符串（如 "123"、"-45.6"、"1e3"）时才会转为数字匹配，否则一律按字符串比对。
后果很直接：旧代码里靠 switch 分支处理用户传入 ID 字符串（如 "123edit"）的逻辑，升级后可能完全跳过所有 case，掉进 default 或无响应。
- 确保
switch的条件变量是明确类型：用(int)$str或is_numeric($str) && ctype_digit($str)做预处理 - 避免在
case中混用数字和字符串值：写成case "123":而非case 123:，除非你确定输入一定是纯数字字符串 - 检查所有涉及
$_GET['action']、$_POST['type']等动态字符串进入switch的地方
最危险的坑：没报错、没日志、逻辑悄悄错
这些变化都不触发 Warning 或 Error，error_reporting 再高也看不到——它们只是让 == 返回不同布尔值。权限判断、状态流转、路由分发这类依赖松散比较的业务代码，最容易出问题。
- 用
===替代==是最彻底的解法，但需确认两边类型一致（比如先is_string()/is_int()） - 对用户输入做显式清洗：用
filter_var($input, FILTER_VALIDATE_INT)或正则/^\d+$/判断是否为纯数字字符串，再决定怎么比 - 别依赖
@抑制——它对这种逻辑变更完全无效 - 升级后务必跑一遍真实业务路径，尤其是带 ID、状态码、类型标识的请求，不能只看单元测试是否通过
真正麻烦的从来不是报错的代码，而是看起来还跑得通、但已经漏放行或误拦截的那几行 if ($id == $allowed_id)。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
