根本原因是内存生命周期错配：Python对象释放后C++仍访问其内存，或C++分配内存未被Python正确管理；常见于PyArg_ParseTuple类型不匹配、未初始化输出指针、析构中触发Python回调及shared_ptr删除器无GIL保护等。
为什么Python调用C++扩展时容易触发Segmentation Fault？
根本原因几乎总是内存生命周期错配：Python对象被释放后，C++代码仍在访问其底层内存，或者C++分配的内存未被Python正确管理。这不是“随机崩溃”，而是典型的悬空指针或越界访问——gdb回溯里常看到PyUnicode_AsUTF8、PyList_GetItem或自定义PyObject*成员访问处中断。
检查PyArg_ParseTuple参数类型与实际传入是否严格匹配
这是最隐蔽也最高频的崩溃源头。比如声明"s"却传入None，或用"O!"但没校验对象类型，PyArg_ParseTuple会静默填充垃圾指针，后续解引用直接崩。
- 用
"s#"代替"s"处理可能含\0的bytes，避免strlen越界 - 对非基础类型（如自定义类实例），必须用
"O!"并传入对应&PyMyType_Type，不能只写"O" - 所有输出参数指针（如
char**）在调用前必须初始化为NULL，否则未赋值时可能指向随机地址
确保C++对象析构不触发Python GC相关操作
在__dealloc__或C++析构函数里调用Py_DECREF、Py_XDECREF是安全的，但绝不能在此时触发Python层回调（如__del__、弱引用回调、或任何可能重新进入CPython解释器的路径）。常见陷阱：
- 析构函数里调用
PyRun_SimpleString或PyObject_Call - 持有
PyObject*成员的C++类，在析构时未先置空就调用Py_XDECREF，而该对象已被GC回收 - 使用
std::shared_ptr管理Python对象，但其删除器未用Py_DECREF且未加GIL保护
调试时优先启用AddressSanitizer和Python的-debug构建
普通gdb只能告诉你崩在哪一行，但无法定位内存误用根源。真实排障要靠工具链协同：
立即学习“Python免费学习笔记（深入）”；
- 编译C++扩展时加
-fsanitize=address -fno-omit-frame-pointer，链接时加-shared -fsanitize=address - 用
python3-dbg（而非普通python3）运行，它内置更多内存检查断言 - 崩溃时看ASan输出的
heap-use-after-free或stack-buffer-overflow提示，比段错误信号更精准
真正麻烦的从来不是“怎么修”，而是“怎么确认修对了”——ASan能暴露90%的内存误用，但前提是你的构建流程允许它介入。别跳过这步。
