1. 为什么sprintf值得单独拎出来讲

刚接触C语言那会儿，我对sprintf的态度是"能用就行"，直到有一次在嵌入式项目里做数据上报，格式化字符串写错了一个%d对应了double类型，程序不崩，但上报的数值全是乱码，排查了整整两天。从那以后我就明白，sprintf这类变参格式化函数，属于"用对了很顺手，用错了很难查"的典型代表。

sprintf是C标准库stdio.h里的函数，作用是把格式化的数据"打印"到一个字符数组里，而不是输出到屏幕。你可以把它理解成printf的"写内存版本"：printf往标准输出写，sprintf往你指定的缓冲区写。这个区别看着小，实际用途极大——拼装日志字符串、生成文件名、把数字转成字符串、构造协议报文、格式化时间戳，几乎任何需要"把多种类型的数据揉成一段文本"的场景，它都能顶上。

它适合谁来学？我的判断是：只要你在写C，迟早会用上。新手需要它来完成"数字转字符串"这种基础操作；进阶开发者需要它做日志、做序列化；嵌入式方向上的人更是绕不开它，因为很多场景下你连printf都没有，只能先sprintf到buf里再通过串口发出去。

但这里有个前提必须说清楚：sprintf本身不做任何边界检查，缓冲区多大、写进去多少，全靠你自己算。这也是它被诟病、被建议用snprintf替代的根本原因。所以这篇内容不会只讲"怎么用"，更会讲"怎么用不出事"——参数怎么对、长度怎么算、什么时候必须换函数，这些才是实战里真正值钱的部分。

下面我按"整体思路 → 核心细节 → 实操落地 → 问题排查"的顺序展开，中间会穿插一些我踩过的坑和实际项目里的做法，你可以对照自己的代码看看有没有类似隐患。

2. 整体设计思路与函数定位拆解

2.1 从函数原型看它的本质：一个"带格式的字符串拷贝"

先看原型，这是理解一切的基础：

int sprintf(char *str, const char *format, ...);

三个部分拆开看。第一个参数str是目标缓冲区指针，也就是"往哪儿写"；第二个参数format是格式控制字符串，决定"怎么写"；后面的...是变参列表，提供"写什么"。返回值是int，表示成功写入的字符数，不包含结尾的\0。这个返回值很多人忽略，但它其实很有用——比如你想知道拼出来的字符串有多长，直接接返回值就行，不用再strlen一次。

这里有个容易混淆的点：返回值是int，理论上可能出现负数（编码错误时），但绝大多数实现下只要是正常格式化就返回实际长度。我个人的习惯是，在需要长度的场景下接住返回值，但不会拿它做安全判断——因为真要溢出，函数已经写完了，返回值再准也晚了。长度必须在调用之前就算好，这个思路后面会反复强调。

理解sprintf的定位，关键是想明白它和几个"亲戚"的关系。printf是输出到流，sprintf是输出到内存，snprintf是"带长度限制的输出到内存"，fprintf是输出到指定流。它们共用同一套格式化规则，所以你只要掌握了格式串的写法，换函数只是换个"目的地"。这也是为什么很多人学完printf觉得sprintf不用学——规则确实一样，但内存安全的责任完全转移到了调用者身上，这才是差异所在。

2.2 它到底解决了什么问题：类型到文本的统一出口

C语言是强类型语言，int、float、char、指针各是各的，想把它们拼成一段字符串，理论上你可以对每种类型写一个转换函数，但那太蠢了。sprintf的价值就在于提供了一个统一的、声明式的转换出口：你用一个格式串描述"我要什么样的文本"，剩下的转换工作交给库函数。

具体来说，它解决三类问题。第一类是数值转字符串，比如把int的1234变成字符串"1234"，这个需求在C里其实挺尴尬的，因为没有内置的itoa（它不是标准函数），sprintf是最正统的做法。第二类是混合类型拼接，比如"temp=%d, volt=%0.2f"这种，一次调用把整数和浮点都塞进去。第三类是格式规范化，比如补零、定宽、十六进制输出、左对齐右对齐，这些用sprintf一行搞定，手写循环要写一堆。

我见过有同学为了避开sprintf，自己写了个int_to_str函数，结果负数处理错了、INT_MIN溢出了、前导零也没处理。这种轮子不是不能造，但标准库已经验证过几十年的东西，除非你有特殊约束（比如某些安全规范禁用该函数），否则没必要重造。真正需要花精力的是怎么安全地用，而不是要不要用。

