根本原因是内存生命周期错配：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解释器的路径）。常见陷阱：

提示词大师-python版

图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍

下载

• 析构函数里调用PyRun_SimpleString或PyObject_Call
• 持有PyObject*成员的C++类，在析构时未先置空就调用Py_XDECREF，而该对象已被GC回收
• 使用std::shared_ptr管理Python对象，但其删除器未用Py_DECREF且未加GIL保护

调试时优先启用AddressSanitizer和Python的-debug构建

普通gdb只能告诉你崩在哪一行，但无法定位内存误用根源。真实排障要靠工具链协同：

• 编译C++扩展时加-fsanitize=address -fno-omit-frame-pointer，链接时加-shared -fsanitize=address
• 用python3-dbg（而非普通python3）运行，它内置更多内存检查断言
• 崩溃时看ASan输出的heap-use-after-free或stack-buffer-overflow提示，比段错误信号更精准

真正麻烦的从来不是“怎么修”，而是“怎么确认修对了”——ASan能暴露90%的内存误用，但前提是你的构建流程允许它介入。别跳过这步。

Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！