企业官网建设流程全解析

先直接亮观点：Promise的静态方法，是你在ES6里最值得花一小时彻底搞懂的一组API。它不像then、catch那样每个用Promise的人都会写，但Promise.all、Promise.race、Promise.allSettled、Promise.any、Promise.resolve、Promise.reject这六个家伙，才是真正让你从“会用Promise”进化到“能设计异步流程”的分水岭。这篇文章我打算掰开揉碎讲清楚每个静态方法的行为、适用场景、典型代码，再把我这些年线上排查Promise相关报错的实录一并放出来，适合已经会用new Promise但一碰到多请求并发、竞态处理、批量任务就犯嘀咕的同学。

1. 为什么我劝你先搞懂Promise的静态方法

1.1 从实例方法到静态方法，到底差在哪

很多人学Promise的时候，最先接触的是new Promise((resolve, reject) => {...})，然后就是.then()、.catch()、.finally()。这些方法挂在Promise实例上，解决的是“单个异步任务完成后怎么收尾”的问题。但真实业务里，你不会只处理一个异步任务——你会有三个接口要并行请求、一个请求可能超时需要兜底、一批上传任务里有的成功有的失败但你全都要拿到结果。这时候只靠实例方法就捉襟见肘了，你需要的是“不依赖某个具体实例，直接对Promise做组合和加工”的工具，这就是静态方法存在的意义。

静态方法和实例方法一个更朴素的区别是：实例方法得先有一个Promise对象才能调用，比如promise.then(...)；静态方法直接用Promise.xxx()调用，它接收的是一组Promise（或者其他值），然后返回一个新的Promise给你。你不需要手动去new Promise，也不需要先声明一个变量接住前面的Promise——静态方法帮你把“多个异步任务的组织”这件事抽象出来了。这就像你手里有几条独立的流水线，实例方法是每条流水线末端的质检员，而静态方法是中央调度台，告诉你这些流水线是并行开、谁先出结果听谁的、还是等全部跑完统一汇报。

1.2 六个静态方法一张表看清楚

为了避免后面看晕，我先把六个方法的核心行为列出来，后面每个方法我都会单独展开。你可以把这张表当成索引，实操的时候拿不准了就翻回来看。

这张表里最容易被混淆的是race和any：一个是“第一个落地的说了算”，不管它是成功还是失败；另一个是“第一个成功的说了算”，只有全挂了才会失败。这个区别会在后面的代码里体现得非常明显。

2. Promise.resolve()和Promise.reject()：所有静态方法的地基

2.1 Promise.resolve()的四种传参行为

Promise.resolve()这东西看起来简单，实际上有四种传参情况，行为完全不一样。

第一种，传一个普通值，比如数字、字符串、对象。这时候它会返回一个立即成功的Promise，值就是这个普通值。这个很好理解，相当于帮你把同步值包成异步。