2.3 方案选型的核心考量：为什么它"危险"却仍在被大量使用

sprintf最著名的问题就是不检查缓冲区边界。你给它一个char buf[10]，格式串却要写进去20个字符，它照样往里写，后面的内存就被踩了。这个行为的后果是不确定的：可能什么都没发生（刚好那块内存没用），可能改掉了旁边的变量，可能直接段错误。这种"不一定立刻出错"的特性，让它成为调试噩梦。

那为什么还在用？因为在很多场景下，缓冲区大小是你自己可控的。比如你知道最大就是拼一个IP地址，那char buf[16]就够了，格式串也固定，这种情况下用sprintf是安全的，而且比snprintf少一个参数、少一次长度计算，代码更干净。反过来，如果格式化内容来自外部输入（用户输入、网络数据），长度不可控，那就必须上snprintf。

我的选型原则很朴素：格式串和参数全在本地掌控内，用sprintf；有任何外部不可控因素，用snprintf。举个具体例子，拼日志行"[%s] code=%d"，其中%s是函数名——函数名是编译期确定的，长度可控，可以用sprintf；但如果%s是用户传进来的字符串，那必须snprintf，并且要算上它的最大可能长度。这个判断标准比"一律禁用"或"一律使用"都更实际。

还有一点值得说：snprintf虽然安全，但它有个行为差异——截断时返回的是"本应写入的长度"，而不是实际写入的长度。这个细节后面会专门讲，很多人在这儿栽过。

2.4 格式串的本质：一份微型"规格说明书"

我一直觉得格式串是C语言里被低估的设计。它本质上是一份运行时的规格说明，用极简的语法描述了"数据怎么变成文本"。一个格式说明符由几部分组成：%开头，然后是标志位（-左对齐、0补零、+显示正号）、宽度、精度（.n）、长度修饰符（l、ll、h）、最后是转换类型（d、u、f、s、x等）。

比如%08.3f，拆开就是：宽度8、补零、精度3位小数。理解了这个结构，你就能自己组合出需要的格式，而不用死记。我建议新手拿一张纸，把常用的几个组合写下来贴在显示器边上，用一周就记住了。

格式串的危险之处在于它和参数列表是分离的。编译器只能检查格式串本身的语法，无法完全校验后面的参数类型是否匹配（现代编译器加了-Wformat能查一部分，但变参的本质决定了它做不到全查）。所以%d对应了一个double，编译可能只给个警告，运行时读到的就是一堆垃圾值。这类错误不会崩，只会让数据悄悄错掉，是最难查的一类。

3. 核心细节解析与实操要点

3.1 常用格式说明符速查与易错对照

先把高频的列出来，这张表我建议直接存下来：

几个高频坑必须点出来。第一个是%f对应float——错。在变参传递中，float会自动提升为double，所以%f实际读的是double，你传float反而会被提升，能正常工作；但如果传的是double却用了%d，那就是灾难。第二个是%u和%d混用，值小的时候看不出问题，一旦超过INT_MAX，%d会输出负数，这个现象我在日志里见过好几次，本质是同一个二进制被按不同符号解释。

第三个是长度修饰符漏写。size_t是unsigned long（64位平台），用%u打印会截断一半；long long用%ld同理。这类错误在32位上可能正常，一换64位就暴露，属于典型的"移植时才炸"的问题。我的做法是，打印size_t统一用%zu，打印long long统一用%lld，养成肌肉记忆就不容易错。

注意：%c在变参中接收的是int（因为char会整型提升），所以传char变量是安全的，但传指针就是错的——这个错编译器不一定报。

3.2 宽度、精度与对齐：格式串里的三个"旋钮"

这三个概念是sprintf真正好用的地方，也是新手最容易搞混的地方。我的理解方式是把格式串想象成一个"格子"：宽度决定格子多宽，精度决定格子里内容的精细程度或最大长度，标志位决定内容在格子里怎么摆。

宽度就是最小字符数。%5d输出1234会变成1234（前面补空格），输出123456则原样输出——宽度是下限，不是上限。这一点很多人误以为是截断，其实不会。想要补零就用%05d，输出01234。补零和补空格的区别就是那个0标志位。

精度对浮点是小数位数，%.3f的3.14变成3.140。对字符串，精度是最大长度：%.5s处理"hello world"只输出hello，这是截断，和宽度的行为完全不同。这个差异我觉得挺反直觉的，但记住"浮点精度是补，字符串精度是截"就不会乱。

