ThinkPHP 6 的 render() 默认按 Accept 头或 URL 后缀判断响应格式，未明确声明 JSON 时 fallback 为 HTML；应结合 isAjax()、expectsJson() 和路由前缀（如 api/）判断并用 response()->json() 返回，避免跳过中间件和状态码。
ThinkPHP 6 的 render() 方法为什么总返回 HTML 而不是 JSON？
接口异常时看到的是带堆栈的网页，而不是 {"code":500,"msg":"..."} —— 根本原因是 render() 默认按请求类型（Accept 头或 URL 后缀）判断响应格式，而 CLI、Postman 或部分前端请求没带 Accept: application/json，框架就 fallback 到 HTML。
- 在
app/exception/Handler.php的render()里，先用$request->isAjax() || $request->expectsJson()判断是否该走 JSON；别只靠isAjax()，它只认X-Requested-With: XMLHttpRequest，现代 fetch 不带这个头 - 手动加一层兜底：如果当前是 API 路由（比如路由分组用了
api/前缀），强制返回 JSON，用$request->routeIs('api.*')或检查$request->path()是否以'api/'开头 - 别在
render()里直接return json([...])—— 这会跳过响应输出流程，丢失 HTTP 状态码和中间件逻辑；应该 throw 新异常或调用response()->json([...], $code)
如何让自定义异常类在全局生效且不被 think\ExceptionHandle 吞掉？
写了 AppException 继承 HttpException，但抛出后还是进默认错误页 —— ThinkPHP 6 默认只捕获 Throwable，但 ExceptionHandle 的 ignoreReport 和 shouldReport 配置会过滤掉非 Exception 子类，或者你没在 app/exception/Handler.php 的 $dontReport 里排除它。
- 确保自定义异常继承
\think\Exception或至少\Exception，不要继承\Error类型 - 在
Handler类中显式把你的异常加到$dontReport = [AppException::class]，否则会被当成需上报错误，触发日志+页面渲染双路径 - 如果想统一处理所有业务异常，重写
shouldReport()：当$exception instanceof AppException时返回false，避免写入日志干扰排查
app_debug = false 下，接口异常为什么还暴露敏感信息？
线上关了调试模式，但调用 /api/user 报错时依然返回完整 SQL 或文件路径 —— 关键在于 app_debug 只控制「是否显示调试页面」，不控制「异常内容是否脱敏」；真正起作用的是 exception_handle 配置里的 show_error_msg 和异常处理器本身的逻辑。
- 检查
config/app.php中'show_error_msg' => false是否生效（TP6.1+ 支持，旧版需手动处理） - 在
render()中对生产环境做字段裁剪：删除$e->getTraceAsString()、过滤$e->getFile()和$e->getLine()，只保留$e->getMessage()并映射为用户友好提示 - 数据库异常（如
think\db\exception\DataNotFoundException）尤其危险，必须单独拦截，不能直接透出$e->getMessage()，里面可能含表名或条件片段
调试 API 异常时，trace 日志和 log 日志的区别在哪？
开了 app_trace，但接口报错后找不到 trace 记录 —— trace 是运行时快照（SQL、请求参数、模板渲染等），只在调试模式下写入，且默认不记录异常；而 log 是结构化错误日志，只要配置了 log 驱动就会记，但默认等级是 error，有些异常被吞了就没记录。
立即学习“PHP免费学习笔记（深入）”；
- 要查异常链路，优先看
runtime/log/下的error日志，不是trace目录 - 在
Handler->report()里加一行Log::record($exception->getTraceAsString(), 'trace');，可强制把堆栈写进 trace 日志（仅调试期） - 注意
log配置中的level，如果设成['error']，那Warning级异常不会落盘；API 场景建议加上'notice'，方便捕获Undefined array key这类弱提示
异常处理最麻烦的从来不是怎么返回 JSON，而是怎么让不同来源的请求（小程序、H5、APP、定时任务）都拿到一致、安全、可定位的反馈——这得靠请求识别 + 异常分类 + 环境分级三者咬死，漏掉任何一环，日志和响应就会对不上。
