用chan string构建日志字符串流管道，每个过滤器启动独立goroutine，输入输出均用带缓冲channel（如make(chan string, 16)），过滤器只做字符串变换或丢弃，I/O操作剥离至末端writer goroutine统一处理。
怎么用 channel 管道串起日志字符串流的过滤阶段
日志字符串流不是 HTTP 请求，不能套用 http.Handler 链；必须用 chan string 构建真正的数据管道。每个过滤器是一个独立 goroutine，接收输入 channel、产出输出 channel，靠缓冲区解耦速率差异。
常见错误是把过滤器写成同步函数调用，导致上游卡住；或用无缓冲 channel，在下游没启动时直接阻塞整个流水线。
- 每个过滤器必须启动自己的 goroutine：
go func() { ... }()，不能裸调函数 - 输出 channel 建议带缓冲：
make(chan string, 16)，避免因瞬时积压触发 goroutine 阻塞 - 上游 producer 负责
close(out)，所有消费者只读完就退出，不主动 close 输入 channel - 若某阶段要丢弃日志，直接跳过
out <- s，不传即可；链式中断靠“不发”实现，不是返回 bool
为什么不能在日志过滤器里直接调用 log.Printf 或写文件
log.Printf 是同步 I/O，哪怕写到 os.Stderr，在高吞吐下也会成为瓶颈——单个 goroutine 写日志慢了，整条管道就淤积。更糟的是，多个过滤器并发调用 log.Printf，会竞争 stdout 锁，实际吞吐反而下降。
真正可行的做法是把日志字符串当作纯数据流转，最后统一交给一个专门的 writer goroutine 处理。
立即学习“go语言免费学习笔记（深入）”；
- 过滤阶段只做字符串变换（如
strings.TrimSpace、strings.Contains判断）、路由分发（按 level 字段分流到不同 out channel） - 所有 I/O 操作（写文件、发 Kafka、打到 ES）必须剥离到 pipeline 末端，且用带背压的 consumer 控制速率
- 若需采样或限频，放在最前段做：
if rand.Intn(100) < 5 { out <- s }，别在 writer 侧做，否则已序列化的字符串白跑了
如何安全地从 X-Forwarded-For 提取真实 IP 并注入日志字段
HTTP 中间件里提取 IP 是常见需求，但直接用 r.Header.Get("X-Forwarded-For") 得到的是逗号分隔字符串，且该头可被伪造。日志过滤器本身不接触 *http.Request，所以这个提取动作必须发生在日志生成源头——即 HTTP 中间件写入 pipeline 前。
关键不是“怎么解析”，而是“在哪解析”：必须在日志 entry 构造完成、转成字符串前，就把校验过的 IP 注入结构体字段，再序列化。
- 不要在字符串流过滤阶段再去 parse IP——此时已是扁平字符串，再切分、校验、去私有网段成本高且易错
- 推荐做法：HTTP 中间件构造
map[string]interface{}日志结构体，调用clientIP(r)提取并验证，再json.Marshal成字符串推入 pipeline -
clientIP函数必须优先取X-Forwarded-For最左非私有 IP（如10.0.0.1、192.168.x.x要跳过），fallback 到r.RemoteAddr解析出 IP 部分 - 若中间件已信任 Nginx，且 Nginx 配置了
proxy_set_header X-Real-IP $remote_addr;，则直接用r.Header.Get("X-Real-IP")更可靠
goroutine 泄漏和 channel 死锁最容易发生在哪几个点
管道过滤器看似简单，但 goroutine 生命周期和 channel 关闭时机稍有偏差就会泄漏或死锁。最危险的不是代码量多的地方，而是“看起来没问题”的几行。
典型泄漏场景：上游已 close，下游还在 range；或两个 goroutine 同时 close 同一个 channel；或 io.Copy 未设 deadline 导致连接 hang 住 goroutine。
- 绝对不要在多个 goroutine 中对同一 channel 调用
close()—— 只有创建者能 close 它的 output channel - 使用
errgroup.Group管理 fan-in 多路输入：等所有上游 goroutine return 后，再统一 close 汇聚 channel - 每个过滤器 goroutine 的 for-loop 必须带
select+ctx.Done()，防止 context cancel 后 goroutine 永远不退出 - 测试时故意让某个过滤器 panic，观察其他 goroutine 是否能及时回收 —— 这比压测更能暴露泄漏问题
实际跑起来后，最常被忽略的是缓冲区大小和超时控制。64KB 缓冲对千 QPS 日志流可能刚够，但万级流量下得调到 256KB；而每个 goroutine 的 context 必须设 WithTimeout，否则一个卡死的正则匹配就能拖垮整条链。
