C++与Python内存管理深度对比：指针、引用与垃圾回收的底层逻辑

写惯了Python的人第一次正儿八经地碰C++，十有八九会在指针上栽跟头。反过来，C++老手刚上手Python时也容易把“引用”误当成指针，各种花式踩坑。这个现象我见过太多次了，核心原因是——两门语言的内存模型看似相近，底层哲学却完全不同。把这层窗户纸捅破，跨语言开发时的很多困惑会瞬间消失。

这篇文章想做的，就是把C++和Python的内存管理与指针机制放在一起做一个深度的对照拆解。我会从“变量到底是什么”这个最底层的问题讲起，再逐步展开到对象生命周期、传参语义、智能指针、垃圾回收，以及两门语言互相切换时最容易犯的错。不管你是从Python转C++、从C++转Python，还是两支都想掌握的开发者，这篇内容应该都能帮你省下不少排查内存问题的功夫。

先说结论放在前面：Python不是“没有指针”，它处处都是指针，只是换了一副人畜无害的面孔。理解了这一点，你才算真正读懂了Python的赋值、传参、可变对象和垃圾回收。

1. Python的“引用”和C++的“指针”：形似而神不似

“Python到底有没有指针”这个讨论，论坛里吵了十几年也没个定论。答案取决于你问的是语法层面还是实现层面——语法上Python确实没有暴露指针操作符，但语义上，Python的每一个变量本质都是一个指针，只不过这个指针被包了一层叫“引用”的外衣，用户根本碰不到地址本身。

这一章我会把这个问题彻底拆开，讲清楚Python的“引用”和C++的“指针”之间，到底哪些地方像，哪些地方根本是两码事。

1.1 变量是什么：C++里的盒子与Python里的标签

C++里定义一个变量，可以理解成在内存里划出一块区域，这块区域里存数据。int a = 10，就是找一块4字节的内存，把10写进去，以后通过a这个门牌号去访问这块内存。变量是“实实在在的容器”，你往盒子里放东西、换东西，操作的始终是盒子本身。

Python里完全不是这样。a = 10这句话，实际发生的事情是：先在堆上创建一个PyObject对象来表示整数10，然后让名字a“指向”这个对象。变量不是容器，而是一个贴在对象上的标签。标签可以随时撕下来贴到别的对象上，但对象本身才是真正活在内存里的实体。

有一个直观的验证方式。Python里用id()可以拿到对象在内存中的地址，对应C++里取地址操作符&的作用：

python复制a = 10
print(id(a))  # 输出一个很大的整数，比如 140735817752608

b = a
print(id(b))  # 和 id(a) 相同：b是同一个“标签”，没有复制任何东西

a = 20
print(id(a))  # 变了，a被重新绑定到了新的对象上
print(id(b))  # 没变，b仍然指向原来的10

对比C++的等价场景：

cpp复制int a = 10;
int b = a;   // 这里真的复制了一份数据，b和a是两个独立的盒子
a = 20;
std::cout << b << std::endl;  // 输出10，b完全不受影响

这就是最核心的区别：C++的赋值是“复制数据”，Python的赋值是“给对象贴标签”。你看到Python里赋值不拷贝数据，其实是它把所有变量都设计成了“引用”的结果。

用生活化的方式理解：C++的变量是家里的储物柜，你把东西放进去，再复制一份放进另一个柜子，两台柜子互不干涉。Python的变量是便利贴，你在一堆快递盒上贴名字，叫“a”的便利贴贴到哪个盒子，哪个盒子就是“a”；撕下来贴到另一个盒子上也完全没问题。

1.2 为什么Python不让你直接碰指针地址

很多从C++过来的朋友刚接触Python时会有个疑问：既然变量内部都是指针，为什么不提供取地址、解引用的操作符，让大家明明白白地操作？

答案是为了安全，以及为了抽象。C++把内存完全交给程序员，是指针和地址的作者级自由度，也是崩溃和内存泄漏的万恶之源。Python从设计之初就把内存安全放在首位——你碰不到地址，就不会把地址算错；你不知道内存在哪，就不会把它释放错。代价是性能上牺牲了不少，但对于绝大多数业务场景来说，这个交换非常划算。

注意一个容易混淆的地方：Python只是在语法层屏蔽了指针，底层实现完全离不开指针。以CPython为例，每个对象都是一个PyObject结构体，里面有引用计数、类型指针等信息。你调用a.func()的时候，解释器底层干的事情就是通过对象指针找到func这个成员。只是这些操作被解释器封装掉了，开发者在应用层看不到。

