企业官网建设流程全解析

简介：围绕PyQt的视频监控系统实战教程，面向希望用Python快速构建桌面GUI应用的初中级开发者，尤其适合课程设计、毕业设计或想快速做出可演示原型的读者。资源包共28个文件，包含4个Python源码、5个XML工程文件、14张PNG图片及少量pyc缓存与IDE配置，整体仅84KB，轻量而结构清晰，按入口主程序、摄像头采集、界面生成等模块存放，便于对照学习。内容覆盖PyQt窗口部件与布局管理、QMediaPlayer视频播放、OpenCV摄像头取流、多线程视频处理、信号槽通信、事件响应、界面设计与录制回放等关键机制，并给出从界面搭建到视频流接入的完整实现思路。已有357人浏览学习，下载后可获得可直接运行的示例工程与模块化代码，边对照边实践，即可搭建出一个基础远程视频监控系统，也可作为后续扩展网络传输功能的起点。

1. 使用 pyq 实战教程：从一个能跑通的桌面小工具说起

第一次看到「使用 pyq 实战教程」这个标题时，我以为是某个缩写；按技术路线拆开看，pyq 通常对应的就是 Python 的 Qt 绑定方案 PyQt。这篇课程资源的核心，是带你把一个桌面小工具从零拼到能打包：有界面、有文件选择、有进度条，而不是零散地讲控件。实际动手后你会发现，PyQt 的难点从来不是按钮和弹窗，而是界面、线程和业务三件事怎么串成一条线。

本教程就按这个顺序展开：先说选型和环境，再讲布局与信号槽，中间用批量压缩图片这个小工具练手，最后把打包和换肤的坑一并填上。适合刚学完 Python 基础、想把脚本变成窗口程序的 A 同学，也适合需要给团队做内部小工具的某开发者；如果你想一次性做大型跨平台产品，这套内容的范围就不够了。

2. 为什么选 pyq：桌面 GUI 选型逻辑与一分钟环境搭建

2.1 桌面端为什么值得用 Qt：三选一之后留下的方案

Python 世界的桌面 GUI 方案，大多数人会在 Tkinter、Electron 和 PyQt（也就是标题里 pyq 所指向的技术栈）之间选一个。Tkinter 的优势是零安装，Python 自带，写几十行的设置面板完全够用；问题在于控件风格偏旧，复杂布局写起来很啰嗦，回调函数一旦多起来，代码会变成一串串难维护的命令绑定。Electron 的优势是前端技术栈可以直接搬，界面做得非常漂亮；代价是体积和内存占用十分可观，一个 hello world 级别的窗口打包后经常在几百兆级别，对内部小工具来说属于杀鸡用牛刀。PyQt 恰好站在两者中间：控件齐全，文档积累厚，信号槽机制天然贴合事件驱动，打包体积也比 Electron 小一截。

我一般这样划边界：如果你只是需要一个表单、一个按钮，Tkinter 就够了；如果要做编辑器级别的复杂交互，或者说团队里已经全是前端，那 Electron 更顺手；如果你要把 Python 现有的数据分析、图像处理逻辑直接变成桌面产品，PyQt 是性价比最高的选择。它不需要额外起一个 Node 进程，Python 代码和界面逻辑能在同一个进程里互相调用，调试链路短，出问题也好排查。这段取舍也回应了这类课程资源里最常见的疑问：为什么教程一上来不先让你拖控件，而是先谈选型？因为选型错了，后面做得越深，返工越多。

PyQt 本身是基于 C++ 的 Qt 框架的 Python 绑定，意味着你可以继承 QMainWindow、QThread 这些类，直接用 Python 写业务逻辑，底层渲染和事件循环交给 Qt 处理。拿到一份 pyq 课程资源时，我建议你先看它的目标产物是什么。如果目标是一个能处理真实文件、有耗时任务和进度反馈的工具，那它大概率就是用 PyQt 这类绑定库写的；这种资源的价值不在控件清单，而在把界面和业务串起来的组织方式。把选型逻辑想清楚，接下来环境搭建才有意义。

