readv/writev能缓解I/O瓶颈，因其支持分散-聚集I/O，一次系统调用即可处理多个不连续缓冲区，避免传统read/write频繁系统调用、用户态拼接和冗余内存拷贝，显著降低上下文切换开销与cache miss，在高并发小响应场景下QPS可提升15%～40%。
readv/writev 为什么能缓解 IO 瓶颈
传统 read/write 每次只能处理一块连续内存，HTTP 响应头、正文、尾部等数据天然分散在不同变量里（比如 header_buf、body_data、footer_str），硬拼成一块大缓冲区不仅浪费 memcpy，还增加 cache miss 和堆分配开销。而 readv/writev 允许你把多个不连续缓冲区“逻辑上拼接”，由内核一次性完成原子写入——省掉用户态拼接、减少系统调用次数、避免中间拷贝。
关键点在于：瓶颈往往不是磁盘或网卡带宽，而是系统调用上下文切换和用户态内存操作。一次 writev 替代 3～5 次 write，实测在高并发小响应体场景下，QPS 可提升 15%～40%，且 strace 显示 write 系统调用数下降明显。
怎么构造 iovec 数组才不踩坑
iovec 数组本身简单，但实际用起来容易出错：
- 数组元素不能跨栈帧生命周期——比如在函数内局部定义
struct iovec iov[4]，然后传给异步写的回调，回调执行时栈已销毁，iov[i].iov_base指向野地址 -
iov_len必须是真实有效长度，不能传未初始化的变量或超界值；writev遇到iov_len == 0会跳过该段，但不会报错，容易导致数据静默丢失 - Linux 要求
iovcnt <= IOV_MAX（当前内核通常是 1024），但 glibc 在超过时会自动 fallback 到单次write+ 内存拷贝，性能反而更差——建议显式检查：if (iovcnt > IOV_MAX) { /* 分批 submit */ } - 所有
iov_base指向的内存必须在writev返回前保持有效；若用std::string::data()，确保 string 不被 move 或 resize
writev 在 HTTP 响应中的典型用法
一个完整 HTTP 响应通常含三部分：状态行+头部（静态字符串）、正文（可能来自文件 mmap 或堆内存）、分块传输尾缀（可选）。用 writev 直接投递，无需 memcpy：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
struct iovec iov[3];
iov[0].iov_base = status_line.data();
iov[0].iov_len = status_line.size();
iov[1].iov_base = body_ptr; // 可能是 mmap 地址或 new[] 分配
iov[1].iov_len = body_len;
iov[2].iov_base = "\r\n";
iov[2].iov_len = 2;
<p>ssize_t n = writev(sockfd, iov, 3);
if (n == -1 && errno == EAGAIN) {
// 非阻塞场景，需注册 epoll EPOLLOUT 后重试
}</p>注意：writev 返回的是**总字节数**，不是 iov 数量；它不保证每个 iov 都写满（尤其在网络拥塞时），但保证顺序——即 iov[0] 的内容一定在 iov[1] 之前到达对端。
readv 处理请求时的边界陷阱
readv 常用于解析 HTTP 请求头+正文混合包（如 keep-alive 连接中粘包），但它不会按 iov 边界切分数据：
- 如果请求头 200 字节，你设
iov[0].iov_len = 128，iov[1].iov_len = 128，那么前 128 字节进第一块，剩下 72 字节进第二块，**不会**因为第二块还有空间就继续填——它严格按数组顺序填充，填满一块再填下一块 - 这意味着：不能靠
iov数组结构反推协议字段边界；解析仍需扫描整个读取结果，readv只是减少拷贝，不替代协议解析逻辑 - 若用
readv读固定格式二进制协议（如 header+payload），务必确认各iov长度与协议定义完全一致，否则iov[0]读不满会导致后续偏移错乱
真正省事的场景是“已知结构、只需搬运”，比如从 socket 读出 magic number、length field、payload 三段，且每段长度固定——这时 readv 能让代码更直白，也更安全（避免手撕 offset）。
