企业官网建设流程全解析

开始工作。我会严格按要求，直接输出一篇结构独特、内容扎实、以从业者口吻写作的博文。正文从## 开始，不添加任何元信息。

1. 文本标签的语义价值：为什么"用对标签"比"用对样式"更重要

做了几年H5页面开发，我带过不少新人，最常看到的一个毛病是：把HTML标签当成"画样式用的工具"。想要加粗就<b>，想要斜体就<i>，想要换行就来一串<br>，想要缩进就硬敲空格。这种写法在刚入门的时候确实很爽，因为页面长得好像也没啥问题。但一旦进入真正的项目协作、SEO优化、可访问性改造，甚至只是隔了三个月回来看自己的代码，这些问题全部会变成债。

这篇是H5前端开发笔记的第06期，聊两个最基础但最容易被用错的家族：文本标签和图片标签。基础不代表简单——恰恰因为它们出现在每一个页面里，出一丁点问题都会被放大。这一期我不打算只罗列"标签长什么样"，而是把重点放在"为什么一个标签该这么用、不该那么用"，看完你至少能少踩我当年踩过的几个坑。

1.1 标题标签与段落：从h1到p的骨架意识

<h1>到<h6>是六级标题，很多人以为它们的区别就是"字体越来越大"，于是为了样式好看，跳着选。比如页面主标题用<h2>，因为<h1>默认太大；或者一个页面上放四五个<h1>，因为每个板块都觉得自己是"主标题"。

这在浏览器里看着没事，但对搜索引擎和读屏软件来说，标题是一份页面的"目录"。爬虫会把<h1>理解为页面最高优先级的内容主题，读屏用户会用标题快捷键在页面中跳转导航。一个页面塞了五个<h1>，相当于一本书有五张封面，谁都不信你是认真的。

我自己的准则是：一个页面只保留一个<h1>，它一般就是页面最大的那个标题；下面按层级依次用<h2>、<h3>，可以跳过级别往下跳（比如从<h2>直接到<h4>），但绝不往上跳——你不可能把一个<h4>放在<h3>的上级。标题层级的正确顺序，本质上就是在维护一份清晰的文档大纲。

再说<p>。段落标签的问题比标题更隐蔽：很多新手觉得<p>自带上下边距，布局不好控制，于是习惯用<div>包文字。这个习惯会让页面的语义完全丢失——读屏软件拿到一大片<div>时，不知道哪里是段落、哪里是列表、哪里是导航。对SEO来说，清晰的分段结构也有助于内容主题提取。我的建议是：文字内容一律放进<p>，<div>只负责结构性分区。段落里如果有一段更细的带样式文本，用<span>包，千万别本末倒置。

1.2 格式化标签：strong、b、em、i，别再把语义当装饰

文本标签里最容易混淆的就是两组：<strong>和<b>，<em>和<i>。从视觉上它们一模一样：前者加粗，后者斜体。但语义差别非常大：

读屏软件对<strong>和<em>的处理方式是改变音调语速，用户能感觉到"这里重要"，但<b>和<i>就是纯粹的视觉样式，读出来没有任何区别。如果你暂时分不清，最简单的记忆方式就是：<strong>和<em>是"有感情的"，<b>和<i>是"没感情的"。

HTML5之后还有一组非常实用的文本标签：<del>表示删除内容，浏览器渲染为删除线；<mark>表示高亮标记，自带黄色底；<ins>表示插入内容。这三个标签在做版本对比、标注修改记录、搜索结果关键词高亮时特别好用，而且语义非常明确。

2. 掌握文本嵌套与排版规则：内联、块级、换行的底层逻辑

文本标签用错了最典型的结果，不是页面崩掉，而是"浏览器帮你圆了过去"。比如你在<p>里面又放了一个<p>，浏览器不会直接报错，它会悄悄把标签拆开，最后渲染出来的DOM结构和你想的完全不一样。这种问题在开发者工具里能看到，但新手常常被"页面看起来还能用"欺骗，等到要改样式时才发现选择器根本选不中目标。

2.1 内联元素与块级元素的边界，决定了你能怎么嵌套

HTML里的元素按显示方式分两大类：块级元素和内联元素。块级元素像一个"集装箱"，默认占满整行，上下可以堆叠，比如<div>、<p>、<h1>~<h6>、<ul>；内联元素像"货架上的盒子"，多个盒子可以排在同一行，比如<span>、<a>、<strong>、<em>、<img>。

嵌套规则基本可以总结成一句话：内联元素可以放进块级元素里，但块级元素不能随便放进内联元素里。尤其是<p>标签，它内部不能放<div>、<p>、<h1>这类块级元素。HTML规范明确写了<p>的"内容模型"是短语内容。你如果真的写了一个<p>里面套<div>，浏览器在解析时会把<p>自动闭合，于是<div>就跑到<p>外面去了。这就是为什么很多人写完样式发现不对劲——不是CSS写错了，而是HTML结构已经被浏览器悄悄改写了。

