不能直接用 sync.Pool 实现动态线程池，因其仅复用对象，不管理 goroutine 生命周期、并发数或负载伸缩；需自建调度器，含活跃数、最大容量、空闲阈值、任务队列与信号控制，通过 channel 驱动和原子计数实现扩缩容。
为什么不能直接用 sync.Pool 实现动态线程池
sync.pool 是对象复用工具，不是并发执行调度器。它不管理 goroutine 生命周期，也不控制并发数，更无法响应负载动态伸缩——你往里放的是“对象”，不是“工作线程”。真要建线程池，得自己调度 goroutine、维护运行中任务数、定义扩容/缩容策略。
核心结构体怎么设计才支持动态扩缩容
关键字段必须包含：当前活跃 worker 数、最大容量、最小空闲数、任务队列（chan）、控制信号（sync.WaitGroup + sync.RWMutex 保护状态）。不要用 slice 管理 worker，而是靠 channel 驱动 + 计数器联动：
-
workers不存 goroutine 句柄，只用atomic.Int64记录活跃数 - 任务队列用
chan func()，带缓冲（比如 1024），避免提交阻塞 - 扩容触发点：当任务入队时，若
activeWorkers < maxWorkers且len(queue) > threshold（如 50），则启动新 worker - 缩容逻辑不主动 kill goroutine，而是让空闲超时的 worker 自行退出（用
select+time.After）
worker 启动和退出的边界条件怎么处理
每个 worker 是一个长期运行的 goroutine，但必须能安全响应停止信号。错误写法是用 for range queue —— 这会导致关闭 channel 后 panic；正确做法是用 select 轮询任务与超时：
func (p *ThreadPool) worker() {
defer p.wg.Done()
var lastWorkTime time.Time = time.Now()
for {
select {
case task, ok := <-p.taskQueue:
if !ok {
return
}
task()
lastWorkTime = time.Now()
p.activeWorkers.Add(1)
case <-time.After(p.idleTimeout):
// 空闲超时，且当前活跃数 > minWorkers，允许退出
if int(p.activeWorkers.Load()) > p.minWorkers {
return
}
}
}
}
注意：p.activeWorkers 要在执行前加 1、执行后减 1（示例中简化了，实际需配对）；idleTimeout 建议设为 30–60 秒，太短导致抖动，太长缩容滞后。
提交任务和关闭池时最容易踩的坑
常见问题集中在 channel 关闭时机和 goroutine 泄漏：
立即学习“go语言免费学习笔记（深入）”；
- 关闭
taskQueue前，必须先调用p.wg.Wait()等待所有 worker 退出，否则读已关闭 channel panic - 不要在
Submit中直接go f()—— 这绕过池控，等于没用线程池 - 如果任务本身 panic，需 recover 并记录日志，否则 worker 会静默退出，导致
activeWorkers计数失准 - 扩容时重复启动 worker：必须用 CAS 或 mutex 检查
activeWorkers < maxWorkers，否则高并发提交可能瞬间拉起上百 goroutine
动态线程池真正的复杂点不在启动，而在状态一致性 —— 活跃数、队列长度、空闲超时、关闭信号，四个变量必须原子协同。少一个锁或一次忘记 Add/Dec，压测时就掉连接、卡死、计数负值。
