3个坑搞定壁纸王者荣耀手写实现

报错一堆看不懂 StackTrace？别慌，这行代码里藏着 90% 前端面试的“壁纸王者荣耀”级难题。今天咱们不背八股文，直接上手手写实现，把那些让你抓狂的异步流控、状态管理一次拆解干净。

定位与痛点：为什么是“壁纸王者荣耀”

在编程圈，有个梗叫“壁纸级难度”，指的是那些看似简单、实则细节魔鬼的场景。比如给一个“王者荣耀”风格的游戏加载器写状态机，或者处理高并发下的资源加载队列。很多开发者一看到 unhandled promise rejection 或者 Maximum call stack size exceeded 就头大，其实核心就两点：时序控制和状态隔离。

咱们要对比的，是三种常见的手写实现方案：

原生 Promise 链式调用：轻量，但回调地狱容易失控。
async/await 封装：代码直观，但错误处理容易遗漏。
状态机模式（FSM）：最稳健，适合复杂业务流程，但样板代码多。

为什么选这三个？因为它们在中小项目里最常用。你去看 NPM 上的 async-validator 或 PyPI 上的 celery，底层逻辑都逃不出这个框架。今天咱们就用一个“加载游戏壁纸”的场景，把这三者拉出来溜溜。

核心差异：一张表看清本质区别

别光看代码，先看懂底层逻辑。下面这张表是面试时可以直接抄的“作弊条”：

维度	Promise 链	async/await	状态机 (FSM)
可读性	低，嵌套深时难读	高，像同步代码	中，需理解状态流转
错误处理	需层层 `.catch`	需外层 `try/catch`	统一在 `error` 状态处理
并发控制	需手动管理 Promise.all	易写成串行，需并发封装	天然支持并发分支
调试难度	高，堆栈追踪混乱	中，堆栈较清晰	低，状态日志可追溯
适用场景	简单线性流程	中等复杂度业务	复杂交互、多分支流程

重点来了：很多新手用 async/await 时，喜欢把串行写成并行，或者把并行写成串行。比如加载 3 张壁纸，你以为 await 了三行就是并行，其实它是串行的！这就是为什么 StackTrace 里全是 await 导致的阻塞。

代码写法对比：手写实现实战

咱们用 TypeScript 写，因为类型检查能帮你少踩坑。场景：加载“王者荣耀”角色的 3 张壁纸，要求并发加载，任意一张失败则整体失败，成功后更新 UI 状态。

方案一：Promise 链（反面教材，但必须懂）

function loadWallpapersPromise(urls: string[]): Promise<void> {return urls.map(url => fetch(url).then(res => res.blob())).reduce((prev, curr) => prev.then(() => curr), Promise.resolve()).then(() => console.log("All loaded"));
}
// 问题：.reduce 这里是串行的！并发加载用 .then 链是错误的。
// 正确并发应该用 Promise.all，但错误处理会变得非常复杂。

点评：这种写法在面试中如果直接甩出来，基本挂。因为 .reduce 配合 .then 是串行执行，违背了“并发加载”的需求。而且一旦某个 fetch 失败，后续的 then 都不会执行，且没有统一错误出口。

方案二：async/await（推荐入门，但需避坑）

async function loadWallpapersAsync(urls: string[]): Promise<void> {try {// 关键：Promise.all 实现并发const results = await Promise.all(urls.map(url => fetch(url).then(res => {if (!res.ok) throw new Error(`Failed to load ${url}`);return res.blob();})));console.log("All loaded", results.length);} catch (error) {// 统一错误处理console.error("Loading failed:", error);throw error;}
}

点评：这是最平衡的方案。Promise.all 确保并发，try/catch 确保错误不逃逸。但注意，Promise.all 是“快速失败”策略，只要一个挂，全部 reject。如果需要“尽力而为”（加载成功的保留，失败的标记），就得用 Promise.allSettled。

方案三：状态机模式（进阶，面试加分项）

enum State {IDLE, LOADING, SUCCESS, ERROR
}interface WallpaperState {state: State;progress: number;error?: string;
}class WallpaperLoader {private state: WallpaperState = { state: State.IDLE, progress: 0 };private listeners: ((state: WallpaperState) => void)[] = [];subscribe(listener: (state: WallpaperState) => void) {this.listeners.push(listener);}private setState(partial: Partial<WallpaperState>) {this.state = { ...this.state, ...partial };this.listeners.forEach(l => l(this.state));}async load(urls: string[]) {this.setState({ state: State.LOADING, progress: 0 });try {const total = urls.length;let loaded = 0;// 并发加载，但通过回调更新进度await Promise.all(urls.map(url => fetch(url).then(res => {if (!res.ok) throw new Error(url);loaded++;this.setState({ progress: loaded / total });})));this.setState({ state: State.SUCCESS });} catch (err: any) {this.setState({ state: State.ERROR, error: err.message });}}
}

点评：代码多了，但状态可观测。UI 层可以订阅 progress 渲染进度条，订阅 state 切换按钮禁用状态。这在“壁纸王者荣耀”这种需要实时反馈的场景里，比 async/await 更可控。

适用场景与避坑指南

什么时候用哪个？

Promise 链：除非你在维护老代码，否则新项目别用了。它只适合 2-3 步的简单流程，比如 getConfig().then(data => save(data))。
async/await：90% 的业务场景首选。特别是当逻辑是“先 A 后 B，B 依赖 A 的结果”时，await 的线性思维最省心。
状态机：当你的流程有分支、重试、回滚需求时。比如加载壁纸失败后，用户点击“重试”，或者加载中可以“取消”。async/await 处理取消很麻烦（需要 AbortController），而状态机里 CANCEL 就是一个状态。

避坑：StackTrace 看不懂的真相

你看到的 TypeError: Cannot read properties of undefined (reading 'then')，90% 是因为：

fetch 返回的 Promise 没有 .then 方法？不可能，是你在 map 里返回了 undefined。
async 函数忘了 return，导致外层 await 得到 undefined。
最常见：在 Promise.all 的数组里，混入了非 Promise 值。比如 urls.map(url => fetch(url)) 中，如果 urls 是空数组，Promise.all([]) 会立即 resolve，没问题；但如果 urls 里混了 null，就会炸。

调试技巧：在 catch 块里，打印 error.stack。如果堆栈很乱，用 console.trace() 打印当前调用栈，定位到具体哪一行 await 出了问题。

选型建议与面试话术

作为技术选型顾问，我给中小团队的建议是：

默认用 async/await：团队上手快，代码易维护。配合 Promise.allSettled 处理并发失败，比 Promise.all 更健壮。
复杂交互上状态机：如果页面有“加载-失败-重试-取消”等多状态切换，别硬用 if/else 堆状态变量，写一个简单的 FSM 类，或者用 xstate 这样的库（NPM 下载量 100k+/周，可信度高）。
别过度设计：别为了“手写实现”而手写。如果场景简单，Promise.all 加个 try/catch 就够了。面试时，先说你的默认方案，再讲极端场景下的优化，这才是老手思维。