Go 默认将 GOMAXPROCS 设为逻辑 CPU 数，但图片处理等 I/O + CPU 混合型任务盲目设高会加剧调度开销、goroutine 阻塞在系统调用（如 os.Open、image.Decode），导致上下文切换频繁、吞吐下降；实测建议按负载“打折”：纯计算型用 runtime.NumCPU()，I/O 密集型设为 NumCPU()/2 或固定值 4，且仅启动时设置一次。
为什么 runtime.GOMAXPROCS 设置为 CPU 核心数反而变慢？
Go 默认会把 GOMAXPROCS 设为逻辑 CPU 数，但图片处理这种 I/O + CPU 混合型任务，盲目设高反而引发调度开销和内存争用。尤其当批量读取文件、解码 JPEG/PNG、调整尺寸再写回时，goroutine 大量阻塞在 os.Open、image.Decode 或 jpeg.Encode 上，调度器频繁切换，实际吞吐不升反降。
实操建议：
- 先用
runtime.NumCPU()获取核心数，再根据任务类型「打折」：纯计算型可设为NumCPU()，I/O 密集型建议设为NumCPU() / 2或固定值如4 - 避免在循环里反复调用
runtime.GOMAXPROCS(n)—— 它是全局设置，只应在程序启动时调一次 - 用
pprof抓取go tool pprof http://localhost:6060/debug/pprof/goroutine?debug=2看 goroutine 是否堆积在系统调用上
sync.WaitGroup 和 context.Context 哪个更适合控制批处理生命周期？
单纯等所有图片处理完，用 sync.WaitGroup 足够；但一旦涉及超时、取消、错误传播（比如某张图损坏导致解码失败），context.Context 是唯一可靠选择。
常见错误现象：用 WaitGroup 启动 100 个 goroutine 处理图片，其中第 5 张因文件损坏卡死在 image.Decode，整个流程无限等待。
立即学习“go语言免费学习笔记（深入）”；
实操建议：
- 初始化时传入带超时的 context：
ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second) - 每个 goroutine 开头检查
ctx.Err() != nil，并在 I/O 调用处使用支持 context 的替代方案（如用http.NewRequestWithContext加载网络图，本地文件暂无原生支持，需手动加 select + timer） -
WaitGroup仍需保留，用于确保所有 goroutine 已退出，但不再承担“等待成功”的语义
用 chan *image.RGBA 传递图像数据，为什么内存暴涨？
每张 4K 图片解码后可能占 32MB 内存（3840×2160×4 字节），如果用无缓冲 channel 直接传 *image.RGBA 指针，且下游处理慢（比如写磁盘速度跟不上），channel 会持续缓存未消费的图像对象，GC 来不及回收，OOM 风险极高。
实操建议：
- 永远对 channel 设限：
make(chan *image.RGBA, 4)—— 缓冲数 ≤ 预期并发数，防止生产者狂塞 - 更推荐「零拷贝」复用：用
sync.Pool管理*image.RGBA实例，Decode 前从池中取，处理完立刻Put() - 若必须传递图像，优先传
io.Reader或文件路径，让下游按需解码，而不是提前全量加载到内存
为什么 jpeg.Encode 并发写同一目录会报 permission denied？
不是权限问题，而是 Windows 下对同一目录高频创建文件触发了防病毒软件或 NTFS 日志锁；Linux/macOS 则多因 ext4/xfs 文件系统元数据更新竞争，表现为 open /path/out.jpg: permission denied（实际是 ENOSPC 或 EDQUOT 被误报）。
实操建议：
- 写入前确保目标目录已存在且可写：
os.MkdirAll(dir, 0755)，不要依赖 goroutine 自行创建 - 避免所有 goroutine 同时调用
os.Create—— 改用os.OpenFile(path, os.O_CREATE|os.O_WRONLY|os.O_TRUNC, 0644)，它比Create更稳定 - 若批量写入量大（>1000 张），考虑分批次，每批间隔几毫秒，或用单个 goroutine 串行写，其他 goroutine 只负责解码+缩放后发 channel
Encode 在等磁盘 —— 这些细节不打日志、不设超时、不控缓冲，跑着跑着就静默失败。 
