C++老项目重构实战：从裸指针到现代C++的安全迁移路径

接手一个“老项目”最怕什么？不是需求不明确，不是文档缺失，而是你打开代码，发现当年那个写出几万行C++的程序员早已离职，留下的是一堆用裸指针手搓的“多维数组”、能跑但没人敢动的排序逻辑、以及散落在各处的printf调试痕迹。这篇文章我想从一个真实存量项目的重构经历说起，聊一聊C++代码重构中“从哪下手、怎么安全地改、改了之后如何验证”的完整思路，以及这中间踩过的坑。适合准备对老代码动手、或者想提升C++代码质量的读者参考，内容偏向工程实操，不堆砌理论。

我这次重构的代码龄跨度很大，最早的模块可以追溯到C++98时代，工具链换过几轮，期间经历过MSVC和GCC双平台编译。重构目标很明确：不改变外部行为，只改变内部结构与可维护性。经过一个多月的分批改造，最终把模块的代码量压缩了约30%，编译告警数从300多降到个位数，冒烟测试全通过。这篇文章会把整个过程拆开，尽量做到“照着做也能复现”。

1. 先盘清楚：什么样的代码才值得动手重构

很多程序员一看到老代码就手痒，总想着推翻重来。这个冲动可以理解，但必须压住。我见过太多“重构没做完、业务功能也堆不回去”的惨案，究其原因，都是在第一步“识别重构对象”上出了偏差。

1.1 坏味道识别的五个信号

什么样的代码最值得重构？我从实践经验里提炼出五个高频信号：

• 巨型函数反复出现。一个函数动辄两三百行，内部通过注释块“/ section 1 /”划分逻辑，说明函数职责已经严重超出单一范围。
• 重复代码块蔓延。类似的排序逻辑、字符串拼接、数组遍历在多个文件里各写一份，改一处漏三处，这是最典型的重构目标。
• 裸指针满天飞。代码里大量new/delete，内部用指针互传数据，稍不留神就悬垂或者泄漏。顺着重构机会换成智能指针或容器，意义远大于“换个写法”。
• 全局状态隐式耦合。大量全局变量或单例，导致某个函数的行为取决于“之前谁调用过它”。
• 用注释掩盖逻辑混乱。代码里充斥“这里不能删，删了会崩”“这个offset别动”这类注释，往往是真相被掩盖的提示。

1.2 不建议重构的情况

重构不是政治任务，有些代码不建议碰：只运行一次就丢的脚本、马上要整体替换的模块、测试覆盖率几乎为零且无法补齐的“死代码”，以及正在经历业务风暴、需求天天变的地方。在这些场景下重构的投入产出比极低，属于“动了反而错”。

1.3 重构前的估值：先算性价比

我习惯在动手之前先做一次“三分钟估值”：这块代码预计还能活多久？改动成本有多大？重构后收益是否可见？如果代码是核心链路、且未来三年大概率还要维护，那花一周重构完全值得；如果是边缘工具、固定输出结果，那我建议只做局部清理，别大动干戈。这次重构我选中的模块正好是核心数据处理链路，所以我在后面列出了详细的优先级和评估方式，供你参考。

2. 动手之前：先给代码加一张安全网

真实项目里的重构，最怕的不是改不动，而是改错了没人知道。所以在动任何一行代码之前，我做的第一件事不是打开编辑器，而是确认自己手里有没有一张“安全网”。所谓安全网，就是能在你改动后快速告诉你“行为是否发生变化”的机制。

2.1 没有测试的情况下，如何补“支护结构”

我们项目里历史包袱很重，模块几乎没有单元测试。这种情况下，直接要求团队补全测试并不现实。我更推荐的做法是：为重构边界加上“特征测试”。具体来说，为每个核心函数写一个接收样本输入的测试程序，把旧实现的输出结果记录下来，作为基线；重构后的新实现跑同样的输入，一行一行对比输出差异。听起来原始，但极其管用。

我写了一个轻量级的基线测试工具，用C++的std::function封装被测函数，然后统一做输入输出序列化：

cpp复制#include <functional>
#include <iostream>
#include <fstream>
#include <sstream>
#include <string>
#include <vector>

struct TestCase {
    std::string name;
    std::string input;
    std::string expected_output;
};

