# 1. Wasm 在云原生基础设施的定位中 containerd wasm shim（runwasi）以及 Wasm 容器与 OCI 容器在启动速度/资源占用/安全隔离上的对比 A Wasm 与 OCI 容器完全等价，无任何差异 B runwasi 让 containerd 能运行 Wasm 工作负载，Wasm 启动更快、资源更省、隔离基于能力模型，与容器互补 ✓ 正确答案 C Wasm 启动比容器慢，资源占用更大 D Wasm 无法在 Kubernetes 中调度
# 2. Wasm 数据面扩展的更新与灰度中代理内 Wasm 过滤器热更新、灰度发布与回滚机制 A Wasm 过滤器更新必须重启代理，无法热更新 B 灰度发布与回滚都不可行，只能一次性全量替换 C Wasm 过滤器支持热更新，配合灰度发布与回滚机制，通过版本管理与监控实现安全的数据面更新 ✓ 正确答案 D Wasm 过滤器更新无需版本管理
# 3. Envoy/Istio 的 Wasm 扩展中 Proxy-Wasm ABI、自定义过滤器开发（Rust/Go/TinyGo）以及与 Lua 过滤器的性能对比 A Wasm 过滤器性能比 Lua 差很多 B Proxy-Wasm ABI 只支持 Lua 一个语言 C Proxy-Wasm ABI 是代理与 Wasm 模块间的标准接口，Wasm 用 Rust/TinyGo 开发，性能通常优于 Lua 且更安全 ✓ 正确答案 D Wasm 过滤器无法在 Envoy 中运行
# 4. Wasm 在边缘计算的应用中 Cloudflare Workers、Fastly Compute、Shopify Functions 的 Wasm 运行时与多租户隔离模型 A 边缘平台用进程隔离每个租户，与 Wasm 无关 B Wasm 冷启动慢，不适合边缘 C Cloudflare Workers/Fastly Compute 等用 Wasm 运行时，通过线性内存隔离与资源限制实现共享进程内的多租户安全隔离 ✓ 正确答案 D 边缘平台无法运行 Wasm 代码
# 5. Wasm 插件化的工程取舍中 Envoy Wasm 过滤器与原生过滤器在性能、调试与供应链风险上的对比 A Wasm 过滤器性能一定优于原生过滤器 B 原生过滤器性能与调试最优但更新需重编译，Wasm 可热更新、隔离好但性能与调试有代价，需权衡取舍 ✓ 正确答案 C Wasm 过滤器供应链风险一定高于原生 D 原生过滤器无法调试
# 6. Wasm 的沙箱模型中线性内存、能力限制与容器（OCI）相比的安全边界差异？ A Wasm 模块可以随意访问宿主内存与系统调用 B 容器默认无权限，与 Wasm 能力模型一致 C Wasm 沙箱与容器沙箱的安全模型完全相同 D Wasm 用线性内存隔离 + 能力限制实现沙箱，默认无系统调用，与容器依赖内核隔离的安全模型不同 ✓ 正确答案
# 7. Wasm 插件供应链安全中插件签名、可信来源与版本校验如何落地 A Wasm 插件无需签名，直接加载即可 B 插件加载无需版本记录 C 插件来源与供应链安全无关 D 通过签名校验、可信来源白名单与版本/哈希校验，配合最小权限与审计，实现 Wasm 插件供应链安全 ✓ 正确答案
# 8. Fermyon Spin 框架中 HTTP/Redis/Kafka 触发器、spin.yaml 应用定义、Serverless Wasm 的冷启动优势（小于 1ms）与适用场景 A Spin 只能处理 HTTP 一种触发器 B Spin 支持 HTTP/Redis/Kafka 触发器，用 spin.yaml 定义应用，Wasm 冷启动快，适合 Serverless/事件驱动场景 ✓ 正确答案 C spin.yaml 与触发器无关 D Wasm 冷启动慢，不适合 Serverless
# 9. WASI 与组件模型的演进中 Preview 2/3 对可移植性与多语言互操作的影响 A WASI Preview 2/3 让 Wasm 更依赖单一平台 B WIT 与接口定义无关 C 组件模型让语言间无法互调 D WASI 与组件模型用 WIT 标准化接口，组件间可互操作，提升可移植性与多语言互操作 ✓ 正确答案
# 10. Wasm 在 Kubernetes 调度中的现状与限制中 Krustlet 项目演进、runwasi 的 CRI 集成、GPU/特殊硬件支持的缺失与生态成熟度评估 A Krustlet 是当前主流 Wasm 调度方案 B runwasi 通过 CRI 让 Kubernetes 调度 Wasm，但 GPU/特殊硬件支持缺失，生态仍在成熟中 ✓ 正确答案 C Wasm 完整支持 GPU 推理 D Wasm 在 Kubernetes 中生态已完全成熟
# 11. Wasm 安全模型中线性内存隔离、WASI 能力限制与宿主系统调用的边界 A Wasm 模块可绕过宿主直接进行系统调用 B Wasm 通过线性内存隔离、WASI 能力限制与宿主系统调用边界实现默认隔离、显式授权、边界拦截的纵深安全 ✓ 正确答案 C Wasm 模块无内存边界检查 D WASI 授予模块所有系统能力，无限制
# 12. Wasm 工作负载的运维中镜像分发、版本更新与可观测性接入如何实现 A Wasm 模块无法用 OCI 镜像分发 B Wasm 更新必须重启整个集群 C Wasm 无法接入可观测性 D Wasm 负载用 OCI 镜像分发、版本化热更新，并通过 OTel 接入指标/日志/trace 实现统一可观测 ✓ 正确答案
# 13. Wasm 性能特征中启动速度、执行吞吐与内存占用相比原生与容器的实测差异 A Wasm 启动比容器慢，内存占用更大 B Wasm 执行吞吐远低于原生 C Wasm 启动极快、吞吐接近原生、内存更省，但 ABI 边界调用有开销 ✓ 正确答案 D Wasm 内存占用与容器相同
# 14. Wasm 的性能与生态中 WASI、组件模型（WIT）与语言支持的成熟度以及何时值得引入？ A Wasm 生态已完全成熟，适合所有负载 B WASI 与组件模型无关 C Wasm 语言支持全部成熟 D Wasm 适合高并发、短命、Serverless/插件/安全多租户负载，但 GPU/重负载与不成熟生态需谨慎，要在匹配优势且生态就绪时引入 ✓ 正确答案
# 15. Wasm 组件模型（Component Model）与 WASI Preview 2 中 wit 接口定义、组件组合以及与 OCI 镜像的打包分发（wasmcloud） A wit 只用于描述系统接口，与组件无关 B 组件模型用 wit 定义接口、组件可组合互操作，并可通过 OCI 镜像打包分发（如 wasmcloud） ✓ 正确答案 C 组件无法组合，只能独立运行 D wasmcloud 不涉及 OCI 分发
# 16. Wasm 运行时的生产运维中 Wasmtime/Wasmer/WasmEdge 选型、资源限制（fuel/epoch interruption）、可观测性（OTel 集成）与安全沙箱配置 A Wasm 运行时无需资源限制，模块可无限执行 B Wasm 安全沙箱无法配置 C Wasmtime 与 WasmEdge 完全等价，无需区分 D 生产运维需选型（Wasmtime/Wasmer/WasmEdge）、用 fuel/epoch 限制资源、接入 OTel 可观测并配置 WASI 沙箱 ✓ 正确答案
# 17. Wasm 运行时选型中 Wasmtime、Wasmer 与 WasmEdge 在性能、安全与生态上的差异 A Wasmtime 安全标准高宜服务端、Wasmer 通用灵活、WasmEdge 偏云原生/边缘/AI，按场景与生态选型 ✓ 正确答案 B Wasmtime 与 WasmEdge 完全一致，无需区分 C WasmEdge 不支持 AI 推理 D 三个运行时性能差异巨大
# 18. WASI-NN 与边缘 AI 推理中 Wasm 运行机器学习模型的现状、性能与限制 A WASI-NN 让 Wasm 直接做模型训练 B Wasm 完整支持 GPU 训练 C WASI-NN 通过标准接口调用推理后端，Wasm 提供轻量隔离与快速部署，适合边缘推理，但 GPU 支持与标准成熟度是限制 ✓ 正确答案 D WASI-NN 与推理无关
# 19. Wasm 实例池化与预热中冷启动优化、快照恢复与实例复用对吞吐的影响 A 预热与池化会增加冷启动时间 B 快照恢复无法加速启动 C 实例无法复用，每次都要新建 D 预热、快照恢复与实例池化/复用消除一次性实例化与编译开销，提升吞吐与降低延迟，但需权衡内存与隔离 ✓ 正确答案
