strcpy、strncpy、strcat、strncat、strcmp、strncmp、strlen、memcpy、memset、strchr——这十个函数几乎是每个写 C 的人绕不过去的第一道坎。它们出现在每一本教材的前几章也出现在每一次线上崩溃的堆栈里。我带过几个刚入行的同学简历上写着精通 C 语言指针与字符串处理让他手写一个把配置项拆成 key 和 value 的循环十个里有七个会在 strncpy 上翻车剩下三个会在 strncat 的第三个参数上栽跟头。这篇东西不讲语法书上的定义那些你自己翻手册两分钟就能看到。我想聊的是这批函数在真实代码里的脾气哪些是看着安全实则挖坑的哪些是被误解多年的哪些参数的含义和你以为的完全不是一回事。适合刚写完第一个 C 项目、正在被段错误和乱码折磨的人也适合写了几年、但一直靠多留几十字节缓冲糊弄过去的人。看完你至少能做到两件事第一知道每个函数调用时该检查什么第二看到一个陌生的字符串处理函数能猜出它的边界在哪里。1. 先把这批函数归归类别一锅炖十个函数挤在一个标题里乍看都是处理字符串的实际上它们分属两个完全不同的家族边界感和设计哲学差得很远。分不清这个后面所有的参数选择都会失去依据。1.1 字符串家族和内存家族的根本区别strcpy、strncpy、strcat、strncat、strcmp、strncmp、strlen、strchr这八个属于字符串家族。它们的共同前提是你操作的那块内存里躺着一个合法的、以\0结尾的字符序列。它们靠这个零字节判断到哪里停而不是靠你传进去的长度。memcpy和memset属于内存家族。它们根本不认识\0只认字节数。你给它 100 字节它老老实实搬 100 字节中间有多少个零字节它都不关心。这个区别决定了两个家族的适用场景。字符串家族适合处理人写的文本——配置项、路径、命令行参数、日志行。内存家族适合处理机器认的数据——结构体、二进制协议包、图像缓冲区、数组初始化。我见过有人用strlen去量一个二进制包的长度结果包体中间恰好有个0x00量出来的长度是 3实际包长 1024后面解析全乱。这个错误在协议对接里特别常见因为调试的时候你看到的往往是文本形式的十六进制打印容易产生这是字符串的错觉。反过来也有人用memcpy(dst, src, 4096)去拷贝一个用户输入的名字只要对方输入超过缓冲区大小就直接越界写。字符串家族虽然危险但至少它会停在\0内存家族连这个刹车都没有。1.2 带 n 的版本到底安全在哪里很多人有个直觉带n的版本是安全版不带n的是危险版。这个直觉一半对一半错错的那一半害人更深。strncpy的n限制的是最多从源拷贝多少字节但它不保证目标串以\0结尾。也就是说strncpy(dst, src, n)在src长度大于等于n的时候dst里根本没有终止符后续任何strlen(dst)、printf(%s, dst)都会一路读到你缓冲区外面的内存里去。这不叫安全这叫把地雷埋得更深了一点。strncat的n限制的是最多从源追加多少字节而且它保证结果以\0结尾——但它需要你在目标里预留strlen(dst) n 1的空间。绝大多数人的错误是把n当成目标缓冲区总大小传进去比如char buf[64]; strncat(buf, src, 64);这一行在buf已有内容的情况下必然越界。strncmp的n倒是名副其实比较前 n 个字符或者遇到终止符就停没有坑。memcpy没有n的说法第三个参数本来就是字节数它是所有函数里语义最干净的一个。所以真实情况是带 n 的版本不解决越界问题它只是把无限越界变成有限越界把责任重新推回给你。真正的安全边界得靠你自己算出目标容量然后按容量传参。1.3 一张表看清各自的刹车在哪函数停下来靠什么是否保证目标以\0结尾典型的容量要求strcpy(d, s)源串的\0是strlen(s) 1strncpy(d, s, n)源串\0或 n 字节否源串长时无终止符n字节且需手动补零strcat(d, s)源串的\0是strlen(d) strlen(s) 1strncat(d, s, n)源串\0或 n 字节是strlen(d) n 1strcmp(a, b)任一方的\0无写入无strncmp(a, b, n)任一方\0或 n 字节无写入无strlen(s)源串的\0无写入无strchr(s, c)源串的\0无写入无memcpy(d, s, n)只认 n不关心n字节memset(d, c, n)只认 n不关心n字节这张表的第三列是整篇文章里最需要记住的东西。凡是那一列写着否或者不关心的你就必须自己在调用前后做点事情否则迟早出事。2. 拷贝与拼接四个函数的真实脾气拷贝拼接是字符串处理的主体也是事故高发区。四个函数我按危险程度从高到低说重点讲每个函数的失败模式长什么样。2.1 strcpy简单到让人放松警惕strcpy的语义干净得没话说从src第一个字节开始一路复制到\0并把它也复制过去返回dst。问题是它对dst的大小一无所知也永远不会知道。我在一个老的嵌入式项目里见过这种写法char name[16]; strcpy(name, get_user_input());get_user_input()返回的是从串口读回来的原始行长度完全由外部决定。测试的时候没人输入超过 15 个字符的东西上线第一周就被一条 40 字节的异常数据打穿了相邻的一个状态变量表现出来的现象是设备每跑几小时就自己重启一次日志里什么都看不到。这种 bug 的排查成本极高因为崩溃点离出错点可能隔了几百行。strcpy不是不能用前提是你能在一眼之内确认目标容量足够。比如char path[256]; strcpy(path, /etc/app/config.ini);字面量长度肉眼可数目标 256 字节这种就完全没问题。但凡源串来自外部输入、文件内容、网络数据、命令行参数就不该用strcpy。判断标准很简单这个 src 的长度我能不能在编译期确定能用不能换。顺带说一个常见误解strcpy的返回值是dst有人喜欢写strcpy(dst, strcpy(dst, src))这种嵌套看起来很聪明实际上如果dst和src有重叠区域行为是未定义的。别耍这种花活。2.2 strncpy名字骗人的典型代表strncpy是这批函数里被误解最深的。它的原始设计目的根本不是安全拷贝字符串而是从一个定长字段里提取内容——上世纪七十年代的那种固定长度的目录项、文件名域。那个场景下源数据是一个 14 字节的定长槽位里面可能没有\0你要把它搬到自己的缓冲区里。这个历史背景解释了它两个奇怪的特性特性一源串不够长时用零填充到 n 字节。你写strncpy(dst, ab, 100)它会往dst里写 100 个字节前两个是a、b后面 98 个全是\0。如果你只是想拷一个短字符串这个行为会白白浪费大量时间拷 3 个字节的活儿干了 100 个字节。特性二源串超长时不补终止符。你写strncpy(dst, abcdefgh, 4)dst里是a、b、c、d后面什么都没有。这四字节不是一个合法字符串而是一段没有结尾的裸数据。所以正确的写法永远是这个形状char dst[32]; strncpy(dst, src, sizeof(dst) - 1); dst[sizeof(dst) - 1] \0;三步缺一不可。第三步兜底防止源串恰好等于或超过缓冲区大小时没有终止符。这里的sizeof(dst) - 1而不是sizeof(dst)是给兜底的那个零留位置——虽然理论上你写sizeof(dst)再补零也对但留着更保险因为有些实现会在边界上做优化。注意dst必须是数组类型sizeof才有意义。如果dst是函数参数传进来的char *sizeof拿到的是指针大小4 或 8不是缓冲区大小。这个坑我在代码审查里见过太多次尤其是在重构把一个函数内联展开的时候sizeof悄悄变了含义而没人发现。2.3 strcat 和 strncat拼接的正确姿势strcat(dst, src)从dst的\0位置开始追加把src连同终止符一起接上去。它内部先做了一次strlen(dst)找尾部这意味着每一次strcat都是一次线性扫描。如果在循环里连续追加 N 个片段总复杂度是 O(N²)片段多的时候性能会很丑。更好的做法是维护一个游标指针自己推进char buf[256]; size_t used 0; buf[0] \0; for (int i 0; i n; i) { size_t need strlen(items[i]); if (used need 1 sizeof(buf)) break; memcpy(buf used, items[i], need 1); used need; }这段代码用memcpy带上了终止符一次扫描一次拷贝而且边界检查在拷贝之前。我更喜欢这个写法因为它把容量够不够这个判断显式摆出来了读代码的人一眼能看到防线在哪。strncat的正确用法是char dst[64] prefix:; strncat(dst, src, sizeof(dst) - strlen(dst) - 1);第三个参数算的是还剩多少空间给它填且留一个字节给终止符。很多人写成strncat(dst, src, sizeof(dst))这一行在dst非空的时候就一定越界因为strncat会在末尾额外补一个零实际写入量是strlen(dst) n 1。提示dst在调用strncat之前必须已经是一个合法字符串不能是未初始化的数组。未初始化的dst里没有\0strncat会从栈上乱找终止符行为完全不可预测。2.4 自己写一个安全拷贝的辅助函数在我的项目里一般会封一个这样的函数规避上面所有问题#include string.h #include stddef.h /* 安全拷贝返回实际写入的字符数不含终止符 */ size_t str_copy(char *dst, size_t cap, const char *src) { if (dst NULL || src NULL || cap 0) return 0; size_t len strlen(src); if (len cap) len cap - 1; memcpy(dst, src, len); dst[len] \0; return len; }这个函数有几点值得说。返回值给的是实际写入长度调用方可以判断是否发生了截断ret cap - 1且strlen(src) ret时说明被砍了。用memcpy而不是strncpy避免零填充的性能浪费也不用操心终止符补不补的问题。cap 0的判断看似多余实际上有人真的传过 0。配套一个拼接版size_t str_append(char *dst, size_t cap, const char *src) { if (dst NULL || src NULL || cap 0) return 0; size_t used strlen(dst); if (used cap - 1) return 0; return str_copy(dst used, cap - used, src); }这两个函数加起来不到 20 行能顶掉项目里 90% 的strcpy和strcat调用。写业务代码的时候人脑是不适合实时计算容量算术的把它抽象成函数把算术封进去出错率会降一个数量级。3. 比较与求长三个不写内存的函数也有坑这一类函数不往内存里写东西所以不会有越界写的风险但它们的坑在别的地方——返回值语义、无符号数、性能特征。3.1 strcmp 的返回值不是 -1 和 1标准里只规定了strcmp返回值的符号小于零、等于零、大于零。没有规定具体是 -1 还是别的数字。glibc 的实现里常常返回的是第一个不相等字节的差值你能看到 -32、100 这种值。所以下面这种写法是错的if (strcmp(a, b) 1) { /* 错 */ ... }在源串首字节相差不止 1 的时候这个判断永远不成立。正确写法只有三种if (strcmp(a, b) 0) { /* 相等 */ } if (strcmp(a, b) 0) { /* a b */ } if (strcmp(a, b) 0) { /* a b */ }还有个更隐蔽的问题很多标准库会把strcmp当成内建函数优化掉你在调试器里单步跟不进去或者看到编译器直接把它替换成一段 SIMD 指令。这不影响正确性但会让你在排查时产生困惑。比较用的是unsigned char语义。这意味着带重音符号的字符、中文 UTF-8 字节流比较出来的是字节序不是语言学意义上的顺序。要按语言习惯排序得用strcoll那是另一个话题了。3.2 strncmp判断前缀的标准工具strncmp最典型的场景是判断一个字符串是不是以某个前缀开头if (strncmp(cmd, --verbose, 9) 0) { /* 命中 */ }这里的 9 是strlen(--verbose)。手动写数字容易错写成strncmp(cmd, --verbose, strlen(--verbose)) 0更稳妥编译器一般会把strlen在字面量上折叠成常量。注意这个用法在cmd长度不足 9 的时候也安全因为strncmp遇到\0就停不会读过界。但如果cmd本身是个没有终止符的裸数组一样会出事——strncmp的刹车依赖终止符存在。前缀判断还有一个常被忽略的细节如果你要匹配的是完整的命令名光用前缀判断会把--verbose-extra也当成--verbose。要么比较完之后检查下一个字符是不是\0或空格要么干脆先按分隔符切好再比较。3.3 strlen 是 O(n)别在循环条件里调strlen返回size_t一个无符号整数类型。这个类型选择带来了一类经典的 bugif (strlen(a) - strlen(b) 0) { ... }a比b短的时候无符号减法会回绕成一个巨大的正数条件直接成立。正确写法是先转成有符号或者分开比较。性能上strlen每次调用都要扫一遍到终止符。写成这样就有问题了for (size_t i 0; i strlen(s); i) { /* 慢 */ ... }字符串长度是 10000这个循环就扫了 1 亿次字节。标准做法是开头取一次size_t len strlen(s); for (size_t i 0; i len; i) { ... }现代编译器在简单循环里有时能自己识别出这个模式做优化但别指望它——尤其是循环体里s可能被修改的时候编译器必须保守地重新计算。顺便说一个sizeof和strlen的混淆点。对数组char buf[32]sizeof(buf)是 32strlen(buf)是里面实际字符数。但对指针char *psizeof(p)是 864 位下和内容无关。这个区别在函数传参时会突然生效数组名传进函数就退化成指针sizeof立刻从缓冲区大小变成指针大小。这是我在新人代码里见得最多的错误没有之一。4. 内存家族memcpy 和 memset 的边界这两个函数语义最干净但也最容易因为太干净而被误用。它们不看内容只看字节所以用错的时候不会有任何提示。4.1 memcpy 只认字节数重叠是禁区memcpy(dst, src, n)从src搬 n 个字节到dst要求两块内存不重叠。重叠的时候行为未定义实践中可能表现为前面几个字节对、后面全乱因为实现里可能用了按块向量化的拷贝。需要处理重叠就用memmove它内部会判断方向重叠时从后往前拷。代价是多一次分支判断性能略低一点点绝大多数场景可以忽略。一个容易被忽略的重叠场景在同一个数组内部搬数据。char buf[64] 0123456789; memcpy(buf 2, buf, 8); /* 重叠未定义 */ memmove(buf 2, buf, 8); /* 正确结果是 0101234567... 的一部分 */很多人以为只有两个不同变量才可能重叠实际上同一个数组的区间搬移是最常见的重叠来源。第三个参数的类型是size_t注意不要传负数进去。写成memcpy(dst, src, -1)的时候-1会被隐式转成一个巨大的无符号数直接导致灾难性的越界写。编译器一般会警告但如果你用了强制类型转换或者中间变量警告就消失了。4.2 memcpy 的返回值与链式调用的坑memcpy返回dst设计意图是支持链式调用。但这个特性在实际代码里经常被滥用memcpy(a, b, n); memcpy(c, memcpy(a, b, n), m); /* 重复拷贝a 被写了两次 */第一行的结果被第二行覆盖前又拷了一次纯属浪费。更糟的是下面这种void *p memcpy(dst, src, n);如果dst是char *类型返回值是void *赋值给char *在 C 里可以隐式转换没问题。但如果是 C 编译就需要显式转换。跨语言编译的代码里经常在这里出问题。我的建议是永远忽略memcpy的返回值单独一行调用。链式调用省下的那几个字符换来的是阅读时的额外思考成本不划算。4.3 memset 只该用来清 0memset(dst, c, n)把dst开始的 n 个字节全部设成c的低 8 位。注意是每个字节都设成这个值不是把整个对象设成这个值。这个语义导致一个非常常见的错误int arr[10]; memset(arr, 1, sizeof(arr)); /* 你以为每个元素是 1实际是 0x01010101 */每个 int 的四个字节都被填成0x01结果是168430090x01010101。这不是编译器 bug是memset的定义决定的。所以memset真正安全的用法只有一个清 0。因为零的特殊性——所有字节都是 0 的时候无论整型、浮点、指针表示的都是 0 或空。这也解释了为什么老代码里到处是memset(s, 0, sizeof(s))。要把数组设成别的值用循环或者calloc它保证清零。C23 里有了memset_explicit但语义变化不大还是按字节。注意对含虚函数表指针的 C 对象、含std::string成员的类memset清 0 会直接摧毁内部结构后续析构必然崩溃。这条在 C 和 C 混编的项目里踩过不止一次因为.c文件里的习惯被带到了.cpp里。4.4 结构体清零的实操细节结构体清零有两个写法语义在大多数平台一致但细节有差别struct cfg c1; memset(c1, 0, sizeof(c1)); struct cfg c2 {0};第二种是初始化只在定义时可用编译器生成的代码通常就是一次memset或者几条存储指令效率不差。第一种是运行时赋值任何位置都能用。如果结构体里有指针成员清 0 之后它们是空指针用之前必须判空。如果结构体里有大数组memset会实打实写满整个大小几十 KB 的结构体频繁清零是有性能代价的热路径上要考虑清楚。还有一个细节memset的第二个参数是int但只有低 8 位有效。写memset(p, 0x100, n)和memset(p, 0, n)效果一样因为0x100 0xFF是 0。这种写法不会报错但会让读代码的人困惑半天。5. strchr简单函数里的两个细节strchr(s, c)在s里找字符c第一次出现的位置返回指向它的指针找不到返回NULL。看起来简单到没什么可说但有两个点值得单独拎出来。5.1 返回值必须判空再解引用char *p strchr(line, ); *p \0; /* 如果没找到 这里就是空指针解引用 */这是最典型的崩溃来源。正确的做法char *p strchr(line, ); if (p ! NULL) { *p \0; }第二个细节是c的类型是int但实际按char处理。传0或者\0的时候它会返回指向字符串终止符的指针——这个行为在标准里是明确定义的不是错误。有人利用这一点来获取字符串尾地址char *end strchr(s, \0); /* 等价于 s strlen(s)但可能更快 */不过在大多数实现里strchr找\0不一定比strlen快别为了这点性能做奇怪的替换。5.2 const 限定符的丢失问题标准里strchr的原型是char *strchr(const char *s, int c);参数是const char *返回值却是char *。这意味着你传一个 const 字符串进去拿回来的指针可以随便改——标准委员会当年这么定是为了兼容后来在 C 里改成了重载版本C 这边就留下了这个历史包袱。后果是这样如果你在一个接受const char *的函数里调用strchr编译器不会报错但你实际上获得了修改只读内存的能力。如果那个字符串是字面量写进去就是段错误。const char *s ab; char *p strchr(s, ); *p \0; /* 运行时崩溃字面量在只读段 */这种情况编译器不会给你任何提示。我的做法是拿到的返回值只读不写确实需要修改的先拷贝一份再处理。5.3 一个实战用法字段切分strchr在解析类代码里非常顺手。比如解析keyvalue形式的配置行char *line strdup(raw); char *eq strchr(line, ); if (eq) { *eq \0; const char *key line; const char *val eq 1; /* key 和 val 现在都可以直接用了 */ }注意strdup是 POSIX 的函数不在 C 标准里用之前确认平台支持或者自己封一层。它的内存需要free别漏了。如果要找的是最后一次出现用strrchr。要找一整段子串用strstr比如解析 HTTP 头的时候找\r\n\r\n。这些函数都在同一个头文件里用法和strchr一个套路返回值判空是铁律。6. 完整实操写一个配置串解析模块纸上说完了走一遍完整的实现。需求是给定形如nameapp;modedebug;level3的字符串拆成若干个 key-value 对每对长度有上限非法输入要能识别出来。6.1 接口与数据结构设计#define KV_KEY_MAX 32 #define KV_VAL_MAX 128 #define KV_ITEM_MAX 16 typedef struct { char key[KV_KEY_MAX]; char val[KV_VAL_MAX]; } kv_pair; typedef struct { kv_pair items[KV_ITEM_MAX]; size_t count; } kv_list; int kv_parse(const char *text, kv_list *out); void kv_dump(const kv_list *list);固定大小的数组而不是动态分配理由很简单配置项数量本来就可预期用定长能省掉一堆 malloc 失败处理出错面小很多。这个选择在嵌入式里几乎是默认的在服务端也可以接受只要上限设置得合理。6.2 核心解析逻辑#include stdio.h #include string.h int kv_parse(const char *text, kv_list *out) { if (text NULL || out NULL) return -1; out-count 0; const char *cur text; while (*cur ! \0) { if (out-count KV_ITEM_MAX) return -1; const char *seg_end strchr(cur, ;); size_t seg_len (seg_end ! NULL) ? (size_t)(seg_end - cur) : strlen(cur); if (seg_len 0) { cur (seg_end ! NULL) ? seg_end 1 : cur seg_len; continue; } const char *eq memchr(cur, , seg_len); if (eq NULL) return -2; size_t klen (size_t)(eq - cur); size_t vlen seg_len - klen - 1; if (klen 0 || klen KV_KEY_MAX) return -3; if (vlen KV_VAL_MAX) return -4; kv_pair *slot out-items[out-count]; memcpy(slot-key, cur, klen); slot-key[klen] \0; memcpy(slot-val, eq 1, vlen); slot-val[vlen] \0; out-count; if (seg_end NULL) break; cur seg_end 1; } return 0; }几个设计上的取舍值得说明。为什么用memchr而不是strchr找等号因为strchr会一直扫到整个字符串的终止符可能跨过当前段的边界。假设输入是a;bc处理第一段的时候strchr(cur, )会跑到第二段去找到的是b后面的等号然后算出klen是一个越界的巨大值。memchr限制了搜索范围在当前段内从根上避免了这类错误。这是个很细但很关键的点我第一次写这段代码的时候就在这里翻了车。为什么所有长度判断都写在memcpy之前因为memcpy不检查边界。先算后拷是这类代码的基本纪律顺序反了就是给自己挖坑。返回值用不同的负数区分错误类型方便调用方打印日志。如果只在内部用也可以简化成 0 和非 0。6.3 边界测试与验证测试用例我一般会覆盖这几组输入期望结果验证点a1;b2成功2 项正常路径a1;成功1 项尾部空段被跳过a1;;b2成功2 项中间空段被跳过a返回 -2缺少等号1返回 -3空 key超长 key返回 -3上限保护a1;b2;...超过 16 项返回 -1数量上限空串成功0 项边界情况跑测试的时候把-fsanitizeaddress打开任何一次越界写都会被立刻抓住并打印调用栈比事后用调试器回溯省太多时间。这个编译器开关我从五年前开始就在所有本地调试构建里默认开启抓到的越界比我手动 review 出来的还多。关于那个尾部空段的处理本来seg_len 0时我应该跳过但代码里写的是cur seg_end 1如果seg_end为 NULL 就会用错分支。这里其实有个隐患当空段出现在末尾且seg_end NULL时走的是cur seg_len那cur根本没前进会死循环。所以更稳妥的写法是在seg_len 0分支里统一处理if (seg_len 0) { if (seg_end NULL) break; cur seg_end 1; continue; }这种分支覆盖不全导致的死循环是字符串解析代码里的经典 bug特点是不崩溃、不报错就是 CPU 跑满。写完一定用空段的各种组合测一遍。7. 排查实录与速查表这一节是我这些年攒下来的问题清单基本都是被现场打脸之后记住的。7.1 崩溃和乱码的定位顺序遇到字符串相关的崩溃别急着单步调试先按这个顺序过一遍第一步看崩溃地址是不是很小。如果栈里显示访问了0x0000000000000003这种地址说明某个字符串指针是NULL然后被加了偏移或者是一个没初始化的小整数被当成指针用了。往下找最近一次给这个指针赋值的地方。第二步看目标缓冲区附近有没有被踩。相邻变量的值莫名其妙变了基本可以确定是越界写。用 AddressSanitizer 重新编译跑一遍它会在写越界的那一刻就停下来比事后猜高效得多。第三步看字符串是不是没有终止符。现象是打印出来的内容后面跟一堆乱码或者长度大得离谱。重点查strncpy的调用点、read之后有没有手动补零、malloc之后有没有清零。第四步看是不是用了重叠的memcpy。现象是拷完之后头几个字节对、后面全错。改成memmove试试。乱码问题还有个常被忽视的来源编码不一致。源文件是 GBK 保存的终端是 UTF-8 显示中文字符串看上去就是一堆问号或者方块。这种情况strlen返回的字节数也是对的只是显示层的问题别往内存错误上想。7.2 常见问题速查表现象最可能的原因定位方法字符串打印后面带乱码目标缓冲区无终止符检查strncpy后是否手动补零相邻变量被莫名修改越界写开 ASan 重跑程序在printf处崩溃传入的指针非法或未初始化打印指针值判空strlen结果异常大同上无终止符检查数据来源是否裸字节strncmp判断前缀失效长度参数写错或字符串未终止用strlen算长度替代手写数字memset后数组不是期望值按字节填充的语义误解除 0 之外改用循环赋值释构时崩溃C 混编对含对象的成员做了memset改用构造函数初始化拼接结果被截断strncat的 n 算错用cap - strlen(dst) - 17.3 几个我踩过的坑坑一sizeof在函数里失效。我一直有写strncpy(dst, src, sizeof(dst))的习惯直到有一次把一个函数从直接操作数组改成接收指针参数sizeof悄悄变成了 8而缓冲区实际只有 32 字节。代码编译通过测试也过因为测试数据短上线后才炸。后来我的规矩是函数参数里传容量别在函数内算sizeof。坑二strncpy的零填充拖慢性能。在一个日志模块里为了安全我把所有字符串拷贝都换成了strncpy并且传了 1024。日志行平均 40 字节结果每次拷贝都要写 1024 字节QPS 掉了一半。后来换成手写的str_copy性能立刻回来。这件事让我明白安全版本的成本是要算的不能无脑上。坑三memcmp比较结构体。这个不在标题里但同属内存家族顺手提一句。结构体里有 padding 字节内容未定义用memcmp比较两个逻辑相同的结构体会返回不相等。要比较就逐字段比或者用memset先清零保证 padding 一致但加了新字段又容易忘。坑四strcat在循环里拼接。一个拼接 200 个 URL 参数的地方用了循环strcat跑起来 CPU 直接 100%。原因是每次都从头找终止符总工作量是平方级的。换成维护游标指针的方案后耗时从 800 毫秒降到 2 毫秒。最后分享一个我现在的习惯新写的 C 文件开头把所有需要字符串操作的函数都在本地重新封一层str_copy、str_append、kv_parse这类业务代码里禁止直接调用原生strcpy/strcat。这个约束听着麻烦实际执行下来字符串相关的崩溃从每月几次降到了几乎没有。原因不复杂——把有风险的操作收敛到十几个函数里只需要 review 这十几个函数的正确性而不是几百个调用点。这件事的价值比记住任何一个函数的参数顺序都大。