我至今记得第一次把“1加到100”算成100的那个深夜。屏幕上那个孤零零的数字，一度让我怀疑是程序把本该输出5050的结果只留下了最后一项。后来我才明白，问题出在一行看起来人畜无害的代码上：sum = i;。
在C语言初学者的典型错误里，“循环变量i”和“固定值n”还有“累加器sum”这三者的角色，几乎每届新手都要搞混一遍。这篇文章既是我的调试手记，也是我对这个经典错误的一次复盘：从一行错误的赋值代码出发，把for循环真正的执行节奏拆开看，搞清楚为什么sum = i不是累加而是覆盖，为什么有人会把n++当成i++，以及如何靠一套简单的习惯，让自己不再栽进同一个坑里。内容不复杂，但值得你花十分钟认真走一遍。
1. 先看“病号代码”：sum = i 与 sum = n 的迷惑现场
1.1 一个永远输出“最后一个数”的求和程序
很多初学者第一次写累加求和，代码长这样：
#include <stdio.h> int main(void) { int n = 100; int sum = 0; for (int i = 1; i <= n; i++) { sum = i; // 经典错误：赋值覆盖，不是累加 } printf("sum = %d\n", sum); return 0; }运行结果：
sum = 100我猜你第一反应是：“编译器是不是把我的5050吞掉了？”其实完全没有。程序非常忠实、非常机械地执行了你的每一行指令，问题出在循环体里那一句sum = i。
sum = i的意思是把i的当前值直接复制进sum，原来sum里存的所有内容全部丢弃。循环变量i从1走到100，每轮循环都把sum“刷新”成当前i的值。最后一轮循环i = 100，所以sum定格在100。这不是“只输出最后一位”，而是sum从来没有做过加法，它只是在不断被覆盖。
1.2 症状对照表：同一个错误的不同“马甲”
混淆循环变量与固定值，并不只有sum = i一种写法。我整理了一份常见“马甲”对照表，全部以n = 100、期望结果5050为例：
| 错误写法 | 实际输出 | 出错本质 |
|---|---|---|
sum = i; | 100 | 循环变量直接覆盖累加器 |
sum = n; | 100 | 固定边界值赋给累加器 |
sum += 1; | 100 | 把“变化量i”写成了常量1 |
sum = i + n; | 200 | 每一轮都丢弃历史累加结果 |
for(...; n++) { sum += i; } | 死循环 | 更新动作作用在固定值n上，循环变量没有变化 |
这些写法表面各不相同，本质上都没有分清一件事：哪个变量负责“变”，哪个变量负责“定”，哪个变量负责“攒”。循环变量i负责“变”，边界固定值n负责“定”，累加器sum负责“攒”。一旦把三者的职责搞乱，程序就会以各种匪夷所思的方式回报你。
2. for循环的执行节奏：初始化一次、条件判断N+1次、更新N次
2.1 逐拍拆解：判断、执行、更新到底谁先谁后
要把sum = i为什么是错的理解透，光靠“记住写法”没有用，得看for循环底层究竟按什么顺序跑。
for (init; condition; update) body;的完整执行顺序是：
- 执行
init：初始化语句，整个循环只执行一次。 - 判断
condition：若为真，进入循环体；若为假，跳出循环。 - 执行
body：循环体内的语句。 - 执行
update：更新语句，通常是i++。 - 回到第2步，再次判断
condition。
我用一张表模拟n = 100时正确累加代码sum += i的早期几轮：
| 步骤 | 当前i | 判断 i<=100 | 进入循环体 | 执行后sum | 执行i++后i |
|---|---|---|---|---|---|
| 初始化 | 1 | — | — | 0 | 1 |
| 第1轮 | 1 | 真 | 是 | 1 | 2 |
| 第2轮 | 2 | 真 | 是 | 3 | 3 |
| 第3轮 | 3 | 真 | 是 | 6 | 4 |
| ... | ... | ... | ... | ... | ... |
| 第100轮 | 100 | 真 | 是 | 5050 | 101 |
| 第101次判断 | 101 | 假 | 否 | — | — |
注意一个容易被忽略的细节：i++是在循环体执行完之后立刻执行，然后再进行下一次判断。也就是说，最后一次循环体执行完毕后，i先变成101，再去判断101 <= 100为假，循环才结束。
这个“先判断、再执行、后更新”的节奏，是理解一切for循环错误的钥匙。很多人把for循环看成一个“黑盒子”，只关心循环次数，不关心每一步谁先谁后，于是当循环体内的变量关系稍微模糊一点，就会写出神奇的代码。
2.2 为什么sum = i不是累加而是覆盖
“=”在C语言里是赋值，不是数学意义上的“相等”。sum = i的意思是：把i的值复制到sum的内存空间。原来sum`里存的是什么，无所谓，直接扔掉。
这就像你面前有一个存钱罐sum，你手里有一张当前价值的卡片i。
sum = i：把存钱罐倒空，再把这张卡片塞进去。sum += i：往存钱罐里又扔一枚硬币，罐子里的钱越来越多。
如果你要的是累加，就必须让右侧出现sum自己：sum = sum + i。这个写法对刚开始学编程的人确实很反直觉，因为在数学里你不会写“一个数等于它自己加另一个数”。但在C语言里，赋值号的执行逻辑是“先算右边，再把结果写到左边”。
那sum = n呢？更直接——n在整个循环里压根没变过，所以每轮循环sum都被赋成同一个固定值100。这就不是“只输出最后一个数”的问题了，而是“每轮都在重复写入同一个固定值”。程序没有任何语法错误，逻辑上却完全站不住脚。
还有一种与之类似、但更隐蔽的“一行错误代码”也值得点名：
for (int i = 1; i <= n; i++); { sum += i; }for那一行的末尾多了一个分号，这个分号本身就是一个空语句，构成了for循环的循环体。也就是说，循环体里什么都没做，只是空转100次；后面的花括号块是在循环结束之后才执行的一次普通代码块。如果i在for外部定义，你会看到程序编译能通过，但sum只加了一次已经变成101的i，结果完全错误。这就是不理解执行节奏的直接后果。
2.3 累计过程的“接力棒”模型
我用一个小规模例子，把正确累加和错误覆盖放在一起对比。假设n = 3，期望结果是1 + 2 + 3 = 6。
正确代码sum += i的逐轮状态：
| 轮次 | 进入前sum | 当前i | 执行后sum |
|---|---|---|---|
| 第1轮 | 0 | 1 | 1 |
| 第2轮 | 1 | 2 | 3 |
| 第3轮 | 3 | 3 | 6 |
错误代码sum = i的逐轮状态：
| 轮次 | 进入前sum | 当前i | 执行后sum |
|---|---|---|---|
| 第1轮 | 0 | 1 | 1 |
| 第2轮 | 1 | 2 | 2 |
| 第3轮 | 2 | 3 | 3 |
差别看得一清二楚：正确版本每一轮都“接过上一轮传下来的接力棒”，再加上新值；错误版本每一轮都扔掉接力棒，重新从当前i起跑。累加器的本质是“带着历史跑下去”，而sum = i这种写法恰恰丢失了历史。
所以，当有人跟你说“从一行错误代码理解for循环的执行逻辑”，真正要理解的就是这个接力棒机制：for循环的update负责改变循环变量的接棒位置，而循环体负责传递累加器的接棒状态。判断、执行、更新三个动作咬合在一起，才构成我们看到的循环过程。
3. 循环变量、边界固定值、累加器：三个角色的身份辨析
3.1 三个变量的分工与生命周期
混淆的根源，归根结底是角色认知模糊。这里把三个变量放在一起对比：
| 角色 | 典型名字 | 循环中的变化 | 生命周期/作用域 | 典型错误 |
|---|---|---|---|---|
| 循环变量 | i, j, k | 每次迭代后更新，驱动循环走向结束 | 写在for头部声明的，循环外不可见；外部声明则退出循环后值为边界下一值 | 在循环体内误改它，导致死循环 |
| 固定边界值 | n, limit, count | 循环过程中一般不变化 | 外部变量，函数内可见 | 把n当作循环变量更新，边界被改乱 |
| 累加器 | sum, total | 每轮叠加，必须保留上一次计算结果 | 循环外初始化，循环内更新 | 在循环内清零，或直接覆盖 |
这里有个初学者特别容易踩的坑：C99之后，for (int i = 1; ...)里声明的i，作用域仅限于for语句内部，循环结束后i就“消失”了。如果你在printf里直接写i，编译器会报“未声明”的错误。
如果你把i声明在for外面，比如：
int i; for (i = 1; i <= n; i++) { sum += i; } printf("%d\n", i);那么循环结束后i的值是101，不是100。原因是最后的i++先执行，把i变成101，紧接着发现101 <= 100为假，循环退出。很多人想当然认为“循环结束后i就是最后一个项的值”，然后拿这个值去做后续计算，结果差了一个单位。
固定边界值的角色也一样重要。它应该在循环过程中保持稳定，用来和循环变量比较。如果你不小心在循环体里改了它，比如n--，那条件i <= n会随着循环动态变化，循环次数变得不可预测。这类错误往往比sum = i更隐蔽，因为程序不会立刻崩，而是输出一个看起来“好像就差一点”的奇怪结果。
3.2 命名习惯与“=”号的数学思维陷阱
我知道很多初学者喜欢用i和n，因为课本例子就这么写，短、快、省事。但这两个字母太像了，在快速阅读代码时，大脑很容易把“循环变量”和“边界固定值”混为一谈。
我后来把变量名改成语义化的名字，错误率直线下降：
int limit = 100; int sum = 0; for (int i = 1; i <= limit; i++) { sum += i; }limit一眼就知道是“上限”，sum一眼就知道是“累加结果”，i是“当前轮次”。名字本身就是注释，这句话在调试时是真的能救命。
第二个心理陷阱来自数学课。“=”在数学里表示相等，但在C语言里表示“赋值，把右边的结果写进左边”。这个差异导致很多新手看到sum = sum + i时心里发毛：“sum怎么可以等于sum加i？”你需要把这句话念出来：“用sum现在的值，加上i，得到一个新的sum。”当你这样理解时，sum = i`为什么错就很清晰了——它没有把sum现在的值纳入运算。
+=、-=、++这类复合赋值的本质，都是“读旧值 → 计算 → 写回”。如果你对“读旧值”这一步没把握，就把它展开写完整，先保证逻辑正确，再考虑写法简洁。
3.3 一个把所有角色搞混的极端案例
我再展示一个“全家桶”级别的错误代码，它把循环变量、固定边界值、累加器三个角色全部错位：
#include <stdio.h> int main(void) { int n = 5; int sum = 0; for (int i = 1; i <= n; n++) { sum = n; } printf("sum = %d\n", sum); return 0; }这里for循环的更新部分是n++，而不是i++。后果是：
i永远停在1，从不变化；n从5开始一路增大，i <= n永远为真；- 循环变成死循环；
sum每一轮都被覆盖成当前n的值。
这个代码一跑起来就卡死，或者只能靠强制结束。如果你在调试器里查看变量，会看到i纹丝不动，而n在飞快变大。这就是更新动作作用在了错误的变量上。
还有一种常见的“初始化位置错误”：
int n = 5; int sum; for (int i = 1; i <= n; i++) { sum = 0; // 每轮都把sum清零 sum += i; } printf("%d\n", sum); // 输出5，而不是15sum = 0放进了循环体，导致每轮进入时累加器被重置。输出结果是5，虽然不是死循环，但离正确答案15差了整整三轮累积。初始化位置放错，本质上也是对“谁负责攒，谁负责定”认识不清。
4. 我的调试手记：从一行错误代码到根因定位的完整链路
4.1 第一轮排查：在循环体内打印i与sum
当年我遇到这个错误时，先好好反思了自己是不是哪里看漏了，然后做了一个最简单有效的动作：在循环体里加两行printf。
for (int i = 1; i <= n; i++) { sum = i; printf("i = %d, sum = %d\n", i, sum); }运行结果密密麻麻，但信息量极大：
i = 1, sum = 1 i = 2, sum = 2 i = 3, sum = 3 ... i = 100, sum = 100我盯着输出看了三秒钟：i在正常增长，sum却永远等于当前i。这说明sum没有“攒”任何东西，它只是被一次次刷成i的当前值。问题锁定在循环体里的赋值方式，不需要再猜了。
这种“打印中间变量”的方法，是新手最容易上手的调试手段。注意一个技巧：调试时把n暂时改成5，输出量小，看起来更清楚。否则屏幕上滚过100行，反而分散注意力。
4.2 第二轮排查：画一张手推的变量变化表
打印只能告诉我们“结果如何”，如果想理解“为什么”，还得回到纸笔。我把n = 3时的错误代码推演了一遍，写下这张表：
| 轮到谁执行 | 当前i | sum（进入循环体前） | 执行sum = i后 | 执行i++后 |
|---|---|---|---|---|
| 初始化 | 1 | 0 | — | 1 |
| 第1轮 | 1 | 0 | 1 | 2 |
| 第2轮 | 2 | 1 | 2 | 3 |
| 第3轮 | 3 | 2 | 3 | 4 |
看到问题了吗？从第2轮开始，进入循环体前sum明明还带着上一轮的累计值，但执行完sum = i，这个历史值就被冲掉了。
手推表格的意义在于，它强迫你把for循环的每一步都当作“真实发生的事件”来看待，而不是抽象地认为“循环了3次，所以结果对”。这张表一画出来，sum缺了什么一目了然——它缺的是“把上一次的自己加进来”。
4.3 用调试器单步跨过循环体时的观察
如果你用的是带断点调试功能的IDE，或者命令行下的调试器，还可以做更精细的观察。
把断点设在循环体的第一行。第一次停住时，看“变量监视窗口”里的i和sum；执行完sum = i后，继续步进，再看第二次进入循环体时sum的值。
正确的累加代码，第二次进入循环体时sum应该是1，带着上一轮的结果进来；而sum = i的错误代码，第二次进入时sum还是1（如果上一轮刚好也是1），到第三轮就明显跟不上了，它永远等于上一轮的i。
单步调试最爽的一点，是你能亲眼看着sum“忘记历史”的那个瞬间。这种体验比看100行日志更深刻。你甚至可以把断点打在for循环的第三部分i++上，观察每次更新的是哪个变量——当n++这类错误发生时，你会立刻看到边界值在跳动。
4.4 修复、验证与同类错误排查
把sum = i改成sum += i，运行结果立刻变成5050：
#include <stdio.h> int main(void) { int n = 100; int sum = 0; for (int i = 1; i <= n; i++) { sum += i; } printf("sum = %d\n", sum); return 0; }修复本身很简单，难的是识别出这一类错误。这里给你一套我后来一直在用的排查思路：
- 死循环：检查for的第三部分是不是
n++这类“改错对象”，也检查循环体里有没有误改边界值。 - 输出等于n或最后一个数：检查循环体是覆盖（
sum = i）还是累加（sum += i）。 - 输出比预期大很多或乱序：检查累加器的初始化位置，是不是被挪进了循环体内。
- 编译时提示找不到
sum：检查sum是不是在循环体内声明，作用域只在循环里。 - 循环结束后
printf("%d", i)报错或值不对：检查i是在for头部声明的（循环外不可见），还是在外部声明的（退出后值是边界下一值）。
记住一句话：调试累加问题，盯住“谁在变、谁在攒、谁在限定范围”，十有八九能快速定位。
5. 抛掉侥幸心理：几项让我少走弯路的防错习惯
5.1 给变量起能够“说人话”的名字
第一件事，把n改成limit，把sum改成total或者runningTotal。不要觉得“命名影响速度”，调试时节省的时间远超敲键盘多花的时间。
我现在的习惯是：循环变量用i、j这类约定的计数名；边界固定值一定用limit、max、size这种有含义的词；累加器用total、sum、count这种能体现功能的词。哪怕多敲几个字符，也值得。
5.2 初始化位置与+=的语义化理解
累加器必须在循环开始之前初始化，而且只能初始化一次。位置放在循环外，是“从零开始攒”；位置放进循环内，是“每轮清零重来”。
不确定时，把复合赋值展开：
sum += i;等价于sum = sum + i;- 写全式时，你无法回避“sum自己”出现在右侧，这会倒逼你想清楚累加的本质。
- 想记录“最后一个符合条件的值”时，才考虑
sum = i;，但那种场景下sum就不再是累加器的角色，而是一个“末值快照”变量。
5.3 用“纸上推演+断点观察”建立循环直觉
我现在写for循环相关代码时，有个雷打不动的习惯：遇到不确定，先缩小数据规模，再纸上跑两轮。
- 把
n从100改成3或5。 - 列出每轮执行前的
i、条件判断结果、执行后的sum、更新后的i。 - 跟代码实际运行结果对比。
- 还不放心，就开断点单步看一遍。
这个流程看起来“笨”，但它能快速建立对for循环的肌肉记忆。跑过三五次之后，先判断、再执行、后更新就不再是需要背诵的知识点，而是你眼里自然而然的过程。
我现在写累加代码，写完顺手在心里默念一遍第一轮和第二轮：i从1到2，sum从0到1再到3，连续确认“继承”在发生。这比事后调试省太多时间。
这种错，每个学C语言的人都至少要交一次学费。我今天写这篇文章，不是想说你笨，而是想告诉你：当年我也是被那个孤零零的100整得怀疑人生之后，才真正把for循环的执行顺序刻进脑子的。如果你现在也卡在同样的问题上，别急着怀疑编译器，打开调试器，打印一下i和sum，拿张草稿纸跑两轮循环，答案立刻就会现出原形。祝你少踩几个坑，早日写出那个属于你的5050。
