<p>data-* 属性冲突的根本原因是缺乏业务上下文前缀，必须强制使用短横线分隔的带域前缀命名（如data-user-id），禁用下划线、大写及裸名；读取用dataset，写入须setAttribute，跨团队组件需统一data-comp隔离。</p>
data-* 属性名为什么一写就冲突？
根本原因不是“名字太常见”，而是没加业务上下文。浏览器不限制 data-id 或 data-type，但 Alpine.js、HTMX、你自己的弹窗逻辑、第三方埋点 SDK 全可能监听同一个名字——谁先注册、谁后覆盖、谁读谁写，全靠运气。裸写 data-id="123" 就像把房间钥匙贴在门上还标着“开门用”，没人知道它是用户 ID、订单号，还是某个临时调试值。
强制加业务前缀是唯一防冲突手段
所有 data-* 属性必须带明确业务域前缀，且只用短横线分隔（kebab-case）。这不是风格偏好，是避免解析失效和语义漂移的硬性要求。
-
data-user-id="123"✅ 语义清晰，JS 可读为el.dataset.userId -
data-shop-cart-item-id="456"✅ 多层上下文，隔离性强 -
data-id="123"❌ 全局裸名，三个月后没人敢动 -
data_user_id="123"❌ 下划线在 IE 和 SSR 中可能被丢弃 -
dataUserId="123"❌ 大写字母直接被浏览器忽略，dataset.userId返回undefined
dataset 读写不一致会放大冲突风险
很多人以为 el.dataset.xxx = "val" 就等于更新了 DOM，其实它只改内存副本；真要持久化，必须用 el.setAttribute("data-xxx", "val")。混用会导致 JS 读到旧值、服务端渲染拿到新值，状态彻底错乱。
- 读取统一走
el.dataset.xxx（自动驼峰，语义清晰） - 写入必须用
el.setAttribute("data-xxx", "val")（否则下次刷新就丢失） - 判断是否存在：先用
"xxx" in el.dataset，再取值，避免undefined报错 - 删除属性优先
delete el.dataset.xxx，比removeAttribute("data-xxx")更安全
跨团队组件库必须用 data-comp 隔离样式和行为
纯 HTML 分发场景下，类名前缀（如 .c-button）天然不可靠：对方可能漏引 CSS、覆盖样式、或已有同名 class。而 data-comp 是唯一不依赖构建、不污染命名空间、浏览器原生支持的选择器锚点。
立即学习“前端免费学习笔记（深入）”；
- 根元素必须带
data-comp="button"，CSS 写成[data-comp="button"] { ... } - 变体统一用扩展属性：
data-comp-size="large"、data-comp-theme="dark" - 禁止混用 class 和 data 属性做样式判断，例如
.c-button[data-comp="button"]—— 等于维护两套标识，失效风险翻倍 - 所有
data-comp-*必须进团队白名单，CI 用 ESLint 插件校验
最常被忽略的一点：data 属性不是状态管理容器。它只适合存轻量、静态、非敏感的上下文标识。一旦开始往 data-state='{"loading":true,"error":null}' 里塞对象，就等于把状态逻辑耦合进 HTML，后续任何变更都会牵一发而动全身。