2.2 br、hr、span在排版中的正确角色

<br>也是一个被滥用极狠的标签。很多新手用它来做间距、做换行排版，比如三段文字之间空一行就敲两个<br>。这个习惯很糟糕：<br>的语义是"在诗歌或地址中换行"，它不是排版工具，用它在段落里做间距会导致屏幕阅读器一个词一个词地跳，阅读体验极差。段落之间要用<p>，间距用CSS的margin，需要强制换行且确实没有语义的地方才用<br>。

<hr>的情况类似。它原本是一条水平分割线，HTML5里它的语义变成了"段落级别的主题分隔"。如果你只是想画一条好看的线，请用CSS边框；如果你是想表达"上文结束，开始另一个话题"，<hr>是语义上最正确的选择。我甚至见过有人为了让<hr>变细而把它包在<div>里加样式——完全没必要，直接给<hr>写CSS样式就行，它本质上也是一个元素。

<span>则是文本标签里的"万能兜底"：它是一个纯粹的内联容器，不含任何语义，专门用来给一段文字包样式。需要给某个词换个颜色、加个背景、做hover效果，就用<span>包起来，不要用<strong>去加粗再改样式——那样会给读屏软件一个错误的"重要性"提醒。

2.3 文本源码里那些看不见的幽灵：空格、换行与转义

还有一个所有人都应该知道的基本规则：HTML会把连续多个空格合并为一个空格，换行符在正常文本流里也会被当作空格处理。很多新手在代码里看到自己写了空行，以为页面上会出现距离，结果却发现标签之间紧紧贴在一起，然后又靠一堆<br>和 去撑间距。正确的做法是，间距问题全部交给CSS，不要在HTML里用大量空格做视觉效果。

如果你要在页面上展示一个小于号<，直接写在文本里是会被浏览器当作标签起始符解析的。这时候必须用字符实体：<代表<，>代表>，&代表&。这个坑我在做代码展示类的页面时踩过太多次，写示例代码忘了转义，结果页面渲染出来的内容凭空消失了一块。

3. 图片标签三大核心属性：src、alt、title怎么用才算吃透

图片标签<img>是所有网页里几乎一定会出现的元素。它的写法看着简单——一个src指路径，一个alt写替代文案——但实际上关于图片标签的坑，十个里面有八个来自这三个属性。先把最标准的骨架写出来：

<img src="images/poster.jpg" alt="活动主视觉海报" title="查看活动详情" width="640" height="360">

这一行代码包含了5个关键属性，但每个属性的正确含义和边界，很多人并没有真正吃透。

3.1 src路径的四种写法与常见路径坑

src的取值范围是URL，实际项目里常见的有四种写法：相对路径（images/logo.png）、根相对路径（/images/logo.png）、绝对路径（https://...）、以及基于当前目录的../上跳。

从维护性角度，我强烈建议在组件化项目中优先使用根相对路径，以站点根目录为基准，无论当前文件在哪一层，路径都不会因为位置变化而失效。但根相对路径有一个前提：部署时你的页面确实在站点根目录下，如果网站跑在二级目录（比如https://example.com/shop/），根相对路径的/images/logo.png会直接指到一级目录去，图片全挂。这时候就得用相对路径或者带域名的绝对路径。

最常见的路径坑就两种。一是层级算错：页面在page/about/下，图片在images/下，你写images/logo.png，浏览器会去找page/about/images/logo.png，然后404。正确写法是../../images/logo.png。二是在本地用file://协议打开HTML时一切都正常，一到服务器上因为路径分隔符或大小写问题全挂了。排查路径问题最快的办法就是按F12看Network面板，404的请求会直接告诉你浏览器实际请求的完整URL，人对一下马上就能看出来哪里写错了。

3.2 alt属性：加载失败时的替代文案，也是SEO的通行证

alt是图片标签里最容易被忽略、但对用户影响最大的属性。它的作用是：当图片无法加载时，在图片位置显示一段文字说明；当用户使用读屏软件时，这段文字会被读出来；搜索引擎抓取图片时，也是优先读取alt内容来理解图片是什么。

实际项目里我总结了两条铁律：

• 承载信息的图片：alt如实描述图片内容和作用。比如一张"报名二维码"，就写"扫码报名前端交流会"，不要写"img123"。
• 纯装饰性图片：alt留空字符串alt=""。这样读屏软件会直接跳过它，而不是读出一堆文件名的噪音。

