本文讲解如何解决定时轮询中因 DOM 异步更新导致的选择器无法捕获新元素的问题，核心是避免重复添加、确保 currentRecords 始终反映最新状态，并提供更现代、高性能的替代方案。
本文讲解如何解决定时轮询中因 dom 异步更新导致的选择器无法捕获新元素的问题，核心是避免重复添加、确保 `currentrecords` 始终反映最新状态，并提供更现代、高性能的替代方案。
在基于 jQuery 的轮询逻辑中，常见误区是：每次循环仅通过 $('.call-record') 静态获取当前 DOM 中的元素，却未同步更新本地记录数组 currentRecords。当 AJAX 成功插入新 <div class="call-record"> 后，下一轮 worker() 执行时仍从旧 DOM 快照读取 —— 表面看新元素已存在，但 currentRecords 未包含其 ID，导致系统误判为“全新记录”，反复追加。
上述问题的原始修复方案使用了 DOMNodeInserted 事件监听 + .on() 委托，看似可行，但需特别注意：
⚠️ DOMNodeInserted 已被废弃（自 DOM4 起），在现代浏览器中不推荐使用，且性能开销大、触发不可控，易引发内存泄漏或卡顿。
✅ 推荐做法：将 currentRecords 的更新逻辑内聚到 AJAX 成功回调中，确保“添加即记录”——简洁、可靠、零额外开销。
优化后的完整代码如下：
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
(function worker() {
// 1. 获取当前所有记录 ID（静态快照）
const currentRecords = $('.call-record').map((_, el) => el.id).get();
$.ajax({
url: '/api/pending-calls', // 替换为真实接口
dataType: 'json',
type: 'POST',
success: function (data) {
// 假设 data 是 { records: [{ id: 'id4', content: 'Record 4' }] }
if (Array.isArray(data.records) && data.records.length > 0) {
data.records.forEach(record => {
// ✅ 关键：仅当 ID 不在 currentRecords 中才插入
if (!currentRecords.includes(record.id)) {
const newRow = $(`<div class="call-record" id="${record.id}">${record.content}</div>`);
$('.pending-calls').prepend(newRow);
// ✅ 同步更新 currentRecords（避免下次重复判断）
currentRecords.push(record.id);
}
});
}
},
complete: function () {
setTimeout(worker, 5000);
}
});
})();进阶建议（面向中大型项目）：
- 使用 Set 替代数组存储 ID，提升 includes() 查找效率（O(1) vs O(n)）：
const currentRecords = new Set($('.call-record').map((_, el) => el.id).get()); // 判断：!currentRecords.has(record.id) // 添加：currentRecords.add(record.id) - 若数据量大或轮询频繁，考虑改用 MutationObserver 监听 .pending-calls 的子节点变化，比轮询更高效；
- 更彻底的解法是放弃客户端轮询，改用服务端推送（如 SSE 或 WebSocket），从根本上消除竞态与冗余请求。
总之，状态一致性应由业务逻辑保障，而非依赖 DOM 事件被动同步。将 ID 记录与 DOM 插入放在同一执行上下文，是最直接、健壮、可维护的解决方案。
