php 7.2+ 中 count() 对非可计数类型报 warning，应优先用 is_countable() 判断后再调用，避免强制转数组导致逻辑失真，并通过日志定位 null 数据源头。
count() 传 null / string / int 报 Warning 怎么办
PHP 7.2 开始，count() 不再容忍非可计数类型——null、''、0、false、'abc'、new stdClass 全部触发 Warning: count(): Parameter must be an array or an object that implements Countable。这不是 bug，是 PHP 类型校验变严了。
最直接的修复不是“掩盖警告”，而是明确告诉 PHP：“只在能数的时候才数”。推荐优先使用 is_countable()（PHP 7.3+ 原生支持）：
if (is_countable($items)) {
$len = count($items);
} else {
$len = 0;
}
若项目还卡在 PHP 7.1–7.2，可用兼容写法：
is_array($items) || (is_object($items) && method_exists($items, 'count'))- 或更保守地强制转数组：
count((array)$items)—— 注意：这会把0、false、''都变成含一个元素的数组（(array)0 === [0]），逻辑可能意外偏移
为什么 (array)$var 有时不安全
强制类型转换看似简单，但容易掩盖真实数据问题。比如：
-
$data = null→(array)$data得到[]，count([]) === 0，表面没问题 -
$data = '[]'（字符串）→(array)'[]'得到['[]']，count() === 1，但业务上它本应是空 -
$data = 42→(array)42得到[42]，count() === 1，完全失真
这种“假安全”会让后续逻辑误判数据状态。尤其在 Magento、Laravel 等框架中，getAppliedTaxes() 或 getItems() 返回 null 通常意味着上游模块写入异常，该查的是谁设了 null，而不是让 count() 忍着。
哪里最容易出错：常见调用场景
这些地方高频触发 warning，检查时优先盯紧：
- 模板层直接
count($collection)，而$collection来自未初始化的变量或失败的查询（如ProductRepository::getList()返回null） - 第三方模块覆盖核心方法（如重写
Address::getAppliedTaxes()）但没做返回值校验，返回了false或'' - JSON 解析后未验证结构：
$json = json_decode($raw); count($json->items)—— 若$raw是无效 JSON，$json为null，$json->items触发 notice 后再进count() - 使用
sizeof()别名（等价于count()），同样受限制
根因比修复更重要：怎么定位谁污染了数据
修完 count() 警告只是止痛，真正要解决的是“为什么这里会是 null”。建议在疑似污染点加日志：
// 在 setAppliedTaxes() 或类似 setter 中
public function setAppliedTaxes($value)
{
if (!is_array($value) && !($value instanceof Countable)) {
error_log('⚠️ setAppliedTaxes called with non-countable: ' . var_export($value, true));
}
$this->_appliedTaxes = $value;
}
或者在关键 getter 返回前拦截：
public function getAppliedTaxes()
{
$val = $this->_appliedTaxes;
if (!is_countable($val) && $val !== []) {
error_log('❌ getAppliedTaxes returned non-countable: ' . gettype($val));
}
return $val ?: [];
}
这类日志能快速暴露是哪个插件、哪段自定义代码把脏数据塞进了对象属性——这才是 PHP 7.2+ 下 count() 报警背后真正该修的坑。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
