Worker线程中同步阻塞虽不卡主线程，但会导致任务不可中断、资源浪费和隐性超时失败三类风险：阻塞期间无法响应isStopped()致假死；独占线程池资源降低吞吐；状态更新与结果返回不同步引发重复提交或数据不一致。
在 Worker 线程中使用同步阻塞操作本身不会导致主线程卡顿，但会带来三类关键风险：任务不可中断、资源浪费、以及隐性超时失败。
阻塞期间无法响应停止信号
Worker 的 doWork() 是同步执行的，系统通过 isStopped() 检测是否应中止任务。但如果代码里存在长时同步阻塞（如 Thread.sleep(5000)、未设 timeout 的 InputStream.read() 或密集循环），线程将无法及时轮询 isStopped()，导致“假死”状态——即使系统已下发停止指令，Worker 仍继续执行直到阻塞结束或自然完成。
- 务必在每个耗时操作前后检查
if (isStopped) return Result.success()或failure() - 网络请求必须显式设置连接/读取超时，避免无限等待
- 循环体内部不要省略
isStopped判断，尤其在重复调用场景中
线程资源被独占，影响调度公平性
Android 的 WorkManager 默认使用共享线程池（如 ExecutorService）。一个 Worker 长时间阻塞，会占用线程池中的一个工作线程，导致其他待执行 Worker 排队等待，整体任务吞吐下降。尤其在配置了小核心线程数（如 2）+ 小容量队列（如 10）时，极易引发任务堆积。
- 避免在
doWork()中执行 CPU 密集型计算（如图像缩放、加密解密） - 若必须处理，优先考虑移至
runInExecutor或改用CoroutineWorker+withContext(Dispatchers.Default) - 对可拆分任务（如批量下载），加入进度检查点，防止单次阻塞过久
消息通信与状态不同步
Worker 与主线程靠 postMessage() 或数据库/SharedPreference 传递状态。若阻塞发生在状态更新之后、结果返回之前（例如：写入数据库成功 → 阻塞 3 秒 → 才调用 Result.success()），用户界面可能因“迟迟收不到完成回调”而误判任务失败，触发重试逻辑，造成重复提交或数据不一致。
- 状态变更（如更新数据库）尽量靠近
Result返回前执行，减少窗口期 - 不要在阻塞段中间发送多次
progress更新，Worker 不保证中间状态实时送达 - 如需反馈进度，改用
setProgressAsync()并确保其调用不依赖阻塞结果
这些风险不是理论问题，而是在线上环境高频出现的隐性故障源。控制阻塞时长、主动响应停止、分离计算与 I/O，是让 Worker 稳定落地的关键动作。
