PyQt QListView+ComboBox联动实现搜索过滤与导航功能

1. 项目概述与需求拆解

这个标题乍一看是个典型的小工具需求，但拆开来看，里面其实藏着三个互相咬合的功能点：ComboBox作为条件筛选入口，ListView作为数据展示区，再加上列表内导航和搜索。很多人拿到这种需求第一反应是直接用QListWidget凑合，或者干脆用QTableView套模型，但实际做下来会发现，QListView搭配自建模型才是这套逻辑里最顺手、也最不容易翻车的组合。

先说这个项目能解决什么问题：当你有一批结构化数据，比如一批文件、一批设备记录、一批订单号，需要让用户先选一个分类，再在分类内浏览明细，同时支持快速跳转到上一条、下一条，还能输入关键字过滤，那这个组合就是一套相当标准且可复用的 UI 方案。它适合以下几类人来参考：

• 刚接触 PyQt 不久，想把Model/View架构真正用顺手的开发者；
• 做桌面工具，需要频繁实现“筛选 + 列表 + 导航 + 搜索”这类交互的开发者；
• 接手老项目，发现代码里用了一堆QListWidget.addItem()导致数据耦合混乱、想重构的人。

我个人做过好几个类似的东西，比如文件清单筛选器、设备状态查看器，踩过不少坑，比如中文排序错乱、搜索联动卡顿、当前项高亮丢失等等。这篇文章会把从界面布局到核心逻辑再到坑位排查的完整过程都铺开讲，每段都配上可以直接抄的代码和解释。

2. 整体架构设计思路

2.1 为什么选 QListView + 自定义模型，而不是 QListWidget

这是整个方案里最核心的一个决策点。QListWidget用起来确实省事，把数据addItem进去就能显示，但问题在于你一旦需要动态切换 ComboBox 的数据源，或者做搜索过滤，就得反复清空、重填，数据一多还会闪屏，而且“当前选中哪条”“过滤后还剩哪条”这种状态完全要靠自己维护。说白了就是适合一次性展示的小场景，不适合做“数据源会变化”的中型界面。

QListView配合QAbstractListModel的思路则是把“数据”和“展示”分离。数据放在模型里，视图只管怎么画、怎么选。切换分类时只改模型内部的数据并beginResetModel()一下，视图会自动刷新；搜索时只对模型内部数据做过滤。这样逻辑边界清晰，也方便单元测试。

我的建议是：凡是 ComboBox 切换会引起列表内容整体变化、并且需要额外做搜索过滤的，一律用QListView + 自定义模型。如果只是固定几个条目展示给用户看、完全不涉及联动，那QListWidget就够了。

2.2 数据流向设计：从 ComboBox 到 ListView 再到搜索框

整套交互我习惯把它看成一条单向数据管道：

ComboBox 选择分类 ↓ 更新模型中的原始数据集 ↓ 按搜索关键字过滤 ↓ 刷新 ListView 显示 ↓ 导航按钮操作当前选中行

ComboBox 决定了“看哪一堆数据”，搜索框决定了“这一堆里的子集”，导航按钮负责在子集里移动。这个顺序很重要，很多人会把搜索和分类搞混，结果分类一变搜索框还留着旧词，过滤出来一堆不存在的东西。我自己的做法是：分类切换时清空搜索框，或者保留搜索词但强制重新过滤一遍，确保数据源的每个状态都是合法可解释的。

导航的“上一个 / 下一个”逻辑也要放在这个管道末端，只针对当前过滤结果操作，不是针对原始全量数据。否则列表里显示的是 10 条过滤结果，按“下一个”却跳到了全量数据里的第 11 条，用户当场就会觉得程序坏了。

2.3 视图模式下到底用哪种显示形态

QListView有几种视图模式：ListMode、IconMode、StaticMode。普通列表展示用默认的ListMode就行，每一行是一条数据，显示文字、缩略图都没有问题。

如果你需要显示两行文字，比如“文件名 + 更新时间”，那就不要自己拼字符串塞进一行，可以用setFlags结合Qt.ItemIsUserCheckable等方式扩展，更优雅的做法是自定义Qt.ItemDataRole.UserRole并重写data()方法，把结构化数据按角色返回给视图的委托（Delegate）。不过如果你只是做带副标题的列表，用QListView默认的setWordWrap加上自定义paint()逻辑太重了，直接上QListWidget配合setItemWidget反而更快。