2.2 环境搭建：虚拟环境、核心依赖与第一个容易翻车的点

拿到这类课程资源，最容易翻车的第一步不是代码写成什么样，而是环境没有隔离。不少同学一上来就全局 pip install pyqt5，几天后另一个项目需要别的 GUI 库，依赖一冲突，整个环境直接报废。所以不管教程里有没有提，第一步我都会先建虚拟环境：

python -m venv .venv # macOS / Linux 下用这行激活 source .venv/bin/activate # Windows 下用这行激活 .venv\Scripts\activate

虚拟环境的逻辑是给当前项目单独开一份 Python 解释器和依赖目录，pip 安装的东西不会污染全局环境。激活之后命令提示符会多出 (.venv) 前缀，说明已经进入虚拟环境；关掉终端再打开时，要用同样的命令重新激活，这个细节新手特别容易忽略。后面所有安装和运行命令，都建议在这状态下执行。如果发现 pip install 装了之后 python 导入还是失败，第一反应就应该是看当前解释器路径是不是还在虚拟环境里面。

有了隔离环境，再装核心依赖。以这套实战教程配套的批量压缩图片小工具为例，需要三个包：界面框架本身、图像处理库、以及最后的打包工具：

pip install pyqt5 pillow pyinstaller

pyqt5 提供 QtWidgets、QtCore、QtGui 三个核心模块，分别负责控件、事件循环和基础绘图；pillow 负责读图、转格式和压缩质量控制；pyinstaller 在最后一章打包成可执行文件时才用到，现在一起装好可以避免后面环境混乱。这里不需要指定具体版本号，直接装 pip 拉到的当前稳定版本即可；等你在某一台机器上把工程跑起来以后，再用 pip freeze 把版本固定下来，以后换电脑重建环境就有依据了。

安装完成之后，做一次最小化验证，确认 PyQt 能在这个环境里正常创建应用对象：

python -c "from PyQt5.QtWidgets import QApplication; print('qt ok')"

这条命令会导入 QApplication 并打印 qt ok。如果报错，优先检查两件事：第一，当前激活的确实是虚拟环境而不是全局 Python；第二，系统缺少 Qt 运行所需的底层动态库。在 Windows 上，这经常表现为导入阶段报找不到 DLL，需要先装对应版本的 Visual C++ 运行库；在 macOS 上，则要确认 Python 解释器和 PyQt 是同一套架构。把这两点检查完，环境基本就立住了，后面所有示例代码都默认已经处于这个可用环境之中。

2.3 拿到资源先做的三步验收：入口脚本、依赖清单、冒烟测试

一份课程资源下载下来，先别急着从头到尾通读代码，按三步做验收，能省下很多时间。第一步是看目录结构，找到入口脚本，通常叫 main.py 或 app.py，打开它直接确认顶部 import 了哪些模块，这决定了它是不是 PyQt 工程。第二步是看有没有依赖清单，有 requirements.txt 就用pip install -r requirements.txt，没有就从所有 import 语句里手推依赖。第三步是做冒烟测试，直接运行一次入口脚本，界面能弹出来，窗体不闪退，就证明环境可用，再开始改代码。

课程资源最容易藏着的问题有两类：一类是老版 PyQt5 代码把控件类从 PyQt5.QtGui 导入，而新版里控件类都在 PyQt5.QtWidgets 下，一运行就报 ImportError；另一类是缺少入口保护，顶层直接写了创建窗口和 app.exec_() 的代码，在别的模块导入时也会把窗口弹出来。遇到这两类问题，先看报错位置，再对照当前版本的模块划分，基本都能立刻定位。这套验收流程走下来，后面做功能才是在真正理解代码，而不是对着黑匣子乱试。

