dataset 接口本身不提升读取效率，仅提供语义化访问；其性能瓶颈源于滥用读写模式及忽视底层行为——每次访问需解析连字符、检查存在性、拷贝字符串，而 getAttribute 是 O(1) 直查；赋值不更新 DOM，删除需 removeAttribute；高频/复杂场景应改用 Map、WeakMap 或原生属性。
dataset 接口本身不提升“读取效率”，它只是提供了一种更语义化、更便捷的访问方式；真正在高频或复杂场景下拖慢性能的，是滥用 dataset 的读写模式和忽视其底层行为。
dataset 读取为什么有时比 getAttribute 慢
每次访问 element.dataset.xxx，浏览器都要做三件事：解析属性名（连字符转驼峰）、检查是否在初始 DOM 中存在、拷贝字符串值。而 getAttribute('data-xxx') 是直通 DOM 属性表的 O(1) 查找，无转换开销。
- 列表渲染中循环读
item.dataset.id100 次，比缓存后读一次const id = item.getAttribute('data-item-id')多出约 2–3ms（实测 Chromium 132） - 带数字或双连字符的 key（如
data-2024-start）触发额外字符串匹配逻辑，点号访问会 fallback 到方括号代理，进一步增加路径判断成本 - CSS 里用
attr(data-xxx)不会触发 JS 层解析，但仅限::before/::after的content，且值仍是字符串，无法用于计算
dataset 赋值根本不会更新 DOM
dataset 是只读代理，不是响应式绑定。你写 el.dataset.count = "5"，DOM 里的 data-count 属性值不变，刷新页面就丢数据。
- 真正写入 DOM 必须用
el.setAttribute('data-count', '5') - 删除必须用
el.removeAttribute('data-count')，delete el.dataset.count只删内存映射，后续读仍返回旧值 - 混用后果严重：先
dataset.foo = "a"，再setAttribute('data-foo', 'b')，之后dataset.foo还是 "a" —— 它缓存的是初始化时的映射，不会重拉
什么时候该放弃 dataset，改用更轻量的方式
当你要频繁读写、绑定状态、或数据结构复杂时，dataset 就成了瓶颈和陷阱源。
立即学习“前端免费学习笔记（深入）”；
- 列表项超过 50 个且需响应点击/悬停：用
Map或WeakMap显式维护 DOM 元素到数据的映射，避免反复解析 - 表单控件（
input、select）优先用原生value、checked、selectedIndex，类型明确、无字符串转换风险 - 组件私有状态（如“编辑中”、“加载中”）用
WeakMap存，不污染 DOM，元素销毁自动回收 - 服务端渲染（SSR）首屏 JS 执行前，
dataset是空的；此时必须用getAttribute直接读 HTML 字符串，否则拿不到初始值
真正影响性能的从来不是 dataset 这个接口，而是你把它当成“轻量状态容器”来用——它只适合存少量、静态、低频读取的元信息，比如 data-test-id 或 data-item-id。一旦开始存 JSON、频繁赋值、或嵌套在滚动/动画回调里读，问题就从“怎么写对”变成了“为什么越来越卡”。
