canvas滤镜本质是手动读、算、写像素，核心依赖getimagedata和putimagedata；失效主因是执行时机错误（如img.onload绑定顺序）、跨域限制、canvas宽高未设为图片实际尺寸，或遍历步长/索引/边界处理不当。
Canvas 滤镜不是“加个 class 就完事”，它本质是手动读像素、算像素、写像素——getImageData 和 putImageData 是绕不开的两个核心操作，漏掉任一环节都会白忙活。
为什么 canvas 滤镜总不生效？常见加载与同源问题
最常卡在“图像画不上”或“getImageData 报错”。根本原因不是代码写错，而是执行时机或权限不对：
-
img.onload必须绑定后再赋src，否则可能错过加载事件 - 图片必须同源（或服务端配好
Access-Control-Allow-Origin），否则getImageData会直接抛SecurityError -
canvas宽高必须显式设为与图片一致（比如canvas.width = img.naturalWidth），不能只靠 CSS 缩放，否则getImageData返回区域为空或越界 - 别在
img.onload里直接调全量处理——先用canvas.offsetWidth确认 canvas 已完成 layout，再开始像素操作
灰度/反色滤镜怎么写才不出错？通道遍历和边界细节
灰度不是简单取平均，反色也不是随便减 255。关键在步长、索引和数据类型：
- 遍历
imageData.data时，步长必须是4（R、G、B、A 各占 1 字节），i += 4，不是i++ - 灰度推荐加权公式：
gray = Math.floor(0.299 * r + 0.587 * g + 0.114 * b)，直接赋给data[i]、data[i+1]、data[i+2] - 反色只需三行：
data[i] = 255 - data[i]、data[i+1] = 255 - data[i+1]、data[i+2] = 255 - data[i+2]；data[i+3]（Alpha）保持不变，但务必确保它不为 0，否则图变透明 -
Uint8ClampedArray会自动截断，所以不用手写Math.min(Math.max(...))，但别依赖它做逻辑判断
卷积滤镜（模糊/锐化/边缘）怎么避免花屏或偏色？
卷积核运算容易崩在边界处理和归一化上，尤其当核含负数或总和 ≠ 1 时：
- 对每个像素
(x, y)，需遍历其邻域（如 3×3），计算加权和：sumR += kernel[dy][dx] * neighborR，注意neighborR来自imageData.data的对应位置 - 边界像素（如第一行、最后一列）没有完整邻域，最稳妥做法是跳过、复制边缘，或补零——别让索引越界访问
data[-1]或data[data.length] - 若卷积核总和 ≠ 1（如拉普拉斯核
[[0,1,0],[1,-4,1],[0,1,0]]总和为 0），结果需加 128 偏移并钳位，否则全黑或溢出 - 别在循环里反复调
ctx.getImageData和ctx.putImageData，它们是重操作；一次性拿、一次性写
大图卡顿怎么办？主线程阻塞的真实解法
一张 1920×1080 图片有 2073600 个像素，纯 JS 遍历在主线程耗时常超 80ms，用户能明显感知卡顿：
- 优先用
OffscreenCanvas：Chrome/Firefox 支持在 Web Worker 中创建并调用getContext('2d')，完全不阻塞 UI - 降级方案用
requestIdleCallback分块处理，例如每次只算 32 行，留出空闲时间响应滚动或输入 - 别迷信“优化 for 循环”——瓶颈从来不在语法，而在内存拷贝和渲染同步；
putImageData是同步阻塞调用，无法异步化 - 如果只是静态图，且滤镜效果固定，真没必要 runtime 计算：用 Photopea 或 Python PIL 预处理导出 PNG 更快更稳
真正难的不是写出灰度函数，而是理解 ImageData.data 是副本、putImageData 是写回、以及浏览器对跨域和 layout 的隐式约束——这些地方不踩坑，滤镜才真正“可控”。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
