Promise链中返回新Promise会自动等待其settled后再执行后续处理，本质是微任务排队而非线程暂停，返回值被Promise.resolve()包装决定下个.then()执行时机。
当在 Promise 链中返回一个新的 Promise 时，链式调用不会“暂停”或“阻塞”，而是**自动等待该 Promise settle（即 fulfilled 或 rejected）后，再继续执行后续的 .then() 或 .catch()**。这不是暂停与恢复的控制流机制，而是 Promise 的异步调度逻辑决定的自然行为。
返回新 Promise 会触发隐式等待
Promise 链中每个 .then() 回调的返回值会被 Promise.resolve() 包装。如果返回的是一个 Promise，链会自动等待它完成：
- 返回普通值（如字符串、数字）→ 下一个
.then()立即以该值为参数执行 - 返回一个 pending Promise → 下一个
.then()暂缓执行，直到该 Promise 变为 fulfilled，并以其 resolve 值为参数调用 - 返回一个已 reject 的 Promise → 下一个
.then()被跳过，转而进入最近的.catch()或后续的.then(null, rejectionHandler)
链中“等待”的本质是微任务排队
Promise 的执行基于 JavaScript 的事件循环和微任务队列。每次 .then() 注册的回调，都会被推入微任务队列。当一个 .then() 返回新 Promise 时：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 引擎不会阻塞主线程，而是记录“等它 settle 后再运行下一个处理器”
- 该新 Promise 内部的异步操作（如
fetch、setTimeout(Promise.resolve(), 0)）完成后，会向微任务队列添加对应回调 - 当前同步代码执行完，JS 引擎清空微任务队列，依次执行这些排队的
.then()回调
常见误解：不是“暂停线程”，而是“推迟回调注册”
有人误以为 return new Promise(...) 让链“卡住”了。实际上：
立即学习“Java免费学习笔记（深入）”；
- 整个链的构造（即连续写多个
.then()）是同步完成的 - 真正延迟的是某个
.then()回调内部返回的新 Promise 的 后续处理器的执行时机 - 你可以把链看作一张有依赖关系的任务图：每个节点是否运行，取决于前一个 Promise 是否已 settle
实用建议：如何清晰控制流程节奏
若需显式控制等待逻辑，推荐方式包括：
- 用
async/await替代长链，语义更直观（底层仍是 Promise 链） - 避免在
.then()中直接return fetch(...)而不处理错误；应接.catch()或用try/catch（配合 await） - 调试时可插入
.then(val => { console.log('reached', val); return val; })观察哪一步被延迟 - 注意不要在
.then()中忘记 return —— 不返回任何值等价于return undefined，会丢失上一步结果
