Hyperf 不支持对已写入日志的错误状态批量修改，正确做法是在日志产生前通过自定义 Processor、全局异常处理器、日志采集层清洗或 AOP 注解等方式统一注入/标记状态字段。
Hyperf 框架本身不提供“错误信息状态的统一批量修改”这一功能，因为日志系统（如 Hyperf 的 Logger）本质是记录行为，而非状态管理器。所谓“批量修改错误信息状态”，通常不是对已写入的日志文件做变更（这既不安全也不推荐），而是指在日志产生前、或上报/消费环节中，对错误上下文进行统一增强、过滤、标记或转换。下面从实际可落地的几个方向说明如何实现类似目标：
1. 使用日志中间件或处理器统一注入/修改上下文
Hyperf 支持自定义 Processor（处理器），可在每条日志写入前动态添加、替换或删除上下文字段，比如为所有 ERROR 级别日志自动追加 "status": "unhandled"，或根据异常类型重写 message。
- 创建自定义 Processor 类，实现
Psr\Log\ProcessorInterface - 在
config/autoload/logger.php中注册到对应日志通道的processors配置项 - 在
__invoke方法中判断$record['level'] === Logger::ERROR，然后修改$record['context']或$record['message']
2. 统一异常处理 + 自定义日志记录逻辑
通过全局异常处理器（ExceptionHandler）拦截所有未捕获异常，在此处集中决定日志内容、级别、附加状态字段，再调用 LoggerInterface 写入——这才是真正可控的“批量干预入口”。
- 在
app/Exception/Handler/ExceptionHandler.php中重写handle方法 - 根据异常类名、HTTP 状态码、业务标识等规则，动态设置
status字段（如"status" => "payment_failed"） - 调用
$this->logger->error($message, [..., 'status' => $status, 'trace_id' => $this->tracer->getTraceId()])
3. 日志收集后端统一清洗与标注（推荐用于可观测性场景）
若需对“已产生的错误日志”做状态归类（例如将多个不同异常映射为同一业务状态 "order_timeout"），应在日志采集层（如 Filebeat、Fluent Bit）或后端分析系统（Loki + LogQL、ELK）中完成，而非回写原始日志文件。
- 在日志采集配置中添加条件判断和字段重写规则
- 例如：匹配
message =~ "timeout|circuit breaker open"→ 添加status="service_unavailable" - Hyperf 只需确保日志结构规范（如固定字段
exception.class、http.status_code），便于下游识别
4. 结合注解或 AOP 在关键方法打标
对特定业务方法（如支付、下单），可用自定义注解 + AOP 切面，在抛出异常时自动附加语义化状态，再交由统一异常处理器处理。
- 定义
@BusinessStatus("payment_failed")注解 - AOP 切面捕获异常后，从方法反射读取该注解值，并存入
Context或Coroutine::getContext() - 异常处理器从上下文中提取该状态，注入日志 context
不复杂但容易忽略：日志的“状态”不应依赖事后修改，而应从源头结构化生成。Hyperf 的灵活性在于你能控制日志从产生到落盘的每个环节，重点是把状态判定逻辑前置、收敛、可配置。
