HTML4到HTML5：核心差异、迁移实战与兼容性排查指南

"html4和html5"这标题，要是放十年前，顶多是新手问"这俩有啥区别"。放到今天再被单独拎出来聊，基本都是面试前突击、课程作业卡壳，或者老项目要翻新时踩了坑才回头补课。我见过太多人背了一堆"HTML5新增了语义化标签、canvas、本地存储"这种面试答案，真到写页面时还是满屏的div套div，问一句"为什么用header不用div"就答不上来。

这篇文章不打算给你划重点式地罗列对比表，而是从HTML4到HTML5这次版本跃迁背后的真实逻辑讲起，配合页面结构、表单、本地存储、多媒体这些实际开发里高频用到的场景，把差异掰开揉碎。最后还会附上本地预览文件打不开、老页面升级后布局崩了这类常见问题的排查经验。无论是刚开始学网页制作的新手，还是维护着祖传老代码想找机会重构的同学，这篇应该都能给你一些能直接抄走的思路。

1. 先从历史背景说起：HTML4时代长什么样

HTML4的正式发布时间是1997年末，1999年发布了4.01版，这个版本统治了Web将近十五年。你现在去看一些古董网站，或者企业内部那些多年没动过的OA系统，源代码里大概率还是这套东西。

1.1 那个靠表格和font标签撑起来的年代

HTML4时代有个特别典型的特征：网页布局靠table，字体样式靠font标签，结构长期是一坨嵌套很深的表格。那时候CSS虽然已经出现，但浏览器兼容性很差，主流做法是能用表格就用表格，毕竟表格在当时的浏览器里渲染最稳定。

举个例子，很多老开发应该有印象，早期做三栏布局，代码长这样：

html复制<table width="960" border="0" align="center">
  <tr>
    <td width="200" valign="top">左侧导航</td>
    <td width="560" valign="top">主体内容</td>
    <td width="200" valign="top">右侧栏</td>
  </tr>
</table>

这种写法的问题非常明显：表格被撑起来以后，不加载完整个内容根本显示不出来，因为浏览器必须拿到所有行的数据才能计算列宽。这就导致一个页面在网速慢的时候白屏很久。而且表格的语义是展示数据，不是搭页面框架，搜索引擎的爬虫很难从这种结构里判断哪里是导航、哪里是正文。

再看字体，那时候想给一段文字变红加粗，常见操作是：

html复制<font color="#ff0000" size="4"><b>重要提示</b></font>

每多一层样式，就得往font标签里塞一个属性。一个页面几十处不同的字号颜色，全是这种方式，后期维护改个主色调，得全文搜索替换，改漏一处的后果就是页面上冒出一个风格完全不对的角落。

1.2 HTML5是针对"Web应用化"的一次重构

2000年之后，Web的形态开始悄悄起变化。Gmail、Google Maps这类产品出现以后，开发者突然意识到：网页已经不只是用来阅读的文档，而是可以承载复杂交互的应用程序。HTML4这套按"文档"思路设计的东西开始力不从心，于是WHATWG组织先提出了Web Applications 1.0，后来和W3C合作推进，最终变成了现在说的HTML5。

HTML5其实不是单纯的一个语言版本号，它是一整组技术的总称，涵盖了新的HTML标签、CSS3的很多模块、还有JavaScript里新增的API。它要解决的核心问题有几个：让页面结构有语义而非全靠div猜、让表单在浏览器端就能完成基础校验而不依赖翻来覆去的JS、让视频音频不需要插件就能播放、给离线存储和本地数据提供一个比cookie好用得多的方案。

我个人的体会是：HTML4和HTML5，本质上是"文档思维"和"应用思维"的区别。HTML4默认你做的是一份可以发布的文档，超链接、图片、文字排版，这些是它的主场。HTML5默认你做的是一个能跑起来的应用，页面结构只是这个应用的表面壳子。

2. 文档头与基础结构差异：为什么doctype从那么长变成一句话

你去看现在的网页，几乎每个页面头上都是这样一行：

html复制<!doctype html>

搜索记录里看到不少人卡在"html lang=zh-cn head meta charset=utf-8"这段上，其实这就是HTML5的标准文档头。但你要知道，HTML4年代，这一行能写到你怀疑人生。

2.1 HTML4的DOCTYPE三兄弟

HTML4的DOCTYPE声明里带着DTD（Document Type Definition，文档类型定义）的地址。常见的有三种，对应三种页面模式：

