回调不传递线程而传递数据，需确保线程安全：通过闭包捕获或参数绑定携带数据，由异步框架决定回调执行线程，推荐不可变数据快照或协程等现代方案替代回调。
在异步任务编排中，回调函数本身不直接“传递线程”，而是作为任务完成时的执行入口，在目标线程（通常是回调所在线程）中安全访问或处理数据。关键在于：**确保回调执行时能拿到所需数据，且数据访问是线程安全的**。这通常不靠回调“传递线程”，而是靠“传递数据”+“明确回调执行上下文”。
回调携带数据：闭包捕获或参数绑定
最常用、最自然的方式是让回调函数在定义时就“记住”需要的数据，即利用闭包（如 JavaScript、Python、Java lambda）或显式参数绑定（如 C++ std::bind、Java Runnable 包装）。
- JavaScript 示例：异步请求后，回调直接使用外层变量 userToken 和 config
.then(data => handleSuccess(data, userToken, config))
.catch(err => handleError(err, userToken));
- Java 示例：Lambda 捕获局部 final 变量，或封装进对象传入
CompletableFuture.supplyAsync(() -> doWork())
.thenAccept(result -> updateUI(taskId, result)); // taskId 被闭包捕获
回调执行线程决定数据消费位置
谁调用回调，决定了数据在哪个线程被使用。这不是回调自己选的，而是由异步框架/执行器控制的：
- Android Handler/Looper：回调 post 到主线程，可安全更新 UI；数据需在主线程内读取或拷贝
- Java CompletableFuture：用 thenAcceptAsync(..., executor) 显式指定线程池，数据就在该 executor 线程中被消费
- Node.js：所有回调默认在事件循环线程（单线程），无需额外同步，但要注意长任务阻塞
⚠️ 注意：不要在回调里直接操作非线程安全的对象（如未加锁的 ArrayList、HashMap），除非确认回调总在同一线程执行。
跨线程安全传递：避免共享可变状态
如果原始数据位于发起线程（如后台线程），而回调在另一线程（如 UI 线程）执行，应避免让两个线程共享同一可变对象。
- 推荐做法：在回调触发前，将所需数据“快照”为不可变结构（如 ImmutableList、String、DTO 对象）再传入
- 不推荐：把一个正在被后台线程修改的 List 直接传给 UI 回调 —— 极易引发 ConcurrentModificationException 或显示错乱
- 必要时用线程安全容器（如 CopyOnWriteArrayList）或加锁，但会增加复杂度，应优先考虑数据复制
替代方案：比回调更清晰的协作方式
现代异步编程中，回调易导致“回调地狱”且线程语义模糊。更推荐以下方式实现线程间数据流动：
- 协程（Kotlin/Go/Rust）：用 suspend 函数 + Dispatcher 切换上下文，数据自然随协程体流转，无显式回调
- 响应式流（RxJava/Project Reactor）：通过 observeOn() 明确指定下游数据消费线程，数据自动序列化传递
- Channel / MessageQueue（如 Kotlin Channel、Android LiveData）：生产者发数据，消费者在指定线程接收，解耦更彻底
这些方案把“数据在哪处理”和“数据怎么传”分离得更干净，比手工管理回调线程更可靠。
