C语言printf与scanf深度解析：格式化I/O、缓冲区与中文乱码避坑指南

1. 为什么printf和scanf值得你花一整篇来搞懂

先说个反直觉的事：这两函数几乎出现在每一本C语言教材的前三十页，但我在代码评审里见过的输入输出相关bug，比指针越界还多。指针错了起码段错误能让你立刻发现，printf和scanf出错往往是程序"看起来能跑"，结果全错或者偶尔卡死，排查起来最要命。

所以这篇不是教你背格式符，而是把这两个函数从底层行为到工程用法完整拆一遍。你可能是刚学C语言的学生，也可能是写了两三年却在中文乱码和缓冲区问题上反复折腾的开发者，无论哪种，读完你应该能回答这几个问题：为什么scanf("%d", &n)有时候像被跳过了？为什么printf在Linux下和Windows下表现不一样？为什么日志模块里printf会被"吞掉"？

先说结论：printf和scanf的本质是格式化I/O。格式化负责把内存里的二进制数据变成人能读的字符序列（输出），或者把字符序列解析成内存里的二进制数据（输入）。这个"格式化"过程里藏着的坑，比大多数人以为的多得多。后面每一节我都会给出能直接跑的实验代码和避坑经验，尽量让这篇文章既当教程又当排查手册用。

2. 格式符的完整语法：从%5.2f到%-10.3s，每一个字符都有意义

2.1 格式符的完整结构

很多教程讲printf就是列个表：%d整数，%f浮点，%s字符串，然后让你背。但实际上一个完整的格式控制符长这样：

code复制%[标志][宽度][.精度][长度修饰符]转换类型

方括号里全是可选项，但每一项单独拎出来都有讲究。我遇到过一个真实案例：同事要打印一个表格，要求学号占10位左对齐，成绩保留2位小数右对齐，他写的是printf("%10d %6.2f\n", id, score)，结果学号右对齐了，跟表头对不上。后来我提示他加负号，改成%-10d，才正常。问题就出在他不知道标志位里的负号代表左对齐。

完整的标志位有这么几个：

宽度就是最小输出宽度，注意是"最小"不是"最大"。如果实际内容比宽度长，宽度会被忽略，不会截断。这个特性在打印长字符串时特别容易踩坑：你写printf("%10s", str)，如果str超过10个字符，它照样完整输出，不会截断。想截断？那就得靠精度，比如%.10s表示最多取10个字符。

2.2 精度与宽度的组合逻辑

精度的小数点后面那部分，很多人一直是"凭感觉"用的。拿%5.2f来举例，它的完整含义是：总宽度至少5个字符，其中小数点后有2位。

但这里有个经典的认知错误：宽度5是先满足精度之后才计算的。也就是说，printf("%5.2f", 3.14159)会先做四舍五入变成3.14（占4个字符），再补一个空格变成" 3.14"，总共5字符。如果写成printf("%5.2f", 1234.567)，精度保留后是1234.57，已经6个字符了，超过了宽度5，宽度就被忽略，直接输出"1234.57"。所以宽度和精度不是同时作用的，精度优先。

精度对不同类型的含义完全不一样，这个表值得收藏：

我在写报表模块的时候，用%.2f做金额对齐，用%.3e做科学计数法的数据对比，用%.5s截断过长的日志标签，这三个组合下来基本覆盖了大部分格式化场景。

2.3 长度修饰符的跨平台意义

%d、%u、%f这些问题不大，但一旦涉及long、long long、size_t，你得特别注意长度修饰符。int是4字节，long在Windows的LP64模型下是4字节，在Linux的LP64模型下是8字节，这个差异坑过无数从Windows转到Linux开发的人。

• %ld用于long，%lld用于long long
• %zu用于size_t（注意是字母z不是数字2）
• %zd用于ssize_t
• %lf在printf里跟%f等价（都是double），但在scanf里%f是float*，%lf才是double*，这个不对称性让很多人栽过

有一个我实际踩过的坑：在64位Linux下用%d打印size_t变量，值直接变成0或者诡异的数字。原因是size_t是8字节无符号，被%d当成4字节有符号来解析，内存布局对不上。编译器还会警告，很多人忽略警告，结果就是线上日志里出现负数长度。安全做法是统一用%zu。

