错误处理模式
将以下提示词粘贴到你的 AI 对话框中:
请根据 https://skillhub.cn/install/skillhub.md,安装 @org-02qudk26/error-handling-patterns。
技能介绍
生产里真正难的是「错了之后怎么办」
功能跑通只是起点。API 在超时、依赖宕机、并发竞态时如何不拖垮整条链路,错误信息能否让值班同学和调用方快速定位,往往比「Happy Path」更决定系统是否可运维。本技能面向的是:在新功能、对外接口和分布式场景里,把错误处理当成一等设计,而不是事后补 try/catch。
技能如何引导你落地
它会要求你先明确目标、约束和输入(例如是否允许重试、错误要对用户还是只对开发者暴露),再按常见模式给出可执行步骤与验证方式,而不是堆概念清单。覆盖方向包括:
- 设计具备错误弹性的 API 与更清晰的错误消息
- 重试与断路器等容错模式
- 异步 / 并发场景下的错误传播与处理
- 结合
resources/implementation-playbook.md中的详细模式与示例做对照实现
适用边界
若任务与错误处理模式无关,或需要的是其他领域工具(例如纯性能调优、与故障无关的安全合规),不必强行套用本技能。 playbook 负责深度示例;日常对话里以步骤和验证方法为主,避免只改文案不改行为。
使用场景
- 新功能开发阶段列出超时、校验失败、依赖不可用等路径,并约定错误码与日志字段
- 设计对外 API 时规定依赖返回 5xx 或超时的降级响应与调用方可解析的结构
- 生产 incident 中从堆栈与 correlation id 追踪异步回调或多 goroutine 并发下的失败起点
- 在服务间 HTTP/RPC 调用上配置重试退避与断路器阈值,防止单点故障拖垮下游
适合人员
- 维护对外 BFF 或 API 网关、需在第三方或内部依赖抖动时仍返回一致错误语义的后端工程师
- 承担 on-call、要把模糊 500 与明确业务拒绝区分开并缩短定位时间的平台或 SRE
- 用消息队列或 asyncio 编写集成流程、需统一异常传播与部分失败补偿逻辑的应用开发者
- 参与微服务拆分、希望跨服务错误格式与可观测性对齐的架构师或 tech lead