企业官网建设流程全解析

前阵子我帮一位朋友梳理一个后台页面的结构，代码量接近两千行，功能却只是最简单的筛选加列表。我挨个往下看，几乎全是<div>，CSS 靠十多个类名硬撑着，表单按钮被写成了span加点击事件，键盘操作直接失效。那是我第一次真正意识到：HTML 页面技术从来不是“能显示就行”的事，而是整个项目能不能被长期维护的根基。这篇内容我想从从业者的角度，把 html 页面技术拆开来聊聊——从信息架构、语义标签、加载性能，到更容易被忽略的表单与无障碍细节。写这些东西，是因为不管是刚入行的前端、半路转岗的测试，还是偶尔需要单独写页面的后端同学，都能从中找到一些能立刻用上的判断标准。

1. 页面结构不是排版工具：先用“信息优先级”搭骨架

1.1 动笔之前先回答三个问题

很多人写 HTML 的习惯是从浏览器开始，打开一个空白文件，先把顶部的导航、中间的图片、底部的版权放上去，再用 CSS 一点点调位置。这种做法的最大问题是：页面的结构被视觉效果带着走，而不是被用户任务带着走。

我现在的习惯恰恰相反，动手写标签之前，先回答三个问题：

1. 这个页面要帮用户完成的最核心任务是什么？
2. 用户在看到这个页面时，眼睛和操作最应该被引导到哪里？
3. 哪些信息是辅助性的，可以放在边缘位置而不是占据首屏？

以内部模拟项目 X 的申请页为例，页面要完成的任务是“让用户提交一个申请”。那信息优先级就很清楚：用户首先要确认这是申请页，其次要知道申请需要哪些内容，然后才轮到表单和操作按钮。最后才是帮助说明、相关链接这类辅助内容。

这个思考过程直接决定了 HTML 的书写顺序。HTML 里的标签顺序，既是代码阅读顺序，也是键盘操作顺序，更是搜索引擎理解页面的顺序。所以它不能是“浏览器中心式”的，而应该是“任务中心式”的。

1.2 先写文字骨架，再填视觉皮肤

有了优先级之后，我不会直接写最终代码，而是先在编辑器里写出一个几乎不带样式的“文章大纲版 HTML”。比如模拟项目 X 的申请页，我会先落成这样的结构：

<!DOCTYPE html> <html lang="zh-CN"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>项目申请 - 模拟项目X</title> </head> <body> <header> <h1>项目申请</h1> <p>请在下方的表单中填写真实信息，提交后需要两个工作日审核。</p> </header> <main> <section aria-labelledby="apply-form-title"> <h2 id="apply-form-title">填写申请信息</h2> <form> <!-- 具体的表单字段放到后面再补 --> </form> </section> <aside> <h2>常见问题</h2> <ul> <li><a href="#">审核需要多长时间？</a></li> <li><a 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为什么不是b，div也不是万能壳

2.1 语义标签对照表：每个标签都有自己的“角色”

HTML 语义化是页面技术里最常被提起、也最容易被误解的概念。很多说法把它等同于“给 div 换个名字”，实际上语义标签解决的根本问题是：让浏览器、搜索引擎、辅助技术能够理解这个区块在页面中扮演什么角色。

这里整理一张我平时判断标签时最常用的对照表：

可以换个更容易理解的说法：如果你打开一个页面，把 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 都改成语义标签，那是一个常见的反向极端。判断标准其实只有三条：

1. 这个区域能不能独立拿出去让别人看？如果能，优先考虑<article>。
2. 这个区域有没有自己的标题？有，用<section>更合适；没有，div 可能就足够。
3. 这个区域在扮演某种特定角色吗？导航、页眉、页脚、补充信息，都有对应标签。

如果三个问题都是否，继续用 div 并没有错。语义化不是“标签用得越高级越好”，而是“每个标签都用得名副其实”。我见过一些项目把页面里每个有 border-radius 的容器全部套上<article>，结果屏幕阅读器朗读时变成了一长串并列的“文章”，反而比 div 更难理解。语义标签的价值来自准确，不来自数量。

3. 加载性能里的HTML细节：一个标签放错位置就可能拖慢整页

3.1 关键渲染路径：浏览器是怎么把HTML变成像素的

聊页面性能，不能光讲“压缩图片”“多级缓存”，最容易被忽略的是 HTML 本身对渲染路径的干预。浏览器拿到 HTML 后，会先解析标签生成 DOM 树，同时遇到 CSS 就解析成 CSSOM 树，两者合并成布局树，最后才绘制到屏幕上。这个过程叫关键渲染路径。

理解这条链之后，很多放置标签的规矩就不再是教条了。比如<link rel="stylesheet">通常放在<head>里，是因为 CSS 不阻塞 DOM 解析，但会阻塞渲染。如果样式表放在<body>底部，浏览器要先完成大部分 DOM 解析，等到快结束时才发现有样式需要重新计算，这时候首屏绘制就会被明显拖慢。

同样的逻辑也适用于<script>。普通的<script>在解析到标签时，会立刻下载并执行，这个过程会阻塞后续 DOM 的解析，浏览器像被按了暂停键。只因为一个没有加任何属性的脚本放在<body>中间，后面的整个表单区域可能要延迟几百毫秒才能出现。

3.2 脚本加载策略与动态内容：defer和异步插入

对于不依赖 DOM 顺序的普通脚本，defer属性是安全的选择。它告诉浏览器：继续解析 HTML，等文档解析完再执行这个脚本。这样脚本不会在解析途中打断渲染。具体的写法是：

<script defer src="app.js"></script>

如果你有一些必须在某个节点之后运行的小段逻辑，也尽量不要用内联脚本去读取同页面的其他节点。内联脚本虽然减少了一次请求，但它会立即执行，仍然阻塞后续解析。对于大段第三方脚本，放在</body>前加defer，通常会比放在<head>里更稳。

