PHP的类型误用，根源往往出在对标量和复合类型这两大阵营的理解偏差上。简单来说，就是你把一个不能装多个值的东西硬塞了多个值，或者把一个复杂的结构体当成简单的开关来用。这才是绝大多数bug的温床。
类型系统的边界，不在语法层面，而在你对数据含义的理解是否稳定。
boolean 和 integer 混用导致逻辑错乱
PHP因为历史原因，隐式转换做得特别多——true变成1，false变成0。听起来很方便，但反过来用整数做条件判断时，边界情况很容易漏网。比如if ($status == 1)和if ($status === true)，这俩在逻辑上完全不是一回事。
- 数据库查出来的status字段是tinyint(1)，值是
0或1。别偷懒直接当成boolean用；要么显式转成(bool) $status，要么就坚决写$status === 1。 empty()这个函数特别“友好”，它对0、"0"、0.0都返回true。但问题是，这些值在语义上并不是false。如果你真想判断“这个值是否为真”，优先用!!$var或者严格比较，别依赖empty()。- 举个经典场景：
strpos()返回0表示找到字符串开头，但这个0在弱类型比较里会被当成false。所以检查返回值一定得用!== false，这是老生常谈但也是最容易忘的。
string 和 float 的精度陷阱
字符串拼接时遇到浮点数，PHP会默默地帮你做截断或四舍五入。这在普通展示页面问题不大，但一涉及金融计算，就是灾难的起点。
- 别写出
"$price + 0.1"这种字符串插值来做数值运算。先转成(float)再算，或者干脆全用整数运算。 - 底层原理是：PHP的
float遵循IEEE 754双精度标准，所以0.1 + 0.2 !== 0.3。这不是PHP的bug，是所有语言的共同问题。处理金额，要么用int存分（比如1000表示10.00元），要么用bcadd()这类高精度数学函数。 json_encode()有个默认行为：大整数会被转成科学计数法字符串。如果你希望保持精度，记得加上JSON_BIGINT_AS_STRING选项。
array 和 object 的选择取决于数据契约
数组适合做无结构、临时聚合的数据容器；对象适合有明确行为约束的实体。选错了，后期维护的痛苦会成倍增加。
- 从数据库查出来的关联结果，如果字段是固定的（比如
id、name、created_at），优先考虑用stdClass或者定义一个具体的类，而不是直接扔一个裸array。这样做的好处是：IDE可以给你补全提示，静态分析工具也能帮你查出错误。 foreach ($data as $k => $v)遍历array没问题，但遍历object时，如果属性是private或protected，你就访问不到了。这时候得用get_object_vars()或者反射来搞定。is_array()无法识别ArrayObject这类实现了数组接口的对象。如果你需要兼容所有可遍历的结构，改用is_iterable()——这个函数是PHP 7.1引入的，专门干这个事。
null 和 empty 的语义混淆
null是一个类型，empty()是一个判断逻辑。两者既不等价，也不覆盖全部场景。把这两个概念混在一起，是产生隐藏bug的常见原因。
$var === null表示变量被显式地设为了空；而empty($var)对""、0、0.0、[]、false都返回true。它们的交集远比你想象的小。- 函数参数默认值设为
null，语义上表示“未传参”，而不是“空字符串”或“零”。如果需要检查用户是否传入了某个参数，用func_get_args()或者PHP 8的命名参数会更清晰。 isset()对null返回false，但它对未定义的变量也返回false。所以，如果你想确认“变量已定义且不为null”，对于数组要用array_key_exists()，对于对象属性要用属性存在性检测（比如property_exists()）。
说到底，类型安全不是靠运行时的各种检查堆出来的，而是在设计阶段就应该建立的约束意识。一旦你开始往array里塞不同结构的子项，或者给object的属性赋任意类型的值，你实际上已经亲手交出了类型系统的控制权。理解数据的真实含义，远比记住语法规则更重要。