html复制<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<!-- Strict严格模式：不允许使用任何表现性标签和属性，如font、center -->

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<!-- Transitional过渡模式：允许继续使用font、center这些表现性标签 -->

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" "http://www.w3.org/TR/html4/frameset.dtd">
<!-- Frameset框架模式：允许使用frameset框架页 -->

当年新手最常见的问题就是这三种声明记不住、分不清，写错一个单词页面就乱了。而这么长的字符串，浏览器真正用它做的事只有一件——判断该按标准模式解析还是按怪异模式解析。所谓怪异模式，是早期Netscape和IE对CSS解释不一致时浏览器为了兼容老页面保留下来的一套渲染逻辑，里面包含了一大堆盒模型的诡异计算方式。

到了HTML5，规范直接拍板：不需要再引用任何DTD，因为现在所有浏览器对标准的支持已经足够统一，DTD本身的验证作用已经名存实亡。所以<!doctype html>这短短一行，就足够告诉浏览器按现代标准去渲染页面了。

2.2 meta charset的演进

字符编码的声明变化，可以看成两个时代对"细节处理"的缩影。

HTML4时期，要么写这样一长串：

html复制<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

或者图省事，用禁止的参数：

html复制<meta http-equiv="Content-Type" content="text/html; charset=gb2312">

那个年代很多国内网站的默认编码是GB2312或GBK，因为当时网速慢，UTF-8编码下如果一个页面里中文占多数，文件体积比GBK大不少。后来UTF-8成了绝对主流，HTML5也把charset从http-equiv的属性里单拎出来，简化成：

html复制<meta charset="utf-8">

如果你打开一个HTML4老页面，看到中文全部乱码，第一件事就是检查文件实际保存的编码和meta声明的编码是否一致。用VS Code打开文件，看右下角，如果写的是UTF-8，但meta里写的是gb2312，把meta改过来就行。反过来也一样。

2.3 lang语言声明里的小坑

你注意看开头那个标准文档头，<html lang="zh-cn">，表示页面主要内容是简体中文。搜索词里出现不少lang="zh cn"这种写法，看起来是zh-cn里的连字符在复制过程中丢了，或者某些编辑器做了奇怪处理。严格来说，zh-cn是标准的区域语言标记，zh单独出现也可以，表示中文但不区分简繁。这个属性本身不影响渲染，但它对无障碍阅读、搜索引擎识别页面语言有帮助，写标准些总没坏处。

3. 内容标签的分工：从一锅炖到各司其职

这部分是HTML4和HTML5在日常页面制作中感受最直观的地方。HTML4时期页面骨架基本就两个标签来回用：div和span。一个是块级容器，一个是行内容器，前者用来分区，后者用来圈字。页面复杂以后，div嵌套七八层非常常见，代码一多，根本分不清哪个是导航、哪个是页脚。

3.1 语义化标签的价值在实际页面里

HTML5新增了这么一套结构性标签：header（页眉/头部）、nav（导航）、main（主内容）、article（文章/独立内容）、section（区块）、aside（侧边栏/补充信息）、footer（页脚）。

做一个博客页面，HTML4时代的骨架大概是：

html复制<div id="header">
  <div id="nav">
    <a href="#">首页</a>
    <a href="#">文章</a>
  </div>
</div>
<div id="content">
  <div class="post">
    <h2>文章标题</h2>
    <p>正文内容</p>
  </div>
</div>
<div id="sidebar">相关推荐</div>
<div id="footer">版权信息</div>

HTML5后的写法是：

html复制<header>
  <nav>
    <a href="#">首页</a>
    <a href="#">文章</a>
  </nav>
</header>
<main>
  <article>
    <h2>文章标题</h2>
    <p>正文内容</p>
  </article>
  <aside>相关推荐</aside>
</main>
<footer>版权信息</footer>

结构上第一眼就能看明白哪块是干嘛的，不需要去翻CSS里每个id对应的位置。更重要的是搜索引擎爬虫和屏幕阅读器在抓取页面时，可以跳过导航直接定位main或者article里的正文，这对SEO和网站无障碍都是实打实的加分项。

用的时候有一点要提醒：section和article都有"区块"的意思，很多新手容易混。我的判断标准很简单：article里面的内容，单独拿出来放到另一个网站，依然能独立成立——比如一篇完整的帖子、一条评论、一个产品卡片。如果内容只是页面内部的一组归类，比如"产品特性一""产品特性二"，用section就对了。header和footer也不是只能整页用一次，article内部可以有自己独立的header和footer，表示这篇文章的标题区和署名区。

