企业官网建设流程全解析

聊到 web前端进阶，多数人的第一反应是框架源码、构建工具链、渲染性能优化，很少有人会把 HTML基础 再翻出来系统地过一遍。但我在带人做代码评审的时候发现一个挺普遍的现象：组件库用得飞起，状态管理理得清清楚楚，可一旦页面在某个浏览器里结构塌了、读屏软件念出来的内容驴唇不对马嘴、搜索结果里的标题摘要乱成一锅粥，排查起来就完全没有方向。往回追，根子几乎都埋在文档结构、标签语义、表单属性这些最底层的地方。

这篇内容说的是 HTML 的基础层，但视角是进阶的：不讲“标签就是尖括号包起来的东西”这种入门话，而是讲每个标签、每个属性为什么存在、选错了会付出什么代价、以及在实际项目里怎么用一套可复用的判断标准去做选择。适合已经能独立写页面的朋友，也适合做了两三年业务、感觉自己在“切图”和“堆组件”之间反复横跳、想补一补地基的同学。下面这些内容，全部来自实际项目里踩过的坑和反复验证过的做法。

1. 进阶视角下，HTML 基础为什么还得再啃一遍

1.1 前端瓶颈大多出在文档结构，而不是框架熟练度

我见过太多项目的页面结构是这样的：一层套一层的 div，靠 class 名字来区分谁是头部、谁是内容、谁是侧栏。这种写法在视觉上完全没问题，样式能生效，交互也能跑起来。问题在于，这份文档除了“给人看”之外，其他所有场景都是失效的——搜索引擎抓取时拿不到区块权重，读屏软件里没有可跳转的地标，页面进入阅读模式后正文和广告混在一起，甚至连做个简单的打印样式都得重新写一遍选择器。

这背后的逻辑很朴素：浏览器、辅助技术、抓取程序这三类“读者”，都不看你的 class 名字，它们看的是标签本身携带的语义。你把导航写成 div，它就只是个装着链接的盒子；你写成 nav，它才是一个可被识别的地标区域，读屏用户能一键跳到那里。这个差别在视觉上为零，在可用性上却是天壤之别。框架帮你解决的是“怎么高效地更新这块 DOM”，解决不了“这块 DOM 到底代表什么”。

所以进阶的第一课，不是去追新语法，而是把每个标签的职责重新捋一遍。这件事的收益是复利的：结构清楚了，样式的选择器层级会变浅，组件的边界会变清晰，无障碍改造的成本会大幅下降，后面做服务端渲染、做内容抓取、做跨端渲染，都会顺很多。反过来，结构没打好的项目，每加一个功能都在往地基上叠砖，早晚要还。

1.2 这篇内容能帮你解决哪些具体问题

我把这篇内容的目标场景列得具体一点，你可以对号入座。第一类是结构类问题：不知道该用 section 还是 article，不知道一页里能有几个 h1，不知道 main 能不能嵌在别的区块里。第二类是表单类问题：提交时字段莫名丢失、移动端弹出来的键盘类型不对、原生校验提示语没法改、按钮点一下就刷新页面。第三类是资源类问题：图片加载导致布局跳动、高分屏上图片发虚、新窗口打开的链接有安全风险、视频自动播放被拦。

这些问题的共同点是：它们都可以用几行 HTML 属性解决，但如果你不知道这些属性的存在，就会下意识地用 JavaScript 去绕，绕出来的方案往往更重、更脆、更难维护。比如给图片加上宽高属性就能消除布局抖动，很多人却去写一个 ResizeObserver 去监听。比如给按钮显式写上 type 就能避免意外提交，很多人却在提交处理函数里加一堆判断。

我会按“骨架搭建——语义选型——表单细节——资源加载——完整实操——问题排查”这个顺序往下走，每一块都会解释清楚“为什么这么选”，而不是只给结论。有些地方会给出可以直接复制的代码，有些地方会给对照表，你可以把它当成一份需要常翻的备忘录，而不是一篇读完就过的东西。

2. 页面骨架怎么搭才不会埋雷

2.1 DOCTYPE 与根元素：三行代码决定渲染模式