所以这里有个经验：如果列表项只是一行文本，那QListView + 自定义模型的正规做法最稳妥；如果每项需要复杂布局（封面图 + 多行文字 + 按钮），直接用QListWidget + setItemWidget或写一个轻量QStyledItemDelegate更省事。本项目按标题描述，一行文本就够，所以走 Model/View 的路线。

3. 环境准备与界面骨架搭建

3.1 基础环境和依赖

我用的是 Python 3.10 + PyQt6，但代码兼容 PyQt5 和 PySide6，改动极小——主要是导入名和个别枚举的引用路径差异。

安装依赖只需要一个包：

pip install PyQt6

如果你还在用 PyQt5，就pip install Pyqt5，代码里把导入改成：

from PyQt6.QtCore import Qt, QAbstractListModel, QModelIndex from PyQt6.QtGui import QIcon from PyQt6.QtWidgets import QMainWindow, QWidget, QVBoxLayout, QHBoxLayout, QComboBox, QListView, QLineEdit, QPushButton, QApplication

PyQt5 则去掉QtCore、QtGui、QtWidgets里的Qt6前缀即可。下面统一按 PyQt6 写。

3.2 主窗口布局设计

界面结构是典型的“上中下”三段式：

• 顶部：分类选择（ComboBox）、搜索框（QLineEdit）
• 中部：列表展示（QListView）
• 底部：导航按钮（上一个 / 下一个）+ 当前定位信息

我习惯把顶部和底部用独立的QHBoxLayout包起来，布局代码逻辑清楚，以后加按钮也方便。

class MainWindow(QMainWindow): def __init__(self): super().__init__() self.setWindowTitle("ComboBox + ListView 联动示例") self.resize(480, 480) central = QWidget() self.setCentralWidget(central) root = QVBoxLayout(central) # 顶部：分类 + 搜索 top_bar = QHBoxLayout() self.combo = QComboBox() self.search_edit = QLineEdit() self.search_edit.setPlaceholderText("输入关键字过滤...") self.search_edit.setClearButtonEnabled(True) top_bar.addWidget(self.combo) top_bar.addWidget(self.search_edit) root.addLayout(top_bar) # 中部：列表 self.list_view = QListView() self.list_view.setSelectionMode(QListView.SelectionMode.SingleSelection) self.list_view.setEditTriggers(QListView.EditTrigger.NoEditTriggers) root.addWidget(self.list_view, stretch=1) # 底部：导航 bottom_bar = QHBoxLayout() self.btn_prev = QPushButton("上一个") self.btn_next = QPushButton("下一个") self.label_pos = QLabel("0 / 0") bottom_bar.addWidget(self.btn_prev) bottom_bar.addWidget(self.btn_next) bottom_bar.addStretch(1) bottom_bar.addWidget(self.label_pos) root.addLayout(bottom_bar) self._init_data() self._init_model() self._bind_signals()

这几行代码里有两个细节容易忽略。第一个是setEditTriggers(NoEditTriggers)，否则用户双击列表项会进入编辑状态，而我们的模型默认是只读数据，编辑会触发一堆多余的校验逻辑。第二个是setClearButtonEnabled(True)，搜索框带个小叉子，用户不用键盘删字符也可以一键清空，桌面工具很实用。

3.3 数据初始化与模型绑定

在这个示例里，我用一个字典模拟数据源：key 是分类名，value 是对应的条目列表。真实项目里可能是从数据库、文件系统或者接口拿数据。

def _init_data(self): self.data_source = { "文件": ["report_01.pdf", "report_02.pdf", "photo_01.jpg", "photo_02.jpg"], "任务": ["task_A", "task_B", "task_C", "task_D"], "设备": ["device_alpha", "device_beta", "device_gamma"], }

然后创建自建的列表模型，绑定到QListView。

def _init_model(self): self.model = StringListModel() self.list_view.setModel(self.model) self.combo.addItems(self.data_source.keys()) self.combo.setCurrentIndex(0) self._load_category(0)

这里有个顺序问题：先setModel再往combo里加数据，这样首次加载时已经保证列表模型存在，后续信号回调可以直接操作模型。如果顺序反了，回调里self.model还没创建，会直接AttributeError。

_load_category是我们核心联动逻辑的入口，后面单独章节讲。

4. 核心模块实现：ComboBox 联动数据源

4.1 自建 ListModel 类的数据角色设计

