C++17 的 std::shared_memory_object 因标准库未实现（GCC/MSVC 完全缺失，Clang/libc++ 仅极新版本部分支持）而不可用；Windows 与 POSIX 内存映射在 API、参数语义（如大小拆分、权限标志）、错误处理及对齐要求上存在本质差异，必须分平台封装且避免宏混写。
为什么不能直接用 std::shared_memory_object
因为 C++17 的 std::shared_memory_object 和 std::mapped_file_view 在 GCC（libstdc++）和 MSVC 中均未实现，Clang/libc++ 也只在极新版本中部分支持。你写完编译就报错：error: 'shared_memory_object' is not a member of 'std'——这不是你代码的问题，是标准库没跟上。
Windows 和 POSIX 内存映射的核心差异在哪
Windows 用 CreateFileMappingW + MapViewOfFile，POSIX 用 open + mmap；两者语义接近但参数不兼容：比如 Windows 的 dwMaximumSizeHigh/dwMaximumSizeLow 要拆 64 位大小，POSIX 的 size 是单个 off_t；权限标志也不同（PAGE_READWRITE vs PROT_READ | PROT_WRITE）。封装时必须隔离这些细节，不能靠宏混写。
实操建议：
- 把平台相关逻辑全收进 .cpp 文件，头文件只暴露统一接口（如
open、map、unmap） - 用
#ifdef _WIN32分支实现，但不要在头里展开；避免模板特化引入 ODR 风险 - 文件描述符/句柄统一用
void*或自定义句柄类型（如handle_t），不暴露HANDLE或int - 大小一律用
uint64_t入参，内部按平台转——Windows 需拆高低 32 位，POSIX 直接传
map() 失败时最常被忽略的三个原因
跨平台封装后，map() 返回空指针很常见，但错误根源往往藏得深：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
- POSIX 下
mmap失败但没检查errno：比如文件没读权限、open返回 -1 却继续调mmap，结果mmap对 -1 句柄返回MAP_FAILED（即(void*)-1），不是nullptr - Windows 下
CreateFileMappingW成功，但MapViewOfFile失败且没调GetLastError()：常见于映射视图大小超过文件实际大小，且没设FILE_MAP_COPY或没处理ERROR_MAPPED_FILE_SIZE_MISMATCH - 未对齐的映射起始偏移：POSIX 要求
offset是sysconf(_SC_PAGESIZE)倍数，Windows 要求是 64KB（SECTION_ALLOCATION_GRANULARITY）倍数；跨平台封装必须做自动对齐，并修正映射长度补偿偏移损失
如何安全释放资源并避免 double-close
Windows 的 CloseHandle 和 POSIX 的 close + munmap 必须严格配对，且顺序不能反：POSIX 必须先 munmap 再 close，否则可能丢数据；Windows 则只要 CloseHandle 就行（UnmapViewOfFile 是可选的，但建议显式调用）。
实操建议：
- 用 RAII 管理，析构函数里按平台分别调用清理逻辑，且加 guard（如
if (m_handle != nullptr)） - 禁止拷贝，只允许移动：把移动构造函数设为
noexcept，移动后立即置空所有句柄/指针 - 不要在
map()失败后还尝试unmap()——应由用户决定是否清理底层文件句柄；封装类只负责映射段生命周期
真正麻烦的是大页映射、稀疏映射或需要 MAP_SYNC（Linux 5.8+）的场景，那些没法靠一层封装抹平，得暴露底层句柄供用户自行操作。
