C语言字符常量到字符串：五种定义方式与内存布局实测

1. 字母在C语言里到底是什么从字符常量到字符类型很多人学C语言的第一课就是printf(hello);但真正把C语言中字母的定义讲清楚的人并不多。我见过不少写了半年代码的朋友仍然说不上来a和a到底是什么类型、占几个字节、存在内存的哪个位置。这个模糊点会一直潜伏直到某天在字符串拼接、大小写转换、编码转换或者缓冲区越界的地方炸出来。字符串的根其实不在字符串而在字母——也就是字符常量和字符类型。把这一层看穿后面C语言中定义字符串的几种方式就不再是一堆要背的语法而是一组可以直接推导出来的内存模型。这篇内容适合两类人看一类是刚啃完指针、正在被char *和char []搞混的新手另一类是有项目经验但一直靠能跑就行过日子的开发者。前者能拿到一套从字符推导到字符串的完整逻辑链后者能在这篇里找到几个平时很少被点破的细节——比如sizeof(a)为什么不是 1比如char s[5] hello到底算不算合法比如为什么函数里的sizeof突然变小了。这些细节在教科书里往往一笔带过在实际调试里却能让人耗掉一整个下午。我按字符 → 字符串 → 内存布局 → 实测验证 → 踩坑排查的顺序铺开来写中间穿插我这些年遇到过、调试过的真实场景。代码都是可以拿去直接编译运行的输出结果也一并贴出来方便你对照自己的环境验证。1.1 单引号包住的那个东西类型其实是int先抛结论在C语言里用单引号括起来的单个字符比如a、0、\n叫做字符常量它的类型是int不是char。这一点跟很多人的直觉相反也跟C不同——C里字符常量的类型就是char。C标准里写得很明确整型字符常量的类型为int。这个结论最直接的验证方式就是sizeof#include stdio.h int main(void) { printf(sizeof(a) %zu\n, sizeof(a)); printf(sizeof(char) %zu\n, sizeof(char)); char ch a; printf(sizeof(ch) %zu\n, sizeof(ch)); return 0; }在常见的64位和32位平台上输出都是4、1、1。也就是说a按一个int来算而变量ch才按一个字节来算。为什么会这样设计因为字符常量本质上是一个整数值的书写形式编译器需要一种能表示所有字符编码值的类型来承载它int显然比char更安全——char只有8位而且符号性还不确定。理解了这一层很多看似奇怪的现象就有解释了。比如下面这段代码char c a 1; /* 合法结果是 b */ int i a 1; /* 合法结果是 98 */a 1这个表达式先做整型运算int int结果是int类型的98然后赋给char变量时发生隐式转换。整个过程没有溢出问题因为98在char的范围内。但如果你写char c a 300;那就是另一回事了——结果超出范围行为由实现决定。提示判断一个字母在C语言里是什么先看引号。单引号是字符常量类型int双引号是字符串字面量类型char[N]这个区分必须刻进肌肉记忆里。我当年在一份老代码里见过有人用if (str a)来比较编译能过因为str是指针指针和整数比较在某些编译选项下只是警告运行直接崩。这类问题追根溯源都是没把字符常量是整数这件事想明白。1.2 ASCII码表不是靠背的是推出来的说到字母就绕不开编码。ASCII 是最基础的一套映射规则把0到127这128个整数分别对应到控制字符、数字、大小写字母和标点符号上。很多人一上来就抱着一张表死记硬背其实完全没必要记住几个锚点就能推导出一整片。三个最关键的锚点字符0的值是48大写A是65小写a是97。剩下的都可以从这三个推字符区间起始值推导方式常见用途0到9480 数字数字字符与数值互转A到Z65A 序号大写字母遍历a到z97a 序号小写字母遍历大小写差值32a - A 32 0x20大小写转换数字字符差值-9 - 0 9字符转数值有了这张表一些平时要查文档的操作就可以直接手写/* 数字字符转数值 */ int digit_to_int(char c) { return c - 0; /* 7 - 0 7 */ } /* 大小写转换利用差值为 32 这一位 */ char to_upper(char c) { return (c a c z) ? (char)(c - 32) : c; } char to_lower(char c) { return (c A c Z) ? (char)(c 32) : c; }大小写转换这里有个很经典的小技巧32是0x20也就是二进制里的第5位从0开始数。大写字母和小写字母在 ASCII 上只差这一位所以c ^ 0x20也能实现翻转。但我要提醒一句这个技巧只对英文字母成立。如果传进来的是别的字节^ 0x20会把它变成一个完全不相关的值。所以我在生产代码里从来不用异或版本宁可多写两个比较可读性和安全性都更好。注意char - 0这种写法要求c确实落在0到9之间。如果输入是/值为47/ - 0会得到-1这个负数如果拿去当数组下标后果不堪设想。这个坑我踩过一次做一个配置文件解析器本来以为格式很规整结果某台机器上配置文件里多了一个空格数字解析函数把空格减成负数直接越界读了内存。好在只是个内部工具没出事但那次之后我所有类似函数里都加上了范围检查。1.3 字符变量的三个隐性细节符号性、位宽、提升char是C语言里的整型家族成员之一只保证至少8位。C标准给char留下了几个实现定义的空白这些空白在不同平台上可能表现不一致写可移植代码时必须留意。第一个是符号性。普通的char究竟是有符号还是无符号由编译器实现决定。在常见的桌面平台上char通常是有符号的取值范围-128到127。但char、signed char、unsigned char在标准里是三种不同的类型尽管它们的大小都是1。这意味着如果你把一个大于127的字节值存进普通char它可能变成负数。处理二进制数据、图片字节、UTF-8 编码的时候这个负号会引发一连串问题。第二个是位宽。标准只保证char至少8位CHAR_BIT宏才是它的实际位数。绝大多数平台是8位但写跨平台代码时用它来判断更严谨。第三个是整型提升。char参与算术运算时会先被提升为int。所以char c 100; c c;的结果是200不会溢出——因为运算发生在int层面。真正会发生截断的是赋值回去的那一刻char c (char)200;在8位有符号char上得到的是-56。#include stdio.h #include limits.h int main(void) { printf(CHAR_BIT %d\n, CHAR_BIT); printf(CHAR_MIN %d, CHAR_MAX %d\n, CHAR_MIN, CHAR_MAX); unsigned char uc 200; char sc (char)200; printf(uc %d, sc %d\n, uc, sc); printf(uc uc %d\n, uc uc); /* 提升为 int结果是 400 */ return 0; }在一个8位有符号char的环境里输出会是CHAR_BIT 8、CHAR_MAX 127、uc 200、sc -56、uc uc 400。这三行输出其实覆盖了字符类型最容易出事的三个位置。我的经验是凡是处理原始字节、编码、哈希、加密这类场景一律显式写unsigned char不要图省事用裸char。省下那几个字母后面排查问题时往往要还回去几十倍的时间。2. 定义字符串的五种主流写法及其取舍字符串在C语言里不是一种独立类型而是以\0结尾的字符数组这个约定。所有看起来在定义字符串的写法本质上都在做同一件事准备一块连续内存把字符依次摆进去末尾放一个值为0的字节。差别只在于这块内存从哪来、能不能改、生命周期多长、编译器帮你做了多少。把这几件事想清楚五种写法就自然区分开了。下面逐一拆解每种的适用场景和禁忌我都会标出来。2.1 字符数组逐字符初始化最笨也最可控最原始的方式是把每个字符列出来char s1[6] {h, e, l, l, o, \0}; char s2[] {h, e, l, l, o, \0}; /* 数组长度推导为 6 */ char s3[] {h, e, l, l, o}; /* 长度 5没有结尾符 */sizeof(s1)和sizeof(s2)都是6s3是5。注意s3这种情况它虽然是一个字符数组但严格来说不符合字符串的定义因为缺少结尾的\0。把它传给任何依赖结尾符的函数比如strlen、printf(%s, ...)都会一路读到数组边界之外。这种方式看起来啰嗦但在一些场景里反而最合适。比如你要构造一个包含\0的字节序列某些二进制协议里就有这时候用字面量初始化反而会被结尾符干扰逐字符写反而干净。再比如你想精确控制每个位置的值、或者初始化一个查表用的数组逐字符形式一目了然。我处理过一个定长报文头解析的场景头部有固定几个字节的标志位其中一个是0x00。如果用字符串字面量初始化读到那个0x00就停了改成逐字节写问题直接消失。2.2 字符数组用字面量初始化日常用得最多这是实际项目里出现频率最高的写法char s4[] hello; /* 长度 6包含 \0 */ char s5[6] hello; /* 刚好装下包含 \0 */ char s6[32] hello; /* 剩余部分全部补 0 */这三种都产生一个可修改的字符数组。s4由编译器推导长度是最省心的写法s5指定长度刚好容纳但如果以后字符串改长了忘了同步数组长度编译期或运行期就会出问题s6预分配了空间剩余部分会被零填充适合后面还要往里追加内容的情况。这里有一个经常被提起、但答案和很多人想的不一样的点char s7[5] hello;这行代码在C语言里是合法的。C标准允许用字符串字面量初始化字符数组时如果数组长度恰好等于字符数而不包含结尾符编译器会丢弃结尾的\0。但在C里这行代码无法通过编译。所以如果你在写同时兼容两种语言的头文件或者从C转过来写C很容易在这里卡住。提示char s7[5] hello;虽然合法但s7不是字符串。用它做printf(%s, s7)是未定义行为。我个人的规范是永远不这么写宁可在数组里多留一个字节。字面量初始化还有一个编译期的便利相邻的字符串字面量会被自动拼接。char s8[] hello , world; /* 等价于 char s8[] hello, world; */这个特性在写很长的提示文本、SQL 语句、或者带宏展开的日志模板时很好用可以把一段文本拆成多行可读性提升明显。2.3 字符指针指向字面量只读、共享、不能改另一种极常见的写法是char *p1 hello; const char *p2 hello;这两个指针指向的是字符串字面量编译器把它放在程序的只读数据区很多平台上就是.rodata段。字面量的存储期是整个程序运行期间所以指针指向的内容始终有效从函数返回也没问题。关键点在于不要通过这个指针修改内容。p1[0] H;在标准里是未定义行为在绝大多数现代平台上会直接触发段错误。这也是为什么现在几乎所有的编译器在开启警告时都会提示你把char *改成const char *——加上const之后编译器会帮你拦住这类修改。那为什么还留着char *这种写法因为C语言早年的历史遗留标准里字符串字面量的类型确实是非 const 的char[N]只是为了兼容老代码没有改。新写的代码尤其是团队协作的项目我建议统一写const char *让编译器当你的守门员。另一个容易忽略的点是资源共享const char *a hello; const char *b hello;在大多数实现里a b可能为真因为编译器会把相同的字面量合并成一份。但这不是标准保证的不能依赖它做任何逻辑判断。用strcmp比较内容才是正确做法用比较指针比较的是地址在字符串上几乎没有意义。写法内存位置可修改生命周期典型用途char s[] hello栈局部/ 静态区全局是随作用域需要改动的缓冲区char *p hello只读数据区否UB整个程序只读常量文本const char *p hello只读数据区否编译拦截整个程序推荐写法我个人的习惯是只要不需要改一律const char *只要需要改就用数组并在定义处初始化。中间态那种指针指向字面量但心里想着要改的写法是事故高发区。2.4 运行期填充strcpy、snprintf 与手动管理前面几种都是定义时就确定内容。实际项目里更常见的是运行期才知道内容这时候需要先准备缓冲区再往里填。char buf[64]; strcpy(buf, hello); /* 危险不检查目标大小 */ strncpy(buf, hello, sizeof(buf) - 1); /* 相对安全但仍需手动补 \0 */ buf[sizeof(buf) - 1] \0; snprintf(buf, sizeof(buf), %s-%d, id, 42); /* 推荐 */strcpy的问题在于它完全信任目标缓冲区够大。只要源字符串比你预留的长就会溢出而且溢出的部分可能覆盖相邻变量甚至覆盖返回地址。这类漏洞在历史上数不胜数。strncpy看起来是安全版本但它有个著名的坑当源字符串长度大于等于 n 时它不会在末尾补\0。这个函数最初是为定长字段设计的行为跟大多数人的直觉不符。我在代码审查里见过太多strncpy(dst, src, sizeof(dst))之后直接printf(%s, dst)的写法纯粹是在赌运气。snprintf是目前最推荐的选择它会保证在缓冲区大小大于0的情况下写入结尾符并且返回本想写入的长度可以用来检测截断int need snprintf(buf, sizeof(buf), %s-%d, id, 42); if (need 0) { /* 编码错误 */ } else if ((size_t)need sizeof(buf)) { /* 发生了截断内容不完整 */ }注意snprintf的返回值是如果不限制长度本该写入多少个字符不是实际写了多少。这个差别在做截断检测时至关重要。还有一点如果缓冲区是动态分配的sizeof(buf)得到的是指针大小而不是缓冲区大小必须自己保存长度。我在一次重构里就遇到过这种问题——函数签名从void f(char buf[64])改成void f(char *buf)之后里面的sizeof从64变成了8缓冲区直接被截断但因为字符串短测试没发现上线后才在一条长日志上暴露。2.5 堆上分配malloc free 的完整闭环当字符串长度在编译期无法确定或者需要跨函数返回、生命周期超出当前作用域时就得用堆#include stdlib.h #include string.h #include stdio.h char *make_greeting(const char *name) { size_t len strlen(name); /* 1 是结尾符7 是 Hello, 和 ! */ char *buf (char *)malloc(len 1 7 1); if (buf NULL) { return NULL; } snprintf(buf, len 1 7 1, Hello, %s!, name); return buf; } int main(void) { char *g make_greeting(world); if (g ! NULL) { printf(%s\n, g); free(g); } return 0; }这段代码里长度计算的1 7 1必须写清楚每个数字代表什么否则半年后没人看得懂。我在团队里推的规范是长度凑出来的地方一律加注释或者干脆用两倍余量加snprintf返回值检测宁可多分配一点也别算错。堆分配必须成对malloc配free。很多人的代码里问题不在忘了 free而在提前 free 之后继续用释放后使用或者同一次分配 free 了两次重复释放。这两种情况在测试环境里可能悄无声息在生产环境里就是随机崩溃。还有一个经常被忽略的替代方案C99 的变长数组和 C11 的可选特性strdup。strdup内部就是malloc strcpy返回的指针需要调用者free用起来方便但它不属于 C 标准的最基础部分跨平台使用前要确认可用性。3. 字符串表的组织方式一维玩明白了再看二维单个字符串的处理搞清楚之后下一步自然是一组字符串——比如命令行参数表、菜单项、错误码到提示文本的映射。这时候有两种主流结构选错了在内存和性能上都会吃亏。3.1 二维字符数组定长、连续、浪费char names[3][10] { tom, jerry, spike };这种结构在内存里是一整块连续的90字节。names[i]可以直接当char *用因为二维数组的每一行都是一个一维数组数组名会自动退化成指向首元素的指针。访问速度很快因为数据都在同一片缓存行附近。代价是每一行都必须按最长的那个字符串来分配空间。上面tom只用了4个字节含结尾符但被占用了10个。如果表里有几百项而且长短差距大浪费会非常可观。更麻烦的是任何一项超长都会导致编译期截断或者运行期溢出扩展性很差。我见过一个嵌入式项目用这种方式存配置项名称最初最多8个字符后来加了个新配置项需要12个字符整张表的维度全要改牵动了几十处代码。这不是二维数组的错是选型的时候没考虑增长。3.2 字符指针数组不定长、省内存、多一次跳转const char *names[] { tom, jerry, spike };这里names是一个指针数组每个元素占一个指针大小64位下是8字节。字符串本体仍然在只读数据区长度各不相同各占各的空间不浪费。代价有两层一是字符串本体分散在只读区的不同位置访问时需要多一次寻址缓存局部性不如二维数组二是指针数组本身占的内存3个指针24字节加上字符串本体总量可能比二维数组小也可能大取决于字符串长度分布。另外一个重要差别指针数组的元素可以指向任意地址所以可以在运行期改变指向甚至可以混用字面量和动态分配的字符串。这在需要动态构建列表的场景里非常灵活。但反过来说如果其中有动态分配的字符串你要记得逐个free二维数组则完全不需要操心释放问题。3.3 两种方式的内存布局对比与选型建议把两种结构放在一起看差异就清楚了对比项二维字符数组字符指针数组内存连续性完全连续指针连续内容分散空间利用率低按最长项对齐高按实际长度访问速度快缓存友好稍慢多一次间接寻址可修改性整体可改取决于指向内容扩展性差改动维度牵动全局好加一项只加一行释放管理无需释放动态内容需逐个释放适用场景固定数量的短字符串、嵌入式长字符串、不定长、需要灵活调整选型的判断标准其实很简单如果所有字符串长度接近且不会增长用二维数组如果长度差异大或者未来会变用指针数组。在资源紧张的嵌入式环境里还要看字符串总数和长度分布的乘积算一下哪种总占用更小。有一个细节值得单独提二维数组作为函数参数时形参必须写全除第一维之外的所有维度。void print_all(int n, char names[][10]); /* 正确 */ void print_bad(int n, char names[][]); /* 编译错误 */ void print_bad2(int n, char **names); /* 类型不匹配传入二维数组会出错 */原因在于编译器需要知道每一行有多长才能计算names[i]的地址。char **和char [][10]是完全不同的类型强行转换后按char **去访问二维数组得到的一定是乱码或者崩溃。这个错误在初学者里非常普遍因为两者的声明看起来确实挺像。4. 内存布局实测sizeof、strlen 与数组退化到这一步概念层面基本齐了。但字符串这块最容易翻车的地方往往不是不知道怎么定义而是搞不清手里这个东西到底是什么。sizeof和strlen的区别、数组名退化的时机是两把必须拿稳的尺子。4.1 sizeof 和 strlen 到底在数什么一句话概括sizeof是编译期运算符数的是这个对象占多少字节strlen是运行期函数数的是从给定地址开始到第一个\0之前有多少个字符。这两个定义听起来很简单但放在不同写法上结果差异很大定义方式sizeof结果strlen结果说明char a[] hello65数组长度含结尾符char a[32] hello325预分配全部计入 sizeofchar *p hello864位5数的是指针本身char a[] {h,e,l,l,o}5未定义无结尾符char a[10] {0}100全零首个字节即结尾sizeof之所以在数组和指针上差这么多就在于它看的是静态类型。数组的静态类型是char[N]所以是 N指针的静态类型是char *所以是指针大小。这也是为什么数组长度这种信息一旦经过函数传参就会丢失。提示sizeof对字符串字面量本身也有效。sizeof(hello)的值是6sizeof()的值是1。用这个来算缓冲区大小很稳比手写6可靠得多。4.2 一段完整可复现的验证代码下面这段代码把前面提到的几种定义方式集中验证了一遍可以直接编译运行#include stdio.h #include string.h #include stdlib.h #define SHOW(expr) \ printf(%-28s - %-10zu | strlen %zu\n, #expr, sizeof(expr), strlen(expr)) int main(void) { char a[] hello; char b[32] hello; char c[] {h, e, l, l, o, \0}; const char *d hello; char e[6]; char *f (char *)malloc(6); strcpy(e, hello); strcpy(f, hello); SHOW(a); SHOW(b); SHOW(c); SHOW(d); SHOW(e); SHOW(f); printf(sizeof(\hello\) - %zu\n, sizeof(hello)); printf(sizeof(h) - %zu\n, sizeof(h)); free(f); return 0; }在64位平台上典型的输出是a - 6 | strlen 5 b - 32 | strlen 5 c - 6 | strlen 5 d - 8 | strlen 5 e - 6 | strlen 5 f - 8 | strlen 5 sizeof(hello) - 6 sizeof(h) - 44.3 运行结果逐条解读a和c都是6说明数组长度由初始化列表决定包含结尾符。两种写法在内存上完全等价只是书写形式不同。b是32这是很多人第一次看到会愣住的地方——strlen明明只有5为什么sizeof是32因为b这个对象确实占了32个字节剩下27个字节被零填充。如果后面用strcpy(b, a much longer string)往里面写只要不超过32字节完全安全sizeof依然是32。所以用sizeof(b)作为写入上限在数组场景下是正确的做法。d和f都是8因为它们的静态类型都是指针。这也是为什么在函数内部对指针参数做sizeof基本没有意义——拿到的永远是指针大小。d指向只读区f指向堆二者在大小上完全一样但可修改性和生命周期完全不同这个信息只能靠代码规范来维护。最后两行是前面讲字符常量时提到过的结论字符串字面量的sizeof包含结尾符字符常量是int大小。4.4 数组传参退化为什么函数里 sizeof 变小了这是新手最容易困惑的现象也是我审代码时最常抓的问题#include stdio.h void bad_sizeof(char s[]) { /* 这里的 sizeof(s) 是 8不是数组真实长度 */ printf(inside: sizeof(s) %zu\n, sizeof(s)); } void good_sizeof(char s[], size_t n) { printf(inside: n %zu\n, n); } int main(void) { char buf[100] hello; printf(outside: sizeof(buf) %zu\n, sizeof(buf)); bad_sizeof(buf); good_sizeof(buf, sizeof(buf)); return 0; }输出会是outside: 100、inside: 8、inside: 100。原因很直接在C语言里数组作为函数参数时会退化为指向首元素的指针形参char s[]和char *s完全等价。所以函数内部看到的永远是指针sizeof自然是指针大小。正确的做法只有一条长度随指针一起传。要么像good_sizeof那样多传一个参数要么在数据结构里存长度要么约定用结尾符。三种方案各有适用场景但绝对不能指望在函数里用sizeof求出数组长度。还有一个类似但更隐蔽的退化在结构体成员里放数组是可以的sizeof会算上整个数组但一旦通过指针访问结构体成员的数组名同样会退化。我见过有人在结构体里定义char name[64]然后写了个函数接收char *name在函数里sizeof(name)想求64结果得到8缓冲区当时就被截断了而且因为日志恰好很短测试期间一直没发现。5. 踩坑实录与问题速查理论讲完落地还得靠踩坑经验。这一节我挑几个真实遇到过、而且新手很容易重复踩的问题展开。5.1 修改字符串字面量导致的崩溃现场char *p hello; p[0] H; /* 未定义行为多数平台直接段错误 */这段代码在很多老教材上能跑通因为它依赖具体实现。在只读段保护开启的现代系统上它会立刻崩溃。更麻烦的是有些编译器在优化时会把相同的字面量合并你改的是p[0]实际影响到的可能是另一个完全无关的字符串。解决办法很直接要改就别指向字面量。char p[] hello; /* 数组内容可改 */ p[0] H;或者用const char *让编译器提前拦住。这里有一个我自己的判断标准看到char *指向字面量一律改掉。如果确实只读加const如果确实要改改成数组或动态分配。中间那种模棱两可的写法早晚出事。5.2 缓冲区溢出与漏掉的 \0这一类问题覆盖面很广但核心就两个写得比缓冲区大以及忘了结尾符。char buf[8]; strcpy(buf, 0123456789); /* 溢出多写了3个字节含 \0 */char buf[8]; strncpy(buf, 0123456789, sizeof(buf)); /* 不补 \0buf 没有结尾符 */第二种情况更隐蔽。strncpy的行为是如果源长度大于等于 n就把前 n 个字符拷过去不补结尾符。所以buf里是8个字符却没有一个字节是0后面任何printf(%s, buf)都会一直读下去直到撞上一个0。推荐写法是把snprintf作为默认选择并且习惯性地检查返回值char buf[8]; int n snprintf(buf, sizeof(buf), %s, 0123456789); if (n 0 || (size_t)n sizeof(buf)) { /* 截断或出错按业务决定是报错还是接受截断 */ }如果确实需要用strncpy那就在后面手动补一刀buf[sizeof(buf) - 1] \0;。这行代码应该成为一种条件反射。5.3 字符处理函数的参数类型陷阱isalpha、isdigit、toupper这些函数来自ctype.h它们接受一个int参数但要求这个值要么是EOF要么能表示为unsigned char。如果直接把一个有符号的char传进去而它的值是负的比如某些编码下的字节行为是未定义的。char c (char)0xE4; /* 某个非 ASCII 字节有符号 char 下是负数 */ if (isalpha(c)) { /* 未定义行为 */ /* ... */ }正确写法是先转成unsigned charif (isalpha((unsigned char)c)) { /* ... */ }这个问题在处理中文、日文等多字节文本时特别容易触发。strlen返回的是字节数一个UTF-8编码的汉字占3个字节如果你按字节遍历并用isalpha判断很可能在某个负值字节上触发未定义行为。要做字符级处理就得先解码或者改用更合适的库。5.4 常见问题速查表现象可能原因排查方向处理方式程序在赋值字符串时崩溃修改了只读区字面量检查指针是否指向...改成字符数组或动态分配printf(%s)输出乱码后崩溃缺少\0结尾检查初始化是否漏结尾符补\0改用snprintf函数内sizeof变小数组退化为指针检查形参是否为char s[]显式传长度字符串被莫名截断strncpy未补结尾符检查拷贝长度与源长度关系手动补\0或用snprintf中文处理出现乱码按字节处理了多字节字符确认编码与遍历粒度用解码后的宽字符或专用库偶发崩溃、难以复现释放后使用或重复释放检查free与使用顺序用工具检测重构生命周期大小写转换结果异常用了^0x20处理非字母检查输入范围加范围判断别用位运算技巧长字符串比较结果不对用比较了指针检查是否用了strcmp改为strcmp或memcmp最后再分享一个我自己坚持了很多年的习惯每定义一个字符串变量就在心里问三句话——这块内存在哪栈、堆、只读区、能不能改、什么时候失效。三个答案都清楚了sizeof用错、越界、野指针这类问题基本就跟你没关系了。另外编译时把警告开到较高等级能提前拦掉很大一部分隐患。像丢弃字符串常量的 const 限定符这种提示很多人嫌吵直接关掉其实那正是编译器在帮你指出第 5.1 节里那个崩溃点。我带的项目里这类警告一直是按错误处理的改起来麻烦一次省下来的调试时间是以天计的。