在HTML开发中，我们经常需要将配置信息或数据从后端传递到前端，或者在不同组件间共享。这时，data-* 属性因其便捷性，成为了许多开发者的首选。然而，一个常见的误解是将其视为一个“智能”的数据容器。今天我们就来厘清一个核心原则：data-* 属性仅仅是字符串的载体，它不负责解析、校验或自动转换类型，所有结构化的数据处理都必须手动完成。
data-* 的本质是字符串键值对，不是 JSON 解析器
浏览器对待 data-* 属性非常“诚实”。当你写下 data-config='{"size":"lg","mode":"dark"}' 时，浏览器只是将其作为一个普通的文本字符串存入DOM。这意味着，即使你通过 element.dataset.config 来读取，得到的也依然是那个原始的JSON格式字符串，而不是一个可以直接操作的对象。如果试图直接访问 .size 属性，自然会得到 TypeError: Cannot read property 'size' of undefined 这样的错误。
- 键名转换：
dataset在读取时会自动将连字符格式的键名转为小驼峰，例如data-api-url会变成dataset.apiUrl，但它的值始终是字符串。 - 特殊字符风险：如果字符串值里包含引号、尖括号或空格等特殊字符，HTML转义可能会破坏JSON结构，导致后续解析失败。
- 服务端渲染注意：在使用Django、Jinja等模板引擎直接插入变量时，务必确保JSON字符串已经过正确的转义处理，否则可能生成非法的HTML。
button 和 option 的 value 属性不能替代 data-*
有时开发者会想用表单元素的 value 属性来存数据，但这完全是两回事。value 是表单语义属性，其设计初衷是参与表单提交流程，并且它同样被强制视为字符串。如果你试图把一个JavaScript对象赋给它，结果只会得到毫无用处的 "[object Object]"。
- 例如，
的btn.value是字符串"{"x":1}"，而非对象。 - 更可靠的做法是：用
value存储一个简单的ID，比如，然后在JavaScript中维护一个映射表来查询完整数据。 - 关联复杂数据时，优先采用“ID + 查表”模式：
const users = { "user-123": { id: 123, name: "Alice" } }。
React/Vue 中不要用 props 直传对象到原生元素
在现代前端框架中，另一个陷阱是将包含复杂对象的props直接传递给原生DOM元素。例如在React中写 ，这个 airport 属性实际上会被React忽略，因为原生DOM并不识别它。在事件处理函数中尝试访问 event.target.airport，结果永远是 undefined。
- 正确做法：必须显式地将对象属性映射为
data-*字符串。例如：。 - 事件读取：在事件处理函数中读取时，同样要注意类型转换：
const id = parseInt(event.target.dataset.airportId)（注意键名已转为小驼峰）。 - 性能考量：应避免在
dataset中存储大量字段。对于复杂数据，依然推荐使用ID结合外部数据源（如状态管理库、Context）来查询，这样可以有效减少DOM的体积和序列化开销。
跨页面传递配置？别依赖 data-*，改用 URL 或 storage
data-* 属性是附着在当前页面的DOM树上的，页面一旦刷新或跳转，这些数据就消失了。如果你需要在不同页面间传递配置信息，就需要借助更持久的机制。
- 短小配置走URL：将参数拼接在URL查询字符串中，如
location.href = "page.html?theme=dark&lang=zh"，目标页面使用new URLSearchParams(location.search)进行解析。 - 较长或敏感配置用 sessionStorage：在同一会话的不同页面间，可以使用
sessionStorage.setItem("config", JSON.stringify(obj))来存储，在目标页面读取后应立即removeItem以避免残留。 - 不推荐Cookie：Cookie有4KB的大小限制，并且会在每次HTTP请求中自动携带，存在性能和安全隐患，不适合用于传递普通配置。
最后，还有一个极易被忽略的细节：dataset 的返回值类型永远是字符串。就算你写了 data-count="42"，用 element.dataset.count 读出来的也是 "42"，而不是数字42。这意味着，在进行任何算术运算或严格比较（===）之前，都必须手动进行类型转换，否则 "42" === 42 的结果永远是 false。记住这一点，能避免很多隐蔽的bug。
