使用setRGB和getRGB方法处理 BufferedImage 时，我注意到两件事：
setRGB和getRGB方法在某些系统上可能非常慢（比修改 int[] 数组慢两个数量级）。
不能保证setRGB之后的getRGB会返回您传递的相同像素
这最后一点从setRGB的 JavaDoc 中基本上很清楚，其中指出：
...对于具有 IndexColorModel 的图像，选择颜色最接近的索引。
看到我可以直接在 BufferedImage 的 int[] 像素中工作，我可以通过这样做来访问它，例如：
int[] a = ((DataBufferInt) tmp.getRaster().getDataBuffer()).getData();
我想知道：在直接操作像素时是否有任何已知的缺点/陷阱int[]？
getData() 让您可以访问支持的 int 数组的全部目的正是为了这种优化，因此好处很可能超过了缺点。
缺点取决于您如何使用缓冲图像。如果您在编辑时将其绘制到屏幕上，您可能会在屏幕上遇到一些伪影（例如未及时着色的像素），在这种情况下，您应该考虑双缓冲（这确实涉及复制整个图像每次刷新）。
不确定这是否与您的问题相关，但是当使用 BufferedImage 方法创建时您会遇到问题getSubimage(int x, int y, int w, int h)。
返回由指定矩形区域定义的子图像。返回的 BufferedImage 与原始图像共享相同的数据数组。
尽管被描述为，方法getTileGridXOffset()并返回偏移量然后getTileGridYOffset()
返回瓦片网格相对于原点的 x 偏移量，例如瓦片位置的 x 坐标 (0, 0)。这始终为零。
但是因为您不能（据我所知）访问scanlineStride栅格的字段，所以您将无法获得数组的正确索引。