在异步函数中，await 必须置于 try 块内才能捕获 promise 拒绝；需区分网络层（如 res.ok、status）和业务层（如 data.code）错误并手动 throw；关键流程应透出错误，非核心模块可降级；调用方仍需处理返回 promise 的拒绝。
在异步函数中用 try-catch 捕获错误，关键不是“加了就行”，而是让 await 真正落在 try 块内，并区分错误来源、明确处理意图。否则容易漏掉业务失败、掩盖真实问题，甚至让错误静默逃逸。
await 必须写在 try 块里才有效
async 函数本身返回 Promise，但 try-catch 不会自动包裹整个函数体——它只捕获 同步抛出的异常 和 被 await 的 Promise 被 reject 时触发的错误。
- ✅ 正确：await 在 try 内，fetch 失败、JSON 解析出错、status 非 200 后手动 throw，都能进 catch
- ❌ 错误：把 fetch() 写在 try 外，或漏写 await（得到的是 pending Promise，不触发 reject）
- ❌ 错误：在 forEach 或 map 中直接 await，因语法限制无法正确捕获，应改用 for...of 或 Promise.all
网络层和业务层错误要分开判断
fetch 成功不代表逻辑成功。res.ok 为 false（如 401、500）、响应体中 code !== 0，这些都不是 JS 异常，await 不会自动进 catch，必须手动检查并 throw。
- 先检查
if (!res.ok) throw new Error(`HTTP ${res.status}`) - 再
const data = await res.json()，此处可能 SyntaxError - 最后检查
if (data.code !== 0) throw new BusinessError(data.message)
按业务重要性决定是否降级，而不是统一吞掉
不是所有错误都该在底层 catch 后返回默认值。核心流程（如支付提交、登录验证）出错应透出，让用户感知并重试；非核心模块（如头像加载、推荐列表）才适合局部降级。
- ✅ 推荐：每个关键请求单独 .catch() 或 await + try-catch，失败时返回空数组、占位图或缓存值
- ❌ 避免：在公共请求函数里对所有错误统一 return {}，导致上层无法区分 404 和超时
- ✅ 并行请求优先用
Promise.allSettled，各请求可独立走自己的降级逻辑
调用方仍需兜底，内部 try-catch 不是终点
async 函数内部有 try-catch，只代表它自己处理了错误，但最终返回的 Promise 仍可能被 reject（比如 catch 里 re-throw，或没 catch 到的错误）。调用它的代码，比如按钮点击事件、React useEffect，仍需处理这个 Promise 的拒绝。
- 事件回调中调用 async 函数，建议加 .catch() 或顶层 try-catch
- 全局未捕获的 Promise 拒绝可用
unhandledrejection监听，仅用于日志上报，不可替代主动处理 - catch 块中别直接 throw 新错误覆盖原始堆栈，如需传递，可用
err.cause = originalErr保留上下文
