栈溢出不是小事，一次崩溃可能就是安全漏洞
写程序时，很多人只关心功能能不能跑通，却忽略了内存管理的细节。尤其是栈溢出，看起来像是教科书里的概念，但在实际开发中，它可能就藏在你写的某个递归函数里，或者一个没检查长度的字符串拷贝操作中。
比如有个小团队做嵌入式设备的固件更新，每次升级都要解析配置文件。他们用了一个局部数组存路径名：char path[256];，然后直接用 strcpy 拷贝用户传进来的字符串。结果有人故意传了个超长路径，设备直接重启——问题就出在栈溢出触发了保护机制。
栈是怎么被“撑爆”的
函数调用时，参数、返回地址、局部变量都压在栈上。栈空间有限，通常几MB，一旦超出就会越界。常见诱因有：深度递归、大尺寸局部数组、不安全的字符串操作。
看个典型的例子：
void vulnerable_function(char *input) {
char buffer[64];
strcpy(buffer, input); // 危险！没检查 input 长度
}如果 input 超过 64 字节，多余的数据就会覆盖栈上的其他数据，包括返回地址。攻击者可以精心构造输入，让程序跳转到恶意代码，这就是常见的缓冲区溢出攻击。
怎么防？从编码习惯开始
最简单的办法是别用危险函数。把 strcpy 换成 strncpy，sprintf 换成 snprintf，明确指定最大写入长度。
void safe_function(char *input) {
char buffer[64];
strncpy(buffer, input, sizeof(buffer) - 1);
buffer[sizeof(buffer) - 1] = '\0';
}虽然麻烦点，但能挡住大部分低级错误。另外，局部变量别随便声明大数组。比如要处理 10KB 数据，别写 char data[10240];，改用动态分配：char *data = malloc(10240);，用完记得 free。
编译器也能帮你盯一眼
现代编译器有栈保护机制。GCC 的 -fstack-protector 会在函数入口插入“金丝雀值”（canary），函数返回前检查这个值是否被修改。如果被改了，说明栈可能被破坏，直接终止程序。
开启方式很简单，编译时加上：
gcc -fstack-protector-strong -O2 program.c这不是万能药，但能拦住不少常见攻击。配合 -Warray-bounds、-Wformat-overflow 这类警告选项，很多潜在问题在编译阶段就能发现。
运行时监控也不能少
对于复杂系统，光靠编码规范和编译器不够。可以用 AddressSanitizer（ASan）这种工具，在程序运行时检测内存错误。它能在栈溢出发生时立刻报错，定位到具体哪一行。
gcc -fsanitize=address -g program.c跑测试时加上这个，等于给内存操作装了个摄像头。虽然会拖慢性能，不适合上线，但开发和测试阶段非常有用。
栈溢出防范不是一招制敌的事，而是从写每一行代码开始的习惯。多一分小心，系统就少一个崩溃点，也少一个被攻破的入口。