尧图网页设计 
这套题的源头其实挺简单。我前阵子翻到之前出的几套 HTML5 测验发现不少读者留言说“看文档都会一到写页面就露馅”尤其是遇到不同浏览器对 HTML5 播放器的支持差异、Canvas 动画性能调优、移动端适配这几类问题时特别容易懵。所以就有了今天这套“HTML5 测验四”不玩虚的每道题都是从真实项目里抽出来的场景考的不只是“记没记住 API”更是“能不能在排错时快速想到原因”。这套题适合两类人一类是刚学会 HTML5 标签和 Canvas 基础语法、准备做点实际页面的前端学习者另一类是做了两三年页面开发、想自查有没有知识盲区的从业者。如果你属于前者建议先跟着题目自己敲一遍再往下看解析如果是后者可以直接跳到章节后的“排查思路”部分那里是整篇最值钱的细节。1. 这套测验的选题逻辑为什么全是“项目里踩过的坑”先说说选题思路。网上讲 HTML5 的教程很多但多数都停留在“这个标签长什么样”“这个 API 有哪些参数”的层面。真正写页面的时候你会发现问题从来不是某个 API 不会用而是几个 API 叠加在一起后暴露出来的兼容性、性能和语义化问题。1.1 从 5 类高频问题里面选考点我整理了一下过去半年在项目里遇到的 HTML5 相关问题发现集中在 5 类场景上场景分类典型问题涉及知识点音视频播放视频在 Safari 里不显示、在 Chrome 里正常video 标签、编解码格式、playsinline视觉动效粒子动画一多就掉帧、canvas 在高清屏上发虚Canvas 2D、requestAnimationFrame、devicePixelRatio移动端适配手机打开页面字特别小、布局乱viewport meta、rem/vw 适配动画渲染CSS 动画和 JS 动画混用时页面卡合成层、transform/opacity、will-change语义化结构开发者工具里提示“section 缺少标题”HTML5 语义化标签、文档大纲这 5 类正好对应热词里的“不同浏览器对 HTML5 播放器的支持”“HTML5 爱心烟花特效代码”“HTML5 网页设计”几个方向。很多读者做个人项目时喜欢用 HTML5 做点有意思的东西——圣诞贺卡、烟花特效、音乐播放器本质上都会碰到这些坑所以我干脆把它们全部揉进题目里。1.2 答题建议先盲答再对答案我强烈建议你先找个编辑器把题复制下来自己写一遍答案再来看解析。哪怕答案写错了也没关系错得越具体后面看解析时印象越深。这套题不是用来评分的是帮你定位“哪些细节你其实没掌握”。2. 第一道实测题video 播放器在不同浏览器的“隐形差异”题目以下代码在 PC 端 Chrome 里能正常播放 mp4 视频但是在 iPhone 的 Safari 里打开后视频区域一片空白点击没有任何反应播放按钮也不显示。请指出至少两个可能的原因并写出修复后的完整代码。video srcdemo.mp4 width640 height360/video这道题几乎把所有“只做 PC 页面的人”全考趴下了。视频在 PC Chrome 里太容易正常了因为 Chrome 几乎什么格式都能解可一到移动端 Safari问题一堆接一堆。2.1 原因一苹果 Safari 对 HTML5 视频内联播放的限制在 iOS Safari 里默认情况下视频是全屏播放的而且如果你不处理 WebKit 的扩展属性视频根本不会内嵌在页面里显示。必须加上playsinlineiOS 10 以后才支持老版本还得配webkit-playsinline才能让视频“老老实实”待在页面里。提示从 iOS 10 开始playsinline替代了老的webkit-playsinline但既要兼容老 iOS 又要保证新系统正常两个属性同时写上最保守。修复后的正确姿势是video srcdemo.mp4 width640 height360 playsinline webkit-playsinline muted/video注意这里muted也建议加上。iOS Safari 还有一条规则带有声音的视频不能自动播放但静音的视频可以。如果你的场景是“页面加载后自动播放背景视频”不设 muted 在所有移动端浏览器里都会被拦下来。2.2 原因二编码格式不一定是 Safari 认识的“那一款”很多人以为“mp4 就是 mp4”其实 mp4 是个容器里面的视频编码可能是 H.264也可能是 H.265HEVC还有可能是 MPEG-4 Part 2 这种老编码。Safari 对 H.264AVC的支持很稳定但对 H.265 的支持取决于具体设备和系统版本早期 iOS 版本直接不支持。反观 Chrome因为捆绑了 FFmpeg 的软解能力很多格式都能播但这恰恰掩盖了格式不兼容的问题。当你发现“Chrome 能播Safari 不能播”时第一步不是加各种属性而是先查两件事视频的编码格式是什么用ffprobe查看命令ffprobe demo.mp4看Video: h264还是hev1。音频编码是否是 AACSafari 对某些音频编码兼容性也一般。如果视频是 H.265 编码最稳妥的做法是转出一份 H.264 的版本然后用多源标签video controls playsinline webkit-playsinline source srcdemo-h264.mp4 typevideo/mp4 source srcdemo.webm typevideo/webm 你的浏览器不支持 HTML5 视频播放器。 /video这里把controls加回来是为了让用户自己控制播放。如果你既要自动播放又不要控件就保持muted autoplay playsinline的组合这是背景视频的标准配方。2.3 由 video 延伸出的播放器选型思路这道题考的是“不同浏览器对 HTML5 播放器的支持”问题但并不仅限于原生 video。很多项目直接上了 video.js 或 plyr 这种第三方播放器它们本质上也是对原生 video 的封装。这里我提一个经验项目里先用原生 video 把逻辑跑通再接播放器库遇到问题好排查。如果一上来就套 library出了兼容性问题你根本分不清是原生能力限制还是库的 bug。我实际踩过 video.js 在移动端控制栏不出来的坑最后排查下来是它依赖的 Flash 回退逻辑在作祟和原生 video 无关。3. 第二道实测题Canvas 爱心烟花特效的性能症结题目某同学写了一个“HTML5 爱心烟花特效”在桌面 Chrome 上跑得很流畅但换到另一台配置稍低的笔记本上粒子一旦超过 300 个就开始明显掉帧。以下是他的核心循环代码请指出至少 3 处性能问题并说明改进方案。const canvas document.getElementById(fireworks); const ctx canvas.getContext(2d); const particles []; function animate() { if (particles.length 500) { particles.push(new Particle()); } ctx.clearRect(0, 0, canvas.width, canvas.height); particles.forEach(p p.draw()); requestAnimationFrame(animate); }这道题考的是 Canvas 粒子系统的底层优化网上能搜到不少“HTML5 爱心烟花特效代码”但大部分只做到了“能跑”完全没考虑性能边界。逐条拆解。3.1 性能问题一清屏方式太粗暴没有考虑“残影”与“刷新率”ctx.clearRect(0, 0, canvas.width, canvas.height)本身没错但它会清掉整个画布。如果粒子后面有背景层每次你都等于把背景重新画了一遍。更常见的高性能做法是用ctx.fillRect填充半透明背景形成“拖尾”效果同时减少重绘面积// 半透明填充代替 clearRect能产生运动轨迹视觉上更有烟花拖尾感 ctx.fillStyle rgba(0, 0, 0, 0.1); ctx.fillRect(0, 0, canvas.width, canvas.height);这里有个细节rgba的 alpha 值越小拖尾越长但粒子叠加次数多了以后画布会越来越亮因为没有完全清干净。所以要根据粒子数量动态调整 alpha——粒子多时 alpha 靠近 0.15粒子少时靠近 0.08 是个人经验值。3.2 性能问题二粒子对象创建无上限没有“存活周期”这段代码的if (particles.length 500)只是限制了粒子总量的上限但粒子生成后永远不会被销毁。每个Particle对象一旦push进去就一直存在即使它已经飞出屏幕、alpha 已经降为 0。内存里堆了 500 个“僵尸粒子”每帧还在执行draw()开销全白费了。正确做法是给粒子加一个life生命周期每帧递减life 0时从数组里移除class Particle { constructor() { this.x canvas.width / 2; this.y canvas.height / 2; this.vx (Math.random() - 0.5) * 8; this.vy (Math.random() - 0.5) * 8; this.life 1; // 从1开始衰减 this.decay 0.01 Math.random() * 0.02; this.alpha 1; } update() { this.x this.vx; this.y this.vy; this.vy 0.1; // 模拟重力让粒子有下坠感 this.life - this.decay; this.alpha Math.max(0, this.life); } draw(ctx) { if (this.life 0) return; ctx.globalAlpha this.alpha; ctx.beginPath(); ctx.arc(this.x, this.y, 2, 0, Math.PI * 2); ctx.fillStyle hsl(${(this.hue this.life * 30) % 360}, 70%, 60%); ctx.fill(); } } // 主循环里只保留 alive 的粒子 particles particles.filter(p p.life 0);这里把颜色用hsl动态计算粒子生命值变化时颜色跟着变化视觉上会有一个从亮到暗、从暖到冷的渐变效果比单一颜色生动得多。滤波操作filter每帧也有一点开销但 500 个粒子以下是完全可接受的不要为了省这一点点开销引入复杂的内存池方案——那是粒子数量过万时才需要考虑的优化。3.3 性能问题三没有清理 Canvas 上的全局状态ctx.globalAlpha是全局属性一旦在某个粒子身上设置了后续所有绘制都会受影响。而这段代码里粒子类内部设置globalAlpha后下一个粒子也会沿用这个值最终导致画面透明度越来越低。解决方案是画完一个粒子后立即恢复ctx.globalAlpha 1; // 在批次绘制前后重置更精细的做法是在draw方法内部用save()和restore()包裹draw(ctx) { if (this.life 0) return; ctx.save(); ctx.globalAlpha this.alpha; ctx.beginPath(); ctx.arc(this.x, this.y, 2, 0, Math.PI * 2); ctx.fillStyle hsl(${this.hue}, 70%, 60%); ctx.fill(); ctx.restore(); }save/restore有性能代价但只在粒子数量在数百级别时是安全的。如果你要优化的粒子数以千计就不要用save/restore改成每次循环结束手动重置globalAlpha、fillStyle等状态。这也是我在大项目里看到的两种主流写法。3.4 额外加分的坑高清屏适配与 Resize这道题如果再加一问我会问“为什么同一份烟花特效代码在 MacBook Retina 屏幕上边缘发虚”答案是 canvas 的物理像素不等于 CSS 像素。你设置canvas.width 500但页面 CSS 里canvas { width: 500px; }在 2 倍屏下实际渲染是 1000 物理像素canvas 只有 500 物理像素浏览器强行拉伸后必然模糊。修复方式const dpr window.devicePixelRatio || 1; canvas.width canvas.clientWidth * dpr; canvas.height canvas.clientHeight * dpr; ctx.scale(dpr, dpr);坐标计算时依然按 CSS 像素写ctx.scale(dpr, dpr)负责把所有绘制操作放大到物理像素量级这样在 Retina 屏幕上才清晰。再配一个 resize 监听去更新 canvas 尺寸同时把粒子的坐标按新宽高做比例调整否则窗口一变粒子可能全跑出可视区。4. 第三道实测题圣诞贺卡页面为什么手机上是一团乱码题目某同学做了一个“HTML5 圣诞贺卡”页面在 PC Chrome 里显示完美用手机扫码打开后文字非常小、布局全部挤在一起背景图也只显示左上角一小块。请问最可能的原因是什么写出修复后的方案。初始代码head meta charsetUTF-8 title圣诞祝福/title /head这道题在热词“HTML5 圣诞贺卡”里特别应景。每年圣诞前后都有人拿 HTML5 做贺卡页面然后扫码发群里结果同事用手机打开发现页面完全没法看。问题几乎 100% 出在viewportmeta 标签缺失。4.1 缺失 viewport meta 引发的“980 像素布局问题”当页面没有设置 viewport 时移动端浏览器会默认用一个 980px部分老安卓是 800px宽的虚拟视口来渲染页面然后再缩小到手机屏幕宽度。这就导致两个现象一是整个页面的 CSS 布局被当成 980px 来算手机屏幕宽度只有 375px全部内容被等比缩小字当然就变得特别小二是如果背景图是用固定像素宽度定义的它也会被缩小到看不见的角落看起来就像是“只显示左上角一小块”。修复方式是在head里加入标准的 viewport 设置meta nameviewport contentwidthdevice-width, initial-scale1.0, maximum-scale1.0, user-scalableno这里面widthdevice-width是关键它让视口宽度等于设备宽度。initial-scale1.0让初始缩放比例为 1maximum-scale1.0和user-scalableno是为了防止用户误操作放大导致布局漂移。但从可访问性的角度不建议完全禁止用户缩放所以个人建议去掉maximum-scale和user-scalableno只保留meta nameviewport contentwidthdevice-width, initial-scale1.04.2 圣诞贺卡页面里的 rem 适配方案加完 viewport 后字还是基于 px 的手机上虽然不再被强制缩小但大屏幕和小屏幕显示效果差别很大ipad 上显得字太大、小屏安卓上又显得小。做这种偏营销展示的贺卡页面我推荐用rem适配方案。核心原理给html根元素设置一个基准字号页面上所有元素用rem写1rem 根元素字号。然后用 JS 根据屏幕宽度动态调整根字号(function (doc, win) { const docEl doc.documentElement; const recalc () { const clientWidth docEl.clientWidth; if (!clientWidth) return; // 以 375 设计稿为基准根字体大小 屏幕宽度 / 375 * 16 docEl.style.fontSize (clientWidth / 375) * 16 px; }; recalc(); win.addEventListener(resize, recalc, false); win.addEventListener(pageshow, recalc, false); })(document, window);这样设计稿里写font-size: 16px的标题代码里就写1rem在 375px 宽的手机上实际渲染 16px在 414px 的 Plus 上就是414/375 * 16 ≈ 17.7px等比放大。这个方案虽然老但在圣诞贺卡、活动页这种“整屏展示型”场景里比vw适配更可控因为缩放基准是线性的。4.3 还有一道隐藏题背景图只显示左上角贺卡页面经常用background-imagebackground-size: cover来铺底图。如果题目里“背景图只显示左上角一块”另一个可能原因是只写了background: url(xxx.png)而没设置background-size。默认的background-size: auto会按图片原始像素显示一张 1920px 宽的图在 375px 宽的屏幕上自然只露出左上角。加一行background-size: cover; background-position: center center;就能解决。这个坑在“HTML5 网页设计”里出现频率极高但很多人第一反应都是去调 viewport忘了查 CSS 本身。5. 第四道实测题CSS 动画与 Canvas 交替混用的渲染链路题目一个 HTML5 互动页面里雪花飘落效果用 Canvas 实现页面标题的淡入效果用 CSSanimation实现卡片区域用transition做位移动画。实测在低端安卓机上Canvas 飘雪一启动整页的 CSS 动画就变得一顿一顿的单独运行 CSS 动画却很流畅。请分析原因并提出优化方案。这道题很多人会直接回答“因为浏览器主线程被 JS 占满”。这个说法对但不准确。真正的问题是“合成层”和“绘制”的关系没搞清。5.1 主线程与合成线程各管什么事浏览器渲染页面的管线大致是JavaScript 改样式 → 计算样式Style→ 布局Layout→ 绘制Paint→ 合成Composite。其中 Layout 和 Paint 在主线程main thread上执行合成的部分由合成线程compositor thread负责。CSStransform和opacity动画之所以流畅是因为它们可以跳过 Layout 和 Paint直接走合成线程。合成线程接到的任务是“把一个图层从 A 点移到 B 点”它不需要重新计算元素内部的样式所以特别快。但 Canvas 绘制的每一帧都要走“绘制”这一步。尤其是一整块 canvas 覆盖大面积区域时浏览器每次都要重新光栅化rasterize这一层。如果这个 canvas 层的更新频率是 60fps但页面里还有 CSS 动画也在同一时间更新两个任务都要占用主线程互相抢时间片最终的结果就是两边都掉帧。5.2 优化方向一把频繁更新的 Canvas 独立成合成层给 canvas 元素添加will-change: transform等于告诉浏览器“这个元素将要进行合成相关的变化你先把它独立成一层”。这样 canvas 层的更新可以尽量与页面其他部分分开光栅化#snowCanvas { will-change: transform; }但这只是第一步。如果同一层里既有 canvas 面积更新又有 DOM 动画合成器压力仍然大。更彻底的做法是把雪花效果区域与其他内容在布局上隔离——不要让 canvas 铺满整个视口而是限定在一个固定区域内区域越小重绘代价越低。5.3 优化方向二用 requestAnimationFrame 统一时间线当 CSS 动画和 Canvas 动画同时存在时很容易出现节奏不一致CSS 动画由合成器驱动Canvas 动画由 rAF 驱动它们的刷新时机可能错开。比较好的做法是把页面所有动态效果用同一套requestAnimationFrame时间线驱动。具体操作CSS 动画部分从animation改成不带动画只保留初始与结束状态用 JS 在 rAF 里按时间推进设置style.transform。这样所有动效的“心跳”来自同一个时钟浏览器可以更集中地批量处理。代价是写起来麻烦一些但对于“圣诞贺卡”这种短小互动页面完全可控。let startTime null; function tick(now) { if (!startTime) startTime now; const elapsed (now - startTime) / 1000; // 根据 elapsed 计算卡片位移 card.style.transform translateY(${Math.min(50, elapsed * 20)}px); // 绘制雪花 drawSnow(elapsed); if (elapsed 3) { requestAnimationFrame(tick); } } requestAnimationFrame(tick);5.4 优化方向三控制合成层数量别给每个元素都加 will-change很多同学一听“will-change 能加速”就给页面里所有动画元素都加上。这其实是反向优化。每个will-change声明都会让浏览器多创建一个合成层合成层越多内存占用越高层与层之间的合成计算反而变慢。低端安卓机上尤其明显。我的经验是整页合成层数量控制在 5 层以内只有频繁变化的容器如 canvas、轮播图、抽屉才加will-change普通淡入淡出元素不加也能流畅运行。因为单纯改opacity本身就已经是合成器友好的属性不需要额外声明。这道题的核心价值在于它纠正了一个常见的错误认知——以为动画卡顿一定是因为 JS 逻辑太多却忽略了合成层竞争和绘制面积的影响。排查步骤应该是打开 DevTools 的 Rendering 面板开启Layer borders观察页面分层情况。开启Paint flashing看哪些区域在不停重绘。把所有重绘区域尽量合并到同一个合成层减少绘制面积。再考虑用 rAF 统一时间线。6. 第五道实测题语义化标签组合的“合法错误”题目以下 HTML5 页面结构用 W3C 验证器会报错吗如果不报错但文档大纲document outline有严重问题请指出并给出修改后的版本。body header nav首页 | 关于 | 联系/nav /header main article section内容一/section section内容二/section /article aside侧边栏/aside /main footer© 2025 测试页/footer /body这道题的陷阱在于标签都用对了但语义层级完全乱了。header里直接放navsection内没有标题article里的内容没有标题层级这些都不会引发验证器报错但对“HTML5 网页设计”的读者来说恰恰是很容易忽略的点。6.1 为什么 section 一定要有标题按 HTML5 规范section表示文档中的一个独立区域这个区域“通常会有标题”。虽然浏览器不会强制报错但屏幕阅读器会依据标题层级来生成文档大纲。没有标题的section在无障碍树里是一团没有标识的区块读屏用户根本不知道这个区域讲的是什么。aside在main里面也不是不行但要区分它描述的是谁。如果aside内容与article直接相关它可以放在article内部如果是整站通用的推荐链接应该放在main之外。上面代码里aside放在main内部语义上更像是“这篇文章的附属信息”但如果它其实是全站侧边栏这就是语义错误。6.2 修正后的结构body header nav aria-label主导航 a href/首页/a a href/about关于/a a href/contact联系/a /nav /header main article h1文章标题/h1 p导语段落/p section aria-labelledbysec1 h2 idsec1内容一小节/h2 p正文.../p /section section aria-labelledbysec2 h2 idsec2内容二小节/h2 p正文.../p /section aside aria-label文章相关链接 p相关阅读/p /aside /article /main footer© 2025 测试页/footer /body改动要点有三个每个section加一个h2标题并用aria-labelledby与标题关联增强无障碍识别。如果aside是文章相关链接放进article如果是全站侧边栏移出main。nav里加aria-label区分“主导航”和页脚的“次导航”防止读屏软件混淆。6.3 语义化为什么影响渲染性能与 SEO很多人觉得语义化只是“写给别人看的规范”其实它还有实际收益。搜索引擎抓取页面时会优先识别main、article、h1等标签内的内容作为核心内容。如果你整个页面全是div即便视觉上没问题搜索引擎也很难把文章的正文和导航栏区分开可能导致关键词权重降低。另外屏幕阅读器在main标签处可以自动跳过重复的导航栏直接进入正文这是对残障用户的直接支撑。实际项目中做 B 端后台管理系统的时候不用太纠结语义化——内容少、交互密度高div虽然朴素但效率高但做 C 端官网、博客、营销活动页时语义化是必须的因为内容质量和 SEO 都与之直接相关。这套“quiz 四”的定位本质上就是帮你界定清楚什么场景吃什么规范。7. 补测题三道快问快答测你有没有隐藏盲区除了上面五道大题我在最后加三道 30 秒快问快答都是实际项目里会碰到的“小判断”。7.1sessionStorage和localStorage能否跨标签页共享先说结论localStorage可以在同源的所有标签页共享sessionStorage不行它只存在于当前标签页。但有个极易忽略的坑如果用户用“复制标签页”的方式打开新页部分浏览器比如 Chrome会复制一份sessionStorage而用地址栏新开标签页则拿不到原标签页的sessionStorage。所以涉及登录态、支付流程里如果用sessionStorage做临时状态传递一定要考虑“用户从新标签打开”的场景这时候会直接丢失数据跳到支付成功页却没有订单号的尴尬场面我见过不止一次。7.2 表单里required与pattern同时存在时的校验顺序浏览器先校验required是否为空再校验pattern是否符合格式。这个顺序的意义在于排错如果你在控制台里看不到校验失败提示先检查是不是第一个条件就挂了。另外pattern里的正则默认是锚定整段匹配的不像 JS 原生regex.test是部分匹配——写pattern[0-9]{4}时输入12345是不会通过的因为它要求整串匹配 4 位数字。想允许更多位数写成pattern[0-9]{4,}才有用。7.3Canvas和SVG在动画场景下的选择边界这个问题老生常谈但每次都能考住人。一句话总结元素数量少几十到几百、单帧状态简单、需要事件绑定和缩放不失真选 SVG元素数量大上千、每帧都有坐标动态变化、需要像素级特效烟花、粒子、拖尾选 Canvas。圣诞贺卡里的雪花如果只有 30 片用 SVG 就够而且还省去了 Canvas 的清晰度和适配问题如果是上千片暴风雪Canvas 才是合适的选择。判断标准不是“哪个更高级”而是“数据量和交互复杂度处在哪个量级”。这三道补测题虽然短背后对应的却是实际开发里的高频困惑。我把它们放进这套测验是因为很多人做完前五题会觉得自己已经 “精通”HTML5 了但这三道题会提醒你——还早坑还多着呢。8. 阅卷心得从这套题反推出来的 HTML5 学习路径既然这套题叫“测验四”前面肯定还有几套但这个系列做到这里我更想谈的是透过这些题总结出来的一个学习方法要把 HTML5 当“工程科目”而不是“语法科目”来学。8.1 会写 demo 不等于能上线很多同学学 HTML5停留在“照着文档写一个 canvas 动画 demo”“用 video 标签播一段视频”的层面。但真正上线一个 HTML5 页面你需要回答这些文档里没写的细节视频编码格式怎么选要不要准备多份转码。移动端适配究竟用 rem 还是 vw适配基准怎么确定。canvas 动画在低端机上掉帧了是先优化绘制还是先优化内存。页面卡顿的时候如何快速定位是主线程占用还是合成层过多。这些问题的答案往往不在任何一本 HTML5 语法书里而要在真实项目中查资料、看 Performance 面板、逐帧分析才能积累。这套测验设计的核心意图就是把这些“工程化经验”以题目的形式暴露出来。8.2 建议的 HTML5 进阶路径如果你测完这套题发现自己一部分答不上来不用慌。按下面的路径重新整理知识第一阶段标签与基础 API把video、audio、canvas、svg、localStorage、sessionStorage、requestAnimationFrame、FormData这些基础 API 全部过一遍至少清楚每个 API 的边界和典型使用场景。这个阶段以“看文档 写最小 demo”为主。第二阶段浏览器的渲染差异主动去查你写的每个 API 在 Chrome、Safari、Firefox、以及不同版本 iOS/Android 上的兼容性。推荐用 caniuse.com 对照同时本地装一台 iOS 模拟器或真机测试环境。只有亲自看到“同一个页面在不同浏览器里的表现”才能在后续项目里形成直觉。第三阶段性能优化学会用 DevTools 的 Performance、Rendering、Layer 面板以及 Lighthouse。当你写的页面出现卡顿时能自己说出“是绘制面积太大还是合成层太多还是主线程 JS 耗时过长”。这个阶段的标志性能力是你能在 5 分钟内定位一处掉帧问题的根因。第四阶段工程化整合把 HTML5 能力放进实际项目中前端基础HTMLCSSJS之上接上工程化工具打包、转译、代码分割。你需要知道哪些 HTML5 特性可以用在哪些实际业务场景中哪些不适用。这一点对做中大型项目尤其重要。8.3 对照自查表你处于哪个阶段阶段能力表现建议练习L1能写 video/canvas 基础 demo但不知道浏览器差异把前两道题的多源视频和粒子生命周期手动改到正确L2知道移动端要加 viewport会调 canvas 高清适配做一版兼容 iPhone 和安卓的完整页面L3能处理页面卡顿会看 Performance 和 Layer 面板做一个超过 1000 粒子的动画并优化到 60fpsL4能根据业务场景选型svg 还是 canvas、原生视频还是播放器库用 HTML5 做一个完整的小型产品原型这套“测验四”不是终点而是帮你定位自己现在处在哪一档。我当年从 L1 升到 L2 用的土办法很笨每次遇到一个页面问题就新开一个空白测试页用最简代码复现然后在浏览器控制台逐行验证最后把结论写进自己的笔记。这个过程虽然慢但积累下来的“可复现案例”比任何教程都有说服力。你现在做这门测验本质上也是在做同样的事。 HTML5实战测验：从视频兼容到Canvas性能优化的避坑指南
这套题的源头其实挺简单。我前阵子翻到之前出的几套 HTML5 测验发现不少读者留言说“看文档都会一到写页面就露馅”尤其是遇到不同浏览器对 HTML5 播放器的支持差异、Canvas 动画性能调优、移动端适配这几类问题时特别容易懵。所以就有了今天这套“HTML5 测验四”不玩虚的每道题都是从真实项目里抽出来的场景考的不只是“记没记住 API”更是“能不能在排错时快速想到原因”。这套题适合两类人一类是刚学会 HTML5 标签和 Canvas 基础语法、准备做点实际页面的前端学习者另一类是做了两三年页面开发、想自查有没有知识盲区的从业者。如果你属于前者建议先跟着题目自己敲一遍再往下看解析如果是后者可以直接跳到章节后的“排查思路”部分那里是整篇最值钱的细节。1. 这套测验的选题逻辑为什么全是“项目里踩过的坑”先说说选题思路。网上讲 HTML5 的教程很多但多数都停留在“这个标签长什么样”“这个 API 有哪些参数”的层面。真正写页面的时候你会发现问题从来不是某个 API 不会用而是几个 API 叠加在一起后暴露出来的兼容性、性能和语义化问题。1.1 从 5 类高频问题里面选考点我整理了一下过去半年在项目里遇到的 HTML5 相关问题发现集中在 5 类场景上场景分类典型问题涉及知识点音视频播放视频在 Safari 里不显示、在 Chrome 里正常video 标签、编解码格式、playsinline视觉动效粒子动画一多就掉帧、canvas 在高清屏上发虚Canvas 2D、requestAnimationFrame、devicePixelRatio移动端适配手机打开页面字特别小、布局乱viewport meta、rem/vw 适配动画渲染CSS 动画和 JS 动画混用时页面卡合成层、transform/opacity、will-change语义化结构开发者工具里提示“section 缺少标题”HTML5 语义化标签、文档大纲这 5 类正好对应热词里的“不同浏览器对 HTML5 播放器的支持”“HTML5 爱心烟花特效代码”“HTML5 网页设计”几个方向。很多读者做个人项目时喜欢用 HTML5 做点有意思的东西——圣诞贺卡、烟花特效、音乐播放器本质上都会碰到这些坑所以我干脆把它们全部揉进题目里。1.2 答题建议先盲答再对答案我强烈建议你先找个编辑器把题复制下来自己写一遍答案再来看解析。哪怕答案写错了也没关系错得越具体后面看解析时印象越深。这套题不是用来评分的是帮你定位“哪些细节你其实没掌握”。2. 第一道实测题video 播放器在不同浏览器的“隐形差异”题目以下代码在 PC 端 Chrome 里能正常播放 mp4 视频但是在 iPhone 的 Safari 里打开后视频区域一片空白点击没有任何反应播放按钮也不显示。请指出至少两个可能的原因并写出修复后的完整代码。video srcdemo.mp4 width640 height360/video这道题几乎把所有“只做 PC 页面的人”全考趴下了。视频在 PC Chrome 里太容易正常了因为 Chrome 几乎什么格式都能解可一到移动端 Safari问题一堆接一堆。2.1 原因一苹果 Safari 对 HTML5 视频内联播放的限制在 iOS Safari 里默认情况下视频是全屏播放的而且如果你不处理 WebKit 的扩展属性视频根本不会内嵌在页面里显示。必须加上playsinlineiOS 10 以后才支持老版本还得配webkit-playsinline才能让视频“老老实实”待在页面里。提示从 iOS 10 开始playsinline替代了老的webkit-playsinline但既要兼容老 iOS 又要保证新系统正常两个属性同时写上最保守。修复后的正确姿势是video srcdemo.mp4 width640 height360 playsinline webkit-playsinline muted/video注意这里muted也建议加上。iOS Safari 还有一条规则带有声音的视频不能自动播放但静音的视频可以。如果你的场景是“页面加载后自动播放背景视频”不设 muted 在所有移动端浏览器里都会被拦下来。2.2 原因二编码格式不一定是 Safari 认识的“那一款”很多人以为“mp4 就是 mp4”其实 mp4 是个容器里面的视频编码可能是 H.264也可能是 H.265HEVC还有可能是 MPEG-4 Part 2 这种老编码。Safari 对 H.264AVC的支持很稳定但对 H.265 的支持取决于具体设备和系统版本早期 iOS 版本直接不支持。反观 Chrome因为捆绑了 FFmpeg 的软解能力很多格式都能播但这恰恰掩盖了格式不兼容的问题。当你发现“Chrome 能播Safari 不能播”时第一步不是加各种属性而是先查两件事视频的编码格式是什么用ffprobe查看命令ffprobe demo.mp4看Video: h264还是hev1。音频编码是否是 AACSafari 对某些音频编码兼容性也一般。如果视频是 H.265 编码最稳妥的做法是转出一份 H.264 的版本然后用多源标签video controls playsinline webkit-playsinline source srcdemo-h264.mp4 typevideo/mp4 source srcdemo.webm typevideo/webm 你的浏览器不支持 HTML5 视频播放器。 /video这里把controls加回来是为了让用户自己控制播放。如果你既要自动播放又不要控件就保持muted autoplay playsinline的组合这是背景视频的标准配方。2.3 由 video 延伸出的播放器选型思路这道题考的是“不同浏览器对 HTML5 播放器的支持”问题但并不仅限于原生 video。很多项目直接上了 video.js 或 plyr 这种第三方播放器它们本质上也是对原生 video 的封装。这里我提一个经验项目里先用原生 video 把逻辑跑通再接播放器库遇到问题好排查。如果一上来就套 library出了兼容性问题你根本分不清是原生能力限制还是库的 bug。我实际踩过 video.js 在移动端控制栏不出来的坑最后排查下来是它依赖的 Flash 回退逻辑在作祟和原生 video 无关。3. 第二道实测题Canvas 爱心烟花特效的性能症结题目某同学写了一个“HTML5 爱心烟花特效”在桌面 Chrome 上跑得很流畅但换到另一台配置稍低的笔记本上粒子一旦超过 300 个就开始明显掉帧。以下是他的核心循环代码请指出至少 3 处性能问题并说明改进方案。const canvas document.getElementById(fireworks); const ctx canvas.getContext(2d); const particles []; function animate() { if (particles.length 500) { particles.push(new Particle()); } ctx.clearRect(0, 0, canvas.width, canvas.height); particles.forEach(p p.draw()); requestAnimationFrame(animate); }这道题考的是 Canvas 粒子系统的底层优化网上能搜到不少“HTML5 爱心烟花特效代码”但大部分只做到了“能跑”完全没考虑性能边界。逐条拆解。3.1 性能问题一清屏方式太粗暴没有考虑“残影”与“刷新率”ctx.clearRect(0, 0, canvas.width, canvas.height)本身没错但它会清掉整个画布。如果粒子后面有背景层每次你都等于把背景重新画了一遍。更常见的高性能做法是用ctx.fillRect填充半透明背景形成“拖尾”效果同时减少重绘面积// 半透明填充代替 clearRect能产生运动轨迹视觉上更有烟花拖尾感 ctx.fillStyle rgba(0, 0, 0, 0.1); ctx.fillRect(0, 0, canvas.width, canvas.height);这里有个细节rgba的 alpha 值越小拖尾越长但粒子叠加次数多了以后画布会越来越亮因为没有完全清干净。所以要根据粒子数量动态调整 alpha——粒子多时 alpha 靠近 0.15粒子少时靠近 0.08 是个人经验值。3.2 性能问题二粒子对象创建无上限没有“存活周期”这段代码的if (particles.length 500)只是限制了粒子总量的上限但粒子生成后永远不会被销毁。每个Particle对象一旦push进去就一直存在即使它已经飞出屏幕、alpha 已经降为 0。内存里堆了 500 个“僵尸粒子”每帧还在执行draw()开销全白费了。正确做法是给粒子加一个life生命周期每帧递减life 0时从数组里移除class Particle { constructor() { this.x canvas.width / 2; this.y canvas.height / 2; this.vx (Math.random() - 0.5) * 8; this.vy (Math.random() - 0.5) * 8; this.life 1; // 从1开始衰减 this.decay 0.01 Math.random() * 0.02; this.alpha 1; } update() { this.x this.vx; this.y this.vy; this.vy 0.1; // 模拟重力让粒子有下坠感 this.life - this.decay; this.alpha Math.max(0, this.life); } draw(ctx) { if (this.life 0) return; ctx.globalAlpha this.alpha; ctx.beginPath(); ctx.arc(this.x, this.y, 2, 0, Math.PI * 2); ctx.fillStyle hsl(${(this.hue this.life * 30) % 360}, 70%, 60%); ctx.fill(); } } // 主循环里只保留 alive 的粒子 particles particles.filter(p p.life 0);这里把颜色用hsl动态计算粒子生命值变化时颜色跟着变化视觉上会有一个从亮到暗、从暖到冷的渐变效果比单一颜色生动得多。滤波操作filter每帧也有一点开销但 500 个粒子以下是完全可接受的不要为了省这一点点开销引入复杂的内存池方案——那是粒子数量过万时才需要考虑的优化。3.3 性能问题三没有清理 Canvas 上的全局状态ctx.globalAlpha是全局属性一旦在某个粒子身上设置了后续所有绘制都会受影响。而这段代码里粒子类内部设置globalAlpha后下一个粒子也会沿用这个值最终导致画面透明度越来越低。解决方案是画完一个粒子后立即恢复ctx.globalAlpha 1; // 在批次绘制前后重置更精细的做法是在draw方法内部用save()和restore()包裹draw(ctx) { if (this.life 0) return; ctx.save(); ctx.globalAlpha this.alpha; ctx.beginPath(); ctx.arc(this.x, this.y, 2, 0, Math.PI * 2); ctx.fillStyle hsl(${this.hue}, 70%, 60%); ctx.fill(); ctx.restore(); }save/restore有性能代价但只在粒子数量在数百级别时是安全的。如果你要优化的粒子数以千计就不要用save/restore改成每次循环结束手动重置globalAlpha、fillStyle等状态。这也是我在大项目里看到的两种主流写法。3.4 额外加分的坑高清屏适配与 Resize这道题如果再加一问我会问“为什么同一份烟花特效代码在 MacBook Retina 屏幕上边缘发虚”答案是 canvas 的物理像素不等于 CSS 像素。你设置canvas.width 500但页面 CSS 里canvas { width: 500px; }在 2 倍屏下实际渲染是 1000 物理像素canvas 只有 500 物理像素浏览器强行拉伸后必然模糊。修复方式const dpr window.devicePixelRatio || 1; canvas.width canvas.clientWidth * dpr; canvas.height canvas.clientHeight * dpr; ctx.scale(dpr, dpr);坐标计算时依然按 CSS 像素写ctx.scale(dpr, dpr)负责把所有绘制操作放大到物理像素量级这样在 Retina 屏幕上才清晰。再配一个 resize 监听去更新 canvas 尺寸同时把粒子的坐标按新宽高做比例调整否则窗口一变粒子可能全跑出可视区。4. 第三道实测题圣诞贺卡页面为什么手机上是一团乱码题目某同学做了一个“HTML5 圣诞贺卡”页面在 PC Chrome 里显示完美用手机扫码打开后文字非常小、布局全部挤在一起背景图也只显示左上角一小块。请问最可能的原因是什么写出修复后的方案。初始代码head meta charsetUTF-8 title圣诞祝福/title /head这道题在热词“HTML5 圣诞贺卡”里特别应景。每年圣诞前后都有人拿 HTML5 做贺卡页面然后扫码发群里结果同事用手机打开发现页面完全没法看。问题几乎 100% 出在viewportmeta 标签缺失。4.1 缺失 viewport meta 引发的“980 像素布局问题”当页面没有设置 viewport 时移动端浏览器会默认用一个 980px部分老安卓是 800px宽的虚拟视口来渲染页面然后再缩小到手机屏幕宽度。这就导致两个现象一是整个页面的 CSS 布局被当成 980px 来算手机屏幕宽度只有 375px全部内容被等比缩小字当然就变得特别小二是如果背景图是用固定像素宽度定义的它也会被缩小到看不见的角落看起来就像是“只显示左上角一小块”。修复方式是在head里加入标准的 viewport 设置meta nameviewport contentwidthdevice-width, initial-scale1.0, maximum-scale1.0, user-scalableno这里面widthdevice-width是关键它让视口宽度等于设备宽度。initial-scale1.0让初始缩放比例为 1maximum-scale1.0和user-scalableno是为了防止用户误操作放大导致布局漂移。但从可访问性的角度不建议完全禁止用户缩放所以个人建议去掉maximum-scale和user-scalableno只保留meta nameviewport contentwidthdevice-width, initial-scale1.04.2 圣诞贺卡页面里的 rem 适配方案加完 viewport 后字还是基于 px 的手机上虽然不再被强制缩小但大屏幕和小屏幕显示效果差别很大ipad 上显得字太大、小屏安卓上又显得小。做这种偏营销展示的贺卡页面我推荐用rem适配方案。核心原理给html根元素设置一个基准字号页面上所有元素用rem写1rem 根元素字号。然后用 JS 根据屏幕宽度动态调整根字号(function (doc, win) { const docEl doc.documentElement; const recalc () { const clientWidth docEl.clientWidth; if (!clientWidth) return; // 以 375 设计稿为基准根字体大小 屏幕宽度 / 375 * 16 docEl.style.fontSize (clientWidth / 375) * 16 px; }; recalc(); win.addEventListener(resize, recalc, false); win.addEventListener(pageshow, recalc, false); })(document, window);这样设计稿里写font-size: 16px的标题代码里就写1rem在 375px 宽的手机上实际渲染 16px在 414px 的 Plus 上就是414/375 * 16 ≈ 17.7px等比放大。这个方案虽然老但在圣诞贺卡、活动页这种“整屏展示型”场景里比vw适配更可控因为缩放基准是线性的。4.3 还有一道隐藏题背景图只显示左上角贺卡页面经常用background-imagebackground-size: cover来铺底图。如果题目里“背景图只显示左上角一块”另一个可能原因是只写了background: url(xxx.png)而没设置background-size。默认的background-size: auto会按图片原始像素显示一张 1920px 宽的图在 375px 宽的屏幕上自然只露出左上角。加一行background-size: cover; background-position: center center;就能解决。这个坑在“HTML5 网页设计”里出现频率极高但很多人第一反应都是去调 viewport忘了查 CSS 本身。5. 第四道实测题CSS 动画与 Canvas 交替混用的渲染链路题目一个 HTML5 互动页面里雪花飘落效果用 Canvas 实现页面标题的淡入效果用 CSSanimation实现卡片区域用transition做位移动画。实测在低端安卓机上Canvas 飘雪一启动整页的 CSS 动画就变得一顿一顿的单独运行 CSS 动画却很流畅。请分析原因并提出优化方案。这道题很多人会直接回答“因为浏览器主线程被 JS 占满”。这个说法对但不准确。真正的问题是“合成层”和“绘制”的关系没搞清。5.1 主线程与合成线程各管什么事浏览器渲染页面的管线大致是JavaScript 改样式 → 计算样式Style→ 布局Layout→ 绘制Paint→ 合成Composite。其中 Layout 和 Paint 在主线程main thread上执行合成的部分由合成线程compositor thread负责。CSStransform和opacity动画之所以流畅是因为它们可以跳过 Layout 和 Paint直接走合成线程。合成线程接到的任务是“把一个图层从 A 点移到 B 点”它不需要重新计算元素内部的样式所以特别快。但 Canvas 绘制的每一帧都要走“绘制”这一步。尤其是一整块 canvas 覆盖大面积区域时浏览器每次都要重新光栅化rasterize这一层。如果这个 canvas 层的更新频率是 60fps但页面里还有 CSS 动画也在同一时间更新两个任务都要占用主线程互相抢时间片最终的结果就是两边都掉帧。5.2 优化方向一把频繁更新的 Canvas 独立成合成层给 canvas 元素添加will-change: transform等于告诉浏览器“这个元素将要进行合成相关的变化你先把它独立成一层”。这样 canvas 层的更新可以尽量与页面其他部分分开光栅化#snowCanvas { will-change: transform; }但这只是第一步。如果同一层里既有 canvas 面积更新又有 DOM 动画合成器压力仍然大。更彻底的做法是把雪花效果区域与其他内容在布局上隔离——不要让 canvas 铺满整个视口而是限定在一个固定区域内区域越小重绘代价越低。5.3 优化方向二用 requestAnimationFrame 统一时间线当 CSS 动画和 Canvas 动画同时存在时很容易出现节奏不一致CSS 动画由合成器驱动Canvas 动画由 rAF 驱动它们的刷新时机可能错开。比较好的做法是把页面所有动态效果用同一套requestAnimationFrame时间线驱动。具体操作CSS 动画部分从animation改成不带动画只保留初始与结束状态用 JS 在 rAF 里按时间推进设置style.transform。这样所有动效的“心跳”来自同一个时钟浏览器可以更集中地批量处理。代价是写起来麻烦一些但对于“圣诞贺卡”这种短小互动页面完全可控。let startTime null; function tick(now) { if (!startTime) startTime now; const elapsed (now - startTime) / 1000; // 根据 elapsed 计算卡片位移 card.style.transform translateY(${Math.min(50, elapsed * 20)}px); // 绘制雪花 drawSnow(elapsed); if (elapsed 3) { requestAnimationFrame(tick); } } requestAnimationFrame(tick);5.4 优化方向三控制合成层数量别给每个元素都加 will-change很多同学一听“will-change 能加速”就给页面里所有动画元素都加上。这其实是反向优化。每个will-change声明都会让浏览器多创建一个合成层合成层越多内存占用越高层与层之间的合成计算反而变慢。低端安卓机上尤其明显。我的经验是整页合成层数量控制在 5 层以内只有频繁变化的容器如 canvas、轮播图、抽屉才加will-change普通淡入淡出元素不加也能流畅运行。因为单纯改opacity本身就已经是合成器友好的属性不需要额外声明。这道题的核心价值在于它纠正了一个常见的错误认知——以为动画卡顿一定是因为 JS 逻辑太多却忽略了合成层竞争和绘制面积的影响。排查步骤应该是打开 DevTools 的 Rendering 面板开启Layer borders观察页面分层情况。开启Paint flashing看哪些区域在不停重绘。把所有重绘区域尽量合并到同一个合成层减少绘制面积。再考虑用 rAF 统一时间线。6. 第五道实测题语义化标签组合的“合法错误”题目以下 HTML5 页面结构用 W3C 验证器会报错吗如果不报错但文档大纲document outline有严重问题请指出并给出修改后的版本。body header nav首页 | 关于 | 联系/nav /header main article section内容一/section section内容二/section /article aside侧边栏/aside /main footer© 2025 测试页/footer /body这道题的陷阱在于标签都用对了但语义层级完全乱了。header里直接放navsection内没有标题article里的内容没有标题层级这些都不会引发验证器报错但对“HTML5 网页设计”的读者来说恰恰是很容易忽略的点。6.1 为什么 section 一定要有标题按 HTML5 规范section表示文档中的一个独立区域这个区域“通常会有标题”。虽然浏览器不会强制报错但屏幕阅读器会依据标题层级来生成文档大纲。没有标题的section在无障碍树里是一团没有标识的区块读屏用户根本不知道这个区域讲的是什么。aside在main里面也不是不行但要区分它描述的是谁。如果aside内容与article直接相关它可以放在article内部如果是整站通用的推荐链接应该放在main之外。上面代码里aside放在main内部语义上更像是“这篇文章的附属信息”但如果它其实是全站侧边栏这就是语义错误。6.2 修正后的结构body header nav aria-label主导航 a href/首页/a a href/about关于/a a href/contact联系/a /nav /header main article h1文章标题/h1 p导语段落/p section aria-labelledbysec1 h2 idsec1内容一小节/h2 p正文.../p /section section aria-labelledbysec2 h2 idsec2内容二小节/h2 p正文.../p /section aside aria-label文章相关链接 p相关阅读/p /aside /article /main footer© 2025 测试页/footer /body改动要点有三个每个section加一个h2标题并用aria-labelledby与标题关联增强无障碍识别。如果aside是文章相关链接放进article如果是全站侧边栏移出main。nav里加aria-label区分“主导航”和页脚的“次导航”防止读屏软件混淆。6.3 语义化为什么影响渲染性能与 SEO很多人觉得语义化只是“写给别人看的规范”其实它还有实际收益。搜索引擎抓取页面时会优先识别main、article、h1等标签内的内容作为核心内容。如果你整个页面全是div即便视觉上没问题搜索引擎也很难把文章的正文和导航栏区分开可能导致关键词权重降低。另外屏幕阅读器在main标签处可以自动跳过重复的导航栏直接进入正文这是对残障用户的直接支撑。实际项目中做 B 端后台管理系统的时候不用太纠结语义化——内容少、交互密度高div虽然朴素但效率高但做 C 端官网、博客、营销活动页时语义化是必须的因为内容质量和 SEO 都与之直接相关。这套“quiz 四”的定位本质上就是帮你界定清楚什么场景吃什么规范。7. 补测题三道快问快答测你有没有隐藏盲区除了上面五道大题我在最后加三道 30 秒快问快答都是实际项目里会碰到的“小判断”。7.1sessionStorage和localStorage能否跨标签页共享先说结论localStorage可以在同源的所有标签页共享sessionStorage不行它只存在于当前标签页。但有个极易忽略的坑如果用户用“复制标签页”的方式打开新页部分浏览器比如 Chrome会复制一份sessionStorage而用地址栏新开标签页则拿不到原标签页的sessionStorage。所以涉及登录态、支付流程里如果用sessionStorage做临时状态传递一定要考虑“用户从新标签打开”的场景这时候会直接丢失数据跳到支付成功页却没有订单号的尴尬场面我见过不止一次。7.2 表单里required与pattern同时存在时的校验顺序浏览器先校验required是否为空再校验pattern是否符合格式。这个顺序的意义在于排错如果你在控制台里看不到校验失败提示先检查是不是第一个条件就挂了。另外pattern里的正则默认是锚定整段匹配的不像 JS 原生regex.test是部分匹配——写pattern[0-9]{4}时输入12345是不会通过的因为它要求整串匹配 4 位数字。想允许更多位数写成pattern[0-9]{4,}才有用。7.3Canvas和SVG在动画场景下的选择边界这个问题老生常谈但每次都能考住人。一句话总结元素数量少几十到几百、单帧状态简单、需要事件绑定和缩放不失真选 SVG元素数量大上千、每帧都有坐标动态变化、需要像素级特效烟花、粒子、拖尾选 Canvas。圣诞贺卡里的雪花如果只有 30 片用 SVG 就够而且还省去了 Canvas 的清晰度和适配问题如果是上千片暴风雪Canvas 才是合适的选择。判断标准不是“哪个更高级”而是“数据量和交互复杂度处在哪个量级”。这三道补测题虽然短背后对应的却是实际开发里的高频困惑。我把它们放进这套测验是因为很多人做完前五题会觉得自己已经 “精通”HTML5 了但这三道题会提醒你——还早坑还多着呢。8. 阅卷心得从这套题反推出来的 HTML5 学习路径既然这套题叫“测验四”前面肯定还有几套但这个系列做到这里我更想谈的是透过这些题总结出来的一个学习方法要把 HTML5 当“工程科目”而不是“语法科目”来学。8.1 会写 demo 不等于能上线很多同学学 HTML5停留在“照着文档写一个 canvas 动画 demo”“用 video 标签播一段视频”的层面。但真正上线一个 HTML5 页面你需要回答这些文档里没写的细节视频编码格式怎么选要不要准备多份转码。移动端适配究竟用 rem 还是 vw适配基准怎么确定。canvas 动画在低端机上掉帧了是先优化绘制还是先优化内存。页面卡顿的时候如何快速定位是主线程占用还是合成层过多。这些问题的答案往往不在任何一本 HTML5 语法书里而要在真实项目中查资料、看 Performance 面板、逐帧分析才能积累。这套测验设计的核心意图就是把这些“工程化经验”以题目的形式暴露出来。8.2 建议的 HTML5 进阶路径如果你测完这套题发现自己一部分答不上来不用慌。按下面的路径重新整理知识第一阶段标签与基础 API把video、audio、canvas、svg、localStorage、sessionStorage、requestAnimationFrame、FormData这些基础 API 全部过一遍至少清楚每个 API 的边界和典型使用场景。这个阶段以“看文档 写最小 demo”为主。第二阶段浏览器的渲染差异主动去查你写的每个 API 在 Chrome、Safari、Firefox、以及不同版本 iOS/Android 上的兼容性。推荐用 caniuse.com 对照同时本地装一台 iOS 模拟器或真机测试环境。只有亲自看到“同一个页面在不同浏览器里的表现”才能在后续项目里形成直觉。第三阶段性能优化学会用 DevTools 的 Performance、Rendering、Layer 面板以及 Lighthouse。当你写的页面出现卡顿时能自己说出“是绘制面积太大还是合成层太多还是主线程 JS 耗时过长”。这个阶段的标志性能力是你能在 5 分钟内定位一处掉帧问题的根因。第四阶段工程化整合把 HTML5 能力放进实际项目中前端基础HTMLCSSJS之上接上工程化工具打包、转译、代码分割。你需要知道哪些 HTML5 特性可以用在哪些实际业务场景中哪些不适用。这一点对做中大型项目尤其重要。8.3 对照自查表你处于哪个阶段阶段能力表现建议练习L1能写 video/canvas 基础 demo但不知道浏览器差异把前两道题的多源视频和粒子生命周期手动改到正确L2知道移动端要加 viewport会调 canvas 高清适配做一版兼容 iPhone 和安卓的完整页面L3能处理页面卡顿会看 Performance 和 Layer 面板做一个超过 1000 粒子的动画并优化到 60fpsL4能根据业务场景选型svg 还是 canvas、原生视频还是播放器库用 HTML5 做一个完整的小型产品原型这套“测验四”不是终点而是帮你定位自己现在处在哪一档。我当年从 L1 升到 L2 用的土办法很笨每次遇到一个页面问题就新开一个空白测试页用最简代码复现然后在浏览器控制台逐行验证最后把结论写进自己的笔记。这个过程虽然慢但积累下来的“可复现案例”比任何教程都有说服力。你现在做这门测验本质上也是在做同样的事。