风控高并发系统需用pipeline+selective parallelism：黑名单同步前置，规则与模型并行且独立超时，特征查询可降级；禁用无context控制的goroutine，waitgroup与channel关闭须严格分离，生产者负责关闭channel。
怎么用 Goroutine + Channel 拆解一个风控请求
高并发系统设计面试里，考的不是“会不会开协程”，而是“能不能把一个复杂请求合理切片、并行、可控地执行”。比如交易风控场景，一次请求要查黑名单、跑规则、调模型、算特征——这些操作耗时差异大、失败影响不同，硬串行会拖慢 P99 延迟，全并行又可能压垮下游。
正确做法是 Pipeline + Selective Parallelism：关键路径保顺序，非关键/可降级部分并行，并用 context.WithTimeout 统一兜底。
- 黑名单检查必须同步前置（快且不可跳过），用
if blacklisted := checkBlacklist(txn); blacklisted { return reject } - 规则引擎和模型推理可以并行，但各自设独立超时（比如规则 30ms，模型 50ms），避免一个慢拖死全部
- 状态特征（如用户最近 10 分钟行为）允许降级：用
select包一层，超时就返回默认值，不阻塞主流程 - 绝对不要在 goroutine 里直接
http.Post后不等结果——没 context 控制的 goroutine 是泄漏温床
sync.WaitGroup 和 channel 关闭的常见误用
面试官常故意在代码题里埋一个 WaitGroup + close(channel) 的组合陷阱。表面看是“等所有 goroutine 写完再关 channel”，实际很容易触发 panic 或漏数据。
典型错误：goroutine 数量动态变化时，wg.Add(n) 写在循环外但 n 计算有竞态；或 close(ch) 放在 wg.Wait() 后，但某个 goroutine 还在往已关闭的 channel 发送。
- 永远用
defer wg.Done()，别手写wg.Done()在逻辑分支里 - channel 关闭只由“生产者”负责，且必须确保所有发送已完成——推荐用
sync.Once包一层关闭逻辑 - 消费者侧别依赖
for range ch自动退出，尤其当 channel 可能被提前关闭时，改用for { select { case v, ok := - 如果只是做信号通知（比如“所有任务启动完毕”），直接用
chan struct{}+close()，别传业务数据
为什么 GOMAXPROCS 不是越大越好
很多候选人一听到“高并发”就下意识调大 GOMAXPROCS，甚至设成 128。这在 IO 密集型服务里可能有用，但在风控这类 CPU-bound 场景，反而引发调度抖动和缓存失效。
Go 调度器的 P（Processor）本质是逻辑 CPU，每个 P 绑定一个 OS 线程。当 GOMAXPROCS 远超物理核心数，P 之间频繁切换，Mcache 局部性被破坏，内存分配性能下降明显。
- CPU 密集型任务（如规则匹配、特征编码）：设为
runtime.NumCPU()最稳，实测波动小于 ±3% - 混合型（如风控引擎：部分计算+部分 Redis 查询）：设为
1.5 * runtime.NumCPU()，上限不超过 32 - 绝不要在程序里硬编码
runtime.GOMAXPROCS(64)—— 容器环境里 CPU limit 可能只有 2 核，这等于自废武功 - 上线前必做：用
go tool trace看 Goroutine 执行图，如果大量 goroutine 在 “Runnable” 状态排队超过 1ms，才是真需要调参的信号
Redis 缓存穿透/雪崩在 Go 里的真实表现
面试时说“加布隆过滤器”“加随机过期时间”只是理论。在 Go 实现里，真正卡住人的，是 client 层细节和 context 传递断层。
比如用 redis-go 的 Get(ctx, key)，如果 ctx 已超时，client 会立即返回 error，但很多人忘了检查这个 error，直接拿空字符串去后续逻辑，导致误判为“缓存未命中”，进而打穿 DB。
- 所有缓存读写必须检查
err != nil，且区分redis.Nil（key 不存在）和超时/连接错误 - 防穿透：本地缓存（如
bigcache）存空对象时，用带过期时间的 struct，别存nil或空字符串 - 防雪崩：批量查询时，用
pipeline替代多次Get，但 pipeline 的 ctx 超时是整体的——一个慢 key 会拖累整批，不如用multi.Get+ 每个 key 单独 context - 最隐蔽的坑：Redis client 初始化时没设
ReadTimeout，网络抖动时 goroutine 卡在read系统调用上，GMP 调度器无法抢占，整个 P 被拖住
高并发系统设计的难点不在并发模型本身，而在于如何让 goroutine、channel、context、第三方 client 四者在超时、错误、降级、扩容这些边界条件下，依然保持行为可预测。这点光看文档没用，得真在压测里见过 goroutine 泄漏堆栈、见过 redis client 卡住 P、见过 GC pause 突然飙到 20ms，才算摸到门。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