对齐用-，%-5d让内容靠左，右边补空格。默认是右对齐，这在拼日志表格的时候很有用。举个例子，我要拼一个对齐的输出：

char line[64]; sprintf(line, "%-8s|%6d|%8.2f", "sensor", 42, 3.14159); // 结果: "sensor | 42| 3.14"

宽度8左对齐的字符串、宽度6右对齐的整数、宽度8保留2位的浮点，拼出来是整齐的三列。手写循环做这个至少要二十行，还可能算错。

这里有个细节值得提醒：宽度可以用*动态指定，比如%*d，然后参数里依次传宽度和值。这在需要动态对齐的报表场景很有用，但可读性会下降，我一般只在不固定列宽的地方用。

实操心得：补零用于编号、时间、校验码这类场景，比如%06d生成000042这种固定长度的ID，方便后续按定长解析。别在普通数值上用补零，会让人误以为是字符串。

3.3 返回值与截断行为：一个被严重低估的细节

sprintf返回实际写入的字符数，不含\0。这个好理解，重点是和snprintf的对比，因为这是最容易出错的地方。

snprintf返回的是如果缓冲区足够大，本该写入的长度，而不是实际写入的长度。也就是说，发生截断时，返回值会大于你给的缓冲区大小减去1。这个设计有它的道理——你可以根据返回值判断"需要多大缓冲区"，从而动态分配或二次调用，但代价是：不能直接拿返回值当实际长度用。

我见过这样的代码：

char buf[16]; int n = snprintf(buf, sizeof(buf), "%s", long_string); // 然后按 n 长度处理 buf，错了！

如果long_string有100字节，n会返回100，但buf里只有15个字符加一个\0。按n去读buf，越界了。正确做法是用n >= sizeof(buf)判断是否截断，实际长度用strlen(buf)或min(n, sizeof(buf)-1)。

sprintf则没这个问题——它不截断，所以返回值就是真实长度（前提是你没溢出）。但反过来说，它没截断就是它危险的根源。这两者之间的取舍，本质是"安全但要多判断"和"简单但不安全"的取舍。

还有一个实用技巧：把返回值存起来，后面可以直接用，省一次strlen。比如拼完字符串要追加，直接把指针偏移到buf + n继续写，效率比反复strlen高。这种写法在拼长报文的时候很常见：

char buf[256]; int n = 0; n += sprintf(buf + n, "header:%d;", ver); n += sprintf(buf + n, "len:%u;", len); n += sprintf(buf + n, "data:%s", payload);

这段代码读起来有点炫技，但要清楚，前提是你已经确认过总长度不会超过256，否则buf + n会越写越远。我在项目里用这种写法时，一定会在旁边写一行注释标明最大长度估算，防止后面有人加字段加到溢出。

3.4%s与%n的两个特别注意事项

%s看着最无害，其实是溢出高发区。因为字符串长度完全由内容决定，你写char buf[32]，格式串是"name: %s"，传入一个50字符的名字，直接溢出。这类问题在测试时不容易发现，因为测试数据通常短，上线遇到长数据才炸。

我的处理方式是：涉及%s时，要么在格式串里限制长度（%.20s），要么用snprintf并把缓冲区大小算进去。%.20s这个写法很实用——它保证最多只取20个字符，即使传入的字符串更长也不会溢出（只要剩下的部分长度可控）。这在拼日志时特别合适，比如打印用户输入的前若干字符。

%n是个特殊说明符，它不输出内容，而是把"目前已写入的字符数"写回对应参数指向的int。功能上可以用来统计长度，但它有严重的安全隐患（可以被用来写内存），所以现代编译器和安全规范基本都禁用它。我的建议很简单：不要用%n，需要长度用返回值就行。

还有一个组合要小心：%%输出百分号是安全的，但如果你动态拼接格式串（比如从配置读取格式），一定要校验里面没有意外的%，否则可能触发未定义行为。动态格式串本身是个反模式，我基本不这么写。

注意：格式串和参数数量必须严格对应。多传参数通常无害（被忽略），少传参数会读到栈上垃圾值，行为不可预测。编译器-Wformat能查一部分，建议开启。

4. 实操过程与核心环节实现

4.1 环境准备与最小可运行示例

先把环境说清楚，这个很重要，因为不同平台行为有差异。编译器用GCC或Clang都行，建议开启警告：

gcc -Wall -Wextra -Wformat=2 -o demo demo.c