很多人纠结"到底要不要写alt"。我的回答是：装饰性图片可以空，但属性本身必须有。一个页面里一堆<img>连alt都没写，在可访问性审计里会被直接打个大红叉。另外不要用title来代替alt，这两个属性的职能完全不同。

3.3 title属性与width/height属性：小细节里的大问题

title属性是鼠标悬停时显示的提示文本。它的定位是"额外信息"，不是"必要信息"——移动端根本没有hover，桌面端也未必有人会特意把鼠标放上去。所以不要把关键说明塞进title，那是alt和正文该干的事。

width和height属性则是用来给图片预设占位尺寸的。很多人以为它们是用来"缩放图片"的，实际上它们真正解决的问题是布局抖动（CLS）：浏览器在图片还没加载出来的时候就能根据这两个值预留出宽高位置，防止图片加载完成后把下面的文字内容猛地挤下去。不写这两个属性，图片加载慢时页面内容会跳来跳去，尤其影响移动端阅读体验。

这里有个细节要注意：如果只设置其中一个值，另一个没设，现代浏览器通常会按原图比例自动计算。但我建议始终把宽高都写上，并且保持与原始图片等比。否则你写死了宽高去拉伸图片，在小屏上会直接变形。真正想要"自适应"的图片，应该交给CSS的max-width: 100%和height: auto处理，而不是在HTML属性里写死固定像素。

4. 响应式图片与懒加载：图片适配不同屏幕的进阶方案

前面的width和height只是"占位"，真正让图片在不同屏幕上都清晰显示的，是响应式图片方案。这个知识走过去属于进阶，但现在H5项目里几乎必用，尤其是移动端适配越来越精细之后。

4.1 一张图片如何服务多种屏幕：srcset与sizes

假设你有一张1200像素宽的产品图，在手机屏幕上其实只需要显示400像素宽。如果你直接给手机端下原图，它会白白浪费流量；如果你只给一张400像素的小图，在桌面端它又会变得模糊。srcset和sizes就是为了解决这个矛盾的。

<img src="images/product-800.jpg" srcset="images/product-400.jpg 400w, images/product-800.jpg 800w, images/product-1200.jpg 1200w" sizes="(max-width: 600px) 400px, 800px" alt="产品展示图">

srcset里列出图片候选和各自的真实宽度，sizes告诉浏览器在什么屏幕宽度下页面实际会占用多少宽度，浏览器会结合设备的DPR（设备像素比）自己挑一张最合适的图。这个方案在开发调试时非常方便：打开DevTools的设备模拟器，切换不同宽度，Network面板里能看到浏览器请求的图片资源会跟着变化。

如果不同屏幕需要的是不同裁剪比例的图片——比如手机端要竖构图，电脑端要横构图——那就得用<picture>了。它可以基于media条件让浏览器选择不同的src：

<picture> <source media="(max-width: 600px)" srcset="img/banner-mobile.jpg"> <source media="(min-width: 601px)" srcset="img/banner-desktop.jpg"> <img src="img/banner-desktop.jpg" alt="活动横幅"> </picture>

注意<picture>里必须放一个<img>作为兜底，否则碰到不支持的浏览器时，连图都不会显示。

4.2 loading="lazy"与图片加载的时机选择

loading="lazy"是HTML原生的懒加载属性。加上之后，浏览器会等图片快滚动到视口时才发起加载请求，能显著减少首屏加载时间。我一般会在以下场景加：页面中下部的长图、内容列表里的缩略图、不重要的广告位图。但有一个关键点：首屏图片不能加。首屏里的图如果加lazy，滚动交互时会看到明显的加载过程，体验反而变差。

另外，给图片加decode相关的异步解码属性在个别场景也有用，但浏览器兼容性支持参差不齐，我的建议是不要过度使用，优先保证src、alt、width、height、loading="lazy"这几个核心属性正确。

还有一个和加载相关的经典问题：图片加载失败的"破图"状态。默认情况下，图片加载失败会显示一个破碎图标，很丑。我的处理方式一般是配合JS监听error事件，加载失败时替换成一张占位图：

const imgs = document.querySelectorAll('img'); imgs.forEach((img) => { img.addEventListener('error', function handleError() { this.src = 'images/placeholder.png'; this.removeEventListener('error', handleError); }); });

一个小细节：在error处理函数里把src替换成占位图后，一定记得移除事件监听，否则占位图加载失败会陷入无限循环。

4.3 图片格式选择：POST到底该用什么存图

HTML层面能控制的是标签属性，但实际项目中图片格式选错，性能问题会特别明显。现在主流格式里：

从开发效率角度，我建议在项目中以WebP为默认格式，JPEG/PNG作为回退兜底。前端判断浏览器是否能加载WebP的方法其实很简单：动态创建Image对象，设置src为一张极小的WebP图，看onload是否触发。如果能加载，就请求WebP版本，否则请求降级版本。这个方案配合服务端的图片处理接口，能省下肉眼可见的带宽成本。

