最稳妥做法是静态链接mimalloc并重载全局operator new/delete，需确保Linux/macOS链接时-lmimalloc置于目标文件之后、Windows关闭/FORCE:MULTIPLE、禁用-fPIE；启用MI_SECURE=1会显著降速，多线程下切勿手动调用mi_heap_destroy。
怎么把 mimalloc 静态链接进 C++ 项目
直接替换全局 malloc/free 是最常用也最稳妥的做法，但必须确保链接顺序和符号覆盖正确。否则程序仍走 libc 的分配器，白集成。
- Linux/macOS 下：编译时加
-lmimalloc，且必须放在所有目标文件之后（比如g++ main.o -lmimalloc），否则链接器可能不优先绑定malloc - Windows MSVC 下：用
#pragma comment(lib, "mimalloc.lib")，并确认/FORCE:MULTIPLE没开——它会干扰符号替换 - 务必关闭
-fPIE或启用-fno-pie（尤其在较老 GCC 上），否则mimalloc的 TLS 初始化可能失败，启动时报segmentation fault - 验证是否生效：运行时调用
mi_stats_print()，有输出即说明已接管；若报undefined reference，说明链接未成功或头文件没包含
mi_malloc 和全局重载哪个该用
除非你明确想绕过某些系统组件（如第三方库的内存钩子），否则别手动调用 mi_malloc。全局重载更干净，兼容性更好。
- 手动调用
mi_malloc/mi_free会导致和std::vector、std::string等标准容器不兼容——它们内部仍走operator new，不会自动转到mi_malloc - 真正有效的做法是重载全局
operator new和operator delete，并在其中调用mi_malloc/mi_free；mimalloc提供了现成的mi_new_delete.cpp，直接编译进去就行 - 注意：重载
operator new后，std::allocator默认行为也会改变，但自定义 allocator（如boost::pool_allocator）不受影响，不用额外处理
为什么开了 MI_SECURE=1 后性能反而暴跌
开启安全模式会为每次分配插入指针加密、边界检查和随机化，适合调试，但生产环境基本不用。
-
MI_SECURE=1会让小对象分配慢 3–5 倍，因为每个malloc都要查页表+解密隐藏指针 - 真正需要防护的是堆溢出和 use-after-free，这类问题靠 ASan/UBSan 更准更快；
mimalloc的 secure 模式不是替代方案，而是粗粒度兜底 - 如果真要在生产用安全特性，改用
MI_SECURE=2（仅对大块内存启用保护），或者干脆关掉，靠部署时开PROT_NONE页保护更轻量 - 环境变量只在进程启动时读取，运行中改
putenv("MI_SECURE=0")无效
多线程下 mimalloc 为啥还卡在 mi_heap_destroy
主线程退出时显式调用 mi_heap_destroy 很危险——其他线程可能还在用默认 heap，导致释放未完成的 arena。
立即学习“C++免费学习笔记（深入）”；
- 绝大多数情况根本不需要手动 destroy heap；
mimalloc在进程退出时会自动清理所有 heap，包括线程局部的 - 唯一该调用
mi_heap_destroy的场景是：你用mi_heap_new()创建了长期存活的私有 heap，并确定再无任何线程访问它 - 常见误用：在
thread_local变量析构函数里调用mi_heap_destroy，此时其他线程可能正从该 heap 分配内存，引发 crash - 如果看到线程卡在
mi_heap_destroy，先检查是否在atexit或静态对象析构期触发了它——那是未定义行为高发区
