pytest.raises对c扩展失效的根本原因是c扩展未抛python异常，而是直接触发sigsegv或abort()等系统信号，绕过python异常机制，导致测试进程被终止而非捕获异常。
pytest 无法捕获 C 扩展模块抛出的“异常”，根本原因不是它不支持，而是 C 扩展压根没抛 Python 异常——它直接触发信号（如 SIGSEGV）或 abort()，绕过了 Python 的异常机制。
为什么 pytest.raises 对 C 扩展完全失效？
Python 的 pytest.raises 只能拦截被 PyErr_SetString、PyErr_SetObject 等 C API 主动设置并由 Python 解释器调度的异常。而多数 C 扩展在出错时：
- 访问非法内存地址 → 触发
SIGSEGV，进程立即终止，不经过 Python 异常栈 - 调用
abort()或exit()→ 进程退出码非零，无 traceback - 忘记调用
PyErr_Set*就返回 NULL → Python 层收到None或静默错误，而非异常 - 即使设置了 Python 异常，但没在返回前调用
return NULL→ 解释器不认为该函数“失败”，异常被忽略
常见错误现象：测试“消失”或返回 Killed
你运行 pytest test_cext.py，结果：
python全能编程助手
下载
SkillSub Pro - Python 题解与代码注释双功能技能功能概述SkillSub Pro - Python 题解与代码注释双功能技能是一项面向实际任务的技能，主要用于SkillSub Pro 是一个 Python 题解生成与代码注释的 双功能合体技能 ，专为学生、算法学习者和开发者设计；✅ 一个技能，两种用途 ：；核心要点📝 题解模式 ：输入题目/题号，自动生成完整 Python 题解（含详细注释、解题思路、复杂度分析）；💬 注释模式 ：输入 Python 代码，自动添加详细中。它将相关步骤、
- 测试用例没报错也没通过，直接退出，终端只显示
Killed - CI 上看到
Exit code: 139（即 SIGSEGV 的 128+11） -
pytest -s -v下看不到任何 traceback，日志戛然而止 - 加了
with pytest.raises(ValueError)，但测试仍标为 PASSED —— 因为 C 函数根本没执行到抛异常那步就崩了
怎么验证确实是 C 层崩溃，而不是 Python 异常没捕获？
别依赖 pytest.raises，改用操作系统级观测手段：
- 用
ulimit -c unlimited开启 core dump，复现后用gdb python core查崩溃点 - 运行
strace -e trace=signal,clone,exit_group pytest test_cext.py，看是否出现SIGSEGV或exit_group(139) - 用
valgrind --tool=memcheck --track-origins=yes python -m pytest test_cext.py检查内存越界/释放后使用 - 在 C 代码关键路径加
fprintf(stderr, "[DEBUG] reached here\n")+fflush(stderr)，确认执行流是否卡在某行前
真正可行的测试策略：隔离 + 监控 + 替代断言
对 C 扩展不能靠「断言异常类型」，而要转向「验证行为边界」和「进程稳定性」：
- 用
subprocess.run(['python', '-c', 'import mymod; mymod.bad_func()'], timeout=5)启子进程跑单个 C 调用，检查returncode是否为 0；非零就说明崩溃 - 在 C 函数入口加输入校验（如指针非空、size > 0），并主动调用
PyErr_SetString(PyExc_ValueError, "...")+return NULL，确保错误走 Python 异常通路 - 用
pytest-cov结合--cov-fail-under=100强制覆盖所有 C 分支，避免漏测未校验路径 - CI 中固定用
python -X dev运行，启用 Python 的开发模式（会额外检查引用计数、API 使用合规性）
最易被忽略的一点：C 扩展里所有 PyObject* 返回前，必须检查是否为 NULL 并及时传播错误；否则哪怕底层已设异常，上层 Python 代码也会当作正常值继续执行，最终在不可预期位置崩溃。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