3.2 表单升级：让浏览器分担校验工作

HTML4时期做表单校验是件苦差事。邮箱格式、必填项、数字范围，全部要自己写正则，再绑定submit事件，在JS里拦截判断，页面刷新后弹出提示。一旦漏校验或者正则写错，用户填了半天一提交，数据就带着各种乱七八糟的格式进了后台。

HTML5给input类型做了一组扩展。你现在写：

html复制<input type="email" required>

浏览器自己就会检查这个输入框里的内容是否符合邮箱基本格式（注意，是基本格式，不是完整验证），空着提交会拦截，并弹出一条本地化提示。类似的还有：

html复制<input type="url" placeholder="请输入网址">
<input type="number" min="1" max="100" step="1">
<input type="date">
<input type="range" min="0" max="100">
<input type="color">
<input type="tel">

每个类型都有特殊价值。type="email"在手机上会呼出带@键的键盘，type="url"会呼出带斜杠的键盘，type="number"直接弹数字键盘，这些细节对移动端用户非常友好。

还有一些新属性也非常实用。placeholder给输入框加灰色占位提示，这个几乎成了标配。pattern允许你写一个正则作为自定义校验规则。autofocus让页面加载完光标自动落在某个输入框里。我记得HTML4年代要实现同样的占位效果，得用JS监听focus和blur事件来回切换类名，不光代码烦，还有浏览器自动填充干扰，非常容易出Bug。

但注意，HTML5表单校验依赖浏览器原生实现，不同浏览器弹出的错误提示样式不一样，而且很难自定义。如果你的产品对提示文案有统一风格要求，比较稳妥的做法是在form上加novalidate属性，关掉原生校验，然后在JS里调用输入框的checkValidity方法拿到校验结果，自己统一渲染提示。

3.3 视频音频与图形：不用插件也能跑富媒体

HTML4年代想在网页里播视频，最主流的方案是Flash，需要通过object标签往页面里嵌一个插件对象：

html复制<object type="application/x-shockwave-flash" data="player.swf" width="480" height="320">
  <param name="movie" value="player.swf">
</object>

这套方案在iPhone和iPad发布后彻底崩了——苹果系统完全不支持Flash。今天你维护老代码如果看到object、embed，基本都是历史遗留。

HTML5的video和audio标签，让媒体播放成了浏览器的原生技能：

html复制<video controls width="640">
  <source src="movie.mp4" type="video/mp4">
  <source src="movie.webm" type="video/webm">
  你的浏览器不支持视频播放，请升级浏览器。
</video>

source标签允许你列多个不同编码的视频源，浏览器会自己挑第一个能播的。controls属性决定是否显示播放控制条，不加的话视频默认是静默的，要配合JS自己写播放按钮。

再比如做图表、做动态图形，HTML5时代的canvas和SVG几乎是绕不开的两个选择。canvas是基于像素的位图，适合做游戏画面、粒子特效这类需要逐帧频繁重绘的场景。SVG是基于XML的矢量图，适合做LOGO、图标、图表这类对清晰度有要求、或者需要和DOM交互的场景。HTML4时代这些功能要么上Flash，要么用大量图片拼接，灵活性差了不止一个级别。

3.4 那些被HTML5正式淘汰的标签

有增就有减。HTML5明确弃用了font、center、big、strike、frameset这些纯粹控制表现的标签。HTML4年代用frameset做左右分栏框架的网站不少，这种结构今天已经完全退场，主要问题是搜索引擎无法为每个frame里的内容单独建立有效索引，同时也不利于分享——复制地址栏URL，实际打开的是框架根页面，不是用户看到的内容页。

我自己处理过不少老站改造，遇到font、center这种标签，现在的迁移思路很简单：font的效果用CSS的color和font-size替代，center可以用text-align: center或margin: auto替代，big、strike分别用font-size和text-decoration: line-through替代。业务含义由HTML负责，视觉效果交给CSS处理，这是HTML4到HTML5最重要的理念切换。

4. 页面不再只是页面：存储与交互能力拉开差距

如果只说标签变化，很多人会觉得"这不就是把div改成了header吗，有啥了不起"。HTML5真正让Web迈入应用时代的，是配套那批JavaScript API。它们让网页能记住用户的状态、能在设备断网时仍保留数据、能做后台计算。

4.1 localStorage和sessionStorage解决了什么问题

