跨平台内存管理需通过抽象层封装分配/释放逻辑，而非直接使用裸指针；应实现符合allocator概念的自定义分配器，统一桥接各平台api，并严格绑定分配与释放责任链。
指针本身不跨平台，跨平台内存管理靠抽象层
直接用裸指针（int*、void*）做“跨平台内存管理”是误区。指针只是地址类型，其行为由编译器、ABI 和操作系统共同决定——比如 Windows 的 HeapAlloc 与 Linux 的 mmap 返回的地址空间规则不同，裸指针无法自动适配。真正可行的是：用指针作为底层载体，但把分配/释放逻辑封装进平台无关的接口。
用 std::allocator 或自定义分配器统一接口
std::allocator 本身不跨平台（它默认调用 ::operator new，而该函数在各平台底层实现不同），但它提供了标准接口契约。关键在于：自己实现一个满足 Allocator 概念的类，在内部桥接平台 API。
- Windows 下可调用
HeapAlloc(GetProcessHeap(), 0, size)，释放用HeapFree - Linux/macOS 下可用
posix_memalign(&ptr, align, size)或memalign（注意 glibc 版本差异） - 必须重载
allocate()/deallocate()/construct()/destroy()四个关键成员函数 - 对齐要求（
align）不能硬编码，需通过std::alignment_of_v<t></t>获取
避免直接暴露裸指针给跨平台模块
常见错误是让上层代码直接操作 void* 并传给不同平台的释放函数，结果在 macOS 上用 free() 释放了 mmap() 分配的内存，触发 double free or corruption 错误。
- 所有分配返回值应包装为 RAII 类型，如
struct AllocatedBlock { void* ptr; size_t size; ~AllocatedBlock() { release(); } }; - 释放逻辑必须和分配逻辑绑定在同一作用域或同一类中，禁止“malloc 在 A 平台，free 在 B 平台”式混用
- 若必须传递指针（如对接 C 接口），至少附带一个
deleter函数指针或枚举标识（如enum class AllocSource { Malloc, HeapAlloc, Mmap };）
调试时重点关注 sizeof(void*) 和 alignof(std::max_align_t)
64 位下 sizeof(void*) 是 8，但某些嵌入式平台（如 ARM Cortex-M）可能运行在 32 位模式；alignof(std::max_align_t) 在 Windows MSVC 下常为 16，Linux GCC 可能是 32——这些差异会导致结构体内存布局错位，尤其在序列化或共享内存场景中。
- 不要假设
new uint8_t[1024]的地址天然满足 16 字节对齐；显式使用aligned_alloc或分配器的allocate - 跨平台结构体（如用于 IPC）必须用
#pragma pack(1)或[[gnu::packed]]+ 手动填充，否则指针字段偏移在不同编译器下不一致 - 调试时用
printf("ptr=%p, align=%zu\n", ptr, (uintptr_t)ptr % align)快速验证对齐是否符合预期
跨平台内存管理最难的不是写几行分配代码，而是确保“谁分配、谁释放”的责任链在预处理宏、链接时、运行时三个层面都不断裂。稍有松动，就是野指针或未定义行为。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