一个页面的开头三行，决定了后面所有样式能不能按预期渲染。第一行是文档类型声明，它的唯一作用是把浏览器从“怪异模式”拉回“标准模式”。这两个模式下的盒模型计算、行高继承、百分比高度解析规则都有差异，最典型的就是怪异模式里宽度会包含内边距和边框，导致你算好的栅格全部错位。现代编辑器模板都会自动带上这行，但如果你从别处拷贝了一段老代码，或者手写的时候图省事省掉了，问题就会以一种非常隐蔽的方式出现——在某些页面正常，在某些页面不正常，排查时你根本想不到是这一行的问题。

第二行是根元素，这里最容易被忽略的是 lang 属性。它的作用不止是给翻译工具看，还影响读屏软件用哪种语言的发音规则去朗读，影响浏览器对中文标点、连字符、字体回退的选择，甚至影响某些排版特性是否启用。我见过一个项目因为 lang 写成了别的语言，导致中文页面里的引号和破折号渲染宽度不对，视觉上看着别扭，查了半天是这行属性的事。

第三层是 head 和 body 的职责划分。head 负责“描述这份文档”，body 负责“呈现这份文档”。所有元信息——字符集、视口、标题、描述、图标、预加载提示——都应该待在 head 里；所有用户可见的内容都应该待在 body 里。这个边界听起来像废话，但实际项目里往 body 里塞 meta、往 head 里塞可见内容的情况并不少见，尤其是在做服务端模板拼接的时候。分清楚了，后面处理首屏渲染、处理资源优先级才有下手的地方。

注意：文档类型声明必须写在文件最开头，前面不能有任何字符，包括空格和空行。某些模板引擎在渲染时会在文件头部插入 BOM 或空行，这会让声明失效，页面悄悄退回怪异模式。

2.2 head 里的字符集、视口与标题优先级

字符集声明的位置有个硬性约束：必须出现在文档的前 1024 字节以内。原因是浏览器在解析到声明之前，会先用一套默认编码去试探，如果声明出现得太晚，前面那段内容可能已经被错误解码了，表现出来就是首屏出现乱码、标题里出现问号方块。所以这条声明我一般放在 head 的第一行，紧跟文档类型声明之后，不给它任何被挤到后面的机会。

视口声明是移动端适配的开关。不写这行，移动端浏览器会默认按一个虚拟的宽视口去渲染，然后把整个页面缩小塞进屏幕，用户看到的字小得需要放大才能读。写上之后，页面宽度才会等于设备宽度，媒体查询里的断点也才会按真实宽度生效。这里有个细节值得说：初始缩放比例不建议禁用用户缩放，那会让需要放大阅读的用户失去这个能力，属于典型的用可用性换视觉整齐。

标题的写法有个不太被重视的规则：越具体的信息放越前面。浏览器标签页、搜索结果的标题行、分享卡片的标题，展示宽度都是有限的，如果把站点名放前面，用户看到的永远是同一串字，区分不出具体页面。我的习惯是“页面主题 - 分类 - 站点名”这个顺序，遇到层级很深的页面，宁可砍掉站点名也要保住页面主题。描述元信息虽然不直接参与排名，但它决定了搜索结果里那两行摘要，写得具体一点，点击率的差别是能感觉到的。

2.3 脚本与样式的位置选择：defer、async 到底怎么挑

脚本放哪、怎么加载，是骨架阶段最容易做出错误决定的地方。默认的脚本标签是阻塞式的：浏览器解析到它，就会停下来去下载并执行，执行完才继续往下解析。这意味着放在 head 里的脚本会拖慢首屏内容的出现，放在 body 中间的脚本会让下半部分内容延迟渲染。现代做法是把脚本放到 body 末尾，或者用属性改变它的加载行为。

defer 和 async 这两个属性经常被混用，差别其实很清楚。defer 表示“异步下载，等文档解析完再按顺序执行”，它保证多个脚本之间的依赖顺序，适合那些需要操作完整 DOM 的业务脚本。async 表示“异步下载，下载完立刻执行”，它不保证顺序，适合完全独立的第三方脚本，比如统计、埋点这类。选错的后果很实际：把有依赖关系的脚本写成 async，会出现 A 还没执行 B 就跑起来的情况，报错信息通常是“某某未定义”，而且这种错误是偶发的，取决于网络快慢，本地开发环境根本复现不了。