HTML4时代想在本地存点用户数据，唯一的原生途径是cookie。cookie的使用限制很明显：每个域名下的总大小被限制在4KB左右，而且每次浏览器向服务器发起请求，cookie都会自动带上，无形中浪费流量。存个几十K的用户配置，cookie完全干不了。

HTML5的localStorage直接把单域名下可存空间提升到了5MB级别（不同浏览器有差异），并且数据不会随着HTTP请求自动发给服务器。API设计也简单：

js复制// 写入
localStorage.setItem('theme', 'dark');

// 读取
const theme = localStorage.getItem('theme');

// 删除
localStorage.removeItem('theme');

// 清空
localStorage.clear();

存进去的都是字符串，想存复杂对象得先JSON.stringify转一下，取出来再JSON.parse。sessionStorage用法和localStorage完全一样，唯一区别是生命周期：localStorage只要不手动清，永久保留；sessionStorage在标签页关闭时数据就没了，适合存一些临时性的会话状态，比如用户填写了一半的表单草稿。

实际项目里要存用户自定义的主题色、侧边栏折叠状态、浏览历史记录、购物车内容这种不敏感的数据，localStorage几乎是首选。做优化的时候，配合storage事件，还能实现两个标签页之间的实时通信。

4.2 离线能力：从白纸到能做离线应用的跳板

HTML5时代有一批很前沿的离线方案，比如Application Cache，理念是把某些文件声明为缓存清单，让浏览器断网时也能加载。这个标准后来被Service Worker取代了。Service Worker本质上是个独立于网页运行的JavaScript文件，它能在浏览器后台拦截网络请求，先查缓存再走网络，从而让页面支持离线访问和资源预加载。

虽然AppCache现在已经被废弃了，但"离线优先"这条路确实是HTML5这代开启的。今天很多移动端H5页面能做到秒开，背后就是Service Worker在预缓存静态资源。夸张一点说，没有HTML5打开这扇门，PWA（渐进式Web应用）这套概念就无从谈起。

4.3 拖放、地理定位与多线程

HTML5另外几个让我印象比较深的API：

• 拖放（Drag and Drop）：允许元素之间拖动。HTML5的拖放API对开发者来说写起来有点繁琐，dragstart、dragover、drop的事件要一个一个绑，中间还容易漏掉preventDefault，但原生支持总比引入一堆拖拽库轻量。

• 地理定位（Geolocation）：网页里调用navigator.geolocation.getCurrentPosition()就能拿设备坐标。第一次搞这个的时候我还挺意外的，明明没装任何插件，浏览器就能调起系统的定位授权。

• Web Worker：允许JavaScript在后台开一个独立线程跑计算密集的任务，避免主线程卡死界面。HTML4年代的局限是JS所有的计算都在UI线程里跑，一旦循环复杂度上来，页面的滚动点击全部瘫痪。Web Worker把"Web不只是文档、而是能承载重计算的平台"这件事又往前推了一步。

这些API在HTML4时代大多需要依赖浏览器插件或ActiveX控件才能实现，而且兼容性非常差。现在这些能力成了标配，前端能做的事情的边界被大幅扩宽了。

5. 实操中的迁移经验与兼容性选择

知道区别之后，真正的问题是：我现在手上有个HTML4老项目，或者在用HTML5写新页面，应该怎么取舍、怎么排查问题。

5.1 老HTML4页面升级改造的顺序建议

接到改版老页面的需求，不要一上来就想着全改，风险极大。我建议按这样一个顺序逐步推进：

第一步，只改DOCTYPE声明，把HTML4那三行长的DTD换成<!doctype html>。改完一定要立刻全页面回归测试，因为DOCTYPE一变，浏览器的渲染模式就从"可能是怪异模式"切到了"标准模式"，盒模型的计算方式会有变化，老页面经常在这一步出现很多意想不到的错位。

第二步，把CSS里的兼容性hack清理掉。很多老CSS文件里塞了一堆针对IE6、IE7的下划线hack、星号hack。现代浏览器根本不认这些，留着只会让代码更乱。

第三步，逐个替换表现型标签。遇到font标签，先在CSS里写好对应类或元素选择器，再在HTML里把font删掉。这个过程要勤提交，分小批做，不要一个5000行的文件一口气改完再验证，出错都不知道从哪查起。

第四步，评估现有JS里那些功能能不能用HTML5原生的方案替代。比如表单校验的jQuery验证插件，如果项目没有特别复杂的自定义规则，完全可以拆成HTML5的required、pattern加少量原生JS。又比如过去模拟placeholder的脚本，现在可以整段删掉。

