低效HTML代码直接拖慢解析、增加内存占用、干扰可访问性、加剧维护难度；典型表现是首屏渲染慢、Lighthouse DOM size或render-blocking得分差、屏幕阅读器无法识别结构、改class引发样式连锁崩溃。
低效的 HTML 代码不是“看着不漂亮”的问题，而是直接拖慢解析、增加内存占用、干扰可访问性、让后续维护变成猜谜游戏。最典型的信号是：页面首屏渲染慢、Lighthouse 的 DOM size 或 render-blocking resources 得分差、屏幕阅读器读不出结构、改个 class 就连锁崩样式。
用语义化标签替代无意义的 <div> 嵌套
浏览器和辅助技术靠标签含义理解内容，不是靠 class 名。写一堆 <div class="header"> + <div class="nav-item">，等于主动放弃语义红利。
-
<div class="header">→ 改成<header>，<div class="nav">→<nav>，<div class="main">→<main> - 嵌套层级超过 4 层时，先检查是不是能用
<section>或<article>拆分逻辑块，而不是继续套<div> - BEM 类名（如
card__title）不能弥补语义缺失——<div class="card__title">仍被解析为普通容器，而<h2 class="card__title">才有层级和语义
禁止内联样式和脚本，哪怕只有一行
style="margin: 0" 或 onclick="doSomething()" 看似省事，实则破坏分离原则、阻断 CSS/JS 缓存、无法被 lint 工具捕获、且在 SSR 或构建流程中极易被遗漏。
- 所有样式必须进外部
.css文件，或<style>块（仅限极小关键 CSS，如首屏字体颜色） - 所有交互逻辑必须进外部
.js文件，用事件委托或现代框架绑定，而非on*属性 - 特别注意：Vue/React 中的
v-bind:style或style={{}}是运行时计算，不算“内联样式”，但静态写死的style="..."仍算
控制 DOM 节点数量与嵌套深度
Chrome DevTools 的 Elements 面板右上角显示的节点数（如 “1245 nodes”）超过 1500，就该警惕。过多节点会显著拉长解析、样式计算和布局时间。
立即学习“前端免费学习笔记（深入）”；
- 删除调试残留：注释掉的
<!-- <div>... -->、空<div></div>、重复的<span></span> - 避免“防御式包裹”：不要为每个文字加一层
<span>，除非真需要独立样式或 JS 操作目标 - 表格慎用：用
<table>表达真实数据关系；用display: table布局已过时，优先选flex或grid
确保文档模式与资源加载顺序正确
没声明 <!DOCTYPE html> 或把它写在第二行，浏览器会进怪异模式（Quirks Mode），CSS 盒模型、JS API 行为全乱套；JS 放 <head> 里又没加 defer，直接阻塞 HTML 解析。
-
<!DOCTYPE html>必须是文件第一行，前面不能有任何字符（包括 BOM、空格、注释） - CSS
<link>全部放<head>，且按依赖顺序排列（基础重置 → 通用组件 → 页面特例） - JS
<script>默认放<body>底部；若必须放<head>，至少加defer（保证执行顺序）或async（完全异步，适合统计脚本）
真正难的不是记住这些规则，而是在快速迭代中坚持检查：每次提交前扫一眼 Elements 面板的节点数、右键查看页面源码是否满屏 <div>、用 Lighthouse 跑一次 Accessibility 和 Best Practices 分项——很多低效问题，其实就在刷新页面那一秒就能暴露出来。