void runBaselineTest(
    const std::string& caseName,
    const std::string& input,
    const std::string& expectedOutput,
    const std::function<std::string(const std::string&)>& newFunc) {

    std::string actual = newFunc(input);
    if (actual == expectedOutput) {
        std::cout << "[PASS] " << caseName << std::endl;
    } else {
        std::cout << "[FAIL] " << caseName << std::endl;
        std::cout << "  expected: " << expectedOutput << std::endl;
        std::cout << "  actual  : " << actual << std::endl;
    }
}

这里的关键点是输入输出序列化格式必须稳定。我的做法是输出统一用JSON数组格式，这样后续可以做更精细的字段对比，而不是囫囵吞枣地比对整个字串。

2.2 厘清编译器与构建配置的差异

C++代码重构最容易被忽视的风险之一，是不同编译器、不同标准版本下行为并不一致。我们目标代码库在MSVC和GCC下编译，两者对“ unsigned int 溢出回绕”“模板实例化时机”等细节处理有细微差别。为了减少这种平台差异带来的干扰，我给CMake配置补充了严格的编译参数，并统一开启编译告警门禁：

cmake复制set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
add_compile_options(-Wall -Wextra -Wpedantic -Werror)

这套配置的意义在于：让编译器成为你的第一道审查员。很多重构中引入的小问题，比如变量遮蔽、类型转换丢失精度、未使用变量等，如果不开启- Werror，很容易被忽略，等到运行时才暴露。对于MSVC，对应的是/W4 /WX。开了严格告警之后，我改代码的信心至少翻了一倍。

2.3 静态检查与Sanitizer的配合

编译期告警只能发现一小部分问题。我这次重构还启用了两套动态检查：地址消毒器（AddressSanitizer）和未定义行为消毒器（UndefinedBehaviorSanitizer）。它们的区别在于：

• ASan：检查内存泄漏、越界访问、悬垂指针等。
• UBSan：检查整数溢出、非法移位、空指针解引用等。

我建议在重构阶段保持ASan与UBSan同时开启，不要嫌慢。重构中我抓到了一个内存越界写，旧代码在特定数据规模下会越界一个字节，恰好没崩，重构后改成容器才暴露出来。如果没有Sanitizer，这个问题会继续潜伏。

3. 分而治之：从函数级别开始的重构切片

拿到旧代码，最忌讳的是“从第一行开始读到最后一行，然后边读边改”。正确的姿势是按函数切片重构，一次只处理一个最小可验证单元。我这次重构的对象中有一个计算排序和统计排序结果的模块，它正好可以作为切片示例。

3.1 迁移示例：从裸指针多维数组到 std::span 与容器

先说背景。旧代码里有一处数据块被表示成“二维数组指针”，类似这样：

cpp复制void processGrid(int* grid, int rows, int cols) {
    for (int i = 0; i < rows; i++) {
        for (int j = 0; j < cols; j++) {
            int val = grid[i * cols + j];  // 手动计算偏移
            // ... 处理
        }
    }
}

这段代码的问题很典型：行和列信息以参数散装传入，调用方需要保证传入的指针长度足够、维度顺序正确，一旦传错很难排查。

我的第一刀是把接口改成std::span形式。C++20的std::span可以携带长度信息，避免裸指针长度丢失的问题。如果编译环境只支持C++17，可以用gsl::span或一个简单的“连续内存跨度”结构替代。

cpp复制#include <span>

void processGrid(std::span<const int> data, int rows, int cols) {
    for (int i = 0; i < rows; ++i) {
        for (int j = 0; j < cols; ++j) {
            int val = data[i * cols + j];
            // ...
        }
    }
}

改动虽小，但收益是立竿见影的：调用方无法再传入“长度不足”的裸数组，因为std::span在构造时就知道数据的真实大小，后续越界访问在检查模式下一抓一个准。

3.2 顺手处理两个隐藏问题

这个接口改完，我顺着调用链往下看，发现两处隐藏问题。

第一处是数据传入前用了new int[rows * cols]分配内存，但其中一个分支忘了delete[]，属于隐性泄漏。我直接把分配改为std::vector<int>，这样内存管理由容器自动完成，省心不少。

第二处是排序逻辑里顺手复制了两遍相同代码块，分别处理“行优先”和“列优先”的二维数据，但总体逻辑几乎一致。因为数据底层都是连续内存，我抽了一个内部小函数，不再区分行列优先，只是计算索引时多一个步长判断。这一步重构降低了后续修改排序逻辑时的改动面。

3.3 抽出可测试的纯函数

老代码还有个通病：业务逻辑和I/O操作揉在一起，测试很麻烦。我用到的一个技巧是把纯计算抽离出来。比如原本函数里一边读数据、一边排序、一边打印结果，我把它拆成“读数据”“排序”“格式化输出”三个独立层，排序层完全与I/O解耦：

