微服务中pipeline卡死主因是中间stage未正确处理channel关闭：上游已close(in)但下游未检查ok或未用for v := range in，导致goroutine永久阻塞等待数据，引发deadlock或大量goroutine堆积。
为什么微服务里 pipeline 容易卡死在中间 stage
微服务场景下 pipeline 卡死，90% 是因为某个 stage 的 goroutine 没收到关闭信号，还在等上游数据——而上游早就 close 了输入 channel，只是下游没检查 ok 就继续读，或者压根没用 for v := range in。
- 典型现象：
fatal error: all goroutines are asleep - deadlock，或 pprof 显示几十个 goroutine 堵在 - 真实场景：服务 A 调用服务 B 获取一批用户 ID，B 返回空 slice 后直接 close 输出 channel；但 A 的 pipeline 第二阶段用了
for { v, ok := ，漏掉最后一次 <code>ok == false就退出，导致后续 stage 永远 range 不到 EOF - 正确做法：所有 stage 必须统一用
for v := range in，且上游（比如 RPC client 封装层）必须在数据发完后显式调用close(in) - 特别注意：gRPC 流式响应、HTTP chunked body 等场景，不能依赖连接关闭自动触发 channel 关闭，得靠业务逻辑判断“流结束”并主动 close
怎么让 pipeline 支持服务间超时与 cancel 传播
微服务调用链里，一个 stage 超时不能只 kill 自己，必须让整条 pipeline 快速退出，否则 goroutine 和 channel 缓冲区会持续堆积。
- context.Context 必须从入口传到底层每个 stage 函数签名里，例如
func(ctx context.Context, in - 所有阻塞操作（读 channel、HTTP 调用、DB 查询）都得包在
select里，例如：select { case - 错误 stage 发现异常（如 HTTP 500、JSON 解析失败）时，不应 panic，而应调用
cancel()（来自context.WithCancel），并立即 return —— 别再往out写数据 - 切忌在 stage 内部新建子 context（如
context.WithTimeout），超时策略必须由最外层服务统一控制，否则 cancel 无法穿透
扇出（fan-out）worker 数量设多少才不爆内存
微服务常需并行处理请求（比如批量查用户资料），但 fan-out worker 开太多，goroutine + channel 缓冲会吃光 RSS。
Colly Golang Web Scraper and Crawler Framework
下载
Colly 是一个用于 Go 语言的快速开源爬取和爬虫框架。它适用于从简单的页面提取到异步爬虫处理大量页面集合，支持请求回调和结构化解析。
- 别硬编码
4或8个 worker —— 应基于目标服务的 CPU 核心数和单次处理耗时动态计算，公式参考：min(4, runtime.NumCPU()) * (100ms / avg_process_ms) - 每个 worker 的输入 channel 必须带缓冲，大小建议
make(chan string, 16)；太大（如 1024）等于放弃背压，太小（如 1）会导致频繁阻塞 - worker 内部若含阻塞 IO（如 DB 查询），务必加
ctx透传，并在 SQL 执行前检查ctx.Err()，避免 goroutine 卡住不返回 - 监控指标要盯紧：
runtime.NumGoroutine()异常上涨 +runtime.ReadMemStats().Mallocs持续增长，基本就是 fan-out 泄漏了
错误怎么跨 stage 传递而不污染数据 channel
微服务 pipeline 里，一个 stage 解析失败，下游不该继续处理脏数据，但也不能靠 panic 传播——它跨不了 goroutine，还可能 crash 整个服务。
立即学习“go语言免费学习笔记（深入）”；
- 绝对不要把
error塞进数据 channel，例如chan interface{}或chan *Result里混装成功/失败值，调用方必须做类型断言，极易 panic - 推荐方案：定义
type Result struct { Data string; Err error }，所有 stage 统一输出chan Result，下游用if r.Err != nil分支处理 - 更轻量做法：额外传入
errCh chan，仅第一个出错 stage 往里发一次错误，主控 goroutine select 等待 <code>errCh或最终结果 channel，收到即终止 pipeline - 关键细节：
errCh必须带缓冲（make(chan error, 1)），否则错误发送时若主控还没开始 select，就会永久阻塞 sender
实际写微服务 pipeline 时，最难的不是拼 channel，而是让每个 stage 对“关闭”“错误”“取消”有确定性响应。很多问题直到压测半小时后 RSS 突增才暴露，那时再查 pprof，往往发现是某个 stage 的 defer close(out) 被 recover() 吞掉了，或者 fan-out 的 merge goroutine 忘了等所有输入 channel 关闭就提前 close 了输出 channel。
