PHP7.2count函数如何避免非数组参数警告

聊一个在 PHP 升级到 7.2+ 后，几乎每个开发者都会撞上的小“坑” —— count() 函数突然开始报 Warning 了。

这个改动让不少老项目在升级后直接“报警”，甚至有些新项目在调试时也一头雾水。其实，背后的逻辑并不复杂，只是 PHP 从一个“宽容”的版本，切换到了一种“严格”的模式。

count() 报 Warning 的根本原因是什么

从 PHP 7.2 开始，count() 这个函数就变得“挑剔”起来了。它现在只接受两种类型：array（数组）和实现了 Countable 接口的对象。如果你传入 null、false、字符串、整数，甚至是一个未定义的变量，它都会立刻甩给你一个 Warning，提示你“参数必须是一个数组或实现了 Countable 接口的对象”。

这不是什么 bug，这是 PHP 在主动帮你“抓虫”。它想告诉你：你正在对一个本不该计数的东西进行计数，你的代码逻辑可能存在潜在缺陷。所以，与其抱怨，不如学会如何优雅地应对。

最常用且安全的修复方式：强制转成数组

要解决这个问题，最直接、最轻量、也是语义最清晰的做法，就是给变量套上一层 (array) 强制转换。PHP 的数组转换规则非常明确，而且几乎不会出意外：

• null 会变成 []（空数组，count() 返回 0）
• false 会变成 [false]（一个包含 false 的数组，count() 返回 1，但业务上可能需要额外判断）
• 'abc' 会变成 ['abc']
• 42 会变成 [42]
• 如果它本身已经是数组，那就保持不变。

看个例子：

$data = get_post_meta($post_id, 'tags', true); // 可能返回 null / '' / false / string
$tag_count = count((array)$data); // ✅ 安全，不会警告

这样写，代码就安全了，而且意图一目了然：无论你传来什么，我都把它当作一个数组来处理。

什么时候该用 is_countable() 而不是 (array) 强转

不过，(array) 强转虽然好用，但并非万能。当你需要区分“这个值本来就不可计数”和“它就是一个空数组”时，is_countable() 才是更精确的选择。

举个例子，在 Magento 或某个自定义类中，一个方法本应返回一个 Collection 或 array，但可能因为某些原因，它被赋了 null 或 0。这时候，你希望记录一个异常，而不是悄无声息地把它当成空数组处理。那么，is_countable() 就派上用场了：

• is_countable(null) → false
• is_countable([]) → true
• is_countable(new stdClass()) → false

典型的写法是：

$items = $product->getRelatedItems();
$process_count = is_countable($items) ? count($items) : 0;

这样，你就能在保持代码健壮性的同时，保留对数据源的判断力。

容易踩的坑：别用 @ 抑制、也别用 isset() 替代

有些开发者图省事，会用一些“看似聪明”的方法来绕过警告，但这些做法往往治标不治本，甚至可能埋下更大的隐患。

• @count($data)：这只是在屏蔽警告，并没有解决数据污染的问题。后续的逻辑很可能会因为意料之外的数据类型而崩溃在别的地方。
• isset($data) && count($data) > 0：当 $data = [] 时，这个条件会成立，但问题出在 $data = false 时，isset() 会返回 false，导致漏判。更糟的是，如果 $data = 0 或 ‘0’，isset() 会放行，但 count(0) 会直接报错。
• is_array($data) && count($data) > 0：这个比 isset 要严谨一些，但不如 (array)$data 简洁通用。而且，如果 $data 是一个实现了 Countable 接口的对象（比如 Lara vel 的 Collection），is_array() 会判断为 false，导致你也无法正确计数。

所以，真正要判断“有没有元素”，直接上 count((array)$data) > 0 或 is_countable($data) && count($data) > 0 就好，别绕远路。

话说回来，很多 count() 警告，其实根源并不在 count() 本身，而是上游数据源没有做好兜底。比如 json_decode() 失败返回 null，API 返回空响应，数据库查询失败返回 false…… 修复 count() 调用只是在“止痛”，真正要做的，是顺藤摸瓜，查清楚到底是谁把脏数据塞了进来，从根本上解决问题。