memorymappedfile不是开箱即用的高性能方案，仅适用于跨进程共享内存、高频随机访问或零拷贝ipc；createfromfile卡死源于windows页错误风暴，因默认可写映射+全量扫描触发密集i/o；顺序读应优先用filestream+sequentialscan；映射须分块（如64mb）、跨进程需加global前缀、只读须p/invoke指定page_readonly、32位进程易因地址空间不足崩溃。
MemoryMappedFile 不是“开箱即用”的高性能方案，用错比不用还慢；它只在特定场景下有不可替代价值：跨进程共享同一块原始内存、高频随机访问大文件、或需零拷贝 IPC 的场合。
为什么 CreateFromFile 一读大文件就卡死
不是 .NET Bug，是 Windows 虚拟内存机制被误触发。调用 MemoryMappedFile.CreateFromFile 时，即使传 FileAccess.Read，.NET 默认仍以可写权限映射整个文件。真正卡住的点在于：一旦你用 Span<byte>.GetPinnableReference()</byte> 或 Unsafe.ReadUnaligned 扫一遍视图，就会强制提交所有虚拟页为物理页，引发密集页错误 + 磁盘 I/O。
- 顺序读大文件，优先用
FileStream+FileOptions.SequentialScan：实测 10GB 文件比全量映射快 2–3 倍 - 真要映射，必须分块：用
capacity参数限制单次映射大小（如64 * 1024 * 1024），再配合CreateViewAccessor(offset, size)跳着读 - 避免在循环里反复 new
MemoryMappedViewAccessor：每次创建都涉及内核对象调度，开销不小
跨进程通信时 OpenExisting 找不到映射对象
90% 是命名空间隔离导致的“明明创建了却找不到”。Windows 默认把命名映射放在会话（Session）级命名空间，服务进程、不同用户登录的控制台进程互相看不见。
- 跨进程必须加
Global前缀：例如"Global\MyApp_IPC_v2"，否则默认在当前会话内查找 - 名称严格区分大小写，且全局唯一；建议用常量定义，调试期可追加
Process.GetCurrentProcess().Id辅助排查 - 不要依赖
CreateFromFile自动带名——它不保证命名可见性；改用CreateOrOpen显式指定名称和容量
WriteArray 报 “Attempted to read or write protected memory”
这不是权限问题，是典型的生命周期错乱：MemoryMappedViewAccessor 实例已被 GC 回收或 Dispose，但你还拿着它的 IntPtr 在操作。
- 每次调用
WriteArray前加防御检查：if (accessor.SafeMemoryMappedViewHandle.IsInvalid) throw new ObjectDisposedException(nameof(accessor)); - 绝不缓存
accessor实例跨方法使用——它不是线程安全的，且底层句柄可能被提前回收 - 写入长度必须 ≤ 视图容量：
int len = Math.Min(data.Length, (int)(accessor.Capacity - offset)); accessor.WriteArray(offset, data, 0, len); - 结构体写入必须加
[StructLayout(LayoutKind.Sequential, Pack = 1)]和显式[MarshalAs]，否则字段对齐错位直接越界
如何真正实现只读映射不被意外修改
靠 FileAccess.Read 或 MemoryMappedFileAccess.Read 不够。.NET 封装层不控制 Win32 底层的 flProtect 参数，只要文件句柄可写，映射区域就可被修改。
- 只读场景必须用 P/Invoke 调用
CreateFileMapping并传PAGE_READONLY，再用OpenFileMapping获取句柄 - 或者退而求其次：映射时用
MemoryMappedFileAccess.Read，但确保原始文件句柄以FileShare.Read打开，且无其他进程持有写权限 - 32 位进程映射大文件易崩溃：不是磁盘空间不足，是用户模式虚拟地址空间耗尽（2GB 限制），务必确认目标平台是 x64
最危险的坑不在 API 调用本身，而在多个进程对同一块内存的读写节奏没对齐、结构体布局没对齐、或者释放顺序搞反——这些错误不会立刻报异常，而是静默破坏数据或引发偶发崩溃。
