PyQT5 GUI生成exe后运行1小时崩溃问题求助

可能的原因及排查方向 #

1. GUI主线程被日志写入阻塞 #

PyQt要求所有GUI操作必须在主线程执行，但如果每秒的日志写入操作也在主线程里同步执行，即使单次写入耗时极短，在exe打包后的环境中（解释器性能、系统调度差异），大量高频的IO操作会逐渐挤占主线程资源，导致GUI事件队列堆积，最终卡顿崩溃。而PyCharm中运行的原生Python环境，线程调度效率更高，能更好地处理这种高频操作。

解决方向：把日志写入逻辑放到单独的QThread线程中执行，主线程只负责接收数据并传递给线程，避免IO操作阻塞GUI。

2. 文件句柄/资源泄漏 #

如果你的每秒日志写入逻辑是每次都重新打开/关闭文件（而非保持一个持久的文件句柄），虽然用了with open语法理论上会自动释放资源，但在PyInstaller打包的exe环境中，可能存在系统文件资源回收延迟的问题，高频的文件打开/关闭会导致句柄积累，最终触发系统资源耗尽崩溃。

解决方向：初始化时打开一次日志文件，保持文件句柄，每次写入后调用flush()确保数据落盘，程序退出时再关闭文件；或者检查是否有未正确释放的文件相关对象。

3. PyInstaller单文件打包的额外开销 #

如果你用了--onefile参数打包成单文件exe，运行时程序会先把自身解压到系统临时目录，再加载运行。这种模式下，文件IO的额外开销更大，且临时文件的管理可能存在隐性问题，高频日志写入会放大这些开销，导致内存或资源占用持续增长。

解决方向：改用--onedir模式打包（生成一个目录包含所有依赖），对比是否还会出现崩溃；或者检查临时目录的权限，确保程序有读写权限。

4. 文件缓冲策略导致内存占用过高 #

默认情况下，Python的文件写入会使用系统级缓冲，在exe环境中，可能缓冲的阈值或回收机制和原生Python不同，每秒写入的小数据会不断积累在内存缓冲中，没有及时写入磁盘，导致内存占用持续升高，最终崩溃。而PyCharm运行时，系统的缓冲调度更及时，内存不会过度积累。

解决方向：打开文件时显式指定buffering=1（行缓冲），或者每次写入后调用file.flush()强制将缓冲数据写入磁盘；也可以尝试buffering=0（无缓冲，适合小数据高频写入场景）。

5. 内存泄漏（对象未被正确回收） #

在PyInstaller打包的环境中，Python的垃圾回收机制可能因为打包时的优化（比如某些模块被静态链接），导致日志相关的对象（比如每次创建的csv.writer/csv.DictWriter）无法被及时回收，内存占用逐渐升高。而PyCharm运行的原生Python环境，垃圾回收调度更频繁，能及时清理这些对象。

解决方向：检查日志写入逻辑，避免重复创建不必要的对象（比如可以复用同一个csv.writer实例，而非每次写入都重新创建）；用内存监控工具（比如psutil）在exe运行时跟踪内存变化，定位内存增长的来源。

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