-Wformat=2会把格式串和参数类型的匹配检查开到较严的级别，能提前抓出%d对double这类错误。MSVC对应的是/W4，也能查一部分。这个编译选项我强烈建议常开，它是成本最低的防线。

最小示例从一个完整的小程序开始，覆盖几种常见用法：

#include <stdio.h> int main(void) { char buf[128]; int count = 42; double volt = 3.14159; const char *name = "sensor_a"; int n = sprintf(buf, "%s: count=%d, volt=%.2f", name, count, volt); printf("result=[%s]\n", buf); printf("length=%d\n", n); return 0; }

输出是result=[sensor_a: count=42, volt=3.14]，长度34。n可以直接当长度用，因为sprintf的返回值就是实际写入数。

这里算一下缓冲区该开多大：字符串sensor_a是8，: count=是8，42最多11（含负号），, volt=是7，3.14按double最大可能……其实浮点格式化后的长度不好精确估，保守按"整数部分3位+小数点+2位小数+符号+可能的溢出表示"算，留20字节余量。总的128是绰绰有余的。这种"逐段估算再加余量"的方法，就是sprintf安全使用的核心心法。

4.2 参数计算过程实录：一次缓冲区大小的完整推导

光说方法不够具体，我拿一个实际场景完整走一遍。需求：生成文件名，格式为log_YYYYMMDD_HHMMSS_序号.txt，序号最大9999。

逐段列出来算：

• log_：4字节
• YYYY：4字节
• MM：2字节
• DD：2字节
• _：1字节
• HH：2字节
• MM：2字节
• SS：2字节
• _：1字节
• 序号：最大4字节（9999）
• .txt：4字节
• 结尾\0：1字节

加起来是29字节。取整开32，留3字节余量。如果有人后来改了序号...

等一下，这里有个真实的坑：如果有人后来把序号改成最大99999，4字节就变5字节了，缓冲区就不够了。所以我在代码里会加一个静态断言或者注释，标明这个数字的依据。更好的做法是用宏定义各段长度，让改动集中在一处：

#define SEQ_MAX_LEN 4 char filename[4+8+1+6+1+SEQ_MAX_LEN+4+1]; sprintf(filename, "log_%04d%02d%02d_%02d%02d%02d_%04d.txt", year, month, day, hour, min, sec, seq);

%04d和%02d保证了定长，这一点很关键——如果依赖数值本身的位数，长度就是变的，估算就没法精确。用补零强制定长，缓冲区大小才有确定的上界。这个技巧我在做协议报文时用得最多，所有字段都定宽，整个报文长度就是常数，安全性和可解析性都上去了。

实际运行验证一下，year=2024, month=3, day=15, hour=9, min=5, sec=7, seq=42，输出log_20240315_090507_0042.txt，数一下是29个字符，加上\0正好30，缓冲区32够用。

4.3 三种典型场景的完整实现

场景一，数值转字符串并按定长补零。这个需求在生成订单号、设备编号时非常常见：

char code[16]; sprintf(code, "%010d", 12345); // 输出 "0000012345"，10位定长

这里为什么用补零而不是补空格？因为后续如果需要按定长切分解析，补零能保证长度恒定，补空格在传输过程中可能被截掉尾部空格，导致长度变化。这个细节在跨系统交互时特别要注意。

场景二，十六进制输出，做协议调试时必备：

unsigned char data[] = {0xDE, 0xAD, 0xBE, 0xEF}; char hex[32]; int off = 0; for (int i = 0; i < 4; i++) { off += sprintf(hex + off, "%02X", data[i]); } // 输出 "DEADBEEF"

%02X保证每个字节两位，不足补零。如果写成%X，0x0A会输出A而不是0A，解析的时候就对不上位置了。这类定宽十六进制的写法，我在做数据抓包分析时天天用。缓冲区32是安全的，因为4个字节最多8个字符加\0。

场景三，浮点格式化与精度控制。浮点是最容易出意外的地方：

char val[32]; double v = 0.1 + 0.2; // 经典的浮点误差 sprintf(val, "%.10f", v); // "0.3000000000" sprintf(val, "%.20f", v); // "0.30000000000000004441" sprintf(val, "%g", v); // "0.3"

这段值得细说。0.1 + 0.2在二进制浮点下不等于0.3，打印10位看着正常，打印20位就露馅了。这不是sprintf的错，是浮点表示本身的局限。所以做数值输出时，精度要按实际需要给，别盲目给高精度，否则用户会看到一堆本不该出现的尾数。%g会自动选更紧凑的表示，适合日志；%.2f适合金额——但金额其实更建议用整数分单位存储，这是另一个话题了。