同样的道理，C++里需要显式解引用才能操作对象，Python里直接写变量名就行。不是因为Python没有解引用，而是解释器帮你把解引用的步骤做了。省心是真的省心，但也导致很多人学了多年Python，对内存模型的理解始终是模糊的。

1.3 Python的“引用”和C++的“引用”也不是一回事

这里需要比对着讲一下。C++里除了指针，还有一种叫“引用”的语法，看起来和Python的引用有点像，但语义差得远了。

C++的引用有一个铁律：必须在声明时初始化，且一旦绑定到某个变量，终身不能更改。引用本质上就是被绑定变量的别名，你通过引用改值，就是在改原变量。

cpp复制int a = 10;
int& ref = a;   // ref 是 a 的别名，绑定后不可更改
ref = 20;       // a 变成了 20

Python的变量完全没有“绑定后不可更改”这个限制。前面代码里已经看到了，a = 20之后，a就被重新绑定了。在C++的世界里，这相当于让一个引用去绑定另一个变量——这在语言层面根本不允许。

所以你如果非要说Python的变量“类似于指针”，其实比说“类似于引用”更准确——Python的变量是一个可以随时改指目标的指针，只是在语法上不需要写星号解引用而已。很多人讲Python时说“变量即引用”，这话没毛病，但要小心别把它和C++的引用混为一谈，否则后面理解可变对象、理解不可变对象时就会各种别扭。

2. 内存生命周期：谁分配、谁释放、悬垂与泄漏是怎么发生的

聊完“变量是什么”，下一个绕不开的问题就是内存的生命周期。C++和Python在这个层面上的差异，基本上就是手动挡和自动挡的差异——C++把方向盘和离合器都交给你，Python则把换挡逻辑藏进了引擎盖。两种模式各有代价，这一章我逐条拆开讲。

2.1 C++的栈与堆：作用域即生死线

C++里的对象可以生存在两个区域：栈和堆。

栈上对象的生命周期由作用域决定。你在函数里写了一个局部变量int a = 10;，这个变量在函数退出时自动销毁，内存自动回收。栈是编译器帮你管理的，你不必（也不能）手动释放。这种自动机制非常可靠，函数返回后你不可能再访问到它——如果真的尝试访问，恭喜你，你制造了一个悬垂引用。

堆上对象就不同了。你通过new在堆上创建的对象，生命周期只受一条规则约束：直到手动delete为止。它可以跨越函数边界存在，也可以在某个作用域结束后继续存活，但代价是你必须记得在合适的时候把它销毁。忘记delete，就是泄漏；delete两次或使用已delete的对象，就是未定义行为，程序可能当场崩溃，也可能在几天后以最诡异的方式爆炸。

cpp复制void leakExample() {
    int* p = new int(42);
    // 忘记 delete p;
    // p 指向的4字节内存再也无法释放，直到进程结束
}

这里有个常见认知误区：很多人以为new/delete主要看编程习惯。实际上，即使你每次都记得delete，遇上提前return、抛异常等情况，正常的delete路径可能根本走不到，照样泄漏。所以现代C++才大力推行RAII（Resource Acquisition Is Initialization，资源获取即初始化）和智能指针，思路就是——把内存的释放绑定到某个栈上对象的析构函数上，栈上对象生命周期结束时自动执行析构，内存就顺理成章地释放了。这个思路的重要性，后面专门有一章详细展开。

2.2 Python的引用计数与循环引用GC

Python（指CPython）的内存管理走了另一条路。它的核心机制是引用计数：每个对象内部都保存着一个计数器，记录当前有多少个变量（引用）指着它。当这个计数器归零，说明没有人再需要它了，解释器立刻回收这块内存。

python复制import sys

a = []
print(sys.getrefcount(a))  # 2，为什么是2？getrefcount自己也会临时引用一次

b = a
print(sys.getrefcount(a))  # 3，b也指向了同一个对象

del b
print(sys.getrefcount(a))  # 又变回2

引用计数最大的好处是回收及时、逻辑简单：对象没人用了，马上释放，不需要“等到某个时刻才回收”。但引用计数有一个天生bug——循环引用。如果两个对象互相引用，并且它们和外部世界彻底断开了联系，它们各自的引用计数都不会归零，于是谁也不会被释放，内存就泄漏了。