样式的位置相对简单，放 head 里，让浏览器在渲染前就拿到样式表，避免出现无样式内容的闪烁。但要注意内联样式的体积，如果一段内联样式超过几 KB，它会阻塞后续内容的解析，反而不如外链。还有一个容易被忽略的点：外链样式表会阻塞脚本执行，如果你在样式表后面放了一个脚本，浏览器要等样式表下载解析完才会执行脚本，这个串行关系在弱网下会被放大。

3. 语义化标签选型：section、article、div 到底用哪个

3.1 五个区块标签的边界判断法

区块类标签的选择是语义化里最容易纠结的地方，我给一套按顺序判断的方法，基本能覆盖九成场景。第一步问：这块内容脱离当前页面之后，还能不能独立成立、独立分发？能，就用 article，典型的是列表里的每一条、每篇正文、每条评论。第二步问：这块内容是不是页面或某个区块的头部/尾部？是，用 header 或 footer，注意这两个标签可以出现在 article 内部，表示这篇文章自己的头尾。第三步问：这块内容是不是一组主要导航链接？是，用 nav，注意 nav 不该滥用，页脚那堆版权链接不算主导航，不需要包 nav。

第四步问：这块内容是不是和主内容相关、但删掉也不影响主内容理解？是，用 aside。第五步问：这块内容是不是一个围绕单一主题的独立章节，且通常带标题？是，用 section。剩下的、纯粹为了布局或者挂样式的容器，用 div。这套判断的关键在于顺序：先判独立性，再判区域角色，最后才落到通用容器。顺序反了就会陷入“这块看起来像章节，但又有点像文章”的纠结里。

main 这个标签有个硬约束容易被违反：一个页面只能有一个可见的 main，而且它不能是 article、aside、nav、header、footer 的后代。它代表的是“这份文档独有的主体内容”，页头页脚侧栏都不算。我见过模板里把 main 写在 article 里面的，结果读屏软件的地标导航出现两个主体区域，用户直接迷路。如果你的页面有多个 article，正确做法是把 main 包在最外层，article 放在 main 里面，而不是反过来。

keep in mind：section 和 article 都建议带一个标题元素。没有标题的 section 在文档大纲里就是个无名节点，辅助技术读到这里只能说“区域”，说不出这是什么区域，语义价值大打折扣。如果一块内容实在想不出标题，那它大概率不该是 section，退回 div 更诚实。

3.2 标题层级是结构骨架，不是字号调节器

标题标签被当作字号工具用，是我见过频率最高的问题。有人觉得 h3 的字号刚好，就把一个本该是 h2 的标题写成 h3，跳过了层级。这在视觉上毫无破绽，因为字号可以随便改，但在文档大纲里，就出现了一个没有父级的子节点。靠标题层级导航的用户（读屏用户里用标题跳转的比例很高）会遇到大纲断裂，某些抓取程序在提取内容层级时也会判断失误。

正确的做法是：标题层级只反映内容的结构关系，字号统一交给样式去控制。写的时候先问“这个标题属于哪个层级”，写完之后再用 CSS 把各级标题的视觉尺寸调成设计稿的样子。这样做的好处是，无论设计怎么改字号，结构始终是对的。我在项目里通常会给各级标题定义一套样式变量，写内容时只管结构，视觉上永远统一。

还有几个细节。h1 的数量在现代规范里允许多个，但我仍然建议一个页面只保留一个，理由是对大纲的解读更稳定，也便于后续做页面级的标题提取。标题里不要塞整段文字，也不要用标题去做“更多”这种功能性链接的样式，那会让大纲里全是无效节点。如果标题需要带副标题，用段落或者独立的小元素，不要把副标题塞进同一个标题标签里换行。

3.3 语义化对可访问性与抓取的真实收益

