PHP字符串拼接误用+导致0结果、==松散比较引发类型转换错误、浮点数直接比较不等、三元运算符优先级陷阱；应改用.拼接、===严格比较、bccomp浮点比较、三元加括号。
字符串拼接误用 + 而不是 .
PHP里+只做数值加法，.才是字符串拼接。用+连字符串不会报错，但结果是0或意外数字。
- 现象：
$a = "hello" + "world"得到0，而不是拼接 - 原因：PHP把两个字符串强制转成整数，
"hello"→0，"world"→0，所以0 + 0 == 0 - 真实场景：模板拼接、SQL构造、日志组装中手滑写错，调试时发现变量“消失”了
- 建议：IDE里开PHPStan或Psalm，能直接标出
+用于字符串的类型不匹配
== 和 === 混用导致逻辑翻车
松散比较==会静默转换类型，'1'、1、true全被当成相等；严格比较===才真正可靠。
- 现象：
var_dump('abc' == 0)输出bool(true)（因为'abc'转整数是0） - 典型踩坑点：用户状态判断
if ($status == 1)，但数据库返回的是字符串"1"或"active"，结果总进错分支 - 兼容性影响：PHP 8.0+ 对某些隐式转换已触发
E_WARNING，但旧版本完全沉默 - 建议：所有涉及配置值、API响应、数据库字段的比较，无条件用
===；必要时先filter_var($input, FILTER_VALIDATE_INT)校验类型
浮点数直接用 == 或 != 比较
二进制无法精确表示十进制小数，0.1 + 0.2 !== 0.3 是通用问题，PHP也不例外。
- 现象：
var_dump(0.1 + 0.2 == 0.3)返回false，但肉眼看起来“明明一样” - 财务/计费类代码最危险：比如余额扣减后判断是否为
0.00，可能永远进不了清零逻辑 - 不要用
round()临时修复——它只是掩盖误差，不是消除误差 - 正确做法：用
bccomp($a, $b, 2) === 0（2表示保留两位小数比较），或统一转为整数分单位运算（如金额存“分”）
三元运算符嵌套不加括号，优先级反直觉
?: 的优先级比&&和||还低，没括号时整个表达式会被错误切分。
立即学习“PHP免费学习笔记（深入）”；
- 现象：
$x = true ? 'a' : false ? 'b' : 'c'实际执行的是true ? 'a' : (false ? 'b' : 'c')，结果恒为'a'，而非预期的嵌套判断 - 更隐蔽的坑：
$user->role == 'admin' ? $user->salary * 1.2 : $user->salary || $user->is_temp—— 后半段||会脱离三元作用域 - 调试困难：语法合法、无警告、结果错得毫无征兆
- 建议：只要三元表达式里出现任何其他运算符（包括
==、??、??），就给整个三元部分加括号：($cond ? $a : $b)
实际项目里，这几个坑往往叠加出现：比如用==判断一个从$_GET拿到的字符串型数字，再拿结果参与浮点计算，最后用+拼进日志——一行代码，三重失效。越短的表达式，越要盯紧运算符行为。