2.4 printf的返回值：几乎没人看但关键时刻救命

printf返回的是成功输出的字符数，如果发生错误返回负值。这个返回值在正常业务里确实没人用，但有一个场景它非常关键：在嵌入式或者串口调试的环境里，数据可能被截断，你要检查printf返回值是否等于预期的字符串长度，不等就得重发。

格式符这部分，我建议你在自己的开发环境里把上面每个例子都跑一遍。花十分钟看看实际输出，比背十遍表格都管用。肉眼确认过对齐效果以后，写表格代码就不再需要反复试错。

3. scanf的缓冲区陷阱：你的程序为什么"卡住"或者"跳过输入"

3.1 一个几乎每个人都遇到过的经典场景

很多初学C语言的人都碰到过这个问题：

c复制int n;
char c;
printf("请输入一个数字: ");
scanf("%d", &n);
printf("请输入一个字符: ");
scanf("%c", &c);
printf("你输入的数字是%d，字符是%c\n", n, c);

运行起来你会发现，第二个scanf根本没有等你输入，直接就把一个换行符读走了。c变量存的是'\n'，程序看起来就像"跳过"了第二次输入。

这事儿的根源在于：scanf读数字的时候，会在缓冲区里留下一个换行符。第二次用%c读的时候，它看到缓冲区里第一个字符就是'\n'，直接就消费掉了，压根不阻塞等待键盘输入。

3.2 缓冲区残留的完整机制

理解这个问题需要知道scanf消费输入的规则。scanf读取数据时，会忽略前导空白字符（空格、制表符、换行），这个"忽略前导空白"只对%d、%f、%s这些格式有效，唯独%c不忽略。所以缓冲区里残留的换行符就被%c原样读走了。

这不是"bug"，而是设计如此。关键是要在%c前面加一个空格，强制跳过前导空白：

c复制scanf(" %c", &c);

3.3 输入类型不匹配时的死循环

另一个经典坑是用户输入的类型跟格式符不匹配。比如你要求输入整数，用户敲了个abc：

c复制int n;
while (scanf("%d", &n) != 1) {
    printf("输入无效，请重试: ");
}

如果用户真的输入了abc，这个循环会无限刷屏。为什么？因为scanf遇到无法解析的内容时，会把那个字符留在缓冲区里，然后立即返回。下次循环再次尝试，还是同样的abc，还是解析失败，陷入死循环。你必须在失败时主动把缓冲区里的非法字符消费掉：

c复制int n;
while (scanf("%d", &n) != 1) {
    // 清空本行输入，直到消费掉换行符
    int ch;
    while ((ch = getchar()) != '\n' && ch != EOF)
        ;
    printf("输入无效，请重试: ");
}

3.4 fflush(stdin)为什么不行

网上很多教程教你用fflush(stdin)清空输入缓冲区，我可以负责任地告诉你：这是未定义行为。C语言标准明确规定fflush只对输出流有效，对输入流的调用行为是未定义的。在Windows的某些编译器上它碰巧能用，在Linux的glibc上基本无效，而且哪怕能用也只是清空了stdio库的缓冲区，如果底层文件描述符里还有数据，照样有残留。工程上不要依赖这个。

我实际工作中总结出一个理念：想安全地从键盘读输入，优先用fgets + sscanf，而不是直接scanf。

c复制char line[128];
int n;
fgets(line, sizeof(line), stdin);
if (sscanf(line, "%d", &n) != 1) {
    // 处理输入错误
}

fgets负责从stdin读一整行，sscanf负责从这行字符串里按格式解析。这样做有三个好处：缓冲区残留问题天然消失（每次都是干净的一行）；输入错误可以整行丢弃重新读；不会出现上面那种死循环。代价是代码多写几行，但稳定性提升非常明显。

3.5 scanf的返回值是必须检查的

写生产级代码时，scanf的返回值不能忽略。它返回成功赋值的参数个数。你写scanf("%d %d", &a, &b)，成功解析两个整数就返回2，只解析一个就返回1，一个都没解析成功就返回0，如果文件结束了就返回EOF（负值）。

