.NET WebAssembly（如Blazor）中System.IO直接报错，因浏览器沙箱禁止访问本地文件系统，所有File/Directory操作抛PlatformNotSupportedException；WASI环境下需显式挂载目录且依赖host支持，路径、编码、权限等行为与原生差异大。
WebAssembly 里 System.IO 为什么直接报错
因为 .NET WebAssembly 运行时（如 Blazor WebAssembly）根本没权限访问浏览器的文件系统。所有 File.ReadAllText、Directory.GetFiles 调用都会抛出 PlatformNotSupportedException，不是写法问题，是设计如此——浏览器沙箱禁止 JS 或 WASM 直读本地磁盘。
常见错误现象：Unhandled exception rendering component: Operation is not supported on this platform.
- 别试图绕过
AllowUnsafeBlocks或 P/Invoke，WASM AOT 模式下没有libc可调 - 浏览器里唯一合法的“文件”入口是用户主动选择的
<input type="file">，后续只能通过IFormFile或IBrowserFile处理内存副本 - 若需持久化，得走 IndexedDB 封装（如
Blazored.LocalStorage），但那是键值存储，不是文件路径操作
WASI 环境中 System.IO 能用，但得看运行时实现
WASI（WebAssembly System Interface）本身定义了文件 I/O 的 capability（如 wasi_snapshot_preview1::path_open），但 .NET 对 WASI 的支持仍处于实验阶段（.NET 8+ 的 WasiHost），且依赖底层 host 是否启用了对应权限。
使用场景：用 dotnet publish -r wasi-wasm 发布后，在 wasmer 或 wasmtime 中运行，且启动时显式挂载目录（如 wasmer run --dir=. app.wasm）
-
--dir=.是关键，没它File.Exists("config.json")永远返回false - 路径必须是相对路径或绝对路径（如
/data/input.txt），不能用 Windows 风格盘符C:\ -
Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData)在 WASI 下返回空字符串，别依赖它 - 性能上，WASI 文件操作比原生慢，尤其小文件高频读写，建议批量处理或加缓存
跨环境统一读写逻辑的坑：别硬写 #if 预编译
WebAssembly（浏览器）和 WASI（命令行沙箱）虽然都跑 WASM 字节码，但系统能力差异巨大。用 #if NETWASM 区分只解决编译问题，不解决运行时行为差异。
容易踩的坑：
- 同一段代码在 Blazor 里调
File.ReadLines崩溃，在 WASI 里成功，但文件内容却是空的——因为没挂载目录 - 用
FileStream打开文件时，WASI 要求显式传FileAccess.Read，而 .NET 默认是ReadWrite，权限不匹配直接失败 - 编码问题：WASI 默认按 UTF-8 解析路径和内容，但 Windows 用户可能传 GBK 编码的文件名，此时
File.ReadAllText会乱码
真正能落地的方案：抽象层 + 显式能力探测
不要让业务代码直接碰 File，而是封装一个 IFileSystem 接口，运行时根据环境注入不同实现。
实操建议：
- 在 WASI 启动时检查
Directory.Exists("/host")，若为false就提前报错，而不是等第一次读文件才崩 - 浏览器端实现用
IBrowserFile+Stream内存缓冲，WASI 端用FileStream，两者都返回Task<stream></stream>统一契约 - 路径拼接永远用
Path.Join，别用字符串拼"/" + name，WASI 对路径斜杠敏感 - 日志里打上
RuntimeInformation.IsOSPlatform(OSPlatform.Create("WASI"))，方便排查环境误判
最麻烦的其实是调试：WASI 环境里没 Console.WriteLine 输出到终端（除非 host 支持 wasitools 日志重定向），打印路径前先确认 Console 是否可用。
