data-*属性本质是公开字符串容器，不能防篡改；仅适合存储渲染所需、可公开、结构简单的辅助信息，敏感数据必须由后端校验或通过签名、JWT等方式保护。
data-* 属性根本不能防止数据被篡改——它连“防”这个动作都没有，只是个公开挂载点。
data-* 本质是公开字符串容器，不是安全边界
浏览器把 data-id="123"、data-status="pending" 这类属性原样暴露在 DOM 中，用户打开开发者工具，双击就能改；用 JS 一行 el.dataset.id = "999" 或 el.setAttribute("data-id", "hacked") 就能覆盖。它不加密、不签名、不校验，也不触发任何保护机制。
常见误判场景：
- 以为
data-user-id能代替后端权限判断 → 实际上用户改完就提交，后端若直接信任该值，立刻越权 - 把 token、密钥、金额等敏感值塞进
data-secret→ 控制台一眼可见，爬虫一扫即得 - 用
data-is-admin="true"控制前端按钮显隐 → 用户删掉属性或改成"false"，再手动触发接口，照样执行管理员操作
哪些场景下 data-* 还算合理用法
它只适合存三类信息：渲染所需、可公开、结构简单。
立即学习“前端免费学习笔记（深入）”；
- 列表项的唯一标识（如
data-item-id="456"），仅用于 JS 事件委托时定位目标元素 - 预加载的静态配置（如
data-theme="dark"），由服务端渲染注入，且不参与业务逻辑判断 - 辅助 CSS 选择器的标记（如
data-loaded="true"），纯前端状态提示，不影响后端行为
注意：dataset 读取会自动驼峰转换（data-user-id → el.dataset.userId），但返回值永远是字符串——你要用数字就得 parseInt(el.dataset.userId)，要解析 JSON 就得 JSON.parse(el.dataset.config) 并加 try/catch，否则遇到非法值直接报错中断脚本。
想“防篡改”，必须换思路：后端校验 + 协议层保护
前端任何挂载在 HTML 上的数据，包括 data-*、value、hidden input、甚至 readonly 字段，都不可信。真正防篡改的路径只有一条：让关键数据不出前端，或出前端也带不可伪造的凭证。
- 敏感字段（如订单 ID、用户角色）必须从 session 或 JWT 中提取，而不是靠
data-order-id传入 - 需要客户端携带的业务参数，应走 HMAC 签名（例如拼接
id=123&ts=1727023860&sig=xxx），后端用共享密钥重算比对 - 涉及权限的操作，必须在后端做二次鉴权：即使前端传了
data-can-delete="true"，后端仍要查当前用户对该资源是否真有删除权限
最常被忽略的一点：data-* 的命名一旦写死在模板里，就等于把结构契约暴露给了攻击者。与其花时间加固它，不如直接砍掉依赖——用 API 响应体动态返回必要上下文，再由 JS 安全消费。
