PHP多模块项目统一隐藏错误需入口层拦截、运行时强制覆盖、环境感知三者结合：所有入口文件开头必须执行error_reporting(0)和ini_set('display_errors','0')，禁用set_error_handler()，启用log_errors，并彻底删除phpinfo()等敏感函数。
PHP 多模块项目中，统一隐藏错误（即禁用 display_errors、关闭 error_reporting 输出、避免暴露路径/版本等敏感信息）不能靠单点配置，必须在入口层拦截 + 运行时强制覆盖 + 环境感知三者结合，否则子模块或 CLI 调用仍可能漏出错误。
所有入口文件开头强制调用 error_reporting(0) 和 ini_set('display_errors', '0')
多模块项目常有多个入口：如 public/index.php（Web）、bin/cli.php（命令行）、api/v1/index.php（子 API 入口）。每个入口都必须在加载任何业务代码前执行错误屏蔽：
<?php
error_reporting(0);
ini_set('display_errors', '0');
ini_set('log_errors', '1'); // 确保错误仍写入日志
// 后续再 require autoload 或路由分发
?>
- 仅在
php.ini中设display_errors = Off不够——CLI SAPI 默认值可能不同，且模块若被单独 require 会绕过 ini 配置 -
error_reporting(0)比error_reporting(E_ALL & ~E_NOTICE)更彻底，避免开发误留调试级输出 - 务必搭配
ini_set('log_errors', '1')，否则错误既不显示也不记录，等于“静默丢弃”
模块内禁止使用 set_error_handler() 或 restore_error_handler()
某些模块为捕获自定义错误，会注册自己的错误处理器。这极易破坏全局隐错策略，尤其当模块未正确 restore 或抛出异常后未清理 handler 时：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 一旦某个模块调用
set_error_handler()，它会接管所有E_WARNING/E_NOTICE，而默认不处理的错误可能意外输出到页面 - 若模块内用了
restore_error_handler()，会把控制权交还给上一个 handler（可能是未屏蔽的默认行为），导致隐错失效 - 统一做法：禁止模块自行注册 error handler；如需结构化错误处理，应统一走异常（
throw new RuntimeException()）+ 全局set_exception_handler()
检查 phpinfo()、get_cfg_var()、ini_get() 是否暴露配置
即使错误不显示，模块若主动调用配置探测函数，仍可能泄露敏感信息：
立即学习“PHP免费学习笔记（深入）”；
-
phpinfo()必须从生产环境彻底删除，连注释掉都不够——若被误包含或路径猜解命中，直接暴露全部配置 - 模块中避免使用
ini_get('display_errors')或get_cfg_var('error_reporting')，这类调用本身无害，但常伴随调试逻辑（如“仅开发环境打印”），易成隐错漏洞出口 - 检查 Composer 自动加载器（如
vendor/autoload.php）是否含调试代码；某些老旧包会在初始化时 dumpphpversion()或extension_loaded()结果
真正难控的是跨 SAPI 场景：Web 请求走 Apache/Nginx，CLI 脚本走系统 PHP，Cron 任务可能用另一套 php.ini。隐错必须在每个执行上下文里独立生效，而不是指望“一次配置，处处生效”。
