runtime.gomaxprocs仅控制p数量，即并行执行用户代码的os线程上限；真正影响系统线程负载的是阻塞系统调用触发的m创建，因此需通过goroutine池限制可能阻塞的任务并发数，并配合context超时与资源清理，才能有效控住线程数。
runtime.GOMAXPROCS 不控制 goroutine 数量，也不等于“系统线程负载上限”——它只设 Go 调度器中 P（Processor）的数量，即**可并行执行的 OS 线程上限**。真正影响系统线程负载的是：实际运行中的 goroutine 是否阻塞在系统调用（如 net.Read、os.Open、syscall），以及 runtime 是否需要创建新的 M（OS 线程）来承载被阻塞的 G。
所以，想“控制最大系统线程负载”，关键不是调小 GOMAXPROCS，而是**限制可能触发阻塞系统调用的并发数**。Goroutine 池在这里的作用，是把“潜在阻塞型任务”关进可控的笼子。
为什么 Goroutine 池能间接控住系统线程数？
每个阻塞系统调用（比如 HTTP 请求、数据库查询、文件读写）会让 goroutine 脱离 P 并绑定到一个 M 上，直到系统调用返回。如果 1000 个 goroutine 同时发 HTTP 请求，Go runtime 可能瞬间拉起上百个 OS 线程（M），远超 GOMAXPROCS 设置值，造成线程资源耗尽、上下文切换爆炸。
用 Goroutine 池限制 worker 数量（比如固定 20 个），就等于最多只有 20 个 goroutine 能同时发起阻塞调用 → 最多新增约 20 个活跃 M → 系统线程负载可控。
- 池大小应略高于典型 I/O 延迟下的并发需求，但必须低于目标系统的连接数/线程数硬限（如 MySQL max_connections、Linux ulimit -n）
- 不要设成
runtime.NumCPU()—— 这是 CPU 密集型任务的参考，I/O 型任务常需更大池（但要配合超时） - 若池中 worker 执行的是纯计算（无阻塞），那它根本不会新增 M，此时线程数几乎不变
goroutine 池 + context.Context 是防卡死的底线
只靠固定 worker 数还不够。一个 worker 卡在没超时的 http.Get 或死锁 channel 上，就会永久占用一个 M，后续所有任务排队等它释放——池形同虚设。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
必须给每个任务加 context 控制：
- 提交任务时传入
context.WithTimeout(ctx, 5*time.Second) - worker 内部用
select监听ctx.Done()，并在退出前清理资源（关闭连接、释放 buffer） - 避免在 worker 中直接用
time.Sleep替代超时，它不响应 cancel - panic 必须 recover，否则 worker 退出后无法重用，池容量实质缩水
别混淆：chan struct{} 信号量 vs. Goroutine 池
两者都能限流，但目的和适用场景不同：
-
sem := make(chan struct{}, 10)是轻量级并发闸门，适合“一次一任务、无状态”的简单场景（如批量发请求） - Goroutine 池（带任务队列+固定 worker）更适合需要复用资源的场景：HTTP client 复用连接、DB 连接池复用 session、TLS handshake 复用上下文
- 信号量本身不管理 goroutine 生命周期；池则自带启动、关闭、等待机制（
sync.WaitGroup+close(tasks)） - 信号量无法优雅停止正在运行的任务；池可通过
context.WithCancel主动中断所有 worker
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
