Java 图像像素遍历为什么不能直接改 BufferedImage.getRGB() 返回的数组
因为 getRGB() 返回的是新拷贝的 int 数组，原图数据完全不受影响。你改了这个数组，等于在纸上画了个假图——屏幕上的图片纹丝不动。
正确做法是用 setRGB(x, y, rgb) 逐点写入，或更高效地用 WritableRaster 拿到原始像素缓冲区再批量操作。
- 小图（setRGB() 最简单，代码直白不易出错
- 大图务必切块处理，避免单次
getRGB(0,0,w,h)触发整图内存拷贝，OOM 风险陡增 -
getRGB()默认返回 ARGB 顺序，但很多马赛克逻辑只关心 RGB，记得用(rgb & 0xFFFFFF)屏蔽 alpha 通道，否则平均值会偏灰
邻域平均马赛克的核心：如何定义“一块”并安全取均值
马赛克不是模糊，关键在「区域对齐」和「边界截断」。随便从 (x,y) 开始取 8×8 块，遇到图像边缘就会越界报 ArrayIndexOutOfBoundsException。
推荐用「左上角锚点 + 固定块尺寸」方式：对每个块起始坐标 blockX = i * blockSize，blockY = j * blockSize，然后计算该块实际宽高（考虑右/下边界）。
立即学习“Java免费学习笔记（深入）”；
将后端 Java 接口文档转换为前端 TypeScript 类型定义（interface / type）。输入：飞书文档、Spring Boot 接口文档、Swagger/OpenAPI、手写 API 文档等。输出：包含请求参数与响应结果的 .md 文件，含完整 JSDoc 注释。触发关键词：Java 转 TS、接口转换、生成前端类型、接口文档转 TypeScript、DTO/VO/BO 转 interface、后端文档转前端类型、生成接口类型、类型定义生成。
- 块尺寸建议设为 2 的幂（如 4/8/16），方便后续做缩放或硬件加速时对齐
- 均值计算别用
int sumR / count这种整除——先转long累加，再除，否则 200+200+200=600 → 600/3=200 没问题，但 255+255+255=765 → 765/3=255，而 255+255+0=510 → 510/3=170，精度损失明显 - 别忘了把算出的均值 R/G/B 合成一个
int：(alpha
性能卡在哪儿？setRGB() 慢还是颜色解包慢
实测下来，90% 的耗时在反复调用 setRGB(x, y, rgb) —— 它内部每次都要做坐标校验、色彩模型转换、光栅更新，比单纯写数组慢 10 倍以上。
真正快的路径是绕过 API，直写 raster：
WritableRaster raster = image.getRaster(); DataBufferInt buffer = (DataBufferInt) raster.getDataBuffer(); int[] pixels = buffer.getData(); // 然后按 scanline 计算索引：pixels[y * width + x] = rgb;
- 必须确保图像是 TYPE_INT_ARGB 类型，否则
DataBufferInt强转失败 - 写完像素数组后，**必须调用
raster.setDataElements(0, 0, width, height, pixels)**，否则修改不生效——这点极容易漏 - 多线程并行写不同行？可以，但别跨行共享同一行数据，也别用
getRGB()和直写混用，缓存不一致会导致花屏
导出马赛克图时 PNG 透明通道变黑怎么办
根源在保存时没保留 alpha 信息。用 ImageIO.write(image, "png", out) 看似没问题，但如果原始图是带透明背景的 PNG，而你在马赛克过程中把 alpha 设成了 0xFF（强制不透明），或者压根没管 alpha，导出就会丢通道。
- 处理前先检查：
image.getColorModel().hasAlpha()，有就保留；没有就跳过 alpha 计算 - 均值计算时，alpha 也要单独平均，别跟 RGB 混着算——透明度均值不是“半透+半透=全透”
- 写 raster 时，如果原图有 alpha，
pixels[i]的 layout 必须是 ARGB，不能只写 RGB 三位
邻域平均本身很简单，难的是边界对齐、类型匹配、通道一致性——这几个地方一松懈，出来的图要么缺边，要么发紫，要么半透明变实心，调试起来比算法本身还费时间。
