HDUOJ上做过ACM入门题的人，十有八九都卡过1002这道题。题面看着人畜无害，不过是A+B嘛，第一题的升级版，但真正动手写的时候才发现：这题完全不是“加法”那么简单，而是一道货真价实的大数加法。题目里给的数能到1000位以上，int装不下，long long也装不下，C++里甚至连一个能直接处理这么大整数的原生类型都没有，只能自己动手模拟手算竖式的过程。这篇文章我想把这道题从原理到实现、再到输出格式的坑，完整拆开讲一遍，给正在刷HDUOJ的初学者当一份参考笔记。
我当年第一次交这道题时，样例测试全对，结果一提交就收到一个鲜红的WA，当时整个人是懵的。后来排查了半天才发现，问题根本不在加法逻辑上，而是输出格式里那一个不起眼的空行。这类“隐藏条件”恰恰是OJ题最折腾人的地方，也是初学者最容易忽略的地方。所以这篇文章不只是讲算法，更想帮大家避开那些非算法层面的坑，把这些用WA换来的经验一次说清楚。
1. 题目到底在考什么：A+B Problem II 的真实意图
1.1 从 A+B Problem 到 A+B Problem II 的跨越
HDUOJ的第1000题是经典的“A+B Problem”，也就是输入两个普通的整数，输出它们的和。那个题用int就能轻松解决，其实它真正的目的是让大家熟悉OJ的输入输出机制，比如循环读入、多组数据、标准输出这些基本操作。
但到了第1002题，事情就不再单纯了。题目的名字沿用“A+B Problem”，但后面加了个“II”，意味着这不再是一道“直接相加”的题目。题目中给出的整数可以非常巨大，长度可以达到上千位。这种数字有多大呢？可以做一个类比：int的取值范围大约是正负21亿，long long也只能到19位十进制数左右；而一个1000位的数字，约等于在long long后面再拉出980多个数字。现实世界里，这种数量级只会出现在天文计算、加密算法和某些科研数据中，用普通的电脑数值类型根本无法承载。
所以这道题真正想考察的核心，是“高精度运算”或者说“大数运算”的基本思路——当内置类型放不下时，如何处理超出范围的大数值？这要求解题者主动绕过数值类型的限制，寻找一种不依赖CPU原生整数能力的计算方式。
1.2 大数加法的本质：模拟竖式与进位
要理解这道题的解法，最直观的方式就是回忆小学时做过的竖式加法：
12345678901234567890 + 98765432109876543210 ----------------------手算时，我们从最右侧的个位开始逐位相加，逢十进一，一位一位地向左推进。大数加法算法的本质，就是把这一整套手工流程移植到程序里。不过，程序里没有“纸和笔”，所以需要借助数组或字符串来保存这些超出的位数，再用循环来模拟自右向左的逐位相加过程。
这里的关键点有三个：第一，大数的每一位都要独立存储，不能整体塞进一个数值变量；第二，相加的顺序必须从低位往高位进行，这与竖式的习惯完全一致；第三，进位必须被正确处理，因为每一位相加的结果一旦超过9，就需要把多出来的部分推进到下一位。听上去不复杂，但实际编码时，很多人会在前导零、数组长度和进位这几点上翻车。
2. 核心算法设计与步骤拆解
2.1 解法选型：为什么选择字符串模拟而不是别的方案
面对大数加法，常见的编程思路有好几种。第一种是用数组存储每一位数字，然后用嵌套循环模拟竖式；第二种是用Java的BigInteger或者Python的任意精度整数，直接把大数问题丢给内置类库处理；第三种则是用C++自己封装一类“大数结构”来复用，但这对于一道入门题来说明显杀鸡用了牛刀。
对于这道题，我推荐的思路是“字符串转整型数组，再用数组模拟加法”。原因很简单：第一，C和C++的字符串可以直接用string类型处理，读入和输出都方便；第二，数组逐位加法的实现难度低，代码量小，出错率也低；第三，这个思路可以平滑迁移到后续的A+B Problem III、大数乘法、大数阶乘等高精度题目上。说到底，高精度的“地基”就是“大数加法字符串模拟”，把这个地基打牢，后面很多题都顺手得多。
有人可能会问：用Java的BigInteger不是更省事吗？确实省事，直接a.add(b)就完事，面试和竞赛的某些场景里这也是合理选择。但如果是ACM初学者，我建议第一版至少用C++/C语言手动实现一次，搞清楚内部原理。否则以后一旦遇到语言库不能直接用、或者需要自己构造高精度结构的题目，会非常痛苦。
2.2 用数组模拟竖式加法的完整步骤
以C++为例，整个实现可以分为四步。
第一步，用两个字符串接收输入的大数。例如读入99999999999999999999和1，此时它们还只是字符串，并不是数值。
第二步，把字符串里每一位字符转成对应的数字，并且倒序存入整型数组。为什么要倒序？因为竖式加法是从个位数开始的，而字符串读取的a[0]是最高位（最左边的字符）。如果正着存，从数组下标0开始相加，那就相当于从最高位开始计算，进位处理起来会变得非常别扭，输出的时候也容易出错。所以倒序存储后，数组下标0就表示个位，下标1表示十位，依次类推。
比如字符串"123"倒序存入数组后：
num[0] = 3（个位）num[1] = 2（十位）num[2] = 1（百位）
第三步，按位相加并处理进位。用一个循环从下标0开始遍历到最长的那个数组长度，每次计算sum = A[j] + B[j] + carry。这里的carry是上一位产生的进位，初始时是0。如果sum大于等于10，就让当前位的结果取sum % 10，同时把carry置为sum / 10；如果sum小于10，当前位就是sum，carry归零。
第四步，检查最高位是否还有残留进位。如果两个长度相等的大数，例如999 + 1，加完之后产生了一个额外的千位进位，那么需要在结果数组的最高位再补一个1，同时结果的长度要增加1位。
2.3 进位的特殊处理与前置零问题
进位问题看着简单，但边界条件一旦没考虑到，结果就一整片全错。比如下面这几个典型场景：
999 + 1：逐位相加后最终会产生一个长度为4的结果1000，如果不做“残留进位”的补位，结果就会变成000，完全错误。123 + 456：每一位相加都不超过9，全程没有进位，输出结果应为579，这算是最简单的一种情况。0 + 0：两个数组都是0，最后结果数组全是0，这时候必须在输出时特判，否则逆序输出可能会什么都不输出，甚至造成越界。
前导零的处理也值得单独说。如果按照倒序存储的数组直接逆序输出，正常情况下最高位不会是0。但在某些写法里，如果声明了定长数组而没有清理多余空间，前面那些“没用到”的元素可能残留随机值，甚至带来了前导零。保险的做法是：按照实际计算结果的长度len来控制输出范围，只输出下标len-1到0的元素，不要多输出一个字节。
3. 从思路到代码：C/C++ 实现与格式细节
3.1 一份可以直接 AC 的 C++ 参考代码
说再多不如直接给代码。下面这份代码我自己在HDUOJ上重测过，可以直接通过，注释也写得比较详细：
#include <iostream> #include <string> #include <algorithm> using namespace std; int main() { int n; cin >> n; for (int i = 1; i <= n; i++) { string a, b; cin >> a >> b; int A[1005] = {0}, B[1005] = {0}, C[1005] = {0}; int lenA = a.length(); int lenB = b.length(); // 倒序存入数组，下标0表示个位 for (int j = 0; j < lenA; j++) { A[j] = a[lenA - 1 - j] - '0'; } for (int j = 0; j < lenB; j++) { B[j] = b[lenB - 1 - j] - '0'; } int len = max(lenA, lenB); int carry = 0; for (int j = 0; j < len; j++) { int sum = A[j] + B[j] + carry; C[j] = sum % 10; carry = sum / 10; } // 处理最高位的残留进位 if (carry) { C[len] = carry; len++; } // 输出 cout << "Case " << i << ":" << endl; cout << a << " + " << b << " = "; for (int j = len - 1; j >= 0; j--) { cout << C[j]; } cout << endl; // 注意：除最后一个测试数据外，每个输出后面都要跟一个空行 if (i != n) { cout << endl; } } return 0; }这段代码里，数组长度直接开了1005。题目中给出的数字长度不会超过1000位，两个1000位相加得到的结果最多1001位，所以1005的空间足够安全。如果你更严谨，可以用动态数组比如vector<int>来自适应扩容，但对于入门题来说，定长数组够了。
3.2 HDUOJ 的输出格式：Case编号与空行的坑
这道题真正把无数人绊倒的地方，在输出格式。题目要求每个测试用例输出两部分内容：
- 第一行是
Case i:，其中i是测试用例的编号，从1开始。 - 第二行是
a + b = sum，也就是原样输出两个输入的大数、加号和最终结果。
更重要的是，每个Case i: ...输出之后，除了最后一个测试用例，每个结果后面都要接一个空行。很多人提交WA，原因就是最后一行多余输出一个endl，或者少了一个空行。在线评测系统对输出是严格匹配的，多一个空格、少一个换行都算错误，更不用说整个空行错位了。
正确习惯是：if (i != n) cout << endl;。这样最后一个用例的输出结尾是干净的，不留下多余的空白行。这也是一个通用的OJ输出经验：凡是样例之间有间隔的，都要用“先判断是不是最后一个再输出间隔”的方式处理，而不是“先输出内容再固定输出间隔”，否则末尾几乎一定会带一个多余空行。
3.3 用 Java 和 Python 偷懒的正确方式
如果你用的是C++，老老实实模拟竖式是最有收获的。但如果你用的是Java或Python，确实有更省力的大数处理方案。
Java的BigInteger可以支持任意精度的整数运算。在这道题中，只需要把读入的字符串转为BigInteger，再使用add方法求和。但要注意，Java的输出也要严格遵循空行规则，不能因为使用了类库就忽略格式。示例片段如下：
import java.math.BigInteger; import java.util.Scanner; public class Main { public static void main(String[] args) { Scanner sc = new Scanner(System.in); int n = sc.nextInt(); for (int i = 1; i <= n; i++) { String a = sc.next(); String b = sc.next(); BigInteger bigA = new BigInteger(a); BigInteger bigB = new BigInteger(b); BigInteger sum = bigA.add(bigB); System.out.println("Case " + i + ":"); System.out.println(a + " + " + b + " = " + sum); if (i != n) { System.out.println(); } } sc.close(); } }Python更直接，因为Python内置的int本身就不限长度，所以只要用int(a) + int(b)就能完成计算。示例：
n = int(input()) for i in range(1, n + 1): a, b = input().split() sum_val = int(a) + int(b) print(f"Case {i}:") print(f"{a} + {b} = {sum_val}") if i != n: print()这两个方案可以帮你快速AC，但如果你在系统学习算法，我还是建议至少用C++手写一次大数加法。因为高精度的思想在很多题目里都会变体出现，比如大数乘法、大数阶乘、大数幂运算、大数比较等，只会BigInteger而不懂原理，后续会非常被动。
4. 常见问题与 WA 排查实录
4.1 样例测试通过，提交却WA：先查输出格式
这道题最常见的WA原因绝对不是什么算法缺陷，而是输出格式。具体来说，有三种情况最容易出问题。
第一种，Case i:后面多打了空格。题目要求的样式是Case 1:，如果你输出成Case 1 :，字符间多了一个空格，OJ就会直接判WA。有些人是因为直接抄代码时没注意，有些人是因为“看起来好看”加了空格，结果就被精准打击。
第二种，表达式行的加号两侧空格。题目明确要求a + b = sum这样的形式，加号和等号两侧都是有空格隔开的。如果你把空格漏掉，或者写成a+b = sum，照样WA。
第三种，空行位置不对。很多初学同学习惯在每次输出结束后都打印一个空行，但最后一个测试用例后面多出的空行会让OJ判定输出不匹配。解决办法就是前面提到的if (i != n)判断。
排错建议：把代码提交前，自己在本地模拟几组数据，然后对照题目要求的输出格式逐字核对。尤其是肉眼不容易注意到的空格和空行，最好用一个能显示行尾符的编辑器（比如VS Code的插件或Notepad++）检查。
4.2 数组越界和长度计算错误：隐蔽但致命的边界条件
除了输出，数组和长度相关的错误也是一大痛点。比如声明数组长度时只用1000，你觉得题目说“1000位”，数组开到1000就够了，结果两个1000位的数相加可能产生1001位的结果，此时len++之后数组越界，程序在本地可能正常，但OJ运行时直接RE（Runtime Error）。这种事我第一次写的时候也遇到过，后来养成了习惯：数组一律比需求多开5到10个元素，反正内存不差那几个字节。
长度计算还有一个坑：len = max(lenA, lenB)之后，如果最高位相加产生进位，你不仅要len++，还要确保当前位已经对C[len]赋值后再输出。有些代码在进位分支里忘了给C[len]赋值就直接len++，那输出的时候就会把数组里残留的垃圾数据打印出来，得到一串莫名其妙的大数，而不是预期的进位1。
边界测试可以重点检查这几组数据：
0 + 0，结果应为0。999 + 1，结果应为1000，检查残留进位。1 + 999，结果应为1000，验证两个数长度不同且进位的场景。123456789 + 987654321，结果应为1111111110。99999999999999999999 + 1，结果应为100000000000000000000，这组数据直接考验数组长度和进位处理。
4.3 调试技巧：自己当评测机，手动生成有效数据
没有特殊评测环境时，自己写一个简单的对拍脚本是排查逻辑的最好方式。我个人的做法是：写两个程序，一个是使用string模拟大数加法的标准程序，另一个是直接用Python或者Java的BigInteger算出的正确答案；然后用随机数据跑一遍，对比两边输出。如果发现不一致，就可以锁定是进位逻辑还是格式问题。
具体操作也不难。先用Python写一个生成随机大数测试数据的脚本，生成比如50组500位左右的随机大数对，然后分别喂给两个程序执行，最后用diff或者简单的文件对比工具比较输出。如果输出一致但OJ仍然WA，那问题大概率出在格式和细节上，而不是算法本身。
还有一个很值得养成的习惯：把出错的那一组测试数据保存在文本文件里，作为回归用例加入你的本地测试集中。以后无论怎么改代码，每次运行前先跑一遍这些历史WA用例，能避免改了一处却把另一处改崩的低级失误。
4.4 关于“Case”编号的另一种常见误区
有些同学会误把Case这一行和表达式放在同一个输出里，比如写成Case 1: 3 + 4 = 7。在少数OJ题里，确实允许这种单行输出，但HDUOJ的1002题明确要求分两行显示。要留意题目原描述里的输出样例，严格按照样例的换行格式来，不要想当然地合并。
另外一个相关性很强的问题：如果输入文件本身以EOF结束而不是先给一个n，那么循环条件通常写成while (cin >> a >> b)，循环内部的Case编号用一个自增变量来维护。这一点虽然和本题不是完全一致，但在后续更多HDUOJ题目里经常出现，可以提前了解，免得换一道题又卡住。
5. 从这道题延展出去：高精度计算还能用在哪些场景
5.1 大数乘法与阶乘的扩展思路
大数加法解决之后，下一道常见的变体就是大数乘法，比如HDUOJ的1042题“N!”，要求计算一个10000以内整数的阶乘，结果是一个极其夸张的大数。做加法时我们只需要维护一个进位，而做乘法时，需要用一个数组保存当前“大数”的每一位，再用外层数字去逐位相乘，并且每乘完一位都要立刻处理进位；如果乘数和被乘数都是大数，则还需要循环嵌套，最后把乘数不同位产生的中间结果错位相加。这些操作都建立在大数加法的逻辑之上：用数组保存大数、倒序存储、模拟进位。
从工程的角度看，大数运算常用于密码学中，例如RSA加密算法需要对数百位的大数做乘法和取模运算，普通CPU的整数指令根本无能为力。理解高精度的模拟过程，也能帮助你理解为什么加密算法在计算机内部可以处理那么大块的数值。
5.2 字符串处理能力的提升
1002这道题表面上是大数运算，实际上也是字符串处理的入门训练。输入的“大数”本质是一串字符，程序必须要完成字符到数字的转换、字符串求长度、按位定位、逆序输出等操作。这些基本功在后续的题目中非常常见，比如大数比较、高精度减法、高精度求余、进制转换等，绝大部分实现最终都会落到“把字符当数字处理”这个基础上。
初学者如果能彻底弄明白这道题的每一步，尤其是为什么倒序存储、为什么用字符减法-'0'、为什么输出时从len-1开始，那么后面接触到字符串处理类题目时会感觉顺畅很多。
5.3 不用BigInteger时的应对策略
有些同学在本地IDE里用Python或Java跑通之后，就误以为自己已经掌握了这道题。但如果参加的是限制语言或者不允许用大数类的比赛，就要求你仍然能徒手写出模拟算法。我建议你至少做到这种程度：不借助任何外力，在白纸上能写出C/C++的数组模拟版本。如果连这一步都能流利完成，那么大数运算的基础才算真的扎实了。
我的个人打分标准很简单：把代码里的数字类型和数组清空，闭上眼睛，能完整推导出每一行代码的作用，并能解释A[j] + B[j] + carry这个表达式中carry的初始值和最终值是什么，这道题就算彻底学透了。
6. 新手避坑清单与当地提交的注意事项
6.1 常见的“看似无关”的细节问题
新手第一次刷HDUOJ时，还会遇到一些和算法无关但影响提交结果的问题。比如有些编译器不支持C++11的某些语法特性，需要保持代码风格保守，避免使用太新但OJ编译器不支持的写法。再比如main函数必须记得return 0，这个习惯在ACM竞赛里不算硬性要求，但在一些严格配置的OJ上可能影响最后的返回状态。
还有一个细节是数据读入时，要注意输入数据中可能含有前导空格、空行之类的干扰。虽然HDUOJ的1002题格式比较友好，但有些题目的输入样例中会在数字和数字之间夹入多余空格，稳妥的读入方式还是直接用cin >>或者scanf，让标准输入流自己过滤空白字符。
6.2 对比工具的简单使用
如果你到了本地测试和OJ提交结果不一致的尴尬境地，建议学会使用文件输入输出重定向。本地调试时可以在代码运行目录放置input.txt，然后通过命令行重定向把文件内容喂给程序：
./main < input.txt > output.txt之后再写一个Python的基准程序，生成一个std_output.txt，用diff命令逐行比较：
diff output.txt std_output.txt一旦出现差异，diff会精确地告诉你哪一个字符、哪一行的内容不一致。大部分情况下，这种对比能直接揪出空格、空行和小数点般的隐蔽问题。
提示：如果
diff毫无输出，说明两个文件完全一致，此时就要把怀疑的目光移回算法逻辑本身，而不是继续与输出格式较劲。
7. 关于这道题我的几点实操体会
做1002这道题的过程，其实比AC本身更值得回味。刚开始我试图用long long直接存两个数相加，跑第一组数据就爆了；后来改用字符串模拟，格式又WA了几次；等到终于AC的时候，再去翻别人的题解，发现几乎没什么高深的优化空间，就是最朴素的逐位加法。这也从一个侧面说明：很多时候竞赛题目卡住我们的不是“不会”，而是“不够细心”，以及“缺少处理边界情况的习惯”。
如果你正在刷HDUOJ的入门题，我真心建议在AC之后再多做一步：把代码里的数组长度改成动态分配，或者尝试不依赖string库，改成C风格字符数组来解决；甚至可以顺手把大数加法的代码改成大数减法或者大数乘法。这种举一反三的练习，比连续做十道同类型题目更能锻炼对数据结构和算法的敏感度。
最后再分享一个我后来一直沿用的习惯：每次提交OJ前，都在心里把题目输出样例的最后一行检查一遍，确认没有多余的换行或空格。这道题让我养成的检查习惯，在后续几十道题里帮我避免了很多无谓的WA。希望这篇文章也能帮你顺利AC这道经典的大数入门题，把HDUOJ 1002这一关稳稳迈过去。
