std::async 默认不真异步，因常走延迟执行或线程不复用；提速需用 mmap 预映射、固定线程池+packaged_task，Linux 下可选 io_uring。
直接用 std::async 默认行为做“异步预加载”，大概率没真异步，只是延迟执行；真正要提速，得绕过用户态拷贝、控制调度粒度、并确保资源不泄漏。
为什么 std::async(std::launch::async, ...) 仍卡主线程
常见现象是：调用后 UI 冻结、get() 阻塞时间长、多文件并发时线程数暴涨。根本原因不是代码写错，而是默认策略没生效或底层没真并发。
- 省略启动策略（即不写
std::launch::async）→ 实际走std::launch::deferred，get()一调就同步执行，和普通函数调用无异 - 即使写了
std::launch::async，标准不保证线程复用；GCC/Clang 多数实现每次新建线程，高频小任务（如几十 MB 的纹理、配置文件）会快速耗尽系统资源 -
std::ifstream::read()在大文件场景下本质是阻塞式系统调用，哪怕在新线程里跑，也照卡——它不释放 CPU，只是换了个线程卡
用 mmap 预映射替代 read，跳过用户态内存拷贝
适用于 Linux/macOS，Windows 可用 CreateFileMapping + MapViewOfFile。核心价值是让 OS 按需分页加载，首次访问才触发磁盘 I/O，后续读取近乎零延迟。
- 必须用
O_RDONLY（Linux）或GENERIC_READ（Windows）打开文件，且不能加O_SYNC或O_DIRECT（会破坏按需加载语义） - 映射地址无需手动释放，但
munmap/UnmapViewOfFile必须在对象生命周期结束前调用，否则内存泄漏 - 别对
mmap返回的指针做std::string构造——它不保证 null 结尾，且可能跨页；优先用std::span<const std::byte></const>或裸指针 + 显式长度 - 示例关键段：
int fd = open("data.bin", O_RDONLY);<br>size_t size = lseek(fd, 0, SEEK_END);<br>void* mapped = mmap(nullptr, size, PROT_READ, MAP_PRIVATE, fd, 0);<br>close(fd); // fd 可立即关，映射仍有效
std::future 不适合批量预加载，改用固定线程池 + packaged_task
当你要同时预加载 20 个资源文件，每个几 MB 到几百 MB，std::async 会创建 20 个线程，而实际磁盘吞吐早被瓶颈了——这不是并发，是内耗。
立即学习“C++免费学习笔记（深入）”；
- 建一个大小为 4～8 的线程池（匹配物理核数），用
std::queue<:packaged_task>></:packaged_task>接收任务 - 每个预加载任务封装为
std::packaged_task<:unique_ptr>()></:unique_ptr>，返回裸指针+长度，避免 vector 拷贝开销 - 主线程只负责投任务，用
std::vector<:future>></:future>收集 handle，但别立刻get()；用wait_for(1ms)非阻塞轮询状态，或等全部提交完再统一wait_all（C++20） - 异常必须处理：任务内
throw后，对应future.get()会 rethrow；若不调get()，析构时直接std::terminate
Linux 下追求极致性能：io_uring 替代所有用户态线程调度
如果你的部署环境确定是 Linux 5.1+，且文件在本地 NVMe/SSD 上，io_uring 是目前唯一能逼近硬件极限的方案——它没有线程切换、无锁、零拷贝，吞吐比 std::async + read 高 3～5 倍。
- 必须用
O_DIRECT打开文件，且 buffer 地址和长度都按 512B 对齐（用posix_memalign分配） - 不要单次提交一个
IORING_OP_READ；攒够 4～8 个请求一起io_uring_submit，否则提交开销反超读取本身 -
io_uring实例不是线程安全的，多线程提交必须加锁，或每个线程独占一个实例 - 别指望它兼容 Windows/macOS；跨平台项目里，把它作为 Linux 特化路径，其他平台 fallback 到 mmap + 线程池
真正难的不是选哪个 API，而是判断加载时机与内存生命周期是否对齐：mmap 映射后没访问的页不会进 RAM，但若预加载后很久才用，OS 可能已将其换出；io_uring 提交后任务在内核队列里，但若程序提前退出，未完成请求会丢失。这些细节不写进 RAII 封装，迟早出问题。
