1. 赛场上那一次TLE逼我重新审视scanf和cin如果你打过几场正式的信息学竞赛大概率见过这种场景交上去的代码逻辑自测完全没问题时间复杂度也算了能过结果一发OJ返回一个红色加粗的TLE。查来查去最后发现卡你的不是算法而是输入输出。我第一次被这玩意儿坑是在一场区域赛的现场。那场题目的数据范围是n, m 10^6操作次数也到了百万级别。我习惯性在代码里写了cin n、cout ans算法本身是O(n log n)思路也和标准解法对得上。结果样例过了提交上去时间超限换scanf重写一遍同样逻辑直接压线通过。从那时起我就明白了一个事实在竞赛场景下IO不是可以糊弄过去的东西它是程序性能里实实在在的一部分。先说结论方便后面展开scanf/printf和cin/cout各有适用场景纯粹说“谁比谁快”其实不严谨关键要看运行环境、是否开启同步、以及数据规模到了什么量级。而快读快写则是算法竞赛场景下针对大规模整型数据输入输出的终极优化手段很多老选手甚至把它默写进自己的代码模板里。这篇文章我想把这件事讲透包括cin/cout为什么慢慢在哪些底层机制上scanf/printf和cin/cout在不同场景下的真实差距快读快写的工作原理以及可以直接放进模板的高性能实现我在实际比赛和日常刷题中踩过的坑尤其是快读和标准IO混用导致的神秘错误适合的人群很明确准备参加算法竞赛、在OJ上刷题的大学生或中学生以及工作中需要处理大规模数据IO的开发者。如果你只是写写小程序、处理几千行数据那cin/cout怎么用都无所谓但一旦数据量上了一百万、一千万这篇内容能帮你少走很多弯路。2. cin与cout慢在哪儿解开iostream底层的锁链2.1 不只是“多一条缓冲流”那么简单很多人一提到cin比scanf慢给出的解释就是“C的流对象更复杂多了缓冲机制”。这个说法对但太笼统了。真正的原因在于C标准库为了兼容C的标准IO库默认让iostream和stdio保持同步。具体来说你每用一次cin它内部可能要去同步C语言标准库的缓冲区状态。这个同步机制确保了你可以在一个程序里混用scanf和cin、printf和cout而不至于数据错乱。代价是每次IO操作都附带了额外的状态检查和同步开销在百万、千万级别的读写量下这些开销会被无限放大。跟你们打个比方scanf/printf就像是直接开着货车从仓库A往仓库B运货路线固定、中间没有检查站。而cin/cout默认情况下就像是每开一小段就有个检查站要核对货单、看看和另一套物流系统有没有冲突然后再放行。量大之后这些检查站的等候时间比运输本身还长。2.2 sync_with_stdio(false)的魔术与解开方式庆幸的是C给了我们一个开关来关掉这套同步机制#include iostream using namespace std; int main() { ios::sync_with_stdio(false); // 关闭cin/cout与scanf/printf的同步IO速度大幅提升 int n; cin n; cout n endl; return 0; }这行ios::sync_with_stdio(false)是每个C选手几乎必写的两行代码之一另一行是cin.tie(NULL)。加了这一句之后cin/cout的速度会接近甚至在某些场景下反超scanf/printf。但代价是此时不能再混用C风格和C风格的IO否则可能出现数据读取混乱、输出乱序等问题。原理很简单——你告诉编译器“我不需要你做同步保证了”它自然就把那套安全检查优化掉但同时也失去了容错能力。我说个误区很多人以为sync_with_stdio(false)只能配合cin/cout用不能碰scanf/printf。这个理解不对。它的本质是关闭“两种IO风格之间的同步”不是关闭某一个IO库。你只要不同时混用两种风格那么关掉同步之后用哪一种都是快速的。但如果你既想用scanf读大数据又想用cout输出中间结果那这个开关就救不了你。2.3 cin.tie(NULL)又是什么鬼cin.tie(NULL)是另一条锁链。默认情况下C的cin和cout是绑定的tied绑定意味着每次你在用cin 读数据之前程序会先强制刷新一次cout的输出缓冲区。想一想如果你的程序是边读入边输出那么每次cin操作都会触发一次缓冲区刷新而刷新缓冲区是重量级操作等于每次都强制把系统缓冲区的数据实际写到屏幕或文件上。累积下来这会成为巨大的性能瓶颈。cin.tie(NULL)就是解除这个绑定让cin读入不再自动刷新cout。这样缓冲区满了才刷新一次性能自然提升。很多初学者只加sync_with_stdio(false)不加cin.tie(NULL)在交替输入输出的场景下照样TLE原因就在这里。所以标准模板是两行连着写ios::sync_with_stdio(false); cin.tie(NULL);2.4 输出来凑数endl的隐藏成本另外输出侧有个容易忽略的坑endl。endl不仅仅是一个换行符它还会强制刷新缓冲区。用cout endl来换行相当于每输出一行就强迫清空一次缓冲区这在输出量大的比赛题目里是致命的。很多选手整场比赛都写cout ans endl结果别人循环输出一百万行你循环输出一百万次缓冲区刷新时间和别人能差出数倍。正确的习惯是需要换行但不需要强制刷新时用\n。cout ans \n才是竞赛选手真正该用的写法。如果要总结cin/cout慢的本质四个字兼容性开销。C标准库为了让你能混用C风格IO和C风格IO默认加上了同步和绑定两个机制。这两个机制在没有大量IO的场景下毫无存在感但在竞赛场景下就是实实在在的拖累。而你只需要两行代码就能把它们卸掉。3. scanf与printf的硬核优势格式化与类型安全之外3.1 scanf/printf真正的护城河不是速度在很多人的认知里scanf比cin快是因为它更“底层”。这说法有一定道理但并不全面。scanf/printf的实际优势在于格式化控制能力。比如控制输出占几位、补零、对齐、保留几位小数、用十六进制还是八进制输出这些在printf里都是极具表达力的格式控制符搞定的事。而cout在默认情况下用的是操作符重载和流操纵符虽然也能实现类似功能但代码写起来比printf啰嗦得多// printf输出格式控制 printf(%5d, n); // 宽度5右对齐 printf(%-5d, n); // 宽度5左对齐 printf(%05d, n); // 宽度5右对齐前导补零 printf(%.2f, x); // 保留2位小数 printf(%x, n); // 十六进制小写 // cout实现相同效果 cout setw(5) n; // 宽度5右对齐 cout left setw(5) n; // 宽度5左对齐 cout setfill(0) setw(5) n; // 前导补零 cout fixed setprecision(2) x; // 保留2位小数 cout hex n; // 十六进制对比很直观。而且用printf来做格式化输出字符串格式是编译期解析的格式控制符是标准C库的一部分不涉及C的模板和操作符重载。这也是它在很多编译器上比cout快一点的原因之一。3.2 scanf读入时最容易忽略的返回值判断scanf的另一个不常被新手注意但非常实用的特性返回值表示成功匹配并赋值的参数个数。int a, b; int ret scanf(%d%d, a, b); // ret 2 表示成功读了两个整数 // ret EOF 表示读到了文件末尾在竞赛题目中经常有“输入多组测试数据以EOF结尾”这种格式。用scanf处理起来非常顺手int n; while (scanf(%d, n) ! EOF) { // 处理每一组数据 }用cin同样可以实现int n; while (cin n) { // 处理每一组数据 }两者都能用。但scanf的返回值语义更精确能让你知道到底读成功了几个变量这在处理格式不固定的输入时很有用。比如输入一行里可能有两个整数也可能有三个你可以根据返回值走不同分支。3.3 C风格的类型安全是cin的真实优点那cin就毫无优势吗也不是。cin最核心的优点是类型安全和错误处理。scanf的%d、%lld、%lf等格式符和传入的变量类型必须严格匹配一旦写错轻则读到垃圾值重则直接内存越界。而cin x会自动根据变量x的类型调用对应的operator重载不存在格式符和类型不匹配的问题。尤其是long long类型。用scanf读long long必须写%lld写%d会导致读取长度只有4字节的高低位错乱这种bug极其隐蔽运行时看起来“好像能读进来”但数值完全是错的。当年多少人栽在%d和%lld的混用上我想很多老选手都有惨痛记忆。所以我的习惯是整数读入量大时直接上快读根本不用纠结scanf还是cin浮点数、字符串和格式化输出时优先用scanf/printf因为格式控制更强代码风格上追求类型安全、或者写模板、泛型代码时用cin/cout输出大量数据时printf和cout \n差别不大关键是别用endl4. 快读快写打破标准IO的墙自己动手造轮子4.1 快读快写的底层思路绕过格式化解析标准IO慢有一部分开销在格式化解析。scanf(%d, n)内部要处理输入流里的空白字符、判断正负号、逐位将字符转成十进制整数。这些工作是通用的但同时也很复杂包含了各种边界处理。而竞赛场景经常是“读入大量十进制整数格式简单规整”。这时候完全可以自己写一个轻量级的整型读取器直接从缓冲区字符层面逐位解析省掉标准库的格式解析开销。这就是快读。快读的核心并不神秘就三步绕过scanf/cin直接从缓冲区或文件流中读取字符跳过非数字字符把连续的数字字符累加成整数最基础的版本用getchar()inline int read() { int x 0, f 1; char ch getchar(); while (ch 0 || ch 9) { if (ch -) f -1; ch getchar(); } while (ch 0 ch 9) { x x * 10 ch - 0; ch getchar(); } return x * f; }这段代码的思想先读字符只要不是数字就继续读如果是负号就记录正负标志。读到数字后连续累加直到遇到下一个非数字字符为止。这样读一个整数的耗时就是O(位数)只和字符本身有关没有额外开销。4.2 fread快读竞赛级高性能实现的模板getchar()版的快读已经比scanf快很多了但还不是极限。因为getchar()底层本质是每次从缓冲区读一个字符仍然有函数调用和缓冲区状态维护的开销。对于百万级、千万级的数据量这个开销依然存在。更极限的做法是用fread直接一次性把一大块数据读入自己管理的内存缓冲区然后从缓冲区里逐个字符解析。这样IO系统调用只发生一次剩下全部是内存内的指针运算速度可以再上一个台阶。一个我常年放在个人模板里的fread快读#include cstdio const int MAXSIZE 1 20; // 1MB缓冲区 char buf[MAXSIZE], *p1, *p2; inline char getchar_custom() { if (p1 p2) { p2 (p1 buf) fread(buf, 1, MAXSIZE, stdin); if (p1 p2) return EOF; // 文件读完了 } return *p1; } inline int read() { int x 0, f 1; char ch getchar_custom(); while (ch 0 || ch 9) { if (ch -) f -1; if (ch EOF) break; // 避免读到EOF后死循环 ch getchar_custom(); } while (ch 0 ch 9) { x x * 10 ch - 0; ch getchar_custom(); } return x * f; }这里p1和p2分别表示当前读取位置和缓冲区末尾位置。当p1 p2说明缓冲区读完了就用fread再读取下一块数据填充缓冲区。getchar_custom()实际上成了“从自己管理的缓冲区取一个字符”的宏级操作没有多余的状态检查。在数据量超过百万时这个版本和getchar版本能再拉开接近一倍的差距。而和cin不关同步的情况相比差距可以到十倍以上。4.3 支持long long和负数的进阶快读实际比赛中题目不会只让你读int范围内的数long long、负数都是常见的。我用的完整版快读长这样#include cstdio const int MAXSIZE 1 20; char buf[MAXSIZE], *p1 buf, *p2 buf; inline char gc() { if (p1 p2) { p2 (p1 buf) fread(buf, 1, MAXSIZE, stdin); if (p1 p2) return EOF; } return *p1; } template typename T inline T read() { T x 0; int f 1; char ch gc(); while (ch 0 || ch 9) { if (ch -) f -1; if (ch EOF) return 0; ch gc(); } while (ch 0 ch 9) { x x * 10 (ch - 0); ch gc(); } return x * f; } // 使用int a readint(); long long b readlong long();用模板实现之后一个函数通吃所有整型类型读int就readint()读long long就readlong long()。负数、零、正常正数都能正确处理。4.4 快写的实现从输出侧同样榨干性能快写相对快读简单一些核心是把整数转成字符数组然后一次性输出。思路是先把数字从低位到高位取出来存到临时字符数组里再反序输出。inline void write(int x) { if (x 0) { putchar(-); x -x; } if (x 9) { write(x / 10); } putchar(x % 10 0); }这个递归版快写逻辑很清晰但是函数递归有少量开销。如果你追求极致性能可以改成非递归的反序输出char out_buf[MAXSIZE]; int out_pos 0; inline void write(int x) { char tmp[12]; int len 0; if (x 0) { out_buf[out_pos] -; x -x; } if (x 0) { out_buf[out_pos] 0; } else { while (x) { tmp[len] x % 10 0; x / 10; } while (len) { out_buf[out_pos] tmp[--len]; } } if (out_pos MAXSIZE - 12) { fwrite(out_buf, 1, out_pos, stdout); out_pos 0; } } inline void flush_output() { if (out_pos) { fwrite(out_buf, 1, out_pos, stdout); out_pos 0; } }思路是先把输出暂存在自己的缓冲区里满了再一次性fwrite刷出去最终在程序结束前调用一次flush_output()。这样系统级IO调用次数会降到最低输出性能非常可观。注意一点如果用了上面这套手动缓冲区那么输出顺序是按调用write的顺序进入缓冲区再刷出的不要和printf或cout混用否则因为不同层的缓冲策略不同输出顺序可能错乱。5. 快读快写和标准IO混用那些让你怀疑人生的神秘bug5.1 缓冲区脱节最经典的混用事故很多人在刚开始用快读时觉得快读只负责读整数处理字符和字符串时还是用原始的scanf或getchar顺手于是写出了这种代码int n read(); char op; scanf( %c, op);看上去没问题——先快读读了个整数再用scanf读一个字符。但实际运行起来你会碰到极度诡异的现象op读进来的值完全对不上或者有时候程序直接卡死。我当年在这个坑里蹲了很久才想明白。scanf读字符时虽然前面加了空格来跳过空白字符但scanf的缓冲区和我的fread缓冲区完全是两套东西。我手动定义了一个buf数组fread读入的数据存在buf里指针p1同步移动。scanf用的却是系统自身的输入缓冲区。当read()读完整数后系统缓冲区的文件位置指针还在那个位置没有向前移动于是scanf会从流中读同一个位置的数据。比如你输入42 xread()用自己缓冲区从buf里读了4和2就停了此时p1指向空格但系统缓冲区的位置指针在4之前。接着scanf( %c, op)从系统缓冲区读先跳过空格后读到的依然是4而不是预期的x。说白了手动fread把数据读走之后系统缓冲区里那块数据已经没了但C标准库的文件位置指针不知道这件事。两套缓冲逻辑互相不知道对方的存在结果就是数据错乱。5.2 解决的唯一思路要么全信自己要么全用标准踩过这个坑之后我给自己定了一条死规矩一旦用了fread型快读整个程序的输入部分就全部自己管理不用任何标准输入函数输出部分如果用fwrite缓冲也一样不再混用printf和cout。具体来说如果要处理带空格的字符串、单个字符、整行数据就自己写对应的读取函数。一行完整读入可以用fgets配合自己的缓冲区或者自己在buf基础上实现读一行。这样虽然代码量稍微多了点但不会出现数据错位的玄学问题。如果你的场景比较混合、代码里既有cin又要读字符又要读长串就别硬上fread快读用ios::sync_with_stdio(false)cin.tie(NULL)的优化就够了保证代码可维护性。5.3 getchar快读与scanf混用也一样出问题有人可能会想那我不用fread用getchar实现的快读是不是就能和scanf混用了答案依然是不行。虽然getchar底层用的是C标准库的缓冲区不会出现fread的“文件位置指针错位”问题但快读函数里读取字符和判断数字的过程可能会多消费掉一个非数字字符。比如快读判断结束的那个字符比如空格当你以为“读完了数字”时实际上那个触发循环结束的字符已经被getchar消费掉了scanf再读时就没有这个字符了。很多人在处理类似(n, m, q)这种带括号逗号的输入时快读读数字没问题接着用scanf想读标点符号结果发现逗号或括号不见了就是这个原因。所以我的实践结论是快读快写是一个封闭体系要么完全用自己的一套彻底不碰标准IO要么就用标准IO加上两行优化。不要两边讨便宜。6. 性能对比实测从100万到1000万的数据量级看差距6.1 测试场景设计为了给大家一个直观的认识我用同一台机器、同一份数据对一个简单场景做了性能对比程序循环读取n个整数再把这n个整数原样输出。测试方式分别用下面五种方案方案实现方式Acin不关同步默认状态Bcin关同步 关绑定Cscanf/printfDgetchar快读 递归快写Efread/fwrite快读快写编译选项统一为g -O2数据量n分别取10万、100万、1000万。测试数据全部是随机正整数存放在文件里程序重定向从文件读入、向文件输出。6.2 测试结果与解读结果非常能说明问题时间单位毫秒取三次平均值数据量方案A方案B方案C方案D方案E10万38231372412100万334023131591431000万无法直视22402870810386这个表有几个非常有意思的结论第一不关同步的cin简直就是性能黑洞。10万数据就要382毫秒100万直接3.3秒1000万我根本没测试量级太大时间太长。这不是慢一点的问题是数量级的差距。第二关掉同步后的cin方案B完全可以和scanf/printf方案C掰手腕甚至在100万、1000万的数据量下反超printf。原因是printf的格式化解析在大量小整数输出时仍有固定的开销而cout配合\n输出在关同步后拥有一套独立的快速路径。第三fread/fwrite快读快写相比标准IO还有约5到8倍的提升。1000万数据的情况下方案C需要2.87秒方案E只需要0.386秒。虽然单看这个数据似乎“也没差多少”但在时限只有1秒的赛题里这2秒多的差距就是TLE和AC的区别。第四getchar版本方案D和fread版本方案E的差距主要体现在数据量变大之后。100万时差一倍左右1000万时也是约一倍。如果你的手写读取技巧已经足够熟练两者都可以接受但追求极致还是fread更稳。6.3 不同数据规模下的推荐使用策略根据上面的实测我个人的使用策略是这样的数据总量在10^5以下随便用。cin不关同步也不会挂scanf写起来舒服就用scanf。数据总量在10^5到10^6之间至少加上ios::sync_with_stdio(false)和cin.tie(NULL)或者直接用scanf/printf。这个量级两者都行差别不大。数据总量在10^6以上或者明确知道时限很紧直接用fread快读fwrite快写。这已经不只是IO的问题了是整个程序能否在时限内跑完的生死问题。数据量不大但输出格式复杂大量浮点数格式化、对齐补零老老实实用printf别跟快写较劲。快写处理整数和字符串还行处理浮点格式化太麻烦得不偿失。7. 我在实际比赛中的选型经验与踩坑清单7.1 时间充裕时的优雅做法 vs 紧急关头的条件反射我见过有一些选手平时刷题非常讲究所有代码都用cin/cout觉得类型安全、写起来舒服。到了正式比赛数据量一大贴板子之前还要犹豫半天“这里该用快读还是scanf”在最需要条件反射的时刻卡了壳。我的建议是把IO选型变成条件反射不要到赛场上临时纠结。平时训练时就把规则定死凡是需要手写模板的正式比赛开场先把快读快写模板贴进代码里。不管当前题目数据量大不大先放那儿用不用是另一回事。真正需要时直接readint()拿来就用不用现场手敲。数据量很小、题目明显是模拟题或数学题直接scanf/printf代码更短调试更方便。涉及字符串、浮点、结构体等复杂格式化输入用标准IO别硬上快读。7.2 浮动小时钟快读的错误处理与传统习惯冲突用快读有一个容易忽视的问题它不会像scanf那样优雅地处理读取失败。scanf返回EOF或者匹配失败次数时你的代码可以立刻知道输入有问题。而自己写的快读函数在读到EOF时经常返回0或者什么都不返回。如果你写的是while (readint() ! EOF)这种逻辑就会非常别扭。所以我在模板里对读文件尾的情况做了特殊处理——返回0并设置一个全局的EOF标记。但这也导致了一个小问题如果题目输入里真的有一个数字0和一个文件结束标记混在一起代码就要小心区分。竞赛题目一般不会在这种地方恶心你但如果你用快读去做在线评测系统的交互式题目就要非常谨慎了。交互式题目需要一边读一边判断是否轮到对方输入这种场景我建议不用快读直接用cin/cout关同步逻辑更清晰。7.3 我踩过的快读坑清单顺手整理几个我实际踩过、也常见于别人求助帖的坑坑1fread缓冲区大小定太小。一开始我图省事#define MAXSIZE 1000想着读一点刷一点。后来才发现1KB太容易触发多次fread调用性能提升有限。建议直接给1MB起步1 20这和竞赛输入文件的大小也匹配。坑2p1和p2没有初始化就使用。有些编译器下全局变量自动置零有些则不是。定义时就要初始化char buf[MAXSIZE], *p1 buf, *p2 buf;否则初始状态p1、p2值不确定gc()里比较和读取逻辑直接崩。坑3处理EOF时死循环。如果输入文件读完了fread返回0p1和p2都被置成buf此时如果代码里没有ch EOF的退出判断gc()会一直返回EOF而外层循环永远在等待有效数字程序就卡死在读取上。所以gc()返回EOF时一定要让上层感知到在read函数里加if (ch EOF) return 0;的判断。坑4负数最小值溢出。write函数里处理负数时如果有-2147483648这个int最小值先取x -x会导致溢出。正确做法是先将x转为long long再取负或单独处理这个边界值。实话说大部分比赛数据不会真给你int最小值但稳妥起见还是处理一下为好inline void write(long long x) { if (x 0) { out_buf[out_pos] -; x -x; } // ... }注意x的类型直接定义成long long就不会有int最小值取负的溢出问题了。坑5快读函数读的是带前导符号的字符串时逻辑错误。比如输入是42有些快读写法里没有处理正号会把当成非数字字符跳过然后读出了42这没问题。但有一种手滑的写法会把读成非法字符导致死循环判断时要特别注意识别-和都要跳过或妥善处理。7.4 什么时候可以完全不考虑这些最后再说个反向场景如果你平时只写工程代码、不参加算法竞赛、也不需要对海量数据进行格式化解析那cin/cout就是最好的选择。工程代码需要的是可读性、可维护性和类型安全这些cin/cout全都具备而且现在的主流机器上IO开销在大多数业务场景里可以忽略不计。文章里讲的所有性能优化手段都是针对“百万级以上数据量 严格时限”的竞赛场景。所以我的最终建议是面向竞赛建立属于自己的IO模板fread快读fwrite快写是标配面向工程cin/cout 关同步就足够了别为了那点性能搞出一套自维护缓冲来折腾自己希望这篇文章能帮你把输入输出这个问题彻底想透把自己的代码模板在赛前就打磨稳定。别再让一个TLE毁掉一场比赛因为IO选型这件事本来就不该是赛场上需要思考的问题。
C++输入输出性能优化：从cin到快读快写的终极指南
1. 赛场上那一次TLE逼我重新审视scanf和cin如果你打过几场正式的信息学竞赛大概率见过这种场景交上去的代码逻辑自测完全没问题时间复杂度也算了能过结果一发OJ返回一个红色加粗的TLE。查来查去最后发现卡你的不是算法而是输入输出。我第一次被这玩意儿坑是在一场区域赛的现场。那场题目的数据范围是n, m 10^6操作次数也到了百万级别。我习惯性在代码里写了cin n、cout ans算法本身是O(n log n)思路也和标准解法对得上。结果样例过了提交上去时间超限换scanf重写一遍同样逻辑直接压线通过。从那时起我就明白了一个事实在竞赛场景下IO不是可以糊弄过去的东西它是程序性能里实实在在的一部分。先说结论方便后面展开scanf/printf和cin/cout各有适用场景纯粹说“谁比谁快”其实不严谨关键要看运行环境、是否开启同步、以及数据规模到了什么量级。而快读快写则是算法竞赛场景下针对大规模整型数据输入输出的终极优化手段很多老选手甚至把它默写进自己的代码模板里。这篇文章我想把这件事讲透包括cin/cout为什么慢慢在哪些底层机制上scanf/printf和cin/cout在不同场景下的真实差距快读快写的工作原理以及可以直接放进模板的高性能实现我在实际比赛和日常刷题中踩过的坑尤其是快读和标准IO混用导致的神秘错误适合的人群很明确准备参加算法竞赛、在OJ上刷题的大学生或中学生以及工作中需要处理大规模数据IO的开发者。如果你只是写写小程序、处理几千行数据那cin/cout怎么用都无所谓但一旦数据量上了一百万、一千万这篇内容能帮你少走很多弯路。2. cin与cout慢在哪儿解开iostream底层的锁链2.1 不只是“多一条缓冲流”那么简单很多人一提到cin比scanf慢给出的解释就是“C的流对象更复杂多了缓冲机制”。这个说法对但太笼统了。真正的原因在于C标准库为了兼容C的标准IO库默认让iostream和stdio保持同步。具体来说你每用一次cin它内部可能要去同步C语言标准库的缓冲区状态。这个同步机制确保了你可以在一个程序里混用scanf和cin、printf和cout而不至于数据错乱。代价是每次IO操作都附带了额外的状态检查和同步开销在百万、千万级别的读写量下这些开销会被无限放大。跟你们打个比方scanf/printf就像是直接开着货车从仓库A往仓库B运货路线固定、中间没有检查站。而cin/cout默认情况下就像是每开一小段就有个检查站要核对货单、看看和另一套物流系统有没有冲突然后再放行。量大之后这些检查站的等候时间比运输本身还长。2.2 sync_with_stdio(false)的魔术与解开方式庆幸的是C给了我们一个开关来关掉这套同步机制#include iostream using namespace std; int main() { ios::sync_with_stdio(false); // 关闭cin/cout与scanf/printf的同步IO速度大幅提升 int n; cin n; cout n endl; return 0; }这行ios::sync_with_stdio(false)是每个C选手几乎必写的两行代码之一另一行是cin.tie(NULL)。加了这一句之后cin/cout的速度会接近甚至在某些场景下反超scanf/printf。但代价是此时不能再混用C风格和C风格的IO否则可能出现数据读取混乱、输出乱序等问题。原理很简单——你告诉编译器“我不需要你做同步保证了”它自然就把那套安全检查优化掉但同时也失去了容错能力。我说个误区很多人以为sync_with_stdio(false)只能配合cin/cout用不能碰scanf/printf。这个理解不对。它的本质是关闭“两种IO风格之间的同步”不是关闭某一个IO库。你只要不同时混用两种风格那么关掉同步之后用哪一种都是快速的。但如果你既想用scanf读大数据又想用cout输出中间结果那这个开关就救不了你。2.3 cin.tie(NULL)又是什么鬼cin.tie(NULL)是另一条锁链。默认情况下C的cin和cout是绑定的tied绑定意味着每次你在用cin 读数据之前程序会先强制刷新一次cout的输出缓冲区。想一想如果你的程序是边读入边输出那么每次cin操作都会触发一次缓冲区刷新而刷新缓冲区是重量级操作等于每次都强制把系统缓冲区的数据实际写到屏幕或文件上。累积下来这会成为巨大的性能瓶颈。cin.tie(NULL)就是解除这个绑定让cin读入不再自动刷新cout。这样缓冲区满了才刷新一次性能自然提升。很多初学者只加sync_with_stdio(false)不加cin.tie(NULL)在交替输入输出的场景下照样TLE原因就在这里。所以标准模板是两行连着写ios::sync_with_stdio(false); cin.tie(NULL);2.4 输出来凑数endl的隐藏成本另外输出侧有个容易忽略的坑endl。endl不仅仅是一个换行符它还会强制刷新缓冲区。用cout endl来换行相当于每输出一行就强迫清空一次缓冲区这在输出量大的比赛题目里是致命的。很多选手整场比赛都写cout ans endl结果别人循环输出一百万行你循环输出一百万次缓冲区刷新时间和别人能差出数倍。正确的习惯是需要换行但不需要强制刷新时用\n。cout ans \n才是竞赛选手真正该用的写法。如果要总结cin/cout慢的本质四个字兼容性开销。C标准库为了让你能混用C风格IO和C风格IO默认加上了同步和绑定两个机制。这两个机制在没有大量IO的场景下毫无存在感但在竞赛场景下就是实实在在的拖累。而你只需要两行代码就能把它们卸掉。3. scanf与printf的硬核优势格式化与类型安全之外3.1 scanf/printf真正的护城河不是速度在很多人的认知里scanf比cin快是因为它更“底层”。这说法有一定道理但并不全面。scanf/printf的实际优势在于格式化控制能力。比如控制输出占几位、补零、对齐、保留几位小数、用十六进制还是八进制输出这些在printf里都是极具表达力的格式控制符搞定的事。而cout在默认情况下用的是操作符重载和流操纵符虽然也能实现类似功能但代码写起来比printf啰嗦得多// printf输出格式控制 printf(%5d, n); // 宽度5右对齐 printf(%-5d, n); // 宽度5左对齐 printf(%05d, n); // 宽度5右对齐前导补零 printf(%.2f, x); // 保留2位小数 printf(%x, n); // 十六进制小写 // cout实现相同效果 cout setw(5) n; // 宽度5右对齐 cout left setw(5) n; // 宽度5左对齐 cout setfill(0) setw(5) n; // 前导补零 cout fixed setprecision(2) x; // 保留2位小数 cout hex n; // 十六进制对比很直观。而且用printf来做格式化输出字符串格式是编译期解析的格式控制符是标准C库的一部分不涉及C的模板和操作符重载。这也是它在很多编译器上比cout快一点的原因之一。3.2 scanf读入时最容易忽略的返回值判断scanf的另一个不常被新手注意但非常实用的特性返回值表示成功匹配并赋值的参数个数。int a, b; int ret scanf(%d%d, a, b); // ret 2 表示成功读了两个整数 // ret EOF 表示读到了文件末尾在竞赛题目中经常有“输入多组测试数据以EOF结尾”这种格式。用scanf处理起来非常顺手int n; while (scanf(%d, n) ! EOF) { // 处理每一组数据 }用cin同样可以实现int n; while (cin n) { // 处理每一组数据 }两者都能用。但scanf的返回值语义更精确能让你知道到底读成功了几个变量这在处理格式不固定的输入时很有用。比如输入一行里可能有两个整数也可能有三个你可以根据返回值走不同分支。3.3 C风格的类型安全是cin的真实优点那cin就毫无优势吗也不是。cin最核心的优点是类型安全和错误处理。scanf的%d、%lld、%lf等格式符和传入的变量类型必须严格匹配一旦写错轻则读到垃圾值重则直接内存越界。而cin x会自动根据变量x的类型调用对应的operator重载不存在格式符和类型不匹配的问题。尤其是long long类型。用scanf读long long必须写%lld写%d会导致读取长度只有4字节的高低位错乱这种bug极其隐蔽运行时看起来“好像能读进来”但数值完全是错的。当年多少人栽在%d和%lld的混用上我想很多老选手都有惨痛记忆。所以我的习惯是整数读入量大时直接上快读根本不用纠结scanf还是cin浮点数、字符串和格式化输出时优先用scanf/printf因为格式控制更强代码风格上追求类型安全、或者写模板、泛型代码时用cin/cout输出大量数据时printf和cout \n差别不大关键是别用endl4. 快读快写打破标准IO的墙自己动手造轮子4.1 快读快写的底层思路绕过格式化解析标准IO慢有一部分开销在格式化解析。scanf(%d, n)内部要处理输入流里的空白字符、判断正负号、逐位将字符转成十进制整数。这些工作是通用的但同时也很复杂包含了各种边界处理。而竞赛场景经常是“读入大量十进制整数格式简单规整”。这时候完全可以自己写一个轻量级的整型读取器直接从缓冲区字符层面逐位解析省掉标准库的格式解析开销。这就是快读。快读的核心并不神秘就三步绕过scanf/cin直接从缓冲区或文件流中读取字符跳过非数字字符把连续的数字字符累加成整数最基础的版本用getchar()inline int read() { int x 0, f 1; char ch getchar(); while (ch 0 || ch 9) { if (ch -) f -1; ch getchar(); } while (ch 0 ch 9) { x x * 10 ch - 0; ch getchar(); } return x * f; }这段代码的思想先读字符只要不是数字就继续读如果是负号就记录正负标志。读到数字后连续累加直到遇到下一个非数字字符为止。这样读一个整数的耗时就是O(位数)只和字符本身有关没有额外开销。4.2 fread快读竞赛级高性能实现的模板getchar()版的快读已经比scanf快很多了但还不是极限。因为getchar()底层本质是每次从缓冲区读一个字符仍然有函数调用和缓冲区状态维护的开销。对于百万级、千万级的数据量这个开销依然存在。更极限的做法是用fread直接一次性把一大块数据读入自己管理的内存缓冲区然后从缓冲区里逐个字符解析。这样IO系统调用只发生一次剩下全部是内存内的指针运算速度可以再上一个台阶。一个我常年放在个人模板里的fread快读#include cstdio const int MAXSIZE 1 20; // 1MB缓冲区 char buf[MAXSIZE], *p1, *p2; inline char getchar_custom() { if (p1 p2) { p2 (p1 buf) fread(buf, 1, MAXSIZE, stdin); if (p1 p2) return EOF; // 文件读完了 } return *p1; } inline int read() { int x 0, f 1; char ch getchar_custom(); while (ch 0 || ch 9) { if (ch -) f -1; if (ch EOF) break; // 避免读到EOF后死循环 ch getchar_custom(); } while (ch 0 ch 9) { x x * 10 ch - 0; ch getchar_custom(); } return x * f; }这里p1和p2分别表示当前读取位置和缓冲区末尾位置。当p1 p2说明缓冲区读完了就用fread再读取下一块数据填充缓冲区。getchar_custom()实际上成了“从自己管理的缓冲区取一个字符”的宏级操作没有多余的状态检查。在数据量超过百万时这个版本和getchar版本能再拉开接近一倍的差距。而和cin不关同步的情况相比差距可以到十倍以上。4.3 支持long long和负数的进阶快读实际比赛中题目不会只让你读int范围内的数long long、负数都是常见的。我用的完整版快读长这样#include cstdio const int MAXSIZE 1 20; char buf[MAXSIZE], *p1 buf, *p2 buf; inline char gc() { if (p1 p2) { p2 (p1 buf) fread(buf, 1, MAXSIZE, stdin); if (p1 p2) return EOF; } return *p1; } template typename T inline T read() { T x 0; int f 1; char ch gc(); while (ch 0 || ch 9) { if (ch -) f -1; if (ch EOF) return 0; ch gc(); } while (ch 0 ch 9) { x x * 10 (ch - 0); ch gc(); } return x * f; } // 使用int a readint(); long long b readlong long();用模板实现之后一个函数通吃所有整型类型读int就readint()读long long就readlong long()。负数、零、正常正数都能正确处理。4.4 快写的实现从输出侧同样榨干性能快写相对快读简单一些核心是把整数转成字符数组然后一次性输出。思路是先把数字从低位到高位取出来存到临时字符数组里再反序输出。inline void write(int x) { if (x 0) { putchar(-); x -x; } if (x 9) { write(x / 10); } putchar(x % 10 0); }这个递归版快写逻辑很清晰但是函数递归有少量开销。如果你追求极致性能可以改成非递归的反序输出char out_buf[MAXSIZE]; int out_pos 0; inline void write(int x) { char tmp[12]; int len 0; if (x 0) { out_buf[out_pos] -; x -x; } if (x 0) { out_buf[out_pos] 0; } else { while (x) { tmp[len] x % 10 0; x / 10; } while (len) { out_buf[out_pos] tmp[--len]; } } if (out_pos MAXSIZE - 12) { fwrite(out_buf, 1, out_pos, stdout); out_pos 0; } } inline void flush_output() { if (out_pos) { fwrite(out_buf, 1, out_pos, stdout); out_pos 0; } }思路是先把输出暂存在自己的缓冲区里满了再一次性fwrite刷出去最终在程序结束前调用一次flush_output()。这样系统级IO调用次数会降到最低输出性能非常可观。注意一点如果用了上面这套手动缓冲区那么输出顺序是按调用write的顺序进入缓冲区再刷出的不要和printf或cout混用否则因为不同层的缓冲策略不同输出顺序可能错乱。5. 快读快写和标准IO混用那些让你怀疑人生的神秘bug5.1 缓冲区脱节最经典的混用事故很多人在刚开始用快读时觉得快读只负责读整数处理字符和字符串时还是用原始的scanf或getchar顺手于是写出了这种代码int n read(); char op; scanf( %c, op);看上去没问题——先快读读了个整数再用scanf读一个字符。但实际运行起来你会碰到极度诡异的现象op读进来的值完全对不上或者有时候程序直接卡死。我当年在这个坑里蹲了很久才想明白。scanf读字符时虽然前面加了空格来跳过空白字符但scanf的缓冲区和我的fread缓冲区完全是两套东西。我手动定义了一个buf数组fread读入的数据存在buf里指针p1同步移动。scanf用的却是系统自身的输入缓冲区。当read()读完整数后系统缓冲区的文件位置指针还在那个位置没有向前移动于是scanf会从流中读同一个位置的数据。比如你输入42 xread()用自己缓冲区从buf里读了4和2就停了此时p1指向空格但系统缓冲区的位置指针在4之前。接着scanf( %c, op)从系统缓冲区读先跳过空格后读到的依然是4而不是预期的x。说白了手动fread把数据读走之后系统缓冲区里那块数据已经没了但C标准库的文件位置指针不知道这件事。两套缓冲逻辑互相不知道对方的存在结果就是数据错乱。5.2 解决的唯一思路要么全信自己要么全用标准踩过这个坑之后我给自己定了一条死规矩一旦用了fread型快读整个程序的输入部分就全部自己管理不用任何标准输入函数输出部分如果用fwrite缓冲也一样不再混用printf和cout。具体来说如果要处理带空格的字符串、单个字符、整行数据就自己写对应的读取函数。一行完整读入可以用fgets配合自己的缓冲区或者自己在buf基础上实现读一行。这样虽然代码量稍微多了点但不会出现数据错位的玄学问题。如果你的场景比较混合、代码里既有cin又要读字符又要读长串就别硬上fread快读用ios::sync_with_stdio(false)cin.tie(NULL)的优化就够了保证代码可维护性。5.3 getchar快读与scanf混用也一样出问题有人可能会想那我不用fread用getchar实现的快读是不是就能和scanf混用了答案依然是不行。虽然getchar底层用的是C标准库的缓冲区不会出现fread的“文件位置指针错位”问题但快读函数里读取字符和判断数字的过程可能会多消费掉一个非数字字符。比如快读判断结束的那个字符比如空格当你以为“读完了数字”时实际上那个触发循环结束的字符已经被getchar消费掉了scanf再读时就没有这个字符了。很多人在处理类似(n, m, q)这种带括号逗号的输入时快读读数字没问题接着用scanf想读标点符号结果发现逗号或括号不见了就是这个原因。所以我的实践结论是快读快写是一个封闭体系要么完全用自己的一套彻底不碰标准IO要么就用标准IO加上两行优化。不要两边讨便宜。6. 性能对比实测从100万到1000万的数据量级看差距6.1 测试场景设计为了给大家一个直观的认识我用同一台机器、同一份数据对一个简单场景做了性能对比程序循环读取n个整数再把这n个整数原样输出。测试方式分别用下面五种方案方案实现方式Acin不关同步默认状态Bcin关同步 关绑定Cscanf/printfDgetchar快读 递归快写Efread/fwrite快读快写编译选项统一为g -O2数据量n分别取10万、100万、1000万。测试数据全部是随机正整数存放在文件里程序重定向从文件读入、向文件输出。6.2 测试结果与解读结果非常能说明问题时间单位毫秒取三次平均值数据量方案A方案B方案C方案D方案E10万38231372412100万334023131591431000万无法直视22402870810386这个表有几个非常有意思的结论第一不关同步的cin简直就是性能黑洞。10万数据就要382毫秒100万直接3.3秒1000万我根本没测试量级太大时间太长。这不是慢一点的问题是数量级的差距。第二关掉同步后的cin方案B完全可以和scanf/printf方案C掰手腕甚至在100万、1000万的数据量下反超printf。原因是printf的格式化解析在大量小整数输出时仍有固定的开销而cout配合\n输出在关同步后拥有一套独立的快速路径。第三fread/fwrite快读快写相比标准IO还有约5到8倍的提升。1000万数据的情况下方案C需要2.87秒方案E只需要0.386秒。虽然单看这个数据似乎“也没差多少”但在时限只有1秒的赛题里这2秒多的差距就是TLE和AC的区别。第四getchar版本方案D和fread版本方案E的差距主要体现在数据量变大之后。100万时差一倍左右1000万时也是约一倍。如果你的手写读取技巧已经足够熟练两者都可以接受但追求极致还是fread更稳。6.3 不同数据规模下的推荐使用策略根据上面的实测我个人的使用策略是这样的数据总量在10^5以下随便用。cin不关同步也不会挂scanf写起来舒服就用scanf。数据总量在10^5到10^6之间至少加上ios::sync_with_stdio(false)和cin.tie(NULL)或者直接用scanf/printf。这个量级两者都行差别不大。数据总量在10^6以上或者明确知道时限很紧直接用fread快读fwrite快写。这已经不只是IO的问题了是整个程序能否在时限内跑完的生死问题。数据量不大但输出格式复杂大量浮点数格式化、对齐补零老老实实用printf别跟快写较劲。快写处理整数和字符串还行处理浮点格式化太麻烦得不偿失。7. 我在实际比赛中的选型经验与踩坑清单7.1 时间充裕时的优雅做法 vs 紧急关头的条件反射我见过有一些选手平时刷题非常讲究所有代码都用cin/cout觉得类型安全、写起来舒服。到了正式比赛数据量一大贴板子之前还要犹豫半天“这里该用快读还是scanf”在最需要条件反射的时刻卡了壳。我的建议是把IO选型变成条件反射不要到赛场上临时纠结。平时训练时就把规则定死凡是需要手写模板的正式比赛开场先把快读快写模板贴进代码里。不管当前题目数据量大不大先放那儿用不用是另一回事。真正需要时直接readint()拿来就用不用现场手敲。数据量很小、题目明显是模拟题或数学题直接scanf/printf代码更短调试更方便。涉及字符串、浮点、结构体等复杂格式化输入用标准IO别硬上快读。7.2 浮动小时钟快读的错误处理与传统习惯冲突用快读有一个容易忽视的问题它不会像scanf那样优雅地处理读取失败。scanf返回EOF或者匹配失败次数时你的代码可以立刻知道输入有问题。而自己写的快读函数在读到EOF时经常返回0或者什么都不返回。如果你写的是while (readint() ! EOF)这种逻辑就会非常别扭。所以我在模板里对读文件尾的情况做了特殊处理——返回0并设置一个全局的EOF标记。但这也导致了一个小问题如果题目输入里真的有一个数字0和一个文件结束标记混在一起代码就要小心区分。竞赛题目一般不会在这种地方恶心你但如果你用快读去做在线评测系统的交互式题目就要非常谨慎了。交互式题目需要一边读一边判断是否轮到对方输入这种场景我建议不用快读直接用cin/cout关同步逻辑更清晰。7.3 我踩过的快读坑清单顺手整理几个我实际踩过、也常见于别人求助帖的坑坑1fread缓冲区大小定太小。一开始我图省事#define MAXSIZE 1000想着读一点刷一点。后来才发现1KB太容易触发多次fread调用性能提升有限。建议直接给1MB起步1 20这和竞赛输入文件的大小也匹配。坑2p1和p2没有初始化就使用。有些编译器下全局变量自动置零有些则不是。定义时就要初始化char buf[MAXSIZE], *p1 buf, *p2 buf;否则初始状态p1、p2值不确定gc()里比较和读取逻辑直接崩。坑3处理EOF时死循环。如果输入文件读完了fread返回0p1和p2都被置成buf此时如果代码里没有ch EOF的退出判断gc()会一直返回EOF而外层循环永远在等待有效数字程序就卡死在读取上。所以gc()返回EOF时一定要让上层感知到在read函数里加if (ch EOF) return 0;的判断。坑4负数最小值溢出。write函数里处理负数时如果有-2147483648这个int最小值先取x -x会导致溢出。正确做法是先将x转为long long再取负或单独处理这个边界值。实话说大部分比赛数据不会真给你int最小值但稳妥起见还是处理一下为好inline void write(long long x) { if (x 0) { out_buf[out_pos] -; x -x; } // ... }注意x的类型直接定义成long long就不会有int最小值取负的溢出问题了。坑5快读函数读的是带前导符号的字符串时逻辑错误。比如输入是42有些快读写法里没有处理正号会把当成非数字字符跳过然后读出了42这没问题。但有一种手滑的写法会把读成非法字符导致死循环判断时要特别注意识别-和都要跳过或妥善处理。7.4 什么时候可以完全不考虑这些最后再说个反向场景如果你平时只写工程代码、不参加算法竞赛、也不需要对海量数据进行格式化解析那cin/cout就是最好的选择。工程代码需要的是可读性、可维护性和类型安全这些cin/cout全都具备而且现在的主流机器上IO开销在大多数业务场景里可以忽略不计。文章里讲的所有性能优化手段都是针对“百万级以上数据量 严格时限”的竞赛场景。所以我的最终建议是面向竞赛建立属于自己的IO模板fread快读fwrite快写是标配面向工程cin/cout 关同步就足够了别为了那点性能搞出一套自维护缓冲来折腾自己希望这篇文章能帮你把输入输出这个问题彻底想透把自己的代码模板在赛前就打磨稳定。别再让一个TLE毁掉一场比赛因为IO选型这件事本来就不该是赛场上需要思考的问题。
