VSCode本身不运行WASM，真正加载执行依赖本地HTTP服务（如Live Server、Vite）和浏览器；根本原因是浏览器禁止file://协议加载WASM，且要求服务返回Content-Type: application/wasm。
WASM 在 VSCode 中无法加载：根本不是 VSCode 的问题
VSCode 本身不运行 WASM，它只是编辑器。你看到的“运行 WASM”实际是启动本地 HTTP 服务（比如 live-server、esbuild serve 或 python -m http.server），再由浏览器加载 HTML 页面并执行 .wasm 文件。真正卡住你的，是浏览器对本地文件（file:// 协议）的沙盒限制 —— 它直接拒绝加载 WASM 模块，报错类似：Failed to compile WebAssembly module: TypeError: Failed to execute 'compile' on 'WebAssembly': Incorrect response MIME type. Expected 'application/wasm'.
必须用 HTTP 服务，且响应头要正确
浏览器只允许通过 http:// 或 https:// 加载 WASM，且服务器必须返回正确的 Content-Type: application/wasm。常见错误配置：
-
python -m http.server默认不设application/wasm类型，WASM 文件会被当成text/plain返回 → 加载失败 -
live-server0.9.x 及更早版本不识别.wasm后缀 → 需升级到live-server@1.2.2+或手动配置 MIME - Vite / Webpack Dev Server 通常默认支持，但若自定义了
contentBase或静态资源路径，可能漏配 MIME 映射
推荐方案：npx serve -s（自动识别 WASM）、vite（开箱即用）、或用 Python 3.11+ 的 python -m http.server --bind 127.0.0.1:8080 --directory . 并配合 --cgi 或自定义 handler（不推荐）。
Chrome / Edge 启动时禁用安全策略？别试
网上流传的 --unsafely-treat-insecure-origin-as-secure="http://localhost:8080" --user-data-dir=/tmp/chrome-test 方式，仅适用于开发调试特定 insecure origin 场景，对本地 WASM 加载无效。而且 Chrome 120+ 已收紧该 flag 行为，即使加了也大概率被忽略。更危险的是，改浏览器启动参数容易污染日常环境，导致后续 HTTPS 页面异常。
真正安全的做法只有两条：
- 确保服务跑在
localhost（非127.0.0.1有时会触发不同策略，优先用localhost） - 确认
.wasm文件路径在 HTML 中是相对 URL（如./pkg/module.wasm），而非绝对路径或file://路径 - 检查 Network 面板中 WASM 请求的 Response Headers 是否含
Content-Type: application/wasm
VSCode 插件能绕过沙盒吗？不能，但可以帮你少出错
像 Live Server、ESBuild Runner、Vite Runner 这类插件，本质只是封装了命令行服务启动逻辑，并不会修改浏览器行为。它们的价值在于：
- 自动打开
http://localhost:xxxx（而不是file://） - 监听文件变更并热重载（避免手动刷新）
- 部分插件（如 Vite Runner）内置了 WASM MIME 支持，省去手动配置
注意：Code Runner 插件默认不支持 WASM —— 它试图直接执行 .wasm 文件，这是完全错误的用法。WASM 必须通过 JS 的 WebAssembly.instantiate() 或 import 语法加载，不能当脚本直接运行。
最易被忽略的一点：WASM 模块的导入对象（imports）里如果引用了 Node.js API（如 fs、path），哪怕你在浏览器里跑，也会在 instantiate 阶段报 Import not found。这时候不是环境配错了，是模块编译目标选错了 —— 确保你用的是 wasm32-unknown-unknown 或 wasm32-wasi（后者需 WASI polyfill），而不是 wasm32-unknown-emscripten（它依赖 Emscripten runtime）。