语义化的收益，很多人只停留在“规范好看”这个层面，其实落到实处的收益很具体。可访问性方面，读屏软件会给页面的地标区域生成一份快捷导航列表，用户可以按快捷键在主体、导航、补充内容之间跳转，跳过重复的页头页脚。如果你的页面全是 div，这份列表就是空的，用户只能从头开始一个元素一个元素地听，体验差距是数量级的。

抓取方面，虽然各家算法不公开，但有一点是确定的：结构清晰的页面更容易被正确切分和提取。区块标签、标题层级、文章的独立边界、时间的语义标注，这些东西构成了一份“内容地图”。做内容型站点的时候，这份地图直接影响摘要在搜索结果里的呈现质量。我实际操作过一个内容列表页，把原本的 div 列表改成带 article 和 time 的结构之后，收录速度和摘要完整度都有可感知的变化。

还有一些偏工程的收益。语义清晰的文档，在浏览器阅读模式、打印样式、纯文本导出、无障碍自动化检测这些场景下，几乎不需要额外适配。我们做自动化检测的时候，常见告警里排前面的基本都是“缺少可访问名称”“标题层级跳跃”“地标区域缺失”这几类，全是结构问题，改起来成本很低，但不改就会一直挂在报告里。

4. 表单是翻车重灾区：从字段命名到校验属性

4.1 label、name、id 三件套的绑定关系

表单里最基础的一组关系是 label、name 和 id，三者各管一件事，缺一个就出问题。label 管的是“这个输入框叫什么”，它通过 for 属性指向输入框的 id，建立绑定。绑定建立之后，点击文字就能聚焦输入框，读屏软件在聚焦时会念出这段文字，这是可访问性的基础。我见过大量把文字写在输入框旁边的写法，视觉上是对的，但辅助技术读过去只有“编辑框”，用户不知道要填什么。

name 管的是“这个值提交时叫什么”。没有 name 的输入框，值不会出现在提交的数据里，这是“提交后字段莫名丢失”最常见的原因。特别是自定义组件封装的输入框，很容易在透传属性的时候把 name 漏掉。还有一种情况是多个复选框共用同一个 name，提交时会以数组形式出现，如果后端按单值解析就会只拿到最后一个，这个在前端看着没问题，联调时才发现。

id 管的是“这个元素在文档里的唯一标识”。它必须全局唯一，一旦重复，label 的 for 就会指向第一个匹配的元素，点第二个标签的文字会聚焦到第一个输入框上。这种 bug 在循环渲染列表的时候特别容易出现，比如 id 写成固定的字符串没有拼上索引。我的做法是给列表项的 id 加上业务前缀和唯一值，确保不会撞。

注意：不要用 placeholder 替代 label。placeholder 在输入时就会消失，用户填到一半回头就忘了这个框要填什么；它的对比度通常偏低，视力不佳的用户读起来吃力；部分辅助技术对它的播报支持也不一致。placeholder 的正确用途是给格式示例，比如“例如：13800000000”。

4.2 input 类型选择与移动端键盘映射

type 属性决定的不只是校验规则，还直接决定移动端弹出哪种键盘。用 type=“tel” 时，手机弹出的是数字键盘，用户输手机号不用在字母和数字之间切换；用 type=“email” 时，键盘上会带 @ 和点号；用 type=“number” 时，弹出的是带加减按钮的数字键盘。这些差别看起来小，在一个需要填十几个字段的表单里，累积起来就是几十秒的时间差和明显更低的放弃率。

type=“number” 有个坑值得单独说：它允许输入科学计数法的 e、正负号和小数点，而且取到的值是字符串，输入非法内容时读取会得到空字符串。如果字段是纯数字的编号、验证码、数量，用 type=“text” 配合 inputmode=“numeric” 更可控，既能让键盘变成数字，又不会引入那些奇怪的输入。inputmode 这个属性就是专门用来解耦“键盘类型”和“校验类型”的，很多人不知道它的存在。

type=“date” 这类日期控件，各浏览器的呈现差异比较大，样式也很难完全定制。我的经验是：如果设计稿对日期选择器有强视觉要求，就自己实现一个，但底层仍然保留一个可访问的输入框；如果没有强要求，直接用原生控件，能省掉大量兼容和可访问性工作。别为了统一视觉去把原生控件的交互完全重写，那部分工作量远比看上去大。

