全局属性本身不直接触发重排重绘，但滥用会间接拖慢渲染；id查询最快但不可复用，data-*存大字符串增HTML体积，style和title增加解析与交互开销，DOM深度与属性叠加才是性能瓶颈。
id、class、data-*、style、title 这些全局属性本身不触发重排重绘，但滥用会间接拖慢渲染——关键不在“有没有”，而在“怎么用”和“用在哪”。
DOM查询性能：id比class快，但别迷信选择器速度
浏览器对 id 的查找是哈希级的，document.getElementById('foo') 几乎恒定时间；而 class 查询（如 getElementsByClassName 或 querySelector('.bar')）需遍历匹配节点。但这只影响 JS 执行阶段，不影响初始 HTML 解析。
- 真正拖慢首屏的是：在深层嵌套结构里反复用
querySelector查class，尤其配合复杂 CSS 选择器（如section > .content div[data-loaded]），会放大样式计算开销 -
id不可复用，强行给动态列表项加id="item-1"、id="item-2"等，会让后续 DOM diff 或 SSR hydration 更难做语义映射 - SSR 渲染后，客户端 JS 若依赖
id绑定事件，但服务端没生成对应节点（比如条件未满足），就容易报Cannot read property 'addEventListener' of null
data-* 属性：存数据方便，但别塞大对象或 JSON 字符串
data-* 是合法的自定义数据容器，但它的值始终是字符串。若你写 data-config='{"api":"/v1/users","timeout":5000}'，浏览器不会解析它，但 JS 调用 element.dataset.config 拿到的是原始字符串——每次要用就得 JSON.parse()，且该字符串会常驻内存。
- 超过 2KB 的
data-*值会使 HTML 体积明显上升，拉高 TTFB 和解析耗时（实测 5KB+ 内联 data 会让低端机 HTML 解析延迟 80ms+） - 避免在大量重复元素（如商品卡片）上都挂
data-product-json，改用集中式状态管理或懒加载接口 -
dataset访问是同步的，但频繁读取带长字符串的data-*属性，在滚动中触发（如 IntersectionObserver 回调里反复读）可能引发 jank
style 和 title 属性：内联样式越少越好，title 工具提示有渲染成本
style 是内联样式入口，title 是悬停提示来源——它们都不参与 CSSOM 构建，但各自有隐性开销。
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
立即学习“前端免费学习笔记（深入）”；
-
style属性会强制覆盖 CSS 规则，导致浏览器跳过部分样式继承优化；更严重的是，它让每个含该属性的元素在布局阶段多一次“内联样式解析 + 合并”步骤 - 批量设置样式（如循环中对 100 个
div写el.style.color = 'red'）比一次性用className切换快得多，但前提是这些元素已存在于 DOM 中；若在innerHTML插入时就带style，等于把样式计算压力提前到解析阶段 -
title属性看似无害，但浏览器必须为其创建 tooltip 元素、监听mouseenter、管理显示/隐藏逻辑；在移动端，它还会干扰 touch 事件流，某些机型上触发title提示后，紧接着的点击可能失效
真正容易被忽略的点：全局属性和 DOM 深度是耦合的
没人单独因为用了 data-id 就让页面变慢，但当你在一个 7 层嵌套的 table > tbody > tr > td > div > span > button 结构里，每个 button 都带 id、class、data-action、title ——这时问题就不是属性本身，而是浏览器要为每个节点多维护几份字符串引用、多走几轮属性检查逻辑、并在样式计算时多匹配几次选择器。
DevTools 的 “Show DOM properties” 显示的 depth 值，已经包含了所有属性带来的内存与解析负担。压低 DOM 深度，比纠结某个 data- 是否该删，更能立竿见影地改善 FCP 和内存占用。