3. 从控件到事件：布局器、信号槽与 Qt Designer 的边界

3.1 Qt Designer 画界面：什么时候该用，怎么把 .ui 并进工程

说到 PyQt 实战，绕不开 Qt Designer。它打开就是可视化拖控件，把 QListWidget、QPushButton 拖到窗口上，再调整大小、设置默认文案，看起来比手写布局直观得多。这一步值得做，但前提是得知道它在干什么。Qt Designer 保存的 .ui 文件本质是一份 XML 描述，里面记录的是控件类型、属性值和布局关系，它本身不是可执行的 Python 代码。工程化一点的做法是，把反复试验界面样式的阶段放在 Designer 里完成，然后通过 pyuic5 把 .ui 转成 Python 类：

pyuic5 main.ui -o ui_main.py

这条命令生成的文件包含一个名为 Ui_MainWindow 的类，里面有 setupUi(self, window) 方法。在正式代码里这样接入：

from PyQt5.QtWidgets import QMainWindow from ui_main import Ui_MainWindow class MainWindow(QMainWindow): def __init__(self): super().__init__() self.ui = Ui_MainWindow() self.ui.setupUi(self)

到这一步，MainWindow 里就能用 self.ui.list_file、self.ui.btn_start 访问 Designer 里定义的控件了。你可能会问：既然 Designer 能可视化布局，为什么还要强调手写布局？我的答案很直接：因为界面改不动的时候，九成原因是布局器用错了，不是控件拖少了。Designer 只负责生成初始结构，运行时窗口一拉伸，控件怎么伸缩、间距怎么变化，全部由布局器决定。不理解布局器，就只能反复在 Designer 里拖，拖半天一运行又变样。

所以我一般养成的习惯是：第一版界面用 Designer 快速成形，然后亲自把 setupUi 里的布局代码读一遍。比如 QVBoxLayout 和 QGridLayout 的区别、addWidget 的 stretch 参数怎么给，在 Designer 里只是几个属性，在代码里才是完整逻辑。另外还要留意控件的父对象参数：像 QWidget(self)、QPushButton(central) 这种写法，把控件挂进了对象树，PyQt 会在父对象销毁时自动清理子对象，不需要手动去 delete，这也是能从 Designer 生成的代码里学到的细节。

3.2 手写布局：主窗口、中央组件与 stretch 参数的配合

既然上面把 Designer 的边界说清了，这里直接手写一个最简工具窗口。目标是批量压缩图片工具的主界面：一个文件列表、一个开始按钮。用 QMainWindow 作为最外层容器，它自带菜单栏和状态栏的区域；中央区域放一个 QWidget 作为容器，再在容器上铺一个垂直布局：

import sys from PyQt5.QtWidgets import (QApplication, QMainWindow, QWidget, QVBoxLayout, QListWidget, QPushButton) class MainWindow(QMainWindow): def __init__(self): super().__init__() self.setWindowTitle("批量压缩工具") self.resize(720, 480) central = QWidget(self) self.setCentralWidget(central) layout = QVBoxLayout(central) self.list_file = QListWidget(central) layout.addWidget(self.list_file) btn_start = QPushButton("开始处理", central) layout.addWidget(btn_start) btn_start.clicked.connect(self.on_start) def on_start(self): count = self.list_file.count() paths = [self.list_file.item(i).text() for i in range(count)] print(paths) if __name__ == "__main__": app = QApplication(sys.argv) win = MainWindow() win.show() sys.exit(app.exec_())

这段代码有几个结构点值得细看。QMainWindow 本身不直接装控件，需要 setCentralWidget 指定一个中央 QWidget，否则控件没地方放；QVBoxLayout 里 addWidget 的顺序就是控件从上到下的排列顺序，不需要手动算坐标。resize(720, 480) 给了窗口一个初始尺寸，之后窗口被拉伸时，列表和按钮之间的距离、谁变宽谁固定，由布局器和 stretch 参数共同控制。当前版本没有设置 stretch，按钮和列表会按比例伸缩，拉伸效果不太符合预期。