4.3 原生校验属性的正确打开方式与边界

原生校验属性包括 required、pattern、minlength、maxlength、min、max、step 这一套。它们的好处是零成本、无需脚本、浏览器自带提示气泡，而且校验时机符合用户预期。我现在的做法是：能用原生属性表达的规则，一律先用原生属性，再用脚本补充原生表达不了的规则，比如两次密码一致性、跨字段依赖、异步唯一性检查。

用原生属性有几个边界要清楚。pattern 的匹配是整串匹配，不是包含匹配，写的时候不用加首尾锚点，但正则语法要符合规范，某些高级特性不支持。maxlength 只限制用户输入长度，不限制通过脚本赋值的长度，所以粘贴和程序赋值这两条路径要单独考虑。required 对复选框和单选组的表现不一样，单选组要在一组里至少一个上加 required 才有效果。

还有一个交互细节：原生校验失败时，浏览器会自动聚焦到第一个不合法的字段并显示气泡。这个行为很好用，但如果你的表单是分步骤的，或者字段在折叠面板里，聚焦过去用户可能看不到东西。这时候需要监听校验失败的事件，手动把所在的步骤或面板展开，再让默认行为继续。提交按钮也要显式写上 type=“submit”，而表单里那些“取消”“重置”类的按钮，一定要显式写 type=“button”，否则它们在表单里默认就是提交按钮，点一下整个表单就发出去了——这是我觉得最值得重复三遍的一条。

5. 图片、链接与媒体资源的加载细节

5.1 img 的 alt、尺寸与懒加载

图片标签有三个属性决定了它在工程上的质量：alt、宽高、加载策略。alt 的作用分两种情况：内容性图片要写清楚图片表达的信息，装饰性图片要写空值。写空值和完全不写是两回事，完全不写的话，辅助技术可能会把文件名念出来，或者跳过时产生歧义；写空值等于明确告诉它“这张图不重要，跳过”。判断标准很简单：把图片去掉，内容有没有损失？有损失就是内容性图片。

宽高属性的价值在于消除布局抖动。浏览器在拿到图片之前，如果不知道尺寸，就预留不出空间，图片加载完成的瞬间会把下面的内容往下推，这就是常说的布局偏移。写上宽高之后，浏览器按比例预留空间，图片加载完直接填进去，页面不会跳。写的时候用图片的原始像素尺寸就行，配合样式里的宽度设置，比例关系会自动维持。

懒加载属性让浏览器推迟加载视口外的图片，能显著降低首屏的资源压力。但要注意别给首屏内的图片加这个属性，那反而会延迟关键内容的出现。还有一个细节是解码属性，它可以提示浏览器优先解码当前视口内的图片，配合懒加载使用，滚动时的视觉感受会更顺。这些属性都是声明式的，写上去就生效，比引入一个懒加载库要轻得多。

5.2 srcset 与 sizes 的实际计算过程

高分屏图片发虚，本质是给了一张像素不够的图去铺一个更大的显示面积。解决办法是用 srcset 提供多个候选尺寸，让浏览器自己挑。这里的关键是理解两组数字的含义：srcset 里的 w 描述符表示图片的固有宽度，sizes 表示这张图在不同条件下会占多宽的布局空间，浏览器用后者除以设备像素比，得出需要多少像素，再去 srcset 里挑最接近的一个。

举个具体例子。一个响应式卡片里的图片，在窄屏上占满整行，在宽屏上固定占 400 像素，设备像素比按 2 计算。sizes 写成(max-width: 600px) 100vw, 400px。当视口是 375 像素时，布局宽度是 375，乘以 2 等于 750，浏览器会去 srcset 里找 750w 附近的候选。当视口是 1200 像素时，布局宽度是 400，乘以 2 等于 800，浏览器会挑 800w 附近的。所以 srcset 里我一般准备 400w、800w、1200w、1600w 这几档，覆盖常见场景即可，档位太密收益很小。

