回调无并发控制，需手动实现；Promise支持组合但无背压与取消；响应式流通过请求驱动、取消传播和内置算子实现精细并发调控。
回调、Promise 和响应式流（Reactive Streams）都用于处理异步操作，但在并发控制能力上差异显著——核心不在“能否异步”，而在于“能否精细调度、背压管理、资源复用与取消传播”。
回调：无内置并发控制，依赖手动协调
回调本身不提供任何并发语义。它只是“操作完成时通知你”的机制，所有并发逻辑（如限制同时发起的请求数、排队、超时、取消）必须由开发者自行实现。
- 无法天然表达“最多并发 3 个 HTTP 请求”，需配合计数器、队列（如 async.queue）、或手写状态机
- 没有统一取消机制：若请求已发出但回调未执行，通常无法中止底层 I/O（如 Node.js 的
fs.readFile不支持取消；fetch 在浏览器中才支持 AbortSignal） - 错误分散、流程断裂：每个回调需独立处理失败，难以统一熔断、重试或降级
Promise：支持基本组合，但缺乏运行时流控能力
Promise 解决了回调嵌套和错误冒泡问题，通过 Promise.all、Promise.race、Promise.allSettled 等可表达并行/竞争语义，但它仍是“单次交付”的抽象——一个 Promise 只 resolve 或 reject 一次，不支持多值、取消传播或背压。
构建 Shopify 嵌入式应用（Embedded App）的开发技能：基于 @shopify/shopify-app-react-router + React Router v7 + Admin API 2026-04。覆盖 shopifyApp 配置、authenticate.admin 的 GraphQL/REST 调用、Webhook 校验、Session 存储、订阅计费、App Bridge 导航、部署，并新增：适用场景判断、安全最佳实践、错误处理与容错、最佳实践、常见问题 FAQ、高级场景。G
-
Promise.all会同时触发全部异步操作，无法限流；若需“每次最多 2 个请求”，必须借助额外工具（如 p-limit、p-map）包装 - 原生 Promise 不支持取消：
Promise.prototype.cancel()从未进入标准；虽有AbortSignal可配合 fetch 使用，但属于外部协作机制，非 Promise 自身能力 - 无背压：无法告知上游“我处理不过来了”，下游过载时只能丢弃或崩溃（如快速生成 1000 个 Promise 导致内存飙升）
响应式流（Reactive Streams）：面向流的并发控制系统
响应式流（如 Java 的 Project Reactor、RxJava，JS 的 RxJS、xstream）将异步数据建模为“可取消的、支持背压的事件流”，其核心接口（Publisher / Subscriber / Subscription）明确定义了并发控制契约：
-
请求驱动（Pull-based）：Subscriber 通过
request(n)主动声明“我现在能处理 n 个数据”，Publisher 据此节制下发节奏，天然支持背压 -
取消即释放：调用
Subscription.cancel()可中断整个链路，包括上游生产、中间运算符、下游消费，资源清理确定可靠 -
内置并发策略：提供
parallel()、publishOn()、subscribeOn()、onBackpressureBuffer()等算子，可精确控制线程切换、缓冲区大小、溢出策略（丢弃/抛异常/阻塞） - 适合持续数据源：如 WebSocket 消息流、数据库变更日志（CDC）、传感器实时读数等需要长期稳定吞吐的场景
简单说：回调是“发完就不管”，Promise 是“一次性交货”，响应式流是“带订单、带物流、带退货通道的供应链系统”。选型关键看是否需要长时间、高吞吐、可中断、可调控的异步数据流管理。
