13、逻辑错误调试：二分法与断言的艺术

逻辑错误，说白了就是代码能跑，但结果不对。

这种错误最让人头疼。语法错误编译器会告诉你，段错误有core dump可以分析。但逻辑错误？它就像个幽灵，程序正常执行，就是不按你预期来。我在项目中遇到过最离谱的一次，一个排序算法跑了三个月才被发现有问题——数据量小的时候结果全对，数据量一大就偶尔出错。

13.1 为什么逻辑错误最难抓？

逻辑错误的本质，是你的代码和你的想法不一致。你脑子里想的是A，写出来却是B。编译器不会管这个，它只关心语法对不对。

我见过太多新手，遇到逻辑错误就疯狂加printf。打印一堆日志，看得眼花缭乱。最后问题没找到，眼睛先花了。这就像在黑夜里找钥匙，你拿着手电筒乱晃，不如先想想钥匙最可能掉在哪。

13.2 二分法：缩小搜索范围

二分法的思路很简单：把问题范围一分为二，判断错误在哪一半，然后继续分。

你想想看，如果你有1000行代码，逐行排查要多久？但用二分法，最多10次就能定位到问题行。2的10次方是1024，刚好覆盖。

13.2.1 代码层面的二分

具体怎么做？我习惯在代码里插入检查点。比如这样：

// 原始代码
void process_data(int *data, int len) {
    // 假设这里有200行代码
    step1(data, len);      // 第1-50行
    step2(data, len);      // 第51-100行
    step3(data, len);      // 第101-150行
    step4(data, len);      // 第151-200行
}

// 二分调试：先检查中间结果
void process_data(int *data, int len) {
    step1(data, len);
    // 检查点1：step1之后的结果
    print_array(data, len);  // 临时加的
    
    step2(data, len);
    // 检查点2：step2之后的结果
    print_array(data, len);  // 临时加的
    
    step3(data, len);
    step4(data, len);
}

如果检查点1的结果是对的，检查点2的结果是错的，那问题就在step2里。然后你再对step2内部的50行代码做同样的操作。

13.2.2 数据层面的二分

有时候问题不在代码逻辑，而在数据。比如一个数组处理函数，处理100个元素时出错。你可以先试50个，再试25个，找到触发bug的最小数据集。

我曾经调试过一个内存泄漏问题。程序跑24小时才崩一次，根本没法调。后来我用二分法，先试12小时，再试6小时，最后发现只要处理超过1000个网络包就会触发。定位到具体函数后，发现是一个计数器溢出了。

13.3 断言：把错误扼杀在摇篮里

断言是什么？简单说，就是你在代码里埋的「地雷」。如果某个条件不满足，程序立刻炸给你看。

很多人不喜欢用断言，觉得麻烦。但我的经验是：断言省下的调试时间，远比你写断言的时间多。

13.3.1 断言的基本用法

#include <assert.h>

int divide(int a, int b) {
    // 除数不能为0，这是前置条件
    assert(b != 0);
    return a / b;
}

void copy_buffer(char *dst, char *src, int size) {
    // 指针不能为空
    assert(dst != NULL);
    assert(src != NULL);
    // 大小必须为正
    assert(size > 0);
    
    memcpy(dst, src, size);
}

你看，assert就像个守门员。条件不满足，它立刻报错，告诉你哪一行、什么条件失败了。这比程序跑到后面莫名其妙崩溃要好得多。

13.3.2 断言的最佳实践

我个人总结了几条断言的使用原则：

• 断言前置条件：函数入口处，检查参数是否合法
• 断言后置条件：函数出口处，检查结果是否符合预期
• 断言不变式：循环或算法过程中，某些条件应该始终成立
• 断言不可能发生的情况：比如switch的default分支

举个例子，写一个二分查找：

int binary_search(int *arr, int len, int target) {
    // 前置条件：数组有序
    assert(arr != NULL);
    assert(len > 0);
    
    int left = 0, right = len - 1;
    while (left <= right) {
        int mid = left + (right - left) / 2;
        
        // 不变式：mid一定在[left, right]范围内
        assert(mid >= left && mid <= right);
        
        if (arr[mid] == target) {
            return mid;
        } else if (arr[mid] < target) {
            left = mid + 1;
        } else {
            right = mid - 1;
        }
    }
    
    // 后置条件：没找到，返回-1
    return -1;
}

这个assert(mid >= left && mid <= right)看起来多余？不，它帮我抓过一次bug。有一次我手滑写成了mid = left + (right - left) * 2，结果mid直接飞出去了。如果没有这个断言，程序会访问越界内存，崩溃在莫名其妙的地方。

13.4 二分法 + 断言 = 黄金组合

二分法帮你定位问题在哪，断言帮你确认问题是什么。两者结合，效率翻倍。

我常用的调试流程是这样的：

1. 先加断言，把明显的前置条件、后置条件都检查一遍
2. 如果断言没触发，说明问题不在边界条件，在逻辑内部
3. 用二分法，在代码中间加检查点，缩小范围
4. 找到可疑区域后，再加更细粒度的断言
5. 重复步骤3-4，直到定位到具体行

13.5 实战案例：一个链表反转的bug

说个真实案例。有一次我写链表反转，代码看起来没问题：

typedef struct node {
    int data;
    struct node *next;
} node_t;

node_t* reverse_list(node_t *head) {
    node_t *prev = NULL;
    node_t *curr = head;
    node_t *next = NULL;
    
    while (curr != NULL) {
        next = curr->next;
        curr->next = prev;
        prev = curr;
        curr = next;
    }
    
    return prev;
}

逻辑上完全正确。但运行结果就是不对。链表反转后，第一个节点丢了。

我加了断言：

while (curr != NULL) {
    assert(curr != NULL);  // 肯定成立，没用
    next = curr->next;
    curr->next = prev;
    prev = curr;
    curr = next;
}

没用。断言没触发，但结果就是不对。

然后用二分法。我在循环中间加了个检查点，打印prev和curr的值。发现第一次循环没问题，第二次循环时，curr指向了一个野指针。

再仔细看代码，发现问题不在反转逻辑，而在调用方——传入的链表最后一个节点的next没有置为NULL。反转后，新链表的头节点指向了野地址。

这就是典型的「调用方错误，被调用方背锅」。如果没有二分法一步步缩小范围，我可能会在反转函数里折腾半天。

13.6 断言的艺术：什么时候用，什么时候不用

断言不是万能的。用错了地方，反而添乱。

场景	用断言	用if-else
检查函数参数合法性	✅ 内部接口	✅ 外部接口（如API）
检查算法不变式	✅ 强烈推荐	❌ 没必要
检查用户输入	❌ 绝对不要	✅ 必须用
检查内存分配	❌ 不要用	✅ 用if判断
检查不可能发生的情况	✅ 非常适合	❌ 冗余

简单来说：断言用于检查「程序内部不应该出现」的情况，if-else用于处理「程序外部可能发生」的情况。

13.7 本章小结

逻辑错误调试，说白了就是两件事：缩小范围，确认假设。

二分法帮你缩小范围。每次砍掉一半代码，最多log2(N)次就能定位问题。

断言帮你确认假设。在关键位置埋下检查点，条件不满足立刻报错。

两者结合，再复杂的逻辑错误也能一步步拆解。嗯，这就是我多年调试经验的精华了。