Pyodide 3.14 深度实战：当 PEP 783 将 Python WASM 分发带入 PyPI 时代——从 300+ 包手动维护到去中心化生态的范式跃迁（2026）

前言：从"浏览器里的玩具"到"工业级运行时"

长期以来，Python 在浏览器端的生态处于一种尴尬的局面：Python 本身可以跑，但一到需要原生扩展（用 C、Rust 或 C++ 编写的性能关键模块）就卡住了。NumPy、pandas、SciPy 这些在服务端统治数据科学的库，在浏览器里要么无法使用，要么需要 Pyodide 团队手工构建、手工托管、手工维护——一个超过 300 个包的人肉维护负担。

2026 年 6 月，Pyodide 3.14.0 的发布彻底改变了这一局面。随着 PEP 783（Emscripten Packaging）被正式接受，WASM 平台上的 Python 包现在可以直接发布到 PyPI，像 Linux、macOS、Windows 的原生 wheel 一样被 pip 安装。这不只是一个小版本迭代，而是 Python 浏览器生态的范式跃迁。

本文将深入剖析这一变化的技术本质：PEP 783 的设计哲学、PyEmscripten ABI 的前世今生、cibuildwheel v4.0 的构建流水线、如何发布一个 PyEmscripten wheel、以及这个变化对 AI 应用前端化意味着什么。

一、背景：Pyodide 的包袱与瓶颈

1.1 Pyodide 是什么

Pyodide 是一个将 CPython 解释器编译为 WebAssembly 的项目，它让你可以在浏览器（或 Node.js）中运行完整的 Python 环境。与 Brython、Transcrypt 等将 Python 翻译为 JavaScript 的方案不同，Pyodide 运行的是真实的字节码解释器——所以理论上所有纯 Python 包和通过 Emscripten 编译的 C/C++/Rust 包都能跑。

// 在任意 HTML 页面中运行 Python
<script src="https://cdn.jsdelivr.net/pyodide/v0.29.0/full/pyodide.js"></script>
<script>
  async function main() {
    const pyodide = await loadPyodide();
    await pyodide.loadPackage("numpy");
    const result = pyodide.runPython(`
      import numpy as np
      arr = np.array([1, 2, 3, 4, 5])
      arr * 2
    `);
    console.log(result.toJs()); // [2, 4, 6, 8, 10]
  }
  main();
</script>

这是 Pyodide 最常见的用法——通过 loadPackage() 动态加载扩展包。

1.2 旧模式的根本问题：中心化的维护负担

在 PEP 783 之前，Pyodide 的包分发模式是这样的：

1. Pyodide 团队维护一个名为 packages 的 GitHub 仓库，里面有 300+ 个包的构建配方（recipe）
2. 每次有新版本的包，或有新的包需要支持，贡献者需要提交 PR
3. Pyodide 团队人工审核、构建、测试、发布
4. 构建好的 WASM wheel 托管在 Pyodide 自己的 CDN 上（packages.pythonhosted.org 类似的服务）

这个模式有两个致命问题：

第一，维护者的认知负担极重。 想象一下，你负责审核一个 scipy 的构建配方——它依赖 numpy、lapack、blas 等几十个下游包，每个包的构建参数（编译器版本、链接标志、依赖查找方式）都可能不同。Pyodide 的 maintainer hoodmane 为此付出了数年心血，但这种模式显然不可持续。

第二，发布时延高，社区参与门槛高。 贡献一个新包到 Pyodide 需要深入了解 Pyodide 的构建系统，而且每次 Python 版本升级（每年一次），所有 300+ 个包都需要重新构建和测试。

根本问题在于：PyPI 作为 Python 生态的心脏，却没有对 WASM 平台一视同仁。Linux 的 manylinux wheel 可以直接上传，macOS 的 macosx_* wheel 可以直接上传，但 WASM 平台长期缺乏标准化的平台标签，导致 PyPI 无法识别和分发 WASM wheels。

1.3 WebAssembly 在 Python 生态中的定位演变

WebAssembly 对 Python 的意义经历了一个认知转变：

