PHP隐错后浏览器仍显示错误，说明display_errors未真正关闭，需检查php.ini实际生效值、运行时代码覆盖、框架调试模式、OPcache缓存及Web服务器参数覆盖。
PHP 隐错后浏览器仍显示错误信息，说明 display_errors 未真正关闭，或被运行时函数（如 ini_set()）临时开启，也可能受 Web 服务器配置、框架层覆盖或 OPcache 缓存影响。
检查并强制关闭 display_errors 和 html_errors
仅在 php.ini 中设置不够——PHP CLI、FPM、Apache 模块可能加载不同配置文件。必须确认当前运行环境实际生效的值：
- 新建
info.php，写入<?php phpinfo(); ?>，访问后搜索display_errors和html_errors，看其“Local Value”是否为Off - 若为
On，修改对应配置文件（常见路径：/etc/php/*/fpm/php.ini、/etc/php/*/apache2/php.ini或php --ini显示的路径） - 设为：
display_errors = Off，html_errors = Off（后者防止错误中嵌入 HTML 标签泄露路径） - 改完重启服务：
sudo systemctl restart php*-fpm或sudo systemctl restart apache2
排查运行时代码主动开启错误显示
很多老项目或调试代码会在入口处调用 ini_set('display_errors', '1') 或 error_reporting(E_ALL)，这类设置优先级高于 php.ini：
- 全局搜索项目中所有
ini_set、error_reporting、set_error_handler调用 - 特别注意
index.php、bootstrap.php、config.php等启动文件 - 若有，改为：
ini_set('display_errors', '0');，并确保它在任何报错发生前执行 - 避免在条件分支里开启（如
if (DEBUG) { ini_set(...) }），上线时 DEBUG 常被遗漏
确认 error_log 是否启用且路径可写
关闭 display_errors 后，错误应写入日志而非屏幕。若日志没内容，可能是 error_log 未配或权限不足，导致错误被丢弃：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
立即学习“PHP免费学习笔记（深入）”；
- 检查
php.ini中error_log指向路径（如/var/log/php_errors.log） - 确认该文件存在且 Web 进程用户（如
www-data或nginx）有写权限：sudo chown www-data:www-data /var/log/php_errors.log - 同时设
log_errors = On，否则即使路径对也不记录 - 测试：在脚本中故意触发 Notice：
echo $undefined_var;，再查日志是否新增条目
留意框架/Composer 自动错误处理器
Laravel、Symfony、ThinkPHP 等框架常自带开发模式错误页，它们绕过 PHP 原生 display_errors 控制：
- Laravel：检查
.env中APP_DEBUG=true→ 改为false；清缓存：php artisan config:clear - Symfony：查看
APP_ENV=dev是否误用于生产；确保APP_DEBUG=0 - Composer autoload 错误（如类未找到）可能由
composer dump-autoload -o生成的优化文件引发，尝试删掉vendor/autoload.php重装 - OPcache 启用时，旧代码可能被缓存，改了
php.ini但没清 OPcache：opcache_reset()或重启 PHP 进程
最易忽略的是多环境配置叠加：Nginx 的 fastcgi_param PHP_VALUE 可能强行覆盖 display_errors，检查站点配置里是否有类似行；另外某些主机控制面板（如 cPanel）会单独提供 PHP 设置界面，其优先级可能高于系统 php.ini。
