可行，但需处理设备像素比、动画循环分离、清屏策略：用 devicePixelRatio 放大 canvas 内在尺寸并 CSS 缩放，ctx.scale 补偿；拆分 update/draw；用半透明 fillRect 清屏；粒子数组复用；连线加阈值剪枝。
直接在 index.html 里加 Canvas 粒子背景，不引入第三方库（如 particles.js），是完全可行的——但必须手动处理设备像素比、动画循环分离、清屏策略这三处，否则在 Retina 屏或低配设备上要么模糊，要么卡顿。
如何正确设置 canvas 尺寸并适配高清屏
浏览器默认用 CSS 像素渲染 canvas，但高 DPR 设备（如 MacBook、iPhone）会把 1px 物理像素映射成多个设备像素。若只设 canvas.width 和 canvas.height 为 window.innerWidth/window.innerHeight，画布内容会被拉伸模糊。
- 先读取
window.devicePixelRatio，再按比例放大 canvas 的内在尺寸：canvas.width = window.innerWidth * window.devicePixelRatio，同理设height - 再用 CSS 把 canvas 缩放到视口大小：
canvas { width: 100vw; height: 100vh; }，此时 CSS 尺寸不变，但绘图分辨率翻倍 - 最后别忘了在
ctx.scale()补偿缩放，否则绘制会变小：在获取 ctx 后立刻执行ctx.scale(dpr, dpr) - 监听
resize事件时，要重新计算 DPR 并重设 canvas 内在尺寸——DPR 在插拔显示器或缩放浏览器时可能变化
requestAnimationFrame 循环里不能只写 draw
常见错误是把粒子更新（位置、速度、alpha 变化）和绘制（ctx.arc、ctx.fill）混在一个函数里，尤其当粒子数超过 200 个时，JS 计算会拖慢帧率，出现肉眼可见的掉帧。
- 拆成两个函数：
updateParticles()负责纯数值运算（x += vx、边界反弹、生命周期衰减），drawParticles()只调用绘图 API - 清屏不用
ctx.clearRect(0, 0, w, h)——它强制重绘整块区域，在大画布上开销大；改用半透明覆盖法：ctx.fillStyle = 'rgba(0,0,0,0.05)'; ctx.fillRect(0, 0, w, h)，既保留残影效果又快 - 避免在循环中新建对象，粒子数组用固定长度 plain object 数组或
Float32Array存储，复用实例 - 鼠标交互逻辑（如距离计算）放在
updateParticles()中，但只在mousemove触发后缓存一次坐标，不要每帧都查event.clientX
连线逻辑怎么避免 O(n²) 性能爆炸
粒子两两判断距离并连线，算法复杂度是 O(n²)。300 个粒子就要做 9 万次距离计算，CPU 直接吃满。
立即学习“前端免费学习笔记（深入）”；
- 加距离阈值剪枝：只对
Math.abs(p1.x - p2.x) 且 <code>Math.abs(p1.y - p2.y) 的粒子对才算欧氏距离 - 更进一步，用空间划分（如二维网格桶），把画布划分为若干 cell，每个粒子只跟同 cell 及相邻 8 个 cell 内的粒子检测，复杂度降到接近 O(n)
- 连线本身别用
ctx.stroke()逐条画——改用单次ctx.beginPath()+ 多个ctx.moveTo()/ctx.lineTo()+ 一次ctx.stroke()，减少状态切换 - 线宽和透明度随距离衰减：用
ctx.lineWidth = Math.max(0.1, maxLineWidth * (1 - dist / maxDist))，避免远距离画出不可见的细线
真正难的不是让粒子动起来，而是让它们动得“不费力”：DPR 适配漏掉一帧就糊，清屏策略错一次就卡，连线不做剪枝就崩。这些细节不在炫酷效果里显形，却决定用户是觉得“网页很灵动”，还是“这个网站好卡”。
