简介十一国庆节祝福网页是一份面向Web开发初学者和节日互动页面制作爱好者的轻量源码包可用于快速搭建国庆主题送祝福页面。用户只需在文本框中填写送祝福人与自己的名字点击提交后即可自动复制专属地址并转发给亲友适合节日问候、课堂练习和HTML/CSS入门实践。压缩包共9个文件约152KB包含5个JPG和2个GIF图像素材用于页面配图与动效装饰另有1个HTM页面文件和1个DB数据文件分别承载页面结构与提交数据记录。目前已有2276人学习下载说明其具备一定参考价值。读者可从中了解表单输入、页面排版、图片素材调用及简单提交处理的组织方式并基于现有页面替换文案、图片和样式快速改造成个性化祝福页。1. 一份国庆祝福网页源码先别急着套模板它到底解决什么问题拿到一份节日主题的 Web 开发源代码多数人的第一动作是把标题一改、背景一换、直接丢服务器。真上线才发现手机端横向能拖动、低端安卓一进页面就发烫、烟花动画在微信里黑屏。这套 HTML CSS 源代码包解决的其实不是「做个好看的页面」而是把节日氛围动效拆成可控制的层让它在三年前的千元机和最新的旗舰机上都不至于失控。它适合三类人需要一天内交付一个节日专题页的前端、要给公众号或活动落地页做视觉包装的运营开发、以及想拿一份完整静态页练手 CSS 动效与 Canvas 粒子的新手。我把包拆开跑了一遍下面按文件结构、动效层、粒子层、坑位逐段说。2. 拆开压缩包看骨架index.html 的语义结构与四个资源入口静态祝福页最容易出问题的地方不在视觉在结构。结构定错了后面每一层动效都在跟文档流打架。这份包的骨架相对克制没有把整页塞进一个巨大的 div也没有用绝对定位把所有元素钉死这一点值得保留。2.1 目录结构与文件依赖关系解压后第一件事不是打开 index.html 看效果而是先看依赖关系。节日页的加载顺序错了会出现「动画先跑、背景后到」的观感断层。常见做法是按下面这种结构组织把首屏必须的资源和其他资源分开festival-page/ ├── index.html # 唯一入口首屏所有内容都在这一个文件里 ├── css/ │ ├── base.css # reset、字体、CSS 变量、主题色 │ ├── layout.css # 三层舞台、容器尺寸、响应式断点 │ └── animate.css # 关键帧与动画类全部只碰 transform/opacity ├── js/ │ ├── fireworks.js # Canvas 粒子主逻辑 │ └── main.js # 初始化、事件绑定、可见性暂停 ├── assets/ │ ├── img/ # 背景、飘带、纹理优先 webp │ └── font/ # 可选非必须不要引外部字体 └── favicon.ico这张清单里最关键的一条是animate.css单独拆出来。节日页的动效经常被反复调时长和节奏和布局代码混在一个文件里改一次动画就要重新读一遍布局血泪经验。另外assets/font/标了可选——外部字体是首屏白屏的头号嫌疑能用系统字体栈顶住就别引。依赖关系上base.css必须在layout.css之前因为主题色变量定义在 base 里layout 里会引用animate.css放最后方便用层叠优先级覆盖个别元素的动画。JS 全部用defer引入不要阻塞首屏渲染link relstylesheet hrefcss/base.css link relstylesheet hrefcss/layout.css link relstylesheet hrefcss/animate.css script srcjs/fireworks.js defer/script script srcjs/main.js defer/scriptdefer保证脚本在 DOM 解析完成后按顺序执行fireworks.js先于main.js后者才能拿到前者暴露的初始化函数。如果改成async两个文件的执行顺序就不确定了初始化时拿到undefined是经典翻车点。2.2 语义化骨架从 header 到 canvas 的挂载顺序骨架的核心是「三层舞台 一个画布」。三层分别是背景层静态图或渐变、中景层飘带、光晕、前景层祝福文案与按钮Canvas 挂在背景层和中景层之间这样烟花在后面炸、文案在前面压得住。!DOCTYPE html html langzh-CN head meta charsetUTF-8 !-- 关键viewport 不加 user-scalableno会被无障碍审计直接判不合格 -- meta nameviewport contentwidthdevice-width, initial-scale1, viewport-fitcover meta nametheme-color content#c8102e meta namedescription content节日祝福主题静态页 title节日祝福/title /head body !-- 舞台容器所有绝对定位元素的定位基准 -- main classstage !-- 第一层静态背景纯 CSS 渐变不依赖图片 -- div classlayer layer-bg aria-hiddentrue/div !-- 第二层Canvas烟花画在这里 -- canvas idfx classlayer layer-fx aria-hiddentrue/canvas !-- 第三层中景装饰飘带与光晕纯装饰给 aria-hidden -- div classlayer layer-mid aria-hiddentrue span classribbon ribbon-1/span span classribbon ribbon-2/span span classglow/span /div !-- 第四层文案唯一需要被读屏软件读到的内容 -- section classlayer layer-content h1 classtitle节日快乐/h1 p classsubtitle愿你今年顺遂所愿皆成/p button classbtn-fire typebutton点亮烟花/button /section /main /body /html这段骨架有三个设计决定值得说清楚。第一装饰性元素全部加aria-hiddentrue读屏软件只会读到标题、副标题和按钮不然一进页面就是十几条无意义的「图片」播报。第二viewport-fitcover是为刘海屏准备的配合 CSS 里的env(safe-area-inset-*)用不加这一条全屏页在异形屏上文案会被裁掉一截。第三按钮用原生button typebutton而不是 div键盘 Tab 能聚焦、回车能触发成本几乎为零收益是整页可访问性达标。挂载顺序也有讲究Canvas 必须在.layer-mid之前、.layer-bg之后。DOM 顺序决定默认层叠顺序后面的元素压在前面的上面这样烟花不会盖住飘带和文案视觉上才有纵深。如果嫌 DOM 顺序不好调用z-index显式指定也行但别两套混着用容易在某个浏览器里表现不一致。2.3 meta 与资源加载参数怎么配静态页的性能预算基本在 head 里就决定了一半。下面这张表是我在几个节日专题页上反复调过之后留下来的配置按需取用配置项推荐值作用与边界viewportwidthdevice-width, initial-scale1, viewport-fitcover禁止写maximum-scale1会挡住用户缩放theme-color主题主色如#c8102e移动端浏览器地址栏染色只影响观感preload背景图link relpreload asimage href...只对首屏大图用超过 200KB 建议先压缩font-displayswap若必须引外部字体用 swap 避免文字长时间不可见图片格式webp 优先png 兜底背景图是首屏最大体积项压缩收益最高首屏 JS全部defer总体积控制在 30KB 内粒子逻辑不复杂超了说明写了冗余代码theme-color这条经常被忽略但它对「节日感」的贡献比想象中大移动端浏览器顶部那条色带和页面主色一致整页的完整度立刻不一样。注意theme-color只认一个颜色值不支持渐变别写linear-gradient()写了也不生效。如果背景图确实大除了preload还有一招在.layer-bg上先铺一层同色系的纯色或径向渐变图片加载完再淡入覆盖。用户看到的是「颜色先到、细节后到」比整块白屏强得多。这套做法不需要 JS纯 CSS 就能完成.layer-bg { background-color: #7a0d18; /* 兜底底色和主图色调接近 */ background-image: radial-gradient(circle at 50% 30%, #c8102e 0%, #7a0d18 70%); background-size: cover; background-position: center; opacity: 1; transition: opacity .6s ease; } /* 主图加载完成后由 JS 加 loaded 类叠一层真实背景 */ .layer-bg.loaded { background-image: url(../assets/img/bg.webp), radial-gradient(circle at 50% 30%, #c8102e 0%, #7a0d18 70%); }transition: opacity .6s在这里是给后续可能加的淡入淡出留的口子本身不触发重排。background-position: center保证不同宽高比下裁切位置一致比top稳妥因为节日页的视觉重心通常在中上部裁底部不会伤到主体。3. CSS 动效层怎么排飘带、光晕与三层合成的参数表CSS 动效是这类页面观感的主要来源也是性能问题的主要来源。同样的飘带用left做位移和用transform: translateX()做位移在千元机上的帧率能差一倍。3.1 三层结构先把 z-index 和定位定死动手写动画之前先把层级和定位方式一次性定死后面所有元素都往这个框架里塞。我一般用下面这套.stage { position: relative; width: 100%; min-height: 100vh; min-height: 100svh; /* 小视口单位规避移动端地址栏高度抖动 */ overflow: hidden; /* 关键把飘带的溢出裁掉防止横向滚动条 */ } .layer { position: absolute; inset: 0; /* 等价于 top/right/bottom/left 全 0 */ } .layer-bg { z-index: 0; } .layer-fx { z-index: 1; pointer-events: none; } /* 画布不拦截点击 */ .layer-mid { z-index: 2; pointer-events: none; } .layer-content { z-index: 3; display: flex; flex-direction: column; align-items: center; justify-content: center; gap: 1.2rem; padding: 0 1.5rem; text-align: center; }四个参数点值得单独说。overflow: hidden放在.stage上而不是body上因为body上加overflow: hidden在部分移动端浏览器里会连带把整个页面的滚动锁死节日页如果下面还有内容就滚不动了。pointer-events: none给layer-fx和layer-mid是为了让点击穿透到按钮上——画布全屏铺开不给这个属性按钮永远点不到这是新手最常踩的一个坑。min-height: 100svh是100vh的替代移动端地址栏收缩展开时vh不变会导致页面顶部被裁或者底部留白svh取小值稳。最后inset: 0比写四个方向属性短兼容性现在没问题但如果你要支持很老的浏览器还是老实写四个属性。3.2 关键帧只碰 transform 和 opacity这条原则说起来简单做起来要克制。节日页里飘带要飘、光晕要呼吸、标题要轻微浮动全部只用transform和opacity两把刀/* 飘带水平往复 轻微旋转全程不碰 left/top */ keyframes ribbon-drift { 0% { transform: translate3d(-10%, 0, 0) rotate(-6deg); } 50% { transform: translate3d(10%, -2%, 0) rotate(4deg); } 100% { transform: translate3d(-10%, 0, 0) rotate(-6deg); } } .ribbon { position: absolute; width: 60vw; height: 60vh; background: linear-gradient(135deg, rgba(255, 214, 120, .35), rgba(200, 16, 46, 0)); filter: blur(28px); /* 模糊只在静态时算一次 */ border-radius: 45% 55% 60% 40%; will-change: transform; /* 提前提升合成层 */ animation: ribbon-drift 18s ease-in-out infinite; } .ribbon-1 { top: -10%; left: -15%; animation-duration: 22s; } .ribbon-2 { bottom: -15%; right: -20%; animation-duration: 26s; animation-delay: -6s; } /* 光晕呼吸只改 opacity不缩放避免边缘模糊抖动 */ keyframes glow-breathe { 0%, 100% { opacity: .35; } 50% { opacity: .75; } } .glow { position: absolute; inset: 20% 10%; background: radial-gradient(circle, rgba(255, 220, 150, .8), transparent 65%); animation: glow-breathe 6s ease-in-out infinite; }translate3d而不是translateX是为了显式触发 GPU 合成代价很小但收益稳定。filter: blur(28px)写在不参与动画的属性里浏览器会把元素先模糊再合成模糊本身只算一次如果你把filter的数值写进关键帧每一帧都要重新算模糊千元机直接跪。animation-delay: -6s是负值作用是让第二条飘带从动画中途开始两条飘带不会同步摆动省掉一个随机化的 JS。will-change: transform要克制用。它会让浏览器提前创建合成层层多了内存吃紧低端机上反而掉帧。我的经验是只给「持续动画 面积超过视口 30%」的元素加其他元素交给浏览器自己判断。动画结束后如果元素不再动用 JS 把will-change删掉别一直挂着。3.3 动画参数表与时长节奏节奏感靠参数表管不靠手感。同一页里所有动画的时长最好落在同一个数量级上否则看起来各动各的。我常用的配置如下元素属性时长缓动延迟说明飘带 1transform22sease-in-out0大面积慢速撑住氛围飘带 2transform26sease-in-out-6s与飘带 1 错开相位光晕opacity6sease-in-out0呼吸感不要低于 4s标题transform3.2scubic-bezier(.4,0,.2,1)0轻微上下浮动幅度 ≤ 6px按钮transform2.4sease-in-out0缩放 1 到 1.04幅度再大就廉价文案入场opacity transform.8scubic-bezier(.2,.8,.2,1).2s一次性不循环表里最容易被忽略的是「幅度」。标题浮动超过 6px、按钮缩放超过 1.05观感立刻从「精致」变成「页游」。慢速大面积的动画飘带、光晕负责氛围快速小幅度的动画按钮负责反馈两类动画的时长至少差一个数量级这是节奏感的来源。另外页面上的循环动画总数建议控制在 6 个以内。超过这个数低端机的合成线程压力明显上来而且视觉上会显得乱。如果确实需要更多装饰用静态图代替动画元素成本几乎为零。3.4 低端设备与减弱动效的降级路径有两个降级必须做。第一个是系统级的「减弱动态效果」用户在系统设置里开了这个开关页面就不该继续播放循环动画media (prefers-reduced-motion: reduce) { *, *::before, *::after { animation-duration: .01ms !important; animation-iteration-count: 1 !important; transition-duration: .01ms !important; scroll-behavior: auto !important; } /* 保留静态视觉只停掉运动 */ .layer-mid { display: none; } #fx { display: none; } /* 画布直接隐藏省掉粒子开销 */ }这里用!important是合理的降级优先级最高压过所有具体规则。注意画布是直接display: none不是暂停——暂停了 rAF 还在跑白烧电。JS 侧也要配合读一次matchMedia((prefers-reduced-motion: reduce)).matches为真就不初始化粒子系统双重保险。第二个降级是设备能力。低端机的判定不用太精细用navigator.hardwareConcurrency和deviceMemory粗略估一下就够// 设备能力粗判核心数少或内存小直接降低粒子预算 function getParticleBudget() { const cores navigator.hardwareConcurrency || 4; const mem navigator.deviceMemory || 4; // 单位 GB部分浏览器不支持 if (cores 4 || mem 2) return 40; // 低端少量粒子 if (cores 6) return 90; // 中端 return 150; // 高端 }hardwareConcurrency在部分浏览器里会返回固定的假值deviceMemory支持面更窄所以这段只能当参考真正的兜底还是靠帧率监测跑起来之后统计每帧耗时连续 30 帧超过 22ms 就自动把粒子预算砍半。这个自适应逻辑比任何静态判定都可靠后面第 4 章会写具体实现。4. Canvas 烟花粒子DPR 适配、对象池与 rAF 帧控烟花是这类页面的视觉重心也是最容易写成性能黑洞的地方。见过太多实现是每次点击new一堆粒子对象、每帧创建数组、每帧ctx.clearRect之外还加shadowBlur——单看代码没毛病跑在千元机上就是灾难。4.1 画布尺寸与设备像素比的一次性校准Canvas 的尺寸有两个概念CSS 尺寸元素占多大和位图尺寸画多少像素。不处理 DPR高分屏上线条糊成一团处理错了位图尺寸爆炸内存直接翻四倍。const canvas document.getElementById(fx); const ctx canvas.getContext(2d, { alpha: true }); let W 0, H 0, DPR 1; function resizeCanvas() { // clientWidth 是 CSS 像素乘 DPR 得到物理像素 DPR Math.min(window.devicePixelRatio || 1, 2); // 上限 23x 屏收益极低 W canvas.clientWidth; H canvas.clientHeight; canvas.width Math.round(W * DPR); canvas.height Math.round(H * DPR); // 用 setTransform 而不是 scale避免多次 resize 后变换叠加 ctx.setTransform(DPR, 0, 0, DPR, 0, 0); } // 首次校准 尺寸变化时重算 resizeCanvas(); window.addEventListener(resize, debounce(resizeCanvas, 200));三个细节决定了这段代码能不能长期稳定。第一DPR上限锁 23x 屏上画布像素数比 2x 多一倍多肉眼几乎看不出差别但内存和填充率压力实实在在这是性价比最高的一个截断。第二用setTransform而不是ctx.scale(DPR, DPR)因为scale是叠加的屏幕旋转几次之后变换矩阵会累乘画面越缩越小。第三resize必须防抖移动端地址栏收缩会连续触发 resize不防抖就是连续重设位图卡顿的元凶。还有一个隐性问题canvas.clientWidth在元素还没布局完成时是 0这时候设canvas.width 0后面所有绘制都是空操作表现就是「画布一片空白」。所以resizeCanvas()的调用时机必须在 DOM 就绪之后defer脚本天然满足如果画布所在的容器是动态显示的还得用ResizeObserver监听容器尺寸别指望window.resize。4.2 粒子对象与对象池复用一次烟花爆炸产生 60 到 120 个粒子用户连点五下就是几百个对象。如果每次new Particle()垃圾回收会在最容易掉帧的时候触发。常用做法是对象池预分配固定数量的粒子用完归还永不新建。// 对象池预分配状态复用避免运行期 GC const POOL_SIZE 600; const pool []; for (let i 0; i POOL_SIZE; i) { pool.push({ alive: false, x: 0, y: 0, vx: 0, vy: 0, life: 0, maxLife: 0, hue: 0, size: 0 }); } function spawn(x, y, count) { let created 0; for (let i 0; i pool.length created count; i) { const p pool[i]; if (p.alive) continue; // 跳过在用的 const angle Math.random() * Math.PI * 2; const speed 1.8 Math.random() * 4.2; // 速度区间决定爆炸半径 p.alive true; p.x x; p.y y; p.vx Math.cos(angle) * speed; p.vy Math.sin(angle) * speed; p.maxLife 45 Math.random() * 35; // 单位帧 p.life p.maxLife; p.hue 20 Math.random() * 30; // 暖金到橙红的色相区间 p.size 1 Math.random() * 2; created; } return created; // 返回实际生成数池满时可用于降级判断 }speed区间1.8 ~ 6.0是调出来的低于 1.8 爆炸半径太小像一团糊高于 6 粒子飞出画面浪费。maxLife用帧数而不是毫秒配合固定步长积分更简单如果你后面改成时间驱动记得把这几个值换算一下。hue限制在暖色区间冷色系混进去会破坏节日氛围这个属于美术决定改之前先看一眼整体色调。speed和maxLife的乘积决定视觉半径调参时这两个要一起动。半径 速度 × 生命周期 × 阻尼衰减系数vy每帧加一点重力实际轨迹是抛物线比直线更耐看function update(dt) { for (let i 0; i pool.length; i) { const p pool[i]; if (!p.alive) continue; p.vy 0.06; // 重力加速度数值越大下落越快 p.vx * 0.985; // 空气阻力越接近 1 滑行越远 p.vy * 0.985; p.x p.vx; p.y p.vy; p.life - 1; if (p.life 0 || p.y H 40) p.alive false; // 归池 } }阻尼系数0.985每帧乘一次60fps 下跑一秒衰减到约 0.4视觉上是「先快后慢」的自然减速。p.y H 40这个兜底判断不能省粒子飞出视口下方后如果还活着会一直在池里占坑点几次按钮池就满了。4.3 主循环dt 驱动与帧率上限requestAnimationFrame的调用频率跟着屏幕刷新率走120Hz 屏上动画速度是 60Hz 的两倍。所以主循环必须按时间差推进不能按帧数硬编码。let last 0; let running false; const FRAME 1000 / 60; // 目标 60fps120Hz 屏上做节流 function loop(now) { if (!running) return; const elapsed now - last; if (elapsed FRAME - 1) { // 不足一帧跳过绘制 requestAnimationFrame(loop); return; } last now; // dt 归一化到 60fps 的倍数update 内部仍可按「帧」写 const dt Math.min(elapsed / FRAME, 2); // 上限 2防止切回标签页时瞬移 ctx.clearRect(0, 0, W, H); update(dt); draw(); requestAnimationFrame(loop); }Math.min(elapsed / FRAME, 2)这一行是黑匣子级别的细节。用户切到别的标签页再切回来elapsed可能是几万毫秒不截断的话所有粒子一帧内飞出天际画面直接崩。截断成 2 倍帧最多是「快进一点点」可以接受。页面不可见时要主动停掉循环这是省电的关键document.addEventListener(visibilitychange, () { if (document.hidden) { running false; // 停止调度 } else { running true; last performance.now(); // 重置时间基准避免首帧 dt 巨大 requestAnimationFrame(loop); } });注意重新启动时一定要重置last否则第一帧的elapsed不可控。这个last的重置我在早期的版本里漏过一次表现是「切回页面后烟花瞬移一下」很难复现查了很久。4.4 点击与触摸的触发点换算画布有 DPR 缩放坐标换算必须用getBoundingClientRect而不是offsetX/offsetY后者在不同浏览器里对滚动和变换的处理不一致。function handleFire(clientX, clientY) { const rect canvas.getBoundingClientRect(); // 转成 CSS 像素坐标与 ctx 的 setTransform 对应 const x clientX - rect.left; const y clientY - rect.top; if (x 0 || x W || y 0 || y H) return; // 边界外丢弃 spawn(x, y, getParticleBudget()); } // 指针事件统一处理鼠标、触摸、手写笔 canvas.addEventListener(pointerdown, (e) { handleFire(e.clientX, e.clientY); }); // 按钮点击在页面上方随机位置爆一朵 document.querySelector(.btn-fire)?.addEventListener(click, () { handleFire(W * (0.25 Math.random() * 0.5), H * (0.2 Math.random() * 0.3)); });pointerdown一个事件覆盖三种输入设备比同时绑mousedown和touchstart干净得多也避免了触摸设备上「先触发 touch 再触发 mouse」的双重触发。坐标用clientX/Y减去rect.left/top得到的是相对画布的 CSS 像素坐标和setTransform(DPR, ...)后的逻辑坐标系一致不需要再乘 DPR。按钮触发的位置限制在画面中上部0.2 ~ 0.5的纵向区间是因为烟花往下落的时候需要有空间展示弹道贴着顶部炸开粒子一半飞出画面观感大打折扣。横向0.25 ~ 0.75是避开左右两侧的安全边距。5. 排查与避坑节日页上线前最容易翻车的五个地方下面这五条全是我在不同项目里真实踩过的按出现频率排序。每条都按「现象、原因、解决」写遇到同类问题直接对号入座。5.1 移动端出现横向滚动条怎么拖都能往右移一屏现象桌面端正常手机上整页可以左右拖动右侧露出一条空白。原因飘带元素用了left: -15%和width: 60vw超出了视口宽度.stage上没有裁切。很多人第一反应是给body加overflow-x: hidden这在 iOS Safari 上有时不生效因为body的滚动容器是html而且加了之后可能连带锁死纵向滚动。解决把裁切放在舞台容器上overflow: hidden写在.stage里同时确认.stage有position: relative。如果页面下方还有内容需要滚动舞台容器必须限制高度用min-height: 100svh而不是height: 100%把滚动交给外层容器。另外60vw这类视口单位在页面出现纵向滚动条时会比可视宽度大一点点桌面端也可能触发横向滚动稳妥写法是width: 60%配合父容器的百分比宽。5.2 低端安卓一进页面就发烫动画还一顿一顿现象iPhone 上丝滑两三千的安卓机上帧率掉到 20 出头手机背面明显发热。原因八成是动画属性没选对。检查关键帧里有没有box-shadow、filter、width/height、top/left参与动画。box-shadow的每一帧都要重新计算阴影模糊代价极高filter: blur()写在关键帧里同理。另一个常见原因是will-change加得太滥几十个元素全部提升合成层GPU 内存吃满后反而更慢。解决动画属性收敛到transform和opacity两个。确实需要模糊的把filter写在静态样式里让浏览器只算一次。will-change只给面积大、持续动画的元素加并且用 JS 在动画结束后移除。改完再用 Chrome DevTools 的 Performance 面板录一段看有没有长任务和强制同步布局通常能定位到具体是哪个元素。5.3 画布在部分内置浏览器里一片空白现象外部浏览器正常从聊天软件里点开链接画布区域全黑或者透明什么都不显示。原因canvas.clientWidth在初始化时读到 0。这类内置浏览器对defer脚本的执行时机、以及首屏布局完成的时间判断和标准浏览器有差异另外画布容器如果被设了display: none或者父级高度为 0clientWidth一样是 0。解决初始化前加一道尺寸校验读到 0 就延迟重试同时用ResizeObserver兜底function initCanvas(retry 0) { const w canvas.clientWidth; const h canvas.clientHeight; if ((w 0 || h 0) retry 10) { // 布局未完成下一帧重试最多 10 次 requestAnimationFrame(() initCanvas(retry 1)); return; } resizeCanvas(); running true; requestAnimationFrame(loop); } initCanvas();重试上限设 10 次约 160ms超过就放弃初始化让页面退化成一个没有烟花的静态页而不是卡在循环里。同时给.layer-fx一个兜底背景色或者静态图画布失效时视觉上不至于开天窗。5.4 首屏白屏一两秒背景图最后才跳出来现象弱网下打开先是白屏然后文字突然出现最后背景图才补上观感割裂。原因背景图没压缩、没预加载而且被 CSS 的background-image引用——浏览器要等 CSS 解析完才开始下载天然晚一步。图片如果是几 MB 的 PNG弱网下就是几秒。解决三步。第一步压缩背景图转 webp控制在 150KB 以内必要时降分辨率再用 CSS 拉伸。第二步给.layer-bg铺兜底渐变让颜色先到。第三步对首屏大图加preloadlink relpreload asimage hrefassets/img/bg.webp typeimage/webp不要在head里预加载超过两张图会挤占关键 CSS 和 JS 的带宽反而更慢。5.5 切走标签页再切回来烟花位置乱跳或者直接消失现象页面在后台放一会儿切回来瞬间粒子全部消失或者集中在角落。原因requestAnimationFrame在后台标签页会被节流甚至暂停但visibilitychange里没做处理切回来时elapsed是一个巨大的值update里一帧把所有粒子推出边界全部归池。解决如第 4 章写的visibilitychange时停掉循环、重置last并且dt做上限截断。另外粒子归池条件里加p.y H 40这种边界判断本身也是一种容错即使逻辑出错也不会出现「粒子永远活着占坑」的情况。这一条我建议直接在代码里写死不要指望用户不去切标签页。6. 上线前的自检与一个换肤技巧把主题色收进 CSS 变量最后说一个我每次交付节日页都会做的事把所有颜色收进:root的 CSS 变量页面里任何地方都不写死色值。:root { --c-primary: #c8102e; /* 主色按钮、主题色 */ --c-accent: #ffd678; /* 点缀色飘带、光晕 */ --c-deep: #7a0d18; /* 深色底背景兜底 */ --c-text: #fff8ec; /* 正文色 */ --glow-size: 28px; /* 光晕模糊半径 */ --ribbon-dur: 22s; /* 飘带时长 */ } .btn-fire { background: var(--c-primary); color: var(--c-text); box-shadow: 0 0 var(--glow-size) rgba(255, 214, 120, .45); } /* 换肤只改根节点变量整页跟着变 */ body.theme-warm { --c-primary: #b8500f; --c-accent: #ffcf8a; --c-deep: #5c2a08; }这套写法的价值不在「能换主题」在于改一版配色只需要动四行。节日专题页最常见的需求就是「今年换个色调」客户临时改主色五分钟能出第二版不至于翻遍 CSS 找#c8102e。参数化还有个副作用好处动效时长也做成变量之后调节奏变成改一个数比翻关键帧快得多。上线前的自检我固定跑一遍手机上真机打开看有没有横向滚动、点击按钮能不能触发、切到后台再切回来画面是否正常、关掉动画系统减弱动态效果后页面是否还有内容、断网状态下首屏是否至少有色块和文案。这五项过了剩下的都是锦上添花。有个教训我记了很久早期做这类页面我总觉得视觉越满越好飘带叠三层、光晕加两个、画布粒子开到三百验收时在演示机上效果拉满交付后用户反馈「打开像幻灯片」。从那以后我每次交节日页都强制先在最便宜的那台测试机上跑一遍帧率不到 45 就直接砍装饰哪怕效果图再好看。动效这东西能跑满 60 帧的七十分视觉永远胜过卡成 20 帧的一百分视觉。希望帮到你。本文还有配套的精品资源点击获取