python复制class Node:
    def __init__(self):
        self.next = None

a = Node()
b = Node()
a.next = b
b.next = a

# 删除 a、b 两个外部引用
del a
del b
# 现在 Node 实例互相引用，引用计数为1，永不为0，常规GC也难以及时回收

针对这个情况，Python还内置了一个循环垃圾收集器（Cyclic GC），专门负责找出这些“互相引用但外部已经不可达”的对象组并回收它们。所以Python的内存管理其实是两层：引用计数负责快速回收简单情况，循环GC兜底解决复杂依赖。这整套机制让你在绝大多数时候根本不用关心释放问题，也正因如此，Python程序的内存占用往往比相同功能的C++程序高——你享受的是自动管理的便利，付出的是内存占用和性能的代价。

2.3 RAII思想与Python的with：殊途同归的资源管理

这里有一个非常值得玩味的对比。C++的RAII用“栈对象析构”来保证资源释放，Python虽然不支持“析构函数”这种同步机制，却提供了一个非常类似的语法糖——with语句和上下文管理器。

拿文件操作举例。C++用fstream打开文件，文件对象在作用域结束时自动关闭，即使中途抛异常，析构函数也会被调用，文件一样能关闭：

cpp复制{
    std::ofstream file("output.txt");
    file << "hello";
    // 不用手动 close，file 析构时自动关闭
}

Python则用with来达到同样的效果：

python复制with open("output.txt", "w") as f:
    f.write("hello")
    中途可以抛出异常，文件也会被关闭

无论执行过程中发生了什么，with语句块退出时都会调用f的__exit__方法，文件被自动关闭。

这两种机制思想上是一致的：把“释放”这件事和“作用域”绑定起来，利用语言自身的控制流替你完成善后。区别在于，C++的RAII是语言级别的基础设施，你写的任何类都可以通过析构函数获得这种能力；而Python的with需要你显式实现__enter__和__exit__，或者使用现成的上下文管理器。Python没有真正的析构保证——__del__方法在CPython中虽然通常在引用计数归零时调用，但等不等得到、何时调用，都无法做到像C++析构那般确定。

我实际项目中遇到过一个问题：在Python的__del__里做资源清理，结果对象进入了循环引用，__del__迟迟不被调用。排查了很久才发现是垃圾回收和析构顺序的坑。后来直接用with改成上下文管理器，问题彻底消失。这个教训分享给所有从C++转Python的朋友——在Python里，别依赖“析构函数”，用with或者try/finally才是靠谱的做法。

3. 可变与不可变：最容易被忽略的内存语义差异

如果说前两章讲的还是“变量是什么”“内存怎么管”，那这一章要讲的是Python里最隐蔽、最容易被踩的一个雷区——可变对象与不可变对象之间的内存语义差异。这个话题单独拿出来讲，是因为它天然横跨了C++和Python两套思维体系：C++程序员习惯用const和值传递约束行为，Python程序员则必须靠“可变性”来预测一个操作到底会不会影响原对象。

3.1 从变量赋值看值语义与引用语义

C++默认是值语义。int b = a，复制的是数值本身；vector b = a，会调用拷贝构造函数，把a里的所有元素复制一份出来。修改b不会影响a，除非你显式地使用引用或指针。

Python默认是引用语义。b = a，复制的只是引用，a和b指向同一个对象。如果这个对象是可变类型，修改b很可能就修改了a。

最常见的例子是list：

python复制a = [1, 2, 3]
b = a           # b 与 a 指向同一个列表
b.append(4)
print(a)        # [1, 2, 3, 4] —— a也被改了！

C++程序员看到这段代码会非常不习惯：我没让你引用传递，为什么a被改了？因为Python里等号就是绑定引用，没有值语义的拷贝。想真正复制一份独立的数据，必须显式使用copy或deepcopy：

python复制b = a.copy()    # 浅拷贝, b 是新的列表
b.append(4)
print(a)        # [1, 2, 3]，不受影响

注意浅拷贝只是复制了最外层。如果列表里嵌套了可变对象，内部对象仍然是共享的：

python复制a = [[1, 2], [3, 4]]
b = a.copy()
b[0].append(99)
print(a)        # [[1, 2, 99], [3, 4]] —— 内部子列表仍然是同一份

