data-*属性只支持字符串，存复杂结构需手动JSON序列化/反序列化；dataset驼峰转换有局限；CSS选择器严格匹配字符串值；大量使用影响性能；不参与表单提交、SEO或无障碍。
不是。 data-* 属性完全可以存复杂结构，但必须手动序列化和反序列化——它底层只认字符串，不自动处理对象、数组或布尔值。
data-* 存 JSON 字符串是安全且常用的做法
你完全可以在 data-config、data-options 这类属性里塞 JSON 字符串，只要确保它是合法的字符串格式：
- HTML 中必须用单引号或双引号包裹整个值，且内部引号需转义或混用（推荐单引号外裹，双引号内用）
- JS 读取后必须显式调用
JSON.parse()，否则拿到的只是字符串 - 写入前必须先
JSON.stringify()，否则会隐式调用.toString()导致意外结果（比如对象变[object Object]）
示例：
<div id="chart" data-options='{"theme":"dark","width":800,"series":[{"name":"sales","data":[12,34,27]}]}'>图表容器</div>JS 读取：
立即学习“前端免费学习笔记（深入）”；
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
const el = document.getElementById('chart');<br>let options;<br>try {<br> options = JSON.parse(el.getAttribute('data-options'));<br>} catch (e) {<br> console.error('data-options 格式错误', e);<br>}dataset API 对连字符命名的自动驼峰转换容易踩坑
用 element.dataset 访问时，data-user-id 会变成 element.dataset.userId，但这个映射不是双向无损的：
-
element.dataset.userId = '1001'→ 正确生成data-user-id="1001" -
element.dataset.user_id = '1001'→ 不会生成data-user_id（下划线不被识别为分词符） -
element.dataset['user-id'] = '1001'→ 语法错误，方括号访问必须用驼峰名 -
element.dataset['userId'] = null→ 不会删除属性，只会设成字符串"null"；要用delete element.dataset.userId
CSS 用 data-* 做状态驱动样式时，值必须严格匹配字符串
CSS 属性选择器对值是**全等匹配**，不是类型宽松比较：
-
<button data-loading="true">✅ 可被button[data-loading="true"]选中 -
<button data-loading="1">❌ 不会被[data-loading="true"]匹配 -
<button data-active>✅ 可被[data-active]（存在性选择）匹配，但[data-active="true"]就不匹配 - 布尔语义建议统一用
"true"/"false"字符串，避免用空属性或数字
大量 data-* 属性会影响内存和解析性能，但日常场景无需担心
每个 data-* 属性都会作为字符串存储在元素的属性列表中，DOM 节点越多、属性越长，占用内存越高：
- 单个元素上堆几十个
data-属性无明显影响，但若在 1000+ 行表格每行都塞 5 个 JSON 字符串，就可能拖慢首次渲染和 JS 遍历 - 服务端渲染时，过长的 data 属性会增大 HTML 体积，影响首字节时间和 gzip 效率
- 真正需要存大量结构化数据时，应优先考虑：把数据放在全局 JS 对象中，用
data-id仅作索引关联
最常被忽略的一点：data-* 是“页面私有数据”，它不参与表单提交、不被搜索引擎索引、也不进无障碍树——别指望靠它传关键业务数据或 SEO 内容。