实操心得：缓冲区开多大，我通常按"最大可能长度 + 32"来给，这32是留给极端情况（比如浮点变成inf、nan，或者数字位数算错）的余量。宁可浪费几十字节，也不要冒溢出的风险，内存现在没那么金贵。

4.4 与snprintf的切换：什么时候必须换

前面说过原则，这里给具体的切换动作。凡是满足以下任一条件的，我会立刻换成snprintf：

• 格式串里有%s，且来源不可控（用户输入、配置、网络数据）
• 缓冲区大小是动态的，或者接近临界值
• 代码要长期维护、多人协作（防的是别人加字段）

切换本身很简单，加一个长度参数：

char buf[64]; // 原来 sprintf(buf, "user=%s, id=%d", username, uid); // 改成 snprintf(buf, sizeof(buf), "user=%s, id=%d", username, uid);

但要注意两点。第一，sizeof(buf)只在buf是真数组时有效，如果buf是函数参数（已退化为指针），sizeof拿到的是指针大小（8），不是缓冲区大小。这个坑非常经典，我见过不止一次。正确做法是把长度一起传进来，或者用宏封装。

第二，截断的处理。snprintf截断后内容是"能放多少放多少"，可能截在半个多字节字符中间（中文场景），也可能截成一个看起来正常但语义不完整的字符串。所以截断要判断：