想让文件列表占据大部分空间、按钮固定在底部，改成这样：

layout.addWidget(self.list_file, 1) layout.addWidget(btn_start, 0)

第一个参数仍然是控件，第二个参数是拉伸因子。1 表示列表在窗口变高时优先占据增加的竖直空间，0 表示按钮保持固定高度；两个控件都是非零因子时按比例分配空间。这是 PyQt 布局里最常见的一组参数，在代码里写清楚，比在 Designer 里点几下更能应对后续需求变化。等列表变成多列、按钮变成多个的时候，你会发现 QGridLayout 的 setRowStretch 和 setColumnStretch 是同一套思维，只是多了一个维度。

3.3 信号槽：clicked 到 on_start 之间发生了什么

刚才代码里有一行 btn_start.clicked.connect(self.on_start)，这是 PyQt 事件体系的核心：信号槽。按钮被点击时，clicked 信号会发送出来，connect 把它连到 on_start 这个槽函数上。你不需要关心按钮内部怎么监听，只需要知道事件发生时，槽函数会被 Qt 的事件循环调用。这个机制比很多人习惯的回调函数列表要清晰，因为它把「谁发的信号」和「谁处理信号」解耦开了。

如果业务函数需要参数，注意不要在 connect 里直接调用函数，那样程序启动时就会执行一遍。常见做法是套一个 lambda：

def on_start(self, quality): # 处理逻辑 pass btn_start.clicked.connect(lambda: self.on_start(80))

这样写成立的关键在于 lambda 形成了一个闭包，点击时才去调用 self.on_start(80)，而不是启动时调用。这个细节在课程资源示例里经常出现，不熟悉的话，运行时会报参数数量不匹配的错误，而且报错点往往不在按钮那一行，排查起来要绕一圈。选 lambda 还是 functools.partial，主要看参数是固定值还是动态值：固定值两者都行，动态值用 lambda 更直观。

另外提醒一个隐藏细节：PyQt 的 clicked 信号其实会携带一个布尔参数，表示按钮当前是否处于按下状态。connect 到无参函数时，多余的参数会被框架忽略；但如果槽函数签名里声明了一个参数，而 connect 时没有包一层，就会出现参数不匹配的问题。很多示例里用 lambda 包一层，不只是为了传自定义参数，也顺带规避了这个信号自带参数的干扰。理解到这层，再看教程里的示例就不再觉得 connect 是黑匣子：它像一根线，把按钮上的事件和你的处理函数稳定地绑在一起。

4. 文件选择与进度反馈：线程隔离是桌面工具的生死线

4.1 文件对话框：多选、后缀过滤与返回结构

批量压缩工具的第一个实际能力是选文件。PyQt 里对应 QFileDialog.getOpenFileNames，弹出系统原生对话框，返回用户勾选的文件完整路径列表。过滤条件写在第三个参数里，用双分号分隔多种类型：

from PyQt5.QtWidgets import QFileDialog paths, _ = QFileDialog.getOpenFileNames( self, "选择需要压缩的图片", ".", "Image Files (*.png *.jpg *.jpeg *.bmp);;All Files (*.*)", )

这里返回的是元组，第一个元素是路径列表，第二个是用户实际选择的文件类型过滤条件。这个方法默认就支持多选，不需要额外传参数；如果只想单选，改用 getOpenFileName，返回的直接是单条路径字符串。路径在 Windows 上往往带反斜杠，在 macOS 和 Linux 上则用正斜杠；后续交给 os 模块处理文件时，我先做一次规范化，避免路径拼接踩坑：

import os normalized_paths = [os.path.normpath(p) for p in paths]