这个行为和C++的浅拷贝、深拷贝问题如出一辙，只是C++里通过拷贝构造函数copy constructor、以及深拷贝的显式实现来管理。Python则用copy模块把选择权交付给开发者，本质问题一模一样：不知道自己在浅拷贝的话，后续查bug查到怀疑人生。

3.2 可变对象在Python传参中引发的“意外”

Python的函数传参机制只有一种——传引用。但为什么有些函数里修改参数会改到调用者，有些不会？答案全在对象的可变性上。

python复制def change_list(lst):
    lst.append(100)     # 修改的是list对象本身，调用方会看到变化

def rebind_list(lst):
    lst = [100, 200]    # 重新绑定了局部变量lst，调用方不受影响

mylist = [1, 2]
change_list(mylist)
print(mylist)   # [1, 2, 100]，被改了

rebind_list(mylist)
print(mylist)   # [1, 2, 100]，没有变成 [100, 200]

这里的关键是：传进去的是引用，但“修改引用指着的东西”和“让引用指向别的对象”是两个完全不同的操作。append是前者，会把影响反映到调用方；等号赋值是后者，只改变了函数内部的局部变量名字指向，外部完全无感。

这个机制如果只停留在理解层面还好，真正坑人的是可变默认参数。看这个例子：

python复制def add_item(item, container=[]):
    container.append(item)
    return container

print(add_item(1))  # [1]
print(add_item(2))  # [1, 2] —— 为什么不是 [2]？

很多人第一次看到这个结果都懵了。原因在于：默认参数[]是在函数定义时创建一次的对象，每次调用函数如果没传container，用的都是这同一个list。第一次append了1，第二次调用时它还是那个list，所以结果变成[1, 2]。这在C++里就相当于函数的static局部变量，只不过没有显式标注。

标准解法是使用None作为默认值：

python复制def add_item(item, container=None):
    if container is None:
        container = []
    container.append(item)
    return container

这个坑无数Python新手踩过，也常被面试官拿来考察对引用语义的理解深度。

3.3 C++的const和值传递，Python完全没有对应物

从C++转Python的程序员，最不习惯的一处就是Python没有const。C++里你可以在函数参数上写const std::vector&，表示“引用传递、性能高、但禁止修改原对象”。Python没有类似的关键字，你没法通过类型签名来告诉调用者“我不会修改你的对象”。

这意味着Python里跨函数传大型对象，天生就是引用传递，性能损耗小，但“保护性”只能靠约定。团队协作时，如果队友在函数里通过append、insert等手段修改了传给它的list，调用方根本无法从函数签名上预判。代码写得越久，越觉得这种缺失带来的隐患不可小觑。

C++这边则刚好相反，需要非常小心地选择传值、传引用、传const引用、传指针、传const指针。传值安全但可能有拷贝开销；传引用高效但可能意外修改原值；传const引用两边兼顾，但如果你处理的对象内部还有指针，const也拦不住深层的修改。两门语言一个缺乏约束、一个约束太多，都有让初学者头疼的地方。

下面是两门语言在传参维度上的简表对比：

C++里你可以把一个对象设计成值语义的，让拷贝很自然；Python里的对象天生是引用语义，想让某个操作“不干扰原对象”，你得时刻记得去拷贝。这两种心智模型差异，比大多数语法层面的差异更影响代码风格。

4. 现代C++的答案：智能指针如何化解手动内存管理的一半痛苦

前面几章反复提到C++的手动内存管理容易出错，这一章就专门讲讲现代C++给出的解决方案——智能指针。这并不偏离本文主题，因为智能指针恰恰是C++想要缩小和Python内存管理体验差距的产物，理解了它，也就理解了C++社区对“自动内存管理”的思考方式。

4.1 裸指针的三大痛点与智能指针的化解思路

裸指针的痛点总结下来有三个：

第一是泄漏。new之后忘了delete，或者因为提前return、抛异常导致delete没有执行。C++里new和delete不是配对的，语言没有任何机制强迫你删除，全靠自觉。

第二是重复释放和悬垂。delete之后指针本身还存着原来的地址，如果你没有手动置空，后续再操作它就是未定义行为；如果两个指针指向同一块内存，两个地方各delete一次，直接崩溃。

第三是所有权不明确。一块内存到底归谁管？谁释放？多人协作时如果没约定好，就会出现“你释放了但我还在用”这样的尴尬局面。

智能指针的解决思路是RAII：把指针包在一个栈对象里，这个对象析构时自动delete它管理的堆内存。编译器保证栈对象在作用域结束时一定会析构，自然就保证了内存一定被释放。这背后用到的就是C++的析构函数机制，和Python的with思想同源。

