count() 是 php 唯一推荐的数组长度统计函数，支持所有数组类型及 null，但对非数组变量触发警告并返回 1；需配合 is_array() 使用，避免误用 sizeof()、strlen() 等错误方式。
count() 是 PHP 里唯一靠谱的数组长度统计函数
PHP 里统计数组元素个数，count() 是标准且唯一推荐的方式。它不看键名类型、不挑数据结构，连多维数组也能递归算——但默认不递归，这点必须手动控制。
常见错误是误用 sizeof()：它只是 count() 的别名，语义模糊，容易让人以为它和内存大小有关；还有人试图用 strlen() 或 mb_strlen() 去“测数组”，结果返回 NULL 或 0，因为它们只处理字符串。
-
count()支持所有数组类型（索引、关联、混合、空数组） - 对
null返回0，对非数组变量（如字符串、整数）会触发E_WARNING并返回1—— 这点极易踩坑 - 第二个参数
$mode控制是否递归：COUNT_RECURSIVE（或1）才进子数组，否则只算顶层元素
count() 对非数组变量的警告行为必须拦截
当你传入一个可能为 null、字符串、对象甚至未定义变量时，count() 不会静默失败，而是抛出警告并返回 1（比如 count("hello") 返回 1），这跟直觉完全相反。
典型场景是处理 API 返回值：前端传了个空字符串当 JSON，后端 json_decode() 失败返回 null，接着直接 count($data)，结果没报错但逻辑全乱了。
立即学习“PHP免费学习笔记（深入）”；
- 安全写法永远加类型判断：
is_array($var) ? count($var) : 0 - PHP 8+ 可用空合并+类型检查：
$len = $var ?? []; count(is_array($len) ? $len : []) - 别依赖
@count()抑制警告——掩盖问题，不解决根源
多维数组要小心 COUNT_RECURSIVE 的性能代价
用 count($arr, COUNT_RECURSIVE) 看似方便，但它会完整遍历每一层子数组，遇到深层嵌套或大体积数据时，CPU 和内存开销明显上升。这不是“慢一点”，而是可能从毫秒级跳到秒级。
比如处理一个 10 层深、每层 100 个元素的嵌套数组，COUNT_RECURSIVE 实际访问元素次数接近 10⁹ 次量级；而你往往只需要顶层长度。
- 先问自己：真需要总元素数？还是只要第一层数量？90% 场景只需默认模式
- 如果必须递归计数且数据大，考虑改用迭代器 +
RecursiveIteratorIterator手动控制深度 -
COUNT_RECURSIVE对含循环引用的数组会崩溃（PHP 7.4+ 会抛出Fatal error）
count() 在 foreach 循环里反复调用等于自找麻烦
有人习惯在 foreach 条件里每次调用 count()，比如：for ($i = 0; $i 。这在每次迭代都重新计算长度，对大数组就是纯性能浪费。
更隐蔽的是在 foreach 循环体里反复 count($items) 判断是否为空，其实一次就够了。
- 提前缓存结果：
$len = count($arr); for ($i = 0; $i - 空数组判断直接用
empty($arr)或!$arr，比count($arr) === 0快且语义清晰 - PHP 8.0+ 支持
array_is_list()等新函数，但count()仍是长度统计不可替代的底层操作
真正难的不是怎么调用 count()，而是想清楚你到底要“数什么”——是结构层级、有效数据量，还是单纯防错兜底。多数线上 bug 都出在没区分这三者。
