应将异常分为业务错、系统错和验证错三类：业务错抛businessexception（400/422），系统错由中间件捕获打system_error标签，验证错单独设validate_error类并带scene字段。
接口异常没分清是业务错还是系统错？
ThinkPHP 默认把所有异常都往 AppException 或 HttpException 上堆，结果日志里全是 500 Internal Server Error，根本看不出是用户传了非法参数（该返回 400），还是数据库连不上（真要告警）。分类统计的前提，是先让错误「有身份」。
实操建议：
- 业务逻辑层主动抛出继承自
BusinessException的自定义异常（比如InvalidOrderException），HTTP 状态码设为400或422； - 系统层（DB、Redis、HTTP client）抛出的异常，统一由中间件捕获，打上
system_error标签再记录； - 别在控制器里用
try...catch吞掉所有异常——吞掉就没了链路，也分不清源头。
Log::record() 记不了调用链路？
直接调 Log::record() 写日志，确实能记下错误，但没上下文：谁调的？哪个 API？耗时多少？Trace ID 在哪？这类日志对分类统计基本没用。
实操建议：
- 在全局中间件（如
AppMiddleware）里用think\facade\Log的channel('api')写结构化日志，固定字段包括：trace_id、api_path、error_type（填business或system）、status_code； - 避免用
Log::info()混写成功/失败日志——失败日志必须走Log::error()，方便后续用日志系统按 level 聚合； - 别把整个
$e->getTraceAsString()往日志里塞，只取前 3 层调用栈 + 关键变量（如$orderNo），否则日志体积爆炸还难过滤。
怎么从日志里快速筛出「业务错误高频接口」？
分类统计不是为了好看，是为了定位问题。如果日志字段不统一、类型不明确，grep 或 ELK 查半天也分不清是登录校验失败多，还是支付回调超时多。
实操建议：
- 所有业务异常日志必须包含
"error_type":"business"和"api":"/api/v1/order/create"字段，用 JSON 格式输出（开启log.format = json）； - 用
awk或日志平台的聚合功能，按api+error_type分组计数，再筛出count > 100的接口； - 注意区分
401 Unauthorized和403 Forbidden：前者是 token 过期（可归为「认证类业务错」），后者是权限不足（属「授权类业务错」），统计时建议拆成两个子类。
TP6.1+ 的 think\exception\ValidateException 怎么归类？
验证失败抛的是 ValidateException，状态码默认 400，但它既不是纯业务逻辑错（比如余额不足），也不是系统错。直接扔进 business 类别会稀释真实业务问题的信号。
实操建议：
- 单独设一类
validate_error，和business、system并列，在日志 channel 中显式标注； - 在验证器里加
scene区分场景（如scene('create')），日志中带上validate_scene字段，方便知道是创建订单时参数错，还是修改地址时错； - 别复写
ValidateException的render()方法去改状态码——改了反而破坏语义，400 就是客户端数据问题，该是什么就是什么。
真正难的不是加几行日志代码，而是每次抛异常时，都要想清楚：这个错，是用户能改的，还是运维得立刻看的，还是开发得马上修的。字段少一个，分类就模糊一层。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