4.2 unique_ptr、shared_ptr、weak_ptr怎么选

C++11开始，标准库提供了三种智能指针，用途各不相同。

unique_ptr表示独占所有权。同一时刻只有一个unique_ptr能拥有这块内存。它不能拷贝，只能通过std::move转移所有权。转移之后原来的指针就变成了nullptr。适合的对象是“明确只有唯一持有者”的资源，比如工厂函数返回的对象、类的独占属性。

cpp复制#include <memory>

std::unique_ptr<int> p = std::make_unique<int>(42);
std::unique_ptr<int> q = std::move(p);  // 所有权转移到q
// p 现在是空指针

shared_ptr表示共享所有权。内部实现了一个引用计数，记录有多少个shared_ptr共享同一块内存。每次拷贝计数器加一，析构时计数器减一，归零时释放内存。这个机制和Python的引用计数几乎一模一样。适合多个对象需要共同持有同一资源、无法确定谁最后离开的场景。

cpp复制std::shared_ptr<int> p = std::make_shared<int>(10);
std::shared_ptr<int> q = p;  // 引用计数变为2

weak_ptr是shared_ptr的“观察者”，它不增加引用计数，也不阻止对象被释放。它存在的核心用途是打破shared_ptr的循环引用——两个对象互相持有对方的shared_ptr，会导致引用计数永远不为零，内存泄漏。这个问题的本质和前面讲的Python循环引用一模一样，C++的解决方案是让其中一方持有weak_ptr。

cpp复制struct Node {
    std::shared_ptr<Node> next;
    std::weak_ptr<Node> prev;  // 打破循环，避免引用计数永远不为0
};

选型时的判断顺序是：先问“这块内存是否有多个所有者”，如果有就用shared_ptr；如果没有，优先unique_ptr。weak_ptr则是在检测到循环引用、或者需要“临时看看对象还在不在”的场景下使用。用裸指针管理生命周期在几乎所有应用场景下都已经不是最优选择了。

4.3 智能指针的隐藏开销和误用提醒

智能指针虽然好用，但也不是银弹，很多细节不注意反而会引入新的问题。

shared_ptr的引用计数操作是线程安全的，这意味着在并发环境下，每次拷贝和析构都会涉及原子操作。原子操作比普通操作慢不少，如果程序里大量拷贝shared_ptr，性能损耗就会显现出来。实测中，高频创建和销毁shared_ptr的场景，性能可能比裸指针慢一个数量级。

另一个坑是shared_ptr的构造方式。建议总是用std::make_shared而不是new + 传入shared_ptr构造器：

cpp复制// 推荐
auto p = std::make_shared<int>(42);

// 不太推荐
std::shared_ptr<int> p(new int(42));

原因是make_shared会在一次分配中同时分配对象内存和控制块内存，减少分配次数；而new版本会分开分配，多一次内存分配开销。此外，如果new完成后、构造shared_ptr之前抛出了异常，前者安全，后者可能泄漏。

还要注意，智能指针管理的是“生命周期”，不等于帮你解决所有的指针问题。如果代码里把一个裸指针从智能指针里取出来（用.get()，然后到处传递，一旦智能指针释放了内存，这个裸指针就是悬垂指针，照样崩。正确做法是：非拥有关系的访问，使用裸指针或引用；拥有关系的存储，使用智能指针。不要混用。

智能指针在C++社区现在已经非常常见，一个项目如果还到处是裸指针和手工delete，大概率是老代码或风格不佳。新写的代码，几乎可以默认选用智能指针。

5. 从C++到Python、或反向切换时最容易踩的坑

对我来说，这两种语言本质上是两种不同的思维模式。C++程序员切换到Python时会带回“指针思维”，Python程序员切换到C++时则会带上“垃圾回收思维”——两种思维迁移过程中都藏着不少坑。这一章分享几个我反复见到的错误，直接给解决方案，帮大家少走弯路。

5.1 C++程序员刚写Python的四个典型错误

第一个典型错误是误用is和==。C++里比较两个指针是否指向同一对象，用的是==；比较两个对象的值是否相等，通常也是==（重载后）。Python里两个比较完全不同：==比较的是值，is比较的是身份（也就是id是否相同）。很多C++程序员用is去判断两个字符串或两个数字是否相等，结果在小整数和短字符串上碰巧通过，在长字符串或大整数上却失败，极其迷惑。

