Canvas背景在个人网站中的轻量实现思路

个人网站加背景动效，常见做法是放一段 MP4 视频。视频文件动辄几 MB，加载慢，还会占用服务器带宽。Canvas 是另一种思路：用 JavaScript 在页面上实时绘制图形，生成粒子、波纹或网格这类数字感背景。它不产生额外网络请求，文件体积小，但代价是持续占用用户设备的 CPU 和 GPU。对 2 核 2G 的小服务器来说，Canvas 动效消耗的是浏览器性能，不是服务器资源，方向本身是对的，关键要控制绘制的开销。

先判断场景再选方案

Canvas 背景适合做氛围衬托，不适合承载信息。页面需要长时间停留、内容以文字为主、希望背景有细微动态，这类场景用 Canvas 合适。如果页面是作品集或电商落地页，用户需要快速浏览图片和按钮，背景动效反而干扰注意力，这时候静态渐变或纯色更稳妥。

另一个判断点是目标设备。个人网站的访客可能用中低端安卓手机访问，这些设备的浏览器对 Canvas 的渲染能力有限。粒子数量一多，帧率立刻下降，页面滚动会明显卡顿。所以实现前先问自己：这个动效是必须的，还是锦上添花？如果去掉它页面依然完整，就应该把默认状态设为关闭或极低强度，让用户按需开启。

轻量实现的核心是控制绘制成本

Canvas 每帧都要重新绘制，性能瓶颈主要在两方面：粒子数量和绘制频率。粒子数量直接决定每帧要计算和渲染多少个对象，绘制频率则决定每秒要执行多少次重绘。

一个可用的做法是限制粒子总数。比如全屏粒子背景，数量控制在几十到一两百之间，具体数值取决于图形复杂度和设备性能，没有固定标准。判断方法是打开浏览器开发者工具的性能面板，录制几秒动画，观察帧率是否稳定在 60 帧附近，如果掉到 30 帧以下，就减少粒子或简化图形。

绘制频率方面，不需要每帧都更新所有粒子。可以把粒子的移动速度放慢，或者用 requestAnimationFrame 配合帧率控制，只在必要的时候重绘。静止的粒子比运动的粒子省很多性能，如果背景只是轻微浮动，可以降低更新频率。

代码结构上，把 Canvas 初始化、粒子生成、绘制循环和清理逻辑封装成独立模块，方便后续维护。一个最小实现大致长这样：

```javascript
const canvas = document.getElementById('bg-canvas');
const ctx = canvas.getContext('2d');
let particles = [];
const COUNT = 60;

function resize() {
canvas.width = canvas.offsetWidth;
canvas.height = canvas.offsetHeight;
}

function createParticles() {
particles = Array.from({ length: COUNT }, () => ({
x: Math.random() * canvas.width,
y: Math.random() * canvas.height,
vx: (Math.random() - 0.5) * 0.5,
vy: (Math.random() - 0.5) * 0.5,
r: Math.random() * 2 + 1
}));
}

function draw() {
ctx.clearRect(0, 0, canvas.width, canvas.height);
for (const p of particles) {
p.x += p.vx;
p.y += p.vy;
ctx.beginPath();
ctx.arc(p.x, p.y, p.r, 0, Math.PI * 2);
ctx.fill();
}
requestAnimationFrame(draw);
}

resize();
createParticles();
draw();
```

这段代码只是骨架，实际使用时要处理几个边界情况。Canvas 的宽高需要根据容器尺寸设置，如果容器尺寸变化（比如手机旋转屏幕或浏览器窗口缩放），要重新调整画布大小，否则画面会拉伸或模糊。另外，canvas.width 和 canvas.height 设置后画布内容会清空，所以 resize 之后要重新创建粒子。

移动端和弱网环境的适配

移动端是 Canvas 背景最容易出问题的地方。手机屏幕小，但像素密度高，Canvas 的实际渲染尺寸如果等于 CSS 尺寸，在高分屏上会显得模糊；如果按设备像素比放大，又会增加渲染负担。折中做法是限制 Canvas 的最大渲染尺寸，比如不超过 2 倍设备像素比，或者干脆在移动端降低粒子数量。

另一个常见问题是页面滚动时 Canvas 仍然在持续绘制。如果背景是固定定位，滚动时不需要重绘，可以监听滚动事件暂停动画；如果背景跟随页面滚动，Canvas 内容会被浏览器自动处理，不需要额外操作。但要注意，页面切换到后台标签页时，requestAnimationFrame 会自动暂停，这正好节省了资源，不需要专门处理。

弱网环境下，Canvas 背景的优势更明显——它不需要加载外部资源。但如果页面同时还有图片、字体等其他资源，Canvas 脚本本身的加载时机也值得考虑。把初始化脚本放在 DOMContentLoaded 之后执行，避免阻塞首屏渲染。如果 Canvas 只是装饰，可以用 IntersectionObserver 监听它是否进入视口，离开视口就暂停绘制。

容易出错的地方

Canvas 背景最常见的错误是忽略清理操作。每次绘制前必须调用 clearRect 清除上一帧内容，否则粒子会拖出残影。但有时候残影是刻意追求的效果，比如用半透明填充代替完全清除，让粒子轨迹有渐变消失的感觉。这两种做法要分清，不要混淆。

另一个问题是 Canvas 元素本身的可访问性。Canvas 绘制的内容对屏幕阅读器是不可见的，如果背景中包含文字或重要信息，必须用 HTML 元素承载，不能用 Canvas 绘制。装饰性 Canvas 应该加上 aria-hidden="true"，避免读屏软件把无意义的画布内容读出来。

还有键盘操作的问题。如果页面有键盘焦点管理的需求，Canvas 本身不应该获得焦点，它的交互逻辑要放在其他可聚焦元素上。比如背景粒子跟随鼠标移动，这个效果对键盘用户没有意义，不需要为它专门做键盘替代方案，但页面主体内容的键盘导航不能被 Canvas 干扰。

检查方法

实现完成后，检查不能只在开发环境看一遍。用浏览器的设备模拟器切换到手机尺寸，观察帧率和滚动流畅度。然后打开开发者工具的性能面板，录制一段包含滚动和动画的交互，看有没有长时间的 JavaScript 执行阻塞主线程。

网络面板也要看，确认 Canvas 方案没有产生额外的资源请求。如果页面同时保留了 MP4 背景作为备选，要检查视频是否设置了 preload="none"，避免用户不点击播放时也下载视频文件。

代码的可维护性同样重要。粒子数量、移动速度、颜色这些参数应该集中放在一个配置对象里，不要散落在代码各处。后续想调整视觉效果，改配置比改逻辑快得多，也不容易引入新问题。

Canvas 背景的取舍本质上是视觉表现和页面性能之间的平衡。控制粒子数量、限制绘制频率、做好移动端适配，这三件事做到位，Canvas 就能在个人网站上以很轻的成本提供不错的视觉氛围。如果发现某个效果在低端设备上实在跑不动，果断降级成静态背景，也是合理的交付结果。