CoroutineWorker卡在Running状态 仅重启应用可结束的问题咨询

CoroutineWorker 判定任务结束、写入返回Result的核心依据是doWork()方法对应的协程Job完全进入终止状态（isCompleted = true，没有存活的子协程、没有被存活的引用持有阻塞），你遇到的日志打印完成但一直卡在Running状态，90%以上是以下三类问题导致的：

• 协程作用域被异常阻塞/存在未收尾的子任务
  如果你在doWork()里用runBlocking包裹了回调逻辑、自定义CountDownLatch/锁，但是在回调执行完成后没有正确触发锁释放；或者你用了外部生命周期的CoroutineScope（比如GlobalScope、页面/Service持有的自定义Scope）启动上传子任务，哪怕你业务逻辑走完打了return前的日志，只要还有子协程处于活跃状态、或者阻塞块没退出，doWork()对应的协程就根本走不到真正返回Result的步骤。
  最容易踩的场景是自己写回调转协程的逻辑时漏了resume调用，或者子协程被SDK内部持有没触发完成，日志打了但协程本身挂在那没结束。
• 存在未释放的引用/监听器，导致协程Job无法正常回收
  如果在任务执行过程中注册了系统广播、ContentObserver、SDK回调、网络监听器，在逻辑执行完后没有反注册、移除；或者打开的文件流、数据库游标、WakeLock没有在return前关闭释放，这些对象会持续持有协程上下文的引用，导致协程Job一直无法进入完成状态，WorkManager收不到任务结束的信号，就会一直标记为Running。
• WorkManager 版本已知死锁bug
  androidx.work:work-runtime-ktx 的2.7.0、2.7.1版本存在已知的状态同步死锁问题：当CoroutineWorker执行过程中应用退到后台，系统调整进程优先级时，WorkManager内部更新任务状态的锁会被意外持有不释放，这时候哪怕doWork()逻辑全走完，Result也无法写入任务状态数据库，对外就一直显示Running，必须重启应用重置WorkManager的内部状态，重新调度的任务才能正常返回。

• 先排查协程逻辑：所有异步操作必须在doWork()自带的协程作用域内执行，禁止使用外部自定义Scope、GlobalScope启动子任务，所有异步调用必须通过await()/join()确保在return前全部执行完成。回调转协程优先用suspendCancellableCoroutine，并且在invokeOnCancellation里写好资源释放逻辑。
  可以在return前加诊断日志：

  Log.d("UploadWorker", "准备返回，剩余子协程数：${coroutineContext[Job]?.children?.count()}，Job活跃状态：${coroutineContext[Job]?.isActive}")
  

  如果日志显示剩余子协程数大于0，顺着子协程链路找没结束的任务即可。
• 全链路检查资源释放：在return前必须反注册所有动态注册的广播、监听器，关闭所有打开的文件流、数据库连接，释放持有的WakeLock，不要留任何持有当前Worker/协程引用的存活对象。
• 升级WorkManager依赖：如果当前用的是2.7.x版本，直接升级到2.8.1及以上的稳定版本，避开内部死锁bug。不要随意替换doWork()自带的协程上下文中的Job实例，否则会破坏WorkManager对协程生命周期的监听逻辑。

内容的提问来源于stack exchange，提问作者Omar Walid