还有一个早年常见但如今依然存在的问题：为了弹出一个浮层，在页面初始化时就把整个弹窗的内容渲染进 DOM，再靠 CSS 的display: none藏起来。这种写法的代价是，浏览器必须解析那些用户可能永远看不到的节点，还会让 DOM 体积变得臃肿。更好的做法是用 JavaScript 在需要时动态插入，或者用<template>元素保留模板，等触发时再克隆到 DOM 里。

3.3 图片标签上的两个属性，直接影响布局稳定性

图片在 HTML 里的写法看起来很简单，但有两个属性经常被漏掉，一个是width和height，另一个是loading="lazy"。

在 CSS 布局里，图片默认在没有尺寸限制时占据一定空间。如果<img>标签没有写width和height，浏览器在图片文件加载完成之前不知道它应该占多大，等图片突然加载出来，下面的内容就会瞬间被挤下去。用户可能正在阅读，文字突然跳一行，体验非常差。既然现在大多数浏览器已经支持通过属性设定宽高，写代码时就别偷懒：

<img src="cover.jpg" alt="项目封面" width="800" height="500" loading="lazy">

loading="lazy"适合页面中靠下、需要滚动才能看到的图片，它让图片在进入视口附近时才加载。但首屏的视觉重点图片不要随便加 lazy，因为那样反而可能推迟关键内容的显示。判断标准很简单：如果这张图片在用户打开页面时就应该看到，就不要 lazy；如果它在页面比较靠后的位置，加上会比较合理。

3.4 DOM 规模过大：最深的地方往往是最容易卡的地方

我个人排查页面卡顿问题时，第一步看的不是 JavaScript 有没有死循环，而是 DOM 树的深度和规模。一个页面被三千个节点塞满，每个节点又都有几十层嵌套，浏览器在布局和样式计算时会多出成倍的工作量。

典型的问题写法是这样的：

<div class="list"> <div class="item"> <div class="item-inner"> <div class="item-content"> <div class="text">内容文字</div> </div> </div> </div> </div>

实际上用两三层就能完成的结构，被写成了五层。每多一层嵌套，浏览器绘制前都要多做一层几何计算的取舍。我后来把这类页面改成更扁平的结构，再配上语义标签，渲染性能明显提升。这里不需要记住一个绝对数字上限，而是守一个原则：标签的嵌套是为了表达内容关系，不是为了给 CSS 选择器铺路。

4. 表单、图片与可访问性：最容易在其他部分看起来没问题时翻车

4.1 表单要发挥“原生能力”，而不是手写交互

表单是页面技术里最需要规范的部分，也是我见过翻车最多的部分。很多看起来正常的表单，实际上是闹了不少笑话的：用<div>做输入框容器、用<span>加点击事件模拟按钮、用“占位符文字”代替真正的标签。

以最简单的输入框为例，原生<label>和<input>的组合自带焦点关联：用户点击“姓名”两个字，光标会跳到对应的输入框。屏幕阅读器会读出“姓名”和当前输入的内容。这些能力都不需要额外写 JavaScript。可一旦换成 div 模拟的输入框，键盘用户根本无法正常聚焦，提示文字也没有任何语义关联，整个表单的可操作性就崩了。

推荐的基础形态是这样的：

<label for="applicant-name">申请人姓名</label> <input id="applicant-name" name="applicantName" type="text" required aria-describedby="name-hint" > <p id="name-hint">请填写真实姓名，提交后不可修改。</p>

这里的for和id必须一一对应，name属性决定提交到后端时的字段名，aria-describedby把辅助提示信息关联到输入框上。这样用户聚焦输入框时，不只是看到提示文字，辅助技术也会把它读出来。

按钮也一样，能用<button>就不要用其他元素模拟。<button>自带键盘操作、焦点状态和表单提交能力，一个真正的按钮在表单里按下回车就能触发表单，而 div 模拟的按钮要做的事件监听、键盘监听、焦点管理，动不动就是几十行代码，还容易在细节上漏掉。

4.2 图片 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 class="detail-wrapper"里，而整个列表的每一项又都用同样的三个 class 组合来区分布局层级。想改一个按钮的颜色，得先翻过几十层父容器才能找到它。

用浏览器自带的检查功能看 DOM 树时，问题很明显：

• 页面里有七个<div>连续嵌套，中间没有一个语义标签来打断。
• 所有的“标题”都用<div class="title">，而不是<h2>或<h3>。
• 列表项不是<li>，而是<div>套<div>，屏幕阅读器读出来是一堆断裂的片段。

这些问题的根源是：写代码的人当时把每一个视觉元素都当成了独立块，而不是信息层级中的一部分。div 本身没有错，错的是让 div 承载了所有角色。

5.2 逐步排查：可复用的修复顺序

我把这类页面的排查顺序总结成了固定的五步，后面遇到类似的页面都能直接用：

1. 打开浏览器开发者工具，看 DOM 树，标出所有连续嵌套超过四层且没有语义标签的区域。
2. 依次检查页面里的 h1 到 h6，看是否能只用标题就说出页面大纲。
3. 对页面里的每个按钮进行操作：先鼠标点击，再尝试键盘 Tab 聚焦并回车。
4. 检查每个输入框：有没有 label，有没有 name，错误提示和输入框有没有关联。
5. 最后看图片和视频元素，确认装饰性内容不会读出毫无意义的信息。

这个顺序不是我随便定的，它是按照“结构 → 语义 → 操作 → 说明 → 媒体”的层递关系来的。前面的问题不修正，后面的很多元素即使补了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 页面技术说到底，是让人与人之间的协作变得更顺畅的一种方式。