别让 new Promise 滥用搞坏你的代码，聊聊 Promise.resolve 的正确姿势

经常重构旧项目的朋友可能都见过这种写法：明明可以直接返回值，非要在外层套一层 new Promise。不仅代码臃肿，还容易引入多余的异步等待。其实，很多时候 Promise.resolve 就能完美替代这种冗余操作，它不仅仅是语法糖，更是处理异步流程标准化的利器。

想象一下这个场景。你维护一个老函数库，有的接口直接返回数据对象，有的接口返回 Promise 实例。下游调用者为了统一处理结果，不得不反复判断类型，写一堆复杂的同步异步切换逻辑。这时候，Promise.resolve(value) 的作用就凸显出来了。无论传入的是普通值、已完成的 Promise，还是类似 Promise 的 thenable 对象，它都能统一转换为一个新的 Promise 状态。

这不仅仅是简化代码行数的问题，更关乎微任务队列的执行效率。当你在高频调用的场景下（比如列表渲染或轮询），手动 new Promise 会强制创建一个新的 Promise 实例和对应的回调上下文。而 Promise.resolve 内部做了优化，如果传入的值本身就是一个 Promise，它会直接返回该对象，避免不必要的包装开销。虽然单次差异不大，但在循环成千上万次的数据流中，累积的性能损耗不容忽视。

不过，这里有个容易被忽视的陷阱。很多新人以为 Promise.resolve 只是把值包起来而已，实际上它对thenable 对象有特殊处理。如果你传递一个包含 then 方法的对象，Promise.resolve 不会把它当成普通值，而是会立即去执行它的 then 方法，并将其解析结果作为最终结果。这意味着如果你的对象恰好有同名的 then 属性但并非 Promise 规范，可能会导致意外行为。在定义业务模型时，避免将普通字段命名为 then 是个好习惯，否则在依赖 Promise.resolve 解构返回值时，可能会陷入无限递归或者状态不一致的 Bug 中。

再深入一点，关于错误处理的边界。有些人误以为 Promise.resolve 也会捕获错误，其实不然。它只负责“成功”路径的标准化。如果在 thenable 对象的方法里抛出异常，这个异常依然会在后续的 .catch 链中被捕获，而不是在 resolve 阶段被吞掉。理解这一点，能帮你省去很多调试异步链路时的困惑。当我们在构建通用的工具函数，比如请求拦截器或数据处理器时，使用 Promise.resolve 作为入口，能保证所有出口的逻辑分支一致，后续无论是 .then 取数还是 .catch 兜底，链条都不会断裂。

写代码的终极目标是降低认知负荷。Promise.resolve 存在的意义，就是让异步和非异步的代码在处理层面上看起来一样。它不需要你关心底层如何排队，也不需要你手动管理状态机。在日常开发中，当你准备手写 return new Promise(resolve => resolve(data)) 这种包裹型代码时，停下来想想，是不是一个 Promise.resolve(data) 就能解决？少几行样板代码，多一分运行效率，这才是优雅异步编程的精髓所在。