HTML属性无法跨窗口即时同步，必须依赖JavaScript主动读写+BroadcastChannel通信机制，并配合localStorage回填初始值、防自扰循环及竞态处理。
HTML 本身不能实现组件的即时属性同步——所有“看起来同步了”的效果，都依赖 JavaScript 主动干预和浏览器提供的通信机制。纯 HTML 属性（包括 data-*、class、hidden）不会跨上下文自动传播，也不会触发其他窗口或组件的响应式更新。
为什么直接改 dataset 或 setAttribute 不会“即时同步”
每个页面（标签页、iframe）拥有独立的 DOM 和 JS 执行环境。document.getElementById('btn').dataset.sync = 'done' 只影响当前页面；另一个标签页里执行 querySelector 拿到的仍是旧值。更隐蔽的问题是：el.dataset.foo = 'bar' 会同步写入 attribute，但反过来 setAttribute('data-foo', 'baz') 虽然能读到，却可能不触发某些插件监听（如 Alpine.js 的 x-bind 是编译时静态解析，不响应运行时变更）。
- 布尔属性（
checked、disabled）受 property/attribute 分离规则限制：JS 已设el.checked = false后，再setAttribute('checked', '')完全无效 -
data-*值始终是字符串，"true"≠true，直接参与逻辑判断易出错 - SSR 渲染的
data-id="123"在客户端 JS 中读出来仍是字符串，未转类型就用于计算（如id + 1）会得"1231"
用 BroadcastChannel + localStorage 实现同源多窗口属性同步
这是目前最轻量、兼容性足够（Chrome 58+、Firefox 60+、Safari 17.4+）的方案，核心是“状态落地 → 广播通知 → 本地更新”。关键不在 HTML 属性本身，而在三者闭环：
- 写入前先存
localStorage.setItem('task-status', 'running')，确保新打开的窗口能读到初始值 - 再发广播：
bc.postMessage({ id: 'task-btn', attr: 'data-state', value: 'running' })，注意带上senderId避免自扰 - 接收端用
document.getElementById(msg.id)?.setAttribute(msg.attr, msg.value)更新属性，**不用dataset赋值**（旧版 Safari 中后者不触发 CSS 重绘） - 监听
storage事件只捕获“自己在这个标签页做的修改”，不能替代BroadcastChannel
在预览窗口或单页内用 [data-state] 驱动 UI，而非 class
如果你只是想让一个按钮在“加载中”时禁用并显示 spinner，[data-state="loading"] 比 class="loading" 更可靠：它语义明确、无样式耦合、服务端直出即生效，且 CSS 选择器原生支持。
立即学习“前端免费学习笔记（深入）”；
- CSS 中写
button[data-state="loading"] { opacity: 0.6; }，不要写成button [data-state]（带空格会匹配后代） - 更新时用
el.setAttribute('data-state', 'success')，别用el.dataset.state = 'success'（后者在部分 Safari 版本中不触发重绘） - 读取优先用
el.getAttribute('data-state')，因为dataset会把连字符转驼峰（data-api-error→apiError），容易误判 - 若需监听变化，用
MutationObserver观察attributes，过滤attributeFilter: ['data-state']
真实协作场景下，HTML 属性只是“输出通道”，不是“数据源”
多人共用一个任务列表时，点击“完成”后所有窗口同步变灰，靠的不是某个 data- 属性被广播，而是：前端先调 fetch('/api/task/123', { method: 'PUT', body: '{"status":"done"}' })，成功后再统一更新本地 DOM 的 data-state 和 disabled 属性。漏掉请求这步，所有视觉同步都是假象。
- localStorage 仅适合单标签页调试，跨窗口无效
- 竞态问题真实存在：两人同时点同一个任务，必须靠服务端原子操作（如 MongoDB 的
findAndModify）或乐观锁（带 version 字段）保障最终一致性 - DOM 更新永远放在网络请求
then()里，失败时保留原状态并提示用户，而不是“先改 UI 再发请求”
真正容易被忽略的，是“谁来保管唯一真相”——HTML 属性只是镜像，不是源头。同步的复杂点从来不在怎么写 data-，而在于你是否把每次变更都对齐到那个唯一的、可验证的数据源上。