如果要做的不是分辨率适配，而是“不同屏幕下裁切比例不同”的艺术方向适配，那就要用 picture 元素配合 source 的媒体查询。这种场景在移动端很常见，比如桌面端用横构图，移动端用竖构图。用 picture 的时候注意，最后的 img 是必须写的，它是兜底，也是实际被渲染的那个元素，source 只是提供候选来源。

5.3 链接 target 与 rel 的安全细节

新窗口打开链接时，被打开的页面能通过一个全局引用访问到原页面的窗口对象，如果不做处理，它可以把原页面导航到任意地址，这是典型的钓鱼手法。解决办法是给链接加上 rel=“noopener”，切断这个引用关系。现代浏览器对 target=“_blank” 已经默认加上了这层保护，但如果你的项目需要兼容较老的运行环境，手动写上更稳妥。

noreferrer 的作用是不把来源信息传过去，同时隐含了 noopener 的效果。什么时候需要它？当链接指向外部站点，你不希望对方知道用户是从哪个页面跳过去的时候。对于站内链接，一般不需要，因为来源信息对分析有价值。我的习惯是：所有新窗口打开的外链，统一加rel="noopener noreferrer"；站内链接不加。

还有一个细节是链接的可访问名称。纯图标链接如果没有可读的文字，读屏软件只会念出“链接”，用户不知道点进去是什么。解决办法是在链接内部放一段视觉上隐藏但可被读到的文字，或者给链接加一个明确的标签属性。这个成本极低，但没有它，页面上的图标链接对一部分用户来说就是完全不可用的。

6. 实操：手写一个结构完整的页面

6.1 骨架搭建与目录约定

下面我按实际项目的方式，从骨架开始搭一个结构完整的页面，你可以对照着看每个决定背后的理由。先看文档骨架部分：

<!DOCTYPE html> <html lang="zh-CN"> <head> <meta charset="utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1"> <title>文章列表 - 技术笔记</title> <meta name="description" content="按主题归档的技术笔记列表，支持按标签筛选。"> <link rel="preload" href="/fonts/main.woff2" as="font" type="font/woff2" crossorigin> <link rel="stylesheet" href="/css/base.css"> <script src="/js/app.js" defer></script> </head> <body> <!-- 页头、主体、页脚 --> </body> </html>

这段骨架里有几个刻意的选择。语言属性写在根元素上，让整个文档继承语言信息；字符集紧跟在 head 开头，保证在前 1024 字节内；视口没有禁用缩放，保留用户放大阅读的能力；字体做了预加载，因为首屏文字会用到，提前发起请求能减少一段等待；样式表在前、脚本在后且带 defer，保证脚本执行时 DOM 已经完整。

目录上我习惯按“基础样式、布局、组件、页面”四层拆分，基础样式里放重置和变量，布局里放栅格和容器，组件里放可复用的块，页面样式只做微调。这样拆的好处是，改一个组件的视觉不用去翻页面级文件，找问题的路径也短。命名上我用块级前缀加元素名的组合，避免样式互相污染。

6.2 内容区填充与语义检查

接着填内容区。页头放站点标识和主导航，主体用 main 包住，主体内部按区块用 section 划分，每个 section 带标题，列表项用 article 承载：

<body> <header class="site-header"> <a class="brand" href="/">技术笔记</a> <nav aria-label="主导航"> <ul> <li><a href="/archive">归档</a></li> <li><a href="/tags">标签</a></li> </ul> </nav> </header> <main> <h1>文章列表</h1> <section aria-labelledby="recent-title"> <h2 id="recent-title">最近更新</h2> <ul class="post-list"> <li> <article> <h3><a href="/posts/1">文档结构的十个判断点</a></h3> <p>从区块标签的选择讲到标题层级的维护。</p> <p> <time datetime="2024-03-12">3 月 12 日</time> </p> </article> </li> </ul> </section> <section aria-labelledby="tags-title"> <h2 id="tags-title">按标签浏览</h2> <ul class="tag-list"> <li><a href="/tags/html">HTML</a></li> <li><a href="/tags/css">CSS</a></li> </ul> </section> </main> <footer class="site-footer"> <p>内容按署名方式共享。</p> </footer> </body>

