PHP数据类型如何正确使用标量与复合类型

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的属性赋任意类型的值，你实际上已经亲手交出了类型系统的控制权。理解数据的真实含义，远比记住语法规则更重要。