5.2 html文件无法预览：很可能是这几种情况

搜"html文件无法预览"的同学相当多，问题大概率出在几处：

一是文件后缀不是.html。Windows系统默认会把已知文件的扩展名隐藏，你看一个文件看着像"index.html"，其实后缀可能被隐藏的其实是.txt。直接把txt改成html是不行的，正确做法是右键文件，看"属性"，确认"文件类型"是不是Chrome/Edge/Firefox Document。改后缀时小心系统提示，扩展名改了但内容还是纯文本，浏览器只能识别HTML语法，无法识别是正常的。另外还要检查文件内容存的是不是纯文本，如果用记事本默认保存的话，编码选了带BOM的UTF-8，部分浏览器也会出现样式错位。

二是文件没有和浏览器关联。双击html文件如果弹出的是记事本或一个软件选择框，说明系统里没有把.html后缀默认关联到浏览器。右键文件，选择"打开方式"，勾选"始终使用此应用"，选Chrome或Edge即可。

三是用VS Code这类编辑器改了代码后直接点右键打开本地文件，某些路径下受本地file协议限制，不能加载同目录的JavaScript模块或者请求本地JSON数据。遇到这种情况，在项目目录里跑个简单的本地静态服务器就能解决。比如装了Node的话，在目录里执行：

bash复制npx serve

或者用Python：

bash复制python3 -m http.server 8080

然后在浏览器访问http://localhost:8080打开页面就好。这既是解决"预览不了"的办法，也是开发阶段更推荐的方式——本地文件协议下，很多HTML5 API是受限的，比如Geolocation、Service Worker这类，在file://环境下根本没法正常工作。

5.3 一键返回顶部：看起来简单其实有兼容细节

搜索词里有"html一键返回顶部算法"，这是个非常经典的交互功能。HTML5时代有原生的平滑滚动方法：

js复制window.scrollTo({
  top: 0,
  behavior: 'smooth'
});

一条代码，浏览器就能平滑滚动到页面顶部。就这么简单？不，有几个细节要考虑：

第一，behavior: 'smooth'对老版本浏览器的兼容性一般，如果用户用的是比较老的内核版本，这个参数被忽略，结果就是瞬间回到顶部，功能不算坏，只是没了过渡动画。

第二，页面里存在滚动容器时（某个div内部overflow: auto），window.scrollTo管不了内部容器的滚动。这时候要滚动到该容器自己的scrollTop为0，比如：

js复制document.getElementById('contentArea').scrollTo({
  top: 0,
  behavior: 'smooth'
});

第三，如果你拿来做"回到顶部"按钮的显隐，监听window的scroll事件要注意节流，不要每个像素滚动都触发一次判断。更现代的做法是用IntersectionObserver监听一个哨兵元素，页面滚过它以后就显示按钮，性能开销小很多。

至于"返回顶部算法"这个词，可能是想找一套不依赖浏览器原生方法来手动实现平滑动画的写法，逻辑无非是：从当前scrollTop出发，每帧减去一个固定步长，直到到达0。用requestAnimationFrame能实现很平滑的效果：

js复制function smoothScrollToTop() {
  const currentY = window.pageYOffset || document.documentElement.scrollTop;
  if (currentY > 0) {
    window.scrollTo(0, currentY - Math.ceil(currentY / 20));
    requestAnimationFrame(smoothScrollToTop);
  }
}

这里减去的步长是currentY/20再向上取整，好处是滚动速度会随着距离变小而自然减速，到最后不会出现"急刹车"的感觉，视觉上更柔和。

5.4 各类转换需求里的一点提醒

搜"html转为md""html格式转换wps表格"这类需求的，多半是拿到了一个现成的网页内容，想把它变成其他格式再利用。

HTML转Markdown，如果只是简单文章，很多在线工具或者VS Code插件都能做。但要注意，HTML里那些块级元素的嵌套层级在转换后极容易丢失。转换完务必人工检查一级二级标题是否准确、表格结构有没有错位。做转换时最好把图片地址、相对链接也一并处理，不然markdown文件挪走之后图片全挂。

HTML里的表格直接复制进WPS或Excel，多数时候能带格式粘贴，但CSS修饰出来的"视觉表格"（用div模拟的）是没法被识别成表格结构的。如果你需要从网页上拿表格数据进WPS表，优先找页面源码中真正的table标签内容。

5.5 HTML邮件的那些祖传坑

