我跟你讲，线性表删除元素要判空吗？这个问题，你要是敢在面试的时候迟疑一下，那基本上就走远了。
废话，当然要判。
但如果答案就这么简单，这篇文章也就没必要写了。这事儿好玩就好玩在，它像一个洋葱，你每剥开一层，都能呛出新的眼泪，看到不一样的风景。
咱们先聊聊最原始、最赤裸的那种——用C语言手搓一个顺序表，就是数组加一个length变量那种。这时候你来问线性表删除元素要判空吗？我直接反问你：你敢不判吗？
想象一下这个画面：一个空空如也的数组，length是0。你上来二话不说，直接调用delete(0)，想删除第一个元素。你的代码逻辑可能是 length--。好，length变成-1了。下一次你再添加元素，会加到 array[-1] 的位置上。这是什么？这是典型的指针越界，是内存访问违规，程序直接给你一个大大的“惊喜”——段错误（Segmentation Fault）。它不会跟你商量，直接崩溃，干净利落。所以，在这种最底层的实现里，判空根本不是一个“要不要”的问题，而是一个“想不想让程序活下去”的问题。它是一道护栏，没这道护欄，下一步就是万丈深渊。
那换个场景，我们玩链表。链表删除元素，判空的意义又变了。
一个空的链表，head指针就是个NULL。你要删除一个节点，通常的逻辑是先遍历查找。一个while(p != NULL)的循环，在空链表面前，连循环体的大门都进不去，直接就跳过了。从这个角度看，它好像不会像数组那样直接崩溃，似乎不判空也“安全”？
别天真了。
这里的“安全”只是没让程序当场去世。但你的函数逻辑已经碎了一地。一个删除函数，它的契约是什么？它应该告诉调用者：“嘿，我成功删掉了”或者“对不起，没找到/表是空的，我啥也没干”。如果你不判空，对于一个空链表，你的函数默默地执行完毕，然后返回。调用者呢？它可能傻乎乎地以为删除成功了，然后继续执行下面的逻辑，最终导致一个难以追踪的、莫名其妙的业务逻辑错误。
所以，对于链表，判空更多的是为了逻辑的健壮性。它是一种沟通，一种承诺。在函数入口处，一个 if (head == NULL) 的判断，然后直接 return false 或者抛出异常，这才是专业的做法。它清清楚楚地告诉所有人：“此路不通，别往下走了。”
再把视线拉到我们现在常用的高级语言和标准库。比如C++的std::vector，Python的list。你试试对一个空的vector调用pop_back()，或者对一个空的list调用pop()。会发生什么？
它们会直接甩你一脸异常（Exception）。
你看，标准库的设计者们早就把这个问题想透了。他们用“抛出异常”这种更现代、更强制的方式，替你完成了判空。这本质上就是一种判空，只不过把判断和处理的责任，从函数内部转移到了函数外部的try-catch块。你作为使用者，可以不写if (vec.empty())，但你必须（或者说，应该）准备好处理那个可能飞过来的异常。这是一种更高级的防御性编程。它假设调用者可能会犯错，所以内置了“警报系统”。
所以，你看，线性表删除元素要判空吗？
在底层实现里，它是程序的“救命稻草”，防止物理层面的崩溃。
在逻辑实现里，它是函数的“职业道德”，保证了逻辑的完整和清晰。
在高级库里，它化身成了“异常机制”，成了框架设计的一部分，强制你写出更健壮的代码。
说到底，写代码不仅仅是实现功能。很多时候，我们是在和各种“意外”作斗争。空表、无效索引、空指针……这些都是埋伏在代码丛林里的地雷。而判空，就是你手里那个最基础、也最重要的探雷器。
别跟我说什么“我知道我调用这个函数的时候，列表肯定不为空”。这种蜜汁自信，是滋生BUG的温床。也许现在是这样，但谁能保证几个月后，另一个同事在维护你的代码时，不会在某个他没想到的地方，传入一个空列表呢？你的函数，作为一个独立的、可复用的单元，它必须有能力保护自己，不能把身家性命寄托在调用者的“自觉”上。
所以，别再问该不该判了。把它刻进你的肌肉记忆里。这不仅是一个技术问题，更是一种态度，一种对代码质量负责的专业态度。代码世界里的“空”，不是虚无，而是一个随时可能引爆的逻辑炸弹。而你，必须是那个拆弹专家。
发表回复