cpp复制std::vector<int> sortAndRank(const std::vector<int>& input, bool ascending);

这样单元测试只需要给一个std::vector<int>输入，校验std::vector<int>输出即可，再也不用为测试构造文件流和缓冲区。这种做法对代码可维护性的提升几乎是质的飞跃。

3.4 用表格对照重构步骤

我把这次函数级重构的步骤汇总成表格，方便对照执行：

4. 从旧式写法到现代C++的逐段迁移：容器、算法库与类型安全

做完整体的函数切分后，接下来要把代码一步步拉入现代C++的语境。这步听起来玄乎，其实可以落在很多具体的写法上。

4.1 用算法库替代手写循环

C++里的<algorithm>头文件提供了大量现成的算法，但老代码普遍只用了std::sort，其余大量循环手写。比如旧代码里有一段“找出最大值并记录位置”的逻辑：

cpp复制int maxVal = arr[0];
int maxIdx = 0;
for (size_t i = 1; i < arr.size(); ++i) {
    if (arr[i] > maxVal) {
        maxVal = arr[i];
        maxIdx = i;
    }
}

其实可以简化为：

cpp复制auto maxIt = std::max_element(arr.begin(), arr.end());
int maxVal = *maxIt;
int maxIdx = std::distance(arr.begin(), maxIt);

如果你觉得后者可读性不如前者清晰，那至少可以加上一句注释说明意图。但长期来看，算法库的语义更准确，也更容易配合并行策略（std::execution::par）进行性能扩展。重构老代码时，我一般从“查找”“统计”“排序”“去重”四类循环入手，收益最明显。

4.2 字符串处理从char*迁移到std::string_view与std::string

老代码中的字符串处理大多基于char*或const char*，配合strlen、strcpy、strcat操作，稍不注意就缓冲区溢出。重构时我做了两类修改：

• 输入参数尽量改成std::string_view，避免不必要的字符串拷贝，且能获得长度信息。
• 字符串内容拼接改成std::string的append或格式化库，例如std::format（C++20）。

这里要注意一个细节：std::string_view并不拥有数据，它只是一个窗口。如果原函数内部必须保存字符串内容，就不能直接存string_view，应存储std::string。很多初学者在这里踩坑，重构时尤其要留意被保留引用或拷贝的语境。

4.3 指针所有权语义重构：从裸指针到unique_ptr与shared_ptr

我在本次重构中见到最多的问题，是函数之间用裸指针传递“由别人创建、由我释放”的对象。比如：

cpp复制SomeObject* createObject();
void useObject(SomeObject* obj); // 谁负责delete？语义不清

重构原则很简单：明确所有权。

• 独占所有权：用std::unique_ptr<T>。
• 共享所有权：用std::shared_ptr<T>。
• 纯借用、不拥有：用T*（或std::span、引用）。

这个改动不只是换个类型名，更重要是让调用链上的人一眼看懂“谁负责释放”。我在重构时把所有裸指针标注为三类，然后逐一迁移。过程中配合ASan检查，彻底清掉了两处长期潜伏的内存泄漏。

4.4 类型安全的枚举和常量

老项目里常出现一组魔法数字：

cpp复制const int STATUS_OK = 0;
const int STATUS_WARN = 1;
const int STATUS_ERROR = 2;

这种做法的隐患在于：整数类型之间可以互相隐式转换，比较时很容易混入其他无意义数字。重构后我改成了enum class：

cpp复制enum class Status : int {
    Ok = 0,
    Warn = 1,
    Error = 2
};

这样调用方必须写Status::Ok，传参和比较都有类型约束，很多“愣头愣脑”的错误在编译期就被拦下了。这类改动虽然小，但对整个项目的健壮性提升非常明显。

4.5 关于constexpr的版本问题

不少读者对C++各版本特性有些混淆，这里顺带讲一个热搜里讨论很高的问题：constexpr是哪个C++版本引入的？答案是C++11。C++14放宽了函数内多个返回语句和局部变量修改的限制，C++17进一步支持了if constexpr和constexpr lambda，C++20则允许constexpr虚函数和constexpr动态内存分配。重构时如果打算用constexpr来定义编译期常量或写编译期计算逻辑，需要先确认编译标准。比如我这次代码库按C++17构建，就大胆使用if constexpr做编译期分支，避免了运行时条件判断的开销。

5. 局部重构实战：化简循环、嵌套与回调

