为何Android禁止在主线程执行含IO操作的协程？结合Node.js、Rust异步机制的实践困惑

我平时主要写Node.js和Rust的异步代码，对它们的异步运行逻辑还算熟悉，最近刚上手Android Kotlin的协程，遇到了一个让我摸不着头脑的问题，想捋捋清楚。

先说说我已经熟悉的异步逻辑做个对比：

• 在Node.js里，I/O代码会在和主线程并行的线程池/事件循环中执行，异步代码本身不会真正阻塞主线程——除非你主动调用fs.*sync这种显式阻塞的函数（正常开发里没人会这么干）。等阻塞代码执行完成后，主线程会从并发队列中获取结果，再继续执行后续的逻辑。
• Rust的异步生态里，一般用Tokio这种多线程运行时。它分两个核心线程池：一个是负责调度异步任务后续逻辑的调度池——这个池依赖协作式调度，绝对不能用来跑阻塞代码；另一个是专门的「工作池」，用来处理阻塞I/O（那些不支持可轮询系统调用的操作）或者CPU密集型任务。这套逻辑其实和Node.js很像，只不过是用多个线程来轮询任务/futures。而且Rust支持真多线程，CPU密集型代码只要扔去工作池，就能在同一个进程内高效运行。

但到了Android Kotlin这里，我的认知好像失灵了：
比如用Room（Android官方的SQLite3封装库）定义的suspend函数，要是在主线程通过lifecycleScope.launch {}去await，有时候会直接触发运行时崩溃。我本来默认认为，这类涉及I/O的阻塞代码会被自动调度到其他线程执行，结果再回调给主线程的协程运行时，但显然实际逻辑不是这样。

现在我只能用withContext(Dispatchers.IO) {}把这些Room的suspend函数包起来，才能避免崩溃。但根据我之前的理解，withContext(Dispatchers.IO)本来就是用来把真正的阻塞代码调度到工作线程的，对吧？

现在我有几个疑惑：

1. 是不是Android（或者说Kotlin协程）把我之前熟悉的异步概念给混淆了？
2. 会不会Room的suspend函数其实是用阻塞函数实现的，协程会立刻resolve，加个suspend修饰符只是为了符合协程的语法规范，实际上根本没做异步处理？
3. 还有个更诡异的点：有时候在主线程跑这些suspend函数又不会崩，好像存在某种不确定性，这又是为什么？

内容来源于stack exchange