PHP赋值运算符语义严格区分：=是覆盖赋值，.=是字符串追加（强制转字符串），+=对数字是加法、对数组是键合并；混用易致类型突变、逻辑错误及隐式转换风险。
PHP 赋值运算符不是“选一个用”，而是按语义和副作用严格区分的；写错一个符号，可能让变量类型突变、字符串意外拼接，或者整数被当成字符串累加。
为什么 = 和 .= 混用会出 bug
PHP 的 = 是纯覆盖赋值，.= 是字符串追加（即使左边是数字也会强制转成字符串）。常见错误是想累加数字却写了 .=，结果得到 "523" 而不是 28。
- 场景：循环中拼接日志或构建 SQL 片段时，误把
$sql .= "WHERE ..."写成$sql = "WHERE ..."→ 丢掉前面所有内容 - 场景：计数器本该用
$count += 1，却写成$count .= 1→$count变成字符串，后续数学运算失效 - 注意：
.=对null值会触发 notice，$s .= null等价于$s = $s . ""，但 PHP 8.1+ 会报Warning: String conversion of NULL to string
+= 和 -= 在数组和数字中的行为差异
+= 对数组是“合并并跳过已存在键”，对数字才是“加法赋值”。这点极易误解 —— 它不是统一的“加”，而是重载操作符。
- 数字场景：
$a = 10; $a += 3;→$a变成13，等价于$a = $a + 3 - 数组场景：
$a = ['x' => 1]; $b = ['x' => 99, 'y' => 2]; $a += $b;→$a仍是['x' => 1, 'y' => 2]，'x'没被覆盖 - 陷阱：
$a += $b不等于$a = array_merge($a, $b)，后者会重排数字键，+=保留左侧键优先级
复合赋值运算符的隐式类型转换风险
PHP 不做运算符级别的类型检查，+=、-=、.= 都会尝试“合理”转换，但这个“合理”常不符合直觉。
立即学习“PHP免费学习笔记（深入）”；
-
$n = "5"; $n += "3";→$n是整数8（字符串被当作数字解析） -
$n = "5abc"; $n += "3";→$n是8（"5abc"转为5，因开头是数字） -
$n = "abc5"; $n += "3";→$n是3（"abc5"转为0，无数字前缀） -
.=总是触发字符串转换：$x = 123; $x .= true;→$x变成字符串"1231"（true转"1"）
什么时候该避免复合赋值，改用显式表达式
当可读性或类型安全比代码短更重要时，硬写 $a = $a + $b 比 $a += $b 更稳妥 —— 尤其在函数返回值、类型混合、或静态分析工具（如 PHPStan）报错时。
- 函数调用后赋值：
$data = getData(); $data += $more;不如拆成两行，方便调试和断点 - 跨类型操作：
$total += $item['price'] ?? 0;中，如果$item['price']可能是字符串"19.99"或null，显式(float)转换更可控 - 性能无差别：PHP 内部对
+=和$a = $a + $b编译后几乎一致，别为“效率”牺牲清晰度
最麻烦的不是记不住哪个符号做什么，而是某次重构时，把 .= 改成 += 后，测试没覆盖到字符串路径，上线就拼出一串无法解析的 ID 列表 —— 这类问题往往只在特定数据组合下暴露，且难以复现。
