html5网站源码

去年帮朋友改一个企业站，网站打开源码文件夹我愣了——整整37个HTML文件，源码每个都塞着重复的网站导航和页脚。他花八千块找人做的源码“响应式网站”，实际就是网站复制粘贴了37遍。这让我想到一个问题：HTML5网站源码到底该怎么看、源码怎么用？网站

先明确一点，HTML5网站源码不是源码单一文件。它至少包含三类东西：结构层（.html文件）、网站表现层（.css文件）、源码行为层（.js文件）。网站很多人拿到源码压缩包，源码看到一堆文件夹就晕，网站其实按这个分类去拆，源码五分钟就能理清骨架。网站

我习惯先打开index.html，用浏览器开发者工具切到“Elements”面板。这里能看到DOM树，比直接读源码快得多。比如一个导航栏，源码里可能是：

<nav class="main-nav"> <ul> <li><a href="/">首页</a></li> <li><a href="/about">关于</a></li> </ul> </nav> 

但浏览器里展开后，你才会发现里面嵌了三个div、两个span，还有一堆data-*属性。这些往往是JS插件自动生成的。直接读源码容易被绕晕，先看渲染结果再回头找对应代码，效率翻倍。

说到data-*属性，这是HTML5源码里最容易被忽略的实用功能。比如<div data-price="299" data-stock="12">，前端JS可以直接读取这些值做价格计算或库存显示，不需要额外请求接口。我见过一个茶叶电商站，所有产品卡片都用data-*存规格参数，切换SKU时零延迟。这种写法不依赖框架，纯原生就能跑。

另一个观察：很多所谓“HTML5模板”其实只用了HTML5的声明<!DOCTYPE html>，语义化标签一个没用。满屏的<div class="header">、<div class="footer">。真正的HTML5应该用<header>、<footer>、<article>、<section>。这不只是好看——屏幕阅读器依赖这些标签给视障用户导航。你写<div>，读屏软件只能念“分组”，写<nav>它会说“导航区域”。差别就在这。

源码里的CSS组织方式也值得琢磨。我见过最离谱的是一个单页站，style.css有四千多行，所有选择器都堆在一起。改一个按钮颜色，得用搜索定位到第2378行。正常做法是按模块拆成base.css、layout.css、components.css，或者至少用注释分块。BEM命名法虽然啰嗦，但半年后回来看，.card__title--highlighted比.title2好懂得多。

JS部分，HTML5网站源码常见两种坑。一种是所有脚本塞在<head>里，页面白屏三秒才渲染。正确做法是加defer或async，或者把<script>放到</body>前。另一种是依赖一堆jQuery插件，每个插件又带自己的CSS和字体文件。你数一下network面板的请求数，超过80个就得考虑合并了。

移动端适配在源码里看什么？看<meta name="viewport">这行。很多模板写的是width=device-width, initial-scale=1, maximum-scale=1，最后那个maximum-scale=1直接禁用了用户双指缩放。这属于 accessibility 反模式。正常应该去掉它，或者改成user-scalable=yes。

最后说个实际案例。上个月帮人排查一个表单提交失败的问题。源码里<form>标签写的是<form action="/submit" method="get">，但后端接口只接受POST。改一个单词就解决了。HTML5新增的type="email"、type="tel"、required属性，浏览器自带验证，比JS写一堆正则省事。但注意，type="number"在移动端会弹数字键盘，可它允许输入e和-，真要限制还得加pattern。

源码这东西，别光看它写了什么，更要看它没写什么。没写alt的图片、没写label的输入框、没写lang的<html>标签——这些缺失比错误更常见。拿到一份源码，先跑一遍W3C验证器，再跑一遍Lighthouse，比逐行读代码管用。