data-track-id 单独存在毫无意义，需配合事件监听、上下文补全与结构化命名才能完成有效埋点。
HTML 全局属性本身不触发行为分析，真正起作用的是 data- 属性与 JS 监听逻辑的配合方式——只加 data-track-id 不等于埋点完成，漏掉事件委托或上下文补全，90% 的点击日志就丢了。
为什么 data-track-id 单独存在毫无意义
浏览器不会因为写了 data-track-id="search-submit" 就自动监听、采集、上报。它只是个静态字符串锚点，和在 DOM 上贴张便签纸没区别。
- 页面加载后能用
$0.dataset.trackId读到值，但用户点了没日志 → 缺少事件监听器 -
data-track-id在多个同名按钮上重复出现，JS 却只绑了一次委托 → 部分点击漏报 - 服务端渲染的
data-user-id="123"被 React hydration 覆盖成空 → 客户端采集拿到undefined -
data-track-id="submit-btn"没带模块/状态信息 → 异常堆栈里查不到是 checkout-flow 还是 login-flow 的按钮
data- 命名与取值的硬性边界
看似自由，实则受浏览器隐式规则严格约束，错一个字符或格式，dataset 就读不到。
- 必须全小写+连字符：
data-page-section✅，data-pageSection❌（IE11 / Safari 会直接忽略） - 数字开头的 key 无效：
data-1st-place→dataset中不可见 - 值永远是字符串：
data-is-paid="true"→el.dataset.isPaid === "true"，不是布尔值true - 连字符自动转驼峰：
data-user-id="123"→ JS 中只能用dataset.userId，不能写dataset.user-id（语法错误）
真正可靠的节点标记组合策略
单靠一个 data- 属性撑不起行为分析系统，必须结构化、可收敛、防冲突。
立即学习“前端免费学习笔记（深入）”；
- 统一前缀隔离用途：
data-monitor-module、data-monitor-type、data-monitor-id，避免和data-track-或data-ui-混用 - 必填字段缺一不可：
module（业务域）、type（组件类型）、id（实例级唯一标识，非 DOMid） - 敏感字段禁入：
data-monitor-user-token会明文暴露在 HTML 源码中，XSS 风险极高 - 高频更新慎用：
data-monitor-cart-count每次加减都改 DOM 属性，可能引发不必要的重排
监听层必须绕过 DOM 挂载时机问题
React/Vue/微前端下，节点可能是异步挂载的，监听器若绑定到具体元素上，90% 的动态节点根本捕获不到。
- 监听必须挂在
document或document.body上，用事件委托兜底 - 推荐用捕获阶段：
document.addEventListener('click', handler, true)，比冒泡更早拿到目标 - 上报前加防抖标记：
e.target.dataset.reported === 'true'（注意是字符串比较），避免重复上报 - 避免同步
fetch()：优先走navigator.sendBeacon()或异步队列，别阻塞用户操作
最常被忽略的一点：data- 只存“身份”，不存“上下文”。时间戳、URL、设备类型、是否首屏……这些运行时信息绝不能硬编码进 HTML，必须由 JS 在事件触发时实时采集补全。否则你拿到的是一堆 ID，不是可归因的行为数据。