QAbstractListModel的核心是rowCount()和data()两个方法。我们用一个 Python 列表存数据，条目本身就是字符串，但在data()方法里，同时要返回DisplayRole和UserRole两套数据。DisplayRole决定界面上显示的文字，UserRole则预留出来存 id、路径、数据库主键一类不直接展示的后台数据。

class StringListModel(QAbstractListModel): def __init__(self, data=None): super().__init__() self._items = data or [] def rowCount(self, parent=QModelIndex()): return 0 if parent.isValid() else len(self._items) def data(self, index, role=Qt.ItemDataRole.DisplayRole): if not index.isValid(): return None if index.row() < 0 or index.row() >= len(self._items): return None item = self._items[index.row()] if role == Qt.ItemDataRole.DisplayRole: return str(item) if role == Qt.ItemDataRole.UserRole: return item return None def reset_items(self, new_items): self.beginResetModel() self._items = new_items self.endResetModel()

几个实现要点：

• beginResetModel()和endResetModel()是成对出现的，用来通知视图“整个数据源变了，全部重新画”。如果你直接改_items而不调用这两个函数，视图不会刷新，这是初学者最容易犯的错。
• rowCount里判断parent.isValid()是标准写法。对于一维列表模型，任何有效 parent 都说明上层还有结构，子行数量就应为 0。
• data()方法对非法 index 要宽容，返回None而不是抛异常，视图在重绘时会频繁查询各种角色，路径上任何一个角色抛错都可能让界面直接崩溃。

实际开发里，如果条目内容要支持排序或更复杂状态，可以把列表里存成小对象或字典，然后data()里按角色解析字段，但本项目一行文本已经足够。

4.2 ComboBox 切换分类的完整流程

当用户在 ComboBox 里选了一个新分类，调用链是：

def _load_category(self, index): key = self.combo.itemText(index) raw_items = self.data_source.get(key, []) self.current_raw = raw_items[:] keyword = self.search_edit.text().strip() if keyword: filtered = [item for item in raw_items if keyword in str(item)] else: filtered = raw_items[:] self.model.reset_items(filtered) self._update_current_label()

这段逻辑把“分类加载”和“搜索过滤”合在了一起。每次分类切换必定触发，每次搜索输入的信号也触发。这里我用了一次浅拷贝raw_items[:]，目的是防止后续过滤、导航逻辑直接改动数据源本体。Hack 一点说，如果是大量数据（几万条），拷贝成本也可以接受，但如果你在乎内存，就改成只存引用，过滤时生成新列表即可。

ComboBox 槽函数连接方式：

def _bind_signals(self): self.combo.currentIndexChanged.connect(self._load_category) self.search_edit.textChanged.connect(self._on_search_text_changed) self.btn_prev.clicked.connect(self._go_prev) self.btn_next.clicked.connect(self._go_next) self.list_view.selectionModel().currentChanged.connect(self._on_current_row_changed)

_load_category直接接收currentIndexChanged发来的整数索引，所以函数签名里有一个index参数。如果你更习惯用文本触发，也可以换成currentTextChanged，函数接收 str，内部再用文本找索引。两种都行，个人推荐 item 方式，万一数据源里有两个分类同名，用索引不会歧义。

4.3 搜索框与分类的联动细节

搜索不改变原始分类数据，只是在原始列表上过滤。这里我保持了原列表的顺序，用 Python 的in做模糊匹配，不区分大小写的问题要做的话，就统一转成lower()再比。

def _on_search_text_changed(self, text): keyword = text.strip() raw_items = self.current_raw[:] if keyword: filtered = [item for item in raw_items if keyword.lower() in str(item).lower()] else: filtered = raw_items self.model.reset_items(filtered) self._update_current_label()

这里我特意从self.current_raw取原始数据，而不是从self.model._items里再过滤，否则多次过滤时上一次的关键字会污染本次结果。这个细节值得强调，我见过有人写搜索时从当前视图内容里反复筛，结果越筛越少，最后列表空掉还得清空搜索框才能恢复。

5. 导航功能与选中状态管理

5.1 上一条 / 下一条按钮的可靠实现

有了模型后，按钮的逻辑并不复杂，核心是拿到当前选中的行号，加减一，再让视图定位到新行。