完成大范围迁移后，还有很多代码是在局部细节层面“折磨”人的。对这类代码，不需要大改接口，只需要重塑内部逻辑，收益也很可观。

5.1 深层嵌套与状态标志的重构

老代码里常见的一种“面条逻辑”是多层if嵌套加多个布尔标志位，比如：

cpp复制bool success = false;
if (conditionA) {
    if (conditionB) {
        if (conditionC) {
            success = true;
        } else {
            success = false;
        }
    } else {
        success = false;
    }
}

重构时我喜欢把嵌套改写成“早返回”风格。

cpp复制if (!conditionA) {
    return false;
}
if (!conditionB) {
    return false;
}
if (!conditionC) {
    return false;
}
return true;

这种写法的核心优势是让“主路径”线性展开，读代码的人不必在心里维护一层层括号的上下文。对于更深层次的业务逻辑，我还会把“满足某条件时进入处理分支”抽成独立函数，让调用点变成一句话。

5.2 将重复循环体替换为标准算法

前面提到算法库，这里再举一个我修过的“快速幂”例子。老代码里实现快速幂是用循环加位运算，功能本身没问题，问题在于同一逻辑被复制到三个模块。我用模板函数统一实现：

cpp复制template <typename T>
T quickPow(T base, int exponent) {
    T result = 1;
    while (exponent > 0) {
        if (exponent & 1) {
            result *= base;
        }
        base *= base;
        exponent >>= 1;
    }
    return result;
}

使用模板后，可以对int、long long、double等类型通用。如果项目里还有constexpr需求，也可以在前面加上constexpr声明，让它在编译期就能参与常量表达式计算。重构的同时就把“复制粘贴三份”的问题根掉了。

5.3 回调函数：从C风格函数指针到可组合的现代写法

老代码里有一块事件分发系统是用C风格函数指针做的，调用时传入一个普通函数地址，完全无法捕获上下文。这种设计在早期很常见，但代码里一旦需要携带用户数据，就只能用全局变量或void*参数，类型安全性很差。

我的重构方案是改成std::function加lambda表达式。如果目标是减少依赖、避免std::function虚函数开销，可以先继续用函数指针，但增加一个上下文指针参数；更好的方案是使用模板回调或std::function。考虑到我们项目的性能敏感度不是极致级别，我采用了std::function。举个例子：

cpp复制using Callback = std::function<void(const EventData&)>;

void registerHandler(Callback cb);

registerHandler([](const EventData& e) {
    std::cout << "Event received: " << e.id << std::endl;
});

这样调用方可以捕获局部变量，不必再用全局状态传递用户上下文。对老代码而言，把回调系统从“函数指针+void*”迁移到std::function，是一次收益非常高的局部重构。

5.4 提升循环性能的局部微调

重构过程中，我顺手优化了一些循环的局部性能问题。主要方向是：

• 避免在循环内部重复做动态内存分配，把可复用的容器提到循环外。
• 减少不必要的拷贝，使用const auto&引用遍历。
• 对于计算密集的内层循环，尝试使用-O2或-O3编译选项，并检查是否可以用SIMD。

这里提一个“快读”技巧。有些竞技类或数据采集类代码里，用标准std::cin读数据会较慢。重构老代码时，很多开发者想换成自定义快读：

cpp复制static inline int fastRead() {
    int x = 0;
    bool neg = false;
    char c = getchar();
    while (c < '0' || c > '9') {
        if (c == '-') neg = true;
        c = getchar();
    }
    while ('0' <= c && c <= '9') {
        x = x * 10 + (c - '0');
        c = getchar();
    }
    return neg ? -x : x;
}

我个人的看法是：除非数据规模达到几十万甚至百万级，否则不值得为了这种快读牺牲可读性。重构时优先保证代码语义清晰、可维护，性能优化要在基准数据的驱动下进行，而不是盲目“炫技”。如果确实要优化I/O，优先考虑std::ios::sync_with_stdio(false)或内存映射。

6. 多维数组与指针访问：重构中最容易翻车的细节

前面讲了宏观改造思路，第六章专门说说“多维数组和指针”这个具体的重构重灾区。热搜词里“多维数组 c++ 指针”和“c++字符串数组初始化”频繁出现，说明这个问题确实困扰了很多人。

6.1 一维连续内存映射多维访问：索引计算易错点

老代码里最经典的多维数组写法是“手算偏移”：

cpp复制value[i * cols + j]

