【白话前端 09】HTML网页结构搭建:从语义化标签到整站规划

早期写网页,前端只有一个容器标签可用:<div>

结果就是页面里堆叠了几百个 <div>。人眼能通过 CSS 样式看出哪里是头部、哪里是侧边栏。但对于搜索引擎爬虫、或是视障者的屏幕阅读器来说,这只是一坨没有主次的文本碎片。机器根本不知道 <div> 这几个英文字母代表核心内容。

HTML5 引入 <header><main> 等语义化标签,本质不是为了给页面换个长相,而是给网页写一份“机器能看懂的结构说明书”

当把核心代码放进 <main>,把底部备案信息扔进 <footer>,爬虫一进来就明确知道:“抓取有效信息直接去 <main> 里找,底部的东西可以直接跳过。”这就是语义化的底层价值。

本文不背概念,直接以一个常见的博客设计稿为例,看我们该如何用这套标签把内容塞进正确的“房间”里。


一、网页的 5 个固定组件

再复杂的网站(比如电商、博客),核心结构都逃不出这 5 个固定组件。就像一套房子的“客厅、卧室、厨房”,功能是定死的:

结构组件对应标签作用页面出现次数(通常)
头部<header>放网站 Logo、大标题、全局搜索框。1 次(每个页面顶部都一样)
导航<nav>放全局首要链接(首页、分类、关于我们)。1 次(常紧挨着头部)
主内容<main>页面独占的核心内容(文章正文、商品详情)。仅 1 次(这是用户来页面的目的)
侧边栏<aside>辅助内容(作者简介、相关推荐、广告)。可多次(依附主内容存在)
底部<footer>网站补充信息(版权声明、备案号、联系方式)。1 次(每个页面底部都一样)

拿到设计稿,第一步就是用这 5 个框,把图纸划分清楚。


二、HTML 标签实战映射(页面级)

我们先看“整个页面只有一份”的三个核心骨架标签。

1. <main>:一切为了核心内容

main 是页面的绝对主角。用户打开这篇网页为了看什么,什么就放在 <main> 里。

💡 核心定律:一个页面只能有 1 个 <main> 且必须可见。绝对不能把它嵌套在 <header><nav><footer> 里面。
<!-- 错误:放了两个主角 --><main>文章摘要1</main><main>文章摘要2</main><!-- 正确:所有文章被包裹在一个主角内 --><main><h1>今天的天气</h1><p>北京今天晴,气温15-25℃...</p></main>

2. <header><footer>:门面与收尾

<header> 放全局性的标识;<footer> 放全局的补充说明。它们通常在每个页面(首页、文章页、关于页)都保持相同的代码。

<body><header><img src="logo.png"alt="我的博客logo"><h1>小A的技术博客</h1></header><main><!-- 这里放每一页不一样的内容 --></main><footer><p>©2025 小A的博客 | 备案号:京ICP备123456号</p></footer></body>

三、文章与章节(内容级标签判断)

大框架搭好后,我们进入 <main> 的内部。这里是新手最容易犯迷糊的地方:到底什么时候用 <article>,什么时候用 <section>

1. <article>:独立成册的“小黄书”

<article> 代表一段完全独立的内容。

📖 独立性判断
判断标准:把这部分内容单独复制下来,发到另一个网站去,它还是一篇完整、能看懂的东西吗? 如果能,就用 <article>

一篇完整的博客文章、论坛里的一个主帖、一个商品介绍卡片,都属于 <article>

<main><!-- 首页的文章列表,每篇文章都是独立的 --><article><h2>如何搭一个简单的HTML页面</h2><p>第一步:创建.html文件...</p></article><article><h2>CSS 基础入门</h2><p>把网页变好看的秘密...</p></article></main>

2. <section>:书里的“第 X 章”

<section> 代表具有相同主题的内容分组。它不是独立的文章,而是文章里的一个“章节”。

💡 核心定律<section> 通常必须带有一个标题(<h1>-<h6>)。如果没有标题,说明这段内容不具备主题分组的资格,可能只是一个普通的 <div>
<article><h2>HTML结构入门</h2><!-- 第一节内容 --><section><h3>1. 什么是HTML结构</h3><p>就是网页的骨架...</p></section><!-- 第二节内容 --><section><h3>2. 核心标签有哪些</h3><p>有header、nav、main...</p></section></article>

四、被滥用的 <nav><aside>

1. <nav>:只留给“主干道”

不要看到链接就加 <nav>。文章底部的“上一篇/下一篇”链接、正文里的外部参考链接,都不配用 <nav>
<nav> 是站点的主导航器

🛠️ 正确做法:通常将 <ul> 列表放在 <nav> 中,确保语义极其清晰。
<nav><ul><li><a href="index.html">首页</a></li><li><a href="about.html">关于我</a></li></ul></nav>

2. <aside>:正文的跟班

<aside> 里面的内容如果被删掉,绝对不能影响主内容的阅读理解。
最经典的场景就是侧边栏的“作者简介”、“相关猜你喜欢”、“广告位”。

<main><article><!-- 主文章 --></article><aside><h3>相关文章推荐</h3><ul><li><a href="#">上周去爬山</a></li></ul></aside></main>

五、无语义元素的归宿:<div><span>

