php网关层报错必须与主业务进程隔离，需从请求入口起全局try-catch包裹路由分发、中间件、反向代理等全流程，超时和连接失败应降级返回502/504并独立异步记录日志，禁用display_errors，依赖幂等设计应对状态不一致。
PHP网关层报错必须与主业务进程隔离
PHP 实现的 API 网关（比如用 Slim、Laravel Octane 或纯 Swoole 搭建）一旦出错，不能让 500 或 Fatal error 泄露到上游或阻塞主业务逻辑。核心原则是：网关层崩溃 ≠ 业务服务宕机。常见错误是把网关和后端服务混在同一进程/容器里，或没做异常兜底，导致一个路由解析失败就卡死整个 worker。
用 try-catch 包裹全部网关路由分发逻辑
不是只 catch 控制器方法，而是从请求进入网关的第一行代码开始捕获——包括路由匹配、中间件执行、反向代理转发等环节。Swoole 场景下尤其关键，因为单个协程崩溃可能影响后续请求。
-
try { $app->run(); }不够，要包住$server->on('request', ...)回调最外层 - Laravel Octane 中需在
bootstrap/app.php入口加全局set_exception_handler，但优先级低于框架自己的 handler，建议改用Octane::call()的包装层 - 别依赖
@error_reporting(0)，它不拦截致命错误，仅屏蔽 notice/warning 输出
超时、连接失败类错误必须降级为 HTTP 502/504 并记录，不抛出异常
网关调用下游服务失败（如 cURL CURLOPT_TIMEOUT 触发、Redis 连接 refused、gRPC deadline exceeded），这类错误本质是通信问题，不是代码缺陷，不该触发 PHP 异常链或日志 flood。
- 使用
curl_exec()后必须检查curl_errno($ch) !== 0，而不是只看返回值是否 false - Swoole HTTP client 要监听
error事件，而非只等finish；connect timeout和receive timeout需分别处理 - 对下游无响应场景，应立即返回
504 Gateway Timeout，并带简短 body（如{"code":504,"msg":"upstream timeout"}），避免空响应或 chunked hang
错误日志写入独立通道，禁止阻塞主流程
网关错误日志如果直写本地文件（error_log('...', 3, '/var/log/gateway.log')），在磁盘 IO 高或满时会阻塞 event loop；若走 syslog 或网络日志服务，更要设超时和 fallback。
立即学习“PHP免费学习笔记（深入）”；
- 用
swoole_async_writefile()替代同步写，或投递到独立协程/进程处理 - Logstash/Filebeat 类采集器需配置
queue.full.action: drop_oldest，防日志堆积拖垮网关 - 生产环境禁用
display_errors = On，且确保log_errors = On+error_log指向非系统盘路径
真正难的是状态一致性——比如网关已返回 502，但下游其实已处理成功。这种 case 只能靠幂等设计兜底，网关本身做不到“不丢不重”，它只负责隔离和快速失败。