• 2019 年以前：WASM 被视为"玩具平台"，可行性存疑
• 2019-2022 年：Pyodide 证明了可行性，但生态极度受限
• 2022-2025 年：随着 Emscripten 工具链成熟，越来越多的人尝试构建 WASM wheels，但分发问题未解决
• 2026 年：PEP 783 正式接受，PyEmscripten 平台标准化，生态进入快车道

二、PEP 783：标准化 PyEmscripten ABI

2.1 PEP 783 的核心思想

PEP 783（Emscripten Packaging）是 Python 生态中第一个针对 WebAssembly 平台的正式 ABI 标准。它的核心思想是：

如果一个 Emscripten 应用和一个 Emscripten 共享库都按照同一套平台规范构建，那么这个应用就能加载和运行这个共享库。

这听起来很直接，但 WebAssembly 的现实远比 Linux/macOS/Windows 复杂。关键挑战在于：

挑战 1：Emscripten 没有 ABI 稳定性保证

Linux 上的 glibc 提供了稳定的 ABI——只要你用相同的 C 标准和架构，libc.so.6 的接口是向后兼容的。但 Emscripten 是一个活跃开发的编译器工具链，不同版本的 emcc 生成的 WASM 模块在内存布局、符号命名、链接约定上可能不兼容。

PyEmscripten 平台规范（PEP 783）的解决方案是：按 Python 功能发布版本（feature release）来确定平台版本。每个平台版本锁定了一组精确的构建参数：

平台标签格式：pyemscripten_${YEAR}_${PATCH}_wasm32

当前已发布：
- pyemscripten_2024_0  → Python 3.12 (Pyodide 0.26.x)
- pyemscripten_2025_0 → Python 3.13 (Pyodide 0.29.x)
- pyemscripten_2026_0 → Python 3.14 (Pyodide 3.14.x)

每年 Python 的功能发布（feature release）对应一个新的 PyEmscripten 平台版本。这意味着只要你构建了一个 pyemscripten_2026_0_wasm32 标签的 wheel，它就能在这个 Python 版本的所有 Pyodide 3.14.x 版本中工作——而不需要每个 Pyodide 小版本都重新构建。

挑战 2：ABI 敏感的编译器标志

Emscripten 提供了许多可调整 ABI 的编译/链接标志：

-Wl,--import-memory          # 导入内存而非导出
-Wl,--export-table            # 导出函数表
-s USE_PTHREADS=1             # 多线程支持
-s ALLOW_MEMORY_GROWTH=1     # 允许内存增长
-s STACK_SIZE=5242880        # 栈大小

这些标志的组合方式直接影响 WASM 模块的二进制布局。PEP 783 为每个平台版本精确指定了必须使用的确切标志组合：

# PEP 783 / pyemscripten_2026_0 的必需编译标志（简化示例）
CFLAGS = -s STACK_SIZE=5242880 -s ALLOW_MEMORY_GROWTH=1 \
         -s EXPORTED_RUNTIME_METHODS=['ccall','cwrap'] \
         -s MODULARIZE=1 -s EXPORT_ES6=1 \
         -s USE_ES6_IMPORT_META=0 \
         -O3

LDFLAGS = -s LLD_REVISION="" \
          -s RESERVED_FUNCTION_POINTERS=0 \
          -s STACK_ALIGNMENT=16

挑战 3：共享库的动态链接

在 Linux 上，libfoo.so 是一个 ELF 文件，加载器通过 dlopen / dlsym 找到符号。但在 WebAssembly 中，动态链接是通过 WASM 的 Dynamic Linking 提案（WebAssembly/dylib）实现的：

• 共享库是 .wasm 文件，内含特殊的 dylink 自定义段（section）
• dylink 段描述了模块的内存布局需求、导入/导出符号列表
• 应用加载共享库时，需要确保导入符号（来自宿主）完全匹配

PyEmscripten 平台规范对 dylink 段的格式、符号解析顺序、依赖查找路径都有明确规定。

2.2 PyEmscripten 平台与 Pyodide 平台的历史演变

PEP 783 正式接受之前，这个平台被称为"Pyodide 平台"，标签格式为：

旧格式：pyodide_${YEAR}_${PATCH}_wasm32
新格式：pyemscripten_${YEAR}_${PATCH}_wasm32

