上一次有个做前端的朋友跟我聊说 HTML 这东西三天就能背完为什么还要单独拎出来复习。我没直接反驳让他把手上那个页面的源码发我看看。打开一看满屏的 div一层套一层二十几个 div 里找不出一个 header表单输入框全靠 placeholder 提示图片全都没有 alt。页面在浏览器里显示得好好的可它在读屏软件里几乎等于一堆乱码在搜索引擎眼里抓不到重点换个人接手维护就得重新猜每个 div 是干嘛的。这就是我想写这组 web 前端进阶内容的原因。很多人往上加技能是从框架开始的但真正卡住天花板的往往是 HTML 基础没打牢。这篇是基础篇的第一篇只谈 HTML 本身文档骨架怎么搭、语义化标签怎么选、表单怎么写得不出错、资源怎么加载才不拖后腿。不管你是刚接触前端的新人还是写了两年框架却没仔细翻过官方文档的人把这一篇的内容落到手上的代码里质量能往上提一截。1. 先看清 HTML 在前端体系里的真实分量1.1 它是唯一一层无法被替代的结构描述浏览器拿到一个页面做的第一件事是字节流解析把收到的字节按编码解码成字符词法分析器把字符切成一个个标签记号再交给树构建器拼成 DOM 树。CSS 会被解析成 CSSOM两者合并成渲染树才有了后面的布局和绘制。这一整套流程的输入只有一个就是 HTML。CSS 可以换预处理器JS 可以换框架构建工具可以来回换但最终浏览器认识的结构描述语言只有 HTML没有第二条路。理解了这一点很多取舍就清楚了。为什么框架的模板最后都要编译成渲染函数去创建 DOM 节点因为浏览器只认这个。为什么同构渲染要做 hydration因为服务端吐出来的 HTML 只是静态结构事件绑定需要客户端再接管一次。这些看起来很高深的概念往下追一层都是在处理HTML 结构怎么生成、怎么复用、怎么和 JS 状态对齐的问题。我见过一些同学写框架写得很熟但一旦遇到为什么我的样式在服务端渲染的首屏里会闪一下、为什么爬虫抓不到我的内容这类问题就卡住。卡点不在框架在于对 HTML 这一层的运行机制没有概念。所以进阶的第一步不是学新东西是把这层地基重新夯实。1.2 新手最容易踩的三个认知偏差第一个偏差是把 HTML 当成能显示就行的语言。只要浏览器画出来了就认为写对了。实际上浏览器对错误的 HTML 有极强的容错能力它会自动补全、自动闭合、自动挪动节点。你写pdivxx/div/p浏览器不会报错它会默默地把 div 提到 p 外面去。这种容错是好事也是坑你的源码和实际 DOM 对不上调试的时候就会怀疑人生。第二个偏差是认为语义化标签只是为了 SEO。SEO 确实受益但语义化的第一受益人是读屏软件用户、键盘操作用户以及未来接手这个项目的人。一个用 nav 包起来的导航区读屏软件可以直接跳转一堆 div 堆起来的导航用户只能一个一个听过去。这是功能差异不是风格差异。第三个偏差是觉得表单写起来没技术含量。实际上表单是最容易出无障碍问题、最容易出移动端兼容问题、也最容易出现提交了但后台收不到数据的地方。后面第 4 节会展开讲这里先记住一句话表单的每个属性都有它存在的理由不写 name 就是收不到数据不写 type 就可能出现意料之外的校验行为。1.3 这套基础能力在什么场景下会立刻变现说几个我实际遇到过的场景。做管理后台的时候产品要求键盘 Tab 键能走完整个表单这时候 label 和 tabindex 的基本功直接决定你要不要返工。做营销落地页的时候首屏加载慢导致跳出率高排查下来是几张首屏大图没写宽高属性造成布局抖动加了 width 和 height 之后指标立刻好转。做内容型站点的时候搜索结果里显示的摘要不对是因为 meta description 缺失或者重复。这些都不是高深问题但它们的共同点是出问题的地方都在最底层解决方式也都在最底层。框架帮不了你构建工具帮不了你只有你自己知道该写什么。2. 文档骨架从第一行到 body 的每一层都有讲究2.1 DOCTYPE 不是装饰它决定浏览器的渲染模式每个 HTML 文件第一行应该是!DOCTYPE html。这一行看起来像一句咒语实际作用是告诉浏览器按标准模式渲染我。如果不写或者写错成老式的一长串声明浏览器可能进入怪异模式quirks mode此时盒模型的计算方式、行高的解析规则、百分比高度的基准都会发生变化。我见过最典型的怪异模式症状是给元素设了width: 100px; padding: 10px;在标准模式下元素总宽是 120px在怪异模式下总宽还是 100px内容区被压缩成 80px。同一份 CSS 在两台机器上表现不一样新手会怀疑是浏览器版本问题实际上是文档开头少了那一行。判断当前页面处于哪种模式很简单在控制台执行document.compatMode返回CSS1Compat是标准模式返回BackCompat就是怪异模式。这个检查我建议在排查任何样式莫名不对的问题时都先做一遍成本极低能排除一大类干扰。另外补充一个细节!DOCTYPE html必须出现在文档的最前面前面不能有任何内容包括空格和注释。严格来说注释在前面是允许的但部分老浏览器会因此触发怪异模式所以最稳妥的写法就是让它成为文件的第一个字符。2.2 head 里那些容易被跳过的关键标签head 区域是新手最容易糊弄过去的地方通常只留一个 title 和一个 charset 就完事。实际上这里有几个标签直接影响页面行为和线上表现。字符编码meta charsetutf-8必须放在 head 的最前面。规范要求编码声明出现在文档的前 1024 字节内如果放在很后面浏览器在读到它之前已经按默认编码解析了一部分内容中文就可能变成乱码。这条规则不是建议是硬性要求我见过因为打包工具在 head 前面注入了大段注释导致编码声明超界的案例表现就是页面标题里的中文变问号。视口声明meta nameviewport contentwidthdevice-width, initial-scale1是移动端适配的起点。不写这一行移动浏览器会按 980px 的虚拟宽度渲染再整体缩小用户看到的是缩小版桌面页。这里有个常见误区是把initial-scale设成0.5或者加user-scalableno来防止用户缩放前者会导致布局计算错乱后者会伤害需要放大阅读的用户现在主流做法是只写 width 和 initial-scale 两个值。html langzh-CN这个属性被严重低估。它影响读屏软件的语音合成选择影响浏览器是否弹出翻译提示影响某些字体的字形选择比如中文和日文共用汉字时的字形差异。写错语言的页面读屏软件可能用英文音库去念中文效果惨不忍睹。多语言站点更是必须处理不要让所有页面都写同一个 lang。title 和 description 也值得认真对待。title 是搜索结果和浏览器标签页的标题建议控制在 30 个汉字以内把最重要的信息放前面。description 不直接影响排名但影响搜索结果里的摘要展示缺失时搜索引擎会自己从正文里截取截出来的内容往往很尴尬。2.3 body 结构划分的实用原则骨架搭到 body 这一层很多人直接开始写 div。我的建议是先想清楚页面的几个大区域站点级的头部、主导航、主要内容、侧边栏、站点级的尾部。这五块基本覆盖了绝大多数页面形态用对应的语义标签划分出来剩下的细节再往里填。划分的时候有个实用原则先确定唯一的 main。一个页面只应该有一个 main 元素它包裹的是这个页面独有的内容不包括重复出现在每个页面上的头部导航和页脚。这条规则带来的好处是读屏用户可以一键跳到主内容区跳过重复的导航噪音。做后台系统的时候尤其明显左侧菜单几十个链接如果没有 main键盘用户每次都要 Tab 几十下才能到内容区。另一个原则是区域之间不要互相嵌套。header 里再套 header、main 里再包一层 main都是不合规范的写法虽然浏览器能渲染但语义树就乱了。如果确实需要在一个区域内部再做区分用 section 或者带 aria-label 的 div而不是重复使用同名区域标签。3. 语义化标签不是加分项是基础盘3.1 语义化真正服务的是哪几类使用者谈语义化容易空对空我把受益方列清楚你就知道该不该花时间了。第一类是使用读屏软件的用户。读屏软件读的不是视觉呈现而是无障碍树。你写div onclick...提交/div它读出来就是提交用户不知道这可以点你写button提交/button它会读提交按钮用户知道可以按。这中间的差别不是体验优化是能不能用。第二类是键盘操作的用户。button、a、input 这些原生元素自带键盘可操作性Tab 能聚焦、Enter 或空格能触发。用 div 模拟的按钮需要手动加 tabindex、手动监听键盘事件、手动处理焦点样式漏一个就出问题。第三类是搜索引擎和各类抓取程序。它们解析 HTML 结构来理解页面主题h1 到 h6 的层级、article 的边界、time 标签里的时间都是它们判断内容重要性的依据。第四类是维护者包括三个月后的你自己。半年后回来改代码看到main和article能立刻回忆起页面结构看到满屏 div 就天真地以为在玩俄罗斯套娃。3.2 常用语义标签的选择对照表很多人不是不想用语义标签是不知道什么时候用哪个。我整理了一张对照表把容易混淆的几组放在一起比较。标签什么时候用什么时候别用header页面或某个区块的引导性内容通常含标题不要用它包整个页面也不要嵌套使用nav主要的导航链接组页脚里一两个零散链接不必用main页面独有的主体内容全页只能有一个不要用来包侧边栏或重复出现的区域article独立成篇、可单独分发的内容如一篇帖子不要把页面每个区块都标成 articlesection有主题的一段内容通常带标题没有标题、纯粹为了布局时用 divaside与主内容相关但可独立存在的补充信息不要用来放主要广告位figure figcaption图片、代码、图表配文字说明单纯装饰性图片不需要time机器可读的时间配 datetime 属性泛指最近这类模糊时间不必用strong / em表示重要性和语气强调只想加粗就用 CSS不要用 b 代替语义dl / dt / dd名值对的列表如术语表、参数表不要拿来当布局容器这张表最值得记的是 section 和 div 的区别。判断标准很简单这一段内容有没有一个能写出来的标题有就用 section没有就是纯布局容器用 div。按这个标准筛一遍你会发现大部分 div 其实该保留因为布局容器本来就该是 div语义标签不该被滥用。3.3 标题层级是语义化的骨架别乱跳h1 到 h6 构成文档的大纲读屏软件和部分工具都靠它来生成页面目录。三条规则值得记住。第一一个页面通常只有一个 h1就是这个页面的主标题。有些老教程说可以有多个 h1那是 HTML5 早期草案的遗留说法现在的实践共识是单个 h1 更清晰。第二层级不能跳。h2 下面直接出现 h4跳过了 h3大纲就断了。第三不要为了字号去选标题。觉得 h3 字太小想要 h2 的大小正确做法是写 h3 然后用 CSS 调整字号而不是直接换成 h2。我做过一次无障碍审查最普遍的问题不是缺 alt而是标题层级混乱。首页 h1 之后直接一堆 h4中间跳了两级。修起来其实很快但如果项目已经上线很久改动标题层级可能影响已有的样式选择器成本就上来了。所以这种习惯最好在项目初期就建立。还有一个细节不要用空标题占位。h2/h2这种写法会让读屏软件读出一个空条目用户会困惑。如果只是需要视觉上的间距用 CSS margin不要用空标签。4. 表单与交互元素最容易被低估的部分4.1 type 属性的选择直接决定移动端键盘移动端填表单最烦的是键盘不对。要填手机号弹出的却是全键盘要填邮箱找 符号要找半天。这个问题用对 type 就能解决。typetel调出数字键盘typeemail的键盘上带 和点号typeurl带斜杠typenumber带数字和负号typesearch的键盘回车键显示搜索。这些都是零成本的体验提升改一个属性就完事。但 number 有个坑要注意它允许输入字母 e科学计数法、允许滚动滚轮改变数值、在某些浏览器里还会显示上下箭头。如果你要的是纯数字输入比如验证码、手机号用typetext配合inputmodenumeric更稳既能调出数字键盘又不会有 number 的那些副作用。手机号还有个细节不要用 number因为手机号可能以 0 开头number 类型会把前导零吃掉。日期类字段也要注意。typedate在桌面浏览器上有原生日期选择器在部分移动端表现不一致各家样式差异较大。如果产品对日期选择器的样式有严格要求还是得用组件库但要记得保留typedate的语义可以在组件内部隐藏原生输入框不要直接用 div 模拟。4.2 label、name、id 三件套的关联关系这三个属性的分工经常被搞混我按作用分别说。label 负责这块输入框是干什么的。两种写法一是label forphone手机号/labelinput idphonefor 的值必须和 input 的 id 完全一致二是把 input 包在 label 里面。两种写法效果相同后者不需要 id但前者在复杂布局里更灵活。关联建立之后点击文字就能聚焦输入框移动端的可点区域也变大了这是实打实的体验提升。name 负责提交时这个字段叫什么。表单提交时浏览器把所有带 name 的控件按namevalue的形式序列化。没写 name 的控件值再正确也提交不上去。这个坑我踩过一次页面上明明填了内容后台就是收不到排查了半小时才发现某个字段漏了 name。id 负责这个元素在文档里的唯一标识。它被 label 的 for 引用被 JS 的 getElementById 查找被锚点链接跳转。同一页面里 id 不能重复重复了 label 可能关联到错误的元素上。顺带说个高频坑button 的 type 默认值是 submit。表单里如果有一个取消按钮没写 type点它会触发表单提交而不是取消。这个默认值的设计在 HTML 早期就定下来了改不了只能自己每次写 button 都显式加上typebutton或typesubmit。我现在的习惯是只要写 button 就先写 type省得回头找问题。4.3 原生校验能力远比你想的强很多人一上来就引校验库其实原生校验能覆盖大部分场景而且不增加包体积。required声明必填pattern配合正则做格式校验min、max、step约束数值范围minlength、maxlength限制长度。这些属性浏览器会直接处理校验不通过时阻止提交并给出提示气泡。组合使用有个示例手机号字段可以写typetel required pattern1[3-9]\d{9}配合inputmodenumeric移动端调数字键盘格式不对时浏览器直接拦下。注意 pattern 是整体匹配不需要写^和$写了反而可能匹配不到。不过原生校验有两个限制要清楚。一是提示文案不能自定义样式各浏览器长得不一样产品如果要求统一视觉还是得自己做校验 UI但可以保留原生属性作为兜底。二是校验只在提交时触发用户边输入边看到的实时反馈需要自己监听 input 事件。我的做法是原生属性全写上保证不写 JS 也有基本防护然后再用 JS 做增强提示两层配合。还有个容易被忽略的点novalidate属性。表单加上它就关闭了原生校验。什么时候用当你需要完全自定义校验流程并且希望在提交前做统一检查时。但加上之后记得自己把必填、格式这些都校验到别以为关掉就完事了。5. 资源加载相关的 HTML 细节5.1 script 的位置和 defer、async 的取舍脚本加载是最容易拖慢首屏的环节三个属性的行为必须搞清楚。默认的script src...会阻塞解析浏览器下载脚本的同时暂停 HTML 解析下载完立刻执行执行完才继续解析。放在 head 里的脚本会直接拖慢首屏因为 body 还没解析DOM 还不存在。defer让脚本异步下载等 HTML 解析完成后再按顺序执行。它保证执行顺序和书写顺序一致适合有依赖关系的脚本绝大多数业务脚本都该用它。async也异步下载但下载完立刻执行不保证顺序并且可能打断解析。它适合完全独立的第三方脚本比如统计代码。我之前遇到过一个问题两个脚本 A 依赖 B加了 async 之后偶尔报错说 B 未定义。原因就是 async 不保证顺序A 先下载完就先执行了。改成 defer 之后问题消失因为 defer 严格按书写顺序执行。还有一个位置问题。有些人习惯把 script 放在 body 末尾这是老办法目的是让 DOM 先解析完。现在有了 defer把 script 放在 head 里加 defer 效果一样而且更清晰因为资源声明集中在一处。我现在的写法是统一放 head 加 defer只有在需要极早执行的场景比如埋点初始化才用内联脚本。5.2 图片写法直接关系到布局稳定性和加载速度图片是页面里最容易造成布局抖动的元素。原因很简单浏览器在图片下载完成前不知道它的尺寸只能先按 0 高度占位图片加载完一撑开下面的内容全部往下跳。这个跳动有个专门指标叫累积布局偏移值越高用户体验越差。解决办法是给每张图显式写 width 和 height 属性。有了这两个值浏览器可以在图片加载前就按比例算出占位空间。注意这两个属性只影响占位比例实际显示尺寸还是由 CSS 控制所以不用担心写死了尺寸。现代浏览器还会根据这两个属性自动计算宽高比配合 CSS 的width: 100%; height: auto就能完美适配响应式。懒加载也很简单loadinglazy一个属性搞定。浏览器会等图片接近视口时才开始加载。但首屏图片不要加加了反而可能延迟显示。判断标准是用户打开页面就能看到的图别懒加载需要滚动才出现的图加上。响应式图片用 srcset 和 sizes 配合。srcset列出多个尺寸的图片地址和对应的宽度描述符sizes告诉浏览器不同视口下图片的显示宽度浏览器据此选择最合适的那张。这个机制省流量效果明显尤其是在移动端。写法上有一点要注意如果用了srcset里的w描述符就必须同时提供sizes否则浏览器不知道该怎么选。5.3 预加载提示用对了加速用错了拖慢link relpreload让浏览器提前加载某个资源适合那些藏在 CSS 或 JS 里、优先级被低估的关键资源比如首屏字体、首屏大图。用法是link relpreload href... asfont typefont/woff2 crossorigin。字体有个坑跨域字体必须加 crossorigin否则预加载的请求和实际请求的凭据模式不一致浏览器会重复下载两次。link relprefetch是预测性加载告诉浏览器下一个页面可能要用这个资源空闲时帮我下一下。它不影响当前页性能适合用在列表页预取详情页的资源。但别滥用一次预取太多会抢带宽。link relpreconnect提前和目标域名建立连接包括 DNS 解析、TCP 握手、TLS 握手。适合用在页面确定会请求的第三方域名上比如字体服务、CDN 域名。一个域名大概能省 100 到 300 毫秒视网络环境而定。但连接数是有限的同时预连接太多域名反而会造成资源竞争控制在三到四个以内。link reldns-prefetch只做 DNS 解析比 preconnect 轻量可以作为 preconnect 的降级方案一起写老浏览器不认 preconnect 就只做 DNS。这些提示不是越多越好。我见过一个页面加了十几个 preload结果把所有资源的优先级都拉平了关键资源反而不突出了。正确的思路是只给最关键的一到三个资源加提示其他交给浏览器自己判断。6. 动手实操从零写一个结构完整的页面骨架6.1 分步搭建的过程记录光看理论容易忘我带你走一遍完整流程。假设要做一个内容站点的文章详情页从空文件开始。第一步写文档声明和语言属性。!DOCTYPE html之后接html langzh-CN。这两行决定了渲染模式和语言环境先写上去。第二步搭 head。顺序上我把 charset 放第一个然后是 viewport再是 title、description最后是资源引用。这个顺序不是随便排的charset 必须在前 1024 字节内viewport 越早越好因为影响布局计算title 和 description 属于元信息可以稍后。!DOCTYPE html html langzh-CN head meta charsetutf-8 meta nameviewport contentwidthdevice-width, initial-scale1 title页面主题 - 站点名称/title meta namedescription content一句话概括本页内容控制在 80 字以内 link relstylesheet href/css/base.css script src/js/app.js defer/script /head第三步划分 body 的五大区域。header 里放站点标识和主导航main 里放文章主体article 包住文章内容本身aside 放相关推荐footer 放版权和次级链接。body header a href/站点名称/a nav aria-label主导航 ul lia href/首页/a/li lia href/archive归档/a/li /ul /nav /header main article h1文章标题/h1 p发表时间 time datetime2024-05-012024 年 5 月 1 日/time/p p正文段落……/p /article /main aside aria-label相关推荐 h2你可能还想看/h2 ul lia href/post/1另一篇文章/a/li /ul /aside footer p站点信息/p /footer /body /html第四步补充交互细节。导航加aria-label是因为页面可能有多个 nav主导航、面包屑、页脚导航需要区分。aside 同理。这些属性不改变视觉但让辅助技术能准确描述。第五步处理图片和媒体。文章里的配图统一写 width、height、alt需要懒加载的加loadinglazy。figure img src/img/demo.jpg alt示意图页面结构的层级关系 width800 height450 loadinglazy figcaption图 1区域划分示意/figcaption /figurealt 的写法有讲究。它是图片内容的替代文本不是图片标题。装饰性图片写alt空字符串告诉读屏软件跳过它。有信息量的图片要描述它传达的信息而不是一张图片。6.2 写完之后的校验清单骨架写完不算完我习惯跑一遍检查。下面这张清单是我自己每次都会过的。检查项具体做法常见问题渲染模式控制台看document.compatMode返回值不是 CSS1Compat大纲结构用开发者工具的辅助功能面板看标题树层级跳跃、多个 h1图片替代文本逐个确认 alt 语义准确缺失、写成文件名表单可提交性提交后看请求体字段是否齐全漏写 name键盘可达性只用 Tab 和 Enter 走完页面自定义控件无法聚焦布局稳定性网络面板限速刷新观察跳动图片未写宽高编码正确性页面标题、正文中文显示正常charset 位置过靠后这套检查做下来大概五分钟但能拦掉大部分线上会暴露的问题。我现在养成习惯页面骨架写完先跑一遍比上线后返工划算太多。7. 常见问题与排查技巧实录7.1 高频问题速查表我把这几年被问得最多、自己也踩过的问题整理成表遇到症状直接对照。症状可能原因排查手段中文变乱码charset 缺失或位置靠后看源码前 1024 字节内是否有编码声明移动端显示成缩小版桌面页缺 viewport 声明检查 head 里是否有视口标签点击文字输入框不聚焦label 的 for 和 input 的 id 不一致核对两处字符串表单提交后字段缺失控件没写 name检查请求体对比页面字段取消按钮触发了提交button 默认 type 是 submit显式写typebutton图片加载时页面跳动未写 width 和 height补齐宽高属性脚本报错找不到元素脚本执行早于 DOM 解析改用 defer 或调整位置样式部分生效部分不生效处于怪异模式检查 compatMode标签嵌套看起来没问题但 DOM 变形浏览器自动修正了非法嵌套对比源码与元素面板的树结构一个页面出现多个 main组件复用时没注意全局搜索 main 标签表格里最值得展开的是DOM 变形这一条。浏览器的容错能力意味着它能接受很多非法写法但会按规范修正。典型情况有三类段落里嵌块级元素p内放div浏览器会把 div 提到 p 外面导致你以为的父元素其实是兄弟元素表格内直接放非表格内容浏览器会把内容挪到表格前面列表里直接放文本或非 li 元素虽然不会挪动但结构不合法。排查方法很直接右键检查元素在开发者工具的元素面板里看实际 DOM 树和源码对比。如果两者结构不一样说明被修正了回去改源码。7.2 我常用的几个排查习惯第一个习惯是遇到样式问题先看渲染模式。刚才说过document.compatMode这行代码花不了两秒但能排除一整类问题。我见过有人为了一个盒模型问题排查了两个小时最后发现是模板引擎在 DOCTYPE 前面注入了空白。第二个习惯是用大纲视角看页面。开发者工具里能看辅助功能树或者用浏览器的阅读模式预览。阅读模式会剥离样式只保留结构如果阅读模式下内容顺序混乱、标题层级断裂说明你的 HTML 结构有问题。这个视角比盯着视觉效果更容易发现语义缺陷。第三个习惯是限速测试。把网络调成 3G 慢速刷新页面观察图片加载时的跳动、字体切换时的闪烁、脚本执行造成的白屏。这些在高速网络下都看不出来一上线用户就抱怨。限速测试花的时间不多收益很直接。第四个习惯是键盘走查。关掉鼠标只用 Tab、ShiftTab、Enter、空格、方向键操作页面。走不通的地方就是无障碍问题。这个测试不需要任何工具成本极低但能发现大量问题。我刚开始做的时候自己的页面连 Tab 都进不去表单那次印象很深。第五个习惯是提交前检查请求体。打开网络面板实际提交一次表单看请求里带了哪些字段、值对不对。比在页面上看直观得多尤其是复选框、多选这类字段页面上选中了不代表提交上去了。7.3 几个不写在文档里的经验关于注释。HTML 注释会影响页面体积生产环境通常会被构建工具去掉但开发阶段的注释很有价值。我的习惯是在每个大区域开始处写一行注释标明区域名比如!-- 主导航 --不是为了给别人看是为了自己在几百行代码里快速定位。关于自闭合写法。img /和img在 HTML 里等价前者是 XHTML 时代的习惯。现在两种写法都能用团队内部统一就行别在一个文件里混着写。关于属性顺序。规范没有要求但我习惯按重要性排id、class、data 属性、src 或 href、alt 或 title、宽高、其他。这么排的好处是扫一眼就能看到关键信息尤其是排查图片问题时alt 和宽高挨在一起看很快。关于空白字符。HTML 里连续空白会被折叠成一个空格这个大家都知道。但行内元素之间的换行会产生一个空格间隙在布局精密的地方会造成几像素的偏差。解决办法是把行内元素写在一行或者用父元素的 font-size 设为 0 再给子元素恢复后者略脏但有效。现在有了 flex 布局这个问题基本消失了因为 flex 容器的直接子元素之间的空白不再影响布局。关于过时标签。center、font、marquee、big 这些都不要再用了浏览器虽然还支持但它们是历史遗留。同理用 table 做布局也不建议table 只用于表格数据。我维护过一个老项目满屏 table 布局改一个宽度要动十几处那种痛苦一次就够了。8. 一点个人的收尾经验写到这里基础篇的第一部分差不多覆盖了日常最常用的部分。我自己回顾这几年的经历HTML 这块能力真正区分水平的不是记住了多少标签而是遇到问题时知道往哪一层找。样式不对先看渲染模式交互不灵先看是不是用了原生元素加载慢先看资源提示和脚本位置这些判断路径形成了排查效率就上来了。有个小技巧分享一下每次接手新项目我会花十分钟把首页的 HTML 源码通读一遍看 DOCTYPE、看 charset、看视口、看标题层级、看图片 alt。十分钟能大致判断出这个项目的代码素养也能提前预判哪些地方会有坑。这个习惯帮我省下了不少后来排查问题的时间。下一篇会继续往深走聊表单的进阶用法、无障碍属性的实战细节以及 HTML 和 CSS、JS 交界处那些容易出问题的边界情况。基础这东西看着简单真往下挖能挖出很多平时想不到的细节慢慢来。
上一次有个做前端的朋友跟我聊说 HTML 这东西三天就能背完为什么还要单独拎出来复习。我没直接反驳让他把手上那个页面的源码发我看看。打开一看满屏的 div一层套一层二十几个 div 里找不出一个 header表单输入框全靠 placeholder 提示图片全都没有 alt。页面在浏览器里显示得好好的可它在读屏软件里几乎等于一堆乱码在搜索引擎眼里抓不到重点换个人接手维护就得重新猜每个 div 是干嘛的。这就是我想写这组 web 前端进阶内容的原因。很多人往上加技能是从框架开始的但真正卡住天花板的往往是 HTML 基础没打牢。这篇是基础篇的第一篇只谈 HTML 本身文档骨架怎么搭、语义化标签怎么选、表单怎么写得不出错、资源怎么加载才不拖后腿。不管你是刚接触前端的新人还是写了两年框架却没仔细翻过官方文档的人把这一篇的内容落到手上的代码里质量能往上提一截。1. 先看清 HTML 在前端体系里的真实分量1.1 它是唯一一层无法被替代的结构描述浏览器拿到一个页面做的第一件事是字节流解析把收到的字节按编码解码成字符词法分析器把字符切成一个个标签记号再交给树构建器拼成 DOM 树。CSS 会被解析成 CSSOM两者合并成渲染树才有了后面的布局和绘制。这一整套流程的输入只有一个就是 HTML。CSS 可以换预处理器JS 可以换框架构建工具可以来回换但最终浏览器认识的结构描述语言只有 HTML没有第二条路。理解了这一点很多取舍就清楚了。为什么框架的模板最后都要编译成渲染函数去创建 DOM 节点因为浏览器只认这个。为什么同构渲染要做 hydration因为服务端吐出来的 HTML 只是静态结构事件绑定需要客户端再接管一次。这些看起来很高深的概念往下追一层都是在处理HTML 结构怎么生成、怎么复用、怎么和 JS 状态对齐的问题。我见过一些同学写框架写得很熟但一旦遇到为什么我的样式在服务端渲染的首屏里会闪一下、为什么爬虫抓不到我的内容这类问题就卡住。卡点不在框架在于对 HTML 这一层的运行机制没有概念。所以进阶的第一步不是学新东西是把这层地基重新夯实。1.2 新手最容易踩的三个认知偏差第一个偏差是把 HTML 当成能显示就行的语言。只要浏览器画出来了就认为写对了。实际上浏览器对错误的 HTML 有极强的容错能力它会自动补全、自动闭合、自动挪动节点。你写pdivxx/div/p浏览器不会报错它会默默地把 div 提到 p 外面去。这种容错是好事也是坑你的源码和实际 DOM 对不上调试的时候就会怀疑人生。第二个偏差是认为语义化标签只是为了 SEO。SEO 确实受益但语义化的第一受益人是读屏软件用户、键盘操作用户以及未来接手这个项目的人。一个用 nav 包起来的导航区读屏软件可以直接跳转一堆 div 堆起来的导航用户只能一个一个听过去。这是功能差异不是风格差异。第三个偏差是觉得表单写起来没技术含量。实际上表单是最容易出无障碍问题、最容易出移动端兼容问题、也最容易出现提交了但后台收不到数据的地方。后面第 4 节会展开讲这里先记住一句话表单的每个属性都有它存在的理由不写 name 就是收不到数据不写 type 就可能出现意料之外的校验行为。1.3 这套基础能力在什么场景下会立刻变现说几个我实际遇到过的场景。做管理后台的时候产品要求键盘 Tab 键能走完整个表单这时候 label 和 tabindex 的基本功直接决定你要不要返工。做营销落地页的时候首屏加载慢导致跳出率高排查下来是几张首屏大图没写宽高属性造成布局抖动加了 width 和 height 之后指标立刻好转。做内容型站点的时候搜索结果里显示的摘要不对是因为 meta description 缺失或者重复。这些都不是高深问题但它们的共同点是出问题的地方都在最底层解决方式也都在最底层。框架帮不了你构建工具帮不了你只有你自己知道该写什么。2. 文档骨架从第一行到 body 的每一层都有讲究2.1 DOCTYPE 不是装饰它决定浏览器的渲染模式每个 HTML 文件第一行应该是!DOCTYPE html。这一行看起来像一句咒语实际作用是告诉浏览器按标准模式渲染我。如果不写或者写错成老式的一长串声明浏览器可能进入怪异模式quirks mode此时盒模型的计算方式、行高的解析规则、百分比高度的基准都会发生变化。我见过最典型的怪异模式症状是给元素设了width: 100px; padding: 10px;在标准模式下元素总宽是 120px在怪异模式下总宽还是 100px内容区被压缩成 80px。同一份 CSS 在两台机器上表现不一样新手会怀疑是浏览器版本问题实际上是文档开头少了那一行。判断当前页面处于哪种模式很简单在控制台执行document.compatMode返回CSS1Compat是标准模式返回BackCompat就是怪异模式。这个检查我建议在排查任何样式莫名不对的问题时都先做一遍成本极低能排除一大类干扰。另外补充一个细节!DOCTYPE html必须出现在文档的最前面前面不能有任何内容包括空格和注释。严格来说注释在前面是允许的但部分老浏览器会因此触发怪异模式所以最稳妥的写法就是让它成为文件的第一个字符。2.2 head 里那些容易被跳过的关键标签head 区域是新手最容易糊弄过去的地方通常只留一个 title 和一个 charset 就完事。实际上这里有几个标签直接影响页面行为和线上表现。字符编码meta charsetutf-8必须放在 head 的最前面。规范要求编码声明出现在文档的前 1024 字节内如果放在很后面浏览器在读到它之前已经按默认编码解析了一部分内容中文就可能变成乱码。这条规则不是建议是硬性要求我见过因为打包工具在 head 前面注入了大段注释导致编码声明超界的案例表现就是页面标题里的中文变问号。视口声明meta nameviewport contentwidthdevice-width, initial-scale1是移动端适配的起点。不写这一行移动浏览器会按 980px 的虚拟宽度渲染再整体缩小用户看到的是缩小版桌面页。这里有个常见误区是把initial-scale设成0.5或者加user-scalableno来防止用户缩放前者会导致布局计算错乱后者会伤害需要放大阅读的用户现在主流做法是只写 width 和 initial-scale 两个值。html langzh-CN这个属性被严重低估。它影响读屏软件的语音合成选择影响浏览器是否弹出翻译提示影响某些字体的字形选择比如中文和日文共用汉字时的字形差异。写错语言的页面读屏软件可能用英文音库去念中文效果惨不忍睹。多语言站点更是必须处理不要让所有页面都写同一个 lang。title 和 description 也值得认真对待。title 是搜索结果和浏览器标签页的标题建议控制在 30 个汉字以内把最重要的信息放前面。description 不直接影响排名但影响搜索结果里的摘要展示缺失时搜索引擎会自己从正文里截取截出来的内容往往很尴尬。2.3 body 结构划分的实用原则骨架搭到 body 这一层很多人直接开始写 div。我的建议是先想清楚页面的几个大区域站点级的头部、主导航、主要内容、侧边栏、站点级的尾部。这五块基本覆盖了绝大多数页面形态用对应的语义标签划分出来剩下的细节再往里填。划分的时候有个实用原则先确定唯一的 main。一个页面只应该有一个 main 元素它包裹的是这个页面独有的内容不包括重复出现在每个页面上的头部导航和页脚。这条规则带来的好处是读屏用户可以一键跳到主内容区跳过重复的导航噪音。做后台系统的时候尤其明显左侧菜单几十个链接如果没有 main键盘用户每次都要 Tab 几十下才能到内容区。另一个原则是区域之间不要互相嵌套。header 里再套 header、main 里再包一层 main都是不合规范的写法虽然浏览器能渲染但语义树就乱了。如果确实需要在一个区域内部再做区分用 section 或者带 aria-label 的 div而不是重复使用同名区域标签。3. 语义化标签不是加分项是基础盘3.1 语义化真正服务的是哪几类使用者谈语义化容易空对空我把受益方列清楚你就知道该不该花时间了。第一类是使用读屏软件的用户。读屏软件读的不是视觉呈现而是无障碍树。你写div onclick...提交/div它读出来就是提交用户不知道这可以点你写button提交/button它会读提交按钮用户知道可以按。这中间的差别不是体验优化是能不能用。第二类是键盘操作的用户。button、a、input 这些原生元素自带键盘可操作性Tab 能聚焦、Enter 或空格能触发。用 div 模拟的按钮需要手动加 tabindex、手动监听键盘事件、手动处理焦点样式漏一个就出问题。第三类是搜索引擎和各类抓取程序。它们解析 HTML 结构来理解页面主题h1 到 h6 的层级、article 的边界、time 标签里的时间都是它们判断内容重要性的依据。第四类是维护者包括三个月后的你自己。半年后回来改代码看到main和article能立刻回忆起页面结构看到满屏 div 就天真地以为在玩俄罗斯套娃。3.2 常用语义标签的选择对照表很多人不是不想用语义标签是不知道什么时候用哪个。我整理了一张对照表把容易混淆的几组放在一起比较。标签什么时候用什么时候别用header页面或某个区块的引导性内容通常含标题不要用它包整个页面也不要嵌套使用nav主要的导航链接组页脚里一两个零散链接不必用main页面独有的主体内容全页只能有一个不要用来包侧边栏或重复出现的区域article独立成篇、可单独分发的内容如一篇帖子不要把页面每个区块都标成 articlesection有主题的一段内容通常带标题没有标题、纯粹为了布局时用 divaside与主内容相关但可独立存在的补充信息不要用来放主要广告位figure figcaption图片、代码、图表配文字说明单纯装饰性图片不需要time机器可读的时间配 datetime 属性泛指最近这类模糊时间不必用strong / em表示重要性和语气强调只想加粗就用 CSS不要用 b 代替语义dl / dt / dd名值对的列表如术语表、参数表不要拿来当布局容器这张表最值得记的是 section 和 div 的区别。判断标准很简单这一段内容有没有一个能写出来的标题有就用 section没有就是纯布局容器用 div。按这个标准筛一遍你会发现大部分 div 其实该保留因为布局容器本来就该是 div语义标签不该被滥用。3.3 标题层级是语义化的骨架别乱跳h1 到 h6 构成文档的大纲读屏软件和部分工具都靠它来生成页面目录。三条规则值得记住。第一一个页面通常只有一个 h1就是这个页面的主标题。有些老教程说可以有多个 h1那是 HTML5 早期草案的遗留说法现在的实践共识是单个 h1 更清晰。第二层级不能跳。h2 下面直接出现 h4跳过了 h3大纲就断了。第三不要为了字号去选标题。觉得 h3 字太小想要 h2 的大小正确做法是写 h3 然后用 CSS 调整字号而不是直接换成 h2。我做过一次无障碍审查最普遍的问题不是缺 alt而是标题层级混乱。首页 h1 之后直接一堆 h4中间跳了两级。修起来其实很快但如果项目已经上线很久改动标题层级可能影响已有的样式选择器成本就上来了。所以这种习惯最好在项目初期就建立。还有一个细节不要用空标题占位。h2/h2这种写法会让读屏软件读出一个空条目用户会困惑。如果只是需要视觉上的间距用 CSS margin不要用空标签。4. 表单与交互元素最容易被低估的部分4.1 type 属性的选择直接决定移动端键盘移动端填表单最烦的是键盘不对。要填手机号弹出的却是全键盘要填邮箱找 符号要找半天。这个问题用对 type 就能解决。typetel调出数字键盘typeemail的键盘上带 和点号typeurl带斜杠typenumber带数字和负号typesearch的键盘回车键显示搜索。这些都是零成本的体验提升改一个属性就完事。但 number 有个坑要注意它允许输入字母 e科学计数法、允许滚动滚轮改变数值、在某些浏览器里还会显示上下箭头。如果你要的是纯数字输入比如验证码、手机号用typetext配合inputmodenumeric更稳既能调出数字键盘又不会有 number 的那些副作用。手机号还有个细节不要用 number因为手机号可能以 0 开头number 类型会把前导零吃掉。日期类字段也要注意。typedate在桌面浏览器上有原生日期选择器在部分移动端表现不一致各家样式差异较大。如果产品对日期选择器的样式有严格要求还是得用组件库但要记得保留typedate的语义可以在组件内部隐藏原生输入框不要直接用 div 模拟。4.2 label、name、id 三件套的关联关系这三个属性的分工经常被搞混我按作用分别说。label 负责这块输入框是干什么的。两种写法一是label forphone手机号/labelinput idphonefor 的值必须和 input 的 id 完全一致二是把 input 包在 label 里面。两种写法效果相同后者不需要 id但前者在复杂布局里更灵活。关联建立之后点击文字就能聚焦输入框移动端的可点区域也变大了这是实打实的体验提升。name 负责提交时这个字段叫什么。表单提交时浏览器把所有带 name 的控件按namevalue的形式序列化。没写 name 的控件值再正确也提交不上去。这个坑我踩过一次页面上明明填了内容后台就是收不到排查了半小时才发现某个字段漏了 name。id 负责这个元素在文档里的唯一标识。它被 label 的 for 引用被 JS 的 getElementById 查找被锚点链接跳转。同一页面里 id 不能重复重复了 label 可能关联到错误的元素上。顺带说个高频坑button 的 type 默认值是 submit。表单里如果有一个取消按钮没写 type点它会触发表单提交而不是取消。这个默认值的设计在 HTML 早期就定下来了改不了只能自己每次写 button 都显式加上typebutton或typesubmit。我现在的习惯是只要写 button 就先写 type省得回头找问题。4.3 原生校验能力远比你想的强很多人一上来就引校验库其实原生校验能覆盖大部分场景而且不增加包体积。required声明必填pattern配合正则做格式校验min、max、step约束数值范围minlength、maxlength限制长度。这些属性浏览器会直接处理校验不通过时阻止提交并给出提示气泡。组合使用有个示例手机号字段可以写typetel required pattern1[3-9]\d{9}配合inputmodenumeric移动端调数字键盘格式不对时浏览器直接拦下。注意 pattern 是整体匹配不需要写^和$写了反而可能匹配不到。不过原生校验有两个限制要清楚。一是提示文案不能自定义样式各浏览器长得不一样产品如果要求统一视觉还是得自己做校验 UI但可以保留原生属性作为兜底。二是校验只在提交时触发用户边输入边看到的实时反馈需要自己监听 input 事件。我的做法是原生属性全写上保证不写 JS 也有基本防护然后再用 JS 做增强提示两层配合。还有个容易被忽略的点novalidate属性。表单加上它就关闭了原生校验。什么时候用当你需要完全自定义校验流程并且希望在提交前做统一检查时。但加上之后记得自己把必填、格式这些都校验到别以为关掉就完事了。5. 资源加载相关的 HTML 细节5.1 script 的位置和 defer、async 的取舍脚本加载是最容易拖慢首屏的环节三个属性的行为必须搞清楚。默认的script src...会阻塞解析浏览器下载脚本的同时暂停 HTML 解析下载完立刻执行执行完才继续解析。放在 head 里的脚本会直接拖慢首屏因为 body 还没解析DOM 还不存在。defer让脚本异步下载等 HTML 解析完成后再按顺序执行。它保证执行顺序和书写顺序一致适合有依赖关系的脚本绝大多数业务脚本都该用它。async也异步下载但下载完立刻执行不保证顺序并且可能打断解析。它适合完全独立的第三方脚本比如统计代码。我之前遇到过一个问题两个脚本 A 依赖 B加了 async 之后偶尔报错说 B 未定义。原因就是 async 不保证顺序A 先下载完就先执行了。改成 defer 之后问题消失因为 defer 严格按书写顺序执行。还有一个位置问题。有些人习惯把 script 放在 body 末尾这是老办法目的是让 DOM 先解析完。现在有了 defer把 script 放在 head 里加 defer 效果一样而且更清晰因为资源声明集中在一处。我现在的写法是统一放 head 加 defer只有在需要极早执行的场景比如埋点初始化才用内联脚本。5.2 图片写法直接关系到布局稳定性和加载速度图片是页面里最容易造成布局抖动的元素。原因很简单浏览器在图片下载完成前不知道它的尺寸只能先按 0 高度占位图片加载完一撑开下面的内容全部往下跳。这个跳动有个专门指标叫累积布局偏移值越高用户体验越差。解决办法是给每张图显式写 width 和 height 属性。有了这两个值浏览器可以在图片加载前就按比例算出占位空间。注意这两个属性只影响占位比例实际显示尺寸还是由 CSS 控制所以不用担心写死了尺寸。现代浏览器还会根据这两个属性自动计算宽高比配合 CSS 的width: 100%; height: auto就能完美适配响应式。懒加载也很简单loadinglazy一个属性搞定。浏览器会等图片接近视口时才开始加载。但首屏图片不要加加了反而可能延迟显示。判断标准是用户打开页面就能看到的图别懒加载需要滚动才出现的图加上。响应式图片用 srcset 和 sizes 配合。srcset列出多个尺寸的图片地址和对应的宽度描述符sizes告诉浏览器不同视口下图片的显示宽度浏览器据此选择最合适的那张。这个机制省流量效果明显尤其是在移动端。写法上有一点要注意如果用了srcset里的w描述符就必须同时提供sizes否则浏览器不知道该怎么选。5.3 预加载提示用对了加速用错了拖慢link relpreload让浏览器提前加载某个资源适合那些藏在 CSS 或 JS 里、优先级被低估的关键资源比如首屏字体、首屏大图。用法是link relpreload href... asfont typefont/woff2 crossorigin。字体有个坑跨域字体必须加 crossorigin否则预加载的请求和实际请求的凭据模式不一致浏览器会重复下载两次。link relprefetch是预测性加载告诉浏览器下一个页面可能要用这个资源空闲时帮我下一下。它不影响当前页性能适合用在列表页预取详情页的资源。但别滥用一次预取太多会抢带宽。link relpreconnect提前和目标域名建立连接包括 DNS 解析、TCP 握手、TLS 握手。适合用在页面确定会请求的第三方域名上比如字体服务、CDN 域名。一个域名大概能省 100 到 300 毫秒视网络环境而定。但连接数是有限的同时预连接太多域名反而会造成资源竞争控制在三到四个以内。link reldns-prefetch只做 DNS 解析比 preconnect 轻量可以作为 preconnect 的降级方案一起写老浏览器不认 preconnect 就只做 DNS。这些提示不是越多越好。我见过一个页面加了十几个 preload结果把所有资源的优先级都拉平了关键资源反而不突出了。正确的思路是只给最关键的一到三个资源加提示其他交给浏览器自己判断。6. 动手实操从零写一个结构完整的页面骨架6.1 分步搭建的过程记录光看理论容易忘我带你走一遍完整流程。假设要做一个内容站点的文章详情页从空文件开始。第一步写文档声明和语言属性。!DOCTYPE html之后接html langzh-CN。这两行决定了渲染模式和语言环境先写上去。第二步搭 head。顺序上我把 charset 放第一个然后是 viewport再是 title、description最后是资源引用。这个顺序不是随便排的charset 必须在前 1024 字节内viewport 越早越好因为影响布局计算title 和 description 属于元信息可以稍后。!DOCTYPE html html langzh-CN head meta charsetutf-8 meta nameviewport contentwidthdevice-width, initial-scale1 title页面主题 - 站点名称/title meta namedescription content一句话概括本页内容控制在 80 字以内 link relstylesheet href/css/base.css script src/js/app.js defer/script /head第三步划分 body 的五大区域。header 里放站点标识和主导航main 里放文章主体article 包住文章内容本身aside 放相关推荐footer 放版权和次级链接。body header a href/站点名称/a nav aria-label主导航 ul lia href/首页/a/li lia href/archive归档/a/li /ul /nav /header main article h1文章标题/h1 p发表时间 time datetime2024-05-012024 年 5 月 1 日/time/p p正文段落……/p /article /main aside aria-label相关推荐 h2你可能还想看/h2 ul lia href/post/1另一篇文章/a/li /ul /aside footer p站点信息/p /footer /body /html第四步补充交互细节。导航加aria-label是因为页面可能有多个 nav主导航、面包屑、页脚导航需要区分。aside 同理。这些属性不改变视觉但让辅助技术能准确描述。第五步处理图片和媒体。文章里的配图统一写 width、height、alt需要懒加载的加loadinglazy。figure img src/img/demo.jpg alt示意图页面结构的层级关系 width800 height450 loadinglazy figcaption图 1区域划分示意/figcaption /figurealt 的写法有讲究。它是图片内容的替代文本不是图片标题。装饰性图片写alt空字符串告诉读屏软件跳过它。有信息量的图片要描述它传达的信息而不是一张图片。6.2 写完之后的校验清单骨架写完不算完我习惯跑一遍检查。下面这张清单是我自己每次都会过的。检查项具体做法常见问题渲染模式控制台看document.compatMode返回值不是 CSS1Compat大纲结构用开发者工具的辅助功能面板看标题树层级跳跃、多个 h1图片替代文本逐个确认 alt 语义准确缺失、写成文件名表单可提交性提交后看请求体字段是否齐全漏写 name键盘可达性只用 Tab 和 Enter 走完页面自定义控件无法聚焦布局稳定性网络面板限速刷新观察跳动图片未写宽高编码正确性页面标题、正文中文显示正常charset 位置过靠后这套检查做下来大概五分钟但能拦掉大部分线上会暴露的问题。我现在养成习惯页面骨架写完先跑一遍比上线后返工划算太多。7. 常见问题与排查技巧实录7.1 高频问题速查表我把这几年被问得最多、自己也踩过的问题整理成表遇到症状直接对照。症状可能原因排查手段中文变乱码charset 缺失或位置靠后看源码前 1024 字节内是否有编码声明移动端显示成缩小版桌面页缺 viewport 声明检查 head 里是否有视口标签点击文字输入框不聚焦label 的 for 和 input 的 id 不一致核对两处字符串表单提交后字段缺失控件没写 name检查请求体对比页面字段取消按钮触发了提交button 默认 type 是 submit显式写typebutton图片加载时页面跳动未写 width 和 height补齐宽高属性脚本报错找不到元素脚本执行早于 DOM 解析改用 defer 或调整位置样式部分生效部分不生效处于怪异模式检查 compatMode标签嵌套看起来没问题但 DOM 变形浏览器自动修正了非法嵌套对比源码与元素面板的树结构一个页面出现多个 main组件复用时没注意全局搜索 main 标签表格里最值得展开的是DOM 变形这一条。浏览器的容错能力意味着它能接受很多非法写法但会按规范修正。典型情况有三类段落里嵌块级元素p内放div浏览器会把 div 提到 p 外面导致你以为的父元素其实是兄弟元素表格内直接放非表格内容浏览器会把内容挪到表格前面列表里直接放文本或非 li 元素虽然不会挪动但结构不合法。排查方法很直接右键检查元素在开发者工具的元素面板里看实际 DOM 树和源码对比。如果两者结构不一样说明被修正了回去改源码。7.2 我常用的几个排查习惯第一个习惯是遇到样式问题先看渲染模式。刚才说过document.compatMode这行代码花不了两秒但能排除一整类问题。我见过有人为了一个盒模型问题排查了两个小时最后发现是模板引擎在 DOCTYPE 前面注入了空白。第二个习惯是用大纲视角看页面。开发者工具里能看辅助功能树或者用浏览器的阅读模式预览。阅读模式会剥离样式只保留结构如果阅读模式下内容顺序混乱、标题层级断裂说明你的 HTML 结构有问题。这个视角比盯着视觉效果更容易发现语义缺陷。第三个习惯是限速测试。把网络调成 3G 慢速刷新页面观察图片加载时的跳动、字体切换时的闪烁、脚本执行造成的白屏。这些在高速网络下都看不出来一上线用户就抱怨。限速测试花的时间不多收益很直接。第四个习惯是键盘走查。关掉鼠标只用 Tab、ShiftTab、Enter、空格、方向键操作页面。走不通的地方就是无障碍问题。这个测试不需要任何工具成本极低但能发现大量问题。我刚开始做的时候自己的页面连 Tab 都进不去表单那次印象很深。第五个习惯是提交前检查请求体。打开网络面板实际提交一次表单看请求里带了哪些字段、值对不对。比在页面上看直观得多尤其是复选框、多选这类字段页面上选中了不代表提交上去了。7.3 几个不写在文档里的经验关于注释。HTML 注释会影响页面体积生产环境通常会被构建工具去掉但开发阶段的注释很有价值。我的习惯是在每个大区域开始处写一行注释标明区域名比如!-- 主导航 --不是为了给别人看是为了自己在几百行代码里快速定位。关于自闭合写法。img /和img在 HTML 里等价前者是 XHTML 时代的习惯。现在两种写法都能用团队内部统一就行别在一个文件里混着写。关于属性顺序。规范没有要求但我习惯按重要性排id、class、data 属性、src 或 href、alt 或 title、宽高、其他。这么排的好处是扫一眼就能看到关键信息尤其是排查图片问题时alt 和宽高挨在一起看很快。关于空白字符。HTML 里连续空白会被折叠成一个空格这个大家都知道。但行内元素之间的换行会产生一个空格间隙在布局精密的地方会造成几像素的偏差。解决办法是把行内元素写在一行或者用父元素的 font-size 设为 0 再给子元素恢复后者略脏但有效。现在有了 flex 布局这个问题基本消失了因为 flex 容器的直接子元素之间的空白不再影响布局。关于过时标签。center、font、marquee、big 这些都不要再用了浏览器虽然还支持但它们是历史遗留。同理用 table 做布局也不建议table 只用于表格数据。我维护过一个老项目满屏 table 布局改一个宽度要动十几处那种痛苦一次就够了。8. 一点个人的收尾经验写到这里基础篇的第一部分差不多覆盖了日常最常用的部分。我自己回顾这几年的经历HTML 这块能力真正区分水平的不是记住了多少标签而是遇到问题时知道往哪一层找。样式不对先看渲染模式交互不灵先看是不是用了原生元素加载慢先看资源提示和脚本位置这些判断路径形成了排查效率就上来了。有个小技巧分享一下每次接手新项目我会花十分钟把首页的 HTML 源码通读一遍看 DOCTYPE、看 charset、看视口、看标题层级、看图片 alt。十分钟能大致判断出这个项目的代码素养也能提前预判哪些地方会有坑。这个习惯帮我省下了不少后来排查问题的时间。下一篇会继续往深走聊表单的进阶用法、无障碍属性的实战细节以及 HTML 和 CSS、JS 交界处那些容易出问题的边界情况。基础这东西看着简单真往下挖能挖出很多平时想不到的细节慢慢来。
