简介一份针对 LeetCode 热题 100 的 C 题目与答案合集面向正在备战算法笔试和面试的程序员与求职者覆盖数组、链表、字符串等高频考点可作为从零系统刷题或考前快速回顾的参考。资源以 PDF 形式收录全部内容全包仅含 1 个文件大小约 640KB轻量便于保存和检索适合碎片时间在多种设备上学习。题目来自 LeetCode 官方热门精选包含两数之和、两数相加、无重复字符的最长子串、寻找两个有序数组的中位数等经典题每道题附带完整 C 解答并给出时间与空间复杂度分析。对于哈希表优化、链表进位处理、滑动窗口去重等重点思路资料中也进行了相应的归纳总结帮助读者不仅知道怎么写也能理解为什么这样写。目前已有1652人下载学习是刷题族和冲刺面试者的实用资料。1. 先聊聊这份leetcode热题100资源到底解决什么问题国内做C开发的人几乎都绕不过leetcode热题100这道坎。它不是什么高端算法竞赛题库而是面试前必须过一遍的高频题集——大厂笔试、二面手撕代码、甚至有些组的入职测评都从这里出题。我之前在某家公司带过几个实习生他们刷题的方式基本都是今天一道明天一道时间拖了三个月回头一看还是卡在链表翻转和动态规划上。原因很简单没有按题型的难度梯度走也没有一份带答案、带注释、带思路的完整参考。这份leetcode热题100题目加答案资源解决的就是这个痛点把热题按常见考法整理好每道题配了可直接编译的答案代码适合正在准备面试、或者想系统过一遍高频题型的C从业者。它不是用来看的是用来抄完再自己写一遍的。下面我从资源结构、典型题复现、踩坑记录三个角度给你拆开讲章节后面的部分会给出具体操作步骤。2. 先看资源的内部结构题目、答案、注释是怎么编排的2.1 目录组织方式按数据结构分类比按题号排序更有用这份资源没有按LeetCode官方的题号排列而是按数据结构与算法题型归类。常见的分法是数组与哈希、链表、二叉树与递归、回溯与DFS、动态规划、贪心、双指针与滑动窗口、栈与单调栈。每一个大类下面题目的顺序基本遵循由易到难。这个分类方式实际上比按题号刷要合理得多。按题号刷的坏处是昨天还在做数组题今天跳到树思维模型切换成本很高。而按题型刷比如连续一周只碰链表你就能把指针操作、虚拟头节点、快慢指针这几个套路练到形成肌肉记忆。资源里的题目顺序大体也是这么设计的——前面几道往往是这类题型的模板题后面的则开始叠加条件。如果你拿到手发现自己的文件按题号排的我建议你自己按题型重新整理一遍目录。常见做法是在每个子目录里放一个README.md记录这个视频里每道题的编号、题名、难度、核心思路标记比如虚拟头节点单调栈状态压缩这种关键词。这样刷第二遍的时候只看标记就能快速定位薄弱环节。2.2 答案代码的统一格式复杂度分析写在开头核心注释标在关键行这套资源里的大部分答案代码格式都比较统一文件开头有一段注释写明题目编号、题名、时间复杂度、空间复杂度函数体内部在关键逻辑处有中文注释。这个习惯很值得直接抄走因为面试手撕代码时面试官几乎一定会问你这个解法的时间复杂度和空间复杂度分别是多少而不是只看代码能不能跑通。举个例子一道典型的“两数之和”题目资源里的答案大概是这样的结构// 题号: 001 | 两数之和 // 时间复杂度: O(n) | 空间复杂度: O(n) // 核心思路: 用哈希表记录「值 - 下标」的映射遍历一次即可 #include vector #include unordered_map std::vectorint twoSum(std::vectorint nums, int target) { std::unordered_mapint, int value_to_index; for (int i 0; i nums.size(); i) { int complement target - nums[i]; // 重点: 先查表再插入避免同一个元素被使用两次 if (value_to_index.find(complement) ! value_to_index.end()) { return {value_to_index[complement], i}; } value_to_index[nums[i]] i; } return {}; }这里有个细节值得注意先查表、后插入。如果先插入再查表数组里恰好有两个相同值能凑成target时会返回下标相同的两个位置这是标准错误。资源里对这类边界处理基本都有注释你要做的是把这种注释换成自己的话写一遍别直接背。2.3 怎么快速判断这份答案的质量看三点就够不是所有题集的质量都可靠。我拿到一份题集后一般只查三个点第一代码是不是纯C标准库实现有没有依赖自定义头文件或某个IDE的专属配置第二边界条件处理是否完整比如空数组、只含一个元素的数组、全部元素相同的情况有没有覆盖第三注释里有没有把为什么这么写讲清楚而不是只写这一步是循环。这三条都满足这份参考资料就可以放心用。如果是你自己整理也建议用这三条标准来过滤。3. 复现一道典型题把「某数组求和问题」从读题到提交完整过一遍3.1 读题阶段先把边界条件和输入范围抄到注释里很多C开发者刷题最容易犯的毛病是题没读完就开写。尤其是英文题目翻译软件翻完就以为理解了结果漏掉数组是升序排列的或不能使用额外空间这样的关键约束。我通常的做法是拿到一道题先在代码文件头部复制原题描述再用自己的话把三个要点标注出来输入规模、是否有序、是否有空间限制。以一份资源里的典型数组题为例题目要求是给定一个升序排列的整数数组找到两个数使它们的和等于目标值返回这两个数的下标。注意升序排列四个字很关键——如果没看到这个条件你可能会直接上手写哈希表解法虽然也能过但面试官期望的其实是双指针解法因为数组有序时双指针更优。// 输入: nums [2, 7, 11, 15], target 9 // 输出: [0, 1]因为 nums[0] nums[1] 9 // 约束: 数组升序且一定有解读题阶段就把这些写在文件顶部比写代码重要得多。因为写代码的过程会不断消耗你的注意力回头再读题的成本很高。3.2 暴力解先跑通别一上来就追求最优解很多新手看资源里的答案直接是哈希表或双指针版本就以为自己也应该直接写最优解。这个想法容易翻车——最优解往往需要你对手里的数据结构足够熟练新手直接抄最优解只能记住代码形状记不住思路。我给你的建议是第一遍先写暴力解哪怕时间复杂度是O(n^2)。目的有三个确认你读懂了题目、验证输入输出的边界、给自己一个能跑的底稿。std::vectorint twoSumBruteForce(std::vectorint nums, int target) { for (int i 0; i nums.size(); i) { for (int j i 1; j nums.size(); j) { // 注意从 i1 开始避免重复 if (nums[i] nums[j] target) { return {i, j}; } } } return {}; }这段代码不需要任何技巧但它能帮你验证基本逻辑。注意内层循环从i 1开始这是为了防止出现i j的情况。暴力解跑通后你再去对照资源里的最优解这时候你看到的不是一段陌生代码而是一个对这个题目已经有一定理解的人的优化方案吸收效率完全不同。3.3 双指针版本的推导过程为什么有序数组更适合双指针如果数组是有序的哈希表实际是绕了远路。双指针的思路是左指针指向开头右指针指向结尾计算当前和。如果当前和小于target说明需要更大的数左指针右移如果当前和大于target说明需要更小的数右指针左移。这个过程每一步都让候选区间缩小时间复杂度是O(n)。std::vectorint twoSumTwoPointer(std::vectorint nums, int target) { int left 0, right nums.size() - 1; while (left right) { int sum nums[left] nums[right]; if (sum target) { return {left, right}; } else if (sum target) { left; // 当前和太小只能向右移动左指针 } else { right--; // 当前和太大只能向左移动右指针 } } return {}; }这段代码里有三个边界条件需要注意第一while (left right)如果允许left等于right就会把一个元素用两次第二左右指针移动的条件要对称不能两个都往一个方向动第三返回值必须是左指针在前右指针在后保持原数组的下标顺序。这三个细节就是面试官常问的考点。3.4 一份题集值不值得继续刷看三套代码能否举一反三这个判断标准很实在。你拿到一份题集比如这份leetcode热题100不要先看答案先挑5道题尝试自己写暴力解然后对照参考答案。如果答案用到的技巧你能理解但不完全熟悉说明这份题集难度是合适的可以继续。如果答案里有超过一半的代码你完全看不懂——比如动态规划的状态压缩、树形DP的递归回溯那说明这份资源当前不适合你建议先回到基础数据结构章节把底子打牢。这是我做了几年C开发之后比较认可的一个检验方式刷题资源的价值不在于题目多而在于你能不能通过它把某一类解法从见过变成会用。如果一本题集刷完你还是只会照着葫芦画瓢那说明它的答案注释写得不够细换个题目类型就失效了。4. 刷这套题最常见的坑现象、原因、解决4.1 现象答案代码在本地编译器能跑一提交就超时或编译错误这个问题我见过很多人踩。原因是你的本地环境跟在线评测环境不完全一致。最常见的坑有三个一是本地用的是老版本编译器支持某些语法但评测环境的标准是C11或C14特性支持有差异二是依赖了本地特有的头文件路径比如直接include了某个用绝对路径指向的本地头文件三是输入输出格式不一致比如LeetCode要求函数返回值你却在代码里自己写了main函数和打印逻辑。解决方法是提交之前先确认两件事。第一代码里有没有写#include bits/stdc.h这个头文件在部分评测环境不支持建议改成显式include你实际用到的标准库头文件第二检查代码里有没有main函数在线评测题目通常只要提交核心函数实现不需要自己处理输入输出。我一般会在本地建一个专门的测试文件核心函数写完先在里面用几个简单用例跑一遍确认无歧义后再把核心函数单独剪切到网页端提交。4.2 现象照抄答案代码换一道同类型题就写不出来这个现象的根源不是你不努力而是你抄的时候没有编码信息。人脑记忆一段不理解的代码本质上是死记硬背跟记忆一长串没有逻辑的数字差不多几天就忘。解决的办法比较反直觉每抄完一道题不要马上看下一题关掉答案自己从头写一遍写不出来再看一眼但要试图定位是哪里卡住是边界条件忘了还是数据结构用法不熟然后把卡住的那个点单独抄三遍。我建议把抄答案和默写答案作为两个独立环节分开抄答案时可以在注释里记自己的理解默写时完全凭记忆写函数签名和核心逻辑。两道步骤之间至少隔几个小时效果最好。说到底热题100这种资源就像一个代码仓库你从里面取走的东西只有自己能再产出一份才真正属于你。4.3 现象用C刷题时老是卡在指针和引用上代码改来改去还是段错误C刷题和用Java或Python刷题最大的区别就是你需要自己管理内存和指针。链表翻转、删除链表节点这种题是段错误高发区。最常见的错误是操作链表节点时丢了头节点的引用或者修改指针指向后旧的next节点没有保存就继续往下走。解决这个问题的关键是养成改动指针前先备份的习惯。具体来说就是在写一个修改next指针的操作之前先把下一个要访问的节点保存到临时变量里。这看起来多写一行代码但能省掉大量调试时间。另外一个实用的做法是用nullptr而不是NULL并且在函数入口检查传入指针是否为空。这套资源的链表题答案里对这类操作一般都有注释标明你可以留意一下。4.4 现象递归题算不出空间复杂度面试被问倒递归题的空间复杂度和迭代题不一样不能只数变量要数递归调用栈的深度。很多人在刷二叉树相关题目时觉得递归解法很流畅一被问到这个递归的空间复杂度是多少就答不上来。这个问题的关键在于递归的每一层调用都会在内存中占用栈帧直到最深层返回后才会逐层释放。所以空间复杂度至少是O(递归深度)如果每层还创建了额外数组或哈希表就要继续往上加。我在刷题时会用这个习惯来辅助记忆每次写完一个递归函数在注释里写一行递归深度 树的高度或递归深度 数组长度这样每次复盘都能看到空间开销而不是只盯着时间开销。面试官问空间复杂度时直接回答递归深度是h每层用了O(1)额外空间所以整体是O(h)这个答案比含含糊糊说O(n)要专业得多。5. 把一套题集刷成自己的一个值得养成的验证方法这份leetcode热题100资源真正的价值不只是100道题的答案而是你从它身上学到的一套解题流程。我现在每次带人刷题都会让他们做一个练习任选一道题写出三种解法——暴力解、优化解、另一种思路的解然后标注出每种解法的适用条件。比如前面提到的那道数组求和题可以列成这样一张表解法时间复杂度空间复杂度适用条件暴力双循环O(n^2)O(1)适用于一切未排序数组面试时可做铺垫哈希表记录O(n)O(n)适用于未排序数组以空间换时间双指针收敛O(n)O(1)仅在数组有序时可用码量最精简这样列完后你会发现三种解法没有绝对的好坏面试时要选哪种取决于题目有没有给出排序条件。这种比较能力才是热题100真正要训练的东西而不是把某个解法背下来。从那以后我每次刷完一个新题都会强制自己走一遍这个流程先暴力跑通再分析资源里的最优解和暴力解差距在哪最后用自己的话在注释里写一句这题最核心的边界点是什么。这样一轮下来哪怕这道题过了三个月忘了具体实现核心轮廓还在。希望这些拆解对你上手这套资源有帮助。本文还有配套的精品资源点击获取