normpath 会把分隔符统一成当前平台风格，并清理掉多余的斜杠。这一步看起来冗余，但平时如果直接把路径拼进字符串，Windows 下很容易拼出双反斜杠目录，最后文件保存到奇怪的位置。做这类文件类工具，我会把 normpath 和后续扩展名检查放到一个公共函数里，避免在每个按钮槽函数里重复写。

还有个容易忽略的点是初始目录参数。这里直接用 "." 代表当前工作目录，但对需要反复使用的内部工具来说，用户通常希望第二次打开时定位到上次的目录。这件事放到后面 QSettings 一节专门处理，这里先知道 getOpenFileNames 可以接受一个绝对路径作为初始目录即可，运行时会优先定位到那里，用户仍然可以在对话框里自由跳转。

4.2 事件循环与假死：为什么耗时任务必须离开主线程

文件列表接进来之后，下一步是压缩。如果直接在按钮槽函数里写一个循环，逐个用 Pillow 压缩几十张图，你会看到一个非常典型的故障：窗口标题栏变成未响应，按钮失效，甚至连鼠标拖拽都没有反应。原因是 PyQt 的界面刷新依赖事件循环，而事件循环跑在主线程里；耗时循环把主线程占住，Qt 就分不出时间处理鼠标事件和重绘请求，操作系统层面认定程序卡死。

解决办法遵从一个黄金规则：任何可能超过几十毫秒的任务都不放主线程。PyQt 里最顺手的方式是继承 QThread，把任务放进 run 方法，通过信号把进度和结果传回主线程：

import os from PyQt5.QtCore import QThread, pyqtSignal from PIL import Image class CompressWorker(QThread): progress = pyqtSignal(int, int) finished_one = pyqtSignal(str) error = pyqtSignal(str, str) def __init__(self, files, quality=60): super().__init__() self.files = files self.quality = quality def run(self): total = len(self.files) for idx, path in enumerate(self.files, start=1): try: out = self._compress_one(path) except Exception as exc: self.error.emit(path, str(exc)) continue self.finished_one.emit(out) self.progress.emit(idx, total) def _compress_one(self, path): out = os.path.splitext(path)[0] + "_compressed.jpg" with Image.open(path) as im: im.save(out, quality=self.quality) return out

这段代码里，QThread 的子类把 run 方法作为工作线程入口，start() 调用后才真正启动线程；pyqtSignal(int, int) 声明了带两个整数的信号，emit 时这两个数值按顺序传到主线程连接的槽函数里。error 信号用来上报单张图片的处理失败，外层循环继续跑，不会因为某一个文件损坏就让整个任务中止。Pillow 的 Image.open 在 with 块中确保文件句柄被释放，压缩结果保存成与原文件同目录、追加 _compressed 后缀的文件，避免覆盖原图。

主线程侧连接：

self.worker = CompressWorker(file_list, quality=80) self.worker.progress.connect(self.update_progress) self.worker.finished_one.connect(self.list_file.addItem) self.worker.error.connect(self.show_error) self.worker.start()

update_progress 拿到两个 int 参数：已完成数和总数，直接同步到 QProgressBar。耗时循环在工作线程里跑，主线程持续刷新界面，进度条能实时前移，窗口也能随时关闭。这里有一个硬性约束：工作线程里绝不能直接操作任何界面控件，比如 self.progress_bar.setValue，所有从工作线程往界面传状态的行为，都必须通过 signal.emit 完成。

课程里有个常见误区是拿 threading.Thread 替代 QThread。threading 本身没有问题，但工作线程和 Qt 事件循环的协同要额外手动处理；QThread 把「跨线程传数据」用信号槽写进框架，省掉自己拼队列的步骤。对这批图片压缩任务来说，继承 QThread 可读性最好，代码量最少。如果追求更规范的架构，moveToThread 模式也可以，但那个模式需要把 Worker 对象 move 到线程里，概念更多，我这里先用最容易复现的写法。

4.3 实测过程：进度从 1 到 500 的失真与修复