5. 真实项目里的高频陷阱：文本与图片标签的排查经验

这一节我想把日常开发和带新人过程中反复遇到的那些"看似小但很折磨人"的问题集中复盘一下。每个问题我都会给出现象、原因和解决办法，你照着这个思路去排查，比重新翻一遍文档快得多。

5.1 文本标签的翻车现场：标题失控与段落嵌套

现象一：页面刚写完时样式正常，但后来某个按钮突然排版错乱，检查半天发现是页面里某个<p>标签没写闭合，导致后续所有内容都被浏览器当作那个<p>的内容，样式全部被继承，布局直接炸开。HTML标签写不闭合在很多情况下是"容错"的，但这种容错只是推迟了问题的爆发时间。经验是：开发周期里哪怕页面再简单，写完最好也用一下IDE的自动格式化，或者让构建工具的校验提前介入，把未闭合的标签在提交前就拦下来。

现象二：团队协作时，文案里的"强调重点"字样在不同页面里有的用了<strong>，有的用了<b>，有的甚至用<span style="font-weight: bold;">。当产品要求对"强调内容"做统一样式时，就会发现选择器根本写不统一，只能全量替换。这就是"标签语义不统一"带来的维护成本。我现在只要看到有人在HTML里直接用style属性写字重样式，就会提醒一句：能归并成CSS类的地方就别写行内样式，能统一成语义标签的地方就别每次重造轮子。

5.2 图片标签的翻车现场：几像素间隙与撑破容器

图片相关的经典坑，第一个是图片底部总有几像素空隙。原因在于<img>默认是内联元素，它要跟文字基线对齐，而基线到父元素底部之间的这段空白就会显示出来。解决方式有很多，最简单的是给<img>设置display: block，或者设置vertical-align: middle。这个坑几乎人人都遇到过，但我发现很多人在网上搜到答案后也没搞懂为什么，下次还会犯。搞懂了基线这个概念，以后再遇到任何内联元素的间距问题，你都能举一反三。

第二个经典问题是移动端图片撑破容器。明明父盒子宽度只有375px，图片却变成一长条超出屏幕。解决办法就一行CSS：

img { max-width: 100%; height: auto; }

max-width: 100%让图片最大宽度不超过父容器，但又不强制拉伸小图；height: auto让高度自适应。这个组合应该是所有响应式页面的默认底裤。比这更进一步的方案是用object-fit: cover做固定比例裁剪，但那个属于CSS进阶用法，这里不展开。

第三个是首屏大图加载过慢。解决问题的路径不是压缩图片本身，而是考虑"是不是一定得用这么一张大图"。有时候设计方案里的一张宽幅banner，在手机端完全可以用一张裁剪后的窄图替换成两倍图，配合srcset在不同端加载不同资源，比统一加载一张2MB的图片好一百倍。

5.3 文本与图片标签的自查清单：我每次提交前都会扫一遍

分享一份我一直在用的自查清单。代码提交之前按这个顺序过一遍，基本能避免90%的低级问题：

1. 页面里是否只有一个<h1>？标题层级是否按顺序排列，没有跳级？
2. 所有文字段落是否用了<p>，还是堆在<div>里？
3. <strong>、<em>是否真的表示"语义强调"，还是只是想要加粗和斜体？
4. 需要强调但纯视觉修饰的部分，是否用了<b>和<i>？
5. 装饰性图片的alt是否写成了alt=""？信息类图片的alt是否如实描述了内容？
6. 每个<img>是否都写全了width和height？有没有直接用固定像素拉伸图片？
7. 移动端样式的全局CSS里，是否已经设置了img { max-width: 100%; height: auto; }？
8. 页面中下方的大图是否加了loading="lazy"？首屏图片是否确认没有加？

这套清单特别适合刚接触前端开发的同学直接抄作业。HTML标签这件事，看十遍文档不如在真实项目里碰一遍坑，但有了清单，至少能让你在还没有经验的时候，就提前避开那些最消耗时间的低级问题。

我自己写HTML时还有一个习惯：写完一个页面的静态结构之后，会强制自己打开浏览器无样式模式（或者临时把CSS文件禁用掉）看一眼。如果在这种状态下页面的大纲依然清晰、段落依然可读、图片都有合理的替代文字，说明HTML本身是健康的。反过来，如果无样式状态下页面一塌糊涂，那即使CSS把页面画得再好看，也只是在给脆弱的骨架打补丁。文本标签和图片标签是前端开发的地基，看起来简单，但地基稳不稳，看的就是这些细节有没有被认真对待。