搜"html邮件"的人，多半是被HTML邮件折磨过。邮件客户端解析HTML的能力普遍停留在非常原始的阶段，它的兼容性要求比HTML4还极端。HTML5新增的那些语义化标签在邮件客户端里基本不会有任何增强，反而可能导致样式失效。做邮件模板时，最稳妥的路线依然是HTML4的老路：布局用表格，样式全部用内联style，不用JavaScript，不用外部CSS，不依赖媒体查询（除了少数支持较好的客户端）。

很多大厂邮件底部会加一个"如果无法正常显示，请点击此处在浏览器中查看"链接，就是因为邮件客户端的HTML解析能力不可控。所以给邮件系统做HTML页面，第一守则是别写花里胡哨的现代语法，老老实实回到桌子布局内联样式。

6. 调试技巧与兜底方案

写HTML5页面时，最怕的不是写错标签，而是你以为写对了但浏览器不按照你的预期工作。这种情况排查起来往往要靠经验积累。

6.1 判断浏览器是否支持某个HTML5特性

最简单的判断方法，用一行JS探测。拿canvas举例：

js复制const canvas = document.createElement('canvas');
if (canvas.getContext) {
  // 支持 canvas
} else {
  // 不支持
}

其他特性类似，比如判断是否支持localStorage，可以直接try一段写入读取，注意有些隐私模式下浏览器虽然暴露了localStorage对象，但写入会抛异常，所以需要try/catch包裹：

js复制function isLocalStorageSupported() {
  try {
    const testKey = '__test__';
    localStorage.setItem(testKey, '1');
    localStorage.removeItem(testKey);
    return true;
  } catch (e) {
    return false;
  }
}

另外CSS那边可以用@supports做能力检测：

css复制@supports (display: grid) {
  .container { display: grid; }
}

浏览器如果支持display: grid就应用这段样式，不支持就跳过，自动走你自己写的兜底布局。

6.2 标准模式与怪异模式：80%样式怪异的元凶

为什么老页面在升级后偶尔会"换了个长相"？很多情况根子就一句话：DOCTYPE没写对，导致浏览器进入了怪异模式。怪异模式主要是为了兼容上古时期没有DOCTYPE声明的页面，在那个模式里，CSS盒模型的width计算规则会不一样。举个例子，在标准模式下，一个div设置width: 300px和padding: 20px，占用的总宽度是340px；在怪异模式下，这个div的总宽度还是300px，不过内容区被压缩成了260px。如果你在老页面里到处用width+padding控制布局，DOCTYPE一换，所有宽度全要重新校一遍。

检查页面到底处于什么模式，开发工具的控制台执行一行：

js复制document.compatMode

返回"CSS1Compat"就是标准模式，返回"BackCompat"就是怪异模式。写新页面的时候务必保证DOCTYPE在文件第一行，前面不要有任何字符，包括BOM的某些变体，不然浏览器同样可能误判。

6.3 开发思路上的两个建议

第一，HTML5新增的那些标签，在新项目里可以大胆用，基本不用太担心兼容问题了。当前所有还在更新维护的现代浏览器对这些特性的支持都已经很稳。如果遇到某个低版本环境需要支持，再用JavaScript或者构建工具补偿处理。

第二，语义化不要走火入魔。一篇文章里通篇section套section，每个小p标签都想找个新标签去包裹，其实没太大必要。页面骨架层级用语义化标签搭清楚，具体到内容里的样式细节，继续用class配合CSS管理就好。过度的语义化标签嵌套反而会造成视觉层级和DOM层级不一致，后期调样式更费劲。

7. 个人体会

HTML4到HTML5这趟升级，回头看最大价值不是多了几个标签可以显摆，而是把Web从一个"看"的媒介，推成了"用"的平台。语义化让机器能更好地理解网页内容，本地存储让网页有了记忆，媒体标签把插件时代终结了，各种API让网页能做的事从一开始的展示文档，一步步扩张到游戏、办公、实时协作这些重场景。

我自己刚入行那会儿，还在用table布局、用font调字体颜色，那时候写页面最怕是"这个样式在IE6里显示正不正常"。如今写页面要考虑的是"离线能不能看、性能够不够、在弱网环境怎么降级"。换个角度看，HTML5之后，我们学的不再是单纯的标签语法，而是怎么借浏览器的能力解决真实问题。

如果你手头正拿着一个HTML4老页面，不妨拿它先做个实验：改DOCTYPE、换掉font标签、把布局从表格切成flex或grid，每做一步都在浏览器里刷新确认。这个过程走完一遍，你对两个版本差异的理解会远远超过背十遍面试题。