根本原因是foreach()接收了null、false、int等非数组/不可遍历类型；常见于json_decode()失败返回null、数据库查询无结果、配置读取失败或$_POST数据截断为null等场景。
为什么 phpEnv 下 foreach() 报 Invalid argument supplied
根本原因不是 PHP 版本或扩展问题，而是 foreach() 的第一个参数传入了 null、false、int 或未定义变量——phpEnv 默认不开启 error_reporting(E_ALL)，这类弱类型警告容易被忽略，但实际代码已出错。
常见触发场景：调用 json_decode() 后没检查返回值、读取配置文件失败返回 false、数据库查询无结果时直接遍历空 mysqli_result 对象。
-
json_decode($str)失败时返回null，而非空数组 —— 必须显式判断 - 使用
parse_ini_file()时路径错误或权限不足，返回false - phpEnv 的 Apache 模块模式下，
$_POST或$_GET可能因请求体过大被截断，导致键存在但值为null
如何快速定位 foreach 的非法参数源
在 phpEnv 控制面板中打开「PHP 设置」→「错误报告」，把 error_reporting 改为 E_ALL & ~E_NOTICE（保留 Warning），并确认 display_errors = On。然后在报错行上方加一行调试：
var_dump($data); // 替换 $data 为 foreach 的变量名
foreach ($data as $item) { ... }
如果输出 NULL 或 bool(false)，就确认了源头；若输出 string(0) ""，说明是空字符串误当数组用了。
立即学习“PHP免费学习笔记（深入）”；
- 不要依赖
is_array($data)做兜底——它对null返回false，但你仍需决定 fallback 行为 - 更安全的写法是：
foreach ((array)$data as $item)，强制转数组（但会把对象转成属性键值对，慎用于 stdClass） - phpEnv 的 PHP 7.4+ 环境支持空合并运算符，推荐：
foreach ($data ?? [] as $item)
phpEnv 特定配置加剧该警告的几个坑
phpEnv 自带的 php.ini 模板常把 track_errors = Off，导致 mysql_query() 失败后 $result 是 false，直接 foreach($result) 就炸。另外，它的默认 post_max_size = 8M，但某些接口 POST 超过此值时，$_POST 变为空数组，而 $_REQUEST 里对应键可能为 null。
- 检查
phpinfo()中的Loaded Configuration File路径，确认修改的是当前生效的php.ini - 若用 mysqli 面向对象风格，
$stmt->get_result()在无结果时返回false，不是空mysqli_result - phpEnv 的 Nginx 模式下，
fastcgi_read_timeout默认仅 60s，超时后 PHP 进程中断，可能留下未初始化的变量
修复后还要注意的兼容性细节
即使加了 ?? []，也要小心数据结构变化：比如原逻辑依赖 count($data) > 0 判断是否有数据，现在 count([]) === 0 成立，但 count(null ?? []) 也等于 0，真假难分。真正关键的是区分「无数据」和「数据获取失败」。
- 对
json_decode()，用json_last_error() === JSON_ERROR_NONE显式校验 - 对数据库查询，先判断
is_object($result) && method_exists($result, 'num_rows')，再遍历 - phpEnv 的多版本共存特性意味着：同一段代码在 PHP 7.2 和 8.1 下，
foreach(null)都报 Warning，但 PHP 8.0+ 对foreach(new stdClass())会报 Fatal error，不能只靠 suppress
最麻烦的其实是嵌套遍历——比如 foreach($list as $item) { foreach($item['children'] as ...)，这里 $item['children'] 可能压根不存在，得逐层判空，光靠类型转换搞不定。
