Promise.resolve：统一同步与异步逻辑的“粘合剂”
在Ja vaScript的异步编程世界里，Promise.resolve 扮演着一个看似简单却至关重要的角色。它的核心价值是什么？简单说，就是充当一个“标准化转换器”。无论你给它一个原始值、一个已经敲定的Promise，甚至一个错误，它都能将其统一包装成一个可链式调用的Promise实例。这样一来，同步逻辑和异步任务就能共享同一套 .then() 和 .catch() 的执行流水线，彻底告别繁琐的分支判断，让流程控制变得异常清晰。
用 Promise.resolve 包裹同步值，获得标准 Promise 行为
同步函数直接返回字符串、数字或对象？问题来了，这些原始值没法直接接上 .then() 进行链式调用。这时候，Promise.resolve(value) 就派上用场了。它会立刻返回一个状态为fulfilled的Promise，后续的链式处理就能顺理成章地进行。
- 处理普通值，比如
42、"ok"或{data: true}，Promise.resolve(42)会将其包裹，之后在.then(v => ...)里拿到的v就是原值。 - 即便是
null或undefined也照单全收，整个过程安全无报错，可以放心地融入执行链路。 - 这招也省去了手动写
Promise.resolve().then(() => value)这种冗余代码的麻烦。
统一处理可能同步、也可能异步的函数返回值
在实际开发中，我们常会遇到一些“两面派”函数：它们有时同步返回结果，有时却返回一个Promise。典型场景就是带缓存的工具函数——命中缓存时同步返回，未命中则发起异步请求。如何优雅地处理这种不确定性？Promise.resolve(fn()) 就是答案，它能完美抹平这种差异。
- 如果
fn()同步返回了"cached"，那么Promise.resolve("cached")会将其转为Promise，后面的.then正常执行。 - 如果
fn()返回的是fetch('/api')这样的Promise，Promise.resolve(fetch(...))会原封不动地传递它，不会产生额外的嵌套。 - 需要留意的是，对于已经确定是Promise的值，就没必要多次包裹了（比如
Promise.resolve(Promise.resolve(x))）。虽然无害，但显得多此一举。
配合 async/await 保持链路一致性（尤其在工具函数中）
当你封装通用的中间件或拦截器时，往往希望每一步处理都能同时兼容同步和异步操作。这时，用 Promise.resolve(...).then(...) 来构建统一的执行链，就成了最佳实践。
- 举个例子，一个权限校验函数可能这样定义：
const check = () => user.token ? true : Promise.reject('no token')。它可能返回布尔值，也可能返回一个拒绝态的Promise。 - 统一调用方式如下：
Promise.resolve(check()).then(() => fetchAPI()).catch(handleError)。无论check()给出的是布尔值还是Promise，整个链路都能畅通无阻。 - 这种方法，远比写
if (check() instanceof Promise) { ... } else { ... }这样的条件判断要简洁得多，而且彻底避免了漏判的风险。
小心陷阱：Promise.resolve 不捕获同步异常
这是关键所在，也是容易栽跟头的地方。Promise.resolve(fn()) 并不会自动捕获函数执行时抛出的同步错误。如果 fn() 内部直接 throw new Error('boom')，这个错误不会被自动转换为rejected状态的Promise，而是会作为一个同步异常直接抛出，打断当前的执行栈。
- ❌ 错误用法：
Promise.resolve(() => { throw 'err' })()—— 注意，这里只是把函数本身当作一个值包裹进了Promise，并没有执行这个函数。 - ❌ 危险写法：直接写
Promise.resolve(fn())，而fn内部有throw语句。这个同步错误会逃逸，无法被后续的.catch()捕获。 - ✅ 正确做法：要么用
try/catch手动包裹函数调用；要么考虑使用Promise.try（但这可能需要polyfill）；或者，一个更稳妥的写法是：Promise.resolve().then(() => fn())，这样就能确保fn中的异常被Promise机制捕获。
