html5网页即以开头的普通网页，无需特殊sdk或编译；核心是语义化标签、废弃标签规避、表单增强、localstorage使用及viewport等关键实践。
HTML5网页就是普通网页，不用额外“做”HTML5
浏览器只要加载的是以 开头的文档，就自动进入HTML5模式——没有单独的“HTML5网页制作流程”，也没有需要下载的HTML5 SDK或编译步骤。所谓“写HTML5”，本质是用更语义化的标签（如 <code><header></header>、<nav></nav>、<article></article>）替代一堆 <div class="header">，同时避开已被废弃的标签（如 <code><font></font>、<center></center>、<u></u>）。
常见错误现象：Uncaught TypeError: HTML5 is not defined 这类报错根本不会出现——HTML5不是JavaScript库，不提供 HTML5.xxx() 这样的API。
- 检查是否误把
写成 <code>（大小写不影响，但别漏掉 <code>!和空格） - 别在
里引入所谓“HTML5 shiv”脚本（仅IE8及以下需要，现代项目基本不用） - 不要试图用
document.createElement('article')来“启用HTML5”——所有主流浏览器原生支持这些标签，只需正确书写即可渲染
响应式不是HTML5的内置功能，靠CSS媒体查询实现
HTML5本身不处理屏幕适配。“响应式网页”完全依赖CSS中的 @media 规则，和HTML结构无关。哪怕你只用 <div>，只要CSS写对，一样能响应式；反之，全用 <code><section></section> 却没写媒体查询，页面照样在手机上挤成一团。
使用场景：适配移动端最常用的是基于宽度断点，比如针对小屏设备加一套样式：
立即学习“前端免费学习笔记（深入）”；
@media (max-width: 768px) {
.sidebar { display: none; }
.content { width: 100%; }
}
- 必须在
中加入<meta name="viewport" content="width=device-width, initial-scale=1">，否则移动端浏览器会按桌面宽度渲染，媒体查询失效 - 避免用
min-device-width——它检测的是设备物理分辨率，容易误判；坚持用max-width或min-width（视口宽度） - 不要只测Chrome模拟器，真机访问时注意iOS Safari对
vh单位的处理异常（地址栏显隐会影响视口高度）
表单控件增强是HTML5重点，但兼容性要兜底
HTML5新增了 <input type="email">、<input type="date">、<input type="range"> 等语义化类型，它们在支持的浏览器中自动触发原生校验、唤起对应软键盘或选择器。但老版本Android WebView、部分国产浏览器内核可能只渲染为普通文本框，甚至报错。
- 永远为
<input>设置name属性，否则表单提交时该字段不会被发送 - 用
required属性做必填校验时，注意Safari旧版对type="date"的required支持不一致，建议搭配JS二次校验 - 不要依赖
placeholder替代<label></label>——它不具可访问性，且在用户输入后消失，无障碍阅读器无法读出字段用途
本地存储用 localStorage 最简单，但别存敏感数据
HTML5提供的 localStorage 是前端持久化最常用方案，比Cookie容量大（通常5MB）、不随请求发送。但它本质是字符串键值对，且同源策略下各站点数据完全隔离。
常见错误现象：QuotaExceededError —— 多见于iOS Safari私密浏览模式（此时 localStorage 被禁用），或存储内容超限（尤其误存JSON.stringify后的长字符串）。
- 写入前先用
try...catch包裹，捕获SecurityError和QuotaExceededError - 避免直接存对象：必须用
JSON.stringify()序列化，读取时用JSON.parse()反序列化 - 敏感信息（如token）别放
localStorage——XSS攻击可直接读取，应优先考虑httpOnlyCookie
localStorage 容量和隐私模式的盲目信任。这两处问题在线上环境才集中暴露，本地调试时往往一切正常。