如果rows或cols涉及可变量，很容易在循环边界上搞出越界。重构时改用std::mdspan（C++23标准库提案，但部分编译器已支持）是最理想的，不过目前生产环境未必能用。退而求其次，我建议定义一个轻量封装：

cpp复制class Matrix {
public:
    Matrix(int rows, int cols) : rows_(rows), cols_(cols), data_(rows * cols) {}

    int& operator()(int row, int col) {
        return data_[row * cols_ + col];
    }
    const int& operator()(int row, int col) const {
        return data_[row * cols_ + col];
    }

    int rows() const { return rows_; }
    int cols() const { return cols_; }

private:
    int rows_;
    int cols_;
    std::vector<int> data_;
};

这样凡是要访问矩阵元素的地方都写成mat(i, j)，不再手写偏移量，出错概率大幅下降。

6.2 指针数组与“数组指针”的边界

另一个常见问题是int*和int**的混用。老代码里有时候用int**表示二维数组，但内存布局往往是“不连续”的，每一行单独new。这种写法在重构成std::vector<std::vector<int>>时没什么障碍，但如果是性能关键的图像或矩阵计算，我建议统一为连续内存加封装，缓存友好度会好很多。

顺便提醒：int (*ptr)[N]这种数组指针类型，在函数参数传递时常让人困惑。重构时与其让调用者传“指向数组的指针”，不如把数组长度信息一并封装进结构体或容器。

6.3 字符串数组初始化与std::array的选择

老代码里字符串数组通常这样写：

cpp复制const char* names[] = {"Alice", "Bob", "Cindy"};

这种写法本身没问题，但如果需要保证固定容量或进行编译期大小推导，我更推荐：

cpp复制constexpr std::array<std::string_view, 3> names{"Alice", "Bob", "Cindy"};

std::array能提供size()方法和迭代器，避免C风格数组在参数传递时的退化问题。注意std::string_view只适合静态字符串常量，不会修改内容的场景；如果运行时要动态拼接，改用std::string更稳妥。

6.4 ABA问题与并发下的重构

最后提一个相对小众但有意思的词：ABA问题。它经常出现在无锁数据结构中，比如一个指针在重构时如果从std::atomic<T*>改为std::shared_ptr<T>，会面临内存回收时机和ABA问题之间的复杂权衡。老代码项目中，很多并发逻辑并不是高频热点，我建议优先保证正确性，使用细粒度锁或std::shared_mutex做读写分离，而不要在没有强需求的情况下挑战无锁编程。重构并发代码时，务必把所有共享变量的访问都标注出来，并逐一确认线程安全边界。

7. 从一次内存越界到隐藏Bug的完整排查链路

重构过程中不可能一帆风顺。我在这次项目里就遇到过一个隐蔽Bug，排查过程花了两天，很值得复盘。这里给出完整链路，希望能帮你在移动端或服务端遇到类似问题时，有一个可复现的排查思路。

7.1 症状与初步定位

重构后的模块在跑一个2万行输入的压力数据时，偶发崩溃。崩溃点不固定，有时在排序比较器里，有时在字符串格式化处。因为问题出现频率不高，我一度怀疑是并发问题，但排查后排除。最终，我决定用ASan跑同一份压力数据。

ASan给出的报告指向一段“堆缓冲区溢出”，访问位置在某个二维数组的最后一行加一个偏移处。但这个位置在原代码里明明写的是“最后一行最后一列”，为什么还会越界？

7.2 根因：多维矩阵的“行数”和“列数”出现了不一致

我顺着调用链回溯，发现新旧接口混用期间，有一处代码还在用旧的裸指针方式创建矩阵，分配行数和列数来自两个不同的配置源。恰好在改接口时，我把新接口传参顺序从(rows, cols)调整成了(cols, rows)，而旧调用点并没有同步修改。于是矩阵实际分配了rows行、cols列，但访问时却按cols行、rows列来算偏移，最后一列自然越界。

这个问题的根源不在于接口改变本身，而在于“我在重构过程中没有一次性全局替换所有调用点”，留下了一个调用点仍在用旧参数顺序。这给我一个很大的教训：接口签名调整时，不能只改定义和部分调用，要从编译错误清单里逐一确认每一个调用点。

7.3 修复与验证

修复方式简单直接：统一所有调用点，使用封装好的Matrix类，不再用手动二维数组分配。同时加了单元测试，专门用不同的行列数组合覆盖访问边界。

在验证阶段，我重新跑了基线测试、ASan、UBSan，连续压测3轮全过。最后又在不同编译器（GCC 11与MSVC 2022）和不同标准模式（C++17与C++20）下各编译运行一遍，确认无告警、无泄漏。

