std::vector 默认内存因对齐不足（仅8/16字节）无法满足O_DIRECT异步DMA落盘要求，需用posix_memalign等手动分配4KiB对齐内存并RAII封装。
为什么 std::vector 默认分配的内存不能直接用于异步 DMA 落盘
因为 std::vector 的底层内存由 new 或默认分配器提供，地址对齐粒度通常是 8/16 字节，而块设备（如 NVMe、某些 SSD 驱动）要求 I/O 缓冲区按扇区边界（常见为 512B 或 4KiB）对齐，否则 io_uring 提交或 libaio 的 io_submit 可能直接返回 -EINVAL，Linux 内核也会拒绝非对齐的 direct I/O 请求。
关键点不是“能不能写”，而是“能不能用 O_DIRECT + 异步 I/O 接口安全落盘”。未对齐缓冲区在 write() 上可能降级为 buffered I/O，失去异步可控性；在 io_uring 中则大概率失败。
- Linux 对
O_DIRECT的强制要求：缓冲区地址 & 长度都必须是逻辑块大小（st_blksize）的整数倍 -
io_uring的IORING_OP_WRITE还额外要求缓冲区物理页连续（用户态需保证对齐+足够大页支持，但至少先对齐） -
std::vector无法指定对齐方式，即使你reserve()也无济于事
如何申请扇区对齐的 vector 等价内存（不依赖 C++20 aligned_alloc）
用 posix_memalign 或 aligned_alloc 手动管理内存，再套一层 RAII 封装，替代 std::vector。不要试图继承或特化 std::vector —— 分配器接口太重，且对齐分配器与标准容器交互存在未定义行为风险。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 确定目标对齐值：
getconf PAGESIZE或读取设备stat().st_blksize，保守起见用4096 - 用
posix_memalign(&ptr, 4096, size)分配原始内存，检查返回值是否为 0 - 用 placement-new 构造元素（若为 trivial 类型可跳过），并手动调用析构（若非 trivial）
- 封装成类似
AlignedBuffer<T>，重载operator[]、data()、size()，但**不提供 push_back / resize** —— 因为 realloc 会破坏对齐
示例片段：
void* raw = nullptr;
if (posix_memalign(&raw, 4096, cap * sizeof(T)) != 0) {
throw std::bad_alloc{};
}
T* ptr = static_cast<T*>(raw);
// 若 T 非 trivial，需 for-loop 调用 placement-new
异步落盘时如何避免 double-copy 和生命周期错位
对齐内存分配后，不能把它简单传给 std::vector::assign 或构造函数 —— 那会触发 memcpy 到新堆区，既浪费又丢失对齐属性。真正要传给 io_uring 或 aio_write 的，必须是原始指针 ptr 和长度。
关键陷阱：
-
std::vector析构时会delete[]自己的内存，但你的对齐内存是free()释放的 —— 混用导致崩溃 - 异步 I/O 提交后，缓冲区必须在整个操作完成前保持有效；若用局部
AlignedBuffer，而 I/O 是 fire-and-forget，必须延长其生命周期（例如 move 到回调闭包、或用std::shared_ptr管理） - 不要在
io_uring的 completion queue 处理中直接free()内存 —— 需确保该 buffer 不再被任何 pending SQE 引用
推荐模式：提交 I/O 前，把 AlignedBuffer move 进一个 std::shared_ptr<AlignedBuffer<uint8_t>>，然后把该 shared_ptr 捆绑到 io_uring_sqe 的 user_data 字段（或自定义 context 结构体）；completion 回调中再释放。
实际落盘性能比拼：O_DIRECT + 对齐 vs mmap + msync
对齐 + io_uring 是吞吐优先路径，但有个硬约束：必须预分配全部数据。而 mmap + msync 更适合流式写入，且内核自动处理页对齐和脏页刷盘调度。
选型判断依据：
- 如果你已知完整数据大小（如日志批处理、快照 dump），且追求最低延迟和最高 IOPS，用对齐 buffer +
IORING_OP_WRITE - 如果数据边生成边落盘（如实时采集），
mmap更稳：用MAP_HUGETLB+MAP_SYNC（需 kernel ≥ 5.15）可逼近 direct I/O 性能，且无需手动对齐 - 注意：glibc 的
msync(MS_SYNC)是阻塞的；异步等效方案是io_uring提交IORING_OP_FSYNC，但只对文件有效，不适用于 buffer
最后提醒：无论哪种方式，务必用 open(..., O_DIRECT | O_SYNC) 或 fcntl(fd, F_SETFL, O_DIRECT) 显式开启 direct I/O，并验证 write() 返回值是否等于请求字节数 —— partial write 在对齐 buffer 场景下极少发生，一旦出现，基本说明底层设备或驱动异常。
