HTML5已是现代Web默认底座，W3C维护HTML Living Standard，基础API兼容性统一；性能优化需关注Canvas重置、纹理预加载及toDataURL阻塞；Storage受同源策略严格限制；PWA需按业务定制Service Worker缓存策略。
HTML5 已不是“新技术”，而是现代 Web 的默认底座
2026 年，HTML5 不再需要被“推广”或“学习入门”——它就是你写的每个 <html> 页面的隐含前提。W3C 早已停止发布“HTML5.1”“HTML5.2”这类版本号，转而维护 HTML Living Standard，所有新增（如 <dialog>、inert 属性）都以向后兼容方式渐进合并。
这意味着：你写 <video controls> 或 localStorage.setItem()，不用查兼容性表；Chrome、Safari、Firefox 对这些基础行为已完全对齐。真正要操心的，不是“HTML5 支不支持”，而是“这个 API 在特定上下文里有没有被限制”——比如 Geolocation API 在非 HTTPS 页面会被静默拒绝，Web Audio API 在 iOS Safari 中需用户手势触发才能播放。
Canvas 和 WebGL 性能足够做中重度游戏，但别跳过帧率监控
白鹭引擎、PixiJS、Three.js 等已在真实项目中支撑起 MOBA 类 H5 游戏和 3D 展厅，靠的是 requestAnimationFrame + WebGL + WebAssembly 三件套。但性能瓶颈往往不出现在渲染本身，而出现在：
-
Canvas每次clearRect()后未重置transform，导致累积误差与绘制错位 - 在
drawImage()前未预加载纹理，造成帧丢弃（DevTools 的 Rendering 面板可直接看到Dropped frame提示） - 误用
toDataURL()导出高清图——该操作同步阻塞主线程，移动端极易卡顿
实操建议：用 performance.now() 包裹关键渲染循环，持续记录单帧耗时；超过 16ms 就得拆逻辑或降分辨率。
立即学习“前端免费学习笔记（深入）”；
Storage API 行为一致，但同源策略比你想的更严格
localStorage、sessionStorage、IndexedDB 在所有主流引擎中执行逻辑完全对齐，问题通常出在“你以为是同源，其实不是”：
-
https://a.example.com与https://b.example.com是不同源，无法共享localStorage -
http://example.com与https://example.com是不同源（协议不同） - iframe 嵌入跨域页面时，即使父页调用
window.frames[0].localStorage也会触发SecurityError
容易踩的坑：开发时本地用 file:// 协议打开 HTML，localStorage 会因浏览器安全策略被禁用（Chrome 报 DOMException: SecurityError），必须起一个本地 server（如 npx serve）才生效。
PWA 和混合容器已成事实标准，但 Service Worker 缓存策略不能照抄模板
微信小程序 WebView、飞书多维表格插件、钉钉宜搭页面，底层都是 Chromium 内核 + HTML5 渲染。这意味着你能用 Service Worker 实现离线优先，但缓存策略必须按业务定：
- 静态资源（JS/CSS/字体）适合
Cache-first，但记得在install阶段用cache.addAll()预加载，否则首屏仍可能走网络 - API 接口响应必须用
Network-first或Stale-while-revalidate，否则用户提交表单后看到的是旧数据 - 别在
fetch事件里无条件event.respondWith(cache.match(event.request))——没缓存时会返回undefined，导致白屏
复杂点在于：微信内嵌 WebView 对 Service Worker 支持有限（仅部分安卓机型），而 iOS Safari 要求 HTTPS 且不支持 background sync。真要全平台可用，得 fallback 到 localStorage + fetch 手动缓存方案。
