浏览器无法直接访问persistent memory，因其受沙箱与虚拟内存限制；可行方案是前端实时发送快照至后端，由rust+pmem库持久化，再通过http恢复。
浏览器重载间实现原始数据零损耗恢复，不能靠传统 localStorage 或 IndexedDB——它们本质是异步写入、非崩溃安全的文件系统后端，断电或进程强杀时仍可能丢失最后几毫秒变更。Persistent Memory（PMem）本身不直接暴露给浏览器，它属于操作系统和硬件层的字节寻址非易失内存资源。因此，“通过 Persistent Memory 实验性接口”在当前（2026年）浏览器环境中并不存在标准或可行路径。
为什么浏览器无法直接访问 Persistent Memory
现代浏览器运行在沙箱进程中，所有内存访问受 OS 虚拟内存管理约束：
- PMem 设备（如 /dev/dax0.0）需 root 权限映射，浏览器无权直接 open/mmap；
- Web API（包括 WebAssembly 线性内存、SharedArrayBuffer）仅能访问进程私有虚拟地址空间，无法绑定到持久化设备内存区域；
- 即便启用 Linux DAX 模式，也必须由服务端进程（如 Node.js + persistent-memory 库）显式管理 Pool 和 Root，并通过 IPC 或 HTTP 向前端暴露状态，而非让 JS 直接读写 PMem 地址。
可行的替代方案：服务端 PMem + 前端协同恢复
若目标是“重载后还原用户刚输入但未提交的表单、画布状态、编辑器光标位置等原始数据”，真正落地的做法是：
- 前端在每次关键变更（如 input、canvas draw、selectionchange）后，立即向后端发送轻量快照（JSON 或二进制），不等待 submit；
- 后端用 Rust + persistent-memory 库将快照写入 PMem Pool，利用其字节寻址与崩溃安全特性，确保即使进程意外终止，数据也不丢失；
- 页面加载时，前端发起 GET 请求获取最新快照，服务端从 PMem 中原子读取并返回；
- 整个链路延迟可压至亚毫秒级（PMem 百纳秒级访问），远优于磁盘型数据库，且避免了 localStorage 的竞态与刷盘不确定性。
实验性探索边界：WASI 与未来可能性
目前唯一接近“浏览器侧接触 PMem”的路径，是通过 WebAssembly System Interface（WASI）的实验性提案：wasi-pmem（尚未标准化，仅个别 Rust/WASI 运行时原型支持）。它允许 WASM 模块申请一块预配置的 DAX 映射内存页，并用 unsafe 指针直接读写。但这要求：
- 用户浏览器运行在定制 WASI 容器中（非 Chrome/Firefox）；
- 操作系统已将 PMem 设备以 DAX 模式挂载，并授权该容器访问；
- 前端代码完全用 Rust 编译为 WASM，并手动管理指针生命周期——失去 JS 生态与调试能力。
该路径目前仅适用于内网可信环境下的边缘计算原型，不具备 Web 兼容性与部署可行性。
