前阵子我帮一位朋友梳理一个后台页面的结构代码量接近两千行功能却只是最简单的筛选加列表。我挨个往下看几乎全是divCSS 靠十多个类名硬撑着表单按钮被写成了span加点击事件键盘操作直接失效。那是我第一次真正意识到HTML 页面技术从来不是“能显示就行”的事而是整个项目能不能被长期维护的根基。这篇内容我想从从业者的角度把 html 页面技术拆开来聊聊——从信息架构、语义标签、加载性能到更容易被忽略的表单与无障碍细节。写这些东西是因为不管是刚入行的前端、半路转岗的测试还是偶尔需要单独写页面的后端同学都能从中找到一些能立刻用上的判断标准。1. 页面结构不是排版工具先用“信息优先级”搭骨架1.1 动笔之前先回答三个问题很多人写 HTML 的习惯是从浏览器开始打开一个空白文件先把顶部的导航、中间的图片、底部的版权放上去再用 CSS 一点点调位置。这种做法的最大问题是页面的结构被视觉效果带着走而不是被用户任务带着走。我现在的习惯恰恰相反动手写标签之前先回答三个问题这个页面要帮用户完成的最核心任务是什么用户在看到这个页面时眼睛和操作最应该被引导到哪里哪些信息是辅助性的可以放在边缘位置而不是占据首屏以内部模拟项目 X 的申请页为例页面要完成的任务是“让用户提交一个申请”。那信息优先级就很清楚用户首先要确认这是申请页其次要知道申请需要哪些内容然后才轮到表单和操作按钮。最后才是帮助说明、相关链接这类辅助内容。这个思考过程直接决定了 HTML 的书写顺序。HTML 里的标签顺序既是代码阅读顺序也是键盘操作顺序更是搜索引擎理解页面的顺序。所以它不能是“浏览器中心式”的而应该是“任务中心式”的。1.2 先写文字骨架再填视觉皮肤有了优先级之后我不会直接写最终代码而是先在编辑器里写出一个几乎不带样式的“文章大纲版 HTML”。比如模拟项目 X 的申请页我会先落成这样的结构!DOCTYPE html html langzh-CN head meta charsetUTF-8 meta nameviewport contentwidthdevice-width, initial-scale1.0 title项目申请 - 模拟项目X/title /head body header h1项目申请/h1 p请在下方的表单中填写真实信息提交后需要两个工作日审核。/p /header main section aria-labelledbyapply-form-title h2 idapply-form-title填写申请信息/h2 form !-- 具体的表单字段放到后面再补 -- /form /section aside h2常见问题/h2 ul lia href#审核需要多长时间/a/li lia href#申请被退回怎么办/a/li /ul /aside /main footer p如有疑问请联系项目支持邮箱。/p /footer /body /html这段代码没有任何 CSS但已经能看出来页面讲了什么页头是主题说明主体是申请表单旁边是常见问题底部是联系方式。样式可以后补结构一旦定错后面所有工作都会受影响。1.3 结构顺序决定交互负担很多人把“响应式布局”当成一门独立的页面技术却忽略了响应式的根本是 HTML 结构顺序。移动端阅读时浏览器只是把 CSS 换成另一套规则不会自动重排 HTML。如果桌面端的主操作区在第七个区块移动端就算视觉上挪到第一屏键盘焦点顺序和屏幕阅读器的朗读顺序仍然会从 HTML 的第一个标签开始。所以我在定结构时有个硬性约束把最重要的内容和操作区域尽量写在前三分之一的位置。这不是为了 SEO 投机的做法而是为了让所有用户都能更快进入任务。信息架构不应该在 CSS 阶段才被想起来它是 HTML 标签阶段就要解决的事。提示如果你发现自己必须依赖 CSS 的绝对定位或者order属性才能把核心内容显示在最前面先回头重新排列 HTML 结构而不是继续给样式打补丁。2. 语义化标签怎么选strong为什么不是bdiv也不是万能壳2.1 语义标签对照表每个标签都有自己的“角色”HTML 语义化是页面技术里最常被提起、也最容易被误解的概念。很多说法把它等同于“给 div 换个名字”实际上语义标签解决的根本问题是让浏览器、搜索引擎、辅助技术能够理解这个区块在页面中扮演什么角色。这里整理一张我平时判断标签时最常用的对照表标签语义角色适合场景常见误区header页眉/区块头部页面顶部、文章开头以为只能出现一次实际上每个独立区块都可以有nav导航容器主导航、页脚导航、侧边栏目录把一组友情链接也叫 nav其实它们不是主要导航main页面主体内容每个页面只能一个把弹窗、抽屉内容也塞进来article可独立分发的内容博客正文、新闻、卡片内容只要有一个圆角卡片就套 articlesection可归组的内容分区有标题的区块给没有任何标题的纯样式容器包 sectionaside辅助性内容侧边栏、广告、补充说明把 main 里面的次要信息也拿出来放 asidefooter页脚/区块尾部页面底部、文章尾部只在页面底部放一个strong重要强调关键提示语像 b 一样拿来加粗em语气强调语气转折、重音只为了改字体斜式可以换个更容易理解的说法如果你打开一个页面把 CSS 全部关掉剩下的 HTML 依然能讲清楚它的内容层次那语义化就及格了。而strong和b的差别恰好是很好的例子strong说的是“这段内容很重要”b说的是“这里文字粗一点”。视觉上可能一样但前者能让屏幕阅读器用不同的语气读出重点后者没有任何意义。2.2 标题层级屏幕上的文字大小本质上是页面大纲标题标签是页面技术里另一个经常被随手使用的部分。很多人选h1到h6的理由是“这个字号看起来正合适”而不是“这个标题在整个页面里处于第几级”。我见过一个很典型的问题页面里有好几个h1视觉上分别代表左侧栏、中间内容和底部区块。这在屏幕阅读器里会被理解成“这个页面有多个一级标题”用户的分级导航就乱了。推荐的写法是一个页面只保留一个h1它描述整个页面的主题下面的内容依据从属关系依次使用h2、h3。标题层级本质上就是文章大纲你能把大纲画出来标题就不会选错。拿模拟项目 X 的申请页举例h1项目申请/h1 section h2填写申请信息/h2 h3基本信息/h3 h3项目背景/h3 /section section h2注意事项/h2 h3材料要求/h3 /section这种结构的好处是用户不管是用鼠标还是用屏幕阅读器都能通过标题快速定位自己想要的部分。不要为了“少一层缩进”就让h2直接变成h4页面大纲不是排版缩进跳级意味着信息归属关系不明确。2.3 我判断一个区域要不要换语义标签的三条标准我平时重构代码时不会把每个 div 都改成语义标签那是一个常见的反向极端。判断标准其实只有三条这个区域能不能独立拿出去让别人看如果能优先考虑article。这个区域有没有自己的标题有用section更合适没有div 可能就足够。这个区域在扮演某种特定角色吗导航、页眉、页脚、补充信息都有对应标签。如果三个问题都是否继续用 div 并没有错。语义化不是“标签用得越高级越好”而是“每个标签都用得名副其实”。我见过一些项目把页面里每个有 border-radius 的容器全部套上article结果屏幕阅读器朗读时变成了一长串并列的“文章”反而比 div 更难理解。语义标签的价值来自准确不来自数量。3. 加载性能里的HTML细节一个标签放错位置就可能拖慢整页3.1 关键渲染路径浏览器是怎么把HTML变成像素的聊页面性能不能光讲“压缩图片”“多级缓存”最容易被忽略的是 HTML 本身对渲染路径的干预。浏览器拿到 HTML 后会先解析标签生成 DOM 树同时遇到 CSS 就解析成 CSSOM 树两者合并成布局树最后才绘制到屏幕上。这个过程叫关键渲染路径。理解这条链之后很多放置标签的规矩就不再是教条了。比如link relstylesheet通常放在head里是因为 CSS 不阻塞 DOM 解析但会阻塞渲染。如果样式表放在body底部浏览器要先完成大部分 DOM 解析等到快结束时才发现有样式需要重新计算这时候首屏绘制就会被明显拖慢。同样的逻辑也适用于script。普通的script在解析到标签时会立刻下载并执行这个过程会阻塞后续 DOM 的解析浏览器像被按了暂停键。只因为一个没有加任何属性的脚本放在body中间后面的整个表单区域可能要延迟几百毫秒才能出现。3.2 脚本加载策略与动态内容defer和异步插入对于不依赖 DOM 顺序的普通脚本defer属性是安全的选择。它告诉浏览器继续解析 HTML等文档解析完再执行这个脚本。这样脚本不会在解析途中打断渲染。具体的写法是script defer srcapp.js/script如果你有一些必须在某个节点之后运行的小段逻辑也尽量不要用内联脚本去读取同页面的其他节点。内联脚本虽然减少了一次请求但它会立即执行仍然阻塞后续解析。对于大段第三方脚本放在/body前加defer通常会比放在head里更稳。还有一个早年常见但如今依然存在的问题为了弹出一个浮层在页面初始化时就把整个弹窗的内容渲染进 DOM再靠 CSS 的display: none藏起来。这种写法的代价是浏览器必须解析那些用户可能永远看不到的节点还会让 DOM 体积变得臃肿。更好的做法是用 JavaScript 在需要时动态插入或者用template元素保留模板等触发时再克隆到 DOM 里。3.3 图片标签上的两个属性直接影响布局稳定性图片在 HTML 里的写法看起来很简单但有两个属性经常被漏掉一个是width和height另一个是loadinglazy。在 CSS 布局里图片默认在没有尺寸限制时占据一定空间。如果img标签没有写width和height浏览器在图片文件加载完成之前不知道它应该占多大等图片突然加载出来下面的内容就会瞬间被挤下去。用户可能正在阅读文字突然跳一行体验非常差。既然现在大多数浏览器已经支持通过属性设定宽高写代码时就别偷懒img srccover.jpg alt项目封面 width800 height500 loadinglazyloadinglazy适合页面中靠下、需要滚动才能看到的图片它让图片在进入视口附近时才加载。但首屏的视觉重点图片不要随便加 lazy因为那样反而可能推迟关键内容的显示。判断标准很简单如果这张图片在用户打开页面时就应该看到就不要 lazy如果它在页面比较靠后的位置加上会比较合理。3.4 DOM 规模过大最深的地方往往是最容易卡的地方我个人排查页面卡顿问题时第一步看的不是 JavaScript 有没有死循环而是 DOM 树的深度和规模。一个页面被三千个节点塞满每个节点又都有几十层嵌套浏览器在布局和样式计算时会多出成倍的工作量。典型的问题写法是这样的div classlist div classitem div classitem-inner div classitem-content div classtext内容文字/div /div /div /div /div实际上用两三层就能完成的结构被写成了五层。每多一层嵌套浏览器绘制前都要多做一层几何计算的取舍。我后来把这类页面改成更扁平的结构再配上语义标签渲染性能明显提升。这里不需要记住一个绝对数字上限而是守一个原则标签的嵌套是为了表达内容关系不是为了给 CSS 选择器铺路。4. 表单、图片与可访问性最容易在其他部分看起来没问题时翻车4.1 表单要发挥“原生能力”而不是手写交互表单是页面技术里最需要规范的部分也是我见过翻车最多的部分。很多看起来正常的表单实际上是闹了不少笑话的用div做输入框容器、用span加点击事件模拟按钮、用“占位符文字”代替真正的标签。以最简单的输入框为例原生label和input的组合自带焦点关联用户点击“姓名”两个字光标会跳到对应的输入框。屏幕阅读器会读出“姓名”和当前输入的内容。这些能力都不需要额外写 JavaScript。可一旦换成 div 模拟的输入框键盘用户根本无法正常聚焦提示文字也没有任何语义关联整个表单的可操作性就崩了。推荐的基础形态是这样的label forapplicant-name申请人姓名/label input idapplicant-name nameapplicantName typetext required aria-describedbyname-hint p idname-hint请填写真实姓名提交后不可修改。/p这里的for和id必须一一对应name属性决定提交到后端时的字段名aria-describedby把辅助提示信息关联到输入框上。这样用户聚焦输入框时不只是看到提示文字辅助技术也会把它读出来。按钮也一样能用button就不要用其他元素模拟。button自带键盘操作、焦点状态和表单提交能力一个真正的按钮在表单里按下回车就能触发表单而 div 模拟的按钮要做的事件监听、键盘监听、焦点管理动不动就是几十行代码还容易在细节上漏掉。4.2 图片 alt 的取舍什么时候该写什么时候可以留空图片的alt属性是页面技术里一个看起来简单、实际很容易把握不住的点。经验法则是如果图片本身在传达内容信息就要在 alt 中描述如果图片只是装饰用空值alt让辅助技术跳过它反而更好。我见过一个常见错误把一张纯背景图写上alt背景图片。看上去“规范”了实际屏幕上阅读器会读出一句毫无意义的话属于典型的声音噪声。另一种错误是 alt 太长把图片里的五十个文字细节全部塞进去让用户被迫听一大段描述。准确的做法是抓住这张图片在页面语境里想表达的核心信息用一两句话讲清楚。可以用这样的判断表来快速决定场景推荐写法理由页面主要宣传图图中文字是核心卖点alt本周提交申请享优先审核图片内容就是重要信息必须可读产品列表里的产品照片alt深灰色商务背包描述产品方便用户从列表理解纯装饰背景图alt不让辅助技术朗读无意义内容同一张图全站多个位置重复出现可读信息只需在主要位置写一次避免同一内容重复朗读4.3 焦点状态与 aria 属性看不见的问题才是大事可访问性不是一个需要额外做得很玄的领域它更像是用另一种方式去验证 HTML 结构是否健全。我最常提醒别人的一点是不要让键盘焦点在页面上“消失”。很多设计为了让页面更“干净”把浏览器的默认焦点边框去掉了比如outline: none。结果键盘用户按 Tab 切换时完全不知道焦点落在哪里。正确的做法是保留焦点样式或者用更贴合设计的方式重新定义它:focus-visible { outline: 2px solid #2563eb; outline-offset: 2px; }outline-offset让焦点边框和元素之间隔出一点距离视觉上更明显。对于那些只有图标、没有文字的可点击操作比如一个搜索按钮可以加aria-label提供文字说明button aria-label搜索 svg!-- 放大镜图标 --/svg /button这样屏幕阅读器用户听到的是“搜索”而不是“按钮”或者 SVG 的代码内容。可访问性这件事做对之后用户不会多说什么但做漏时一部分人面对页面基本等于面对一堵墙。5. 一个难维护页面的复盘从两千行div到可读结构5.1 复盘问题不是样式乱而是结构角色完全混在一起我之前接手过一段功能并不复杂的页面代码视觉上挑不出大毛病但维护起来极其痛苦。点击一个列表项要展开详情展开的详情又被套在一个div classdetail-wrapper里而整个列表的每一项又都用同样的三个 class 组合来区分布局层级。想改一个按钮的颜色得先翻过几十层父容器才能找到它。用浏览器自带的检查功能看 DOM 树时问题很明显页面里有七个div连续嵌套中间没有一个语义标签来打断。所有的“标题”都用div classtitle而不是h2或h3。列表项不是li而是div套div屏幕阅读器读出来是一堆断裂的片段。这些问题的根源是写代码的人当时把每一个视觉元素都当成了独立块而不是信息层级中的一部分。div 本身没有错错的是让 div 承载了所有角色。5.2 逐步排查可复用的修复顺序我把这类页面的排查顺序总结成了固定的五步后面遇到类似的页面都能直接用打开浏览器开发者工具看 DOM 树标出所有连续嵌套超过四层且没有语义标签的区域。依次检查页面里的 h1 到 h6看是否能只用标题就说出页面大纲。对页面里的每个按钮进行操作先鼠标点击再尝试键盘 Tab 聚焦并回车。检查每个输入框有没有 label有没有 name错误提示和输入框有没有关联。最后看图片和视频元素确认装饰性内容不会读出毫无意义的信息。这个顺序不是我随便定的它是按照“结构 → 语义 → 操作 → 说明 → 媒体”的层递关系来的。前面的问题不修正后面的很多元素即使补了aria属性也难有真正作用。5.3 修复时的优先级先处理影响使用的再处理观感上的修复一个混乱页面时我通常先处理键盘操作和表单问题因为它们直接影响“能不能用”。然后是标题层级因为它影响“能不能读懂”。最后才是把某些纯装饰性的 div 精简掉这属于让代码更好维护的层面不影响用户实际操作。在修复模拟项目 X 时第一步是把列表区域从“div 套 div”改成真正的ul和li这样屏幕阅读器能识别出这是列表朗读时会提示有几个项目用户可以直接按项目跳转。第二步是给每个可点击项加上真正的button或合理的链接语义。第三步才是梳理样式把那些只为视觉效果服务的嵌套层慢慢去掉。修复完成后同一个页面的 DOM 节点少了一半键盘用户可以顺畅地走到每一个控件上屏幕阅读器用户能被清晰地引导到主要内容。这个对比让我更坚定一个看法HTML 页面技术的核心不是写出多少惊艳的视觉效果而是让结构在极端情况下依然可靠。6. 长期维护HTML页面的几条习惯6.1 项目一开始就定结构标准而不是等乱成一团再重构HTML 页面技术往往是团队里最不被重视的部分因为看起来谁都能写。但只要维护过超过一年的项目就会发现结构标准越早定后期的成本越低。我现在的习惯是新项目在第一次提交前先约定一套标签使用原则比如哪个场景用 section、哪个场景用 article、标题层级怎么安排、图片什么时候必须写宽高。这些标准不需要写成很长的文档一页纸就够了。关键是让参与的人在前期达成一致而不是在代码里各自发挥。页面结构就像大楼的承重墙视觉效果这些“软装”可以后面再换承重墙位置不对改动就是大工程。6.2 每次改动从“读结构”开始而不是直接找类名维护一个老页面时我经常看到同事一上来就搜索某个 class 名找到后直接改。但如果先花几分钟把页面结构从上到下读一遍很多问题能提前暴露出来。比如一个筛选表单实际上缺少label关联或者一个按钮是 div 模拟的等你翻完样式再回头修交互工作量只会更大。我给自己定的习惯是动任何页面之前先问“这个区域在信息架构里是什么角色”。没有这个习惯的时候我做过不少“改了视觉、废了键盘”的蠢事有这个习惯之后HTML 结构成了我改动时的导航图而不是障碍物。6.3 定期清理不必要的复杂度页面技术里有一条很容易被忽视的规则删除代码比新增代码更难但对长期质量更重要。一个项目时间长了总会积累下曾经的“临时方案”某个区块被内联脚本改过某个弹窗还在 DOM 里挂着某个 CSS 类只在旧版功能里用过。我喜欢定期做一次“去复杂化”的检查把不再需要的脚本移走把纯展示性的 DOM 节点删掉把无意义的嵌套层打开。每次看到页面结构变得比之前更清爽我都会想起那个两千行 div 页面的教训——HTML 不是写给浏览器看的更是写给半年后的自己看的。结构干净后面的人维护起来才会觉得轻松。 HTML 页面技术说到底是让人与人之间的协作变得更顺畅的一种方式。