<p>data-* 属性仅用于页面加载时传递静态配置，不支持状态序列化、响应式更新或复杂数据结构；真需序列化应使用 FormData、JSON.stringify 等机制，状态管理必须交由 JS 变量或状态库。</p>
data-* 属性不能序列化复杂状态，它只适合存初始化配置或简单元数据；真要“序列化”，得靠 FormData、JSON.stringify 或 DOMParser/ XMLSerializer 这类机制，而不是把对象硬塞进 data-user='{}'。
data-* 不是状态序列化工具，只是初始化参数载体
data-* 的唯一合规用途是页面加载时传递静态配置，比如 <html data-api-base="/api" data-env="prod">。它不响应变化、不支持嵌套结构、所有值都是字符串——dataset.config 拿到的是字符串，不是对象，dataset.config.timeout 会报 Cannot read property 'timeout' of undefined。
- 必须用
JSON.stringify()序列化后再写入，读取后手动JSON.parse() - 属性名只能小写字母 + 连字符，
data-userId和data_user_id都无效，对应 JS 中的dataset.userId或dataset.userId全部取不到 - 敏感信息（token、密钥）严禁通过 data-* 传递，源码里明文可见
- 值过长（如 >5KB JSON）会拖慢 DOM 解析，建议改用 JS 变量或
Map
表单数据该用 FormData，不是 data-*
用户输入的结构化数据（含文件、多选、空值逻辑）必须交给原生机制处理：FormData 自动过滤 disabled 控件、保留 File 类型、忽略未选中的 checkbox 和 radio —— 这些行为是标准，不是 bug。
-
new FormData(form)直接提取所有成功控件，无需遍历data- -
Object.fromEntries(new FormData(form))转成扁平对象，注意同名字段（如复选框）会被后一个覆盖 -
URLSearchParams适合 GET 参数拼接，自动encodeURIComponent，但不支持File - 别写
form.querySelectorAll('[data-value]').forEach(...)—— 这绕过了浏览器原生语义，且无法处理文件或 disabled 状态
需要跨元素同步或响应式更新？状态必须在 JS 里
只要状态涉及计算（如“全选”推导）、异步（加载中态）、持久化（localStorage）、或多组件共享（筛选条件联动列表+分页），就彻底放弃 data-*。DOM 只负责渲染副作用，比如用 data-active="true" 配合 CSS 控制样式，而真实状态存在 useState 或全局 store 中。
立即学习“前端免费学习笔记（深入）”；
- data-* 更新不会触发任何监听，手动同步极易遗漏或产生竞态
- 父子组件通信、表单联动、路由参数绑定，全部依赖 JS 变量，不是 DOM 属性
- 自定义元素内部状态也应封装在
element.state = {...}或私有字段里，而非靠this.dataset驱动
真要序列化非表单 HTML 区域？用 innerHTML + 结构约定
如果需求是“把某个配置区块里的所有输入打包发出去”，别碰 data-*，直接定位区域、提取控件、按规则读值：
- 给区域加唯一
id="advanced-config"或 class document.querySelector('#advanced-config').querySelectorAll('input, select, textarea')- 过滤掉
disabled和无name的控件 - 对
input[type=checkbox/radio]读checked，其他读value；select[multiple]需遍历selectedOptions
这比任何 data-* 方案都可靠，且不破坏语义和可访问性。真正容易被忽略的是：data-* 的“便利性”假象，掩盖了状态与视图耦合的风险——一旦业务变复杂，第一个崩溃的往往是那些写着 data-user='{"id":1}' 的 div。