def _go_prev(self): current_index = self.list_view.currentIndex() if not current_index.isValid(): row = 0 else: row = current_index.row() - 1 if row >= 0: target = self.model.index(row, 0) self.list_view.setCurrentIndex(target) self.list_view.scrollTo(target) def _go_next(self): current_index = self.list_view.currentIndex() if not current_index.isValid(): row = 0 else: row = current_index.row() + 1 if row < self.model.rowCount(): target = self.model.index(row, 0) self.list_view.setCurrentIndex(target) self.list_view.scrollTo(target)

两个细节：

• 如果没有任何选中项，currentIndex()是非法 index，isValid()返回 False，此时点击“下一个”应该跳到第一行，而不是直接执行row + 1导致负数。
• scrollTo(target)保证目标行即使在视图可视范围之外，也会滚动到可见区域。如果列表只有五六项，滚动效果看不出来；但数据有几百条时，没有这行用户会以为按钮点了没反应。

另外按钮禁用状态的联动也可以做，但一般不建议在按钮上做严格禁用，因为用户点了边界按钮时你只要静默不做任何事就行。禁用逻辑做多了反而要在每次数据变化时重算边界，容易遗漏状态。

5.2 当前位置信息的实时刷新

列表底部我放了一个QLabel，显示“当前行 / 总行数”，类似“2 / 8”这种。这个标签的刷新点有两处：

• 模型数据变化（分类切换或搜索过滤）后；
• 当前选中行变化后。

def _update_current_label(self): total = self.model.rowCount() current_index = self.list_view.currentIndex() row = current_index.row() + 1 if current_index.isValid() else 0 self.label_pos.setText(f"{row} / {total}")

currentChanged信号会把新 index 和旧 index 都传过来，我只需要新 index，所以槽函数签名里只写一个参数也没问题：

def _on_current_row_changed(self, current, _previous): self._update_current_label()

这里注意，currentChanged是selectionModel()发出的信号，不是 QListView 自己的。如果你直接self.list_view.currentIndexChanged，Qt 里并没有这个信号，会报错。

5.3 数据更新后选中行的正确处理

数据更新（reset）之后，视图的选中状态会丢失。如果不做处理，用户可能看到列表里没有任何一项高亮，导航功能也会从“无选中”状态重新开始。我习惯在模型 reset 之后立刻选中第一行，这样用户不用每次都手动点。

在_load_category和_on_search_text_changed里，最后加一句：

self._select_first_row_if_any()

def _select_first_row_if_any(self): if self.model.rowCount() > 0: first = self.model.index(0, 0) self.list_view.setCurrentIndex(first) else: self.list_view.clearSelection()

这个行为的体验差异很大。试想搜索关键字后命中第一行自动高亮，用户直接按“下一个”就能连续浏览命中项，效率高不少。不自动高亮的话，用户还得先点一下才能导航，多了一步操作。

这里的小技巧是setCurrentIndex会自动更新 selectionModel 的 currentChanged，从而刷新标签。如果你手动setCurrentIndex后又想额外做点什么，可以直接在 setCurrentIndex 前手动调用更新函数，避免依赖信号时机问题。

6. 搜索逻辑的细节与边界情况

6.1 关键字匹配策略选择

示例里的搜索用了最简单的子串包含匹配。真实项目里你可能需要根据场景升级：

• 忽略大小写：直接.lower()转换后再比；
• 多字段匹配：列表项如果是一个字典，就把标题、描述、标签字段拼成一个大字符串再匹配；
• 正则表达式：用re.search代替in，支持模糊、通配；(但注意 Python 的re并不适合非正则用户输入，建议先做转义)
• 多关键字 AND/OR：把关键字按空格拆开，逐个匹配。

如果需求要的是“不区分大小写 + 多字段”，示例的匹配部分改成：

def _filter_items(self, raw_items, keyword): if not keyword: return raw_items[:] kw = keyword.lower() result = [] for item in raw_items: if isinstance(item, dict): haystack = " ".join(str(v) for v in item.values()).lower() else: haystack = str(item).lower() if kw in haystack: result.append(item) return result

这里没有用列表推导式，是为了方便后续扩展字段白名单。真要追求性能，数据量大时可以用filter()配合生成器，但通常桌面工具里几千条数据in操作已经随手就出结果了，性能瓶颈不在这里。

6.2 空数据与无结果的界面反馈

搜索关键字命不中任何记录时，模型里_items为空，视图显示空白区域，用户其实不太明白发生了什么。我实践下来效果比较好的做法是：在空结果时禁用导航按钮并设置占位文本。

