Promise并未彻底解决异步问题，仅缓解回调地狱；不可取消、错误需显式处理、不支持同步/异步统一建模、语义单一难表复杂流。
Promise 并没有彻底解决所有异步问题，它只是让回调地狱（callback hell）变得更可控、更可组合，但依然存在明显局限。
无法取消已发起的 Promise
一旦 Promise 被创建并开始执行（比如发起一个 fetch 请求），就无法中途取消。即使后续不再需要结果，请求仍会在后台继续运行，可能浪费资源或导致状态不一致。
常见应对方式：
- 使用 AbortController 配合 fetch（不是 Promise 本身的能力，而是浏览器 API 的补充）
- 在业务逻辑层手动标记“忽略结果”，比如检查组件是否已卸载再更新状态
- 用 RxJS 等支持取消的响应式库替代原生 Promise
错误处理仍需显式关注
Promise 的错误不会自动冒泡到全局，未被 .catch() 或 try/catch 捕获的 rejection 会变成静默失败（现代环境会触发 unhandledrejection 事件，但不会中断流程）。
这意味着：
- 链式调用中漏写
.catch()就可能丢失错误信息 - async/await 中忘记用
try/catch，错误会直接抛出并终止当前函数执行 - 多个并行 Promise（如
Promise.all）中任一失败即整体失败，有时不符合需求（可用Promise.allSettled替代）
不支持同步/异步统一建模
Promise 总是异步执行 .then 回调（即使 resolve 同步值），这导致它无法自然表达“可能同步、可能异步”的操作（比如缓存命中时同步返回，未命中时异步加载）。这种模式在性能敏感场景（如 React 的 Suspense）中很重要，而原生 Promise 无法优雅支持。
替代思路：
- 用函数返回值区分：同步返回值 vs 返回 Promise
- 采用支持同步调度的抽象，如 Observable、Suspense 的 pending 状态机
- 某些库（如 SWR、React Query）内部封装了这类逻辑，对外隐藏 Promise 层级
语义单一，难以表达复杂异步流
Promise 表达的是“一个未来值”，适合一对一的异步任务。但它不擅长处理：
- 持续的数据流（如 WebSocket 消息、用户输入流）——更适合用 Observable 或 EventTarget
- 竞态控制（如搜索框防抖+取消上一次请求）——需额外逻辑协调多个 Promise
- 重试、超时、降级等策略组合——需借助第三方工具（如 p-retry、promise-timeout）或手写包装
Promise 是异步编程的重要基石，但它只是一个“单次、不可取消、不可中断”的容器。真正健壮的异步逻辑，往往需要它 + 控制机制 + 更高阶的抽象共同完成。
