Promise错误测试应使用expect().rejects断言，它自动等待并捕获拒绝、避免未处理警告、支持链式匹配，且能防止假通过；禁用toThrow()、手动try/catch等误用方式。
前端异步流程中 Promise 错误的集中测试，核心是让测试框架明确感知“预期失败”，并防止未处理 rejection 干扰结果。关键不在于分散捕获、手动 try/catch 或绕开异步机制，而在于用对断言方式，统一收口验证逻辑。
用 expect().rejects 替代手写错误捕获
这是 Jest 中最简洁、最可靠的方案。它自动等待 Promise 完成，内部已处理 rejection，不会触发 unhandledrejection 警告。
- 直接作用于 Promise 表达式或 async 函数调用，无需包装成函数再断言
- 支持链式匹配：比如
.rejects.toThrow('Network error')、.rejects.toBeInstanceOf(ApiError)、.rejects.toMatchObject({ code: 'TIMEOUT' }) - 如果 Promise 实际 resolve，测试会立即失败，避免“假通过”
避免常见误用写法
这些写法看似合理，实则无法正确验证异步错误，还可能掩盖问题：
-
expect(async () => { ... }).toThrow()：async 函数同步返回 Promise，永远不会同步 throw，断言永远失败 -
try { await fn() } catch (e) { expect(e).toMatch(...) }：冗余且易漏——若 Promise 拒绝但没进 catch（比如忘记 await），测试仍会通过 - 只写
fn().catch(...)却不 await 或不加 expect 断言：无法验证错误是否如预期发生
批量测试多个 Promise 错误场景
对一组相似的异步行为（如不同参数触发的 API 错误），可用数据驱动方式集中覆盖：
立即学习“前端免费学习笔记（深入）”；
- 用
test.each配合await expect(...).rejects，一次定义多组输入与期望错误 - 对并行请求，用
Promise.allSettled([...])包裹后断言每个结果的 status 和 reason，适合验证容错逻辑 - 模拟不同网络状态（超时、401、503）时，统一 mock 后集中断言拒绝原因，避免重复 setup
配合全局未捕获错误监听做兜底验证
在测试环境启用 window.addEventListener('unhandledrejection', handler)，可辅助确认所有 reject 都被显式处理：
- 测试前清空监听器、重置计数器；测试后断言未触发 unhandledrejection
- 适用于验证组件生命周期中隐式发起的 Promise（如 useEffect 内的 fetch），确保无遗漏
- 注意仅用于增强信心，主断言仍应基于
.rejects—— 它才是语义明确、可预测的测试手段
