# WAsmC 技术与生态深度研究（第二轮）

> 研究日期：2026-10-09  ·  归属：yinxiaoshuai / LRIGIT  ·  类型：版本冻结评估与技术定位  ·  范围：WAsmC v0.0.21

**研究对象**：[cbgroom/wasmcrelease](https://github.com/cbgroom/wasmcrelease/tree/v0.0.21)，固定提交 `c888af39c11640644591ff42aeaf8b09f632f651`。这里讨论的是**公开发布的产品表面**和独立执行证据，不推断私有编译器源码实现。所有独立数字都可从 [tpc08 实验汇总 JSON](../data/tpc08-evaluation.json) 追踪到测量语料、引擎、样本范围和限制；[第一轮完整实验报告](tpc08-evaluation.md)保留更详细的边界记录。

## 一页结论

**WAsmC 已经形成可运行的、Core Wasm 优先的语言与计算模块生态。** 其主要优势不是声称所有程序都比 Rust/C/JS 快，而是通过轻量源码、低延迟常驻编译、标准 Core Wasm、显式宿主授权及可验证的 Lib 身份，把 AI Agent 生成的业务逻辑转化为可组合、可替换、可运行的计算单元。

本次冻结快照有三类证据。第一类是发布仓库的**能力及制品声明**（42 个当前 Lib Root、236 个 WIT API 路由、278 个索引条目；Provider 4.9、Std 1.4.1、LibSearch 0.5）。第二类是我们在 tpc08 **实际运行的功能与性能试验**。第三类是**未验证或发生问题的边界**，特别是 Core 类型检查路径和 Std Base64 大输入序列。三者不能相互替代。

结论的应用重心是：**AI Agent 可编译工具、动态规则引擎、可控计算插件、边缘决策模块**。复杂 I/O、跨宿主资源生命周期、移动端设备执行和生产集群运维的验证程度明显低于纯 Core 计算路径。

## 研究仪表板

| 项目 | 结果 | 证据属性 |
|---|---|---|
| 核心编译器制品 | **1,510,219 B**，无 Host imports | 发布字节及核对 |
| 已清点 Lib Roots | **42**，其中 Core Wasm 22、其他适配器 6、源码条目 14 | 当前发布清单与逐项验证 |
| WIT API / 搜索索引 | **236 / 278** | 闭包与索引检查通过 |
| Std 1.4.1 | **73 个 API、9 类资源** | 清单与部分消费者执行，非全量语义覆盖 |
| 126 B 源码热编译 | **15.324 μs P50**，34.427 μs P95 | 常驻编译器、tpc08 实测 |
| 112.3 KB 源码热编译 | **5.141 ms P50**，6.162 ms P95 | 常驻编译器、tpc08 实测 |
| 新 Node 测试进程 | **58.450 ms P50** | 新进程，含测试与装载，非纯编译 |
| V8 内三个内核 | WAsmC/Core Wasm 与 JavaScript **基本持平** | 各 2,000 万轮循环、11 次观测 |
| Native AOT 三内核 | 同批 C 进程耗时接近 | Wasmtime AOT，进程级对照 |
| 负向发现 | **F1** 编译成功却无效 Wasm；**F3** 特定 Base64 输入 trap | 本次独立复现，根因尚未隔离 |

## 1. 技术结构与边界

WAsmC 的使用链路可以拆分为四段：

**WIT-shaped Source → Compiler → Core Wasm → Runtime / Lib / Host**。

语言层不是全功能 Rust：小型程序的包、接口、world 定义以 WIT 风格组织；计算主体沿用容易生成的表达式、固定宽度标量和控制流。当前包含 `u64` 参数、局部变量、结果及相关算术运算；`char`、一般普通源码 async 和直接公开 Map 返回仍不能视为通用能力。结构化类型在原始 Core Host 中表现为扁平数值 lanes，不能假设自动提升为 JavaScript 对象。

编译层包含 ESM、classic、Runtime/Registry bootstrap 与原生 CLI 等消费表面。最终产物是标准 Core Wasm。任何 import 是**能力请求**，应由应用端对模块名、函数名和 ABI 进行精确授权。Lib 的安装或发现不会自动授予时钟、文件、设备或网络权限。

运行层需要明确区分：Node/V8 常驻编译与执行、Wasmi 解释执行、Wasmtime AOT 构建及启动是不同流程。默认 Wasmi CLI 不等价于全部可用部署方式；AOT 则是 Wasmtime 的本机执行制品路径，不是证明编译器拥有独立直接机器码后端。

## 2. Lib 与生态：身份完整不等于行为覆盖

| 层次 | 当前构成 | 本轮核对 |
|---|---|---|
| 托管 Provider | 4.9 | Std/Core managed objects 的底层协作 |
| 标准库 Std | 1.4.1；73 API / 9 类资源 | 三消费者共 7,680 次调用通过；不表示所有 API 全覆盖 |
| Lib 搜索 | 0.5.0 | 42 个 package route + 236 API route = 278 个索引条目 |
| 可执行 Core 制品 | 22 | 摘要匹配且经当前 V8 Wasm 验证；只有部分进一步执行行为测试 |
| 其他原生适配器制品 | 6 | 确认存在；未全量运行 |
| Native-source 条目 | 14 | 只确认条目和源码，不推导 Android/iOS 设备执行已合格 |
| 数据处理 Lib | JSON、CSV、gzip、Data Core/Expr/Relational/Interchange 等 | 选定 JSON/gzip 有实际行为和边界实测；其余不冒充全 API 覆盖 |
| Host 与系统能力 | Clock、Telemetry、TLS、HTTP/1、系统原型等 | Host 权限与 ABI 需依 Lib profile 分别判断 |

生态的核心是**Library-first discovery + exact Root resolve + 明确 Host boundary**：优先搜索已存在的 WIT/Lib，而不是重复生成基础算法；但 Search 只能发现候选，不能代替制品完整性、执行资格或应用授权检查。

有状态 Client/Gateway 和动态 DAG 的本地替换、回滚、快照/状态迁移测试是积极信号，仍需与正式 Lib admission、生产部署、集群一致性和外部效果 exactly-once 断言分离。

## 3. 编译性能：五档源文件与完整成本

测试主机：Intel i7-13700 / 24 逻辑 CPU / Linux WSL2 x86_64 / Node 24.21.0 / V8 13.6.233.17。编译器复用一个 resident `createCompiler()` 实例。每档预热 10 次，采样 31 批；小样本每批 50 次、中档 10 次、大档 1 次。下表 P50/P95 为**批次耗时归一化的每次编译值**，不是严格的服务端单请求尾延迟。

| 测试语料 | 源码大小 | Wasm 产物 | imports | 热编译 P50 | 热编译 P95 | Native CLI build P50 |
|---|---:|---:|---:|---:|---:|---:|
| small_scalar | 126 B | 44 B | 0 | **15.324 μs** | 34.427 μs | 7.097 ms |
| structured_variant | 697 B | 208 B | 1 | 63.975 μs | 88.072 μs | 8.514 ms |
| policy_small | 2,562 B | 733 B | 7 | 138.377 μs | 227.672 μs | 9.337 ms |
| policy_large | 30,995 B | 9,454 B | 14 | 1.597 ms | 2.595 ms | 13.681 ms |
| std_mix_large | 112,300 B | 31,242 B | 36 | 5.141 ms | 6.162 ms | 20.691 ms |

五档的输出摘要均与发布基准匹配。另有 **101 个变化源码**分别编译和执行验证。后四档带外部 imports，不能把输出 Wasm 字节数理解为完整依赖封装或无 imports 程序的大小。

### 新进程、缓存与二进制体积

对最小程序启动 11 个新 Node 测试进程，新进程全过程 **58.450 ms P50**。同组统计的 ESM 导入 15.130 ms、编译器实例化 2.155 ms、首次源码编译 6.339 ms、Wasm Module 构造 0.0737 ms、Wasm Module 实例化 0.0215 ms。**阶段的中位数不能相加当作总中位数**，因为测试还有进程与测试框架成本，且中位数属于不同样本的统计。

小程序 AOT 缓存并非全程一定更快：15 次交替命中/未命中测试 P50 为 **43.640 / 35.945 ms**；大语料的独立流程则显示 **cache hit 52.350 ms vs miss 130.482 ms**。故缓存收益依赖语料和构建路径，不把命中率变成端到端速度保证。

最小 Core 输出 **44 B**，独立 AOT 可执行文件约 **12.39 MB**。两个产物不是相同封装层次；不能用原生执行文件大小直接计算语言生成代码膨胀率。

## 4. 执行性能：三组可校验计算内核

三组测试均为**零 imports 的独立算法**，每组以 100 个小输入核对计算结果，再运行 2,000 万次迭代。JS 与 Wasm 在同一 V8 内交替采样，11 次统计 P50。C 与 AOT 在另一阶段测量，两阶段之间少量百分比差异不构成稳定跨引擎排名。

### V8 内计算主体（P50，毫秒）

| 算法 | Core Wasm / V8 | JavaScript / V8 | 解释 |
|---|---:|---:|---|
| xorshift32 | **24.415** | 24.549 | 几乎持平 |
| branch_mix | **17.526** | 17.897 | 小幅差异，未建立普遍优势 |
| f64_recurrence | **29.873** | 29.945 | 几乎持平 |

### 独立进程级执行（P50，毫秒）

| 算法 | Clang C 进程 | WAsmC / Wasmtime AOT 进程 | WAsmC / Wasmi CLI 进程 |
|---|---:|---:|---:|
| xorshift32 | 29.368 | **29.896** | 131.513 |
| branch_mix | 20.667 | **20.722** | 141.041 |
| f64_recurrence | 31.345 | **31.926** | 59.807 |

结论限定为：AOT 对这些标量/分支/浮点程序的进程级结果和 C 接近，Wasmi CLI 对长循环明显慢于 AOT；并不证明所有 Wasm 算法能达到 C 极限，也不意味着 V8 与 CLI 包含相同的计时边界。

## 5. Lib 真实性能、宿主传输与边界控制

| 工作负载 | 输入 | Lib 调用 P50 | Node 内置基线 P50 | 口径提示 |
|---|---:|---:|---:|---|
| JSON compact | 695 B | 0.0161 ms | **0.00528 ms** | Wasm 包含 UTF-8 复制及输出解码 |
| JSON compact | 11,727 B | 0.2133 ms | **0.07877 ms** | `JSON.stringify(JSON.parse(text))` 为宿主基线 |
| JSON compact | 37,114 B | 0.7597 ms | **0.31999 ms** | 不是全部 JSON 工作负载的比较 |
| gzip compress | 4,096 B | **0.02818 ms** | 0.02823 ms | 输出大小 389 vs 382 B |
| gzip compress | 65,536 B | 0.23045 ms | **0.19850 ms** | 输出大小 1,197 vs 1,344 B；参数不同 |
| Base64 encode | 64 B | **1.88 μs**（驻留） | **0.24 μs** | 驻留值不含跨 Host 的逐字节搬运 |
| Base64 encode | 64 B | **9.78 μs**（逐字节端到端） | **0.24 μs** | Host 资源调用开销不能忽略 |

JSON 与 gzip 的 Lib 多使用独立 Rust 产物；**它们的性能不是 WAsmC 源编译器代码生成能力的单独指标**。Base64 的端到端基准采用逐字节带校验的公开资源 API，不能用作优化批量传输的理论上界。

### 边界正反向测试

- JSON：输入 65,536 B 接受，65,537 B 返回 `input-too-large`；64 层接受，65 层返回 `depth-limit`；65 个 JSON Pointers 返回 `too-many-pointers`。
- gzip：压缩输入 1 MiB 接受，1 MiB + 1 B 拒绝；解压输出 4 MiB 接受，超出 1 B 返回 `output-too-large`。
- u64：独立 **304 项**边界和差分对照通过，包含大于 2⁵³、2⁶³ 与 2⁶⁴−1 的值。
- 重复执行：1 万次小源码编译后，编译器线性内存保持 1,310,720 B；1 万次三字节 Base64 编码与 2 万次 drop 后，Provider 线性内存保持 3,670,016 B。**这只能说明特定小输入路径线性内存稳定，不代表 RSS 或生产负载无泄漏。**

## 6. 已复现的问题登记

### F1 · Core 源编译成功，但输出无效 Wasm

```wasmc
package independent:bool_f64;
interface api {
  run: func() -> bool { return 1.5; }
}
world app { export api; }
```

公开 Core `compileDetailed` 返回成功，生成 **43 B** Wasm，但 `WebAssembly.validate()` 为 `false`，验证错误包含 `expected i32, got f64`；原生 CLI `build` 同样返回退出码 0 但输出无效。带真实托管根的 `instantiateLib` 路径拒绝相同类型不匹配。该问题是 **Core 类型检查/成功状态契约的真实缺口**，不是 Wasm 沙箱逃逸：引擎会拦截无效制品。

### F2 · bool 与整数数值的类型语义不一致

Core 路径可将 `bool` 函数中的整数 `2` 或 `-1` 直接返回为整数，而对应托管路径拒绝。说明不同编译路径对源语义的约束不一致，不能仅凭 Core 物理 i32 lane 判断 bool 语义已被约束。

### F3 · Std Base64 特定字节序列 trap

在 Provider 4.9.0 / Std 1.4.1 的公开 Core 模式中，对第 i 字节 `i & 255` 的序列分别用全新实例测试：64 B 正常，256/512/1,024/2,048/3,072/4,096/8,192/65,536 B 在 `std_base64_try_encode_standard` 抛 `RuntimeError: unreachable`；输入字节 push 均成功。**根因未定位。** 测试同时改变了长度及输入内容，不能称为已证明的“256 B 上限”、UTF-8 问题或全部 Component 路径故障。

### F4 · Node 18 Std 兼容性负向控制

Node 18.19.1 缺失当前 Std 所需的 `function-references`、`tail-call`，前置兼容性检查予以拒绝；Node 24.21.0 通过。该结果不说明 WAsmC 整体不能在 Node 18 工作，只限制依赖当前 Std 特性的执行路径。

## 7. 可用性与场景选择

| 场景 | 当前判断 | 依据和限定 |
|---|---|---|
| AI Agent 即时生成小程序 | **重点适用** | 微秒至毫秒级常驻编译、小型 Core 输出、可检验 imports；仍需验证每个程序 |
| 动态规则引擎 | **重点适用** | 明确分支、标量与结构化值，小型模块可独立替换 |
| 受限插件系统 | **适用** | 标准 Core Wasm 和显式 Host 边界；资源所有权按 Lib SDK 契约处理 |
| 边缘/本地策略执行 | **有潜力** | Core 文件小，宿主成本和实体设备资格需要单独测量 |
| 数据转换管道 | **具备基础** | JSON、gzip 和 Data Lib 存在；未证实普遍吞吐优势 |
| 复杂异步 I/O 与分布式网关 | **研究阶段** | Client/Gateway 与完整设备路径不能被当成已验证生产承诺 |
| 通用大型应用开发 | **并非优先定位** | 语言特性、生态与发行稳定性均不同于 Rust/Go/JS |

## 8. 证据等级、限制与下一轮实验设计

这次从发布库选取了 **40 个测试/示例命令**：24 个返回成功，16 个因缺少精确 refresh receipt、`wasm-tools` 等测试前提没有完成目标用例。这**不等于 40% 产品功能失败**。另外编译器回归、Lib、u64、JSON、gzip 等测试彼此存在覆盖重叠，不能把调用总数相加称为独立行为覆盖率。

本轮直接验证只在 **tpc08 Linux x86_64 WSL2** 上执行，没有固定 CPU 亲和性/频率，未独占主机，未清空系统页缓存。未进行私有编译器源码审计、跨六平台性能复测、移动端实体设备全矩阵或 236 API 全面语义覆盖。生产级并发隔离、长生命周期 RSS、动态外部副作用 exactly-once 仍属于未验证范围。

下一轮应优先把 F1 与 F3 制作成独立的最小化可复现实验，分别隔离输入长度/字节模式，加入 `WebAssembly.validate` 固定质量闸，并将 Core/managed/Component 的能力矩阵整理成按位置可测试的表。若追加跨引擎性能对照，应保持相同输入、执行边界及硬件频率控制，再报告跨平台分布，而非直接引用单机的最快一次。

## 9. 冻结来源与复核入口

- [WAsmC v0.0.21](https://github.com/cbgroom/wasmcrelease/releases/tag/v0.0.21)
- [语言文档 LANGUAGE.md](https://github.com/cbgroom/wasmcrelease/blob/v0.0.21/LANGUAGE.md)
- [Lib 使用边界 LIB.md](https://github.com/cbgroom/wasmcrelease/blob/v0.0.21/LIB.md)
- [本轮实验汇总：tpc08-evaluation.json](../data/tpc08-evaluation.json)
- [第一轮完整实验报告](tpc08-evaluation.md)
- [生态结构 SVG 动画](../assets/wasmc-ecosystem-animated.svg)
- [实验图谱 SVG 动画](../assets/wasmc-performance-animated.svg)

**授权提示：**WAsmC v0.0.21 的发布许可仅涵盖非商业研究，商业和生产用途需要另外取得书面授权；开源状态与使用授权不能混淆。此报告是对固定发布物的独立研究快照，不是官方安全认证或性能 SLA。