recv()缓冲区参数必须是指针，因它需直接向指定内存地址写入数据，不分配新内存；传值会复制栈副本，传数组名可能丢失长度，唯指针能准确提供已分配缓冲区起始地址。
recv() 的缓冲区参数为什么必须是指针
因为 recv() 需要直接往你提供的内存地址里写入接收到的字节，它不创建新内存，只填充。传值或传数组名（退化为指针）都行不通——前者复制栈上副本，后者可能丢失长度信息；唯一可靠的是传一个指向已分配缓冲区起始地址的指针。
常见错误是写成 recv(sockfd, buffer, sizeof(buffer), 0) 却把 buffer 声明为 std::vector<char> buffer(1024)</char>，这时 buffer 不是指针，&buffer[0] 或 buffer.data() 才是合法指针。
- 用
char buf[1024]：传buf（自动转指针）或&buf[0] - 用
std::vector<char> buf(1024)</char>：必须传buf.data()，不能传buf - 用
std::unique_ptr<char> buf(new char[1024])</char>：传buf.get()
如何避免 recv() 覆盖缓冲区边界
recv() 不保证一次收完所有数据，也不保证填满缓冲区；它返回实际接收字节数，但如果你忽略这个值，直接当满缓冲区处理，就会读到脏数据或越界解析。
典型翻车场景：声明 char buf[512]，调用 recv(sockfd, buf, 512, 0)，然后直接 std::string s(buf)——这会从第一个 \0 截断，且未校验返回值，若实际只收到 3 字节，后面 509 字节全是未初始化垃圾。
立即学习“C++免费学习笔记（深入）”；
- 始终检查返回值：
ssize_t n = recv(sockfd, buf, sizeof(buf)-1, 0) - 手动补
\0：若n > 0，执行buf[n] = '\0'（前提是预留了 1 字节空间） - 不要依赖 C 字符串函数处理二进制数据；如需完整原始字节，用
std::string(buf, n)或std::span(buf, n)
使用指针管理动态缓冲区时的生命周期陷阱
如果用 new char[...] 分配缓冲区，指针本身只是地址，不绑定内存生命周期；套接字长时间运行时，容易因异常跳过 delete[] 导致泄漏，或重复释放引发崩溃。
更隐蔽的问题是：多个线程共用同一指针、或在异步回调中访问已释放的缓冲区。C++ 没有 GC，指针一旦失效，行为未定义。
- 优先用 RAII 容器：
std::vector<char> buf(65536)</char>，自动管理内存 - 若需裸指针（如对接 C API），用
std::unique_ptr<char></char>，构造时传new char[n]，析构自动delete[] - 绝不在
recv()后长期持有裸指针；如需缓存数据，拷贝到std::string或std::vector
recv() 返回 -1 时，指针内容是否仍可读
返回 -1 表示出错，但错误类型决定缓冲区状态：EINTR 和 EAGAIN/EWOULDBLOCK 是可恢复错误，此时缓冲区内容未被修改，可以重试；而 ENOTCONN、ECONNRESET 等表示连接已断，缓冲区可能部分有效，但继续读无意义。
关键点：返回 -1 不等于缓冲区被清空或污染，它只是没写入新数据。但你不应假设里面还有上次的数据——除非你明确没覆盖它。
- 检查
errno：用#include <cerrno>，判断是否为EINTR或非阻塞相关的错误 - 不要在错误路径里直接解析
buf；先确认n > 0再处理 - 对非阻塞 socket，
recv()返回 -1 +EAGAIN是正常现象，不是 bug
缓冲区指针本身不难写，难的是每次调用 recv() 时都同步维护长度、有效性、所有权和错误分支——这些细节不会报编译错误，但会在凌晨三点让你对着 Wireshark 抓包发呆。
