题干与适用场景
插件宿主同时运行多个语言编写的组件。旧组件依赖 WASI 0.2 的 wasi:io 资源，新组件希望使用 WASI 0.3 的 async func、stream 和 future。请设计一个处理日志流、远程调用和取消的组件接口，说明宿主如何调度、限流和兼容旧版本。
题目考察异步语义和 ABI 边界，不是把所有函数都标成 async。WASI.dev 将 0.3 描述为加入原生异步并重构接口；Component Model FAQ 说明 wasi:io 被移除，ready 状态由 Component Model 的原语跨边界传播。答案必须区分接口契约、运行时调度和业务副作用。
面试官考察点
强回答会先确认调用是单值结果、持续流还是可取消的长操作，再选择 future、stream 或普通返回值。它能解释为什么 0.2 的 pollable 资源在组件边界形成“sandwich problem”，以及 0.3 如何把等待和唤醒交给运行时。
面试官还看重背压、资源上限、错误分类和版本迁移。只说“异步提高性能”不够；需要说明 stream 的消费速度、future 的完成语义、取消后副作用状态，以及旧组件如何通过适配器运行。
回答前需要澄清的问题
数据是单值还是持续流
确认远程调用只返回一个响应，还是持续输出日志、文件块或事件。单值结果用 future；持续数据用有明确结束信号和容量策略的 stream。若消费者可能暂停，必须定义缓冲上限和生产者行为。
取消是否必须阻止副作用
确认取消发生在排队、执行中还是外部写入之后。组件边界能传播取消请求，但不能替外部系统回滚已经提交的副作用；需要幂等键、查询状态或补偿流程。
迁移是否允许双版本运行
确认宿主是否能同时加载 0.2 与 0.3、旧组件是否必须零改动，以及运行时是否支持边界适配。答案不同会决定采用 side-by-side 运行时、WASI 0.2 到 0.3 adapter，还是一次性切换。
30 秒回答框架
“我先按语义选择原语：一次性远程结果用 future，连续日志用带容量和结束标记的 stream，同步纯计算保持普通函数。WASI 0.3 把就绪和唤醒放进 Component Model 的原生 ABI，避免每个组件各自持有 pollable。宿主仍要设置并发、缓冲、超时和取消策略；取消只保证停止后续工作，外部副作用用幂等状态确认。迁移时保留 0.2 world，通过适配器和兼容矩阵逐步切换。”
分步骤深入解答
第一步：把异步语义写进 WIT world
先定义最小接口，不把所有函数都变成异步。示例使用 WIT 风格伪代码：
package acme:plugin@0.3.0;
interface logs {
record chunk { bytes: list<u8>, end: bool }
export next: func() -> future<chunk>
}
world worker {
import logs;
export run: async func(input: string) -> result<string, failure>;
}future 表示一个最终值，不等于后台任务永远运行；stream 更适合由运行时逐步交付的序列。接口还要写清错误、结束和取消后的状态，否则不同语言生成的绑定会产生不同解释。
第二步：解释 0.2 到 0.3 的边界变化
WASI 0.2 通过 pollable、input-stream 和 output-stream 表达 I/O 就绪。它们作为组件资源时，等待信号需要穿过调用者和被调用者各自的异步层，容易出现资源只在一侧可见的 sandwich problem。WASI 0.3 直接使用 async func、future 和 stream 原语，运行时负责跨组件的就绪传播。
这不是把旧二进制强行改写成新 ABI。官方 FAQ 说明 0.3 运行时可以在 host boundary 将 0.2 imports 映射到 0.3 原语；迁移应保留旧 world，先让适配器承担转换，再逐个升级组件。
第三步：为 stream 建立背压和内存界
生产者不能无限写入。宿主为每个 stream 设置元素数、字节数和等待时间上限；消费者落后时暂停读取或返回明确的过载错误。中间缓冲应按租户和组件隔离，避免一个慢消费者占满运行时内存。对于文件和日志，优先传递块或受控句柄，不把整个对象一次性复制到边界。
第四步：设计 future 的取消与错误
future 完成前，宿主保存操作 ID、截止时间和取消信号。取消应阻止尚未开始的工作，并向执行中的组件发送合作式停止；如果外部服务可能已经写入，状态标记为 UNKNOWN，通过幂等键查询或补偿，而不是直接重试。错误要区分超时、取消、业务拒绝、依赖失败和协议不兼容，便于重试策略分别处理。
第五步：把调度责任留给运行时
组件内部不应各自启动一个隐藏事件循环来等待同一类 I/O。宿主运行时统一管理唤醒、并发和公平性；组件只声明接口和返回结果。同步热路径可以保持普通函数，避免不必要的 task 创建。Bytecode Alliance 的路线文章指出，异步基础设施若侵入同步调用会产生额外开销，因此要测量同步适配器、异步边界和业务计算三部分。
第六步：制定渐进迁移与验证矩阵
发布清单记录 WIT 包版本、WASI 版本、运行时、适配器和组件哈希。矩阵至少覆盖 0.2 组件在 0.3 host、0.3 组件在旧 host 的失败方式、stream 中途取消、超时后未知副作用、慢消费者和重复重连。先影子运行并比较完成率、端到端延迟、缓冲峰值、取消延迟和重试次数，再按组件版本灰度。
高质量示范回答
我不会先把所有接口改成 async。我先确认每个操作的语义：单次远程结果用 future，持续日志用 stream，纯本地计算保持同步。WASI 0.3 的关键变化是把 async func、future 和 stream 放进 Component Model 的原生 ABI，替代 0.2 的 wasi:io pollable 资源；运行时因此能在组件边界传播 ready 和 wake-up。
实现上，我给 stream 设元素、字节和等待上限，消费者变慢就暂停生产或返回过载，不让一个租户耗尽共享内存。future 保存操作 ID 和截止时间；取消能停止未开始工作，执行中的外部写入则进入 UNKNOWN，通过幂等键查询或补偿，不能盲目重试。
迁移保留 0.2 world，用适配器在 host boundary 做映射，先影子运行再按版本灰度。验证矩阵覆盖旧组件、新组件、取消、背压、错误和重复重连；如果运行时或工具链还不支持 0.3，我会延后 world 切换，而不是伪造兼容。
常见错误
- 错误表现 → 把
future当成任意后台任务 → 失败原因 → future 代表一个可完成的结果，生命周期和取消仍需契约 → 修正方法 → 记录操作 ID、截止时间和取消状态。 - 错误表现 → 用无限队列吸收 stream 峰值 → 失败原因 → 慢消费者会把内存压力转成运行时故障 → 修正方法 → 设置字节和元素上限，传播背压或明确拒绝。
- 错误表现 → 说 0.3 会自动回滚外部写入 → 失败原因 → ABI 取消不等于跨系统事务 → 修正方法 → 使用幂等键、状态查询和补偿流程。
- 错误表现 → 直接删除 0.2 world → 失败原因 → 旧组件和工具链可能仍依赖 pollable 资源 → 修正方法 → 通过适配器和兼容矩阵分阶段迁移。
- 错误表现 → 每个组件自建事件循环 → 失败原因 → 调度、取消和公平性无法统一 → 修正方法 → 让运行时拥有 wake-up 和并发预算，组件只声明接口。
追问及应对
追问一：stream 的生产者比消费者快，应该丢数据还是阻塞？
先按数据价值分类。日志可按级别丢弃并记录丢弃计数，财务事件不能静默丢弃，应持久化到有界外部队列并返回背压。无论选择哪种策略，都要把租户、组件和流 ID 写入指标，避免只看到总吞吐。
追问二：future 超时后如何判断是否已经完成？
超时只代表调用方停止等待。宿主保留操作 ID，向依赖查询状态；若依赖没有查询 API，就把结果标成 UNKNOWN，交给人工或补偿任务处理。只有服务契约明确幂等且确认未完成时才重试，不能用网络连接关闭推断事务回滚。
追问三：0.2 组件使用 pollable，0.3 host 如何暴露同样语义？
适配器把 0.2 资源事件映射成 0.3 future 或 stream，但要保留资源关闭、错误和取消语义。先在单组件测试中比较 ready 顺序和 EOF，再验证跨组件组合；如果适配器只能模拟部分行为，应在部署门禁中拒绝依赖缺失的接口。
追问四：如何证明异步改造真的降低成本？
把指标拆成边界适配时间、运行时唤醒次数、缓冲峰值、CPU、内存、端到端延迟和业务完成率，并与同步基线对照。若调用很短且没有并发等待，task 管理和 ABI 适配可能抵消收益，应保留同步接口或合并批量调用。