用这套线程方案跑一批几百张图片时，会遇到一个很典型的问题：进度条长时间停在 1%，然后一口气跳到 100%。这时候别急着怀疑线程写错，先看 progress.emit 的时机。如果把进度信号放在单张图片处理完成之后，个别大图压缩耗时接近三秒，进度条自然就出现长时间停顿。用户感知到的不是匀速变化，而是卡一下、跳一段，体验很差。

要改善体验，可以把任务按文件大小拆成更细的步进。Pillow 加载图片前先读一次文件大小，用字节数作为权重，进度信号按累计处理字节数与总字节数之比来算，大图多占进度，小图少占进度，进度条会更接近线性。具体实现就是 run 方法开头先汇总一遍文件信息，把 total 从「文件个数」换成「总字节数」。这样改完，几百张图的进度刷新稳定了很多，至少用户能看出来程序在干活。

别把进度条当成可以省的装饰。对一个要处理大量文件的工具来说，进度反馈就是用户信任程序的入口。教程里经常只贴线程代码，不讲进度设计，实际产品里这一步反而最影响观感。做完这个优化再去考虑单线程还是多线程并行分配，才更划算。

5. 避坑清单：学 pyq 时最容易翻车的五个现场

下面五条是从这类课程资源的常见附赠问答里整理出来的，每一条都有真实的报错现场。把它们放在动手之前看一遍，能省下不少查资料的时间。

5.1 高分辨率屏幕上字小、控件间距乱

现象：在 2K 或 4K 屏幕上运行打包后的工具，字体特别小，按钮挤成一团。原因：PyQt5 默认没有适配高 DPI 缩放，Qt 不知道屏幕像素密度。解决：在 QApplication 创建之前设置高 DPI 属性：

from PyQt5.QtCore import Qt QApplication.setAttribute(Qt.AA_EnableHighDpiScaling, True)

这两行必须在 QApplication 实例创建之前执行，放模块顶部 import 之后最稳妥。有些人把它放进 MainWindow 的init，结果不生效，因为 QApplication 已经创建了，属性设置得太晚；这是最容易被忽略的顺序暗坑。只改一个属性就能解决，但如果先查布局参数，可能要白折腾半天。

5.2 打包后双击没有窗口

现象：打包时加了 --noconsole 隐藏控制台，在别的机器上双击，进程似乎起来了，但看不到窗口也没有报错。原因：控制台被隐藏，程序启动时抛出的异常没有地方显示，等于把错误信息藏起来了。解决：先去掉 --noconsole，打包后双击会弹出控制台，看到异常堆栈再修，能弹窗之后再隐藏控制台。如果控制台一闪而过，在入口最后临时加一个 input() 等待回车，把输出留在屏幕上。这类教训的核心不是打包参数，而是「先让错误可见再优化体验」。

5.3 线程里更新控件直接崩溃

现象：在 QThread 的 run 方法里执行 self.progress_label.setText("...")，有时候整个进程直接退出，有时候界面卡半天。原因：Qt 界面对象只能在主线程操作，工作线程碰控件属于未定义行为；更隐蔽的是多个线程同时改一个控件时的数据竞争，连信号都可能诡异消失。解决：把控件操作统一收进主线程侧的槽函数，工作线程只通过信号 emit 数据，不持有界面控件引用。基于这个原则，我在写每个 QThread 子类时都会强制检查 run 方法里有没有出现任何 setText、addItem 这类词汇，这是纸面自检里最有效的一条。

5.4 打包后提示找不到 Qt 平台插件

现象：打包后的可执行文件在另一台机器上运行，弹窗提示 Could not find the Qt platform plugin，或者把开发机的 Qt 路径打印出来。原因：PyInstaller 默认收集 PyQt5 模块时，可能漏掉 platforms 目录下对应平台的后缀是 dll 或 so 的动态库。解决：在确认 5.2 的控制台问题已经解决、程序能正常弹窗之后，用带 --collect-all 的打包命令收集完整模块：