许多线上崩溃或者数据错乱的bug，源头就是没检查返回值。比如你从配置文件中读取两个整数，但文件只有一行一个整数，第二个scanf直接读不到，a和b的值就可能残留上一次的状态（旧值），这在循环里会导致一系列连锁错误。检查返回值是防御性编程的第一道关口。

4. 中文乱码的根源与控制台编码：别再一股脑setlocale了

4.1 乱码到底是怎么产生的

中文乱码大概是中文开发者跟printf之间最多的纠纷。很多人一看到输出乱码就无脑加setlocale(LC_ALL, "")或者SetConsoleOutputCP(CP_UTF8)，但不理解根源的话，加再多也白搭。

乱码的本质是编码不匹配。源头程序里存的字符串是A编码，控制台或者终端按B编码解码，如果A和B不一致，显示出来就是乱码。C语言源文件本身有一个编码（一般是UTF-8），编译器把字符串字面量按源文件编码存进可执行文件，运行时控制台又按它自己的编码来显示，这三层的编码关系必须理清楚。

4.2 Windows和Linux的典型差异

Windows和Linux在这件事上的行为差异极大。Linux的终端默认都是UTF-8，大家普遍用UTF-8保存源文件，所以几乎不出乱码。Windows的cmd默认是GBK/CP936（控制台代码页），VS的源码也经常是GBK，所以Windows下只要稍微操作不当就乱码。

如果你的源文件是UTF-8，但在Windows cmd里直接printf中文，多半会乱码。原因就是cmd默认用GBK解码，而UTF-8的中文字节序列在GBK里会解析成完全不同的字符。解决思路有两条：

1. 把cmd的代码页改成UTF-8：在程序开头调用SetConsoleOutputCP(CP_UTF8)，或者在cmd里执行chcp 65001。
2. 让源文件保持与cmd一致的编码：把源码存成GBK（在VS里选对应编码保存）。

我个人的建议是统一UTF-8，因为这是跨平台唯一稳定的方向。程序开头这样写：

c复制#ifdef _WIN32
#include <windows.h>
#endif

int main(void) {
#ifdef _WIN32
    SetConsoleOutputCP(CP_UTF8);  // 让Windows控制台按UTF-8解码输出
    SetConsoleCP(CP_UTF8);        // 让Windows控制台按UTF-8解码输入（scanf中文时需要）
#endif
    printf("你好，世界\n");
    return 0;
}

但要注意：SetConsoleOutputCP只影响控制台的代码页，如果你把输出重定向到文件（后面会讲），这个调用就无效了。重定向到文件时，写入的字节就是程序内部存储的字节，文件保存的是什么编码就看你源文件是什么编码。

4.3 宽字符与wprintf：绕开乱码的另一条路

除了控制台代码页，C语言本身还提供了宽字符方案。wprintf配合宽字符串L"你好"理论上能避免编码问题，因为宽字符在内存里统一用wchar_t保存（Windows下是UTF-16，Linux下是UTF-32），不依赖源文件编码。

但宽字符方案在Windows下依然需要预先设置：

c复制#include <wchar.h>
#include <locale.h>

int main(void) {
    setlocale(LC_ALL, "");
    wprintf(L"你好\n");
    return 0;
}

这里的setlocale(LC_ALL, "")会读取系统默认区域设置，让程序知道当前用户的语言环境。在Windows下配合宽字符输出，中文基本能正常显示。

我的经验是：普通的控制台调试输出，用窄字符+SetConsoleOutputCP(CP_UTF8)就够了；如果要做国际化多语言支持，直接用宽字符方案，至少不用每个平台单独调编码。但宽字符在Linux的打印性能上有一定损耗，涉及高频日志输出时要注意效率。

4.4 解决乱码的排查顺序

如果你已经乱码了，按这个顺序排查：

1. 先看源文件本身编码是UTF-8还是GBK，用什么编辑器打开能正常显示？
2. 再看编译器保存字符串字面量的编码，一般跟源文件一致。
3. 最后看运行环境的控制台代码页是什么（Windows cmd下用chcp命令查看）。
4. 用十六进制打印字符串的前几个字节，确认实际字节序列。

