data-*属性仅用于初始化传参，不可作响应式状态源；hidden和class才是驱动视图更新的可靠通道；需监听data-变更时应使用自定义元素+attributechangedcallback。
data-* 属性别当状态源，只做初始化传参
把 data-user-id 或 data-config 当成响应式状态直接读取，十有八九会出错。它本质是字符串容器，不是状态通道。
常见错误现象：
-
dataset.count读出来是"10"，再做10 + 1得到"101" -
JSON.parse(el.dataset.filters)没包try/catch，字段缺失或格式错直接崩掉整个组件 - 在自定义元素的
constructor()里就访问this.dataset.id，此时 DOM 还没挂载，值为undefined
实操建议：
- 仅用
data-传简单、不可变参数，比如data-theme="dark"，挂载后立刻转类型存进内部state - 结构化数据统一走
el.getAttribute('data-config')，然后JSON.parse(...) || {}，且必须加try/catch - SSR 模板里避免动态生成
data-值——服务端和客户端初始值不一致时，框架 diff 会丢状态
hidden 和 class 才是真正能触发视图更新的输出通道
hidden 和 class 是少数几个浏览器原生支持“属性变更 → 视图重绘”的全局属性。它们不存状态，但能可靠驱动 UI 变化。
关键差异：
-
hidden是布尔属性：存在即隐藏，移除即显示；旧版 Safari 需 fallback 到style.display = 'none' -
class支持增删切换：el.classList.toggle('loading')比直接操作className更安全，且能触发 CSS 重绘 -
id和tabindex能影响行为（焦点流、样式选择器），但语义受限，不适合承载业务状态
实操建议：
- 显隐同步用
el.hidden = true/false，别用setAttribute('hidden', '')—— property 和 attribute 容易不同步 - 多状态 UI（如 loading / success / error）用
class控制，配合命名空间化 CSS 类名，例如.state-loading .spinner - 别用
title或lang控制显示逻辑——它们只影响辅助技术，不触发重绘
要用 data- 响应变更？必须走 customElements + attributeChangedCallback
原生 <div> 或 <code><span></span> 加了 data-，浏览器不会通知 JS “它变了”。想监听变化，唯一可控路径是自定义元素。
使用场景：
- 需要根据
data-filter动态刷新子组件 - 外部框架通过设置
data-status控制组件行为，而非调用方法 - SSR 渲染后，客户端需感知属性变更并同步内部状态
实操建议：
- 在
observedAttributes中声明要监听的data-名，例如['data-id', 'data-mode'] - 在
attributeChangedCallback里做类型转换和状态同步，别直接操作 DOM - 避免在回调里触发新的属性变更，防止无限循环（如改了
data-又触发自身回调）
draggable 和 contenteditable 必须配事件，不能只靠属性值
draggable 和 contenteditable 属于“开关型”属性，开/关本身不携带交互逻辑。它们只是告诉浏览器“允许拖拽”或“允许编辑”，后续行为全靠事件驱动。
常见错误现象：
-
contenteditable="true"后没监听input或blur，导致内容变更无法捕获 -
draggable="true"但没实现dragstart/drop，拖拽行为无反馈甚至被拦截 - 在非编辑区域误设
contenteditable，破坏键盘可访问性（如屏幕阅读器误判为可编辑）
实操建议：
-
contenteditable元素必须绑定input（实时）、blur（提交）事件，并手动管理光标、撤销栈等 -
draggable需配合dragstart设置dataTransfer，dragover阻止默认行为，drop处理落点逻辑 - 非必要场景禁用
contenteditable；优先用受控<input>或<textarea></textarea>替代
真正难的不是写对属性，而是分清哪些属性能“驱动视图”，哪些只能“传递初始值”，哪些必须“靠事件补全”。一旦混淆这三类角色，组件就会在 SSR、hydration、用户交互多个环节陆续出问题。
