C++本身不防缓冲区溢出，所有防护依赖开发者主动实施：使用安全函数（如strncpy、snprintf）、启用编译器保护（-fstack-protector-strong、-D_FORTIFY_SOURCE=2）、采用现代容器（std::string、std::vector）、严格校验输入长度，四者缺一不可。
直接说结论：C++ 本身不防缓冲区溢出，所有防护都靠开发者主动加——用安全函数、开编译器保护、换现代容器、做输入校验，四者缺一不可。
用 strncpy、snprintf 替代 strcpy、sprintf
这类 C 风格函数是溢出重灾区，strcpy 不检查目标长度，sprintf 不限制输出字节数，一旦源数据超长就写穿栈。
-
strncpy(dest, src, sizeof(dest) - 1)后必须手动补dest[sizeof(dest)-1] = '\0'，否则可能漏掉终止符，后续strlen或printf会继续读内存 -
snprintf(buffer, sizeof(buffer), "%s:%d", host, port)是安全底线，第二个参数必须是缓冲区总大小，不是可用空间 -
gets已被 C++14 标准移除，但仍有老代码残留，一律换成fgets或std::getline
启用 -fstack-protector-strong 和 -D_FORTIFY_SOURCE=2
这些不是“可选优化”，而是运行时第一道防线。GCC/Clang 默认不开启，必须显式加进编译命令里。
-
-fstack-protector-strong会在含数组、地址取值或调用alloca的函数中插入 canary 值，覆盖返回地址前先破坏 canary，函数返回时检测失败就 abort -
-D_FORTIFY_SOURCE=2让部分标准函数（如memcpy、printf）在编译期做静态长度推导，若发现目标大小明显小于源长度，直接报错 - 注意：这两个选项对 inline 函数或模板实例化无效，关键路径上仍要靠代码逻辑兜底
用 std::string、std::vector、std::array 替代裸 char[]
原生数组 + 手动管理 = 溢出温床。STL 容器自带容量管理和边界检查（尤其在 debug 模式下），能从源头掐断多数栈溢出场景。
立即学习“C++免费学习笔记（深入）”；
-
std::string处理动态文本比char buf[256]安全得多，拼接、截取、格式化都无需操心长度 -
std::array<char></char>比char buf[64]多一层类型安全，.at()可抛异常，.data()返回指针时也更明确语义 - 网络收发场景慎用
std::string存二进制数据（隐含 null 截断风险），优先用std::vector<:byte></:byte>（C++17）或std::span（C++20）
所有网络/用户输入必须做长度校验再进缓冲区
TCP 是字节流，recv 返回的字节数完全不可控；命令行参数、配置文件字段、HTTP body 都可能被恶意拉长。不做校验就往固定大小缓冲区里塞，等于开门揖盗。
- 收到 TCP 数据后，先检查
len ，超长直接丢弃或断连，别试图“截断后处理” - 解析协议头里的长度字段时，必须验证该字段值是否在合理区间（比如不能为负、不能超 1MB、不能超过剩余缓冲区可读字节数）
- 即使用了
snprintf，也要确保格式化前的各字段（如用户名、路径名）已单独做过长度限制，防止组合后仍溢出
最易被忽略的一点：堆溢出比栈溢出更难定位，malloc/new 分配的缓冲区越界不会立刻崩溃，可能污染相邻 chunk 元数据，几轮分配释放后才暴露。所以 ASan（-fsanitize=address）不是调试玩具，是上线前必跑的回归项。
