不能直接用 make(chan t) 构建流式api，因为无缓冲通道强制同步，生产者会因下游未读而永久阻塞，违背懒求值、可组合、可中断的设计原则。
为什么不能直接用 make(chan T) 构建流式API
因为无缓冲管道会强制生产者和消费者严格同步，一旦下游消费慢或未启动，上游就会永久阻塞——这和 Java Stream 的懒求值、可组合、可中断特性完全相悖。你写 filter 或 map 时，根本不想管谁在读、什么时候读。
- 无缓冲管道
ch := make(chan int)要求每次ch 都必须有 goroutine 在等 <code>，否则卡死 - 有缓冲管道
ch := make(chan int, 100)只是把阻塞延迟到缓冲满，没解决背压传递、取消、错误传播问题 - 无法表达“这个流还没开始”“中途被 cancel”“某阶段 panic 了怎么收尾”这些真实场景
Stream 类型必须封装 chan + context.Context + error
真正的流式 API 不是裸 channel，而是一个带生命周期控制的结构体。比如 Go-JavaStreamAPI 中的 Stream 实际是：
type Stream struct {
ch chan interface{}
ctx context.Context
cancel func()
err error
}
这样设计才能支持：
-
ctx.WithTimeout控制整条流水线超时，而不是某个 stage 单独超时 -
cancel()调用后，所有 goroutine 应主动退出，避免 goroutine 泄漏 - 任意 stage 返回 error 时，能通过
err字段透出，并让后续 stage 短路 - 用户调用
stream.Close()时，不只是 close(channel)，还要触发 cancel
每个操作符（Filter、Map、Reduce）必须返回新 Stream，且启动独立 goroutine
不能把逻辑写在主 goroutine 里，否则就退化成串行。例如 Map 必须：
- 接收上游
Stream，新建一个chan作为输出 - 启一个 goroutine，在其中 range 上游 channel，对每个元素 apply 函数，写入下游 channel
- 当上游 channel 关闭或 ctx Done，goroutine 必须 clean exit，并 close 下游 channel
- 返回的新
Stream持有这个下游 channel 和继承的 ctx
典型错误是漏掉 select { case 判断，导致 goroutine 永不退出；或者忘了 <code>close(outCh)，让下游永远等不到 EOF。
组合多个操作符时，channel 链容易泄漏，必须用 defer + recover + 显式关闭
写 s.Filter(f).Map(g).Reduce(h) 看似链式，实际背后是 ch1 → ch2 → ch3 三级管道。中间任一 stage panic 或提前退出，上游 channel 就没人读了。
安全做法是：
- 每个 stage goroutine 开头用
defer func() { recover() }()捕获 panic，防止整个 pipeline 崩溃 - 每个 stage goroutine 结尾用
defer close(outCh)，确保无论正常退出还是 panic，下游都能收到关闭信号 - 上游 stage 在写入前加
select { case outCh ，避免向已关闭 channel 写入 panic
最容易被忽略的是：Go 的 channel 关闭后仍可读，但不可再写；而未关闭的 channel 被遗弃，就是 goroutine 泄漏源。这不是理论风险——线上服务跑几天后 goroutine 数翻倍，八成是这里没关严。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
