HTML5是面向现代Web应用的底层能力升级，核心在于canvas像素控制、video/audio跨浏览器限制、localStorage同步阻塞风险及语义化标签的无障碍价值。

HTML5 不是“一个新标签”，而是整套面向现代 Web 应用的底层能力升级。真正影响开发决策的，是那些你每天会调用、会踩坑、会查兼容性的具体特性。

的核心用途不是画图，而是像素级控制

很多人把 当成 SVG 替代品，这是误解起点。它本质是一块位图缓冲区，getContext('2d') 返回的不是绘图工具，而是像素操作接口。

• 动画帧必须手动清屏（clearRect()），否则上一帧残留
• 没有 DOM 树、不响应事件，要实现点击识别得自己算坐标 + isPointInPath()
• 高 DPI 屏幕下需手动缩放 canvas.width/canvas.height，否则模糊（devicePixelRatio 必须参与计算）
• WebGL（getContext('webgl')）才是性能关键路径，2D 上做复杂动效不如 CSS 或 SVG

const canvas = document.getElementById('myCanvas');
const ctx = canvas.getContext('2d');
// 高 DPI 适配示例
const dpr = window.devicePixelRatio || 1;
canvas.width = canvas.clientWidth * dpr;
canvas.height = canvas.clientHeight * dpr;
ctx.scale(dpr, dpr);

和 的真实限制比文档写得更硬

原生媒体标签极大简化了播放逻辑，但格式支持、行为差异和权限策略远比想象中复杂。

• Chrome 对 autoplay 有严格静音策略：未用户交互前，带声音的视频默认被阻止（muted 属性可绕过）
• Safari 在 iOS 上禁止 JS 调用 play()，必须由用户手势触发（click、touchstart）
• H.264 是最安全的视频编码，但 Firefox 默认不支持；MP4 容器 ≠ H.264 编码，导出时需确认编码器
• canplaythrough 事件不可靠，建议监听 loadeddata + readyState === 4 组合判断

localStorage 和 sessionStorage 的容量与阻塞风险常被低估

它们不是“前端数据库”，而是同步、阻塞式、无事务的键值字符串存储。

• 实际可用容量约 5–10MB（各浏览器不同），超出会抛 QuotaExceededError
• 所有读写都在主线程执行，存取大对象（如 JSON 字符串 >1MB）会导致明显卡顿
• 数据是纯字符串，存对象必须 JSON.stringify()，取回必须 JSON.parse()，失败直接报错中断流程
• 同源策略严格：子域名间不共享，http 与 https 视为不同源

try {
  localStorage.setItem('user', JSON.stringify({ id: 123, name: 'Alice' }));
} catch (e) {
  if (e.name === 'QuotaExceededError') {
    console.error('本地存储已满');
  }
}

语义化标签不是为了 SEO，而是为了无障碍与可维护性

• 多个 是合法的（如顶部主导航 + 页脚快捷导航），但每个页面应有且仅有一个
• 表示独立内容单元（博客文章、新闻条目），不是所有“区块”都该套用
• 旧项目迁移时，盲目替换 为
  可能破坏 CSS 选择器（如 div.header h1 失效）
• 辅助技术依赖这些标签构建内容大纲，但前提是结构合理——嵌套错误（如
  包在 内）反而降低可访问性

真正难的不是记住哪些标签新增了，而是在加载策略、错误降级、跨端行为、性能临界点这些地方做取舍。比如一个 标签背后，可能要同时处理 Safari 的手势限制、Chrome 的自动播放策略、低端 Android 的解码失败 fallback，以及服务端 HLS 分片配置是否匹配——这些细节，才是 HTML5 在真实项目里的样子。