Flight 的 error 回调不触发，因默认不捕获 PHP 致命错误；需在 Flight::start() 前注册回调，并配合 set_error_handler 和 register_shutdown_function 处理致命错误。
Flight 中 error 回调不触发？先确认是否启用了错误捕获
Flight 默认不会自动捕获 PHP 致命错误（如 Fatal error: Call to undefined function），它只处理抛出的异常和手动调用的 Flight::error()。如果你改了 error 回调但 500 页面没变，大概率是错误根本没进到 Flight 的流程里。
实操建议：
- 确保在
Flight::start()前注册了Flight::error()回调，否则无效 - 检查
display_errors和error_reporting设置——它们会影响底层错误是否被转成异常；推荐在入口文件开头加error_reporting(E_ALL); ini_set('display_errors', '0'); - 致命错误（Parse/Compile/Fatal）需配合
set_error_handler+register_shutdown_function才能兜底，Flight 本身不接管这部分
自定义 404 响应：用 notFound 而不是 error
404 是路由未匹配，属于正常控制流分支，不是错误。Flight 提供专用的 Flight::notFound() 回调，别往 error 里塞 404 逻辑，否则会干扰真实错误排查。
常见错误现象：访问不存在路径时返回空白页或默认 Apache/Nginx 404，说明 notFound 没生效。
立即学习“PHP免费学习笔记（深入）”；
实操建议：
- 必须在
Flight::start()之前注册：Flight::notFound(function() { http_response_code(404); echo '自定义404页面'; }); - 如果用了 URL 重写（如 Apache 的
.htaccess），确保所有请求都落到index.php，否则 Flight 根本收不到请求 - 不要在
notFound回调里 throw 新异常——这会跳转到error回调，导致 404 变成 500
返回 JSON 格式的 404/500 响应：注意 Content-Type 和状态码顺序
API 场景下，前端依赖正确的 Content-Type: application/json 和 HTTP 状态码。Flight 不会自动设置响应头，漏掉会导致前端解析失败或状态码被忽略。
实操建议：
- 在
notFound或error回调开头立即调用http_response_code(404)或http_response_code(500)；放在header()之后可能失效 - 手动设置头：
header('Content-Type: application/json; charset=utf-8'); - 示例：
Flight::notFound(function() { http_response_code(404); header('Content-Type: application/json; charset=utf-8'); echo json_encode(['error' => 'Not Found'], JSON_UNESCAPED_UNICODE); });
生产环境禁用调试信息：display_errors 关闭后仍要控制输出内容
即使 display_errors=Off，Flight 的 error 回调若直接 echo $e->getMessage()，依然会把敏感信息（如路径、数据库配置片段）暴露给用户。
实操建议：
- 开发环境可保留详细错误，生产环境回调中只输出泛化提示，例如
'Something went wrong.' - 记录完整错误到日志：
error_log($e->getMessage() . ' in ' . $e->getFile() . ':' . $e->getLine(), 3, '/var/log/flight-error.log'); - 避免在回调里调用
var_dump、print_r或未过滤的$e->__toString()
真正容易被忽略的是：Flight 的错误处理只是应用层一环，Web 服务器（如 Nginx）可能配置了 error_page 500 /50x.html，会覆盖 PHP 输出。上线前务必检查服务器级错误页配置是否冲突。
