中午十二点，我第N次打开外卖软件，盯着满屏的“吃什么”陷入贤者时间。桌面上还摊着一份没复习完的LinkedList作业，编辑器里停着一个调了一半的bug。这两个看似毫不相干的事情，其实有一个隐藏的共同点：都在逼我做选择——选菜、选数据结构、选排查方向。如果你也被“吃什么”困扰，并且正在学LinkedList或者正在debug，那这篇东西应该能帮上忙。我不会讲什么大道理，就把我复习LinkedList和实际调试中踩过的坑、用过的工具、总结出的方法论，从头到尾捋一遍。

1. “吃什么”与数据结构本质上是同一个问题

1.1 选择的本质：场景决定数据结构

“吃什么”为什么难？因为需求太模糊。你想吃辣的还是清淡的？赶时间还是可以等？预算多少？一旦需求清楚了，选择就变简单了。数据结构也一样，LinkedList和ArrayList的争执，本质上是“你接下来要干什么”的问题。

如果你要频繁在中间插入、删除，那ArrayList这种连续内存结构就很痛苦，因为每次插入都要移动后面的所有元素。反过来，LinkedList的每个节点都是独立的，插入、删除只需要改前后两个节点的指针。这就像你去串串店，想往签子中间加一块肉，只需要把签子抽出来重新串；而去快餐店，套餐里的配菜是固定的，你想换得重新做一份。

但如果你要快速拿到第N个元素，比如“给我第三道菜”，LinkedList就抓瞎了，它得从头一个个数过去；ArrayList直接按索引定位，像快餐店菜单一样，翻到第三页就行。所以一句话：读多写少用数组，写多读少用链表。这个判断标准，来自我刷题和写业务代码多年的实际体会。

1.2 一张表看懂ArrayList与LinkedList

把两者放到一张表里看，对比会非常直观：

注意表格里的“中间插入O(1)”有个前置条件：你得先通过遍历到那个节点。所以实战中不要只看单个操作的复杂度，要看你整体的操作模式。比如你在循环里先找节点再插入，那复杂度还是O(n)。

1.3 为什么“没有最优解”才是真相

我见过很多同学背结论：“LinkedList插入快，所以用它一定好”。实际一跑性能测试，数据量小的时候ArrayList反而快，因为CPU缓存把连续内存都预加载了，而LinkedList的节点散落在内存各个角落，每次访问都可能要等缓存行刷新。这和“吃什么都行但别把选择留给饿肚子”一样，脱离场景谈最优解，就是伪最优。

所以我复习LinkedList第一件事就是扔掉“谁替代谁”的想法。考试和面试喜欢问对比，但真正写代码的时候，你还要考虑并发（LinkedList不是线程安全的）、内存占用、GC压力。这个认知建立起来，后面复习算法和调bug才不至于跑偏。

2. 复习LinkedList：从手写节点到高频算法题

2.1 复习第一步：把图画出来

复习链表最忌讳一上来就背代码。链表的本质是“地址的串联”：每个节点写着两个信息，一个是你真正存的数据，一个是下一个节点的地址。就这么简单，但很多人栽在指针顺序上。

比如在B节点后面插入一个新节点D，你可能会写成“B.next = D; D.next = C”，结果一跑就发现C丢了。正确顺序是先连后路再改前路：先让D.next = B.next，再让B.next = D。为什么？因为你如果先改了B.next，那原来B后面的C就找不到了。这个错误我在作业里写过不止一次，每次都是靠画图救回来。

所以我建议复习的第一道工序就是拿一张白纸，画一条三个节点的链表，然后手动模拟插入、删除、反转，把每一步的指针变化写清楚。不要觉得画图浪费时间，链表题百分之八十的解法，都是在图上一下就能看出来的。

2.2 核心代码：从节点定义到遍历

以Java为例，单链表节点通常长这样：

public class ListNode { int val; ListNode next; ListNode() {} ListNode(int val) { this.val = val; } ListNode(int val, ListNode next) { this.val = val; this.next = next; } }

遍历的模板就是：

