不能直接用泛型Filter函数对chan T通用过滤，因为channel不支持索引或遍历，需显式读取、判断、写入，并严格管理goroutine生命周期、关闭逻辑及context取消；否则易导致panic或goroutine泄漏。
为什么不能直接用 filter 函数对 chan T 做通用过滤？
Go 的 channel 本身不支持像 slice 那样索引或遍历，而泛型函数若想消费并转发数据，必须显式读取、判断、写入——这意味着你得自己管理 goroutine 生命周期和关闭逻辑。很多人一上来就写：func Filter[T any](in chan T, f func(T) bool) chan T，结果发现输出 channel 永远不关闭，或者在输入 channel 关闭后还 panic：「send on closed channel」。
Filter 函数必须显式处理 channel 关闭与 goroutine 退出
核心是：输入 channel 关闭 ≠ 立刻退出 goroutine；输出 channel 必须在所有有效数据发完后才关闭；中间不能漏掉任何一次 select 对 done 的监听，否则会泄漏 goroutine。
- 必须接收一个
context.Context或额外的done chan struct{}用于提前终止（尤其在 filter 条件耗时或依赖外部状态时） - 输出 channel 类型应为
chan（只写），避免调用方误读；输入应为 <code><-chan T（只读），防止意外写入 - 循环中必须用
for v, ok := <-in; ok;而不是for range in，否则无法在中途响应取消 - 关闭输出 channel 的时机：输入 channel 关闭 + 所有已读数据处理完毕后，且仅由该 goroutine 关闭一次
示例实现：
func Filter[T any](ctx context.Context, in <-chan T, f func(T) bool) <-chan T {
out := make(chan T, cap(in))
go func() {
defer close(out)
for {
select {
case v, ok := <-in:
if !ok {
return
}
if f(v) {
select {
case out <- v:
case <-ctx.Done():
return
}
}
case <-ctx.Done():
return
}
}
}()
return out
}泛型约束影响性能：别盲目加 comparable 或 ~int
如果你的 filter 函数内部只做值传递和函数调用（比如 f(v)），那 [T any] 就足够了。但一旦你试图在函数里对 T 做 map key、== 判断或 switch，就必须加约束——而加错约束会让本可接受 struct{} 或自定义类型的地方编译失败。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
- 需要
==？用[T comparable]，但注意：指针、slice、map、func、chan 不满足该约束 - 只想限定数字类型？用
[T ~int | ~int64 | ~float64]，但别写成[T int]——后者只接受int，不接受int32 - 如果 filter 函数本身不操作
T的内部结构，只是传给用户函数f，那保持[T any]最灵活
实际使用时容易卡住的三个点
这个函数看着简单，但上线后常因以下原因阻塞或泄露：
- 输出 channel 缓冲区太小（比如
make(chan T, 0)），而 filter 条件命中率低，导致 goroutine 在out <- v处永久阻塞——务必根据吞吐预估 buffer size，或搭配select+default做背压处理 - 调用方忘了从返回的
<-chan T读取，goroutine 会永远卡在发送上（Go channel 是同步的） - 多个
Filter链式调用（如Filter(ctx, Filter(ctx, ch, f1), f2)）时，每个都开 goroutine，但上游没关、下游没读，泄漏风险陡增；建议用单个 goroutine + 复合判断替代链式调用
真正难的不是写出来，是让每个 goroutine 在正确时间点退出、channel 正确关闭、buffer 不溢出也不死锁——这些细节不跑真实流量压不出来。
