subscribeOn() 只生效一次是因为它仅在订阅时指定源头线程，后续上游操作均在此线程执行；observeOn() 可多次切换，因它每次都将之后的下游操作切至指定调度器。
为什么 subscribeOn() 只生效一次，observeOn() 却能多次切换？
因为 subscribeOn() 控制的是整个 Observable 链的**源头线程**——它只在订阅时起作用，一旦链启动，后续所有上游操作符（比如 map()、filter()）默认都在那个线程里跑；而 observeOn() 是个“下游拦截器”，每次调用都会把**之后的下游操作符**（包括 onNext() 回调、map()、doOnNext() 等）切到指定调度器。
常见错误现象：subscribeOn(Schedulers.io()).map(...).observeOn(Schedulers.computation()).map(...) 中，第一个 map() 其实还在 IO 线程执行，只有第二个 map() 才在 computation 线程——很多人误以为第一个 map() 也自动被“带过去”了。
- 使用场景：IO 操作（如网络请求）后需要做 CPU 密集计算，再切回主线程更新 UI
- 参数差异：
subscribeOn()接受任意Scheduler，但多次调用仅第一次有效；observeOn()每次都生效，可链式叠加 - 性能影响：频繁
observeOn()会引入额外的队列投递和线程切换开销，非必要不嵌套三层以上
Schedulers.io() 不是“万能 IO 调度器”，用错反而拖慢响应
Schedulers.io() 底层是无限扩容的线程池，适合短时、大量、阻塞型 IO（如文件读写、数据库查询），但它**不适合长耗时或 CPU 密集任务**——这类任务会占住线程，导致后续 IO 请求排队，甚至饿死其他订阅者。
常见错误现象：在 flatMap() 内部用 Schedulers.io() 做图片缩放或 JSON 解析，结果 UI 卡顿、网络请求延迟飙升。
立即学习“Java免费学习笔记（深入）”；
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 正确做法：CPU 密集任务必须用
Schedulers.computation()（固定大小，等于 CPU 核心数） - 混合场景示例：
flatMap(url -> api.get(url).subscribeOn(Schedulers.io())).observeOn(Schedulers.computation()).map(Bitmap::decode).observeOn(AndroidSchedulers.mainThread()) - 兼容性注意：Android 上若未引入
RxAndroid，AndroidSchedulers.mainThread()不可用，得手动用HandlerScheduler.from(new Handler(Looper.getMainLooper()))
自定义 Scheduler 时，别直接 new Thread() —— 缺少生命周期管理会泄漏
手动创建线程（如 Schedulers.from(new Thread())）看似简单，但 RxJava 无法感知该线程何时该停、资源何时该释放。尤其在 Android Activity 销毁后，如果该线程还在执行 onNext()，就可能触发空指针或更新已销毁的 View。
常见错误现象：Activity 退出后 Crash 报 ViewRootImpl$CalledFromWrongThreadException，或后台持续打印日志却收不到回调。
- 安全替代方案：用
Schedulers.single()（单线程复用）或Schedulers.trampoline()（当前线程立即执行，适合测试） - 真要定制线程：用
Schedulers.from(Executors.newSingleThreadExecutor())，并确保在组件销毁时调用executor.shutdown() - 性能提示：自定义
Executor若未设拒绝策略（如AbortPolicy），任务堆积时可能 OOM
Android 中 observeOn() 切主线程失败，大概率是忘了加 RxAndroid 依赖
标准 RxJava 2/3 不包含 Android 主线程支持，AndroidSchedulers.mainThread() 是 RxAndroid 提供的扩展。没加依赖时编译不过，但更隐蔽的问题是：有人用 Schedulers.from() 手动包装 Handler，却忽略了 Looper 是否已准备（比如在子线程里 new Handler() 会直接抛 RuntimeException: Can't create handler inside thread that has not called Looper.prepare()）。
常见错误现象：App 启动时报 NoClassDefFoundError: android.os.Looper（混淆问题），或静默失败——UI 不更新，但日志显示 onNext() 已调用。
- 检查点：确认
build.gradle中有implementation 'io.reactivex.rxjava3:rxandroid:3.0.0'（对应 RxJava 3） - Gradle 多模块下容易漏掉：Application module 有依赖，但 feature module 没声明，导致运行时类找不到
- ProGuard 注意：RxAndroid 类需保留，否则混淆后
AndroidSchedulers变成乱码，反射失败
线程切换不是加个 observeOn() 就完事——关键在理解每个调度器的线程模型、生命周期和资源边界。最常被忽略的是：IO 调度器不能跑计算任务，主线程调度器不是 RxJava 自带的，以及自定义线程池必须自己关。
