Worker pool 适用于语言学习中的并发任务（如翻译、校对），关键在任务IO特性与系统负载；workerCount需匹配API限流与HTTP连接池配置，jobs channel缓冲大小应兼顾突发流量与内存安全，sync.WaitGroup需正确管理生命周期，结果返回须保序防丢失。
worker pool 不是为“语言学习”设计的模式，它解决的是并发资源控制问题。如果你正在批量处理语言学习相关任务（比如并发调用翻译 API、批量校对文本、解析词库文件、生成练习题），那 worker pool 确实适用——但配置关键不在“语言学习”，而在任务类型、IO 特性与系统负载。
怎么设 workerCount 才不拖慢翻译请求又不压垮服务
翻译类任务本质是网络 IO 密集型，延迟高、CPU 占用低，worker 数可以比 CPU 核心数高得多：
- 本地测试环境（单机 mock API）：workerCount = runtime.NumCPU() * 3 起步
- 真实调用第三方翻译 API（如 DeepL、Google Cloud Translation）：必须查清该服务的 rate limit 和连接池上限
- 常见坑：设了 100 个 worker，但 http.Client 的 Transport.MaxIdleConnsPerHost 默认只有 2，结果 98 个 goroutine 在排队等连接，吞吐反而不如 5 个 worker
- 正确做法：同步调大 http.Client 配置，例如：
client := &http.Client{<br> Transport: &http.Transport{<br> MaxIdleConns: 100,<br> MaxIdleConnsPerHost: 100,<br> IdleConnTimeout: 30 * time.Second,<br> },<br>}
jobs channel 用带缓冲还是无缓冲
语言学习任务常有突发流量（比如用户一次性上传 5000 个单词 CSV 文件）：
- 用无缓冲 make(chan Job, 0)：主协程在没空闲 worker 时立刻阻塞，HTTP handler 可能超时返回 503
- 用带缓冲 make(chan Job, 1000)：能暂存积压任务，但缓冲区过大（如设成 10000）会掩盖下游瓶颈，导致内存悄悄上涨、OOM 前毫无征兆
- 推荐值：缓冲大小 ≈ 预期峰值任务量 × 1.2，且不超过可用内存的 5%（例如 1GB 内存机器，每个 Job 结构体约 2KB，缓冲最多 250 个）
为什么 sync.WaitGroup 总是提前返回或死锁
这是语言学习批量任务中最常卡住的点，根本原因不是逻辑错，而是生命周期管理错：
- 错误写法：wg.Add(1) 放在 go worker() 函数内部 → 每个 worker 操作的是 wg 值拷贝，主 goroutine 的 wg.Wait() 看不到计数变化
- 正确顺序必须是：
- 主 goroutine 先
wg.Add(workerCount) - 再
go worker(&wg, jobs, results)（传指针） - 每个 worker 执行完任务后
defer wg.Done()或直接wg.Done() - 所有任务发完后
close(jobs)，不能早也不能晚
wg.Wait() 立刻返回（任务没跑完）、要么永远卡住（worker 因 channel 未关无法退出）如何安全返回每个单词的校对结果而不丢数据
语言学习任务常需一一对应返回结果（比如输入 100 个单词，必须输出 100 条校对建议）：
- 别用无序 results chan Result 直接 range 收集——结果顺序和输入顺序不一致，前端渲染错乱
- 更稳妥做法：给每个 Job 带上 ID int 字段，Result 结构体也含该 ID，主 goroutine 用 map[int]Result 缓存，最后按原始顺序输出
- 如果必须保序且不想额外内存开销：用带缓冲的 results chan Result + 主 goroutine 启动等量接收 goroutine，按 ID 投递到对应 slice 位置，但要注意竞态，加锁或用 sync/atomic 控制索引写入
- 容易被忽略的细节：如果某个 worker panic（比如正则匹配非法 pattern），没 recover 就会静默消失，对应 ID 的结果永远收不到 —— 必须在 worker 内部包一层 defer func(){if r:=recover();r!=nil{...}}()
