<p>data-* 是原型阶段最值得依赖的 HTML 全局属性，因其不触发行为、不干扰渲染、原生支持且语义清晰，比 class 或 id 更适合标记业务元信息，配合 role 和 aria- 可低成本提升可访问性。</p>
data-* 是原型阶段最值得依赖的 HTML 全局属性，它不触发任何行为、不改变渲染、不依赖 JS 执行，却能为后续交互和调试埋下清晰接口 —— 用错或不用，原型迭代效率直接打五折。
为什么 data-* 比 class 或 id 更适合原型标记
class 用于样式，id 用于唯一锚点，而 data-* 是浏览器明确保留给开发者存元信息的“安全区”。原型阶段你常要回答：“这个按钮控制哪块内容？”“这张卡片的数据从哪来？”，靠 class 名猜（比如 .card--user）容易歧义，靠 id（比如 id="user-card-1"）又限制复用。而 data-module="profile"、data-item-id="42" 直接说清意图，且不会干扰 CSS 选择器或 JS 查询逻辑。
- 浏览器忽略所有
data-*属性，不影响渲染性能 - DOM API 原生支持：
el.dataset.itemId自动转驼峰，无需手动getAttribute('data-item-id') - 可被任何后续 JS 框架（Vue、React、原生）无痛读取，不绑定技术栈
- 审查元素时一眼可见，比注释或变量名更可靠
data-* 在原型中怎么填才不踩坑
填错 key 名或 value 类型，后期 JS 一读就 undefined，但错误不报，只默默失效。常见写法问题：
生成Claude风格的精美单页HTML汇报文件。当用户需要生成"汇报"、"周报"、"月报"、"项目进度"、"复盘"、"演示"、"slide deck"、"状态报告"、"工作总结"时触发。支持6种模板：周报(weekly)、项目进度(project)、月度总结(monthly)、复盘报告(postmortem)、演示文稿(slid
- key 名含大写字母或下划线：
data-UserID→ 浏览器转成dataset.userid，应统一小写+短横线：data-user-id - value 是对象或数组：
data-config='{"theme":"dark"}'→ 不推荐，易 XSS 且解析麻烦；改用多个data-属性拆解：data-theme="dark" data-version="2.1" - 动态内容未预留：
<div>张三</div>→ 后期加数据驱动时得重写结构；应提前写：<div data-bind="user-name">张三</div>，JS 可按data-bind统一接管 - 与语义标签重复劳动：
<nav data-section="header"></nav>→ 多余，<nav>本身已有语义，data-应只承载业务维度信息，如data-scope="public"
配合 role 和 aria- 实现可访问原型
仅靠 data-* 不足以让原型具备基础可用性。role 和 aria- 属性是原型阶段最低成本的可访问性保障，它们不改变视觉，但能让屏幕阅读器正确播报结构和状态：
立即学习“前端免费学习笔记（深入）”；
- 用
role="region"+aria-labelledby标记自定义区块：<section role="region" aria-labelledby="search-title"><h2 id="search-title">搜索</h2>...</section> - 临时开关状态用
aria-expanded="false"，比纯data-open="false"更规范，且支持键盘交互（如Enter触发） - 表单控件必加
aria-required="true"，即使没 JS 校验，也能被辅助技术识别 - 避免滥用
role="button"：只有非<button>元素才需要，否则破坏原生语义
真正容易被忽略的点
很多人把 data-* 当成“随便塞点东西的地方”，结果原型跑通后，JS 里全是 el.getAttribute('data-xxx') 硬编码，一改 key 名全崩。更稳妥的做法是：在原型初期就约定一套命名前缀，比如 data-ui-（控制展示）、data-api-（关联后端字段）、data-test-（供 E2E 测试定位），并在 HTML 注释里写明规则。这样哪怕换人接手，也能从 DOM 里直接读懂设计意图，而不是靠翻代码找注释。