7.4 预防同类问题：把“接口变更检查”写进流程

这次教训之后，我在团队内定了两条规矩：

• 任何接口签名变更（包括参数顺序、参数类型）必须全仓库搜索调用点，逐一确认。
• 涉及多维索引的计算，优先使用自定义Matrix或容器封装，禁止手写偏移。

这两条建议看似简单，但能挡住绝大多数“重构期间悄悄越界”的问题。

8. 回归测试与性能基准：重构完工前最后的把关

代码改完了，但离“完工”还差最后两步：回归测试和性能基准。很多重构项目就是在这一步草草收尾，结果上线后性能骤降或功能侧漏。

8.1 建立可重复的回归测试集合

我的做法是：把项目里的“黄金样本”整理成一个回归测试集合。所谓黄金样本，是指那些输入、输出都被人工或历史逻辑验证过的数据。每次重构后都跑一遍，输出结果与预期严格比对。

cpp复制// 简单示意：将所有测试文件的路径放入vector，逐个运行并比较结果
for (const auto& file : testFiles) {
    auto output = runProcessor(file);
    auto expected = readExpectedFile(file);
    if (output != expected) {
        std::cerr << "Mismatch in " << file << std::endl;
        return 1;
    }
}
return 0;

如果项目没有现成的黄金样本，你需要主动生成。可以先使用旧版本程序跑一批典型输入，把输出文件保存下来，作为重构后的基准。这是“没有条件创造条件也要测”的办法。

8.2 性能基准：不要只靠感觉

重构的一个常见副作用是性能变化。有些重构因为引入了std::function、智能指针或容器，会增加少量开销；但也有重构因为消除了冗余拷贝和手写循环，性能反而提升。为了搞清楚真实影响，我用std::chrono写了一个简单的基准测试工具，对比重构前后的耗时。

cpp复制#include <chrono>
#include <iostream>

template <typename Func>
double timeIt(Func&& f, int iterations = 100) {
    auto start = std::chrono::steady_clock::now();
    for (int i = 0; i < iterations; ++i) {
        f();
    }
    auto end = std::chrono::steady_clock::now();
    return std::chrono::duration<double, std::milli>(end - start).count();
}

多次运行取中位数，记录编译优化级别。如果性能下降超过5%，需要审视是否在高频路径上引入了不必要的动态分配或虚函数开销。

8.3 编译告警清零与发布前检查清单

在发布重构版本前，我自己的检查清单大致包括：

• 编译告警是否为0（或至少为个位数，且无严重告警）。
• ASan/UBSan跑核心测试是否通过。
• 回归测试是否全部PASS。
• 性能基准是否在预期范围内。
• 所有旧的printf/日志调试代码是否移除。
• 代码格式化是否统一。

9. 重构完成之后，代码评审该盯哪几个地方

代码评审是重构质量守门的重要一环。评审时，我通常重点看这几个地方：

• 接口是否清晰。两个函数之间的边界是否合理，能否独立测试。
• 是否引入了隐含的复制开销。比如用值传递大对象，或者循环内反复构造std::string。
• 是否还有裸指针所有权含糊。出现裸指针，必须能一句话说清“谁释放、何时释放”。
• 是否保持了行为不变。重构的核心是“不动行为”，评审时多问一句“这里和旧逻辑等价吗”。

还有一点：评审判定问题时不追求大而全，而是“可执行的小改进”。一次评审盯三到五个关键问题，比一次提二十条意见有效得多。

10. 重构路上的核心心得与一个实用小技巧

说实话，这轮重构做完，我的最大体会是：C++代码重构，真正难的并不是语法转换，而是“如何在改动过程中始终保持行为不变”。要做到这一点，安全网比技巧更重要。先把测试、编译告警、Sanitizer做起来，再谈各种花式重构，顺序不能反。

最后分享一个非常实用的小技巧：每完成一个函数的重构，先用git diff检查改动，并单独编译一次。不要攒了一百个函数再统一编译，那样一旦出错，定位成本非常高。小步提交、小步验证，看似慢，实际整体节奏反而快。

如果代码库里正好有那些“能跑但没人敢碰”的老模块，不妨试试我上面这套流程：先加安全网，再按函数切片，优先清理裸指针和深层循环，最后用回归测试和性能基准收尾。重构之后你再回去维护那段代码，会明显感觉到心情不一样。毕竟，代码是给人读的，顺便让机器跑一跑罢了。