这里面每一个标签都不是随手写的。header 表示页头，nav 表示导航并给了可访问名称，main 是唯一的主体区域，两个 section 各自带标题并用标题的 id 做了标注关联，列表项里的 article 表示每条内容可以独立分发，time 标签带上了机器可读的日期。这些细节单独看都很小，叠在一起，这份文档对各类读者的友好度就完全不同了。

写完结构之后，我会做一次快速自检：页面里有没有直接用 div 承担了本该属于区块标签的角色；每个 section 和 article 是否都有标题；h1 是不是只有一个；层级有没有跳跃；所有表单控件是否都有可访问名称；所有图片是否都有 alt；所有链接的文字是否能独立表达含义。这套检查用浏览器的可访问性面板就能过一遍，两三分钟的事。

6.3 上线前的自检清单

我把每次交付前会过一遍的清单整理成表格，你可以直接拿去用。这张表的重点不是“全都做到”，而是“知道哪些没做到、为什么可以暂时不做”：

这张表我通常是放在代码评审模板里的，逐项勾选。刚开始会花时间，做熟了之后写的时候就会自然带上，不再需要事后补。

7. 常见问题与排查技巧实录

7.1 问题速查表

下面这些是我在项目里反复遇到的问题，按现象、原因、处理方式整理，遇到类似的可以先对照着排：

这张表的用法是倒着来的：先看现象，再对原因是哪一类，最后按处理方式改。如果对不上，大概率是多个问题叠在一起，那就退回结构层面，从骨架开始重新过一遍，比在样式里乱试要快。

7.2 几条踩过坑才明白的经验

第一条，改动结构之前先确认渲染模式。我有一次排查一个盒模型错位的问题，在样式里来回改了两小时，最后发现是那段代码从别处拷过来的时候把文档类型声明弄丢了，整个页面跑在怪异模式下。从那以后，我遇到“所有宽度都对不上”这类全局性的异常，第一件事就是确认渲染模式，而不是去怀疑某条样式。

第二条，凡是用循环渲染出来的元素，id 一定要带唯一值。列表项里的输入框如果 id 是固定的字符串，label 就会全部指向第一个输入框，用户点第二行的文字，光标跳到第一行。这个 bug 在演示数据只有一两条的时候完全看不出来，上线数据一多就暴露，而且报错信息为零，只能靠肉眼发现。我的做法是给所有循环生成的 id 拼上业务主键。

第三条，原生能做的事尽量别用脚本重做。校验、懒加载、图片自适应、日期选择，这些都有声明式的做法，写几个属性就生效，而且行为和用户预期一致。用脚本重做一遍，除了要处理各种边界，还要处理辅助技术的兼容，投入产出比很低。真要做自定义，也尽量保留原生元素作为底层，只替换视觉层。

第四条，写结构的时候把自己当成读屏用户走一遍。不看屏幕，只用键盘和朗读，从页头走到页脚，看看能不能顺利找到主体内容、能不能听出每个链接去哪、能不能填完整个表单。这个练习做一次，比看十篇规范都管用，因为你遇到的问题都是真实存在的，改完之后收益也是立刻可感的。我现在做新页面的第一版结构，都会用这个方式过一遍，通常能发现五六个光看代码发现不了的问题。

第五条，别一次性重构整个项目的结构。老项目的 div 结构往往牵一发动全身，样式选择器、脚本查询、埋点都挂在上面，整体重写风险很高。可行的做法是按页面分批改，先改访问量最高、结构最乱的那几个页面，改的时候保留原有的 class，只在外面套上语义标签，样式和脚本完全不用动。这样风险最小，收益也最快能验证出来。

这套东西我在不同规模的项目里都用过，从小型内容站到复杂的业务系统，结论是一致的：HTML 这层的地基做得扎实，后面所有的技术选型和架构演进都会省力。反过来，地基上的每一处妥协，都会在某个意想不到的时刻回来找你。下一篇我会接着讲表单进阶和可访问性的具体实践，那部分内容更多，坑也更深，这里先把骨架和语义这两块打牢。