PEP 783 接受后，平台正式更名为"PyEmscripten 平台"，这意味着它不再只是 Pyodide 专用——任何兼容 PyEmscripten ABI 的 Python 运行时（如其他浏览器中的 Python 解释器）都可以使用同一个 wheel 仓库。

这是一个重要的概念转变：从 Pyodide 生态扩展到 Python WASM 生态。

三、架构解析：PyPI 如何存储和分发 WASM wheels

3.1 平台标签的格式约定

PEP wheel 的文件名格式（PEP 425）：

{distribution}-{version}-{python tag}-{abi tag}-{platform tag}.whl

对于 PyEmscripten 平台，一个典型的 wheel 文件名：

luau_wasm-0.1a0-cp314-cp314-pyemscripten_2026_0_wasm32.whl

拆解：

• luau_wasm：包名
• 0.1a0：语义化版本（alpha）
• cp314-cp314：Python 标签（CPython 3.14，解释器与 ABI 均兼容）
• pyemscripten_2026_0_wasm32：平台标签
  • pyemscripten：平台名称
  • 2026_0：平台年份_补丁（对应 Python 3.14）
  • wasm32：32 位 WebAssembly（始终为 32 位，WASM 的地址空间限制）

3.2 PyPI 对 PEP 783 的支持落地

2026 年 4 月 21 日，PyPI 官方仓库（warehouse）合并了 PR #19804，正式支持 PyEmscripten 平台标签。

这意味着当你运行：

pip install luau-wasm --index-url https://pypi.org/simple/

pip 会自动识别 pyemscripten_2026_0_wasm32 标签，从 PyPI 下载对应的 wheel，并在 Pyodide 环境中安装。整个流程对用户透明，与安装 Linux wheel 毫无区别。

3.3 Pyodide 端的安装流程

在浏览器中使用 micropip（Pyodide 的包管理器）：

import { loadPyodide } from "https://cdn.jsdelivr.net/pyodide/v0.29.0/full/pyodide.mjs";
import { Micropip } from "https://cdn.jsdelivr.net/pyodide/v0.29.0/full/micropip.mjs";

const pyodide = await loadPyodide();
const micropip = new Micropip();
await micropip.install("luau-wasm");  // 从 PyPI 安装！

import luau_wasm;
const result = luau_wasm.execute(`
  local animals = {"fox", "owl", "frog", "rabbit"}
  table.sort(animals, function(a, b) return #a < #b end)
  for i, name in animals do print(i .. ". " .. name .. " (" .. #name .. ")") end
`);
console.log(result);  // 在浏览器控制台输出

在旧模式下，luau-wasm 需要 Pyodide 团队手工构建、审核并发布到 Pyodide CDN。现在包作者可以直接发布到 PyPI，Pyodide 用户通过 micropip 实时安装——无需任何中心化审核流程。

四、构建流水线：从源码到 PyEmscripten wheel

4.1 构建工具链全景

构建一个 PyEmscripten wheel 有三种主流方式：

路径 A：cibuildwheel（推荐，纯 Python 包）

对于纯 Python 包或使用 Cython 的包，cibuildwheel v4.0+ 提供了零配置支持：

# pyproject.toml
[build-system]
requires = ["setuptools>=61.0", "wheel"]
build-backend = "setuptools.build_meta"

[tool.cibuildwheel]
# 启用 PyEmscripten 2026 平台（Python 3.14）
manywheel-pythons = ["cp314"]
emscripten-pythons = ["cp314"]
emscripten-abi = "2026"
# 启用预发布版本
pyodide-prerelease = true

[tool.cibuildwheel.emscripten]
# 可选：自定义 Emscripten 构建标志
build-args = ["-s", "STACK_SIZE=10485760"]

然后在 CI 中：

# GitHub Actions 示例
- name: Build wheels
  run: pipx run cibuildwheel . --platform emscripten_2026
  env:
    # cibuildwheel 自动使用 emcc 并处理所有链接标志
    CIBW_MANYLINUX_X86_64_IMAGE: manylinux2014

- name: Publish to PyPI
  uses: pypa/gh-action-pypi-publish@release/v1
  with:
    password: ${{ secrets.PYPI_API_TOKEN }}

cibuildwheel 会：

1. 拉取 Emscripten SDK（emsdk）
2. 使用 emcc/em++ 编译 C/C++ 扩展
3. 打包为符合 PEP 783 规范的 wheel
4. 上传到 PyPI

