使用Visual Studio构建Python 3.6.4静态库(/MTd)遇调试断言失败求助

这个调试断言失败（_osfile(fh) & FOPEN）的核心原因其实很好理解：当你用/MTd（多线程调试静态CRT）模式构建Python和你的代码时，Python运行时和你的自有代码会各自拥有独立的CRT（C运行时库）实例——每个静态链接的CRT都有自己的全局状态（比如文件句柄表_osfile），两者完全不共享。这就导致Python的CRT无法识别你的代码打开的文件句柄状态，反过来也一样，最终触发了断言。

下面是具体的解决步骤，亲测有效：

1. 彻底统一Python构建的CRT配置 #

Python源码默认是按动态CRT（/MD//MDd）配置的，所以你必须确保整个Python构建流程完全切换到/MTd：

• 如果用VS打开Python的项目（比如PCbuild\python.sln），逐个检查所有子项目（包括pythoncore、各个扩展模块、测试项目）的C/C++ → 代码生成 → 运行库设置，全部改成多线程调试(/MTd)，绝对不能混合/MDd和/MTd选项。
• 如果用PCbuild\build.bat脚本构建，需要修改脚本里的编译参数，把所有/MDd替换成/MTd，同时确保脚本调用的所有编译工具链都使用这个参数。

2. 避免跨CRT的文件句柄传递 #

因为两个CRT实例的文件状态表完全独立，直接在你的代码里打开文件然后交给Python操作，或者反过来，都会导致状态不匹配：

• 优先统一通过Python的C API来处理文件：比如不要在你的代码里用fopen打开文件，而是调用Python的PyFile_Open或者通过PyRun_SimpleString执行Python的open()函数，获取Python文件对象后再操作。
• 如果必须在你的代码里处理文件，就自己完成所有读写逻辑，不要把底层文件句柄传递给Python；同理，Python打开的文件，也不要在你的代码里直接用_read/_write这类CRT函数操作。

3. 适配Python源码的CRT依赖 #

Python的部分源码直接依赖CRT的全局状态（比如read.cpp里用到的_osfile），静态链接时这部分会失效。你可以做小范围的源码修改：

• 找到Python源码中依赖CRT全局文件状态的地方，替换为Python自身维护的文件对象状态。比如，Python的PyFileObject结构体里有自己的状态标记，可以用这个来判断文件是否打开，而不是依赖CRT的_osfile。

4. 调试验证技巧 #

调试时可以在断言触发处暂停，查看fh的值，然后在你的代码打开文件后，检查当前模块的_osfile状态，再对比Python模块里的_osfile——你会发现两者对同一个句柄的状态标记完全不同，这就能实锤是CRT实例隔离的问题。

最后提个建议：如果不是必须要静态链接CRT，优先保持/MDd的构建方式，Python的设计本身更适配动态CRT，能避开很多这类跨模块状态隔离的坑。

内容的提问来源于stack exchange，提问作者Jiminion