data-*属性不能替代虚拟滚动逻辑，因其不减少DOM节点数、不控制渲染时机，仅作为数据绑定载体；应配合虚拟列表、节流更新和DOM复用才能提升性能。
直接用 innerHTML 拼接几万条带 data-* 属性的 HTML 字符串，不仅不会提升性能，反而会因字符串构建、HTML 解析和 DOM 构建三重开销让页面更卡。自定义属性本身不加速渲染，它只是「数据绑定」的载体——真正起作用的是你如何用它配合虚拟列表、节流更新和 DOM 复用。
为什么 data-* 不能替代虚拟滚动逻辑
data-* 属性只是把 JS 数据挂到 DOM 上，不减少节点数量，也不控制渲染时机。常见错误是：生成 10 万条 <div data-id="123" data-index="9999"></div> 后塞进容器，结果 DOM 节点数仍是 10 万，浏览器照样卡死。
- 所有带
data-*的元素仍参与 layout/paint 流程，内存和 CPU 压力没变 - 点击某行想读
dataset.id？前提是这行 DOM 已存在——而虚拟滚动里它可能根本没被创建 -
dataset是只读映射，无法反向定位真实数组索引，除非你额外维护映射表（又增复杂度）
data-* 在虚拟列表中该绑定什么
在固定高度虚拟列表中，data-* 应只绑定「当前帧可见项的真实业务标识」，而非全量数据索引。比如滚动到第 2000 行，只给当前渲染的 20 个 <li> 分别写 data-user-id 和 data-row-index，值来自 items[startIndex + i]。
- 避免用
data-index存原始数组下标（如i），而应存逻辑位置startIndex + i，防止滚动后索引错乱 - 优先用语义化名：
data-order-id比data-id更易维护；data-row-key比data-index更准确 - 不要在每个节点上重复写相同字段（如全加
data-table-name="orders"），提取到容器级data-table="orders"更省内存
如何用 dataset 配合 requestAnimationFrame 批量更新
当用户滚动或筛选后需刷新可视区内容时，用 dataset 更新比重建 DOM 快得多。前提是节点已预先创建并复用。
立即学习“前端免费学习笔记（深入）”；
- 初始化时创建 30 个
<tr>节点池，统一设class="virtual-row"，不设data-* - 滚动触发后，在
requestAnimationFrame回调里遍历这 30 个节点，仅更新textContent和dataset：row.dataset.userId = items[i].id - 避免在循环里调用
getAttribute('data-user-id')——直接读row.dataset.userId，快一个数量级 - 若需响应点击，事件委托到容器，从
e.target.dataset.userId拿值，别用querySelectorAll('[data-user-id]')全局查
容易忽略的兼容与序列化陷阱
dataset 自动转换命名规则和类型丢失问题，在大规模渲染中会被放大。
-
data-user-id="123"→dataset.userId === "123"（永远是字符串），别直接用于数值比较：if (el.dataset.count > 5)会隐式转成"5" > 5→false -
data-is-active="true"→dataset.isActive === "true"，不是布尔值，需显式判断：dataset.isActive === "true" - IE11 不支持
dataset，老项目必须 fallback 到getAttribute('data-is-active') - 服务端渲染时若用 Node.js 生成含
data-*的 HTML，注意 JSON 序列化会把null/undefined变成空字符串，导致dataset.foo返回""而非undefined
真正关键的不是加多少 data-*，而是确保每个属性都对应一次「必要且可预测」的 DOM 访问。渲染百万行时，少一次 dataset 读取，就少一次原型链查找；少一个冗余属性，就少几 KB 内存——这些细节在量级上来后，比算法选择更影响实际体验。
