php算术运算和比较操作存在复杂隐式类型转换规则：字符串转数字取左端连续数字，null/false为0、true为1；==松散比较会按string→number→boolean→null顺序转换，导致0=="abc"等意外真值；===可避免类型转换但需注意false/0语义差异；应优先使用filter_var等显式转换确保可控性。
PHP 运算符对操作数类型的隐式转换规则
PHP 在执行 +、-、*、/、% 等算术运算时，会自动把非数字类型转成数字再计算——但转换逻辑不统一，且和上下文强相关，不是简单“转成 int 或 float”。
常见错误现象："123abc" + 45 得到 168，而 "abc123" + 45 得到 45；null + 1 是 1，但 false + 1 也是 1，true + 1 却是 2。
- 字符串转数字：从左开始读取连续数字字符，遇到非数字就停（
"3.14px"→3.14，"px3.14"→0） -
null转为0；false转为0；true转为1 - 数组、对象、资源无法参与算术运算，会触发
Warning: A non-numeric value encountered（PHP 7.1+）或静默转成1（旧版） - 浮点精度问题会影响
==判断，但算术运算本身按 IEEE 754 执行，不额外“四舍五入”
什么时候 == 会偷偷做类型转换？
== 是松散比较，它会在比较前按固定顺序尝试转换两边操作数的类型，优先级是：string → number → boolean → null。这个过程容易绕晕人，尤其在判断用户输入或数据库字段时。
常见错误现象：0 == "abc" 返回 true（因为 "abc" 转数字是 0），0 == "" 也是 true，0 == false 同样是 true。
立即学习“PHP免费学习笔记（深入）”；
- 空字符串
""、字符串"0"、整数0、浮点0.0、false、null在==下全等价 -
"1" == true是true，但"1" === true是false（类型不同） - 涉及数据库查询结果时，MySQL 返回的
tinyint(1)常被 PHP 当作int，但若字段允许 NULL，PHP 可能收到null字符串，导致== 0意外为真
=== 和 != 的安全边界在哪
===（全等）和 !==（全不等）跳过类型转换，只比值和类型都一致才返回 true。这是避免隐式转换坑最直接的方式，但要注意它不能解决所有问题。
常见错误现象：用 === 判断 JSON 解码失败（json_decode($str) === null），结果在 $str 是 "null" 字符串时误判为失败；又或者用 === 0 判断 strpos() 结果，却忘了 strpos("abc", "a") 返回 0（合法位置），不是 false。
-
===对null安全，但对false、0、""不天然区分语义（比如“未找到” vs “在开头找到”） -
strpos()、array_search()等函数返回false表示失败，0表示成功但位置为 0，必须用=== false判断失败 - 函数返回类型不确定时（如 PDO::fetch() 可能返回 array 或 false），
=== null无法捕获 false，得用=== false或is_array()显式检查
如何让类型转换更可控、更可读
靠记忆隐式规则不如主动控制类型。PHP 提供了明确的类型转换函数和 cast 操作，它们行为稳定，文档清晰，且 IDE 和静态分析工具（如 PHPStan）能更好识别。
常见错误现象：用 (int) $x 处理浮点字符串 "3.9" 得到 3（截断），而用 intval($x) 默认也是截断，但加 10 进制参数后对 "0xFF" 无效；用 floatval() 处理科学计数法字符串 "1e2" 没问题，但 (float)"1e2px" 会变成 100.0（忽略后缀）。
- 字符串转整数优先用
filter_var($str, FILTER_VALIDATE_INT)，失败返回false，可设options控制范围和进制 - 字符串转浮点用
filter_var($str, FILTER_VALIDATE_FLOAT)，比(float)更严格（拒绝"123abc"） - 需要兼容空值或默认值时，别写
$x ? (int)$x : 0，改用($x !== null && $x !== "") ? (int)$x : 0或coalesce((int)$x, 0)（需自定义函数） - 处理用户输入或 API 参数时，尽早 cast 并验证，不要留到运算时才暴露类型问题