python复制a = "hello world"
b = "hello world"
print(a == b)  # True，值相等
print(a is b)  # False，两个不同的字符串对象（在某些实现或场景可能是True，但不要依赖）

第二个典型错误是默认值浅拷贝。C++的赋值操作默认为拷贝，Python则是引用。C++程序员写Python时经常下意识以为b = a已经创建了新对象，结果a一变b也跟着变，定位半天才发现问题。解决方法是记住：在Python里等号不拷贝，想要独立对象就调用copy或deepcopy。

第三个典型错误是遍历list的同时修改list。这个不算纯内存问题，但和引用语义密切相关。C++里遍历vector并删除元素，只要正确处理迭代器也可以做到；Python里for x in lst循环体内直接调用lst.remove(x)或lst.append(...)，会导致运行错误或死循环。正确做法是遍历副本，或使用列表推导生成新列表。

第四个典型错误是对Python的不可变对象掉以轻心。Python的int、str、tuple是不可变的，任何修改操作都会创建一个新对象。C++程序员常以为数字变量就是一块可以随时改的内存单元，但在Python里，每次做a += 1都会在堆上创建新的int对象，丢弃旧的。这在循环里会带来不少性能开销。学会用id()观察这个现象，就能理解为什么Python里某些字符串拼接或循环累加会这么慢。

5.2 Python程序员刚写C++的四个典型错误

反向切换时又是一个镜像问题。

第一个典型错误是不初始化指针就使用。Python里没有“未初始化变量”的概念，所有变量都指向某个对象；C++里如果声明了一个指针却没有初始化，它的值是随机的，直接使用就是未定义行为，轻则读到垃圾值，重则奔溃。C++里一定要养成“声明即初始化”的习惯。

第二个典型错误是new了却忘记delete。Python开发者没有delete的概念，换成C++后如果只知道new而不知道配套的delete，程序跑着跑着内存就爆了。我的建议是，现阶段写C++首先考虑的不是裸指针+delete，而是直接用unique_ptr、shared_ptr，顺便把所有权设计想清楚。等到熟练了以后，再慢慢深入底层细节。

第三个典型错误是不理解函数返回局部变量的危险性。Python里函数返回一个list，很自然，调用方拿着用就行，Python会在堆上管理它的生命周期。C++里如果函数返回一个指向栈上局部变量的指针，局部变量在函数退出时就报废了，调用方拿到的是一块已失效的内存。返回堆上对象又涉及谁来释放的问题。这里的正确姿势通常是返回值对象本身（移动语义会帮你避免深拷贝），或者返回智能指针。

第四个典型错误是忽视拷贝开销。Python里int、float、list传参默认都是引用，没有拷贝成本；C++里如果你不写引用或指针，传一个vector就是完整深拷贝，数据量大时直接慢到怀疑人生。写函数参数时，记住：只读场景用const引用，要修改的场景用普通引用，有生命周期管理需求时用智能指针，只有特殊情况下才传值。

5.3 性能与心智模型：什么时候用谁

从内存管理的角度看，两门语言各自的定位已经很清楚了。

C++里你能精确控制每个字节的生命周期，能写出极具内存效率的程序，但这份控制力需要极高的注意力和经验来驾驭。适合的场景是：性能敏感的底层系统、实时系统、游戏引擎、嵌入式开发、需要长时间稳定运行且对内存占用有严格要求的环境中。

Python的内存模型让你不必关注底层细节，开发效率极高，但代价是内存占用通常比C++多好几倍，运行速度也会慢一到两个数量级。适合的场景是：快速原型、数据分析、脚本工具、Web后端、AI和机器学习方向。

实际工程里，不少人采用混合策略：核心计算模块用C++写好封装成Python的扩展模块，外围逻辑用Python调用。C++负责吃内存的能力、Python负责写代码的速度，各取所长。

对开发者的建议是，不要试图“只用一种思维”套用到两门语言上。C++的严谨、显式、对资源的高度掌控，和Python的轻快、简洁、自动化的资源管理，本质是两种工程哲学。能把两种心智模型切换自如，跨语言的开发体验才会真正上一个台阶。我自己多年来两门语言混着用，最大的收获反而是对内存管理本身的理解越来越深——所有语言在“数据存在哪里、它归谁管、什么时候释放”这个问题上，答案都是相通且相互启发的。