题干与适用场景
一个 SaaS 平台要允许不同团队交付文件解析、规则计算和数据脱敏插件。插件由 Rust、Go 或 C 编写，运行在多租户服务中；平台要求插件不能任意读主机文件或访问网络，接口升级不能让旧插件全部失效，异常插件可以被停止并回滚。请设计基于 WebAssembly Component Model 的运行时，不绑定某一家 Wasm 引擎。
本题聚焦组件边界和能力治理，区别于“把任意 Wasm 当沙箱执行”的题。回答需要说明 WIT 如何表达接口、Canonical ABI 如何跨语言传递值，以及宿主如何限制导入能力。
面试官考察点
- 能否把 WIT interface、world、package 与组件导入导出映射到部署契约。
- 能否解释 Canonical ABI 解决跨语言布局问题，但不自动解决权限、资源上限或业务兼容。
- 能否设计能力最小化、租户隔离、取消、超时、内存和 CPU 限制。
- 能否用版本化接口、适配器、兼容矩阵和可观测回滚处理插件生命周期。
普通回答只说“Wasm 比容器安全、启动更快”。强回答会把接口、能力、资源、版本和证据拆成可测试的边界。
回答前需要澄清的问题
- 插件是请求内同步调用，还是允许异步任务、流和长时间状态？这决定超时、取消和状态保存方式。
- 插件需要哪些主机能力？文件、网络、密钥和时间都应通过显式导入，而不是隐式获得。
- 接口兼容要求是什么？只保证新增可选字段，还是需要同时运行多个 world 版本？
- 资源预算按请求、插件版本还是租户计算？没有配额维度就无法证明隔离。
30 秒回答框架
“我先用 WIT 定义窄接口和 world，把插件的导入能力与宿主实现分开。组件遵循 Canonical ABI，因此不同语言的字符串、列表和记录可以按统一规则跨边界传递，但 ABI 不等于授权。我在宿主建立能力表，只向每次调用注入经过租户和版本校验的文件、网络或密钥句柄，并设置 CPU、内存、调用深度、输出大小和截止时间。运行时记录组件摘要、接口版本、资源消耗和调用结果；新版本先在隔离租户运行，兼容矩阵和回放通过后再扩大，失败时按版本路由回旧组件并保留审计。”
分步骤深入解答
第一步：把业务契约写成 WIT
为每个稳定能力定义小型 interface，例如 parser.parse、redactor.redact，再用 world 声明组件提供什么、依赖什么。输入输出使用明确的记录、枚举、错误和资源句柄，避免把宿主内部对象地址或数据库连接暴露给插件。
package acme:document@1.0.0;
interface parser {
record document { bytes: list<u8>, content-type: string }
variant parse-error { unsupported, invalid, denied }
parse: func(input: document) -> result<list<string>, parse-error>;
}
world plugin {
export parser;
}第二步：说明 Canonical ABI 的边界
Component Model 为组件定义统一的 Canonical ABI，使不同语言对字符串、列表和复合类型采用可互操作的边界表示。宿主仍要处理线性内存复制、所有权、长度校验和错误映射；“跨语言可调用”不能推导出“输入可信”或“不会耗尽内存”。
第三步：把能力做成显式导入
宿主只实现允许的 WIT imports，例如 blob.read、clock.now 或 http.fetch，每个导入都绑定租户、资源 ID、方法、最大字节数和审计上下文。插件拿到的是短期句柄，不是数据库凭据；宿主在每次调用重新检查状态、配额和取消信号。
第四步：设计隔离与资源预算
运行时为每个调用设置 CPU 指令或时间预算、最大线性内存、栈深度、并发数、输出大小和递归调用限制。超限后取消组件任务并回收实例；对于异步接口，保存可观测的调用 ID 和取消状态，避免宿主线程永久等待。租户预算与插件版本预算分开记录，防止一个租户通过多个插件绕过总量限制。
第五步：处理版本与组合
把 package、interface、world 和组件摘要作为发布身份。新增字段优先使用可选接口或新 world；无法兼容时并行发布 @1 与 @2，由路由层按租户和能力矩阵选择。适配器可以转换旧错误码或字段，但不能掩盖语义变化。组件组合前校验导入、导出、类型和资源所有权，拒绝未满足依赖的组合。
第六步：建立供应链与回滚
存储组件摘要、构建来源、WIT package 版本、签名、依赖和审核结果。加载前验证摘要、签名、允许的导入集合和漏洞策略。新版本先在测试租户和回放流量中运行，比较成功率、输出差异、CPU、内存和尾延迟；异常时把路由权重切回旧摘要，停止新实例，并保留失败输入的脱敏重放记录。
高质量示范回答
“我会把插件当成受版本和能力约束的组件。团队先用 WIT 定义窄的 interface 和 world，组件导出业务函数，宿主实现经过授权的 imports。Canonical ABI 让 Rust、Go、C 生成的组件共享字符串、列表、记录和错误的边界表示，但宿主仍需做长度、所有权和错误校验。
每次调用创建带租户、插件摘要和截止时间的 capability context，只暴露短期资源句柄；文件读取、网络访问和密钥使用都经由宿主策略检查并记录审计。运行时限制 CPU、内存、栈、输出和并发，取消后销毁实例。发布流程验证组件签名、WIT 版本、依赖和导入白名单，先回放再分租户放量。接口能兼容就保持旧 world，破坏性变更并行运行新旧 world；指标或输出差异越过阈值时按摘要路由回滚，而不是重新编译宿主。”
常见错误
- 错误表现：把 Canonical ABI 当作安全边界 → 失败原因：它只规定调用表示和转换，不限制主机能力 → 修正方法：单独设计 imports 白名单和每次调用授权。
- 错误表现：给插件传数据库连接或长期密钥 → 失败原因：泄露后无法按租户和调用撤销 → 修正方法：使用短期、最小权限的宿主句柄。
- 错误表现：只限制模块内存，不限制输出和并发 → 失败原因：插件仍可制造大响应或占满执行槽 → 修正方法：为调用和租户设置完整资源预算。
- 错误表现：升级 WIT 后直接替换所有组件 → 失败原因：旧 world 的语义和错误处理可能不同 → 修正方法：并行版本、适配器和兼容矩阵先行。
- 错误表现：发生异常时重启同一版本并继续放量 → 失败原因：无法区分确定性错误和资源耗尽 → 修正方法：保留摘要、输入类别、资源指标和可审计回滚点。
追问及应对
追问一：组件需要流式处理大文件怎么办？
在 WIT 中定义受限的字节流或分块读取接口，规定最大块、背压、取消和总字节数。宿主不把整文件一次复制到组件内存；每个句柄绑定租户和对象权限，读取结束或超时立即关闭。
追问二：插件要调用另一个插件，如何防止能力扩散？
默认不允许任意组件发现其他组件。宿主先验证目标 world 和版本，再创建只包含必要接口的受限子调用上下文，并把剩余截止时间、租户身份和累计预算向下传递。调用图和深度纳入审计与限额。
追问三：如何证明升级没有改变业务结果？
固定输入样本、边界值、错误和取消场景，分别运行旧新组件并做结构化差异比较。对非确定输出定义等价关系；在线先按租户小流量采样，比较成功率、字段差异、延迟、资源和拒绝原因，达到预设门槛才扩大。