RxGo 的核心是将 Go 的并发原语映射到 Observable 生命周期，而非简单包装 channel；Observable 是惰性、可取消、带完成信号的迭代抽象，需显式订阅；类型安全、背压控制与错误传播必须全程显式处理。
RxGo 不是“学完语法再套用”的工具，而是要把 Go 的 channel、goroutine、类型系统和错误处理习惯，直接映射到 Observable 的生命周期里——否则写出来的数据流容易崩在订阅时、卡在背压处、漏在错误传播中。
Observable 不是 Channel 的包装器，而是带生命周期的迭代器
RxGo 的 Observable 表面看像 chan interface{}，但本质是惰性、可重试、可取消、带完成信号的迭代抽象。它不自动启动数据发射，只有调用 .Observe() 或 .Subscribe() 才触发执行链。
- 常见错误：把
rxgo.Just(1,2,3)()当成立即执行，结果发现没输出——其实它只返回一个Observable，还没订阅 - 正确做法：显式调用
.Observe()获取 channel，或用.Subscribe()注册Next/Error/Complete回调 - 注意：
FromChannel(ch)会消费原 channel，且不会关闭它；若原 channel 已关闭，FromChannel会立即发出Complete
Map 和 FlatMap 的类型安全陷阱
Map 要求转换函数返回值类型与下游一致，而 FlatMap 必须返回另一个 Observable；Go 没有泛型推导（v2 版本仍需手动指定类型），写错会导致编译失败或运行时 panic。
- 错误示例：
observable.Map(func(x int) string { return strconv.Itoa(x) })—— 若下游期望int，类型不匹配会在调用.Observe()后才暴露 - 推荐写法：用类型注解明确约束，例如
rxgo.Just(1,2,3).Map(func(x int) int { return x * 2 }, rxgo.WithContext(ctx)) -
FlatMap容易忽略内层 Observable 的错误传播：外层不会自动 catch 内层Error，必须用Catch或Retry显式处理
背压不是自动的，需要靠操作符选型和配置控制
RxGo 默认不实现 Reactive Streams 规范中的背压协议，Buffer、Throttle、Sample 这类操作符才是实际控流手段。盲目依赖 WithPool(n) 并不能解决生产者过快问题。
立即学习“go语言免费学习笔记（深入）”；
- 典型症状：下游处理慢，上游持续发数据，内存暴涨甚至 OOM
- 可用方案：
- 用
Buffer(10)限制缓存深度，超限后丢弃或阻塞（取决于 buffer 策略） - 用
Throttle(100 * time.Millisecond)强制节流 - 用
Sample(500 * time.Millisecond)采样最新值，适合传感器类高频流
- 用
-
WithPool(n)只影响操作符并发度（如Map并行执行），不改变数据流速率，也不能替代背压逻辑
错误处理必须贯穿整个链，不能只在末端 catch
RxGo 的错误会沿操作符链向上传播，但一旦被某个操作符吞掉（比如 Filter 不处理 error），后续就收不到任何信号。Observer 的 Error 回调只对未被捕获的 error 生效。
- 常见疏漏：只在
.Subscribe()里写Error: log.Println，却没在Map或FlatMap中预设 fallback - 可靠写法：
- 在可能出错的操作符后接
Catch(func(err error) Observable { ... }) - 用
Retry(3)重试网络请求类 Observable - 用
DefaultIfEmpty防止空流导致逻辑中断
- 在可能出错的操作符后接
- 注意：
Defer创建的 Observable，其内部 error 仍会透出，但延迟到订阅时才发生——这对初始化失败场景很关键
真正难的不是写对一个 Map，而是让整条链在高并发、部分失败、慢消费者共存时仍保持语义清晰和资源可控。RxGo 的每个操作符都在悄悄改写 goroutine 生命周期和 channel 关系，漏掉一个 context 或少设一个 buffer，就可能让流在凌晨三点静默卡死。
