快速定位导致页面崩溃的属性：在DevTools Elements面板右键元素→“Break on”→“attribute modifications”，刷新或交互触发断点；重点检查id、class、data-、aria-类属性，结合VSCode正则搜索识别空值、冗余及语义冲突的aria属性。
删完属性后页面崩了，怎么快速定位是哪个属性惹的祸
别一上来就全量回滚。先在 DevTools Elements 面板里右键目标元素 → “Break on” → “attribute modifications”，然后刷新页面或触发交互。如果断点命中，说明 JS 正在读/写这个属性——哪怕它看起来“没用”，也不能删。
- 重点盯
id、class、data-*、aria-*这几类：它们常被querySelector、getElementById、addEventListener或 CSS 属性选择器（如input[data-validated] + .error）隐式依赖 - 删了
class="loading"却发现按钮点击后没转圈？可能 JS 用el.classList.contains('loading')控制状态，不是只靠 CSS -
aria-labelledby指向的元素被删了，屏幕阅读器会直接跳过整个控件，但视觉上毫无异常——必须用 Chrome 的无障碍树（Accessibility panel）验证
空值和重复 aria 属性怎么批量识别又不误伤
VSCode 全局搜索（Ctrl+Shift+F）开正则模式，用这些模式能准确定位高危项：
- 匹配空值：
aria-[a-z-]*=["']\s*["']—— 删掉aria-label=""、aria-describedby=" "这类 - 匹配冗余组合：
aria-hidden="true".*?aria-hidden="true"—— 同一层级两个aria-hidden="true"，留一个就行 - 匹配与原生语义冲突的：
role="presentation".*(<table> —— <code>role="presentation"加在<table> 上大概率绕过了表格语义，得看是否真需要 <li>注意：正则不能替代人工判断。比如 <code>aria-hidden="true"加在div上，若父级已设aria-hidden="true"，子级就是双重冗余；但若父级是dialog，子级可能是为了屏蔽背景内容，就得留 - 在 Console 执行
document.querySelectorAll('.old-modal, .is-dirty, [data-temp]')，看是否还有残留节点 - 全局搜
classList.add、className =、setAttribute('class'，确认你准备删的 class 是否出现在这些调用里 - 临时把
class="btn-primary"改成class="btn-primary__dead"，跑一遍核心流程（登录、提交表单、切换 Tab），观察 JS 报错或样式丢失 - 特别小心内联
style：像style="display:none"看似可删，但可能是 JS 通过el.style.display = 'block'控制显隐，删了就永远显示不了 - 在 DevTools Performance 面板录一次完整页面加载，对比删前后 “Parse HTML” 阶段耗时：减少 10% 以上才算有效（尤其当
document.querySelectorAll('*').length > 2000时） - 用 Lighthouse 跑 Accessibility 审计，确认没误删关键
aria-属性：如果 “ARIA input fields have accessible names” 这类项变红，说明删过头了 - 在低端安卓机上手动滚动长列表，观察是否从卡顿变流畅——DOM 节点数下降超过 30%，低端设备感知最明显
- 记住：删掉一个
<div class="wrapper"><div class="container"> 嵌套，比删十个空 <code>title=""对性能影响更大。优先砍结构冗余，再动属性
删 class 和 style 前怎么确认没漏掉动态逻辑
很多 class 是 JS runtime 时才挂上的，静态扫描根本看不到。安全做法是三步交叉验证：
删完之后怎么量化效果又不被假数据骗
别只看 HTML 文件体积少了多少 KB——那可能是删掉了注释或空格，对实际加载没影响。真正要盯的是运行时指标：
立即学习“前端免费学习笔记（深入）”；