这三层对齐了，乱码自然消失。不排查直接堆代码，今天能用明天换个环境又乱。

5. printf重定向与日志落地：从屏幕到文件的经典手段

5.1 什么时候需要重定向

我在写后台服务和定时任务的时候，经常需要把程序输出存到文件里而不是仅仅打印在终端。最简单的重定向方式，其实根本不用改代码，bash命令行直接搞定：

bash复制./my_program > output.txt
./my_program >> output.log 2>&1

第一条命令把标准输出写入文件（覆盖写），第二条把标准输出和标准错误都追加到日志文件。这里的原理是shell把stdout重定向到文件，然后printf继续往stdout写，用户态代码完全无感。

但如果你在程序内部需要按需切换输出方向，比如一个服务默认输出到终端，收到某个信号后把日志落盘，那就得用代码做重定向。

5.2 freopen：最粗暴但简单的方案

C标准库提供了freopen，可以直接把stdout重新指向文件：

c复制freopen("output.txt", "w", stdout);
printf("这行输出会写入文件\n");

调用之后，所有printf的输出都写入output.txt。恢复终端输出比较麻烦，因为原来的终端设备句柄丢了，一般做法是先保存一份stdout的拷贝，或者不再恢复（程序后面一直输出到文件）。这个函数胜在简单，适合那种"程序启动时根据配置文件决定日志位置"的场景。

5.3 dup2：更精细的fd级重定向

如果你需要在重定向之后还能恢复，或者需要同时保留两种输出，需要用系统调用dup2。POSIX的dup2可以复制一个文件描述符到另一个：

c复制#include <unistd.h>
#include <fcntl.h>

int saved_stdout = dup(STDOUT_FILENO);  // 保存原始的stdout
int fd = open("output.txt", O_WRONLY | O_CREAT | O_TRUNC, 0644);
dup2(fd, STDOUT_FILENO);  // 让文件描述符1指向文件
printf("这行输出会写入文件\n");
fflush(stdout);
dup2(saved_stdout, STDOUT_FILENO);  // 恢复终端输出
close(fd);

这个方案的强大之处在于操作的是文件描述符这一层，stdio库的缓冲区行为也会跟着变。Windows上也有类似API（_dup2），但细节略有差异，写跨平台代码时需要包一层条件编译。

我在实现一个agent服务时，用dup2实现了日志文件按天切割的功能。每天零点检测到日期变化，打开新的日志文件，dup2到STDOUT_FILENO，后续所有printf自动写入新文件，而且程序本身完全不用改日志输出逻辑。

5.4 重定向之后"看不到输出"的缓冲问题

这是重定向场景里最容易踩的坑。在终端上printf是行缓冲的（遇到换行就刷出缓冲区），但重定向到文件之后，stdout变成全缓冲（只有当缓冲区满4KB时才刷出），这会导致程序崩溃或异常退出时，缓冲区里的内容丢失。

症状非常典型：程序跑完了，日志文件却是空的；或者日志文件有内容但少了一截结尾。解决办法就是及时强制刷新缓冲区：

c复制printf("关键日志信息\n");
fflush(stdout);

如果你希望每条日志都即时落盘，可以在重定向后调用setvbuf把stdout改成无缓冲：

c复制setvbuf(stdout, NULL, _IONBF, 0);

代价是性能下降，毕竟每次printf都要做一次系统调用。我的折衷方案是：普通调试用行缓冲，生产日志采集在自己实现的日志模块里做，每写一条就fflush，避免崩溃丢日志。

5.5 重定向和printf编码问题的叠加

重定向之后，前面提到过的编码问题会更加隐蔽。在终端里乱码你还能肉眼看到，重定向到文件后文件内容的编码错了，往往得用hexdump才能发现。如果是Windows下载UTF-8源码，程序内部字符串是UTF-8，直接重定向写到文件，文件就是UTF-8编码，这没问题。但如果你把控制台代码页设置成CP_UTF8之后重定向，控制台代码页的设置不会影响文件写入的字节，文件里存的依然是程序内部的原始字节，所以反而更容易保持一致。

