异步任务渲染错乱的本质是并发请求状态更新竞争，解决关键是用promise.all批量请求并一次性更新状态，避免循环中多次setstate；分页场景需用对象暂存已加载项；极端情况可加序号校验。
异步任务完成顺序不一致导致的渲染错乱，本质是多个并行请求返回时间不可控，而状态更新又未按原始顺序聚合或同步。这不是“快慢”问题，而是“谁先更新、谁覆盖谁”的竞争问题。解决关键在于切断无序更新链，统一用确定性方式组装结果。
避免在循环中多次 setState
这是最常见的根源。比如遍历 Pokémon 列表，对每个名字发起请求，并在每个回调里调用 setPokedex：
- 每次
setPokedex((prev) => [prev, data])都基于当前状态快照，但多个并发回调可能读取到同一个旧状态，导致部分数据丢失或顺序颠倒 - 正确做法是收集所有请求结果，等全部 resolve 后一次性更新：用
Promise.all批量请求，再用单次setPokedex - 示例：先获取 ID 列表，再
Promise.all(ids.map(id => axios.get(`/pokemon/${id}`)))，最后setPokedex(results.map(res => res.data))
用 Promise.all 替代分散触发
确保批量请求的结果顺序与输入顺序严格一致——Promise.all 的返回数组索引永远匹配传入的 Promise 数组索引：
- 不要把
Promise.all(data)写成Promise.all(data.map(...))，前者 data 是对象数组，会报错；后者才是正确用法 - 若需按名称请求，先构造 URL 数组：
const urls = names.map(name => `/pokemon/${name}`)，再Promise.all(urls.map(u => axios.get(u))) - 这样即使第 3 个请求比第 1 个慢，结果数组第 3 位仍是第 3 个名字的数据，顺序可保
引入 loading 状态 + 暂存中间结果
当无法一次性发完所有请求（例如分页加载或滚动加载），需用额外状态管理“已加载项”与“待加载项”：
- 定义
const [loadedItems, setLoadedItems] = useState({})，以 ID 为 key 存储已获取的数据 - 渲染时用
itemList.map(item => loadedItems[item.id] ?? <spinner></spinner>)，避免空值或错位 - 每个请求完成后只更新对应 key：
setLoadedItems(prev => ({ ...prev, [id]: data }))，不干扰其他项
必要时加唯一标识与校验逻辑
极端场景下（如服务端响应延迟差异极大、重试机制介入），可在响应体中携带原始索引或请求 ID：
- 请求时附带序号：
axios.get(`/pokemon/${name}`, { params: { seq: index } }) - 响应后检查
res.config.params.seq，仅当等于预期序号才更新该位置，否则丢弃或排队 - 适用于对顺序极其敏感的列表（如实时排行榜、日志流），但多数业务场景用前三种已足够