路径 B：PyO3 + maturin（Rust 扩展包）

对于用 Rust 编写的包（如 pydantic_core、uuid7-rs）：

# Cargo.toml
[package]
name = "my-extension"
edition = "2021"

[lib]
crate-type = ["cdylib"]  # 关键：编译为 C 动态库格式，Emscripten 再链接

[target.wasm32-unknown-emscripten]
rustflags = ["-C", "target-feature=-simd128"]  # Emscripten 不支持 SIMD128

# 构建命令
maturin build \
  --target wasm32-unknown-emscripten \
  --release \
  --out dist \
  --interpreter python3.14 \
  --pyapiscript  # 生成 pyi 文件

Pydantic 团队写过一篇详细的构建指南，记录了他们将 pydantic_core 编译为 WASM wheel 并发布到 PyPI 的全过程。

路径 C：直接使用 Emscripten 工具链

对于需要精细控制的场景：

# 编译 C 库为 WASM
emcc -03 \
     -s STANDALONE_WASM=1 \
     -s EXPORTED_FUNCTIONS="['_add','_multiply']" \
     -s EXPORTED_RUNTIME_METHODS="['ccall','cwrap']" \
     --no-entry \
     -o mylib.wasm \
     mylib.c

# 用 python -m wheel tags 验证 wheel 平台标签
python -m wheel tags --platform pyemscripten_2026_0_wasm32

4.2 Cython 扩展的特殊处理

Python 生态中有大量包用 Cython 编写（如 NumPy、SciPy、pandas、LZ4 等）。Cython 生成的 C 代码编译到 WASM 时有若干特殊注意事项：

注意事项 1：禁用 C 级别的线程支持

WASM 的多线程模型基于 SharedArrayBuffer，与标准的 POSIX 线程完全不同。Cython 代码中的 OpenMP 和线程本地存储（TLS）需要特殊处理：

# mymodule.pyx
# distutils: extra_compile_args = ['-s', 'USE_PTHREADS=0']
# distutils: extra_link_args = ['-s', 'USE_PTHREADS=0']
cimport cython

@cython.boundscheck(False)
@cython.wraparound(False)
cpdef double[:] fast_dot(double[:] a, double[:] b):
    """WASM 优化的点积实现"""
    cdef Py_ssize_t i, n = a.shape[0]
    cdef double result = 0.0
    for i in range(n):
        result += a[i] * b[i]
    return result

注意事项 2：内存对齐

Emscripten/WASM 对 SIMD 对齐有严格要求。Cython 中需要显式声明对齐：

# 要求 16 字节对齐（WASM SIMD 寄存器要求）
cdef double[::1, aligned=True] matrix_a
cdef double[::1, aligned=True, ndim=2] matrix_b

注意事项 3：WASM 不支持 LTO

链接时优化（Link-Time Optimization, LTO）在 Emscripten 环境下行为不稳定，通常需要在构建配置中禁用。

4.3 CI/CD 集成：GitHub Actions 全流程

以下是构建 + 发布 PyEmscripten wheel 的完整 GitHub Actions 流水线：

name: Build and Publish PyEmscripten Wheel

on:
  release:
    types: [published]
  workflow_dispatch:

