await 不处理数据验证错误，需开发者主动编写验证逻辑并在 await 后、使用数据前执行；验证失败应主动 throw 错误以被 try/catch 捕获，或封装进 promise 链、用 zod/yup 校验、safeawait 工具函数统一处理，避免静默忽略业务层验证。
await 本身不处理数据验证错误，它只等待 Promise 完成或失败；验证逻辑必须由开发者主动编写，并在 await 后、使用数据前执行。
验证失败时主动抛出错误
这是最直接的方式：拿到响应后，检查数据结构或业务规则，不符合就 throw 新错误。这样能被外层 try/catch 捕获，统一走错误流程。
- fetch 成功但接口返回 { code: 400, msg: "参数错误" }，需手动判断 code !== 200 并 throw
- 解析 JSON 后发现缺少必要字段（如 data.user.id），可 throw new Error("用户ID缺失")
- 数值范围校验失败（如 age = -5），立即中断后续逻辑并报错
把验证逻辑封装进 Promise 链
在 await 的 Promise 内部完成验证，让错误自然冒泡到 await 层，避免调用方重复写 if 判断。
- 写一个 fetchWithValidate(url) 函数，内部 fetch → checkStatus → .json() → validateSchema，任一环节失败都 reject
- 使用 Zod 或 Yup 做运行时类型校验，校验失败时 throw，配合 await 自动捕获
- 示例：const user = await fetch('/user').then(r => r.json()).then(validateUserSchema)，其中 validateUserSchema 是校验函数，失败则 throw
结合 safeAwait 封装实现“验证即返回”
用类似 to() 或 safeAwait 的工具函数包裹带验证的异步操作，返回 [error, data]，调用方用 if (err) 分支处理验证失败。
- 封装时可在 resolve 后插入校验步骤，校验失败时 return Promise.reject(new Error("邮箱格式非法"))
- 这样 await safeAwait(validateEmailAsync(input)) 得到的 err 可能是网络错误，也可能是邮箱校验失败，语义清晰
- 比层层 if (res?.code !== 200) 更扁平，也比每个地方写 try/catch 更轻量
避免静默忽略验证失败
常见陷阱是只检查网络层是否成功，却跳过业务层验证，导致无效数据流入后续逻辑。
- 不要仅依赖 response.ok，还要看 data.code、data.success 等业务字段
- 不要在 .json() 后直接解构，先确认 data 是否为对象、是否有 required 字段
- 日志中明确区分：是“请求失败”还是“响应成功但数据不合法”，便于排查
