getAttribute('data-xxx')比dataset.xxx更可靠，因其直接读取原始HTML字符串，无驼峰转换限制，兼容含数字、大小写、下划线等任意合法data-*名，且不隐式类型转换或静默失败。
getAttribute() 是最稳、最直白的读取方式，别一上来就用 dataset —— 它在命名不规范、含数字、大小写混用或需要原始字符串时会静默失败。
为什么 getAttribute('data-xxx') 比 dataset.xxx 更可靠
浏览器对 dataset 的驼峰转换有硬性规则：只识别全小写+连字符格式（如 data-user-id → dataset.userId），一旦属性名含数字（data-1st-load）、大写字母（data-apiKey）、下划线（data_user_id）或空格，dataset 就完全访问不到该属性，也不会报错，而是返回 undefined。
getAttribute() 则无此限制，它直接读取 HTML 中写的原始字符串，兼容所有合法 data-* 名称，且返回值就是你写的值（包括空字符串、"0"、"false"），不会强制转成布尔或数字。
- 遇到
data-api-endpoint="https://api.example.com/v2"？用getAttribute('data-api-endpoint') - 服务端渲染输出了
data-initial-state='{"count": 10}'？必须用getAttribute+JSON.parse()，且要加try/catch - 想判断某个
data-属性是否存在（不管值是什么）？el.hasAttribute('data-disabled')比el.dataset.disabled !== undefined更准确
dataset 适合什么场景，又有哪些坑
dataset 不是 getAttribute 的升级版，而是语义更窄的快捷通道。它只适合纯配置类简单字段，比如开关标记、索引编号、角色类型。
立即学习“前端免费学习笔记（深入）”；
- 推荐用法：
data-role="menu-item"→el.dataset.role返回"menu-item" - 写入时注意：
el.dataset.enabled = true实际存的是字符串"true"，不是布尔值 - 赋值后 DOM 属性同步更新，但不会触发
MutationObserver，CSS 的[data-enabled]选择器也不会自动重匹配 - 想让 CSS 响应变化？得手动
el.setAttribute('data-enabled', 'true')
jQuery 里 .attr('data-xxx') 和 .data('xxx') 完全不是一回事
很多人以为 .data('xxx') 是 jQuery 对 dataset 的封装，其实它维护了一套独立的内存缓存，首次调用会从 data-xxx 属性读取并解析（比如把 "123" 转成数字 123，"true" 转成布尔 true），后续再调用就只读缓存，不再查 DOM。
- 读原始 HTML 值？必须用
.attr('data-config') - 修改后想让其他 JS 或 CSS 看到？得
.attr('data-status', 'loading')，而不是.data('status', 'loading') - 混用两者极易导致“明明设了值却读不到”——因为
.data()已缓存旧值，而.attr()还没被调用过
CSS 里用 [data-*] 选择器必须加引号
写 [data-status=active] 看似省事，但只要实际值含空格、点、连字符或引号（比如 data-status="in-progress"），这个选择器就完全失效。CSS 规范要求属性值含特殊字符时必须用引号包裹。
- 安全写法只有两种：
[data-status="active"]或[data-status~="active"]（后者匹配空格分隔的单词） - 避免无值判断：
[data-id]会匹配data-id=""和data-id="0"，若只想选非空，得写[data-id]:not([data-id=""])} - 服务端渲染时，如果
data-值来自用户输入，务必先 HTML 实体编码，否则引号未转义会导致整个 HTML 结构崩坏
真正麻烦的从来不是读取本身，而是当 data- 被当成状态容器、配置中心甚至 JSON 传输通道时，没人记得它本质只是字符串槽位——值怎么来、怎么转、怎么逃逸、怎么监听，每个环节都得单独兜底。
