data-*属性唯一合规用途是HTML或body标签上初始化静态配置，必须JSON.stringify()后写入并转义，读取需JSON.parse()且加try/catch；挂载业务容器会导致DOM未就绪、SSR失效、框架透传失败三大隐患。
data-* 属性是唯一合规、可靠、无需额外依赖的初始化配置传递方式，但必须挂载在 或 上，且所有结构化数据必须 JSON.stringify() 后再写入，否则 JS 读取时会直接报错或截断。
为什么不能把 data 配置写在业务容器上
把 data-api-base="/v1" 写在 <div id="app"> 里，看似方便，实则埋下三个隐患：DOM 尚未就绪时脚本就读不到；服务端渲染（SSR）中该节点可能还没生成；多个组件共用同一份配置时，容易重复定义或读取错位。更糟的是，某些框架（如 Vue）默认不透传 <code>data- 属性，this.$attrs['data-api-base'] 根本为空。
推荐做法：。这样 document.documentElement.dataset.apiBase 在任何脚本中都能立即访问，不依赖 DOMContentLoaded。
JSON 结构化数据必须手动序列化与解析
常见错误是直接写 ，结果 HTML 解析器把 " 当作属性值结束符，导致后续内容被丢弃；或者服务端模板没做 HTML 实体转义，引入 XSS 风险。
立即学习“前端免费学习笔记（深入）”；
实现 Markdown↔ HTML 互转，支持导出 PDF，用于用户请求的文档格式转换。
- 服务端输出时，必须对 JSON 值做 HTML 实体转义，例如
data-config=""{"timeout":5000}" - 前端读取后，必须用
JSON.parse()还原，且要加try/catch：const raw = document.body.dataset.config; let config = {}; try { config = JSON.parse(raw); } catch (e) { console.warn('Invalid data-config JSON', e); } - 布尔和数字字段不能靠隐式转换：
dataset.debug === "true"才安全，!!dataset.debug会把字符串"false"当成真值
dataset 和 getAttribute 的行为差异必须分清
dataset 看似方便，但它只处理标准命名：连字符自动转驼峰（data-user-id → dataset.userId），但遇到 data-2024-id 或 data-user_name 就失效；而 getAttribute('data-2024-id') 总能原样拿到字符串。
更关键的是：用 el.dataset.foo = 'bar' 修改，等价于 el.setAttribute('data-foo', 'bar')；但反过来，用 setAttribute('data-foo-bar', 'x') 不会自动同步到 dataset.fooBar —— 它们不是双向绑定。
- 读含数字/下划线的属性，一律用
getAttribute()，别信dataset - 写入时优先用
dataset（语义清晰），但要知道它底层仍是setAttribute - 不要混用：
dataset.timeout = 3000后又getAttribute('data-timeout')拿到"3000"，别误以为类型保留
敏感信息绝对不能走 data- 属性
API 密钥、用户 token、加密盐值这类东西，一旦出现在 HTML 源码里，就等于公开暴露。浏览器开发者工具里一搜 data- 就全出来，CSP 也拦不住。
真正该做的：
- 初始化阶段只传非敏感上下文，比如
data-tenant-id="acme"、data-lang="zh" - 敏感凭证由独立接口按需获取，配合
Authorization头和短时效 token - 若必须本地暂存，用
localStorage+ 加密（注意：仍非绝对安全），绝不用data-
最容易被忽略的一点：服务端模板渲染时，如果把用户输入直接拼进 data-config，又没做 HTML 转义，就构成典型 XSS 入口——这个漏洞比 JS 逻辑错误更隐蔽、更难审计。