int n = snprintf(buf, sizeof(buf), "user=%s", username); if (n >= (int)sizeof(buf)) { // 发生截断，需要记录告警或扩大缓冲区 }

这个判断我一般会加上，尤其是日志里，截断丢信息比直接报错更难查。有些项目会封装一个带检查的宏，把n >= size的情况上报，我觉得这个做法值得抄。

还有一个替代思路：先用snprintf(NULL, 0, ...)算出所需长度，再malloc。这个技巧在做动态拼接时很有用：

int need = snprintf(NULL, 0, "%s/%s", dir, file); char *full = malloc(need + 1); snprintf(full, need + 1, "%s/%s", dir, file);

snprintf在size为0时不会写任何东西，只返回所需长度，这是标准规定的行为。这样两遍调用的写法，比拍脑袋估一个"应该够大"的缓冲区靠谱得多，代价是多一次格式化计算。路径拼接、SQL构造这类长度不好估的场景，我倾向用这种方式。

5. 常见问题与排查技巧实录

5.1 问题速查表

这张表里的每一条，我基本都在实际项目里遇到过。尤其第一条和第二条，占了绝大多数。

5.2 三个真实踩坑记录的复盘

第一个坑是类型不匹配。当时做传感器数据上报，代码是sprintf(buf, "temp=%d", temp)，而temp是float。编译只给了个警告（当时没开-Wall），运行后输出的数值毫无规律，一会儿正一会儿负。原因很简单：float在变参中提升为double占8字节，%d只读4字节，读到的内容完全不是那个数。修复就是改成%.2f。这个坑教我的第一件事是开警告，第二件事是变参函数没有类型检查，全靠自己。

第二个坑是缓冲区计算漏了结尾。有段代码拼一个16字符的固定报文，缓冲区开了char buf[16]，格式串恰好写满16个字符，没有给\0留位置。函数写完之后，\0写到了缓冲区外面，把相邻的一个变量低字节清零了。那个变量是状态标志，被清零后程序进入了错误分支。这种问题靠单步调试都很难发现，因为出错点和使用点隔得很远。后来我养成的习惯是：估算长度时永远把\0算进去，宁可多留一个。

第三个坑是sizeof用于函数参数。我封装了一个日志函数，参数是char *buf，里面用snprintf(buf, sizeof(buf), ...)。sizeof(buf)拿到的是指针大小8，于是每次只写7个字符就被截断，日志全是残句。这个错误的隐蔽性在于，代码看起来很标准，snprintf、sizeof都用对了样子，但语义是错的。修复是把长度作为参数传进来，或者用宏在调用点展开、利用sizeof的真实数组大小。这个模式后来我统一改成了宏封装加_Static_assert检查。

5.3 检测手段：把问题在写完之前抓出来

光靠眼睛看代码是靠不住的，我现在的做法是加两道自动防线。

第一道是编译警告加静态检查。除了-Wall -Wextra -Wformat=2，还可以上一些静态分析工具，它们能查出"缓冲区可能溢出""格式串参数不匹配"这类问题。把警告当错误处理（-Werror）也是个好习惯，虽然一开始会改一堆代码，但改完之后整体质量明显提升。

第二道是运行时的检查。调试阶段我会用内存检查工具跑一遍，它能在越界发生的瞬间定位到具体位置，比事后排查效率高一个数量级。这对sprintf这种"越界了也不一定立刻崩"的函数尤其有价值。虽然它拖慢运行速度，但只在调试时开，不影响发布。

还有个小技巧：写一个自己的包装宏，在调试版本里检查长度，发布版本里去掉。比如：

#ifdef DEBUG #define SAFE_SPRINTF(buf, ...) do { \ int _n = snprintf(NULL, 0, __VA_ARGS__); \ if (_n >= (int)sizeof(buf)) { \ fprintf(stderr, "overflow risk at %s:%d\n", __FILE__, __LINE__); \ } \ } while (0) #endif

这个思路不是要替代正确的写法，而是在开发期多一层网。它不能捕获所有情况（比如buf是指针时就失效了），但对数组形式的缓冲区很有用。

5.4 几条不那么"文档化"的经验

关于性能：sprintf比手写拼接慢，但绝大多数场景下这点开销可以忽略。我做过一个粗糙的对比，拼同样长度的字符串，sprintf比纯memcpy加手写转换慢几倍。但如果这个操作每秒只做几千次，那这点差异完全不影响；只有在你用性能分析工具确认它确实是热点时，才值得优化。过早优化是另一种坑。

关于可读性：一段复杂的格式串，不如拆成几行snprintf追加。我见过一个%s套十几层的格式串，改一个字段要数半天。可读性和正确性其实是一回事——看不懂的代码，改错的概率就高。

关于日志里的字符串：日志中拼用户数据，永远用%.Ns限长。日志本来就不是完整数据归档，截断反而更安全，而且能防止超长日志把磁盘写满或者把日志系统打挂。这个做法在线上救过我一次。

关于中文：中文字符在UTF-8下是多字节，按%.Ns截断可能截在半个字符中间，输出乱码。如果内容含中文，要么不截断、保证缓冲区足够，要么用能识别字符边界的处理方式。这个细节在处理用户昵称、备注这类字段时尤其要注意。

6. 我个人的使用习惯与几点提醒

写到这里，把我在实际项目里沉淀下来的几条习惯说一下，供你参考。

第一条，缓冲区大小不写裸数字，用宏定义或者sizeof推导，并在旁边注明"这个数字怎么来的"。我现在的代码里，只要涉及sprintf，那个缓冲区定义上方一定有注释写着各段最大长度的估算依据。这不是形式主义，我吃过亏——隔了半年回来加一个字段，忘了缓冲区是卡着边算的，直接溢出。

第二条，格式串和参数列表尽量写在同一行或者紧挨着。拆得太开，改参数时容易漏改格式串。这个看起来是格式问题，实际上是正确性问题。我见过格式串在上一行、参数在下一行、中间隔了两行的写法，维护起来非常痛苦。

第三条，涉及固定格式的（时间、编号、协议字段），优先用补零定宽（%04d、%02X），让输出长度成为常数。这样缓冲区大小就有确定上界，安全性从"估计"变成"证明"。这一条对需要解析的场景还额外有好处——定长字段可以按固定偏移切，解析代码也简单了。

第四条，养成"能截断就用截断"的判断：凡是外部来的字符串，格式串里加%.Ns限制最大读取长度。这个动作只是一次按键的事，但能挡住大多数由于输入超长导致的溢出。我一般给日志类字段限32或64，给标识符类字段限64或128，具体看业务。

最后一点想说的是，sprintf这类函数的"正确用法"其实是建立在"你知道自己在干什么"之上的。它不是坏函数，它的危险来自它把边界责任完全交给了调用者。你把边界算清楚、把类型对好、把外部输入限住，它用起来又快又干净；你偷懒不做这些，它也不会当场报错，只会在某个意想不到的时候给你一下。所以与其纠结用不用它，不如把上面那几个基本功练扎实——这才是真正的护身符。

如果你现在的项目里还大量用着没做边界控制的sprintf，我的建议是先开编译警告，把格式串和参数类型不匹配的清理掉，然后再逐个评估哪些地方缓冲区不够。分两步走，改动可控，也能逐步体会到"算长度"这件事的价值。