错误反馈闭环需捕获、分类、处理、透出、监控五环节连贯运作；捕获须确保await在try内并手动检查http状态与业务code；分类需区分网络层与业务层错误；处理按核心/非核心路径决定降级或中断；透出需调用方兜底+全局监听双保险。
try-catch 本身不构成闭环，它只是错误捕获的起点。真正的错误反馈闭环，需要从“捕获 → 分类 → 处理 → 透出 → 监控”五个环节连贯运作，缺一不可。
捕获：必须让 await 落在 try 块内
await 不是魔法开关，它只对 Promise 的 reject 状态敏感。如果 fetch 成功但返回 500，或 JSON 解析失败，或业务 code !== 0，这些都不会自动进 catch——必须手动检查并 throw。
- ✅ 正确：先 await fetch()，再检查 res.ok，再 await res.json()，最后校验 data.code，每一步异常都落在 try 内
- ❌ 错误：fetch() 写在 try 外、漏 await、在 forEach 中直接 await（语法上无法捕获）
- ⚠️ 注意：async 函数返回 Promise，内部 try-catch 不会阻止这个 Promise 被 reject；调用方仍需处理返回值
分类：区分网络层与业务层错误
同一段错误日志里混着 TypeError、HTTP 401、code: 1002，根本没法定位问题。必须分层判断、分别构造错误类型：
- 网络层错误：fetch 抛出的 TypeError、res.ok 为 false、res.status ≥ 400 → 用原生 Error 或自定义 NetworkError 包装
- 业务层错误：data.code !== 0、data.success === false、字段缺失 → 用 BusinessError 包装，附带 message、code、traceId
- 不建议统一 return {} 或静默吞掉，否则上层无法区分“没数据”和“请求超时”
处理：按重要性决定是否降级，而非统一兜底
不是所有错误都要“友好提示+默认值”，关键路径该中断就中断，非核心模块才降级：
- 登录、支付、提交表单等核心流程：出错必须透出，让用户重试或跳转错误页
- 头像加载、推荐列表、埋点上报等非核心：可 fallback 到缓存、占位图、空数组，或 fire-and-forget 式重试
- 并行请求优先用 Promise.allSettled()，各路结果独立判断，避免 all 一错全停
透出与监控：调用方兜底 + 全局监听双保险
内部 try-catch 是局部防御，不是终点。错误最终要能被业务层感知、被开发者看见：
- 事件处理器中调用 async 函数，必须显式 .catch() 或外层加 try-catch（如 button click 里 await + try）
- React useEffect 中不能直接 await，应封装成函数并在 useEffect 内调用后 .catch()
- 全局监听 unhandledrejection，仅用于日志上报（如发送 Sentry），不可替代主动捕获
- 关键错误建议携带 context（如当前页面、用户 ID、请求参数简写），方便回溯
