Python 应用在机器学习、科学计算等关键领域广泛存在，这些应用常通过集成 C 等底层语言编写的原生代码来提升性能或实现互操作。然而，原生代码中的缺陷（即 native code bugs）通常隐蔽且难以察觉，给整个 Python 应用的质量带来了额外挑战。尽管已有相关研究，但学术界和工业界对这些缺陷的系统性理解仍然不足。本文首次针对 Python 应用中的原生代码缺陷进行了深入的大规模实证研究。作者从 GitHub 上真实的开源 Python 项目中人工筛选并分析了 216 个原生代码缺陷，结合自动化工具与人工分析，系统梳理了这些缺陷的常见症状（如崩溃、内存错误）、引入位置（如绑定层、扩展模块）、外在表现特征、根本原因（如内存管理错误、类型转换问题、引用计数问题）以及修复模式。研究获得了一系列新颖的发现，例如这些缺陷往往集中在特定类型的 API 边界处，且某些根因在不同项目中反复出现。作者还总结了有效的修复策略和代码审查中值得关注的信号，为 Python 生态中的开发者、代码审查者以及安全人员提供了第一份系统的证据基础，有助于改进工具检测、测试方法和编程实践，从而降低原生代码引入的安全与稳定性风险。

本文针对C语言内存安全加固研究中普遍存在的“单漏洞类孤立评估”问题，提出了一种全新的跨语言比较评估范式。过去数十年，研究者提出了许多针对C语言的内存安全回填机制，但这些机制几乎总是在孤立条件下、针对特定漏洞类型进行评估，导致实际工程实践中难以判断多种防御机制叠加后带来的综合性能开销、互操作冲突和保护覆盖缺口。作者主张应像评估原生内存安全语言（如Rust和Go）那样，对C语言的复合加固方案进行整体性基准测试。为此，他们设计了一套标准化的跨语言任务集，同时部署多种先进的内存安全回填机制，并测量其组合使用时的性能与防护效果。实验结果显示，分层部署的C语言防御机制会带来累积的、依赖工作负载的性能惩罚；部分机制之间存在根本性的架构不兼容；即便叠加多项加固，其防护范围仍无法达到Rust或Go等原生安全语言的水平。这些发现揭示了一个关键的工程决策缺口：在遗留C代码库中向后移植安全特性的真实成本往往被隐藏，使开发团队难以在加固旧系统和迁移到现代安全语言之间做出明智选择。作者因此呼吁内存安全研究领域应放弃孤立评估模式，转向更全面、可比较的评估框架，以帮助高风险决策（如是否重写系统）建立在可靠的数据基础上。该研究对系统软件、嵌入式设备、网络服务等依赖C语言的高危场景具有重要参考价值，也为安全团队评估长期投入方向（是修补还是迁移）提供了方法论支撑。