如果你手上的内容,套不上前面说的任何一个“带名字的房间”,这时候才轮到万能的容器出场。
记住,它们没有任何语义,在机器眼里就是透明容器,仅为了方便 CSS 挂载样式。

  • <div>(大箱子):独占一行。用于包裹无主题的块级内容(如一个用来做动画的遮罩层、一个复杂的购物车弹窗框)。
  • <span>(小贴纸):不独占一行。用于包裹文字里的一小段,方便给这几个字单独上色。
<p> 今天气温<span class="high-temp">25℃</span>,比昨天高了。 </p><!-- 纯为了排版控制布局而存在的壳子,用 div并起好名字 --><div class="banner-wrapper"><img src="ad.jpg"></div>
🧠 10秒速记指南页面唯一主角定生死: <main>。能单独转发给别人的内容块:<article>。带小标题的内容区域/章节:<section>。为了加 CSS 样式而设置的透明大盒子:<div>

➡️ 下期预告
骨架搭好了,但网页还像一座座无法互通的信息孤岛。怎么让页面之间能够自由跳转、一键下载文件、甚至直接弹出邮件草稿?下一篇文章《HTML超链接从入门到精通》,带你掌握Web真正的灵魂——<a>标签!

Read more

Stable Diffusion插件开发:没GPU也能调试,1小时1块

Stable Diffusion插件开发:没GPU也能调试,1小时1块 你是不是也遇到过这种情况?作为一名前端程序员,想给Stable Diffusion(简称SD)开发个插件,比如做个更顺手的UI界面、加个自动保存功能,或者集成一个AI绘图小工具到自己的项目里。但一打开本地电脑——卡!运行基础模型都费劲,显存爆了、风扇狂转、浏览器直接崩溃。 去网吧?不现实,代码环境没法保留,还容易泄露项目信息;买高端显卡?成本太高,用几次就闲置了。那有没有一种方式,既能低成本、安全地远程开发SD插件,又能像在自己电脑上一样流畅调试? 答案是:有!而且现在只需要每小时1块钱,就能拥有一台带GPU的远程开发机,跑动完整的Stable Diffusion环境,还能随时部署和测试你的插件。最关键的是——你家里的低配电脑也能轻松操作。 这篇文章就是为你量身打造的。我会带你从零开始,一步步搭建一个适合SD插件开发的远程环境,教你如何在没有高性能显卡的情况下,照样高效调试、快速迭代。无论你是第一次接触AI绘图,还是已经玩过WebUI但苦于本地性能不足,这篇都能让你立刻上手。 学完你能做到: * 一键

AMD显卡在windows中通过WSL安装使用stable diffusion(WebUI和ComfyUI)

确认windows的amd显卡驱动版本,至少不低于24.12.1,具体可以查看对应 一、安装wsl和ubuntu。 1.安装wsl2: wsl --install 2.安装ubuntu(24.04、22.04等): wsl.exe --install ubuntu-24.04 3.更改ubuntu安装位置(可选): wsl --manage ubuntu-24.04 --move <location> 4.进入wsl实例: #输入wsl -d <version>进入制定版本或输入wsl进入默认实例 wsl -d ubuntu-24.04 可按Ctrl+D退出当前实例。 关闭实例: wsl --shutdown

从Copilot到CodeBuddy:智能编码助手如何重塑开发日常

从Copilot到CodeBuddy:智能编码助手如何重塑开发日常

👋 大家好,欢迎来到我的技术博客! 📚 在这里,我会分享学习笔记、实战经验与技术思考,力求用简单的方式讲清楚复杂的问题。 🎯 本文将围绕人工智能这个话题展开,希望能为你带来一些启发或实用的参考。 🌱 无论你是刚入门的新手,还是正在进阶的开发者,希望你都能有所收获! 文章目录 * 从Copilot到CodeBuddy:智能编码助手如何重塑开发日常 * 🏛️ 第一部分:Copilot时代——你的“贴心”纠错笔 * 1.1 什么是Copilot模式? * 1.2 Copilot的局限:管中窥豹 * 🤝 第二部分:CodeBuddy时代——你的“全能”架构师 * 2.1 进化论的必然 * 2.2 重塑开发日常 * 💻 第三章:实战演练——CodeBuddy是如何干活的? * 3.1 场景一:构建一个RESTful API * ❌ 如果使用Copilot(传统补全模式): * ✅ 如果使用CodeBuddy(Agent模式): * 3.

开箱即用:支持ChatGLM/文心一言的API管理镜像部署手册

开箱即用:支持ChatGLM/文心一言的API管理镜像部署手册 1. 为什么你需要这个镜像——告别密钥混乱与模型适配烦恼 你是否遇到过这样的场景: * 项目里同时调用文心一言写营销文案、用ChatGLM做内部知识问答、再接入通义千问生成技术文档,结果每个模型都要单独配置api_key、base_url、请求头格式、流式开关逻辑……代码里堆满条件判断; * 测试环境用的是本地Ollama的Qwen2,生产环境切到百度千帆的文心一言4.5,一改base_url和模型名,就报400 Bad Request——原来千帆不支持OpenAI原生的temperature字段命名,得改成top_p; * 运维同事半夜被报警电话叫醒:“线上服务崩了!查了一小时发现是讯飞星火的API密钥过期了,但没人知道它被用在哪个微服务里……” 这些问题,不是你代码写得不够好,而是缺一个统一的API网关层。 这不是一个需要你从零搭建的复杂系统,而是一个真正“开箱即用”的镜像——它把所有主流大模型(包括ChatGLM、文心一言、通义千问、讯飞星火等)的差异全部封装掉,对外只暴露标准的OpenAI API