Windows和Linux的mmap接口根本差异在于语义与错误处理：Windows需CreateFileMapping+MapViewOfFile两步，依赖文件句柄权限；Linux直接mmap，PROT_*仅控内存页权限；Windows无原生MAP_SHARED语义，刷盘需显式FlushViewOfFile+FlushFileBuffers，而Linux msync可选。
Windows 和 Linux 的 mmap 接口差异在哪
根本区别不在功能，而在语义和错误处理：Windows 用 CreateFileMapping + MapViewOfFile，Linux 用 mmap；前者需先打开文件句柄并显式创建映射对象，后者直接对 fd 调用 mmap。最常踩的坑是把 Windows 的 FILE_MAP_READ 当成 Linux 的 PROT_READ —— 它们不对应：FILE_MAP_READ 实际要求底层文件句柄有 GENERIC_READ 权限，而 PROT_READ 只控制映射后内存页的访问权限。
另一个关键点：Windows 不支持 MAP_SHARED 对应的“写回磁盘”语义（除非用 FlushViewOfFile + FlushFileBuffers 显式刷盘），Linux 下 msync 是可选的；但若你封装的是“只读映射”，两边都只需保证映射成功、地址有效即可，不必操心同步细节。
如何统一 open / map / unmap 的接口签名
核心是抽象出三个生命周期操作，且参数尽量贴近 POSIX 习惯（便于后续扩展到 macOS 或嵌入式）：
-
open_mapping(const char* path, size_t len, bool read_only)→ 返回自定义句柄（如struct mapping_handle），内部在 Windows 存HANDLE+LPVOID，Linux 存int fd+void* addr -
map_view(mapping_handle h, size_t offset, size_t length)→ 返回void*地址，Windows 调用MapViewOfFile，Linux 直接返回已映射基址 + offset（注意对齐） -
unmap_view(mapping_handle h, void* addr, size_t length)→ Windows 调UnmapViewOfFile，Linux 调munmap；必须传 length，因为 Windows 的UnmapViewOfFile不需要长度，但 Linux 的munmap需要，统一接口就得带
示例关键片段（简化）：
立即学习“C++免费学习笔记（深入）”；
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
// Linux 实现
void* map_view(mapping_handle h, size_t offset, size_t length) {
return static_cast<char*>(h.addr) + offset;
}
// Windows 实现
void* map_view(mapping_handle h, size_t offset, size_t length) {
return MapViewOfFile(h.hMap, read_only ? FILE_MAP_READ : FILE_MAP_ALL_ACCESS,
offset >> 32, offset & 0xFFFFFFFF, length);
}跨平台 size_t 对齐与 offset 处理怎么写才不出错
Linux mmap 要求 offset 必须是 getpagesize() 的整数倍；Windows MapViewOfFile 要求 dwNumberOfBytesToMap 和 dwFileOffsetHigh/Low 组合后的 offset 也必须按页面对齐（通常 4KB）。但用户传进来的 offset 很可能不对齐 —— 不能直接拒绝，得自动向下取整并对齐长度。
- 计算实际映射起始 offset：
aligned_offset = offset & ~(page_size - 1) - 映射长度需覆盖原请求范围：
mapped_length = (offset + length + page_size - 1) & ~(page_size - 1) - aligned_offset - 对外暴露的视图指针要偏移：
return (char*)mapped_addr + (offset - aligned_offset)
别忘了在 Windows 上调 GetSystemInfo 获取 dwAllocationGranularity（用于 CreateFileMapping 的大小对齐），但页面大小（dwPageSize）才是 MapViewOfFile 的对齐依据。
为什么 close_mapping 不能省略，且必须区分 handle 和 view
Windows 下，CloseHandle(h.hMap) 和 CloseHandle(h.hFile) 是两件事；Linux 下，close(fd) 和 munmap 也是独立的。常见错误是只释放 view（内存）却忘了关闭映射对象或文件描述符，导致资源泄漏 —— Windows 上表现为句柄泄露，Linux 上表现为 fd 耗尽。
- 封装层必须提供
close_mapping(mapping_handle h)，它负责：Windows 关闭h.hMap和h.hFile；Linuxclose(h.fd) -
unmap_view只管内存视图，close_mapping只管底层资源，二者不可合并 - 如果用户重复调用
unmap_view同一地址，Linux 会返回-1+errno=EINVAL，Windows 返回FALSE；封装层应检查并静默忽略（或记录 warning），而不是 crash
真正容易被忽略的是：当映射长度远大于实际使用长度时，unmap_view 若传错 length（比如小于实际映射长度），Linux 会失败，Windows 却可能成功——这会导致后续访问触发 SIGSEGV，且难以 debug。
