数组实现多任务超时检测，通过存储任务ID、开始时间、超时阈值和回调等信息，轮询时比对当前时间与预期完成时间，支持并发管理、状态防抖及运维统计，较单变量方案更灵活可靠。
用数组实现任务超时检测，核心是把“待检测任务”和“预期完成时间”一起存进数组，每次轮询时比对当前时间与数组里的时间戳，过期就触发处理。相比单个变量存时间戳，数组能同时管理多个任务，更贴近真实场景。
用数组存任务+时间戳，支持多任务并行检测
单个变量只能记一个任务的截止时间，而数组可以推入多个对象，每个包含任务标识、开始时间、超时阈值、回调等信息：
- 例如：[{id: 'upload-1', start: 1717023400000, timeout: 30000, onTimeout: () => console.error('上传超时')}]
- 轮询时遍历数组，用 Date.now() 减去 start，判断是否 ≥ timeout
- 匹配到超时任务后可执行回调、清除数组项、上报日志等
轮询策略：setInterval 或 requestIdleCallback 更可控
避免高频轮询浪费资源，推荐每 500ms 检查一次：
- 用 setInterval(checkTimeouts, 500)，checkTimeouts 内遍历数组并过滤已超时项
- 若在浏览器环境且任务不紧急，可用 requestIdleCallback 在空闲时检查，更友好
- 注意：clearInterval 需保存 timer ID；任务完成后应主动从数组中 splice 或 filter 掉，防止重复触发
对比单变量时间戳：灵活性与可维护性差异明显
假设只用一个变量 let deadline = Date.now() + 10000：
- ✅ 简单任务（如弹窗 10 秒自动关闭）够用
- ❌ 无法区分多个并发任务谁超时了
- ❌ 超时后变量失效，再发起新任务需手动重置，易出错
- ❌ 不便于统计各任务实际耗时、失败率等运维指标
实战小技巧：加状态字段，避免误判和重复执行
在数组元素中增加 status 字段（如 'pending' / 'done' / 'timeout'），能有效防抖：
- 检查时只处理 status === 'pending' 的项
- 触发超时回调前先设为 'timeout'，防止同一任务被多次判定
- 成功完成任务时设为 'done'，轮询时跳过，后续可归档或清理
- 示例结构：{id: 'fetch-user', start: ..., timeout: 8000, status: 'pending', resolve, reject}
