在刷OJ这条路上，几乎每个人都经历过一个“顿悟时刻”：第一次遇到数字大到连long long都装不下的题目。HDUOJ的1002题A + B Problem II，就是这样一个典型的入门关卡。题目本身很短，输入两个超大整数，输出它们的和，看起来和1000题那种Hello World级别的A+B没有区别，但恰恰是“超大”两个字，把无数第一次接触大数运算的人卡在了Wrong Answer的红叉上。
这道题适合所有刚接触算法竞赛、正在练C/C++基础、或者对字符串处理还不太熟练的初学者。把它吃透，不仅能顺利过掉HDUOJ上这道经典题，更重要的是你会建立一种思维：当内置数据类型装不下数据时，怎么用字符串或数组手动模拟计算。这个思维，是后面所有大数问题（大数减法、乘法、除法、高精度模板）的地基。
1. 先读懂题：1002这道题到底在考什么
1.1 题面背后的隐藏考点
先看一下这道题的输入输出格式。第一行是整数T，表示测试数据的组数；接下来每行有两个整数A和B，都是1000位以内的正整数。要求输出格式非常严格：每个样例占一块，先输出“Case x:”，然后换行输出“A + B = C”，块与块之间要有一个空行。注意是每两块之间有空行，最后一块后面不能有多余空行。
很多新手第一次交的时候，思路是直接读入两个整数，相加后输出。结果一看数据范围，傻眼了——1000位的整数，这是个什么概念？C/C++里long long最多能表示到9223372036854775807，大约是19位。就算用unsigned long long，也就到18446744073709551615，20位封顶。1000位是什么量级？那是个天文数字。宇宙中原子的数量大约在10的80次方这个量级，而一个10的999次方的数字，比它还要大10的919次方倍。说白了，1000位的数字大到完全超出了物理世界的常识范围。
所以这个题表面上是A+B，实际上是在告诉你：不要试图把输入当成数字来读，要用字符串来读，把加法过程拆成逐位的操作。这就是大数运算的核心思想。
1.2 为什么数据范围是“1000位”而不是“10的1000次方”
这里涉及一个特别实用的编程习惯问题。很多初学者拿到题不看数据范围，先写一个long long版本，然后交上去WA，再回头看题才发现数据范围。我个人的习惯是，拿到题第一件事就是看数据范围，这直接决定了算法的选型和数据结构的选择。
1000位这个量级其实是个很温和的设定，因为这意味着你用字符串模拟就够了，不需要上FFT之类的优化。如果题目说10万位，那就要考虑压位甚至分治乘法了。数据范围就是题目在告诉你“你可以偷懒到什么程度”，这是ACM刷题里一个非常实用的经验。
1.3 这题在评测系统里的定位
HDUOJ上的题目编号有它的规律，前面的题号大多是入门热身题。1002排在A+B系列里，属于“给你一个下马威但又不至于劝退”的题目。它的定位很明确：检验你会不会把问题拆小、会不会处理字符串、会不会注意输出格式。这三件事，恰好是算法竞赛初赛阶段最高频的考点。把这道题AC了，后面很多类似的模拟题你都会有底气。
顺便说一句，HDUOJ这个平台本身对新手也很友好，题目分类清晰，讨论区里前人踩坑的记录一翻一大堆，适合自测和复盘。我在早期刷题时，大部分基础功底都是在类似这样的OJ上练出来的。
2. 方案怎么选：四种大数加法思路对比
2.1 主流方案的横向对比
大数加法这个问题的解法，按语言和思路可以分成几类，我列个表对比一下：
| 方案 | 核心思路 | 代码量 | 适用语言 | 推荐指数 |
|---|---|---|---|---|
| 字符串模拟 | 从低位到高位逐位相加，记录进位 | 20行左右 | C/C++/Java | 五星 |
| 数组/向量模拟 | 倒序存数字，按位相加 | 30行左右 | C/C++/Java | 四星 |
| 内置大数类型 | BigInteger / BigDecimal | 几乎为0 | Java/Python | 五星但不练基本功 |
| 压位技巧 | 每4位或8位合成一格存储 | 40行左右 | C/C++ | 三星，数据大时才用 |
如果是刚入门C/C++，我强烈建议用第一种方案，也就是字符串模拟。它代码量小，逻辑直观，正好覆盖了字符串转数字、反向遍历、进位处理这些基本功。数组模拟在思路上和字符串模拟几乎一样，只是多了一步“把字符串拆成数字存入数组”的过程，更适合数据位数特别多的场景。压位技巧属于进阶玩法，适合以后打比赛遇到10万位级别的大数时再去研究，现在不需要贪多。
2.2 大数加法的本质：竖式加法的代码化
不管选哪种方案，大数加法的本质都是同一个：手工竖式加法的代码化。小学三年级我们就算过，两个多位数相加，从个位开始，逐位相加，某一位的和超过9就向高位进1，然后高位继续加。程序里做同样的事，只不过：
- 竖式里我们习惯把两个数对齐个位，程序里我们把字符串反转过来，或者从最后一个字符往左遍历；
- 竖式里我们用笔算，程序里用字符减'0'得到数字，加完再转回字符；
- 竖式里的进位靠人脑，程序里用变量记住进位，加到下一位上去。
这里面最关键的思维转换是：字符串的索引是从左到右的，而数字的位权是从右到左的。所以处理的时候要么从右往左遍历，要么先反转再用循环。很多新手在这里栽跟头，就是因为从左往右遍历，导致错位。
2.3 为什么不能直接把字符串转成long long
有人可能会想，我先把字符串转成long long，加完再转回字符串不行吗？问题在于1000位的字符串转成long long会溢出，导致数据丢失。如果你用atoll或者stoll之类的函数，结果会是未定义行为，在OJ上通常就是一堆莫名其妙的错误值。
所以正确的姿势只有一个：老老实实逐位模拟。这也是所有大数问题的通用解法——把数字拆散，逐个击破，让每一位都在安全范围内计算，然后用进位把分散的结果重新串联起来。
3. 核心代码逐行拆解：字符串模拟加法完全实现
3.1 先上完整可提交的模板
下面是我自己最常用的模板，封装成了一个函数方便复用：
#include <iostream> #include <string> #include <algorithm> using namespace std; string addString(const string& a, const string& b) { string res; int carry = 0; int i = a.size() - 1; int j = b.size() - 1; while (i >= 0 || j >= 0 || carry) { int sum = carry; if (i >= 0) sum += a[i--] - '0'; if (j >= 0) sum += b[j--] - '0'; res.push_back(char(sum % 10 + '0')); carry = sum / 10; } reverse(res.begin(), res.end()); return res; }这段代码的核心就一个while循环。循环条件有三个部分：i >= 0、j >= 0、carry。也就是说，只要两个字符串还没遍历完，或者进位还没消掉，循环就继续。这个写法比“先处理公共部分、再处理剩余部分”要简洁得多，而且天然处理了“一个数比另一个数长”和“最后还有进位”两种边界情况。
3.2 进位逻辑与边界条件的推演
我们拿几个具体例子推演一下。假设a = "99"，b = "1"：
- 初始 i = 1, j = 0, carry = 0。
- 第一次循环：sum = 0 + 9 + 1 = 10，res追加'0'，carry = 1，i变为0，j变为-1。
- 第二次循环：sum = 1 + 9 = 10，res追加'0'，carry = 1，i变为-1，j已经是-1。
- 第三次循环：sum = 1 + 0 + 0 = 1，res追加'1'，carry = 0，循环条件全部不满足，结束。
- res = "001"，反转后是"100"，正确。
再看一个更长的数：a = "12345678901234567890"，b = "98765432109876543210"。两个都是20位，结果应该是111111111011111111100。你可以在本地跑一下这个函数验证，凡是边界情况能过，基本就稳了。
另外注意一个细节：字符转数字用a[i] - '0'，数字转字符用sum % 10 + '0'。这一步千万别直接拿字符做加法，否则结果会变成ASCII码相加，输出一堆乱码。
3.3 提交时的主函数写法
HDUOJ对输出格式的要求很严格。完整的主函数长这样：
int main() { int T; cin >> T; for (int t = 1; t <= T; t++) { string a, b; cin >> a >> b; string sum = addString(a, b); cout << "Case " << t << ":" << endl; cout << a << " + " << b << " = " << sum << endl; if (t != T) cout << endl; } return 0; }这里的重点在最后一个if：除了最后一个样例，每个样例输出完之后都要额外输出一个空行。如果你直接每次循环都输出空行，那最后一个样例后面也会多一个空行，OJ会判成Presentation Error。如果你完全不加空行，那样例之间会紧挨着，也是Presentation Error。这两种错误虽然不扣分，但是在HDUOJ的判题里会显示PE，很多人第一次看到这个缩写会一脸懵。
注意：
addString函数里我用的是const string&引用传参，而不是值传参。对于这种可能很长的字符串，引用传递可以避免不必要的拷贝，虽然在这个题里性能影响看不出来，但这是个好习惯。
4. WA和PE实录：新手最容易踩的三个坑
4.1 Wrong Answer：最常见的三类原因
我把实际刷题时遇到最多的WA原因整理成了表格：
| 错误现象 | 根因 | 解决办法 |
|---|---|---|
| 输出结果少了一位 | 最高位进位没处理 | while循环条件加上carry != 0 |
| 结果变成乱码或ASCII符号 | 字符和数字直接相加 | 用 a[i] - '0' 转数字，用 % 10 + '0' 转字符 |
| 结果错位 | 从左往右遍历字符串 | 从 size() - 1 开始倒序遍历，或先反转 |
| 两个加数长度不同时出错 | 只循环到较短字符串的长度 | 循环条件同时判断 i >= 0 和 j >= 0 |
| 输出结果前导零 | 反转前没处理掉进位逻辑里的零 | 用上面的模板，进位逻辑天然避免前导零 |
其中最隐蔽的是第一个：最高位进位。比如"999" + "1"，正常结果是"1000"，但如果你while条件里只写了i >= 0 || j >= 0，那循环会在i和j都变成-1的时候停下来，结果只剩"000"，最高位的1丢了。这个bug在本地测试的时候特别容易漏，因为你会下意识觉得“999+1=1000”这么简单不可能错。我的经验是：凡是涉及加法的模拟题，最后一轮循环一定要把carry算进去。
4.2 Presentation Error：OJ判题规则冷知识
PE在HDUOJ上是个很有意思的判题结果，它的全称是Presentation Error，表示你的答案在逻辑上是正确的，但输出格式和标准答案有差异，比如多了空格、少了空行、换行位置不对。这种错误不算WA，但也不会AC，会显示在提交记录里。我第一次遇到PE就是在这道题上，当时少判断了“块与块之间要空行”这个条件，折腾了十几分钟才发现。
排查格式问题有个小技巧：把样例输出完全复制下来，在自己的程序输出旁边做对比。先看每个Case后面有没有空行，再看最后一次输出后面有没有多余空行，最后看“+”和“=”两边有没有空格。这三个地方是PE的高发区。
4.3 调试技巧：用极端数据自测
在提交之前，我建议你养成一个习惯：先用几组边界数据在本地跑一遍。大数加法至少有这几组必测数据：
- 两个数长度相同：123 + 456；
- 长度不同：9 + 99；
- 有连续进位：999 + 1；
- 结果位数比两个加数都长：999999 + 1；
- 大量数据：构造一个1000位全是9的和一个1000位全是1的，看程序能不能正常跑完。
这些测试不需要什么高级工具，编译器跑一下就行。HDUOJ的时限一般比较宽松，字符串模拟是O(n)级别的复杂度，n是1000，完全没有任何压力。但如果你连极端数据都不测，大概率要在HDUOJ的WA和PE之间来回游走。
5. 学会举一反三：从大数加法到大数运算全家桶
5.1 大数减法与乘法的思路迁移
学会了加法，减法和乘法就是顺理成章的事。减法需要处理的是：先判断两个数的大小，保证大数减小数，然后逐位相减，不够减就向高位借位。乘法稍微复杂一点，可以用两层循环模拟竖式乘法，每一位相乘，结果累加到对应位置，最后统一处理进位。这些题在HDUOJ上都有对应的题目（比如大数阶乘、大数乘法系列），很多是1002的延伸。
从代码结构上看，这些题的共性非常强：字符串读入、倒序遍历或反转、用一个变量或者数组记录进位或借位、最后反转输出。所以你只要把1002吃透，后面的大数题其实都是换汤不换药。
5.2 大数运算在实际场景中的应用
也许有人会问，这套东西在真实工作里有什么用？我举几个例子：
- 金融系统里处理超过double精度范围的金额计算时，必须用高精度方法，避免浮点误差；
- 加密算法里的模幂运算，动辄几百位的大整数，就是大数运算的典型场景；
- 计算哈希、校验和时，有时需要处理超长数字串；
- 科学计算、天文数据处理中，超大数字更是家常便饭。
算法竞赛里学的大数运算，本质上是一种“用基础类型拼出更大能力”的思路。这个思路在你处理任何超出当前工具能力范围的问题时都适用，不只是数字。
5.3 用自己的模板沉淀解题经验
还有一个建议：从这道题开始，把常用的代码片段整理成自己的模板库。比如字符串加法、减法、乘法、比较大小，都封装成独立的函数，放在一个文件或代码模板里。以后遇到高精度题，直接复用，而不是每次重新写一遍。
我自己的模板库里，至今还留着当年写的大数加法函数，虽然那个版本写得很朴素，但注释特别详细。翻了翻以前的东西，里面有一句注释我现在还记得：“注意最后一个进位别忘了加”。这就是刷OJ最有价值的地方——它逼着你在错误中记住那些关键细节，而不是看完就算。
最后再分享一个小经验。我在刷这道题的时候，其实一开始也犯了“看见A+B就直接用int”的毛病，WA了三次才反应过来去看数据范围。后来我养成一个习惯：每次写完代码，先不看题，先看一眼题目的数据范围和输出格式，再动手。这两分钟看下来，往往能帮你省下半小时的调试时间。1002这道题之所以经典，就是因为它用一道最容易的题目，把这个问题摆在了每个初学者面前。把这个习惯养成了，你后面的OJ之路会顺很多。
