如何让QCompleter在工作线程运行解决大数据量主线程卡顿问题

首先明确两个核心事实：

• QCompleter是和行编辑弹窗绑定的UI类，按照Qt的线程模型规范，所有UI组件都必须运行在主线程，根本没法整体部署到工作线程
• setMaxVisibleItems仅控制弹窗的显示行数，不会在匹配阶段做剪枝，不管你设成多少，QCompleter默认都会跑完全量6万条的匹配流程，这就是你感知到卡顿的根源

不用加线程的快速优化（改两行代码就能见效） #

你当前已经给QCompleter设置了CaseSensitivelySortedModel，这个配置本来是配合排序好的数据集用二分查找替代线性遍历的，只要补一个配置就能把性能拉上来：

• 调用completer.setFilterMode(QtCore.Qt.MatchStartsWith)改成前缀匹配模式。配合已排序的数据集，二分查找的复杂度是O(log n)，哪怕几十万条数据也不会卡主线程
• 如果确实需要支持任意位置的子串匹配，这套就不够用，需要换自定义模型做匹配剪枝

自定义模型实现“匹配阶段就固定截断结果数量” #

这是最贴合你需求的实现，不需要动QCompleter本身的逻辑：

• 写一个继承QAbstractListModel的自定义列表模型，内部存全量的已排序原始数据集
• 模型内部维护一个临时的匹配结果缓存列表，每次收到匹配更新请求时，遍历数据集找匹配项，一旦收集够你设定的固定数量（比如100条）就立刻终止遍历，绝不扫完全量
• 模型对外暴露的rowCount接口直接返回缓存的匹配结果长度，不要返回全量6万条的总数。QCompleter拿到的永远是已经截断好的短列表，根本不会触发全量匹配的开销

匹配流程挪到工作线程的正确姿势 #

如果自定义模型的计算量还是太大，完全可以把纯逻辑的匹配计算丢到工作线程，注意绝对不能碰QCompleter实例：

• 给QLineEdit的输入加300ms防抖，避免用户每敲一个字就触发一次搜索
• 把当前输入的关键词、全量数据集丢到你已经封装好的QRunnable工作线程，在线程内完成匹配、按固定数量截断结果的计算
• 子线程算完结果后通过信号把列表传回主线程，直接更新自定义模型的缓存数据，刷新QCompleter的弹窗
• 子线程全程不要实例化、调用任何带UI依赖的类，只做纯数据计算，完全符合Qt的线程规范

启动阶段的额外优化 #

你当前代码在主窗口初始化时同步读CSV、排序6万条数据，这部分本身就会造成启动冻结：把文件读取、数据排序的步骤整体丢到启动阶段的工作线程，等数据加载完成后再回主线程初始化QCompleter，从根源上消除启动时的主线程阻塞。

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