data-id仅存储字符串，需在js中读取、转换、校验并匹配后端参数名；应分离dom定位（id）与业务数据（data-），避免暴露敏感主键，且不可依赖行序获取数据。
给 <tr> 加 <code>data-id 不等于绑定主键
很多人以为在 <tr> 上写 <code>data-id="123" 就完成了“主键绑定”，其实这只是存了个字符串。真正起作用的是你后续怎么用它——比如提交时取 tr.dataset.id、编辑时传给 API、删除时拼接 URL。如果 JS 里没读它、没传它、没校验它，那这个 data-id 就只是个装饰。
常见错误是：后端返回的 JSON 里主键字段叫 user_id，前端却统一塞进 data-id，结果删行时发请求带的是 ?id=123，而接口实际要的是 ?user_id=123，400 报错但看不出哪错了。
- 确保
data-属性名和后端 API 参数名/字段名严格对齐（大小写、下划线、连字符） - 避免把多个主键混在一个
data-id里拼接，如data-id="123_456"；应拆成data-user-id="123" data-org-id="456" - 服务端渲染时，直接从模板变量注入值；前端动态插入行时，必须在
insertRow()后立刻赋值：newTr.dataset.userId = "123"
dataset 比 getAttribute 更安全，但要注意驼峰转换规则
tr.dataset.userId 看起来方便，但它不是直接映射 HTML 属性名。浏览器会自动把连字符转驼峰：data-user-id → tr.dataset.userId，data-order-status → tr.dataset.orderStatus。一旦命名不规范（比如写了 data-user_ID），JS 就读不到。
更隐蔽的问题是空格或特殊字符：HTML 允许 data-id="abc def"，但 tr.dataset.id 会原样返回字符串，不会自动 trim 或报错。如果后端要求整数 ID，前端没做 parseInt(tr.dataset.id)，就可能发过去一个字符串 "123 "（带空格），导致接口 400 或查不到记录。
- 属性名只用小写字母、数字、连字符；避免下划线、大写字母、空格
- 读取后立即做类型转换：
const id = parseInt(tr.dataset.userId, 10) - 不确定是否为空时加守卫：
if (!tr.dataset.userId) return
别用 data-id 替代 id 属性做 DOM 查找
有人为了“语义统一”，所有标识都往 data- 上堆，结果 JS 里写 document.querySelector('tr[data-user-id="123"]')。这比 document.getElementById('user-row-123') 慢 3–5 倍，尤其表格行多时明显卡顿。
正确姿势是：用 id 做唯一 DOM 定位（快、稳、兼容好），用 data- 存业务字段（灵活、可扩展）。两者配合，不是二选一。
- 静态/服务端渲染：直接输出
<tr id="user-row-123" data-user-id="123"> <li>前端新增行：<code>tr.id = `user-row-${id}`; tr.dataset.userId = String(id) - JS 操作优先用
getElementById或querySelector('#user-row-123')，需要业务字段再取dataset
敏感主键别暴露在 data- 或 id 里
数据库自增 ID 一般没问题，但如果是 UUID、加密 token、租户内唯一编号，甚至手机号哈希值，直接塞进 data-user-id 就等于白给爬虫或恶意用户。哪怕只是临时调试，也建议后端返回脱敏后的展示 ID（如 U1001），真实主键走 session 或 token 绑定，不在 HTML 中明文出现。
另一个容易被忽略的点：排序、搜索、分页后，DOM 顺序变了，但 data- 值不会变。如果你依赖 table.rows[0].dataset.userId 认为它永远是“第一行数据”，那就踩进坑了——用户点了排序，它可能已变成另一条记录。
真正稳定的关联只靠两个东西：一是 DOM 的 id（不变），二是你主动维护的数据映射表（比如用 Map 存 id → record），而不是靠位置或属性实时解析。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
