如果你点进这篇文章大概率也是兜兜转转之后决定拿C#在LeetCode上死磕的那批人。网上关于刷题的经验九成是Python和Java写的C#的优质分享确实少但这门语言在算法题里的实际体验比很多人想象中顺手。我用C#刷题超过一年每天保持至少一道的节奏从最初连Dictionary和HashSet都分不清什么时候用到现在能比较从容地处理图论、动态规划和线段树这类题目这个过程里踩过的坑和沉淀下来的方法我觉得值得写出来。这篇文章不是让你去背题解而是把“每天一道”这件事真正落地从C#在算法题里的语言特性、环境配置到做题节奏怎么安排、常用数据结构怎么写才顺手再到我实际遇到过的诡异问题和排查思路。不管你是刚开始刷题的学生还是工作几年想补算法基础的后端开发者这篇文章都尽量兼顾让你能直接拿去用。1. 为什么用C#刷题语言特性里的优势和暗坑很多人问我刷题不都用Python吗为什么非要用C#我的答案很简单如果你是.NET技术栈的开发者用C#刷题本身就是最好的学习方式。你不需要来回切换思维模式工作里用的语言直接映射到算法题里练过的数据结构、解题套路都能直接沉淀到日常开发中这种迁移效率是Python刷题给不了的。1.1 C#在算法场景下的真实表现C#在LeetCode上的表现被我归类为“全能型选手”。它的执行速度快内存可控又能写得很高层。跑同一道题C#的性能通常比Python好很多比Java也相差不多有些场景因为值类型的优势甚至更快。具体到解题体验有几个特性是你必须知道的var关键字让局部变量声明变得非常自然写var dict new Dictionaryint, int()和写Dictionaryint, int dict new Dictionaryint, int()是完全两种心情。前者的代码看起来清爽得多。值类型和引用类型的区分在算法题里会直接影响内存表现。比如int是值类型存储在线程栈上而object、string、数组都是引用类型。处理大量数据时合理设计成结构体struct可以有效减少堆分配这在做性能敏感的大数据量题目时特别有用。out参数和元组让不少算法的返回值设计变得灵活。比如用TryGetValue配合out去取字典里的值比先ContainsKey再取索引少了一次哈希查找。这些特性单独看不觉得怎样但组合在一起就形成了一套完整的解题表达体系。1.2 容易被忽视的运行时差异这里必须提醒一个很多人踩过的坑LeetCode的C#环境运行版本和你的本地环境可能不同。你现在本机很可能装的是.NET 8甚至.NET 9但LeetCode在线评判的C#环境未必同步更新。一些最新的语言特性在本地编译通过、跑得很欢快一提交到平台上就给你报编译错误非常打击积极性。我的经验是刷题之前先确认平台的C#语言版本支持哪些特性。如果拿不准最稳妥的做法就是尽量少用太花哨的新语法把核心精力放在算法本身。像SpanT、MemoryT这些高性能类型虽然很香在本地控制台应用里也好用但如果平台版本不支持提交上去就是一片红。提示开工之前先在LeetCode随便找一道简单题用你习惯的写法提交一次确认编译通过再开始正式刷题节奏。这是花两分钟省两小时的事情。1.3 语言的规范性对思维的训练用C#刷题还有一个隐藏优势C#的类型系统比Python严格得多这种严格反而逼着你把问题想清楚再动手。Python里你随手res []然后往里塞int又塞stringC#里你必须在定义时就决定列表的类型。这个“决定”的动作其实就是在训练建模能力。我见过不少人用Python刷题写着写着靠动态类型的灵活性把代码写得非常“糊”最后看回放都不知道自己当时写的到底是什么。C#帮你把这种糊弄的空间压缩掉了长期看对你理解数据结构的本质非常有帮助。2. 每日节奏的搭建从定目标到形成肌肉记忆“每日刷题”最大的敌人不是题目太难而是节奏断裂。我自己试过很多种方案最后稳定下来的这套节奏分享给你参考。2.1 目标设置的三个层级不要一上来就喊“每天刷五道”。这种目标连着一周都很难坚持。我给自己的目标分了三个层级用不同的精力投入来对应不同状态基石目标雷打不动每天至少写一道题。哪怕是已经做过的题重新写一遍也算。这一层的核心是维持手感确保“每天都碰代码”这个习惯不断。标准目标正常工作日一道新题加一道旧题重写。新题用来扩展算法视野旧题用来巩固已学套路。冲刺目标周末或假期针对某个专题集中刷比如周末三天只做动态规划或者只做二叉树类题目。这种集中轰炸式刷法对突破某个薄弱专题特别有效。这套目标体系的好处是当你某天特别累你只需要完成基石目标就能心安理得地收工不会有负罪感也不会因为一次没达标就整个放弃。2.2 一天中什么时间刷题效率最高我试过早上起床刷、午休刷、下班回家刷最后发现最适合普通上班族的方案是早上起床后先刷一道简单到中等难度的题不要刷太难。你可以早起20到30分钟用一道题来唤醒大脑这也是一种很好的热身运动。为什么不是晚上因为大多数人的意志力在白天已经被消耗得差不多了。晚上你还要跟“今天太累了明天再说”的念头作斗争消耗的意志力成本比早上高得多。早上刷题大脑清醒、没有杂念注意力集中容易被题目带着思考跑起来。当然如果你确实是个夜猫子型选手也不必强行改成早鸟模式。核心原则只有一条把刷题放在你一天中精力峰值时段不要在疲惫状态下硬刷难题那样只会打击信心。2.3 刷题时间盒管理我在实践里发现如果不给一道题设定时间上限很容易发生“死磕三小时”的惨案。不是说不该想难题而是初学者的时间效率太低了。我的推荐做法是漏斗式时间盒拿到题目后先花5到10分钟阅读理解确认输入输出约束。再花10到15分钟想思路如果完全没有头绪直接看题解思路部分。注意是看思路不是看代码。根据思路自己动手写实现正常花费20到30分钟。如果写不出来再回头研究题解代码逐行理解后合上编辑器凭记忆和思路重新默写一遍。这个流程算下来一道题大约耗时40到60分钟。别小看这个流程它确保你的每一次卡壳都精准地暴露在“思路缺失”或“实现不熟”这两个可改进的维度上而不是模糊地归因于“我不行”。注意看题解并不可耻。可耻的是看完题解关掉页面假装自己会了。真正的学习发生在你合上题解、靠自己的手把代码写出来的那一刻。2.4 如何用周报式回顾保持方向感每天刷完后建议用固定格式记录三个信息题号、核心考点、一句话总结思路。格式越轻越好重了你就坚持不下来。每周抽半小时回顾这周的所有记录把重复出现的考点标红这就是下一步需要重点补强的方向。比如你发现这周遇到三次“双指针”相关问题说明这类题型的出题频率高、你需要熟练掌握。下周就可以专门抽两天集中刷双指针题目。这种数据驱动的复习方式比拍脑袋决定练什么题目要有效得多。3. C#刷题的工程化准备环境、调试与性能观测刷题不只是写算法环境配置同样是体验的一大部分。工具顺手了刷题的幸福指数会高很多。这里把我常用的方案列出来。3.1 本地方案控制台项目还是脚本模式如果你刚起步最简单的方案是在本地建一个控制台应用Console App把每个题目的解法写成独立的类方法然后在Main方法里手动构造测试用例调用。好处是全程可视化调试断点、单步、监视变量该有的都有。做法大致是这样dotnet new console -n LeetCodePractice cd LeetCodePractice然后在项目里按题目分文件组织一个文件一道题public class Solution { public int[] TwoSum(int[] nums, int target) { var map new Dictionaryint, int(); for (int i 0; i nums.Length; i) { int complement target - nums[i]; if (map.TryGetValue(complement, out int index)) { return new[] { index, i }; } map[nums[i]] i; } return Array.Emptyint(); } }这里有一个经验方法签名保持和LeetCode平台一致也就是public方法、同样的参数类型和返回类型。这样你本地调试通过的代码直接贴到LeetCode上就能用不需要反复改接口适配。3.2 调试技巧把复杂用例压缩成断言初学者容易犯一个错测试用例写得过于随意输入一通乱敲输出靠肉眼观察。正确做法是写断言让程序自动帮你验证正确性。比如你写一个排序算法不要光打印排序结果然后用眼睛检查而是Debug.Assert(Enumerable.SequenceEqual(actual, expected));如果断言没抛异常就说明结果是对的。这样一来你可以在本地一次性跑几十个用例快速验证算法在边界条件下是否稳定。配合dotnet test这类测试框架也能用但对于刷题来说断言方案已经足够轻量高效。3.3 性能观测GC压力和耗时统计如果你做到中等偏难的题目开始关注代码性能时有几个工具值得用起来。最简单的做法是直接在代码里用Stopwatch计时var sw System.Diagnostics.Stopwatch.StartNew(); // 调用解法 sw.Stop(); Console.WriteLine(sw.Elapsed.TotalMilliseconds);但光看时间不够我还建议关注内存分配。.NET的GC.GetTotalAllocatedBytes()方法可以直接告诉你当前执行分配了多少字节这比估算更准确long before System.GC.GetTotalAllocatedBytes(); // 调用解法 long after System.GC.GetTotalAllocatedBytes(); Console.WriteLine($Allocated: {after - before} bytes);这个方法对排查“为什么运行时间差不多但内存差出一个量级”这类问题特别有效。尤其是在做矩阵、字符串、大数组相关题目时你会发现用ListT和用原生数组之间的分配差距巨大。3.4 平台提交前的自查清单提交代码到LeetCode之前我养成了一个自查习惯这里公开分享方法签名是否和题目要求完全一致包括大小写、参数类型、返回类型。是否处理了空输入和长度为1的边界情况。是否用了项目里定义的自定义类型而平台没有这个定义。是否有Console.WriteLine之类的输出残留。这个在本地调试方便但提交到平台上会拖慢性能某些极端情况下还会干扰评测。是否有不必要的排序操作。在已经是有序的输入上再次排序时间复杂度会白白高出一截。这套清单帮我把提交出错率降到了很低的水平强烈建议你也保存一份。4. 核心数据结构与算法的C#实现要点刷题过程中你几乎每天都在跟这几个数据结构打交道。C#的标准库实现大部分都很靠谱但有一些使用习惯会对性能和代码可读性产生比较大的影响挑重点拆一拆。4.1 字典与哈希集合选择比写法更重要DictionaryTKey, TValue是你最常用的哈希容器。绝大多数“两数之和”“字母异位词分组”这类题目都靠它。使用时有几个细节优先用TryGetValue而不是ContainsKey加索引取值因为后者把一次查找变成了两次。这个习惯在大型数据量的题目里会有肉眼可见的性能差异。如果可以预知容量务必在构造字典时通过构造函数传入capacity参数。比如你知道要存一万个键值对直接new Dictionaryint, int(10000)可以少很多次扩容的数组拷贝开销。HashSetT用于去重和快速存在性判断非常高效但注意它是无序的如果你需要保持插入顺序不能用它来代替ListT。一个容易被忽略的细节是字典的键类型尽量选择值类型。比如键是元组的情况下用(int, int)值类型元组比用Tupleint, int引用类型元组要好很多因为前者避免了每次查找时创建堆对象。这个优化在二维坐标类题目如岛屿问题里特别明显。4.2 数组与列表容量、扩容与索引C#面试、刷题里大量存在“预先知道答案大小”的场景比如合并区间、收集结果。这时候直接用ListT然后Add其实不是最高效的写法。你可以提前算好最大可能长度一次性分配好容量Listint result new Listint(nums.Length);扩容机制是ListT内部数组翻倍增长频繁触发扩容会带来不必要的拷贝。虽然摊还时间复杂度仍然是O(1)但在性能题里每一点可预测的常数优化都可能让你从超时边缘拉回来。另一个要点是能直接用数组处理就不要转成List再转回数组。我看到很多人习惯把所有东西都装进List最后再ToArray()这在简单场景没问题但在追求极致性能的大数据量场景下增加了无谓开销。4.3 字符串处理不可变性是最核心的认知C#的字符串是不可变对象每次拼接都会创建一个新的字符串对象。在循环里做字符串拼接是性能杀手。如果你需要一个一个字符地构建字符串使用StringBuilder是标准做法。但这里有个更进阶的认知在某些高频修改场景下把字符串转成char[]数组处理最后再new string(chars)往往比逐字符StringBuilder.Append更快。具体场景是你需要多次交换字符位置、做原地翻转这类操作时字符数组更顺手因为数组支持随机访问和直接赋值。StringBuilder虽然也有索引器但它的索引访问走的是内部逻辑不如原生数组直接。还有一个值得留意的点判断两个字符串是否相等时如果你只关心内容而不关心大小写用string.Equals(a, b, StringComparison.OrdinalIgnoreCase)不要用ToLower()后再比较。后者会产生额外字符串对象也白白浪费CPU时间。4.4 自定义比较器别小看排序的灵活性很多题卡在“如何排序”而非“要不要排序”。C#里Array.Sort和ListT.Sort都支持传入自定义比较器但你得知道ComparisonT委托和IComparerT接口的区别。简便方案是直接用Lambda表达式Array.Sort(intervals, (a, b) a.Start.CompareTo(b.Start));这种写法适合快速排序逻辑代码非常紧凑。但如果这个比较器会被多个地方复用或者逻辑很复杂建议定义成实现IComparerT的独立类既避免重复代码又方便单测。需要注意比较器的一致性如果Compare(a, b)在某种输入下返回0那么排序算法会认为a和b相等可能不保证稳定顺序。如果题目要求保持原始相对顺序你需要考虑使用稳定的排序算法或者给每个元素额外带上原始索引作为次关键字。4.5 优先队列的C#正确用法优先队列堆在很多题目里是核心数据结构比如“合并K个有序链表”“数据流中的第K大元素”。C#里对应的是PriorityQueueTElement, TPriority需要确认你使用的平台版本是否支持。用法上有一个很多人会搞错的小细节PriorityQueue的元素和优先级是分开的两个泛型参数。var pq new PriorityQueueint, int(); pq.Enqueue(10, 10); pq.Enqueue(5, 5); int min pq.Dequeue(); // 5默认是最小堆也就是优先弹出优先级最小的元素。如果你需要最大堆最常见的技巧是存入负优先级Enqueue(value, -value)。这个技巧看起来有点歪门邪道但实测是最简单可靠的方案。如果你由于平台版本限制用不了PriorityQueue那就自己用SortedSet或SortedDictionary或者干脆手写一个二叉堆。二叉堆本身也算一种常考的数据结构手动实现一遍对理解堆这个数据结构的底层逻辑很有帮助也练习了代码能力不亏。4.6 递归与栈的互相转换刷树、图相关题目时递归是最自然的思路但递归深度过大会触发栈溢出。C#虽然不像有些语言有严格的递归深度限制但每个递归调用都会有调用栈开销。最典型的例子是二叉树的前序遍历递归版很好写但如果你处理一条超长链状树递归深度可能达到上万层导致程序崩溃。这时候需要掌握用显式栈模拟递归的写法。以中序遍历为例var stack new StackTreeNode(); var result new Listint(); TreeNode current root; while (current ! null || stack.Count 0) { while (current ! null) { stack.Push(current); current current.left; } current stack.Pop(); result.Add(current.val); current current.right; }这种显式栈写法的难点在于把递归调用点转换成循环状态做多了就会发现它们本质上是同一个逻辑只是状态保存的载体不同一个用调用栈一个用显式栈。5. 实测踩坑记录C#刷题常见问题与排查思路这部分是我最想写的。下面这些坑每一个我都真实踩过有些是理解不深造成的有些是语言特性没掌握造成的希望你能绕开。5.1 数组边界与溢出问题刷数组类题目时最容易出错的是边界条件。我自己的血泪教训是写循环前先问自己三个问题——空数组怎么办长度为1的数组怎么办最大值/最小值溢出怎么办以最简单的“最大子数组和”为例用动态规划解法时初始化maxSoFar如果设为0遇到全是负数的数组就会返回0这是错的。正确做法是初始化为int.MinValue或者数组的第一个元素。另一个是整数溢出。C#的int是32位有符号整数最大值是2147483647。当你做加法、乘法后可能超出这个范围比如计算“整数反转”或“字符串转换整数”时反转后很容易溢出。不要图省事直接用int接收要先用long计算并检查范围或者用checked关键字让溢出抛出异常而不是静默回绕。5.2 字典键的哈希冲突陷阱C#的Dictionary底层用哈希表一般情况性能很稳但当键的哈希函数不够好时就会出现大量碰撞导致性能退化到线性。特别是当你用自定义类型作为键时如果没有正确重写GetHashCode默认的引用相等会让两个内容相同的对象被视为不同键直接导致查找失败。这里有一个经典坑用Tupleint, int作为键时虽然Tuple默认实现了值相等比较但它每次创建都会分配堆内存。如果数据量大GC压力就上去了。更好的做法是自定义一个结构体作为键同时重写GetHashCode和Equalspublic readonly struct Point : IEquatablePoint { public readonly int X; public readonly int Y; public Point(int x, int y) { X x; Y y; } public bool Equals(Point other) X other.X Y other.Y; public override int GetHashCode() HashCode.Combine(X, Y); }这个写法在二维动态规划、网格遍历类题目里能实实在在改善性能。5.3 不可变字符串引发的“时间超限”我曾在一道字符串处理的题目里反复遭遇时间超限本地跑小数据量用例完全没问题一到大测试用例就挂。最后用GC.GetTotalAllocatedBytes()观测才发现问题出在循环内的字符串拼接上。循环N次每次都做result result chars[i]字符串又是不可变的实际复杂度是O(N^2)的拷贝量数据一大直接爆炸。修复方式其实很简单把result从string类型改成StringBuilder或者char[]问题瞬间解决。这个坑真正坑人的地方在于小数据量时完全看不出问题让你误以为算法思路没问题直到大数据量才暴露。所以我建议你写字符串相关题目前先明确一次是否要循环拼接是的话直接用StringBuilder或char[]起步别抱有侥幸心理。5.4 LINQ的使用边界方便但不总是免费C#的LINQ写起来确实爽Where、Select、OrderBy组合起来一行搞定的事情用传统循环要写八行。但在算法题里LINQ是隐形的性能陷阱。它的延迟执行机制加上内部的大量委托调用和迭代器状态机分配在高频调用或大数据量时开销相当大。我的准则是算法题的核心路径避免使用LINQ。只有在数据量小、代码确实因为LINQ大幅提升可读性的场景才使用。比如排序用OrderBy(x x)和数组原生的Array.Sort性能差距明显。前者适合小数据量的简单场景后者在LeetCode的大规模测试用例上才是更稳的选择。5.5 递归误区和栈溢出排查树的题目里递归非常自然但递归深度太大时栈溢出不报StackOverflowException而是直接崩溃退出比较难排查。判断是否是栈溢出的一个技巧是本地用小数据量测试跑对换成大数据量用例直接崩溃又没有明显的数组越界问题那十有八九是递归深度问题。改用显式栈或者迭代法解决。如果确实需要递归可以考虑用尾递归优化思路但C#编译器对尾递归的优化不如函数式语言那么彻底所以最稳的解法还是显式栈方案。还有一种排查方法在递归方法入口增加一个深度计数参数超过某个阈值就输出日志快速定位深度的增长路径。这在排查图的深搜类问题时非常好用。6. 从刷题到实战C#算法能力如何反哺日常开发很多人问刷题到底有什么用如果面试用不上是不是就白刷了。我的观点是刷题的价值远不止应付面试它会更深刻地改变你写代码的方式哪怕你日常工作是写业务接口、写数据库访问也一样受益。6.1 复杂度的判断成为本能刷题一年之后我写任何一段逻辑之前会下意识估算它的时间复杂度。比如要在一个列表里查找某个元素我会先想是直接用List.IndexOf还是转成HashSet再查。这种本能不是靠看书得来的是每天面对“为什么这段代码跑不动了”的问题被真实的大数据量测试用例教育出来的。日常开发的很多性能问题本质上都是数据结构选型问题。一个for循环嵌套另一个for循环去查找数据量一涨就卡换成Dictionary查找之后变成O(1)几千行代码的性能问题几行就解决。刷题练出来的敏感度让你在写第一版代码时就避开这些坑。6.2 工具类代码的抽象能力提升刷题时你天天在处理边界条件、异常输入、极端值这种训练让你写的业务代码也更健壮。你会发现那些在生产环境活不过一个月的接口多数不是主流程有问题而是边界没处理输入为空怎么办、并发冲突怎么办、数据量超过预期怎么办。在LeetCode里提交过几十上百次代码之后你会养成一个习惯写任何方法前先假设输入是坏的、是极端的然后反向思考如何保证输出正确。这种防御式编程思维正是生产级代码的核心要求。6.3 建立自己的算法题解库刷题如果没有沉淀那刷过的题会像漏斗一样流走。我的做法是维护一个本地代码仓库按专题分类存放题解。每个文件里包含题目描述、我的解法、以及复杂度分析。更重要的是我会记录每次提交时踩到的坑和改进版本。这个仓库本质上是我自己的算法字典面试前翻一遍比临时抱佛脚刷题效率高得多。而且你写得多了会发现很多题目看似不同核心思路都是同一套你的题解库会自动引导你提炼出“模式”层面的认知。7. 给不同阶段读者的具体建议刷题这件事最大的门槛不是难度而是不知道从哪里开始、按什么顺序刷。这里按读者基础分三类给出建议。7.1 刚入门的新手先别急着上难题如果你是第一次系统刷LeetCode我的建议是不要按题号顺序刷也不要去挑战Hard题。先按专题分类从“数组”和“字符串”这两个最基础的专题入手每天一道简单题保持节奏。大约两周后可以逐步加一道中等题。这个阶段的目标只有一个把手感和语言熟练度练出来。具体路径可以是数组 → 字符串 → 链表 → 栈与队列 → 哈希表 → 二叉树 → 排序与搜索 → 动态规划入门。每一步都等到上一类题目做到“不看题解也能独立完成八成以上”再推进。7.2 有一定基础的进阶者以赛代练、限时模拟如果你已经能比较轻松解决简单题也做过一些中等题建议切换成“模拟面试模式”。每周挑2到3天每次挑一道中等题给自己45分钟的严格时限。到点必须停止不论是否解出。这种训练能有效提升临场压力下的思考能力同时暴露出你在时间分配、思路转向上的短板。进阶阶段的另一个关键是刷“高频面试题”系列这些题覆盖了最常见的考察点出题概率高性价比最优。7.3 资深开发者少即是多专题深挖如果你工作年限较长刷题的目的已经不是算法基础而是弥补特定领域盲区或者保持思维活力。我的建议是做专题深挖连续两周只刷位运算再连续两周只刷线段树。这种沉浸式刷法会在短时间内建立起某种算法模式的直觉效果远好于每天随机刷不同类的题。还有一个小建议资深开发者刷题时多思考“这道题还有没有别的解法和别人的最优解法之间的差距”。这个思考过程其实就是读源码的训练。你会在某个瞬间体会到原来最优解不是灵光一现而是基于对数据结构底层实现深刻理解后的自然产物。8. 坚持不下去怎么办几个真实的动力维持技巧刷题最难的不是某一道题不会做而是连续刷了一个月之后突然某天不想打开编辑器。这里分享几个我自己验证过的技巧。8.1 降低单次启动成本很多时候不想刷题是因为心里觉得“这是一件很重的事情”。早上出门前想到晚上还要花一小时写代码心理负担就直接劝退了。解决办法是把启动动作变得极轻——打开编辑器目录里写好的模板文件只填一个方法体哪怕只写了10行不完整的代码也算今天刷过了。这个策略利用了心理上的“任务完成感”一旦开始就很容易继续做下去。你会发现大多数时候写完10行就顺手把整道题做完了。8.2 别怕重复刷旧题我不止一次遇到有人觉得重复做已经做过的题没有意义。恰恰相反旧题重做是巩固套路的最高效方式。隔一周之后重新写同一道题如果你还能在不看题解的情况下独立写出来说明这个考点才真正属于你了。如果写不出来说明之前看懂只是假象正好暴露弱点及时补救。我每周会固定安排一到两天只刷旧题这个习惯帮我真正掌握了大量“差点就忘了”的算法模板。8.3 用“周赛”制造阶段反馈LeetCode上的周赛是很好的阶段性检验方式。每周花一个半小时参加一次不管成绩好坏你至少能直观看到自己在时间压力下相对于其他人的水平。我在坚持刷题之后明显感觉到前几次周赛连第一题都做不顺几个月后已经能稳定做完前两题这种进步带来的正反馈比任何自我鼓励都管用。周赛成绩不理想也完全不用灰心它暴露的盲区正好可以作为下一周的专题训练方向。把周赛当成免费的诊断工具而不是排名压力来源。8.4 找同伴或开源打卡如果你属于特别容易放弃的类型可以找水平相近的同伴组队打卡。约定每天把提交截图发在群里形成一个无压力的互相监督圈。我个人见过不少因为“大家都在坚持我不能掉队”而最终走了很远的例子。如果找不到合适的同伴也可以在自己的社交账号上打卡把刷题变成一种半公开承诺。公开承诺对有些人来说是动力注意不要让它变成表演就好。最关键的是让刷题保持真实的内在动机你的目标是算法能力的提升不是社交媒体上的打卡仪式感。9. 最后再分享几个小的实用心得刷题这个行为本身很简单但刷得久了你自然会总结出一些书本上没有的实用心得我挑几个最值得说的写在这里。环境配置上我建议在本地IDE里把C#的相关插件装齐尤其是代码分析器和调试器的快捷键要熟练。你越不费力地操作环境精力就越能集中在算法本身。如果编辑器和平台之间切换会打断思考复制粘贴都不顺你会很容易产生烦躁感。做题顺序上如果是第一次接触某个数据结构的题目可以故意先用最暴力的解法跑通然后再想办法优化到更优复杂度。这个“先暴力后优化”的路径不是浪费时间它帮你建立正确的基线认识你至少知道了朴素解法的时间、空间消耗优化时才真正理解优化的意义。测试用例方面不要只依赖平台给的样例。我养成的习惯是提交之前手动构造几个极端用例全相同元素、严格升降序、超长字符串、负数全序列等。这个习惯救了我多次尤其是数组和字符串类的题目很多隐蔽的bug都是在极端用例下才暴露的。最后一点是关于心态。刷题是一个复利积累的过程短期内的收益几乎看不见但坚持数月后你会突然发现自己看很多题的第一眼就知道思路。这个“突然”不是运气是之前无数个平平无奇的日常积累出来的质变。别跟别人比按自己的节奏走保持每天都碰一下代码时间会给你答案。
如果你点进这篇文章大概率也是兜兜转转之后决定拿C#在LeetCode上死磕的那批人。网上关于刷题的经验九成是Python和Java写的C#的优质分享确实少但这门语言在算法题里的实际体验比很多人想象中顺手。我用C#刷题超过一年每天保持至少一道的节奏从最初连Dictionary和HashSet都分不清什么时候用到现在能比较从容地处理图论、动态规划和线段树这类题目这个过程里踩过的坑和沉淀下来的方法我觉得值得写出来。这篇文章不是让你去背题解而是把“每天一道”这件事真正落地从C#在算法题里的语言特性、环境配置到做题节奏怎么安排、常用数据结构怎么写才顺手再到我实际遇到过的诡异问题和排查思路。不管你是刚开始刷题的学生还是工作几年想补算法基础的后端开发者这篇文章都尽量兼顾让你能直接拿去用。1. 为什么用C#刷题语言特性里的优势和暗坑很多人问我刷题不都用Python吗为什么非要用C#我的答案很简单如果你是.NET技术栈的开发者用C#刷题本身就是最好的学习方式。你不需要来回切换思维模式工作里用的语言直接映射到算法题里练过的数据结构、解题套路都能直接沉淀到日常开发中这种迁移效率是Python刷题给不了的。1.1 C#在算法场景下的真实表现C#在LeetCode上的表现被我归类为“全能型选手”。它的执行速度快内存可控又能写得很高层。跑同一道题C#的性能通常比Python好很多比Java也相差不多有些场景因为值类型的优势甚至更快。具体到解题体验有几个特性是你必须知道的var关键字让局部变量声明变得非常自然写var dict new Dictionaryint, int()和写Dictionaryint, int dict new Dictionaryint, int()是完全两种心情。前者的代码看起来清爽得多。值类型和引用类型的区分在算法题里会直接影响内存表现。比如int是值类型存储在线程栈上而object、string、数组都是引用类型。处理大量数据时合理设计成结构体struct可以有效减少堆分配这在做性能敏感的大数据量题目时特别有用。out参数和元组让不少算法的返回值设计变得灵活。比如用TryGetValue配合out去取字典里的值比先ContainsKey再取索引少了一次哈希查找。这些特性单独看不觉得怎样但组合在一起就形成了一套完整的解题表达体系。1.2 容易被忽视的运行时差异这里必须提醒一个很多人踩过的坑LeetCode的C#环境运行版本和你的本地环境可能不同。你现在本机很可能装的是.NET 8甚至.NET 9但LeetCode在线评判的C#环境未必同步更新。一些最新的语言特性在本地编译通过、跑得很欢快一提交到平台上就给你报编译错误非常打击积极性。我的经验是刷题之前先确认平台的C#语言版本支持哪些特性。如果拿不准最稳妥的做法就是尽量少用太花哨的新语法把核心精力放在算法本身。像SpanT、MemoryT这些高性能类型虽然很香在本地控制台应用里也好用但如果平台版本不支持提交上去就是一片红。提示开工之前先在LeetCode随便找一道简单题用你习惯的写法提交一次确认编译通过再开始正式刷题节奏。这是花两分钟省两小时的事情。1.3 语言的规范性对思维的训练用C#刷题还有一个隐藏优势C#的类型系统比Python严格得多这种严格反而逼着你把问题想清楚再动手。Python里你随手res []然后往里塞int又塞stringC#里你必须在定义时就决定列表的类型。这个“决定”的动作其实就是在训练建模能力。我见过不少人用Python刷题写着写着靠动态类型的灵活性把代码写得非常“糊”最后看回放都不知道自己当时写的到底是什么。C#帮你把这种糊弄的空间压缩掉了长期看对你理解数据结构的本质非常有帮助。2. 每日节奏的搭建从定目标到形成肌肉记忆“每日刷题”最大的敌人不是题目太难而是节奏断裂。我自己试过很多种方案最后稳定下来的这套节奏分享给你参考。2.1 目标设置的三个层级不要一上来就喊“每天刷五道”。这种目标连着一周都很难坚持。我给自己的目标分了三个层级用不同的精力投入来对应不同状态基石目标雷打不动每天至少写一道题。哪怕是已经做过的题重新写一遍也算。这一层的核心是维持手感确保“每天都碰代码”这个习惯不断。标准目标正常工作日一道新题加一道旧题重写。新题用来扩展算法视野旧题用来巩固已学套路。冲刺目标周末或假期针对某个专题集中刷比如周末三天只做动态规划或者只做二叉树类题目。这种集中轰炸式刷法对突破某个薄弱专题特别有效。这套目标体系的好处是当你某天特别累你只需要完成基石目标就能心安理得地收工不会有负罪感也不会因为一次没达标就整个放弃。2.2 一天中什么时间刷题效率最高我试过早上起床刷、午休刷、下班回家刷最后发现最适合普通上班族的方案是早上起床后先刷一道简单到中等难度的题不要刷太难。你可以早起20到30分钟用一道题来唤醒大脑这也是一种很好的热身运动。为什么不是晚上因为大多数人的意志力在白天已经被消耗得差不多了。晚上你还要跟“今天太累了明天再说”的念头作斗争消耗的意志力成本比早上高得多。早上刷题大脑清醒、没有杂念注意力集中容易被题目带着思考跑起来。当然如果你确实是个夜猫子型选手也不必强行改成早鸟模式。核心原则只有一条把刷题放在你一天中精力峰值时段不要在疲惫状态下硬刷难题那样只会打击信心。2.3 刷题时间盒管理我在实践里发现如果不给一道题设定时间上限很容易发生“死磕三小时”的惨案。不是说不该想难题而是初学者的时间效率太低了。我的推荐做法是漏斗式时间盒拿到题目后先花5到10分钟阅读理解确认输入输出约束。再花10到15分钟想思路如果完全没有头绪直接看题解思路部分。注意是看思路不是看代码。根据思路自己动手写实现正常花费20到30分钟。如果写不出来再回头研究题解代码逐行理解后合上编辑器凭记忆和思路重新默写一遍。这个流程算下来一道题大约耗时40到60分钟。别小看这个流程它确保你的每一次卡壳都精准地暴露在“思路缺失”或“实现不熟”这两个可改进的维度上而不是模糊地归因于“我不行”。注意看题解并不可耻。可耻的是看完题解关掉页面假装自己会了。真正的学习发生在你合上题解、靠自己的手把代码写出来的那一刻。2.4 如何用周报式回顾保持方向感每天刷完后建议用固定格式记录三个信息题号、核心考点、一句话总结思路。格式越轻越好重了你就坚持不下来。每周抽半小时回顾这周的所有记录把重复出现的考点标红这就是下一步需要重点补强的方向。比如你发现这周遇到三次“双指针”相关问题说明这类题型的出题频率高、你需要熟练掌握。下周就可以专门抽两天集中刷双指针题目。这种数据驱动的复习方式比拍脑袋决定练什么题目要有效得多。3. C#刷题的工程化准备环境、调试与性能观测刷题不只是写算法环境配置同样是体验的一大部分。工具顺手了刷题的幸福指数会高很多。这里把我常用的方案列出来。3.1 本地方案控制台项目还是脚本模式如果你刚起步最简单的方案是在本地建一个控制台应用Console App把每个题目的解法写成独立的类方法然后在Main方法里手动构造测试用例调用。好处是全程可视化调试断点、单步、监视变量该有的都有。做法大致是这样dotnet new console -n LeetCodePractice cd LeetCodePractice然后在项目里按题目分文件组织一个文件一道题public class Solution { public int[] TwoSum(int[] nums, int target) { var map new Dictionaryint, int(); for (int i 0; i nums.Length; i) { int complement target - nums[i]; if (map.TryGetValue(complement, out int index)) { return new[] { index, i }; } map[nums[i]] i; } return Array.Emptyint(); } }这里有一个经验方法签名保持和LeetCode平台一致也就是public方法、同样的参数类型和返回类型。这样你本地调试通过的代码直接贴到LeetCode上就能用不需要反复改接口适配。3.2 调试技巧把复杂用例压缩成断言初学者容易犯一个错测试用例写得过于随意输入一通乱敲输出靠肉眼观察。正确做法是写断言让程序自动帮你验证正确性。比如你写一个排序算法不要光打印排序结果然后用眼睛检查而是Debug.Assert(Enumerable.SequenceEqual(actual, expected));如果断言没抛异常就说明结果是对的。这样一来你可以在本地一次性跑几十个用例快速验证算法在边界条件下是否稳定。配合dotnet test这类测试框架也能用但对于刷题来说断言方案已经足够轻量高效。3.3 性能观测GC压力和耗时统计如果你做到中等偏难的题目开始关注代码性能时有几个工具值得用起来。最简单的做法是直接在代码里用Stopwatch计时var sw System.Diagnostics.Stopwatch.StartNew(); // 调用解法 sw.Stop(); Console.WriteLine(sw.Elapsed.TotalMilliseconds);但光看时间不够我还建议关注内存分配。.NET的GC.GetTotalAllocatedBytes()方法可以直接告诉你当前执行分配了多少字节这比估算更准确long before System.GC.GetTotalAllocatedBytes(); // 调用解法 long after System.GC.GetTotalAllocatedBytes(); Console.WriteLine($Allocated: {after - before} bytes);这个方法对排查“为什么运行时间差不多但内存差出一个量级”这类问题特别有效。尤其是在做矩阵、字符串、大数组相关题目时你会发现用ListT和用原生数组之间的分配差距巨大。3.4 平台提交前的自查清单提交代码到LeetCode之前我养成了一个自查习惯这里公开分享方法签名是否和题目要求完全一致包括大小写、参数类型、返回类型。是否处理了空输入和长度为1的边界情况。是否用了项目里定义的自定义类型而平台没有这个定义。是否有Console.WriteLine之类的输出残留。这个在本地调试方便但提交到平台上会拖慢性能某些极端情况下还会干扰评测。是否有不必要的排序操作。在已经是有序的输入上再次排序时间复杂度会白白高出一截。这套清单帮我把提交出错率降到了很低的水平强烈建议你也保存一份。4. 核心数据结构与算法的C#实现要点刷题过程中你几乎每天都在跟这几个数据结构打交道。C#的标准库实现大部分都很靠谱但有一些使用习惯会对性能和代码可读性产生比较大的影响挑重点拆一拆。4.1 字典与哈希集合选择比写法更重要DictionaryTKey, TValue是你最常用的哈希容器。绝大多数“两数之和”“字母异位词分组”这类题目都靠它。使用时有几个细节优先用TryGetValue而不是ContainsKey加索引取值因为后者把一次查找变成了两次。这个习惯在大型数据量的题目里会有肉眼可见的性能差异。如果可以预知容量务必在构造字典时通过构造函数传入capacity参数。比如你知道要存一万个键值对直接new Dictionaryint, int(10000)可以少很多次扩容的数组拷贝开销。HashSetT用于去重和快速存在性判断非常高效但注意它是无序的如果你需要保持插入顺序不能用它来代替ListT。一个容易被忽略的细节是字典的键类型尽量选择值类型。比如键是元组的情况下用(int, int)值类型元组比用Tupleint, int引用类型元组要好很多因为前者避免了每次查找时创建堆对象。这个优化在二维坐标类题目如岛屿问题里特别明显。4.2 数组与列表容量、扩容与索引C#面试、刷题里大量存在“预先知道答案大小”的场景比如合并区间、收集结果。这时候直接用ListT然后Add其实不是最高效的写法。你可以提前算好最大可能长度一次性分配好容量Listint result new Listint(nums.Length);扩容机制是ListT内部数组翻倍增长频繁触发扩容会带来不必要的拷贝。虽然摊还时间复杂度仍然是O(1)但在性能题里每一点可预测的常数优化都可能让你从超时边缘拉回来。另一个要点是能直接用数组处理就不要转成List再转回数组。我看到很多人习惯把所有东西都装进List最后再ToArray()这在简单场景没问题但在追求极致性能的大数据量场景下增加了无谓开销。4.3 字符串处理不可变性是最核心的认知C#的字符串是不可变对象每次拼接都会创建一个新的字符串对象。在循环里做字符串拼接是性能杀手。如果你需要一个一个字符地构建字符串使用StringBuilder是标准做法。但这里有个更进阶的认知在某些高频修改场景下把字符串转成char[]数组处理最后再new string(chars)往往比逐字符StringBuilder.Append更快。具体场景是你需要多次交换字符位置、做原地翻转这类操作时字符数组更顺手因为数组支持随机访问和直接赋值。StringBuilder虽然也有索引器但它的索引访问走的是内部逻辑不如原生数组直接。还有一个值得留意的点判断两个字符串是否相等时如果你只关心内容而不关心大小写用string.Equals(a, b, StringComparison.OrdinalIgnoreCase)不要用ToLower()后再比较。后者会产生额外字符串对象也白白浪费CPU时间。4.4 自定义比较器别小看排序的灵活性很多题卡在“如何排序”而非“要不要排序”。C#里Array.Sort和ListT.Sort都支持传入自定义比较器但你得知道ComparisonT委托和IComparerT接口的区别。简便方案是直接用Lambda表达式Array.Sort(intervals, (a, b) a.Start.CompareTo(b.Start));这种写法适合快速排序逻辑代码非常紧凑。但如果这个比较器会被多个地方复用或者逻辑很复杂建议定义成实现IComparerT的独立类既避免重复代码又方便单测。需要注意比较器的一致性如果Compare(a, b)在某种输入下返回0那么排序算法会认为a和b相等可能不保证稳定顺序。如果题目要求保持原始相对顺序你需要考虑使用稳定的排序算法或者给每个元素额外带上原始索引作为次关键字。4.5 优先队列的C#正确用法优先队列堆在很多题目里是核心数据结构比如“合并K个有序链表”“数据流中的第K大元素”。C#里对应的是PriorityQueueTElement, TPriority需要确认你使用的平台版本是否支持。用法上有一个很多人会搞错的小细节PriorityQueue的元素和优先级是分开的两个泛型参数。var pq new PriorityQueueint, int(); pq.Enqueue(10, 10); pq.Enqueue(5, 5); int min pq.Dequeue(); // 5默认是最小堆也就是优先弹出优先级最小的元素。如果你需要最大堆最常见的技巧是存入负优先级Enqueue(value, -value)。这个技巧看起来有点歪门邪道但实测是最简单可靠的方案。如果你由于平台版本限制用不了PriorityQueue那就自己用SortedSet或SortedDictionary或者干脆手写一个二叉堆。二叉堆本身也算一种常考的数据结构手动实现一遍对理解堆这个数据结构的底层逻辑很有帮助也练习了代码能力不亏。4.6 递归与栈的互相转换刷树、图相关题目时递归是最自然的思路但递归深度过大会触发栈溢出。C#虽然不像有些语言有严格的递归深度限制但每个递归调用都会有调用栈开销。最典型的例子是二叉树的前序遍历递归版很好写但如果你处理一条超长链状树递归深度可能达到上万层导致程序崩溃。这时候需要掌握用显式栈模拟递归的写法。以中序遍历为例var stack new StackTreeNode(); var result new Listint(); TreeNode current root; while (current ! null || stack.Count 0) { while (current ! null) { stack.Push(current); current current.left; } current stack.Pop(); result.Add(current.val); current current.right; }这种显式栈写法的难点在于把递归调用点转换成循环状态做多了就会发现它们本质上是同一个逻辑只是状态保存的载体不同一个用调用栈一个用显式栈。5. 实测踩坑记录C#刷题常见问题与排查思路这部分是我最想写的。下面这些坑每一个我都真实踩过有些是理解不深造成的有些是语言特性没掌握造成的希望你能绕开。5.1 数组边界与溢出问题刷数组类题目时最容易出错的是边界条件。我自己的血泪教训是写循环前先问自己三个问题——空数组怎么办长度为1的数组怎么办最大值/最小值溢出怎么办以最简单的“最大子数组和”为例用动态规划解法时初始化maxSoFar如果设为0遇到全是负数的数组就会返回0这是错的。正确做法是初始化为int.MinValue或者数组的第一个元素。另一个是整数溢出。C#的int是32位有符号整数最大值是2147483647。当你做加法、乘法后可能超出这个范围比如计算“整数反转”或“字符串转换整数”时反转后很容易溢出。不要图省事直接用int接收要先用long计算并检查范围或者用checked关键字让溢出抛出异常而不是静默回绕。5.2 字典键的哈希冲突陷阱C#的Dictionary底层用哈希表一般情况性能很稳但当键的哈希函数不够好时就会出现大量碰撞导致性能退化到线性。特别是当你用自定义类型作为键时如果没有正确重写GetHashCode默认的引用相等会让两个内容相同的对象被视为不同键直接导致查找失败。这里有一个经典坑用Tupleint, int作为键时虽然Tuple默认实现了值相等比较但它每次创建都会分配堆内存。如果数据量大GC压力就上去了。更好的做法是自定义一个结构体作为键同时重写GetHashCode和Equalspublic readonly struct Point : IEquatablePoint { public readonly int X; public readonly int Y; public Point(int x, int y) { X x; Y y; } public bool Equals(Point other) X other.X Y other.Y; public override int GetHashCode() HashCode.Combine(X, Y); }这个写法在二维动态规划、网格遍历类题目里能实实在在改善性能。5.3 不可变字符串引发的“时间超限”我曾在一道字符串处理的题目里反复遭遇时间超限本地跑小数据量用例完全没问题一到大测试用例就挂。最后用GC.GetTotalAllocatedBytes()观测才发现问题出在循环内的字符串拼接上。循环N次每次都做result result chars[i]字符串又是不可变的实际复杂度是O(N^2)的拷贝量数据一大直接爆炸。修复方式其实很简单把result从string类型改成StringBuilder或者char[]问题瞬间解决。这个坑真正坑人的地方在于小数据量时完全看不出问题让你误以为算法思路没问题直到大数据量才暴露。所以我建议你写字符串相关题目前先明确一次是否要循环拼接是的话直接用StringBuilder或char[]起步别抱有侥幸心理。5.4 LINQ的使用边界方便但不总是免费C#的LINQ写起来确实爽Where、Select、OrderBy组合起来一行搞定的事情用传统循环要写八行。但在算法题里LINQ是隐形的性能陷阱。它的延迟执行机制加上内部的大量委托调用和迭代器状态机分配在高频调用或大数据量时开销相当大。我的准则是算法题的核心路径避免使用LINQ。只有在数据量小、代码确实因为LINQ大幅提升可读性的场景才使用。比如排序用OrderBy(x x)和数组原生的Array.Sort性能差距明显。前者适合小数据量的简单场景后者在LeetCode的大规模测试用例上才是更稳的选择。5.5 递归误区和栈溢出排查树的题目里递归非常自然但递归深度太大时栈溢出不报StackOverflowException而是直接崩溃退出比较难排查。判断是否是栈溢出的一个技巧是本地用小数据量测试跑对换成大数据量用例直接崩溃又没有明显的数组越界问题那十有八九是递归深度问题。改用显式栈或者迭代法解决。如果确实需要递归可以考虑用尾递归优化思路但C#编译器对尾递归的优化不如函数式语言那么彻底所以最稳的解法还是显式栈方案。还有一种排查方法在递归方法入口增加一个深度计数参数超过某个阈值就输出日志快速定位深度的增长路径。这在排查图的深搜类问题时非常好用。6. 从刷题到实战C#算法能力如何反哺日常开发很多人问刷题到底有什么用如果面试用不上是不是就白刷了。我的观点是刷题的价值远不止应付面试它会更深刻地改变你写代码的方式哪怕你日常工作是写业务接口、写数据库访问也一样受益。6.1 复杂度的判断成为本能刷题一年之后我写任何一段逻辑之前会下意识估算它的时间复杂度。比如要在一个列表里查找某个元素我会先想是直接用List.IndexOf还是转成HashSet再查。这种本能不是靠看书得来的是每天面对“为什么这段代码跑不动了”的问题被真实的大数据量测试用例教育出来的。日常开发的很多性能问题本质上都是数据结构选型问题。一个for循环嵌套另一个for循环去查找数据量一涨就卡换成Dictionary查找之后变成O(1)几千行代码的性能问题几行就解决。刷题练出来的敏感度让你在写第一版代码时就避开这些坑。6.2 工具类代码的抽象能力提升刷题时你天天在处理边界条件、异常输入、极端值这种训练让你写的业务代码也更健壮。你会发现那些在生产环境活不过一个月的接口多数不是主流程有问题而是边界没处理输入为空怎么办、并发冲突怎么办、数据量超过预期怎么办。在LeetCode里提交过几十上百次代码之后你会养成一个习惯写任何方法前先假设输入是坏的、是极端的然后反向思考如何保证输出正确。这种防御式编程思维正是生产级代码的核心要求。6.3 建立自己的算法题解库刷题如果没有沉淀那刷过的题会像漏斗一样流走。我的做法是维护一个本地代码仓库按专题分类存放题解。每个文件里包含题目描述、我的解法、以及复杂度分析。更重要的是我会记录每次提交时踩到的坑和改进版本。这个仓库本质上是我自己的算法字典面试前翻一遍比临时抱佛脚刷题效率高得多。而且你写得多了会发现很多题目看似不同核心思路都是同一套你的题解库会自动引导你提炼出“模式”层面的认知。7. 给不同阶段读者的具体建议刷题这件事最大的门槛不是难度而是不知道从哪里开始、按什么顺序刷。这里按读者基础分三类给出建议。7.1 刚入门的新手先别急着上难题如果你是第一次系统刷LeetCode我的建议是不要按题号顺序刷也不要去挑战Hard题。先按专题分类从“数组”和“字符串”这两个最基础的专题入手每天一道简单题保持节奏。大约两周后可以逐步加一道中等题。这个阶段的目标只有一个把手感和语言熟练度练出来。具体路径可以是数组 → 字符串 → 链表 → 栈与队列 → 哈希表 → 二叉树 → 排序与搜索 → 动态规划入门。每一步都等到上一类题目做到“不看题解也能独立完成八成以上”再推进。7.2 有一定基础的进阶者以赛代练、限时模拟如果你已经能比较轻松解决简单题也做过一些中等题建议切换成“模拟面试模式”。每周挑2到3天每次挑一道中等题给自己45分钟的严格时限。到点必须停止不论是否解出。这种训练能有效提升临场压力下的思考能力同时暴露出你在时间分配、思路转向上的短板。进阶阶段的另一个关键是刷“高频面试题”系列这些题覆盖了最常见的考察点出题概率高性价比最优。7.3 资深开发者少即是多专题深挖如果你工作年限较长刷题的目的已经不是算法基础而是弥补特定领域盲区或者保持思维活力。我的建议是做专题深挖连续两周只刷位运算再连续两周只刷线段树。这种沉浸式刷法会在短时间内建立起某种算法模式的直觉效果远好于每天随机刷不同类的题。还有一个小建议资深开发者刷题时多思考“这道题还有没有别的解法和别人的最优解法之间的差距”。这个思考过程其实就是读源码的训练。你会在某个瞬间体会到原来最优解不是灵光一现而是基于对数据结构底层实现深刻理解后的自然产物。8. 坚持不下去怎么办几个真实的动力维持技巧刷题最难的不是某一道题不会做而是连续刷了一个月之后突然某天不想打开编辑器。这里分享几个我自己验证过的技巧。8.1 降低单次启动成本很多时候不想刷题是因为心里觉得“这是一件很重的事情”。早上出门前想到晚上还要花一小时写代码心理负担就直接劝退了。解决办法是把启动动作变得极轻——打开编辑器目录里写好的模板文件只填一个方法体哪怕只写了10行不完整的代码也算今天刷过了。这个策略利用了心理上的“任务完成感”一旦开始就很容易继续做下去。你会发现大多数时候写完10行就顺手把整道题做完了。8.2 别怕重复刷旧题我不止一次遇到有人觉得重复做已经做过的题没有意义。恰恰相反旧题重做是巩固套路的最高效方式。隔一周之后重新写同一道题如果你还能在不看题解的情况下独立写出来说明这个考点才真正属于你了。如果写不出来说明之前看懂只是假象正好暴露弱点及时补救。我每周会固定安排一到两天只刷旧题这个习惯帮我真正掌握了大量“差点就忘了”的算法模板。8.3 用“周赛”制造阶段反馈LeetCode上的周赛是很好的阶段性检验方式。每周花一个半小时参加一次不管成绩好坏你至少能直观看到自己在时间压力下相对于其他人的水平。我在坚持刷题之后明显感觉到前几次周赛连第一题都做不顺几个月后已经能稳定做完前两题这种进步带来的正反馈比任何自我鼓励都管用。周赛成绩不理想也完全不用灰心它暴露的盲区正好可以作为下一周的专题训练方向。把周赛当成免费的诊断工具而不是排名压力来源。8.4 找同伴或开源打卡如果你属于特别容易放弃的类型可以找水平相近的同伴组队打卡。约定每天把提交截图发在群里形成一个无压力的互相监督圈。我个人见过不少因为“大家都在坚持我不能掉队”而最终走了很远的例子。如果找不到合适的同伴也可以在自己的社交账号上打卡把刷题变成一种半公开承诺。公开承诺对有些人来说是动力注意不要让它变成表演就好。最关键的是让刷题保持真实的内在动机你的目标是算法能力的提升不是社交媒体上的打卡仪式感。9. 最后再分享几个小的实用心得刷题这个行为本身很简单但刷得久了你自然会总结出一些书本上没有的实用心得我挑几个最值得说的写在这里。环境配置上我建议在本地IDE里把C#的相关插件装齐尤其是代码分析器和调试器的快捷键要熟练。你越不费力地操作环境精力就越能集中在算法本身。如果编辑器和平台之间切换会打断思考复制粘贴都不顺你会很容易产生烦躁感。做题顺序上如果是第一次接触某个数据结构的题目可以故意先用最暴力的解法跑通然后再想办法优化到更优复杂度。这个“先暴力后优化”的路径不是浪费时间它帮你建立正确的基线认识你至少知道了朴素解法的时间、空间消耗优化时才真正理解优化的意义。测试用例方面不要只依赖平台给的样例。我养成的习惯是提交之前手动构造几个极端用例全相同元素、严格升降序、超长字符串、负数全序列等。这个习惯救了我多次尤其是数组和字符串类的题目很多隐蔽的bug都是在极端用例下才暴露的。最后一点是关于心态。刷题是一个复利积累的过程短期内的收益几乎看不见但坚持数月后你会突然发现自己看很多题的第一眼就知道思路。这个“突然”不是运气是之前无数个平平无奇的日常积累出来的质变。别跟别人比按自己的节奏走保持每天都碰一下代码时间会给你答案。
)
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
