真要“隐错”需分场景：开发期隐藏细节、生产环境防信息泄露、API统一返回格式；Laravel需APP_DEBUG=false且配置日志等级与通道；ThinkPHP6需同时关闭app_debug和show_error_msg；Slim需自定义错误处理器并过滤敏感字段。
PHP框架自带的错误隐藏机制，不是靠“关掉错误显示”就完事——多数时候你关了 display_errors，但日志照打、异常照抛、API 返回 500，用户还是感知到出错了。真要“隐错”，得区分场景：是开发时不想暴露细节？还是生产环境避免泄露路径/类名/SQL 片段？抑或是 API 接口需统一返回格式而非堆栈？不同框架处理逻辑差异很大，不能一概而论。
Laravel 中禁用调试信息但保留日志记录
Laravel 默认在 APP_DEBUG=true 时向浏览器输出完整异常页面（含代码片段和变量 dump），这绝不能上生产。但光把 .env 改成 APP_DEBUG=false 不够——你还得确认 config/app.php 中的 debug 值确实被环境覆盖，且 APP_LOG_LEVEL 设为 error 或更低，否则 warning 级别日志仍可能意外暴露上下文。
-
APP_DEBUG=false是硬性前提，否则所有后续配置都可能被绕过 - 检查
config/logging.php中stackchannel 是否包含single或daily，确保错误实际落盘而非仅输出到php://stderr - 若用 Horizon 或 Scout，它们各自有独立的异常捕获逻辑，需单独配置
horizon.php的trim_recent_failed_jobs和failed处理方式
ThinkPHP 6 的 app_debug 和 show_error_msg 双开关
ThinkPHP 6 把“是否显示错误”和“是否显示错误详情”拆成两个配置项，容易误判。比如 app_debug=false 关闭调试模式后，若 show_error_msg=true，仍会返回 500 + 简短错误字符串（如 “SQLSTATE[HY000] [2002] Connection refused”），这对前端仍是敏感信息。
-
app_debug=false影响路由缓存、模板编译等行为，不只是错误显示 -
show_error_msg=false才真正屏蔽响应体中的错误文本，此时默认返回空内容或自定义 500 页面 - 注意
exception_handle配置项指向的异常处理器类，它可能重写了render()方法，绕过上述开关
Slim Framework 4 中拦截异常并统一 JSON 响应
Slim 默认用 Whoops 显示调试页面，但生产环境必须替换。关键不是“隐藏”，而是“接管”：用 addErrorMiddleware() 注册自定义错误处理器，并在其中过滤敏感字段（如 file、line、trace）。
立即学习“PHP免费学习笔记（深入）”；
- 调用
$app->addErrorMiddleware(false, true, true)时，第一个false表示不显示详细错误，后两个true控制日志和响应体，但仅限内置逻辑 - 必须配合
setExceptionHandler()，在回调中手动构造json_encode(['code'=>500,'msg'=>'服务异常'])并写入响应体 - 数据库连接失败、Redis 超时等底层异常，可能由 PDO 或 Predis 抛出，Slim 不会自动包装，需在中间件中提前
try/catch
真正难的不是“怎么关错误”，而是判断哪些错误该静默、哪些该降级为警告、哪些必须立刻告警。比如 SQL 错误在开发期要全量暴露，在生产期却要抹掉表名和字段名；又比如 JWT 过期该返回 401 而非 500。框架工具只是执行者，背后的错误分类策略，才是隐错是否安全的关键。