pyinstaller --noconsole --name comp_tool main.py --collect-all PyQt5

--collect-all 会把模块相关的数据文件、动态库和子目录整体收进产物，打包体积会变大，但能换来平台插件不缺失。做完后在干净机器上测一次，别只在开发机上跑，因为开发机装过完整 Qt，缺文件时不容易暴露。如果 macOS 上打包后运行提示权限之类的问题，大多是产物本身权限位的问题，不影响代码逻辑，重新指定输出目录打包即可。

5.5 中文文字全部显示成方块

现象：Linux 环境下按钮上的中文变成一排空心方块，程序功能正常。原因：Qt 找不到可用的中文字体，不是编码问题，是系统字体配置里没有 fallback。解决：在应用启动时指定一个确实存在的字体，Windows 上常用 Microsoft YaHei，Linux 上检查是否有 Noto Sans CJK SC：

import sys from PyQt5.QtGui import QFont font_name = "Microsoft YaHei" if sys.platform == "win32" else "Noto Sans CJK SC" app.setFont(QFont(font_name))

还有个附加排查思路：如果字体指定正确仍是方块，检查源码文件是否真的以 utf-8 编码保存，Windows 上部分编辑器默认 gbk，会导致字符串字面量编码错乱，从根源上就是坏数据。

6. 进阶技巧：QSS 换肤、QSettings 记忆目录与 logging 接管调试输出

6.1 QSS：两行代码让界面脱离默认样式

工具跑通之后再考虑观感。PyQt 的样式表语法和 CSS 很像，作用域很直观：写在 app.setStyleSheet 里全局生效，写在单个控件的 setStyleSheet 里只对这个控件及其子控件生效。给按钮加圆角和主色：

app.setStyleSheet(""" QPushButton { background: #2d8cf0; color: white; border-radius: 4px; padding: 6px 12px; } QPushButton:hover { background: #1f6ed4; } """)

写 QSS 时注意选择器是控件类名，不是对象名；想针对某一个按钮单独设置，用#btnStart这样的对象选择器。这套语法适合做内部工具的快速改观，不需要引入额外资源文件。

6.2 QSettings：让工具记住上次打开的目录

内部工具使用频率高后，每次打开都从当前目录开始选文件很烦人。QSettings 按系统约定把配置写进 Windows 注册表或 macOS plist，不需要自己维护配置文件。用法很简单，key 名建议用 / 分段，不要用反斜杠：

settings = QSettings("某团队名", "CompTool") last_dir = settings.value("last_dir", os.getcwd()) settings.setValue("last_dir", current_dir)

这样前面文件对话框的初始目录参数就改成从 settings 读，退出时写回，用户不会觉得每次都从零开始。QSettings 对 null 值和空字符串有区分，业务代码里最好先判断 value 的结果是不是有效路径，再决定要不要使用。

6.3 logging：替代 print，线程输出不再打架

多个 QThread 同时回报进度时，print 输出的内容会交错混在一起，还分不清是哪条线程发的。改用 Python 自带 logging，时间戳加等级加消息，调试效率会提升一截：

import logging logging.basicConfig(level=logging.INFO, format="%(asctime)s %(threadName)s %(levelname)s %(message)s")

在 worker 类里取一个 logger 实例，emit 信号前打一条 info，主线程槽函数再打一条，线程的先后顺序一目了然。这套习惯帮我处理过一次偶现的进度卡顿，最后顺着日志发现是某次工作线程把异常吞了，信号没发出去，界面停在 99%。从那以后每次搭内部小工具，我都会强制走一遍流程：先建虚拟环境、再画主窗口骨架，最后才写业务函数；进度条一定挂在信号上，打包之前先不带 --noconsole 测一遍，写完加上 QSettings 和 logging 就算完整闭环。希望这几条经验能帮你在 pyq 实战里少走几趟弯路。

本文还有配套的精品资源，点击获取