一个真实教训：我负责的一个采集程序在Windows下运行，cmd里输出中文正常，但重定向到文件后用Excel打开全是乱码。原因是Windows cmd在终端显示时做了代码页转换，而重定向后不做这个转换，写入的是原始UTF-8字节，Excel默认按ANSI打开。后来统一在文件头部写UTF-8 BOM，Excel才识别正确。这个坑提醒我：终端显示正常不代表文件编码正确，重定向场景里的编码要对文件本身负责。

6. 实际项目中我发现的高频用法与隐藏细节

6.1 用sscanf做灵活配置解析

项目里需要解析"key=value"形式的配置行时，sscanf是个利器：

c复制char key[64], value[128];
if (sscanf(line, "%63[^=]=%127s", key, value) == 2) {
    // 成功解析出key和value
}

这里%[^=]的意思是"读取直到遇到=号"，配合宽度限制%63防止缓冲区溢出，是stdio函数里非常实用的技巧。这种用法我在解析INI文件、命令行参数、简单协议报文时都反复用到。注意sscanf的字符串是运行时内存，不会像scanf那样处理\r\n换行符，所以从Windows下读取的文本行末尾可能带一个\r，需要用%s解析时注意剔除。

6.2 printf的死循环与格式串安全

printf的格式串里有一个冷门但不应该忽略的写法：%n。它的作用是把已经输出的字符数写入一个int指针参数。这个功能在正常业务里几乎用不到，但因为它的参数是指针，篡改内存的可能性很高，所以在很多安全编码规范里被直接禁用。你在自己的代码里不应该用%n，如果代码审计工具报警，直接去掉就行。

另一个printf的特性和前面讲过的一样：格式控制符和参数不匹配时，行为是未定义的。printf("%d", 3.14)这种代码，编译器可能警告，但仍能编译通过，运行结果完全随机。开启编译器的格式串检查（GCC的-Wformat）是必要的，这一步能拦住90%的格式串错误。

6.3 大项目里封装输入输出层的经验

做了几个项目以后，我越来越倾向于把printf和scanf包在自己的日志模块或者输入模块里，而不是直接在业务代码里散落几百个printf。原因很简单：后期加时间戳、加级别过滤、改输出目标（终端、文件、syslog），只需要改动一个模块。之前有一个项目在对接监控系统时要求所有日志带毫秒级时间戳，因为业务代码直接调printf的太多，改起来非常痛苦。后面新项目一开始就封装了log_info/log_error等宏，底层统一走fprintf(stderr, ...)或者写文件，痛感立刻消失了。

如果你不想做一整套日志库，至少养成一个习惯：写printf时带上\n，对输出行结束的预期保持清晰；在正式服务里不直接scanf，用fgets读行再解析。这两条就能让你的C程序在输入输出的稳健性上超过一大半同类代码。

6.4 printf到底能有多快

有些同学担心大量printf会影响性能。实测下来，printf到终端确实慢（终端IO是瓶颈），但重定向到文件后，printf本身的解析开销相对较小。真正拖慢的是每次printf引发的锁竞争和系统调用，如果只是拼接字符串，纯snprintf比printf快得多。所以你写日志时先snprintf到缓冲区，最后一次性fwrite，性能会有明显提升。

这个优化在Web服务器和网关类的项目里很关键。我记得有一个网关心跳日志模块，每分钟几千条，直接printf导致CPU占用明显上升，改成snprintf+fwrite之后负载降了接近一半。锁竞争、系统调用数量大幅减少，这是幕后真正的差异。

写到这里，突然想说说printf和scanf在我心中的位置。写了多年C，我越来越觉得这两个函数不只是"入门第一课"，而是整个C语言I/O体系的地基。地基里的裂缝，比如缓冲区残留、编码不匹配、格式符误用，往往要在项目后期才集中爆发。这也是我写这篇长文的原因：希望你能在刚接触它们的时候就把这块地基打扎实，省掉后面无数个排查到凌晨的夜晚。