整数运算这件事，几乎每个学C语言的人都要在某个在线判题平台上被它"教育"一遍。标题里这个"整数简单运算"，看着平平无奇，实际上它是一类题目的统称——给两个整数，让你做加、减、乘、除、取余，然后按格式输出。很多人第一次提交就WA（Wrong Answer），盯着代码看半天，逻辑明明没错，问题却出在别的地方。这篇内容就是围绕这类上机题展开的，把整数运算里那些"看着简单、实际有坑"的地方一次讲透，包括输入输出的格式陷阱、整数除法的截断行为、取余的符号规则、溢出的边界处理，以及判题系统对输出格式的苛刻要求。适合刚接触C语言、正在刷上机题的同学，也适合已经写过一些代码但总在细节上翻车的人。我会用从业者踩坑的视角来讲，不讲教科书式的定义，只讲你真正会遇到的麻烦和解决办法。
1. 为什么"简单运算"反而是WA重灾区
1.1 题目越简单，判题系统越较真
很多人有个错觉：题目描述越短，代码越好写。实际情况恰恰相反。像"输入两个整数，输出它们的和、差、积、商、余数"这种题，逻辑复杂度几乎为零，但判题系统对输出格式的要求却精确到字符级别。多一个空格、少一个换行、中文冒号写成英文冒号，统统判错。
我见过太多这样的情况：代码逻辑完全正确，本地跑出来结果也对，提交上去就是WA。原因往往不是算法，而是输出格式和题目要求差了哪怕一个字符。这类题目的判题方式通常是逐字符比对，你的输出必须和标准答案的字节流完全一致，包括行末是否有空格、最后一行是否有换行符。
举个典型的坑：题目要求输出"a+b=c"这样的格式，你写成了printf("%d+%d=%d\n", a, b, a+b);，看起来没问题。但如果题目实际要求的是每个结果单独一行，或者要求用空格分隔而不是等号，那就全错了。所以做这类题，第一件事不是写代码，而是把题目里的输出格式要求逐字读三遍，把样例输入输出对照着看，确认分隔符、换行、标点符号到底是什么。
提示：判题系统不会告诉你"格式错误"，它只会返回WA。所以格式问题只能靠你自己对照样例排查，这是这类题最耗时间的地方。
1.2 样例通过不等于全部通过
另一个高频误区是"样例过了就万事大吉"。样例通常只覆盖最普通的情况，比如两个正数。但判题系统的测试数据里往往藏着负数、零、大数、边界值。你的代码在样例上跑得漂亮，一提交就挂，多半是没考虑这些隐藏情况。
以整数除法为例，样例给的是7 2，你算出3，没问题。但测试数据里可能有-7 2，C语言的整数除法是向零截断的，-7/2的结果是-3而不是-4。如果你脑子里想的是数学上的向下取整，就会对结果产生误判。再比如除数为零的情况，虽然多数题目会保证除数非零，但有些题会故意给0来测试你的程序会不会崩溃。
所以我的习惯是：写完代码后，自己构造几组"刁钻"的输入——负数、零、一正一负、接近int上限的大数——手动跑一遍，看看结果是否符合预期。这一步花不了几分钟，但能挡掉大部分隐藏的WA。
1.3 整数运算里最容易被忽视的三个行为
在动手写代码之前，有三个C语言整数运算的固有行为必须先搞清楚，它们直接决定了你的结果对不对：
| 运算类型 | 行为规则 | 典型陷阱 |
|---|---|---|
| 整数除法 | 向零截断，丢弃小数部分 | -7/2 = -3，不是-4 |
| 取余运算 | 余数符号与被除数相同 | -7%2 = -1，不是1 |
| 整数溢出 | 超出int范围后回绕 | 大数相乘结果变成负数 |
这三条规则，每一条都能让"逻辑正确"的代码输出错误答案。下面几个章节会逐一拆开讲，配合具体的代码和验证方法。
2. 输入输出格式：判题系统的第一道关卡
2.1 scanf的读入陷阱与返回值检查
读两个整数，最直接的写法是scanf("%d %d", &a, &b);。这行代码本身没问题，但有几个细节值得说。
首先是格式字符串里的空格。"%d %d"中间的空格在scanf里表示"跳过任意数量的空白字符"，包括空格、制表符、换行。所以用户输入3 5、3 5、甚至3回车5，都能正确读入。这一点很多人不知道，以为空格必须严格匹配，其实scanf对空白是宽容的。
但scanf有个更隐蔽的问题：它不检查输入是否成功。如果输入格式不对，比如该读整数的地方来了个字母，scanf会失败，而a和b里可能是未初始化的垃圾值。在判题环境里输入通常规范，但养成检查返回值的习惯没坏处：
if (scanf("%d %d", &a, &b) != 2) { return 1; // 读入失败，直接退出 }scanf返回成功读入的项数，这里期望是2。虽然上机题一般不需要这么严谨，但这是好习惯，尤其在你自己调试的时候，能快速发现"为什么结果是乱码"——多半是读入失败了。
还有一个常见错误是漏写取地址符&。scanf("%d", a)而不是scanf("%d", &a)，编译器可能只给个警告，程序运行时直接崩溃或读到错误地址。这个错误新手特别容易犯，而且因为编译能过，排查起来很费劲。
2.2 printf的输出格式必须逐字符对齐
输出是这类题最容易翻车的地方。题目要求什么格式，你就得输出什么格式，一个字符都不能差。常见的格式要求有这么几种：
- 每个结果单独一行：
printf("%d\n%d\n", a+b, a-b); - 用空格分隔：
printf("%d %d\n", a+b, a-b); - 带文字说明：
printf("sum=%d\n", a+b);
关键在于看清楚题目给的样例输出。样例输出里有没有空格、有没有换行、文字部分用的是什么符号，全部照抄。我一般会把样例输出复制到记事本里，打开"显示所有字符"功能，确认行末到底有没有多余空格。
这里有个特别隐蔽的坑：行末空格。有些题目要求输出a b c三个数用空格分隔，你写成printf("%d %d %d\n", x, y, z);，最后一个数后面没有空格，这是对的。但如果你写成循环输出printf("%d ", x);，最后一个数后面就会多一个空格，判题系统可能因此判错。解决办法是最后一个元素单独处理，或者用条件判断控制空格。
// 错误写法：末尾多一个空格 for (int i = 0; i < 3; i++) { printf("%d ", arr[i]); } // 正确写法：最后一个不带空格 for (int i = 0; i < 3; i++) { printf("%d", arr[i]); if (i < 2) printf(" "); }注意：不同判题系统对行末空格的处理不一样，有的会忽略，有的严格比对。稳妥起见，一律按"不多输出任何字符"来写。
2.3 换行符与平台差异
还有一个容易被忽略的点：换行符。在Windows上，文本文件的换行是\r\n两个字符；在Linux上，换行是\n一个字符。判题系统通常跑在Linux环境，你用printf("\n")输出的是\n，没问题。但如果你在Windows下用某些编辑器保存文件，或者手动输入了\r，就可能出问题。
不过对于纯代码提交的判题系统，这个一般不用担心，因为你的\n在编译后就是\n。真正需要注意的是不要多输出换行。比如题目要求输出一行结果，你习惯性地在最后多写一个printf("\n");，就多了一个空行，可能被判错。
我的经验是：输出格式严格对照样例，样例有几行你就输出几行，样例末尾有没有空行你就跟着来。不确定的时候，宁可少输出一个换行，也不要多输出。
3. 整数除法与取余：符号规则是最大的坑
3.1 整数除法的向零截断
C语言里两个整数相除，结果还是整数，小数部分直接丢弃。这个"丢弃"的方向是向零取整，也就是往数轴原点方向靠。正数除法好理解，7/2=3，因为3.5截断成3。负数就不直观了：-7/2，数学上是-3.5，向零截断得到-3，而不是向下取整的-4。
这个规则在判题时经常被用来设陷阱。比如题目让你算两个数的商，测试数据里放一组-7 2，标准答案是-3。如果你用浮点数算完再转int，或者脑子里按数学取整来想，就可能写出错误的结果。
验证方法很简单，写个小程序跑一下：
#include <stdio.h> int main() { printf("%d\n", -7 / 2); // 输出 -3 printf("%d\n", 7 / -2); // 输出 -3 printf("%d\n", -7 / -2); // 输出 3 return 0; }三组结果都是向零截断。记住这个行为，遇到负数除法就不会想当然。
3.2 取余运算的符号跟随被除数
取余的规则比除法更容易记混。C语言里，a % b的结果符号跟a（被除数）一致，和b（除数）无关。所以：
7 % 2 = 1-7 % 2 = -1（符号跟-7）7 % -2 = 1（符号跟7）-7 % -2 = -1（符号跟-7）
这个规则和数学上"余数非负"的约定不一样，很多人第一次遇到会懵。判题系统如果考负数取余，标准答案就是按C语言的规则来的，你按数学规则算反而错。
有个实用的记忆口诀：余数的绝对值小于除数的绝对值，符号看被除数。写代码时如果对结果没把握，直接打印出来验证，别靠脑补。
3.3 除零与取余零的崩溃问题
整数除法里，除数不能为零，否则程序直接崩溃（运行时错误，通常是SIGFPE信号）。取余也一样，a % 0同样会崩。多数上机题会明确说"保证除数不为零"，但有些题不保证，或者故意用零来测试你的防御性。
稳妥的做法是在运算前判断：
if (b != 0) { printf("%d %d\n", a / b, a % b); } else { // 按题目要求处理，比如输出特定提示或跳过 }题目怎么要求就怎么处理，但至少你的程序不能崩。判题系统遇到程序崩溃，返回的通常是RE（Runtime Error），和WA是两种不同的错误，排查方向也不一样。
4. 溢出与边界：int装不下的时候怎么办
4.1 int的取值范围与溢出回绕
C语言里int通常是32位，取值范围是-2147483648到2147483647，也就是大约正负21亿。两个整数做加法或乘法，结果一旦超出这个范围，就会溢出回绕——结果变成一个完全不相干的数，通常是负数。
比如2000000000 + 2000000000，数学上是40亿，但int装不下，实际结果是-294967296。这种错误在样例里看不出来（样例通常是小数字），但测试数据里一旦有大数就暴露了。
判断会不会溢出，可以在运算前估算：如果a和b都是正数，且a > INT_MAX - b，那么a+b就会溢出。乘法更复杂，需要判断a > INT_MAX / b。不过对于"简单运算"这类题，如果题目没说要处理大数，通常测试数据在int范围内，不用过度设计。但如果你不确定，用long long更保险。
4.2 用long long兜底的取舍
long long是64位整数，范围到约正负9.2×10^18，基本能装下绝大多数上机题的数据。把变量声明成long long，输入输出用%lld，就能避免大部分溢出问题。
#include <stdio.h> int main() { long long a, b; scanf("%lld %lld", &a, &b); printf("%lld\n", a + b); return 0; }代价是内存占用翻倍，但对于这种小题完全无所谓。我的建议是：如果题目数据范围接近或超过10^9，直接用long long，别在int上赌。多写几个字符，省去排查溢出的时间，这笔账很划算。
不过要注意，long long的输入输出格式符是%lld，用错了（比如用%d读long long）会导致读入错误，而且编译器不一定报错，排查起来很痛苦。这是用long long唯一需要小心的地方。
4.3 边界值的自测清单
写完代码，我习惯用下面这组边界值自测一遍，能覆盖大部分隐藏陷阱：
| 测试类型 | 输入示例 | 关注点 |
|---|---|---|
| 正数常规 | 7 2 | 基本正确性 |
| 负数除法 | -7 2 | 截断方向 |
| 负数取余 | -7 2 | 余数符号 |
| 除数为负 | 7 -2 | 商和余数符号 |
| 含零 | 0 5 | 零参与运算 |
| 大数 | 2000000000 2000000000 | 是否溢出 |
| 相等 | 5 5 | 商为1余为0 |
这七组跑下来没问题，基本可以放心提交。花两分钟自测，比提交后反复WA再回头找问题高效得多。
5. 一套可复用的提交前检查流程
5.1 从读题到提交的固定动作
刷这类简单运算题，我总结了一套固定流程，每次按顺序走一遍，能挡掉九成以上的低级错误：
- 逐字读输出格式：把题目要求的输出格式和样例输出对照，确认分隔符、换行、文字说明。
- 确认数据范围：看题目有没有给数据范围，接近int上限就用long long。
- 写核心运算：加减乘除取余，注意除法和取余的符号规则。
- 加除零判断：如果题目不保证除数非零，加个if。
- 本地跑样例：样例输入输出必须完全一致。
- 跑边界自测：用上一节的七组数据过一遍。
- 检查行末空格和多余换行：对照样例，不多输出任何字符。
这套流程走下来，一道简单运算题从读到提交不超过十分钟，而且返工率极低。
5.2 常见错误对照表
把这类题的高频错误整理成表，提交前扫一眼，对号入座：
| 错误现象 | 可能原因 | 排查方向 |
|---|---|---|
| WA，样例却通过 | 隐藏测试数据含负数/大数 | 检查除余符号、溢出 |
| WA，格式看着对 | 行末空格或多余换行 | 逐字符比对样例 |
| RE运行时错误 | 除数为零 | 加除零判断 |
| 结果乱码 | scanf漏写&或格式符错 | 检查读入语句 |
| 大数结果变负数 | int溢出 | 改用long long |
这张表基本覆盖了"整数简单运算"类题目的所有常见故障。遇到问题先查表，比盲目改代码快得多。
5.3 关于"简单题"的心态
最后说点实在的。这类题目的价值不在于算法难度，而在于训练你对细节的敏感度。真正写工程代码的时候，整数除法的截断、取余的符号、溢出的处理，这些"简单"的知识点天天都在用。上机题把它们单独拎出来考，就是逼你把基础打扎实。
我见过不少人觉得这种题"太简单不值得认真"，结果在真实项目里因为一个整数除法写错方向，排查了大半天。基础不牢，后面全是坑。所以别嫌题简单，把每一道都当成练基本功的机会，格式抠到字符级，边界想到极端值，这个习惯养成了，受益的是后面所有代码。
提示：如果判题系统支持查看测试点信息（有些会显示第几个测试点错了），一定要利用起来。错在第几个点，往往能反推出是哪类数据出了问题，比盲猜高效得多。
