自定义信号量包装类通过“可控排队”防h5雪崩，核心是固定并发数、请求合并、超时取消与指数退避，配合后端渠道隔离、幂等键与限流联动实现端到端防护。
用自定义信号量包装类防移动端 H5 接口雪崩，核心是把“无序并发”变成“可控排队”，尤其在大促开抢那一秒——不是靠后端硬扛，而是前端主动限流、收敛、错峰。
为什么 H5 在大促时容易物理雪崩
物理雪崩指浏览器线程/连接/内存等底层资源被耗尽，导致页面卡死、白屏、JS 停摆，连错误日志都发不出。常见诱因：
- 同一时间点，成千上万用户点击“立即抢购”，触发相同接口数十次（重复点击+自动重试）
- 多个组件（倒计时、库存轮询、优惠券弹窗、下单按钮）各自发起独立请求，形成请求风暴
- 弱网下请求超时未取消，大量悬挂请求堆积，占满浏览器最大并发连接数（通常同域 6~8 个）
- 无幂等控制，服务端返回 429 或 503 后，前端盲目重试，流量翻倍放大
自定义信号量包装类的关键设计点
它不是简单套个 Promise，而是模拟服务端的信号量（Semaphore）语义，在客户端实现“有界并发 + 可取消 + 优先级感知”：
- 固定容量池：例如只允许最多 3 个“锁库存”请求同时发出，其余自动进队列等待
-
带超时与 AbortController 绑定：每个排队项自带 8s 超时，超时自动 reject，且触发
abort()清理悬挂请求 -
支持请求合并（Coalescing）：相同参数（如
{skuId: "1001", userId: "u123"}）的并发请求，复用首个执行结果，避免重复提交 - 失败自动退避重试：非网络错误（如 400、库存不足）不重试；超时或 5xx 错误则按指数退避（1s → 2s → 4s）再入队，避免同步重试对齐
一个轻量可落地的实现示意
无需引入大型库，几行关键逻辑即可封装：
class H5Semaphore {
constructor(max = 3) {
this.max = max;
this.queue = [];
this.active = 0;
}
async acquire(key, fn, options = {}) {
const { timeout = 8000, mergeKey } = options;
const controller = new AbortController();
const id = mergeKey || Date.now() + Math.random();
return new Promise((resolve, reject) => {
const item = { key, fn, resolve, reject, controller, timeout, id };
this.queue.push(item);
this._tryExecute();
});
}
_tryExecute() {
if (this.active >= this.max || this.queue.length === 0) return;
const item = this.queue.shift();
this.active++;
const timer = setTimeout(() => {
item.reject(new Error('Semaphore timeout'));
this.active--;
this._tryExecute();
}, item.timeout);
item.fn(item.controller.signal)
.then(res => {
clearTimeout(timer);
item.resolve(res);
})
.catch(err => {
clearTimeout(timer);
item.reject(err);
})
.finally(() => {
this.active--;
this._tryExecute();
});
}
}
// 使用示例
const semaphore = new H5Semaphore(2);
document.getElementById('buyBtn').onclick = () => {
semaphore.acquire(
'lock_stock',
(signal) => fetch('/api/lock', { signal, method: 'POST', body: JSON.stringify(data) }),
{ mergeKey: `lock_${skuId}_${userId}` }
).then(res => console.log('锁定成功')).catch(err => console.warn('失败:', err));
};
配合后端才能真正稳住
前端信号量只是第一道缓冲，必须和后端策略联动才有效：
- 所有 H5 请求携带统一
X-Request-ID和X-Client-Type: h5，便于网关识别并启用更宽松的限流阈值（比如 H5 流量单独配 500 QPS，而非和 App 共享 2000） - 后端接口返回
Retry-After或明确错误码（如429 Too Many Requests），前端信号量据此自动延长退避时间 - 关键接口开启幂等键（
Idempotency-Key），前端生成一次性的 UUID 并透传，防止多次点击最终扣多次库存 - 服务端对 H5 流量做「渠道隔离」：微信/H5/APP 的线程池、熔断规则、降级开关全部独立，避免一个渠道抖动拖垮全部
不复杂但容易忽略：信号量不是加了就万事大吉，重点在容量设多少、超时怎么定、合并粒度是否合理。建议大促前用真实机型+ATC 弱网工具压测，观察浏览器 connection queue 和内存增长曲线，动态调优。
