用途：在 API 或应用中实现或重构错误处理，用户提出“error handling”“如何处理错误”“统一错误”等需求，或审查代码的失败处理、定义服务或 API 的错误契约时启用。核心原则是快速失败、不吞错、使用结构化错误，并区分面向用户与面向开发者的信息。
主要能力与工作流程：先识别错误来源与处理边界（校验、数据库、外部 API、认证；路由处理、中间件、顶层），确保每层要么处理要么携带上下文向上传播；定义错误结构，API 使用 HTTP 状态 + 响应体（code、message、可选 details），代码使用错误类或结果类型；将错误映射到 HTTP，校验→400 或 422，认证→401，授权→403，未找到→404，冲突→409，服务端→500，错误时不用 200；响应前先记录带上下文（请求 id、操作）的日志，再返回对用户安全的响应；在 API 边界用 Zod、Pydantic 等做校验与清理，返回一致的字段级校验错误。
API 错误响应采用统一信封：error 对象含机器可读的 code（如 validation_error、not_found、rate_limit_exceeded）、可安全展示的 message、可选的 details（校验时列出字段级错误，通用 500 可省略），可选 request_id 或 trace_id。推荐使用类型化错误类（如 NotFoundError），调用方通过 instanceof 判断并映射状态码；较低层抛出或返回 Result，由路由处理器或中间件捕获并映射为 HTTP 加日志，不在每层捕获。异步使用 try/catch 并确保 promise 拒绝被处理。
日志：失败需关注用 error 级别，可恢复（重试、回退）用 warn；记录消息、错误类型、堆栈（仅服务端）、request_id，不记录密钥或完整个人身份信息，只在处理边界记录一次，避免每层重复。
规则与限制：优先匹配项目现有模式，否则引入最小一致模式并文档化；不得向最终用户暴露堆栈、数据库错误、文件路径，仅服务端记录；校验错误返回 400/422 及字段级细节而非 500。反模式包括：用 200 加 success: false 表示错误、空 catch、记录完整请求与响应、向客户端暴露堆栈、每个端点使用不同错误结构。资料未提供具体安装命令、平台或收费信息。