PHP 7.0+ 默认不报未定义变量/索引错误，需显式设置 error_reporting(E_ALL) 并启用 display_errors；还需检查 opcache.optimization_level 和避免 @ 抑制符，否则 set_error_handler 也无法捕获。
PHP 7.0 起，error_reporting 对隐式错误（如未定义变量、未定义索引）的默认行为发生实质性变化：不再报 E_NOTICE 或 E_WARNING 级别错误，除非显式开启。这不是“参数变了”，而是底层错误触发逻辑收紧 —— 关键在 error_reporting 值和 zend.assertions、display_errors 的协同作用。
PHP7+ 默认不报未定义变量/索引，怎么让它报？
PHP 7.0+ 默认 error_reporting 值为 E_ALL & ~E_DEPRECATED & ~E_STRICT，但实际是否显示 E_NOTICE（比如 Undefined variable $x）取决于运行时配置是否允许该级别被报告。常见误区是只改 php.ini 却忽略脚本内覆盖。
- 检查当前生效值：
var_dump(error_reporting());，不是看phpinfo()里 ini 的默认值 - 强制启用所有非严格警告：
error_reporting(E_ALL | E_NOTICE | E_WARNING);（注意：PHP 8.0+ 已移除E_STRICT的独立位，无需再加） - 若用
ini_set()动态设置，必须在出错代码前调用，且display_errors = On才能在页面看到 - CLI 模式下默认
display_errors = Off，需额外设ini_set('display_errors', '1');
为什么 set_error_handler() 捕不到未定义变量？
set_error_handler() 默认不处理 E_ERROR、E_PARSE、E_CORE_ERROR 等致命错误，但也能捕获 E_NOTICE —— 前提是该 notice 实际被触发并归入 error reporting 范围。PHP 7+ 对“未定义数组索引”（Notice: Undefined array key）这类错误，仅在 error_reporting 包含 E_NOTICE 且 opcache.optimization_level 未跳过语法检查时才抛出。
- 确认
opcache.enable = 1且opcache.optimization_level未禁用0x10000（即“常量折叠”不影响 notice 触发） -
set_error_handler()必须在error_reporting()设置后注册，否则 handler 不会被调用 - 某些 notice（如访问
$arr['missing']）在 PHP 7.4+ 可能被优化为静默返回null，需配合strict_types=1或显式判断isset()来暴露问题
PHP7.4+ 的 Array Access Notice 更隐蔽，怎么调试？
PHP 7.4 引入 Undefined array key 替代旧版 Undefined index，但默认仍不报错 —— 尤其当数组来自 json_decode($str, true) 或 $_GET 等动态来源时，容易漏掉空值或缺失键的边界情况。
立即学习“PHP免费学习笔记（深入）”；
- 开发环境务必设：
error_reporting(E_ALL); ini_set('display_errors', '1'); - 避免依赖 notice 报错来发现逻辑缺陷，改用
isset($arr['key'])或空合并操作符$arr['key'] ?? null - 静态分析工具（如 PHPStan level 5+）比运行时 notice 更早暴露这类问题，
E_NOTICE不应是你的第一道防线 - 若需兼容老代码，可在入口加
error_reporting(E_ALL ^ E_NOTICE);临时屏蔽，但上线前必须清理
真正麻烦的不是参数怎么调，而是 PHP 7+ 把“是否报 notice”从“配置开关”变成了“语言行为 + 运行时配置 + OPcache 优化”的三重耦合。改 error_reporting 只是表象，得同步盯住 display_errors、opcache.enable 和代码里有没有 @ 抑制符 —— 后者在 PHP 7.4+ 会完全吞掉 notice，连 set_error_handler 都收不到。
