data-* 属性不能序列化复杂状态，因其强制转字符串导致结构丢失、类型归零，且无法跨元素同步或响应式更新；表单数据应交由 FormData 等原生机制处理；复杂状态必须用 JS 变量管理，DOM 仅作渲染副作用。
data-* 属性不能序列化复杂状态
直接用 data-* 存对象、数组、函数或需要响应式更新的状态，会立刻出问题——所有值都会被强制转成字符串，深层结构丢失，类型信息归零。比如 data-user='{"id":1,"roles":["admin"]}' 看似可行，但取出来是字符串，不 parse 就没法当对象用；parse 了又得手动处理嵌套、null、日期等，且 DOM 更新不会触发任何监听。
更关键的是：data-* 只作用于单个元素，跨元素同步（如表单联动、父子组件通信）完全无解。一旦状态涉及多个节点或需持久化，硬塞 data- 就等于把逻辑和视图耦合死，后续改起来全是坑。
表单控件本身就有天然序列化能力
真正该“序列化”的不是自定义元素，而是用户输入的表单数据。现代浏览器原生支持按规范收集“成功控件”（successful controls），无需自己遍历 data-：
-
FormData自动提取所有带name的启用控件，包括file输入，值保持原始类型（File或字符串） -
Object.fromEntries(new FormData(form))可快速转为扁平对象，注意同名多值（如复选框）会被后一个覆盖 -
URLSearchParams适合 GET 请求拼参，自动encodeURIComponent，但不支持文件 - 未选中的
radio/checkbox不会出现在结果里——这是标准行为，不是 bug
需要“复杂状态”时，必须脱离 DOM 层
如果状态含以下任一特征，就该放弃 data-，改用 JS 状态变量：
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
立即学习“前端免费学习笔记（深入）”；
- 需要在多个组件间共享（如筛选条件影响列表 + 分页 + 导出按钮）
- 依赖异步操作（如搜索建议加载中态、提交后禁用按钮）
- 含计算逻辑（如“全选”状态要根据子项动态推导）
- 需存 localStorage 或参与路由参数
此时 data- 最多只做「渲染副作用」：比如用 data-active="true" 配合 CSS 控制样式，而真实状态存在 useState 或 store 里。DOM 和状态严格分离，才能避免手动同步带来的遗漏和竞态。
真要序列化非表单 HTML 区域？用 innerHTML + 结构约定
如果需求是“把某个 <div class="config-section"> 里的所有输入框打包发出去”，别碰 <code>data-，直接：
- 给区域加唯一标识，如
id="advanced-config" - 用
document.querySelector('#advanced-config').querySelectorAll('input, select, textarea')拿控件 - 过滤掉
disabled和无name的，再逐个读value或checked - 对多选
select[multiple]或复选框组，手动聚合为数组，而不是依赖FormData默认行为（它只生成重复键）
这种写法可控、可测，也容易加校验逻辑。硬套 serialize() 或往每个元素塞 data-value，只会让 DOM 膨胀、维护成本飙升。