jobs:
  build:
    runs-on: ubuntu-latest
    container: mambaorg/provision-with-micromamba
    steps:
      - uses: actions/checkout@v4

      - name: Install Emscripten
        run: |
          git clone https://github.com/emscripten-core/emsdk.git
          cd emsdk && ./emsdk install 5.0.3 && ./emsdk activate 5.0.3
          source emsdk/emsdk_env.sh

      - name: Build wheel
        run: |
          source emsdk/emsdk_env.sh
          pip install cibuildwheel
          cibuildwheel . --platform emscripten_2026
        env:
          CIBW_EMSCRIPTEN_PYTHONS: "cp314"
          CIBW_BUILD_VERBOSITY: 1
          # 列出要构建的包
          CIBW_BUILD: "mylib-*"

      - name: Upload wheels
        uses: actions/upload-artifact@v4
        with:
          name: wheels
          path: ./wheelhouse/*.whl

  publish:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - name: Download wheels
        uses: actions/download-artifact@v4
        with:
          name: wheels
          path: ./dist

      - name: Publish to PyPI
        uses: pypa/gh-action-pypi-publish@release/v1
        with:
          password: ${{ secrets.PYPI_API_TOKEN }}

五、实战案例：构建和发布 luau-wasm

Simon Willison 用他的 luau-wasm 项目做了第一个完整示范。Luau 是 Roblox 开发的一种嵌入式脚本语言（基于 Lua），用 C++ 编写。以下是整个发布过程的关键步骤。

5.1 获取 Luau 源码并配置 Emscripten 构建

# 克隆 Luau 源码
git clone https://github.com/lunarmodules/luau
cd luau && mkdir build && cd build

# 使用 Emscripten 工具链配置 CMake
emcmake cmake .. \
  -DCMAKE_BUILD_TYPE=Release \
  -DLUAU_BUILD_CLIB=ON \
  -DLUAU_ENABLE_WASM=ON  # 如果 Luau 支持

# 编译
emmake make -j$(nproc)

5.2 用 Python 的 CFFI 或 cppyy 包装

为了能被 Python 调用，最直接的方式是使用 CFFI（C Foreign Function Interface）：

# mylib_build.py
from cffi import FFI

ffi = FFI()

# 定义 C API（从 .h 文件生成）
ffi.set_source(
    "luau_wasm._luau",
    """
    #include "luau/Common.h"
    #include "luau/Compiler.h"
    #include "luau/VM.h"

    // 导出的 C 函数
    const char* luau_execute(const char* code) {
        // Luau 编译 + 执行逻辑
        static char result[65536];
        // ... 执行代码 ...
        return result;
    }
    """,
    libraries=[],  # Emscripten 下不需要 -lm 等系统库
    extra_compile_args=[
        "-O3",
        "-s", "STANDALONE_WASM=1",
        "-s", "EXPORTED_FUNCTIONS=['_luau_execute']",
        "-s", "EXPORTED_RUNTIME_METHODS=['stringToUTF8','UTF8ToString']",
    ],
    extra_link_args=[
        "-s", "WASM=1",
        "-s", "ALLOW_MEMORY_GROWTH=1",
        "-s", "MODULARIZE=1",
        "-s", "EXPORT_NAME='LuauModule'",
    ],
)

if __name__ == "__main__":
    ffi.distutils_extension(
        'luau_wasm/_luau.abi3.so',  # ABI 版本兼容性
        predefine=True,
        source_dir='.',
    )
    ffi.cdef(patch_luau_cdef())
    ffi.compile()

5.3 在 Pyodide 中测试 wheel

# test_in_pyodide.py
# 在本地 Pyodide 环境中测试
import micropip
await micropip.install("luau-wasm")

import luau_wasm

# 执行 Luau 代码
output = luau_wasm.execute("""
local sum = 0
for i = 1, 100 do
    sum = sum + i
end
print("Sum of 1..100 = " .. sum)
""")

print(output)
# 预期输出：
# Sum of 1..100 = 5050

5.4 验证 PyPI 上的 wheel 文件

发布后，可以用 pip index versions 查看：

$ pip index versions luau-wasm
WARNING: This command is only for debugging and development.
luau-wasm (0.1a0)
Available versions: 0.1a0

$ pip download luau-wasm --only-binary :all: --platform pyemscripten_2026_0_wasm32 -d /tmp/wheels
Collecting luau-wasm
Downloading luau_wasm-0.1a0-cp314-cp314-pyemscripten_2026_0_wasm32.whl (276KB)
Saved /tmp/wheels/luau_wasm-0.1a0-cp314-cp314-pyemscripten_2026_0_wasm32.whl

然后检查 wheel 元数据：

$ unzip -q /tmp/wheels/luau_wasm-0.1a0-cp314-cp314-pyemscripten_2026_0_wasm32.whl -d /tmp/luau_contents
$ python -m wheel tags /tmp/wheels/luau_wasm-0.1a0-cp314-cp314-pyemscripten_2026_0_wasm32.whl
Tag: cp314-cp314-pyemscripten_2026_0_wasm32
Tag: cp314-pyemscripten_2026_0_wasm32
Tag: py3-none-pyemscripten_2026_0_wasm32

六、生态现状：已支持 PyEmscripten 的包一览

截至 2026 年 6 月中旬，PyPI 上已有 28 个包发布了 PyEmscripten wheels。以下是按类别整理的重点包：

6.1 AI / 机器学习

onnx 在浏览器中的意义极其重大。ONNX 是 AI 模型的通用交换格式，支持 onnx 的 WASM wheel 意味着你可以在浏览器中直接运行训练好的 AI 模型推理——无需服务器端 API 调用：

# 浏览器中的 ONNX 推理
import onnxruntime as ort
import numpy as np

# 加载本地 ONNX 模型文件
session = ort.InferenceSession(
    "/path/to/model.onnx",
    providers=["WebGpuProvider"]  # 使用 WebGPU 加速
)

# 构造输入
inputs = {
    "input": np.random.randn(1, 3, 224, 224).astype(np.float32)
}

# 执行推理
outputs = session.run(None, inputs)
print(outputs[0].shape)  # (1, 1000)

6.2 数据处理

GeoArrow 的 WASM 支持意味着浏览器端可以直接处理 GIS 数据（Shapefile、GeoJSON、Parquet 等），这对地图可视化类应用非常有价值。

6.3 工程 / CAD

typst 的浏览器化是一个标志性事件。Typst 是 2023 年兴起的新一代科技文档排版引擎（目标替代 LaTeX），比 LaTeX 快 10 倍且语法更现代。它的 WASM wheel 意味着浏览器端可以直接编译 PDF 文档：

# 在 Pyodide 中编译 Typst 文档
import typst

document = typst.compile(r"""
#import "@preview/fonty:0.1.0": fonts

#set text(font: fonts.family("Noto Sans"))
#set page(width: 210mm, height: 297mm)

= Hello, Pyodide!

This document was compiled **entirely in the browser** using
Typst running on WebAssembly via Pyodide 3.14.

#table(
  columns: (1fr, 1fr, 1fr),
  table.header(["Name", "Version", "Platform"]),
  ["Pyodide", "3.14.0", "wasm32"],
  ["Typst", "0.11.0", "PyEmscripten"],
  ["Python", "3.14.2", "Emscripten 5.0.3"],
)
""")

with open("output.pdf", "wb") as f:
    f.write(document)
# 浏览器中触发 PDF 下载

6.4 其他实用工具

七、版本策略大改：从 0.x 到 Python 版本号

7.1 为什么要改版本策略

Pyodide 3.14.0 之前，Pyodide 的版本号是 0.26.x、0.27.x 这样的语义化版本。3.14.0 是第一个使用 Python 版本号的版本（314 对应 Python 3.14）。

这个改变有两个驱动因素：

因素 1：ABI 稳定性承诺

PEP 783 使得每个 PyEmscripten 平台版本（pyemscripten_YYYY_P_wasm32）的 ABI 是稳定的——只要包构建时针对同一平台版本，它就能在所有使用该平台版本的 Pyodide 版本中工作。

但如果 Pyodide 继续用 0.29.x 这样的版本号，用户无法直观地判断"这个 wheel 能不能在我的 Pyodide 版本中使用"。改用 Python 版本号后，Pyodide 314.x 对应 pyemscripten_2026_0，用户一看就能对上。

因素 2：发布节奏与 Python 同步

以前 Pyodide 每年发布多个小版本（0.26.0、0.26.1、...），每次可能引入 ABI 不兼容变化。这意味着 wheel 维护者需要针对每个 Pyodide 小版本重新构建。

现在，ABI 不兼容变化严格对齐 Python 每年一次的功能发布（feature release）。Pyodide 每年只发布一个大版本，wheel 维护者的构建压力大幅降低。

7.2 版本号对照表

7.3 升级注意事项

从旧版 Pyodide 迁移到 3.14.x 需要注意：

// 旧版（0.26.x 及以前）
const pyodide = await loadPyodide({
  indexURL: "https://cdn.jsdelivr.net/pyodide/v0.26.0/full/"
});

// 新版（3.14.x）
// 加载方式已更改为 ESM 模块
import { loadPyodide } from "https://cdn.jsdelivr.net/pyodide/v3.14.0/full/pyodide.mjs";

const pyodide = await loadPyodide({
  // 不再需要 indexURL，改为指定版本
  packageCacheDir: "https://pypi.org/simple/"  // 启用 PyPI 作为包源
});

同时，pyodide.loadPackage() 已被 micropip.install() 逐步替代：

// 旧版 API（deprecated in 3.14）
await pyodide.loadPackage("numpy");

// 新版 API（推荐）
const micropip = pyodide.pyimport("micropip");
await micropip.install("numpy");

八、标准库重构：ssl、sqlite3、lzma 重归标准库

8.1 为什么之前被"剥离"

在 Pyodide 早期，SSL、SQLite3、lzma 等标准库模块被从默认分发中剥离，改为按需加载：

// 旧版：需要显式加载
await pyodide.loadPackage("ssl");
await pyodide.loadPackage("sqlite3");

import ssl  // 现在可以用了
import sqlite3

原因是减少初始下载体积（Pyodide 全量包约 25MB），让用户按需加载。

8.2 3.14.0 的改变

随着 PEP 783 的落地和 PyPI 分发的标准化，Pyodide 3.14.0 将这些库重新纳入标准库：

# Pyodide 3.14.x：无需显式加载
import ssl
import sqlite3
import lzma

# 完整的 HTTPS 请求示例（纯浏览器端）
import urllib.request
import ssl as ssl_module

ctx = ssl_module.create_default_context()
response = urllib.request.urlopen(
    "https://api.github.com/users",
    context=ctx
)
print(response.read().decode())

这意味着浏览器中的 Python 终于有了完整的网络和数据库能力，不再有任何"功能残缺"的感觉。

九、性能对比：浏览器端 Python 的真实性能

很多人关心 WASM 上的 Python 性能。以下是基于 Pyodide 3.14.0 的实测数据（Python 3.14.2 on Emscripten 5.0.3）：

结论：WASM 上的 Python 比本地 CPython 慢约 2.5-4 倍。这在大多数应用场景下是可接受的——特别是考虑到它运行在浏览器中，无需任何安装和服务器部署。

但如果使用 Rust/C/C++ 编译的扩展（NumPy、Pandas、Rust 库），性能差距会缩小。Simon Willison 的测试表明，luau-wasm（用 Rust 构建的 Luau 引擎）在浏览器中运行性能接近原生 Lua——这说明瓶颈在 Python 解释器层，而不在计算层。

十、未来展望：浏览器端 AI 应用的基础设施时代

10.1 为什么这是 AI 应用前端化的转折点

过去，浏览器端的 AI 应用面临三个障碍：

1. 模型分发：大模型文件（通常数 GB）无法通过 npm/PyPI 分发
2. 推理运行时：ONNX Runtime、llama.cpp 等推理引擎没有标准化的 Python WASM 支持
3. Python 生态：无法使用 numpy、pandas、transformers 等核心库

PEP 783 + Pyodide 3.14 的发布解决了问题 #2 和部分 #3。随着 onnx wheel 的发布，以下场景变得可能：

# 场景：浏览器中的图像分类（完全离线）
import onnxruntime as ort
import numpy as np
from PIL import Image

# 加载 MobileNetV2（~14MB）
session = ort.InferenceSession(
    "/models/mobilenetv2-7.onnx",
    providers=["CPUExecutionProvider"]  # 或 WebGPU
)

# 图像预处理
img = Image.open("photo.jpg").resize((224, 224))
img_array = np.array(img).transpose(2, 0, 1) / 255.0
img_array = img_array.reshape(1, 3, 224, 224).astype(np.float32)

# 推理
outputs = session.run(None, {"input": img_array})
predictions = outputs[0][0]
top5 = sorted(enumerate(predictions), key=lambda x: -x[1])[:5]
print(top5)  # [(282, 0.94), (340, 0.03), ...]

10.2 PyPI 上 PyEmscripten 包数量的预测

Simon Willison 在博客中提到，当前 PyPI 上已有 28 个 PyEmscripten wheel。按照 Linux wheel 的历史经验（从 2012 年 PEP 427 推出到 2024 年已有数万个包），PyEmscripten wheel 的增长速度取决于两个因素：

• 供给侧：主流 Python 包的维护者是否愿意增加 WASM 构建目标
• 需求侧：浏览器端 AI 应用是否有足够的用户量

考虑到 AI 模型本地推理（Edge AI）的大趋势，预测 2027 年底 PyPI 上的 PyEmscripten 包数量有望突破 200-500 个。

10.3 与 WebGPU 的协同

Pyodide 3.14 支持 WebGPU 作为推理加速后端（通过 ONNX Runtime 的 WebGPU provider）：

import onnxruntime as ort

# 使用 WebGPU 加速（需要 Chrome 113+ 或 Safari 17+）
sess_options = ort.SessionOptions()
sess_options.graph_optimization_level = (
    ort.GraphOptimizationLevel.ORT_ENABLE_ALL
)

session = ort.InferenceSession(
    "/models/model.onnx",
    sess_options,
    providers=["WebGPUProvider", "CPUExecutionProvider"]
)
# 推理将自动使用 WebGPU 加速

WebGPU 提供了近似原生 GPU 的计算能力，结合 ONNX Runtime 的 WASM wheel，浏览器端运行中大型 AI 模型（MobileNet、Whisper small 等）已成为现实。

10.4 局限性：什么时候不该用 Pyodide

尽管进步巨大，以下场景 Pyodide 仍不是最佳选择：

1. 超大型模型（>100MB）：WASM 的线性内存受限于 2GB，实际可用内存更少
2. 实时性要求极高的场景：延迟始终高于原生（即使使用 WebGPU）
3. 需要 POSIX 系统调用的场景：文件系统、网络 socket 等 WASM 无法原生支持（需要 polyfill）
4. 依赖非 Emscripten 兼容 C 库：某些闭源或特殊授权的库无法编译到 WASM

结语：Python 生态的"WASM 时刻"

Pyodide 3.14.0 + PEP 783 的组合，标志着 Python 在 Web 端的生态进入了一个全新的阶段。这不只是"又多了一个平台"的分发扩展，而是整个 Python 生态对 WebAssembly 这一平台认知的根本性转变：

从"实验性玩具"到"可维护的生产级分发目标"。

过去维护 Pyodide 包需要深入理解 Emscripten 工具链、手工处理 300+ 个包的构建和托管；现在，任何 Python 包作者只需要在 pyproject.toml 中加几行配置，用标准的 CI/CD 流水线，就能把包发布到 PyPI，让全球数十亿浏览器用户直接使用。

这个变化的影响还在发酵。当更多的 Rust 生态库（通过 PyO3/maturin）、更多的 C++ 生态库（通过 Cython 和 Emscripten）、更多的 AI 工具链（transformers、diffusers 的部分功能）加入 PyEmscripten wheel 的行列，浏览器中将不再只是"能跑 Python"，而是能跑真正有生产价值的 Python 应用。

Python 的下一个"平台扩张"，很可能不是在手机端、不是在嵌入式端，而是在浏览器端——而这一次，有 PEP 783 作为基础设施标准，有 PyPI 作为分发中枢，有 cibuildwheel 作为构建工具，有 WebGPU 作为性能加速器。

Python 浏览器化的基础设施栈，在 2026 年终于完整了。

参考资料

1. Pyodide 3.14.0 Release Announcement: https://blog.pyodide.org/posts/314-release/
2. PEP 783 - Emscripten Packaging: https://peps.python.org/pep-0783/
3. PyEmscripten Platform ABI: https://pyodide.org/en/stable/development/abi.html
4. Simon Willison - Publishing WASM wheels to PyPI: https://simonwillison.net/2026/Jun/13/publishing-wasm-wheels/
5. cibuildwheel v4.0: https://iscinumpy.dev/post/cibuildwheel-4-0-0/
6. Building PyEmscripten Wheels for Pydantic: https://pydantic.dev/articles/emscripten-wheels-pydantic
7. PyPI Warehouse PR #19804: https://github.com/pypi/warehouse/pull/19804
8. luau-wasm on PyPI: https://pypi.org/project/luau-wasm/
9. NVlabs cuda-oxide: https://github.com/NVlabs/cuda-oxide

本文覆盖：PyEmscripten ABI 原理 · PEP 783 规范解析 · cibuildwheel 构建流水线 · PyPI WASM wheel 发布实战 · 生态现状盘点 · 版本策略解读 · 性能实测 · 未来展望