MemoryMappedFile名称需全局唯一且区分大小写，否则引发IOException或静默覆盖；结构体须用[StructLayout(Pack=1)]并校验偏移长度；Dispose时accessor须先于mmf释放；大数据宜用CreateViewStream配合同步机制。
MemoryMappedFile 创建时名称必须全局唯一且区分大小写
Windows 系统中 MemoryMappedFile 依赖内核对象命名空间，名称冲突会导致 IOException：“The named shared memory object already exists.” 或静默覆盖——后者更危险，因为旧进程可能仍在读写已失效的映射视图。
实操建议：
- 用带前缀的固定格式命名，例如
"Global\MyApp_Data_v2"（Global前缀确保跨会话可见，适合服务与桌面进程通信） - 避免硬编码字符串，改用常量或配置项；调试阶段可在名称后追加
Process.GetCurrentProcess().Id辅助排查 - 若需多实例隔离，把用户 SID 或应用实例 ID 注入名称，而非依赖随机数——随机数无法保证跨进程一致
Write/Read 必须严格对齐偏移和长度，否则读到脏数据
MemoryMappedViewAccessor 不做边界校验，越界写入会破坏相邻内存区域（可能影响其他字段甚至引发 AccessViolationException），而越界读取则返回零值或旧垃圾数据，错误极其隐蔽。
实操建议：
- 定义结构体时显式使用
[StructLayout(LayoutKind.Sequential, Pack = 1)]，禁用编译器填充 - 用
Marshal.SizeOf<T>()替代sizeof(T)获取实际序列化长度（尤其含引用类型时） - 写入前检查
accessor.Capacity - offset >= dataSize；读取时用TryRead而非Read避免异常中断 - 示例：写入一个
int到偏移 0 处：using var accessor = mmf.CreateViewAccessor(); accessor.Write(0, 123); // 正确：偏移 0，写入 4 字节 int accessor.Write(1, 123); // 危险：从第 1 字节开始写，跨字节破坏数据
Dispose 顺序错误会导致子进程崩溃或句柄泄漏
常见误操作是父进程先释放 MemoryMappedFile 实例，但子进程仍在用其创建的 MemoryMappedViewAccessor。此时子进程访问会触发 ObjectDisposedException 或直接崩溃——.NET 不保证跨进程资源生命周期同步。
实操建议：
- 所有持有映射对象的进程，都应自行调用
Dispose()，不要依赖父进程“统一清理” - 若需协调销毁时机，用命名
EventWaitHandle通知对方“我已退出”，再安全释放；切勿用GC.Collect()强制回收 - 在
finally块或using语句中释放MemoryMappedViewAccessor和MemoryMappedFile，且accessor必须先于mmf释放
大块数据共享时，用 CreateViewStream 比 CreateViewAccessor 更稳
当共享数据超过几 MB，频繁调用 accessor.Write 写入结构体会因重复 pinning 和 marshal 开销变慢，且易触发 GC 压力；而 ViewAccessor 的指针模式在超长数据下容易因地址截断出错（尤其 x86 进程访问大内存）。
实操建议：
- 传输二进制流（如图片、日志块）优先用
mmf.CreateViewStream(offset, length, FileAccess.ReadWrite)，配合BinaryWriter/BinaryReader - 流模式天然支持分段读写，不强制加载整块内存，适合不确定大小的数据
- 注意：流不支持并发写入，需额外用
Mutex同步；若需高并发，改用多个小映射文件 + 索引表
跨进程共享不是“打开就完事”，最麻烦的是两边对结构体布局、生命周期、同步点的理解稍有偏差，程序就会在某个凌晨三点突然返回 0 或抛出无法捕获的异常。别省略 try/catch 包裹 Write 和 Read，也别相信“测试时没问题”。