def _update_ui_state(self): has_items = self.model.rowCount() > 0 self.btn_prev.setEnabled(has_items) self.btn_next.setEnabled(has_items) self.label_pos.setText("0 / 0" if not has_items else self.label_pos.text())

或者更彻底一些，直接用代理在空白区域画一行提示文字“没有匹配的记录”。不过那种做法会增加代码量，而且新手理解起来费劲。普通工具里用“列表置灰 + 标签显示 0/0”已经足够清晰了。

6.3 防抖与性能考量

PyQt 的textChanged信号在用户每敲一个字符时都会触发。如果列表数据有几千条且每条都有一段较长的文本，每次全量重新过滤和 reset 会有轻微卡顿。但大多数桌面工具场景下这不算问题。如果你真的遇到卡顿，可以：

1. 把搜索过滤放到QTimer单次触发中，做 150ms 左右防抖；
2. 不在textChanged里做 all-item 匹配，而是维护一个按关键字分组的索引；
3. 用QSortFilterProxyModel代替手动过滤，让模型层自己做过滤。

临时加个防抖非常简单：

self.search_timer = QTimer(self) self.search_timer.setSingleShot(True) self.search_timer.setInterval(150) self.search_timer.timeout.connect(self._apply_search) self.search_edit.textChanged.connect(lambda: self.search_timer.start())

_apply_search就是前面_on_search_text_changed的核心逻辑。这样连续输入时只会在停顿 150ms 后过滤一次，手感会流畅很多。缺点是实现又多了一个 QTimer 对象，如果你不太喜欢这种有点绕的写法，手动调用也完全没问题。

7. 常见问题与排查技巧实录

7.1 数据更新后 ListView 不刷新

这是最经典的坑：修改了模型内部列表，但没有调用beginResetModel/endResetModel，视图完全无感知。排查思路很简单，在reset_items里加print或者断点看是否执行到和是否真的置换了列表对象。有一种情况是你在模型外直接model._items = xxx，这在面向对象习惯下不太容易犯，但用setModel后不经过自定义方法而是直接换内部变量时很容易踩。所以我把_items的写入封装成reset_items一个入口，这样想绕过也绕不了。

7.2 导航按钮点击后视图不跟随滚动

如果你用了setCurrentIndex却忘记scrollTo，当目标行还在视野内时看起来正常，一旦目标行在视野外，用户以为按钮失效。排查可以先手动把模型里塞 100 条数据，选中一行后不停地按“下一个”，观察行是否是连续变化的，同时看视图是否自动跟随。解决方案就是在_go_prev/_go_next里都加上scrollTo(target)。

7.3 搜索框输入后 ComboBox 分类切换，搜索词残留

默认情况下 ComboBox 切换分类不会清空搜索框。如果你的产品预期是“切换分类后重新开始浏览”，我建议在_load_category里主动self.search_edit.clear()。注意clear()会触发textChanged，而textChanged又会调用_apply_search，形成一次多余的过滤。这种“信号连锁”是 PyQt 里很常见的烦恼。规避做法是加一个self._is_switch_category = True标志位，或者在_apply_search里判断当前 keyword 为空时直接使用当前分类的原始数据，不影响最终结果，也就无所谓多刷一次了。

示例里的逻辑其实已经天然兼容这种连锁：分类切换时_load_category用空搜索词加载原分类数据，紧接着textChanged触发搜索过滤，keyword 为空时仍返回原始数据，所以 UI 不会出问题。真正需要警惕的是搜索框有内容时切换分类：此时_load_category执行时会带上当前搜索词完成过滤，最终展示的是新分类下匹配该词的结果。这个行为是否合理取决于产品定义。如果要求“切换分类忽略搜索词”，就主动清空搜索框；如果要求“切换分类继续在当前词下过滤”，现在的逻辑就直接满足。

7.4 中文与路径中的特殊字符匹配异常

如果列表里是文件路径，用户输入反斜杠或盘符，直接用in匹配没有问题。但如果你加入了re匹配则要小心，比如搜索.会被当成任意字符通配。对策是在正则前加re.escape(keyword)。还有中文大小写、全半角问题，如果搜“abc”期望同时匹配“ABC”，就用.lower()；如果用户输入全角的“ＡＢＣ”，这种边界情况通常不处理，因为成本高收益低，真正的桌面工具里没人会这么搜。

7.5 空列表时执行操作的异常

