简介：这是一份《乐学C语言编程汇编》的完整Word整理版，源自北京理工大学程序设计基础教学场景，主要面向正在系统学习C语言的高校学生，以及需要备考计算机等级考试或校内上机测试的读者，旨在通过大量分阶练习提升编程逻辑与实际解题能力。文档汇总了数十道经典编程题，系统覆盖条件判断、循环、数组、字符串、链表、矩阵、递归、排序、日期计算等核心知识点，典型题目包括判断三角形形状、计算时钟夹角、寻找最大素数、身份证校验、回文字符串递归、扑克牌排序、链表移动等；每道题均给出题目要求、输入输出样例和参考代码，方便对照调试和举一反三。资源以单个doc文件封装，大小仅309KB，目录完整、查阅方便。目前已有1709人学习使用，既适合初学者巩固语法基础，也可为备考者提供专项强化训练与阶段自测。
1. 一份C语言编程汇编，到底能帮你解决什么
拿到一份标着“完整word版”的C语言编程汇编时，多数人的第一反应是存进网盘，然后继续躺平。但真正需要它的人，往往正卡在某个具体的坎上：期末上机考试只剩两周，教材例题看得懂、一开IDE就手抖；或者实验课老师丢过来一套题，说“做完就懂C了”，你打开文档发现题号断断续续，前后排版混乱，不知道该从哪下手。这份汇编解决的不是“学会C语言”这么宏大的命题，而是更实在的三件事：把考点变成一张能照着练的地图，把“好像会了”变成“能一次跑对”，以及让你在考前知道自己的薄弱环节到底在哪几类题上。它适合三类人——正在备考C语言上机考试的学生、带实验课需要出题参考的助教、以及想用题目反推语法漏洞的自学者。但前提是：你得知道怎么用它，而不是把它当成答案库来背。
2. 从汇编的编排逻辑看训练价值：题库分类与平台出题特点
2.1 这类汇编的典型章节结构：照着教材顺序排，就是给复习划了路线
我经手过好几份类似的C语言编程题汇编，虽然来源不同，但结构高度一致：基本语法与顺序结构、分支与循环、数组与字符串、函数与递归、指针与动态内存、结构体与文件、基础算法入门。这个顺序不是随便拍的，它基本踩着经典C语言教材的章节推进，也对应着一门C语言课从第1周排到第16周的教学节奏。
对读者来说，这个结构最大的价值在于：它天然是一份“按难度梯度排列的训练路径”。顺序结构题练的是scanf和printf的格式控制，分支题练的是条件表达的边界，循环题练的是嵌套与终止条件，数组题练的是下标越界和字符串结尾符，函数题练的是传值还是传址，指针题练的是间接访问和动态分配。如果你在某一个章节连续做错三道以上，那基本可以断定语法薄弱点就集中在这个区域。
我一般会建议拿到汇编后先做一件事：不看题目，先翻目录。如果文档目录完整，把每一章的题号区间抄下来，估一下每章题量。这能帮你判断两件事——这份汇编的覆盖范围到底有多广，以及你的复习时间该往哪里倾斜。比如一份汇编里循环和数组占了四成题量，那机考的重点大概率也压在这里，而不是在结构体或文件那几章。
2.2 校内训练平台的出题特点：题短、格式严、隐藏测试点多
这类汇编里的题目，多半来自校内训练平台（就是标题里那个“乐学”这类平台）的日常作业和历年机考原题。平台题和你在网上刷的OJ题有一个显著区别：题目普遍短小，一般一个题目只考一到两个语法点，但输入输出格式要求极其严格。比如“输入三个整数，按从大到小输出”，平台可能要求“每个数后跟一个空格，行末无多余空格”，或者要求“输出格式为a>b>c，其中>两侧无空格”。
这种严格格式恰恰是练基本功最好的素材。LeetCode上的题你可以只关注算法逻辑，平台题不行——多打一个空格就是零分。我见过不少同学在本地IDE跑通样例就觉得自己会了，结果交上去0分，就是因为没注意题目里“输出样例”的空格位置。所以在刷汇编时，把每道题的“输入说明”“输出说明”和“样例”读三遍再动手，比急着写代码重要得多。
平台上机批改的另一个特点是隐藏测试点。题面给的样例通常只有一组最简单的数据，真正决定分数的隐藏用例会覆盖边界：比如数组下标的0和N-1、循环的0次和N次、整数的最大值和最小值、字符串的空串和单字符。这意味着刷汇编时不能只满足于跑过样例，要主动给自己造边界数据。
2.3 这份汇编和通用OJ题库的差别：选它而不是选题库的四个理由
很多人会问：网上刷题平台一堆，为什么要拿一份Word版题集来练？差别在四点。第一，这汇编和教材章节同步，每道题对应哪个知识点一目了然，而通用OJ的题目是按难度或题目编号散的，需要自己筛。第二，题目密度高、单题耗时短，适合碎片时间刷，一道题从读题到跑通控制在15到20分钟内，心理负担小。第三，题目的输入输出风格和各校机考一致，练的就是考试时那种“读题→写码→交卷”的临场节奏。第四，它不依赖在线评测环境，离线也能用，在高铁上、图书馆没网的时候都能打开就练。
当然它有短板：没有自动评测。所以你需要自己搭一个“伪评测”环境，这正是下一章要讲的核心——把一份Word题集变成你本地能验证、能计分、能重跑的一套训练闭环。
3. 把Word题集变成可运行代码：从编译器选型到批量验证的完整路径
3.1 先做文档整理：把题号、知识点、难度标进一张索引表
拿到Word版汇编的第一步不是打开编译器，而是先整理文档。我的习惯做法是建一张索引表，按章节把每道题的题号、知识点、难度、状态列出来，这个表就是整份汇编的地图。推荐用Markdown表格或者Excel，列头如下：题号、所属章节、核心知识点、难度（入门/基础/进阶）、是否已AC、首次提交错误原因、备注。
这份索引表的价值在做完30道题之后才显现。当你回头统计时，会发现错误原因高度集中在某几类——比如“数组越界”出现8次、“scanf格式串写错”出现6次。这时候你就有了一个量化的薄弱点清单，而不是笼统的“我觉得指针不太行”。
我一般把整理流程固定成三步。第一步：通读目录，把每个章节的题号区间抄进表里，标记空题号和跳号。第二步：快速浏览每道题的题干，给难度列打初评，别纠结，凭第一感觉即可。第三步：按顺序开始做，每做完一道题，更新状态列，并把提交错误时的报错信息或运行结果简记在备注列。整个整理过程大约占半小时，但能省下后面两周的盲目刷题时间。
3.2 编译器选型与单文件编译命令：本地环境的标准搭法
本地训练环境我推荐最小组合：Windows上用MinGW-w64的gcc，Linux/macOS上直接用系统自带的gcc或clang，编辑器用VS Code或任何你顺手的文本编辑器。不需要装大而全的IDE，因为平台题都是单文件提交，一个gcc命令就够了。
写代码时我建议遵循一个固定模板，每道题都从这里起步：
#include <stdio.h> #include <string.h> int main(void) { int n; while (scanf("%d", &n) != EOF) { // 每道题的核心逻辑写在这里 printf("%d\n", n); } return 0; }这个模板解决了一个高频踩坑点——平台习惯用多组测试数据，即一个输入文件里包含多组用例，直到文件结束才停止。新手最常见的错误是只读一组数据就输出，结果第二组用例直接无输出。while (scanf(...) != EOF)的标准写法能保证程序一直处理到输入结束。需要注意，如果题目明确说“第一行为测试用例组数T”，模板要改成：
int T; scanf("%d", &T); while (T--) { // 每组用例的处理逻辑 }两种输入格式对应两种循环结构，写题之前一定要先看题目声明的是哪种。单文件编译运行命令我固定用这几条：gcc -std=c11 -Wall -Wextra -o main main.c编译，./main < input.txt从文件读输入，./main < input.txt > output.txt把输出重定向到文件，再用diff output.txt expected.txt比对结果。这里-std=c11强制使用C11标准，-Wall -Wextra开所有警告——警告多的代码到平台上大概率也会翻车，不能视而不见。
3.3 造测试数据的标准姿势：样例、边界、随机三种数据怎么配合
本地环境搭起来之后，最难的不是写代码，而是造测试数据。平台题只给样例数据，样例过了不等于能拿分。我给每个题建三个测试文件：样例数据、边界数据、随机数据。
样例数据就是题目自带的输入输出，直接抄进p01_sample.in和p01_sample.out。边界数据需要你根据题目范围自己构造：比如题目说“0 < n < 1000”，那就要造 n=1 和 n=999 的用例，再顺手造一个 n=0 看看程序行为是否符合预期。随机数据用一个小工具生成，我常用Python写个10行脚本生成随机输入，配合一个暴力解法来验证正确性——这个方法在数组和循环题里特别好用。
造好测试数据后，用diff比对输出是最快的验证方式：
gcc -std=c11 -Wall -Wextra -o p01 p01.c ./p01 < p01_sample.in | diff - p01_sample.out && echo "sample pass" ./p01 < p01_edge.in | diff - p01_edge.out && echo "edge pass" ./p01 < p01_rand.in | diff - p01_rand.out && echo "rand pass"命令里diff - p01_sample.out中-表示把stdin作为左边输入，与期望输出文件比对。如果diff无输出且后面执行了echo，说明该组数据通过；如果diff有输出，会直接打印出两边的差异行，定位到具体是格式问题还是逻辑问题。这三行命令分别验证了功能正确性、边界健壮性和数据规模可靠性，全部通过才敢说这道题真的做完了。
3.4 批量验证脚本：一行命令把全章节题目重新跑一遍
做题做到后面，你会面临一个尴尬：前面做过的40道题，你改了某段公共代码或换了编译器，不知道有没有改坏之前的题。这时候一个批量回归脚本就派上用场了。每道题一个目录，目录下放代码和测试文件，脚本遍历所有目录自动编译、运行、比对：
#!/bin/bash # 批量回归测试脚本：遍历当前目录下所有子目录中的 p*.c 文件 for dir in p*/; do cd "$dir" || continue if [ -f p.c ]; then gcc -std=c11 -Wall -Wextra -o p p.c 2>compile.log if [ $? -ne 0 ]; then echo "$dir COMPILE ERROR" cd .. continue fi pass=0 for t in *.in; do base="${t%.in}" if [ -f "$base.out" ]; then ./p < "$t" | diff - "$base.out" >/dev/null if [ $? -eq 0 ]; then pass=$((pass + 1)) else echo "$dir FAIL at $base" fi fi done echo "$dir pass $pass" fi cd .. done脚本逻辑不复杂：遍历每个章节目录，编译目录下的主代码文件，编译失败直接报错跳过；编译通过后，遍历目录下所有.in测试文件，逐个运行并和同名.out文件用diff比对。compile.log用来接住编译警告和错误，方便事后检查。参数方面，文件名约定是代码固定为p.c，测试数据用p01_sample.in / p01_sample.out这种带序号和类型后缀的命名，脚本才能自动配对。这套脚本跑一次全章节所有题目，正常情况下几十秒到几分钟不等，能让你放心重构代码而不用担心改坏旧题。
4. 刷题避坑指南：版本残缺、输入陷阱与本地通过平台报错
4.1 坑一：Word版缺题漏题，题号跳号，题干被截断
现象：你按顺序刷到第17题，下一道直接跳到第19题，中间少了18题；或者某道题只有“题目描述”和“输入格式”，没有“输出格式”和“样例”，代码根本没法验证。
原因：这类Word版文档在传播过程中经过多次复制粘贴、格式转换和低版本Word打开的“另存为”操作，页面被拆散、题号锚点丢失、图片公式损坏是常态。标题里的“完整word版”往往是分享者自己判断的，未必真的完整。
解决：拿到文档后先花10分钟检查题号连续性，用Ctrl+F搜“第X题”或题号编号逐个跳转，凡遇到题号空缺或题干只有一半的，先用3.1的索引表把这个题标记为“待补全”，然后按题目关键词在搜索引擎里搜原题。平台题通常有固定表述，搜到原题后把完整的输入输出说明补进你的索引表，而不是在Word里修改（改完再次传播又会坏）。如果搜不到，就找一起刷的同学对一下题号，确认是缺题还是排版的顺序错乱。
4.2 坑二：gets和scanf混用，字符串读入被换行符顶掉
现象：本地测试第一组数据正常，多组数据时第二组开始的字符串读进来是空的或者少字符，但整型数据又没问题。你花半小时排查逻辑错误，最后发现是输入函数混用的问题。
原因：gets()在C11标准里已经被移除，很多老教材和汇编答案里还在用。更关键的是，scanf("%d")读完后回车换行符还残留在缓冲区，紧接着再用gets()或scanf("%s")时，换行符被当成空串读进去，数据就从第二位开始错位了。
解决：统一用fgets()读字符串，然后用strcspn或手动把末尾的\n去掉；整型和字符串混读时，在切换前加一句清理残留：
#include <stdio.h> #include <string.h> int main(void) { int n; char s[100]; scanf("%d", &n); // 清掉 scanf 留下的换行符，避免影响后面的 fgets while (getchar() != '\n'); fgets(s, sizeof(s), stdin); s[strcspn(s, "\n")] = '\0'; printf("%s\n", s); return 0; }代码里while (getchar() != '\n')这一行的作用是把缓冲区里直到换行符为止的残留字符全部消费掉——这是处理“整型读完读字符串”场景的固定动作。s[strcspn(s, "\n")] = '\0'则把fgets带进来的末尾换行符替换成字符串结束符，确保后续处理不会拿一个含\n的“脏字符串”去比较或输出。这两个动作看似基础，但能消掉平台上这类题的大量隐藏扣分。
4.3 坑三：本地全过平台0分，边界数据没造、数组开太小、没用long long
现象：样例输出完全一致，本地怎么跑都对，提交上去0分或只有部分分。很多人第一反应是平台出错，实际上永远是自己的代码在隐藏测试点上翻车。
原因：典型原因有三个——数组大小按样例数据开的（样例n=3你就开int a[3]，隐藏用例n=500直接越界崩溃）；输入范围达到10^9级别时int溢出，求和结果变成负数或截断值；多组测试数据时全局标记数组没重置，上一组用例的状态污染了下一组结果。
解决：写代码之前，把题面里的“数据范围”用笔抄在代码文件头部注释里，对照着开数组、选类型。整数范围超过2^31-1的求和一律用long long，数组长度按范围上限加10（比如n最大1000就开a[1010]，留出余量防止手滑）。多组数据全局数组重置，最省事的做法是把大数组在while循环内每次用memset清零一次。此外，坚持用3.3节的方法造边界数据——把输入上限、下限、中间值、重复值都跑一遍，能拦下大部分隐藏测试点问题。
4.4 坑四：照抄汇编里的老答案，编译一堆warning还自欺欺人
现象：题目卡住时翻开汇编，后面附带的参考代码用的是void main()、gets()、clrscr()这类老写法。你抄完编译出现几十条warning，甚至直接error，于是开始怀疑是不是自己环境没配好。
原因：汇编的答案多半来自早期教材或老版本编译器时代，当时void main()是“能跑”的，现在C11标准下它是未定义行为；gets()在C11里已移除函数声明，编译不过属于正常现象。把这些代码原样提交到现代评测平台，轻则大量警告，重则直接编译失败。
解决：写代码时遵守现代C标准——main函数一律写成int main(void)，字符串输入用fgets替代gets，清屏函数clrscr()这种平台相关函数直接删掉。同时养成一个习惯：编译命令里的-Wall -Wextra开启后，出现任何warning都不要忽略，警告位置往往就是隐藏bug的提示。记住：汇编是题目集合，不是答案范本，参考代码只能看思路，不能直接复制提交。
4.5 坑五：跳着刷题，从指针和链表开始，一周后劝退
现象：翻开源码发现数组和循环部分题量最大，觉得“这些太简单了”，直接跳到指针、链表章节开刷，结果每道题都卡两小时，信心崩塌，最后连打开的欲望都没了。
原因：汇编的章节顺序是循序渐进的，指针题默认你掌握了数组和函数的基础——数组名作为参数传递的退化为指针、函数调用栈的局部变量生命周期，这些前置知识没练扎实就上指针，等于地基没打就砌墙。
解决：按章节顺序刷，这是汇编这类教材同步题集最大的优势。即使自认为基础好，也把顺序结构和分支循环的题快速过一遍——用很短的时间AC掉，相当于热身，还能顺手检查有没有语法坏习惯。遇到某道题卡超过30分钟，跳过它继续往后做，标记“回看”，过三天再回来做，往往豁然开朗。做题是训练不是闯关，不需要每道题都死磕到底。
5. 把汇编刷成自己的错题本：索引表、回归测试与最小复现用例
这一章是提高转化率的关键手段，也是我认为刷编程题汇编最有价值的一套收尾操作。核心思路是：汇编里的题做完不等于完事，你的错题才是真正属于你的训练资产。
做题到后半程，我会把索引表再扩展两列——“错因标签”和“最小复现用例路径”。错因标签用来归类每次提交失败的原因，比如“数组越界”“scanf格式串错误”“整数溢出”“多组数据未清空”“字符串比较用成了==”。做完50道题后统计这些标签的频次，连续出现3次以上的标签就是你复习的第一优先级。比“我指针不太行”这种模糊认知准确得多。
最小复现用例的思想是：针对每一个错因，写一个10行以内的独立小文件复现这个bug。比如你错过“多组数据未清空全局数组”，就写一个包含全局数组和两轮输入的小程序，故意不memset，观察错误结果，再用memset修好，把修好后的版本保留下来。这个文件不是给你的题解用的，是给你考试前24小时快速过一遍“我当时是怎么错”的实体记忆。
回归测试脚本的用法，是把这些最小复现用例也纳入批量验证。每次你大改代码风格或换编译器版本后，跑一遍3.4节的脚本，之前踩过的坑会被自动重新验证一遍——这就是“后悔药”：你不需要重新做那些题，只要跑完脚本就能确认历史错误没有复发。我自己的习惯是每周日晚上跑一次全量回归，输出的“pass N”数字就是本周学习效果的直接反馈。
做完整套流程后，这份Word版汇编就真正变成了你自己的东西：题目还是那些题，但索引表标注了你的薄弱点，测试数据覆盖了题目没给的边界，回归脚本守住了你不再犯错的下限。我个人的教训是：第一次刷这类汇编时图省事，没建索引表，刷到40题回头发现前面全忘了，只好重刷，反而更费时间。后来每次拿到新题集，都先建表再动手，先把地图画出来再出发。希望这些方法对你有用，帮你把这份汇编刷出比自己预期更高的分数。
本文还有配套的精品资源，点击获取