ListNode cur = head; while (cur != null) { // 处理当前节点 cur = cur.next; }

这里有个很容易被忽略的细节：很多人在循环里把cur当成参数到处传，结果改了传进来的head。我用一个虚拟头节点（dummy node）来解决这个问题，比如在需要头节点可能被删除的题目里：

ListNode dummy = new ListNode(0, head); ListNode cur = dummy; // 操作中始终用cur.next去修改链路 return dummy.next;

虚拟头节点不只是省代码，它能让你从“处理头节点特判”里解放出来。实习带新人的时候，我发现他们最容易在删除头节点这种边界条件上崩溃，有了dummy就不会了。

2.3 高频考题与手写建议

我给自己整理了一份链表高频题清单，覆盖了大部分作业和面试需求：

• 反转链表（迭代和递归两种写法）
• 检测链表是否有环（快慢指针）
• 合并两个有序链表
• 删除倒数第K个节点
• 寻找链表中点
• 判断回文链表
• 两两交换节点

其中反转链表是绝对的必考题。迭代版的关键是三个指针：prev、cur、next，每次循环先保存cur.next，再将cur.next指向prev，然后整体后移。代码如下：

public ListNode reverseList(ListNode head) { ListNode prev = null; ListNode cur = head; while (cur != null) { ListNode nextTemp = cur.next; cur.next = prev; prev = cur; cur = nextTemp; } return prev; }

环检测用的快慢指针也特别经典，slow每次走一步，fast每次走两步，如果快指针追上慢指针就是有环：

public boolean hasCycle(ListNode head) { ListNode slow = head, fast = head; while (fast != null && fast.next != null) { slow = slow.next; fast = fast.next.next; if (slow == fast) return true; } return false; }

手写建议：先在白纸上写，不要开IDE自动提示；然后再到IDE里单步执行，观察每一步后自己的指针有没有画错。还要测边界：空链表、只有一个节点、只有两个节点、正常多个节点。很多人写反转链表跑正常用例没问题，一传空链表就空指针，就是因为没养成边界测试的习惯。

3. 链表Bug的调试链路：从空指针到死循环的完整排查

3.1 链表Bug的典型长相

链表代码出问题，来来回回就那几类。我把它们总结成一张表，越看越亲切：

这些Bug共同的特点是：代码编译能过，逻辑看半天也没毛病，但一跑就暴露。为什么？因为链表操作是“状态流”：你每一步改动都在改变全局拓扑，任何一步错了，后面的节点都可能跟着错。这也决定了它特别适合用debug来查，而不是靠肉眼排查。

3.2 工具矩阵：IDE断点、内存视图、Keil和DOSBox

这些年在不同环境下调试，我积累了一套工具选择经验：

• IDE断点（VS、IDEA、VS Code）：最常用的手段。直接看变量面板里的节点引用，比打印日志快得多。VS Code里给Java、Python附加断点都很方便，重点看调用栈和变量状态。
• VS Code内存视图：打开调试面板，在Watch里输入变量名，可以看到节点的具体地址和字段。如果装了Memory Viewer扩展，还能直接看内存区域。我在调C/C++链表时经常用它确认指针有没有指向合法区块。
• Keil的Debug：嵌入式场景下用得多，主要配合硬件仿真器使用。可以看寄存器、内存、单步执行C代码或反汇编。如果你在调单片机上链表相关的代码，这个工具是必须掌握的。
• DOSBox里的Debug命令：这是DOS时代的经典调试工具，用“debug”命令可以加载程序、查看内存、修改寄存器。虽然现在日常开发很少直接用，但它的核心思路——直接在内存层面看数据变化——放到今天依然有效，尤其是当你需要核对指针实际地址的时候。

工具本身不是目的，它们都用来回答同一个问题：这一步执行完，节点的next到底指向谁？

3.3 一次反转链表的完整调试过程

拿反转链表举例。假设我写的代码出现了一个循环：反转后链表head变成了原链表的中间节点，后半段形成了环。屏幕上表现为打印链表时程序卡死。

我的排查流程是这样的：

1. 先给方法头加断点，传入一个3节点的链表，确认输入正确。
2. 单步执行进入循环，在cur.next = prev;这一行打断点，每次停住后查看prev、cur、nextTemp三个变量的值。
3. 第四步开始，我发现cur.next被正确指向了prev，但prev和cur的推进顺序错了：cur先被改为nextTemp之后，prev再变成cur时已经晚了，导致某一步把cur的next指回了自己。
4. 解决办法其实很经典：在循环体里，先把nextTemp保存好，然后改cur.next，再移动prev，最后移动cur。顺序不能乱。

这类问题用日志打印也能排查，但效率太低，因为你得对比每一步的状态。断点的好处是能看到每一步之前的变量快照，配合条件断点（比如当cur.val等于某个值时停住），很多疑难Bug都能瞬间缩小范围。

还有一个调试技巧叫“二分断点”：如果你不确定问题在前半段还是后半段，就在中间位置打断点，看状态是否正常，然后选择向前或向后找。这跟对数组二分查找的思路一模一样，遇到超长链表时特别省时间。

4. “debug下是新代码，断电后是旧代码”：嵌入式调试中的经典陷阱

4.1 先还原一下这个诡异现场

这个场景我当年被坑过不止一次：在Keil里进入Debug模式，单步执行，一切正常的都是新逻辑；退出调试，断电，重新上电，跑起来却是老逻辑。不少人第一反应是“见鬼了”，其实原因基本都是可查的。

4.2 最可能的几个原因

我把自己排查到的原因归纳成几类：

• Flash没有真正写入新程序：Debug模式下烧录器可能把代码加载到了RAM，而不是写入Flash，断电后RAM掉电，恢复的是Flash里的旧代码。
• 烧录地址配置错了：目标芯片的Flash起始地址、程序大小区域设置不对，导致程序被写到了Flash的空余区域，而复位向量还指向旧代码。
• 启动模式不对：有些芯片支持从Flash、RAM或System Memory启动，跳线或配置字被改过，上电后从别的地址取指令。
• Bootloader干扰：板子自带Bootloader，你在Debug时下载的程序被后来的Bootloader跳转逻辑覆盖或绕过了。
• 编译优化和链接问题：编译器认为某些代码没变化，链接时没有把新代段更新到最终镜像里，你烧录的其实是一个“看起来新”的旧文件。

4.3 排查链路（按顺序来）

遇到这个问题，我的操作顺序固定如下，不建议跳步：

1. 确认编译产物是最新的：看编译生成的hex/bin文件时间戳，和修改代码的时间对比。如果产物时间旧，编译器根本没重新生成，后面一切免谈。
2. 看烧录日志：很多IDE会打印下载的地址范围、校验和、目标芯片信息，先看程序是写到了RAM还是Flash。
3. 检查工程配置：在Keil的Options里核对Flash起始地址、烧录算法、编程范围。拿常见的STM32F103为例，Flash通常从0x08000000开始，如果工程配置里把这个地址改错，程序就会写到别处。
4. 断电后用调试器连接，读取Flash内容：把读出来的数据和编译生成的hex做对比，这样可以确认Flash里的程序到底是不是新的。
5. 检查复位向量和启动文件：看启动代码里链接脚本指定的Reset_Handler地址是否和烧录位置一致。

在DOSBox场景下，Debug命令也能派上用场：你可以用d命令查看内存内容，用r命令查看寄存器状态，用t单步执行。虽然和老式的单片机调试不完全一样，但核心思路相同：对比实际加载的二进制和预期二进制。只要两边不一致，问题就出现在烧录或启动这个环节。

4.4 这个坎和普通开发有什么关系

很多人觉得嵌入式的问题离自己很远，其实“debug下是新代码，断电后是旧代码”的底层逻辑，和普通开发里的“热部署没生效”、“浏览器缓存了旧JS”、“CDN缓存了旧静态资源”完全是一回事——你实际运行的东西，和你以为在运行的东西不一致。

我们常说“先怀疑缓存，再怀疑代码”，这个习惯在任何领域都适用。我以前调试一个前端页面，改了接口请求参数但行为没变，折腾了半小时才发现是浏览器缓存了旧脚本。“断电后是旧代码”的本质，就是更底层版本的这个坑。所以看到这个问题，不要慌张，按“先看版本，再看配置，最后改代码”的顺序来，起码能省一半时间。

5. 当调试器失灵时：日志、错误表与结构化排错法

5.1 先学一招：错误表比抓包好用

有一次我在看网络设备排查日志，发现一个有意思的经验：很多人遇到网络不通就立刻去抓包，但抓包信息量大，看起来费劲。反而是设备上的错误表，比如ospf error表，直接列出了各类错误计数，像是“邻居状态跳变次数”、“校验失败次数”，一目了然，问题往往当场就能定位。

这给我一个很大启发：排查问题的第一优先级，永远是看已有的错误记录，而不是从头开始采集数据。对应到代码调试上，就是先看异常堆栈、错误日志、监控指标，而不是一上来就开debug单步跑。debug当然有用，但它是手段，不是目的。很多时候，日志已经告诉你错在哪一行了，你还非要慢慢打断点，纯粹是浪费时间。

5.2 SQL异常排查实例：“sql长度大于复制长度”

这个报错看起来像绕口令，实际场景我遇到过好几次。有一次是复制一段线上SQL到本地测试，本地数据库把SQL识别成了另一个版本，一执行就报错。还有一次是代码里动态拼SQL，由于某个字段太长，SQL文本被截断了。

排查思路分四步：

1. 把最终执行的SQL完整打印出来：别在日志里截断输出。很多框架默认会省略长SQL，你需要显式开启完整SQL日志。
2. 检查字段定义长度：如果某个字符串字段定义是VARCHAR(50)，你拼命往里塞200个字符，数据库报错很正常。
3. 检查拼接逻辑：看看是不是用了substring截断了SQL里的一部分，或者把参数和SQL语句混在了一个字符串里。
4. 用数据库自带的trace/profiler：比如MySQL general_log，可以拿到客户端实际发给服务器的SQL原文，和本地复现时的SQL做对比。

这类问题如果直接debug，也可以定位到拼接那一行，但不如先看SQL日志来得快。我的经验是：凡是和外部系统交互相关的错误（数据库、缓存、下游HTTP），先看对方记录到的东西，再debug自己的代码。

5.3 HTTP 500类问题的debug姿势

热词里还有一条很典型的返回内容：{"code":-1,"msg":"request failed with status code 500","data":null}。这种接口失败，最直接的排查路径是什么？不是抓包，而是去看服务端的日志堆栈。500代表服务端内部错误，多半是抛了异常，异常堆栈会直接告诉你类名、方法名和行号。

如果堆栈不明显，再在本地把服务跑起来，用IDE在对应的Controller方法、Service方法上打断点，看看入参是什么、哪一步返回了错误。很多人会纠结用不用抓包工具，我的结论是：只要你有源码并且能在本地复现，就优先debug；抓包适合排查网络链路、代理、DNS这类“代码之外的网络问题”。热词里说的“或者直接debug，抓包都不用”，就是这个意思——别被工具绑架，选最快能看到内部状态的方案。

5.4 我的通用排错四步法

经历的事情多了，我沉淀了一套排错流程，适用于链表bug、SQL异常、接口500，也适用于嵌入式“断电后旧代码”这类问题：

1. 复现：把问题固定到一个稳定可复现的输入。复现不了的问题都是猜测。
2. 隔离：把可疑模块从链路里拆出来，单独测。比如链表反转出问题，先把输入链表单独构造出来，不经过业务逻辑。
3. 假设：基于日志和错误表提出最可能的假设，比如“是不是环了”“是不是Flash地址错了”。
4. 验证：用一个最小实验验证假设，可以是断点、内存视图、日志对比、单测。验证通过，问题就能定位。

这四步循环起来，几乎没有排查不了的问题。以前我也像无头苍蝇一样乱试，后来发现“先假设再验证”才是效率最高的方式。每次假设没被证实，至少排除了一个方向，范围越来越小。

我现在的习惯是：遇到问题先问自己能不能在本地debug复现，能就上断点；不能就翻日志和错误表。这套思路不管是链表、SQL还是接口500都能用。至于“吃什么”，我最后发现最好的解决办法是固定两家轮换，别把选择留给饿肚子的时候——数据结构选型也一样，别等写了几千行代码再回头改。复习LinkedList和调试debug，说到底都是“先明确场景，再做出选择”的过程，选对了方法，问题就解决了一大半。