_go_next里如果模型行数为 0，row < self.model.rowCount()为 False，代码会安全跳过。但_go_prev里row >= 0的判断同样能兜底。不过如果列表为空且你调用了self.model.index(0,0)，返回的 index 是isValid = False的，紧接着setCurrentIndex传入非法 index 不会报错但是没有任何效果。所以最安全的做法还是像_select_first_row_if_any那样，先判断行数再操作。

7.6 常见问题速查表

这些坑我基本都踩过一遍，尤其第一条和第二条，每次写新的列表逻辑都会下意识检查。宁可多用beginResetModel两次，也不要少用导致界面“看起来没坏”但实际数据早就错位。

8. 扩展思路与优化方向

8.1 用 QSortFilterProxyModel 替代手动过滤

如果你希望搜索过滤逻辑和视图更新更规范，可以引入QSortFilterProxyModel。它位于模型和视图之间，能动态过滤而不改动原始模型，也会自动维护行号映射。核心步骤：

self.source_model = StringListModel() self.proxy_model = QSortFilterProxyModel(self) self.proxy_model.setSourceModel(self.source_model) self.list_view.setModel(self.proxy_model)

然后重写filterAcceptsRow判断关键字是否命中：

class SearchProxyModel(QSortFilterProxyModel): def __init__(self): super().__init__() self.keyword = "" def set_keyword(self, text): self.keyword = text.strip().lower() self.invalidateFilter() def filterAcceptsRow(self, source_row, source_parent): if not self.keyword: return True idx = self.sourceModel().index(source_row, 0, source_parent) data = self.sourceModel().data(idx, Qt.ItemDataRole.DisplayRole) return self.keyword in str(data).lower()

这时候导航的行号是代理模型里的行号，需要把proxy_model.mapToSource或mapFromSource处理好才能回传原始数据，也是另一个容易绕晕的点。如果你只是想快速完成项目，手动过滤完全够用；如果项目后续会加排序、分组、多级联动，那 ProxyModel 是更划算的投资。

8.2 支持多列与更多展示信息

如果后续想升级成多列，QListView就不太合适了，直接换QTableView，模型增加columnCount()并返回多列数据。UI 布局逻辑、搜索、导航几乎可以全部复用，只需要把视图类换掉并调整 data() 中的列判断。ComboBox + 表格 + 搜索导航的组合在管理类工具里出现频率很高，提前规划好 Model/View 架构会省很多事。

8.3 归纳一下这套骨架的复用场景

• 设备管理工具：左侧分类（在线/离线/告警），右侧设备列表，搜索框过滤，上下键逐条查看；
• 文件备份工具：选择备份任务分类，文件列表内搜索过滤，逐个查看大小、时间等信息；
• 订单管理工具：按订单状态分类，订单号列表搜索，上一个 / 下一个逐条核对；
• 日志查看器：按日志级别筛选，日志内容列表检索，前后翻阅上下文。

只要符合“一个筛选 + 一个列表 + 逐条浏览”的交互模式，这套代码几乎可以直接抄走改数据源。

9. 个人实操心得与建议

最后说几句肺腑之言。PyQt 的 Model/View 架构第一次接触确实觉得绕，文档又抽象，示例代码老是展示什么自定义按钮、自定义背景，看着吓人。但实际做下来，掌握QAbstractListModel的rowCount+data+reset_items三件套，70% 的列表场景都能覆盖了。不要被“自定义模型”四个字吓到，它其实就是告诉视图“你有多少行，每一行显示什么”，其余交给 Qt。

另外，界面交互设计的顺序感非常重要。ComboBox 和搜索框谁在前谁在后、搜索是否联动清空、导航按钮是否要禁用，这些决定了一个工具用起来顺不顺手。我见过功能完整但交互别扭的项目，问题往往不在代码而在“用户脑中的模型”和“程序脑中的模型”不一致。写代码前可以先画一遍实际操作流程，想想用户在什么场景下会先点分类、再输关键字，还是先搜一下再切分类，然后再定逻辑。

这个项目如果你继续往下扩展，我建议下一步就去研究QStyledItemDelegate，给列表项加自定义样式、进度条、状态图标。那才是 QListView 真正拉开差距的地方。至于 ComboBox 联动和搜索导航，到这里已经接近最优解了——模型负责数据，视图负责展示，按钮只操作模型接口，各司其职，后续维护和加需求都会轻松很多。