应按行区间分片并确保子图区域互不重叠：用img.Bounds()获取真实范围，每个goroutine渲染独立SubImage，最后单次draw.Draw合并；复用缓冲需显式清零，LockOSThread仅用于依赖TLS的C库调用。
goroutine 分片渲染图像时如何避免像素越界
直接按像素行或块启动 goroutine 容易在边界处写入 image.RGBA 底层数组越界，尤其当图像宽高不能被 goroutine 数量整除时。Go 的 image.RGBA 是按行连续存储的，索引计算必须严格对应 (y * stride + x * 4)，而非常见的 y * width + x。
- 用
img.Bounds()获取真实坐标范围（Min.X/Max.X等），别硬编码从0开始切分 - 每个 goroutine 渲染前先调用
img.Set(x, y, color)做一次安全校验 —— 虽慢但能快速暴露越界逻辑 - 推荐按“行区间”而非“固定数量 goroutine”分片：例如将
height = bounds.Max.Y - bounds.Min.Y平均分给runtime.NumCPU()个 worker，每段负责连续若干行
sync.Pool 复用 RGBA 像素缓冲区是否真有效
对高频调用的像素级计算（如光线追踪每像素多次采样），反复 make([]uint8, 4) 会触发小对象 GC 压力；但直接复用 []uint8 又需手动管理长度和清零，容易残留旧值导致颜色异常。
-
sync.Pool适合复用固定大小的临时缓冲，比如每次采样生成的[]float64中间结果，而非最终写入图像的color.RGBA - 若要复用像素字节缓冲，必须在
Put前显式清零：buf := pool.Get().([]byte) defer func() { for i := range buf { buf[i] = 0 } ; pool.Put(buf) }() - 实测表明：单帧渲染耗时 >50ms 时，复用缓冲才有可观收益；低于 10ms 时，
sync.Pool本身锁开销可能反超分配成本
使用 image/draw.Draw 覆盖已有图像时的并发安全陷阱
image/draw.Draw 默认不是并发安全的 —— 即使目标图像是 *image.RGBA，其底层 pix 字节数组仍会被多个 goroutine 同时写入，引发竞态（race）且结果不可预测（颜色错乱、部分区域未更新）。
- 绝对不要让多个 goroutine 同时调用
draw.Draw(dst, ...)写同一张图 - 正确做法是：每个 goroutine 渲染到独立的
*image.RGBA子图（用subImage := img.SubImage(rect).(*image.RGBA)），最后用单个 goroutine 合并 - 合并时仍用
draw.Draw，但仅限一次，且确保源子图之间无重叠区域
何时该用 runtime.LockOSThread 而非普通 goroutine
当图像算法重度依赖 C 库（如 OpenCV 绑定、SIMD 加速的 PNG 编码器），且该库内部维护线程局部状态（TLS）或要求调用者绑定固定 OS 线程时，普通 goroutine 的 M:N 调度会导致崩溃或数据污染。
立即学习“go语言免费学习笔记（深入）”；
- 典型错误现象：
unexpected signal during runtime execution或 C 函数返回空指针/非法内存地址 - 只在进入 C 调用前加
runtime.LockOSThread()，并在 C 返回后立即runtime.UnlockOSThread() - 注意：锁定线程后，该 goroutine 不再参与 Go 调度，若 C 调用阻塞过久，会拖慢整个 P，务必设好超时或用
cgo的/* #include <signal.h> */配合异步中断
实际项目中，最常被忽略的是 SubImage 返回的子图是否真正独立 —— 它只是共享原图底层数组的视图，若多个子图覆盖区域有交集，依然会竞态。必须确保每个 goroutine 的矩形区域互不重叠，且全部落在 img.Bounds() 内。
