Parse 错误根本捕获不到，set_error_handler 和 try/catch 都无效
PHP 的 Parse 错误（比如语法写错、少个分号、括号不匹配）发生在脚本加载和编译阶段，远早于运行时。此时 set_error_handler 还没注册，try/catch 根本没机会执行——它们只对运行时错误（E_ERROR 以上但非 E_PARSE）起作用。
常见错误现象：
– 页面空白，日志里只有 PHP Parse error: syntax error, unexpected '}' in /path/file.php on line 12
– 开启了 display_errors 也看不到提示（尤其在生产环境被关掉时）
– 以为加了 try { require 'bad.php'; } catch (...) { } 就能兜住，结果照样崩
- 唯一能“提前发现”的方式是：用 PHP 自带的语法检查命令
php -l filename.php - CI/CD 流程中必须加入该检查，否则上线即失败
- 编辑器/IDE（如 VS Code + PHP Intelephense）能实时标出语法问题，但依赖本地 PHP 环境配置正确
为什么 error_reporting 和 display_errors 对 Parse 错误效果有限
这两个配置控制的是运行时错误的报告行为，而 Parse 错误属于编译期中断，PHP 解析器直接退出，连脚本入口都没进。即使你写了 error_reporting(E_ALL); ini_set('display_errors', '1');，只要文件本身有语法错误，这行代码根本不会被执行。
-
display_errors=On只影响已成功加载并开始执行的脚本 -
log_errors=On能把 Parse 错误记到error_log，但前提是 Web 服务器（如 Apache/Nginx）或 CLI 环境配置了正确的日志路径 - Docker 或容器化部署时，常因
php.ini没挂载或被覆盖，导致 Parse 错误默默丢弃
开发阶段快速定位 Parse 错误的实操办法
别等请求进来才暴露问题。本地改完 PHP 文件，立刻终端执行：
立即学习“PHP免费学习笔记（深入）”；
php -l app/controllers/UserController.php
返回 Errors parsing app/controllers/UserController.php 就说明有语法问题，接着看下一行的具体报错位置。
- 批量检查：用
find . -name "*.php" -exec php -l {} \;（注意引号和空格） - Git 提交前加 hook：在
.git/hooks/pre-commit里写检查逻辑，避免带错文件提交 - VS Code 中按
Ctrl+Shift+P输入 “PHP: Validate” 可手动触发语法校验（需启用 PHP 插件） - 不要依赖浏览器刷新来试——那已经是最后一道防线，而且往往不给完整信息
线上环境 Parse 错误只能靠日志和部署流程兜底
线上不可能开 display_errors，也不能让用户触发 php -l。这时候唯一可靠的方式是：确保每次部署都经过语法检查，并把 Web 服务器错误日志路径配对 PHP 的 error_log。
- Apache 下检查
ErrorLog指向是否和 PHP 的error_log一致 - Nginx + PHP-FPM 场景下，Parse 错误默认打到
php-fpm.log，不是access.log或error.log - 如果用了 Docker，确认
php.ini的error_log路径映射到了宿主机可读位置，且权限可写 - 某些共享主机禁用了
php -l，这时只能靠本地开发环境严格把关，或者用 GitHub Actions 自动跑语法检查
最麻烦的地方在于：Parse 错误不抛异常、不走任何钩子、不触发 shutdown 函数——它就是硬中断。所以防御动作全得放在“执行之前”，而不是“出错之后”。