const p = Promise.resolve('hello'); p.then(res => { console.log(res); // 'hello' });

第二种，传一个thenable对象。所谓thenable，就是“有.then方法的对象”。知名的类库比如jQuery的$.ajax返回的对象、axios早期版本的适配器，都可能是一个thenable而不是标准Promise。Promise.resolve会把thenable转成真正的Promise，并且会调用它的.then方法，直到拿到最终值。

const thenable = { then(resolve, reject) { setTimeout(() => resolve('thenable resolved'), 1000); } }; Promise.resolve(thenable).then(res => { console.log(res); // 1秒后输出 'thenable resolved' });

这个行为特别实用，它意味着你可以在代码里统一用.then处理，不用管底层来源是标准Promise还是某个老库的thenable对象。我当年接手过一个老项目，里面有大量用jQuery Deferred写的异步逻辑，就是用Promise.resolve一层层包出去，新老代码才能无缝对接。

第三种，传一个Promise实例。如果传入的本身就是Promise，Promise.resolve不做事，直接把同一个实例返回。注意，这里返回的是同一个引用，不是复制品。有同学问过“那我用它来复制一个Promise行不行”，不行，你拿到的是同一个对象，对它调用then不会影响原来的Promise状态，但如果有多个地方引用了它，状态变化是共享的。

第四种，不传参。返回一个值为undefined的已成功Promise。这个通常用在需要“先做一个空异步，再链式往下走”的场景，或者写测试用例的时候当作一个干净的起点。

2.2 Promise.reject()的正确打开方式

Promise.reject(reason)就简单多了，它永远返回一个已失败的Promise，失败原因就是你传进去的reason。我看到很多初学者不太用它，觉得“我直接throw一个错误不就行了”，实际上它有两个无法替代的场景。

第一个场景是条件性失败。你想在某个同步逻辑里根据条件决定返回一个失败Promise，但你人又不在异步函数里，这时候用Promise.reject最干净。比如一个表单提交函数：

function submitForm(data) { if (!data.username) { return Promise.reject(new Error('用户名不能为空')); } return fetch('/api/submit', { method: 'POST', body: JSON.stringify(data) }); }

第二个场景是配合async/await做分支控制。你在async函数里有时候想提前终止，但不想用throw去影响外层错误处理链，可以直接return Promise.reject(...)。不过我一个个人体会是：在async函数内部，throw和return Promise.reject最终效果非常接近，但如果你在.then链里，用return Promise.reject比throw更直观，因为它明确表达了“这里要返回一个失败Promise”而不是“这里代码出bug了”。这两种写法在调试时的可读性差别很大。

另外有个细节：Promise.reject返回的Promise如果没有被catch接住，会在控制台输出一条Uncaught (in promise)错误。这不是说你的代码一定写错了，而是说你在某个地方构造了一个失败的Promise却没人处理。要不要“立即”给它加catch取决于你的场景，但绝对不能放任不管。

2.3 实操：用Promise.resolve()把回调接口改造成Promise

假设你有一个老版本的接口，还是回调风格的，比如微信小程序早期的wx.request、Node.js的fs.readFile。它们的共同点是最后一个参数是一个回调函数，成功和失败都在回调里通过参数区分。这种风格遇到多个任务要串行或并行的时候，写起来简直就是金字塔，所以第一步通常是把它包装成Promise。

function readFilePromise(filename) { return new Promise((resolve, reject) => { fs.readFile(filename, 'utf8', (err, data) => { if (err) { reject(err); } else { resolve(data); } }); }); }

这里用new Promise是可以的，但如果你只是想透传一个已有的Promise，或者想统一入口，用Promise.resolve更省事：

function loadConfig() { const config = runtimeCache.get('config'); // 有缓存就直接返回一个Promise，没有就去读取 return config ? Promise.resolve(config) : readFilePromise('/etc/config.json').then(JSON.parse); }

这样loadConfig的调用方永远都在处理Promise，不用关心数据是缓存来的还是磁盘读来的。一致性在异步代码里非常重要，Promise.resolve就是那个帮你把“同步值”和“异步Promise”统一到一个通道的粘合剂。

3. Promise.all()：并行等待的正确姿势

3.1 核心行为：要么全成功，要么快速失败

Promise.all()接受一个可迭代对象，通常是数组。数组里每个元素可以是Promise，也可以是普通值。普通值会被当成“已成功的Promise”自动处理。它返回一个新Promise，只有当数组里所有Promise都成功时，新Promise才成功，结果是一个数组，顺序和传入顺序完全一致；只要有一个Promise失败，新Promise立刻以那个失败原因失败，其他Promise的结果就被丢弃了。

我对初学者的建议永远是：先把这个“快速失败（fail-fast）”的语义刻在脑子里。Promise.all不是为了“等所有结果”而存在的，它是为了“所有条件都满足才继续”而存在的。你想想分布式事务里的一致性检查、表单里多个字段的格式校验、页面初始化要拿到多个接口数据才能渲染——这些都是“全有或全无”的场景，用Promise.all恰到好处。

“快速失败”还有个容易被忽视的点：它并不会终止其他Promise的执行。如果一个请求已经发出去了，就算Promise.all因为另一个请求失败而提前进入了catch，这个请求也不会被取消，它照样会在网络层跑完，只是结果没人处理了。很多人以为Promise.all失败后“其他请求也会自动中断”，这是一个很危险的误解，在移动端弱网环境下，这种场景会白白消耗用户的流量。

3.2 实操：并发请求多个接口并聚合数据

最常见的场景就是详情页需要同时请求用户信息、订单列表、优惠券信息，三个接口互相没有依赖，按道理应当并发发出去，而不是串行等一个再发下一个。

const [userInfo, orderList, couponList] = await Promise.all([ fetch('/api/user/info').then(res => res.json()), fetch('/api/user/orders').then(res => res.json()), fetch('/api/user/coupons').then(res => res.json()) ]);

这段代码里，三个请求是同时发出的，总耗时约等于最慢的那个接口，而不是三个接口耗时相加。用解构赋值把结果一一接住，代码也干净。这里有个关键点：fetch本身返回的Promise只有在网络层出错时才reject，HTTP状态码是404、500都不算reject，所以通常要包一层res.json()，如果后端返回的不是JSON，或者状态码异常，你需要在then里手动判断。

我这边的习惯是封装一个http方法，把状态码处理提前做掉：

async function http(url, options = {}) { const res = await fetch(url, options); if (!res.ok) { throw new Error(`HTTP error: ${res.status} ${res.statusText}`); } return res.json(); }

然后再用Promise.all去并发调用，错误的语义就清晰多了。否则你很可能遇到一个情况：接口返回了500错误，但你的Promise.all居然成功通过了，因为fetch完全不认为这是一个“Promise失败”。

3.3 踩坑记录：空数组、非Promise元素和失败调试

先说空数组。Promise.all([])返回的是一个立即成功的Promise，结果数组是[]。这个行为在逻辑上说得通——“对所有元素都成功了”这个命题，在空集上是真命题。但在业务里，如果你动态拼了一个接口列表，最后发现数组是空的，Promise.all不会报错，而是直接进入then，这时候你要小心业务逻辑会不会拿到空数组以后渲染出空白页面。

再说非Promise元素。Promise.all([1, Promise.resolve(2), 3])没问题，结果是[1, 2, 3]。但是如果你传入的数组里有对象，而这个对象碰巧有个then方法，那它会被当成thenable处理，而不是当成普通值。这个坑很隐蔽，尤其是你从某个接口拿到一组数据，数据里某个字段恰好叫then，比如{ then: '2024-01-01' }——这不是函数，所以没问题；但如果值是函数，就会出大问题。真实案例我见过一次，后端返回了一个对象数组，每个对象里有个retry方法，结果Promise.all误把它当成thenable，直接把整个流程搞乱了。所以传数组给Promise.all之前，最好确认里面是不是干净的数据。

失败调试这块，最大的痛点就是Promise.all拒绝后你拿不到其他成功的结果。Node.js 15之后原生支持了Promise.allSettled，在那之前，如果你既想要失败信息，又想要已经成功的那些结果，只能在每个Promise内部自己包一层，把成功和失败都转成同一个结构。等到了Promise.allSettled部分我会再展开讲。

4. Promise.race()和Promise.any()：竞速场景的两兄弟

4.1 Promise.race()：谁先落地谁说了算

Promise.race()的参数和Promise.all一样，都是数组。但它的语义完全不同：只要数组中任意一个Promise先进入settled状态（成功或失败都算），新Promise就以那个状态为准。剩下的Promise该跑还是会跑，但结果已经不重要了。

我第一次理解race的时候，是拿“赛马”来类比的：一堆马同时出发，谁先冲过终点线，谁就是冠军，不管后面那些马是跑完了还是摔倒了。这里的“终点线”就是settled状态，先到的那个决定了整个race的结果。

实际开发里，race最经典的应用就是超时控制。你发一个请求，正常要1秒，但你等不起，最多等3秒，3秒没返回就当超时处理。做法特别简单：把真实请求和一个定时器Promise放在一起赛跑。

4.2 Promise.any()：只要第一个成功

Promise.any()是ES2021进标准的，历史比race短，所以很多老项目的代码里没见过它。它的语义是：只要数组中有一个Promise成功，新Promise就成功，并且拿到第一个成功的结果；只有全部Promise都失败，新Promise才失败，失败原因是一个AggregateError，里面装着所有失败的原因。

继续用赛马类比，any不是“谁先过终点线谁赢”，而是“只要有一匹马最终没有摔倒，就算赢”。它关心的是成功，而不是先后。所以它特别适合“多点备份”的场景：你有多个数据源，任何一个能用就行，优先选最快返回成功的那个，而不是第一个落地的。

一定要记住race和any的区别，因为它俩太容易混了。race里如果第一个落地的是失败，那整个race就是失败；any里就算前面的都失败了，只要后面有一个成功，那整个any就是成功。一个是“第一个说了算”，一个是“第一个成功的说了算”。

4.3 实操：接口超时控制与多源切换

超时控制在移动端轮询、上传下载这些场景里非常实用。直接上代码：

function withTimeout(promise, ms, timeoutMessage = '请求超时') { let timer; const timeoutPromise = new Promise((_, reject) => { timer = setTimeout(() => reject(new Error(timeoutMessage)), ms); }); return Promise.race([promise, timeoutPromise]).finally(() => { clearTimeout(timer); }); }

用法：

try { const data = await withTimeout(fetch('/api/slow').then(res => res.json()), 3000); console.log('请求成功', data); } catch (error) { console.error('失败或超时', error.message); }

这里有几个细节值得注意。第一，finally里一定要clearTimeout，否则定时器还会留在事件循环里，万一Promise提前成功了，那个定时器到点还是会触发reject，虽然这时候race的结果已经定了，reject不会产生实际影响，但不清理定时器在大量请求的场景下会浪费内存和时间片。第二，超时后原始请求并没有被取消，它挂在后台继续跑，这是Promise机制决定的，如果你真的想在超时后断掉连接，得用AbortController，这个问题我们后面还会提到。

多源切换的场景，比如图片CDN，你配置了两家CDN地址，挂了就换另一家：

const urls = [ 'https://cdn1.example.com/logo.png', 'https://cdn2.example.com/logo.png' ]; const loadImage = (src) => new Promise((resolve, reject) => { const img = new Image(); img.onload = () => resolve(src); img.onerror = () => reject(new Error('图片加载失败: ' + src)); img.src = src; }); try { const availableSrc = await Promise.any(urls.map(loadImage)); console.log('使用可用地址', availableSrc); } catch (error) { console.error('所有CDN都挂了', error.errors); }

如果所有地址都加载失败，error.errors里是一个数组，你可以遍历拿到每个具体失败的原因，方便定位是哪一家CDN出了问题。这个体验是race给不了的，因为race在第一张图片加载失败后就直接进入catch了，它根本不会给你“换下一个”的机会。

5. Promise.allSettled()：不放弃任何一个任务

5.1 和Promise.all()的核心差异

Promise.allSettled()是ES2020进入标准的，它在很多场景下是比Promise.all更合适的选项。核心差异一句话就能说清楚：Promise.all关心“全部成功才继续”，Promise.allSettled关心“全部跑完没，跑完就汇报结果，不管成功失败”。

我来举个例子。你有一批数据要批量上报到服务器，这批数据里有几条可能格式不对，会失败。如果用Promise.all，只要第一条失败就会触发catch，你压根不知道其他几条到底上报成功没有。但是用Promise.allSettled，不管成功还是失败，它会等所有任务都结束，然后给你一个数组，里面每个元素长这样：

// 成功的条目 { status: 'fulfilled', value: '成功的结果值' } // 失败的条目 { status: 'rejected', reason: Error('失败的原因') }

所以allSettled返回的Promise是永远不会走到catch的——它只有fulfilled状态，它的“结果”里就包含了你需要处理的所有成功和失败信息。这个设计思路很巧妙：它不是帮你消灭错误，而是把错误也当成一种“结果”打包给你，让你统一处理。

从名字上也能看出来，settled是Promise生命周期里的一个阶段，表示“状态已经定了，是成功还是失败已经知道了”。所以allSettled就是“等所有Promise都到达settled状态”，它没有理由自己进入rejected状态。

5.2 实操：批量任务收集全部结果

批量校验用户上传的文件，比如有的文件太大、有的是空文件、有的格式不对，你是管理员，希望一次性列出哪些文件有问题、问题是什么，而不是遇到一个坏文件就中断整批任务：

const files = [ { name: 'a.jpg', size: 2048 }, { name: 'b.png', size: 0 }, { name: 'c.gif', size: 999999999 }, ]; function validateFile(file) { return new Promise((resolve, reject) => { setTimeout(() => { if (file.size === 0) { reject(new Error(`${file.name} 是空文件`)); } else if (file.size > 1024 * 1024) { reject(new Error(`${file.name} 超过大小限制`)); } else { resolve(`${file.name} 校验通过`); } }, 300); }); } const results = await Promise.allSettled(files.map(validateFile)); const successList = []; const failList = []; results.forEach((result, index) => { if (result.status === 'fulfilled') { successList.push(result.value); } else { failList.push({ file: files[index].name, reason: result.reason.message }); } }); console.log('成功项：', successList); console.log('失败项：', failList);

这样你在界面上可以同时展示“3个文件里2个失败，1个成功”，并且把失败原因列得清清楚楚。这是Promise.all做不好的事，因为它在第一个失败时就中断了，后续的文件根本不会进入执行列表。

还有一个组合技巧，Promise.allSettled可以配合Promise.all实现“部分失败但整体继续”的需求。比如你有一个总流程，其中步骤2允许失败但不影响整个流程，其他步骤必须全成功。这时候可以把步骤2包成allSettled，其他步骤正常放外面：

const mainFlow = await Promise.all([ step1(), Promise.allSettled([step2MaybeFail()]).then(results => results[0]), step3() ]);

这种写法的可读性比把整个流程拆碎要好得多。我自己的经验是，能用allSettled解决“收集全部错误”的问题，就尽量不要在单个Promise内部用try/catch，因为那样会把错误吞掉，维护的时候反而看不到完整上下文。

6. 静态方法组合实战：封装一个带超时的并发请求

6.1 需求拆解

静态方法单独用都很简单，真正让它们发光的是组合。我拿一个很常见的真实需求来做示范：封装一个fetchAllWithTimeout函数，实现“并发请求多个接口，整体超时限制3秒，超时后抛错，同时保留每个接口的独立结果”。

这个需求乍一看用Promise.all加Promise.race就能做，但拆开来看，有几个边界条件得想清楚：

1. 多个接口并行发起，不串行等待。
2. 整体超时3秒，3秒内所有接口返回则成功，否则算整体失败。
3. 既有Promise.all的“全部成功才继续”，又有Promise.race的“超时兜底”。
4. 超时后，那些还没返回的请求不能被忘记，最好能通过AbortController真正取消。

如果直接Promise.all包Promise.race，容易出问题，因为race会“吃掉”那个率先出现的超时错误，但它不能阻止其他接口继续跑，而且你拿到的错误信息里也不清楚是哪个接口超时了。如果反过来Promise.race包Promise.all，相当于“整体请求”和“定时器”赛跑，整体请求内部再做并发聚合。

我最后选定的方案是双层嵌套：里层用Promise.all做并发聚合，外层用Promise.race接超时控制，另外在超时触发时手动执行AbortController的abort，把还没完成的请求真正取消掉。下面就是完整代码。

6.2 完整实现与逐行讲解

function fetchAllWithTimeout(urls, timeoutMs = 3000) { const controller = new AbortController(); const timeoutError = new Error(`请求整体超时: ${timeoutMs}ms`); // 定时器Promise，到点就reject let timer; const timeoutPromise = new Promise((_, reject) => { timer = setTimeout(() => { controller.abort(); // 真正取消在途请求 reject(timeoutError); }, timeoutMs); }); // 并发请求：每个请求都支持signal const requestPromise = Promise.all( urls.map(url => httpWithSignal(url, controller.signal) ) ); // race：请求整体 vs 超时 const result = Promise.race([requestPromise, timeoutPromise]); // 无论哪种结果，清掉定时器，避免残留 result.finally(() => clearTimeout(timer)); return result; } async function httpWithSignal(url, signal) { const res = await fetch(url, { signal }); if (!res.ok) { throw new Error(`HTTP error: ${res.status} for ${url}`); } return res.json(); }

逐行解释一下关键点。

controller是AbortController的实例，它的signal可以传给fetch。一旦执行controller.abort()，所有挂着这个signal的fetch都会抛出一个名为AbortError的DOMException，这样一来，超时后你不会只是“假装失败”，而是真的把还在网络栈里飘着的请求掐断了，这在移动端省电省流量的效果很明显。

timeoutPromise内部做了两件事：一是controller.abort()取消在途请求，二是reject(timeoutError)让race感知到超时。注意顺序，先abort再reject，能保证fetch抛出的AbortError优先被对应的Promise捕获，避免出现“requestPromise已经reject”和“timeoutPromise也reject”在race里打架的情况。

requestPromise就是正常的Promise.all，它会把每一个URL映射成一个httpWithSignal任务。因为每个任务都传了controller.signal，所以一个abort()能同时取消所有在途请求。这个“一对多取消”的能力，是AbortController配合Promise.all组合出来的，单靠Promise静态方法做不到。

Promise.race把两个Promise放一起比赛，结果是“整体请求成功”或“整体超时失败”二者之一。最后用result.finally(() => clearTimeout(timer))确保定时器一定被清理。这里有个细节：finally返回的是一个新的Promise链，如果你在调用方用了await fetchAllWithTimeout(...)，finally不会吞掉前面race的结果和错误，它只是“路过”清理一下。

6.3 这个封装还能怎么改

这个封装不是唯一解，根据需求还可以变形：

如果把“整体超时”改成“每个请求单独超时”，那就不该在外层包一个race，而是应该每个请求自己用withTimeout包一层，再放进Promise.all。两者在并发场景下行为差异很大：整体超时意味着“3秒内必须全部完成”，单独超时意味着“每一个最慢不能超过3秒，但总的可能拖到6秒、9秒”。根据业务语义选对才不容易埋雷。

如果还想拿到部分成功的结果，把Promise.all换成Promise.allSettled，再加一个超时race，就变成了“超时前能返回多少算多少，全部结果（含失败）都收集”。这种混合赛道的设计在实际项目里特别常用，尤其适合那些“能取到一部分数据也能展示半成品页面”的弱一致性场景。

组合使用的时候，核心原则就一句话：先明确你要的是“全部成功才继续”、“第一个出现就生效”还是“收集所有状态”，再选对应的静态方法。不要一上来就套Promise.all，很多场景其实用allSettled更稳。

7. 常见错误排查实录：Promise报错别再慌

7.1 Uncaught (in promise)到底是怎么来的

浏览器控制台出现Uncaught (in promise) Error: ...，核心原因就一个：某个Promise被reject了，但是没有任何catch或者then的第二个参数去接住这个失败。这种错误有时候不是你自己写的Promise，而是某个库内部产生的，排查起来更麻烦。

最常见的处理方式是，给整个Promise链末尾加一个catch。但在async/await时代，很多人会忽略一点：await后面的Promise如果reject，错误是由外层try/catch接住的，如果你忘了try/catch，引擎会把这个rejection当成未处理的异步错误抛到全局，同样会在控制台打出Uncaught (in promise)。

我见过不少同学调试的时候一直盯着报错的位置看，其实那个位置只是“错误被抛出”的位置，真正的问题可能在上游某个Promise.reject或者throw。排查这种错误，建议先看完整堆栈，再往上游回溯是谁先reject的。

如果你确实想在全局兜底，浏览器里可以监听unhandledrejection事件：

window.addEventListener('unhandledrejection', event => { console.error('未处理的Promise拒绝：', event.reason); // 这里可以上报监控系统 });

这个事件在开发调试和线上监控里都很有用，但不要把它当成“错误处理方案”，它只是“最后的警报器”。正确做法永远是在业务代码里为每个Promise链提供明确的错误处理分支。

7.2 Promise.all失败后，其他请求还在跑吗

这个问题我在前面提到过，但值得单独拿出来再说一遍，因为问的人实在太多。答案是：还在跑。Promise.all一旦因为某个请求失败而进入rejected状态，它对其他请求没有任何“取消”能力，其他请求照常进行，只是它们的结果不会被Promise.all接收了。

举个例子，你用了Promise.all发三个请求，第二个请求1秒后失败，第三个请求是个慢接口，5秒后才返回。从第1秒开始，你的await Promise.all(...)就已经抛错了，但第三个请求直到第5秒才在网络层面结束。在这个过程中，用户可能已经看到了错误提示，但流量还在消耗。

如果你希望失败后能“阻止”其他请求，最直接的办法是用AbortController：把同一个signal传给所有请求，然后在catch里调用abort()。前面fetchAllWithTimeout里已经展示了这个模式。如果你的请求用的是axios，它同样支持signal参数，底层也遵循AbortController标准。

所以结论是：Promise本身没有“取消”的概念，要取消得借助AbortController。搞清楚这一点，你在设计“失败的兜底逻辑”时就不会只做表面功夫，而是能真正做到资源的精准释放。

7.3 fetch传JSON的Content-Type坑

fetch发送JSON数据时，一个非常常见的报错就是后端返回415 Media Type Not Supported，或者后端收到了请求但req.body是空的。绝大多数原因是你忘了设置Content-Type: application/json。

// 错误示例 fetch('/api/submit', { method: 'POST', body: JSON.stringify({ name: '张三' }) }); // 正确示例 fetch('/api/submit', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ name: '张三' }) });

很多同学问我，为什么body都转JSON字符串了，后端还说他收到的不是JSON？因为fetch不会根据你的body自动推断Content-Type，你不设置，浏览器可能默认发text/plain;charset=UTF-8，后端一解析就傻眼了。这是fetch和axios一个很大区别：axios如果data传的是对象，它会自动帮你JSON.stringify并设置Content-Type；fetch全得手动来。

还有一个容易被忽略的点：跨域请求时，设置了Content-Type: application/json会触发预检请求（OPTIONS），有些后端没处理好OPTIONS就会直接拒绝。如果遇到“OPTIONS请求报404/500”或者“POST请求失败但GET正常”，十有八九是预检没通过。排查思路是先看Network面板里有没有OPTIONS请求，再看它的响应状态码。

7.4 用户操作引发的Promise拒绝：play()报错案例

Promise.reject不一定来自代码内部，也可能来自一个用户行为。最典型的就是音频、视频播放的HTMLMediaElement.play()方法。它返回一个Promise，但在移动端浏览器里，如果用户没有先和页面进行交互（比如第一次点击页面就自动播放），浏览器会拒绝这个Promise，控制台就会报：

NotAllowedError: play() failed because the user didn't interact with the document first.

这种错误你处理不当，就会出现“点击播放按钮没反应，控制台还有一大片报错”的情况。正确做法是给play()的返回Promise加catch，并在catch里提示用户需要手动点击一次：

async function playVideo(videoEl) { try { await videoEl.play(); } catch (error) { if (error.name === 'NotAllowedError') { // 提示用户点击播放按钮 showToast('请点击播放按钮开始播放'); } else { console.error('播放失败', error); } } }

这个案例本质上还是在讲同一件事：任何可能reject的Promise，都必须有一个处理失败的姿势。不管是play()、fetch、Notification.requestPermission()还是其他浏览器API，只要它返回Promise，你就要考虑reject分支。把这些API的Promise当成“必定可能失败”来对待，就不会有那么多漏网之鱼了。

8. 静态方法选型速查：看完直接抄

挑方法的时候，先问自己一个问题：失败到底是不是你这个流程的“终态”？如果是，用Promise.all；如果失败只是结果的一部分，你还想继续处理其他数据，用Promise.allSettled；如果只是想拿到“第一个能用的”，用Promise.any。问完这个问题，选择基本就出来了。

最后再分享一个小技巧。我排查Promise问题的时候，习惯在catch里用一个统一日志函数，把错误对象、调用栈、当前URL、用户标识全部打出来，发到监控后台。这个习惯帮我在线上环境抓住过好几次用户反馈“页面打不开”但本地复现不了的问题——那些问题几乎全是某个第三方接口偶发超时，而我的代码又没有做超时兜底。你去看一下线上的unhandledrejection日志，基本都能找到几处漏网的Promise错误。把静态方法用熟练，不是为了炫技，而是为了让你在设计异步流程的时候，脑子里天然带着一张“全或零”、“竞速”、“收集结果”的地图，少踩几个坑。