Qt自定义菜单项实战：QWidgetAction嵌入与QSS美化-平芜编程栈

最近在做一个Qt桌面小工具的时候，被"自定义菜单项"这事来回折腾了好几轮。需求其实很朴素：托盘右键菜单里要显示最近打开的文件列表，每个文件带大小、修改时间；某个管理菜单里要放一个网络状态指示器，前面是绿色/红色小圆点；还有一处需要把预览缩略图直接嵌进"最近浏览"菜单。用Qt默认的QMenu加QAction做出来后，效果怎么说呢——能用，但丑，而且信息密度一高就觉得不对劲。

于是我把这块系统地梳理了一遍，从QWidgetAction嵌入到自绘QWidget，从信号时序到右键菜单，从QSS美化到工程里的编译坑，都踩了一遍。这篇文章就当作Qt菜单系列里关于自定义菜单项的实操记录，适合已经把QMenu、QAction、addMenu这些基础玩法搞熟、想进一步做"非常规菜单项"的人看。

1. 先搞清楚：默认QMenu/QAction的边界到底在哪

很多人一上来就写代码，结果做了一半发现QAction根本满足不了需求，又回头推翻重来。我建议先花十分钟把默认组件的边界摸清楚，这能省下后面大量返工时间。

1.1 QAction自带的能力清单

默认情况下，一个QAction能控制的属性相当多：图标、文本、快捷键显示、勾选状态、禁用态、tooltip、data自定义数据。这些在普通下拉菜单、右键菜单里基本够用。比如你要做"字体大小"菜单，12px、14px、16px三项，每项前面加个小圆点图标、右侧显示快捷键，直接用QAction就能搞定。

QAction *act = new QAction(QIcon(":/icons/font.png"), "12px", this); act->setCheckable(true); act->setShortcut(QKeySequence("Ctrl+1")); act->setShortcutVisibleInContextMenu(true); act->setData(12); menu->addAction(act);

真正的问题出在下面几种需求上：

菜单项里要同时显示"文件路径 + 文件大小 + 修改时间"，一行塞不下，默认QAction只有单行文本布局。
菜单项里要放进度条、开关按钮、输入框，QAction无能为力。
菜单项要高亮显示匹配关键词的文本片段，默认文本绘制不支持富文本。
菜单宽度想固定，但 Qt 默认会根据内容自适应宽度，某些场景下会忽宽忽窄。

1.2 视觉边界和交互边界

视觉边界：默认菜单项的高度通常由字体和图标决定，可调空间很小。虽然可以用setStyleSheet里给QMenu::item设置height，但图标和文本的对齐关系、padding、hover底色这些细节，在复杂内容下很难只看样式表控制。

交互边界：默认菜单项不支持内部嵌套交互。我举个例子，你要在菜单里放一个"音量滑块"，用户可以在菜单弹出时直接拖滑块调整音量。QAction做不到，只能靠QWidgetAction塞一个QSlider进去。类似的还有"颜色选择器""搜索框""最近文件多选列表"。

所以我在项目里会先把需求分类：纯文本、单一图标、勾选状态、快捷键提示这种规规矩矩的需求，一律用QAction解决；凡是需要"菜单项内部有多个控件交互"，或者"信息密度远超一行文字"，才考虑自定义。

2. 做一个信息密集型收件箱菜单：QWidgetAction嵌入方案实战

自定义菜单项的两条主流路线，一条是QWidgetAction，另一条是继承QWidget后自己paintEvent。这两条路线各自能解决什么问题，先看实战再谈选型。

2.1 用QWidgetAction嵌入自定义控件

我实际做的是个"最近文件"菜单，每个文件要显示图标、文件名、路径、大小、修改时间五个信息。直接用QAction的文本肯定塞不下，所以自定义了一个FileItemWidget：

class FileItemWidget : public QWidget { Q_OBJECT public: explicit FileItemWidget(const FileInfo &info, QWidget *parent = nullptr) : QWidget(parent), m_info(info) { setFixedHeight(56); setCursor(Qt::PointingHandCursor); } QSize sizeHint() const override { return QSize(360, 56); } protected: void paintEvent(QPaintEvent *) override { QPainter p(this); p.setRenderHint(QPainter::Antialiasing); QRectF iconRect(12, 10, 36, 36); p.drawPixmap(iconRect.toRect(), loadIcon(m_info.suffix)); QFont nameFont = font(); nameFont.setPointSize(10); nameFont.setBold(true); p.setFont(nameFont); p.setPen(QColor("#222222")); p.drawText(QRect(58, 8, width() - 140, 20), Qt::AlignLeft | Qt::AlignVCenter, m_info.fileName); QFont subFont = font(); subFont.setPointSize(8); p.setFont(subFont); p.setPen(QColor("#888888")); p.drawText(QRect(58, 28, width() - 140, 18), Qt::AlignLeft | Qt::AlignVCenter, QString("%1 大小:%2 修改:%3") .arg(m_info.filePath) .arg(formatSize(m_info.size)) .arg(m_info.modTime.toString("yyyy-MM-dd HH:mm"))); } private: FileInfo m_info; };

然后自定义一个QWidgetAction，通过createWidget创建这个控件：

class FileItemAction : public QWidgetAction { Q_OBJECT public: explicit FileItemAction(const FileInfo &info, QWidget *parent = nullptr) : QWidgetAction(parent), m_info(info) {} protected: QWidget *createWidget(QWidget *parent) override { FileItemWidget *w = new FileItemWidget(m_info, parent); w->setObjectName("fileMenuItem"); return w; } };

在构造菜单时把这些 action 加进去：

QMenu menu(this); for (const FileInfo &info : recentFiles) { FileItemAction *act = new FileItemAction(info, &menu); connect(act, &QAction::triggered, this, [this, info]() { openFile(info.filePath); }); menu.addAction(act); } menu.exec(QCursor::pos());

这里有个关键点要注意：QWidgetAction::createWidget返回的 widget 默认作为菜单的子控件存在，但触发信号的机制是QAction::triggered。如果你在FileItemWidget里自己发了clicked信号，也要手动调用trigger()，不然菜单关闭和动作触发是脱节的。我在第一次做的时候只连了clicked，结果菜单关闭了但文件没有打开，排查了半天才发现QAction的 triggered 根本没发射。

2.2 用自绘QWidget做高度定制项

如果菜单项不只是一行信息展示，而是需要响应用户在菜单里的复杂操作，更推荐直接做一个独立的QWidget，把它放进菜单容器。我还做过一个"颜色方案选择"菜单，每个选择项是一块渐变色带加说明文字，用户点色带就选中，点说明文字则弹出详细配置窗口。

class ColorSchemeItem : public QWidget { Q_OBJECT public: explicit ColorSchemeItem(const QString &name, const QColor &c1, const QColor &c2, QWidget *parent = nullptr) : QWidget(parent), m_name(name), m_c1(c1), m_c2(c2) { setFixedHeight(64); setMouseTracking(true); } signals: void activated(); void detailRequested(); protected: void paintEvent(QPaintEvent *) override { QPainter p(this); QLinearGradient grad(0, 0, width(), 0); grad.setColorAt(0, m_c1); grad.setColorAt(1, m_c2); QRect colorRect(12, 12, width() - 110, 40); p.setPen(Qt::NoPen); p.setBrush(grad); p.drawRoundedRect(colorRect, 6, 6); p.setPen(QColor("#333333")); p.setFont(QFont("Microsoft YaHei", 9)); p.drawText(QRect(width() - 90, 12, 80, 40), Qt::AlignLeft | Qt::AlignVCenter, m_name); } void mouseReleaseEvent(QMouseEvent *event) override { if (event->pos().x() < width() - 100) emit activated(); else emit detailRequested(); } };

然后把多个ColorSchemeItem实例放进同一个QWidget，通过QWidgetAction一次性加入菜单：

QWidget container; QVBoxLayout *layout = new QVBoxLayout(&container); layout->setContentsMargins(4, 4, 4, 4); layout->setSpacing(4); ColorSchemeItem *item1 = new ColorSchemeItem("日出", QColor("#f6d365"), QColor("#fda085")); ColorSchemeItem *item2 = new ColorSchemeItem("深海", QColor("#2b5876"), QColor("#4e4376")); connect(item1, &ColorSchemeItem::activated, this, &MainWindow::applySunrise); connect(item2, &ColorSchemeItem::activated, this, &MainWindow::applyDeepSea); layout->addWidget(item1); layout->addWidget(item2); QWidgetAction *action = new QWidgetAction(&menu); action->setDefaultWidget(&container); menu.addAction(action);

这个方案的好处是，容器里的控件布局完全由自己控制，所有事件自己处理。缺点是菜单关闭方式的坑更多——用户在色带区域点了一下，菜单不会像普通QAction那样自动收起，需要手动调用menu.close()。

2.3 两条路线的选型判断

我自己用的判断标准很简单：

菜单项是一次性展示信息，用户点一下就执行命令——QWidgetAction包一个绘制好的QWidget就够了，信号靠triggered触发。
菜单项内部包含多个可交互区域（点这里是一个功能，点那里是另一个功能），或者需要实时刷新、拖拽、滚动——优先用"容器 + 多个子控件"的自绘方案，但一定要处理好菜单关闭时机。
如果只是改个背景色、加个边框、改hover样式——不要自定义组件，用QSS就行，成本最低。

3. 点击、悬停、关闭的信号时序与状态同步坑

自定义菜单项最让人难受的地方不是画出来，而是它的信号时序和状态同步。

3.1 信号发射顺序带来的逻辑错位

普通QAction点击时信号顺序比较明确：鼠标按下释放后，QAction::triggered被发射，随后QMenu关闭。但自己放进去的 widget 不是这个逻辑。以FileItemAction为例，用户点击FileItemWidget，先触发 widget 自身的mouseReleaseEvent，如果我在里面写了emit clicked()又不做任何转换，QAction::triggered根本没有信号来源路径，菜单倒是会因为鼠标事件关闭了，但动作没执行。

正确的做法是在自定义 widget 内部统一把"用户点击交互"翻译成QAction的动作语义，二选一即可：

// 方式一：在自定义控件里直接触发 action connect(this, &FileItemWidget::clicked, action, &QAction::trigger); // 方式二：在外部把 widget 的信号转成 action 的触发 connect(fileWidget, &FileItemWidget::clicked, [action]() { action->trigger(); });

我建议用方式一，因为信号链路短，排查问题更容易。

3.2 悬停样式与禁用状态不能各自为政

默认QAction的 hover 效果由菜单样式控制，鼠标悬浮时菜单项背景变蓝、文本变白。但自定义 widget 不会自动获得这套视觉效果，所以刚做出来的自定义菜单项，鼠标悬上去和平时长得一模一样，用户会一脸懵。

我在实际项目里让FileItemWidget自己支持 hover 状态：

// 构造时开启 hover 事件 setAttribute(Qt::WA_Hover, true); // 重写 paintEvent，在绘制时读取状态 if (underMouse() && isEnabled()) { painter.fillRect(rect(), QColor(0, 120, 215, 40)); }

禁用状态同理。QAction的 disabled 属性并不会自动传导到自定义 widget，所以需要在FileItemAction里做一次联动：

class FileItemAction : public QWidgetAction { public: using QWidgetAction::QWidgetAction; protected: QWidget *createWidget(QWidget *parent) override { FileItemWidget *w = new FileItemWidget(m_info, parent); // 初始同步一次 w->setEnabled(isEnabled()); // 后续 action 状态变化时同步 connect(this, &QWidgetAction::changed, w, [w, this]() { w->setEnabled(isEnabled()); w->update(); }); return w; } };

这里有个细节：QAction::changed在属性变化时通知，但接收对象是w，如果w在菜单关闭后被销毁，connect 要确保上下文生命周期正确。用connect(this, &QAction::changed, w, lambda)时，w作为 context 对象，会在w销毁时自动断开，安全性没问题。

3.3 让菜单在"执行中"保持弹出

有些操作需要给用户即时反馈，比如点击"同步"菜单项后先显示"同步中..."，同步完成后再关闭菜单并提示结果。默认行为是点击一下就收起菜单，这不符合需求。

可以用QMenu::close和QTimer控制关闭时机：

// 自定义控件里的某个按钮点击后 connect(btnSync, &QPushButton::clicked, this, [this, menu]() { labelStatus->setText("同步中..."); labelStatus->setStyleSheet("color: #ff8800;"); // 1.5秒后关闭菜单 QTimer::singleShot(1500, menu, [menu]() { menu->close(); }); });

注意menu->close()只关闭菜单，不会触发QAction::triggered，所以业务动作要在这个 lambda 里自己触发。如果操作被取消了，只要在倒计时前把定时器停掉即可。

4. 长菜单、右键菜单和全局快捷键：菜单系统的组合拳

自定义菜单项很少单独出现，基本都是跟右键菜单、菜单栏、工具栏混在一起使用。这一节讲几个实战组合。

4.1 动态构建菜单时的组织技巧

比如做一个"最近打开项目"菜单，项目数量不固定，多了要分组、要有"清空历史"入口。我的做法是每次aboutToShow时重建菜单内容：

QMenu *recentMenu = new QMenu("最近项目", this); connect(recentMenu, &QMenu::aboutToShow, this, [this, recentMenu]() { recentMenu->clear(); const QStringList projects = loadRecentProjects(); if (projects.isEmpty()) { QAction *emptyAct = recentMenu->addAction("暂无历史项目"); emptyAct->setEnabled(false); return; } for (int i = 0; i < projects.size(); ++i) { QAction *act = recentMenu->addAction(projectDisplayName(projects.at(i))); act->setData(projects.at(i)); act->setShortcut(QKeySequence(QString("Ctrl+%1").arg(i + 1))); connect(act, &QAction::triggered, this, &MainWindow::openRecentProject); } recentMenu->addSeparator(); QAction *clearAct = recentMenu->addAction("清空历史"); connect(clearAct, &QAction::triggered, this, &MainWindow::clearRecentProjects); });

动态重建的好处是数据源变化后菜单内容不会过期，坏处是每次展开时clear()会销毁旧 action，如果旧 action 上有未断开的连接，会有野指针风险。做法是不要在 lambda 里捕获可能被销毁的对象，统一用this作为 receiver。

4.2 右键菜单的位置计算别踩 viewport 的坑

右键菜单出现在QTableView、QTreeView上时，位置计算是最容易犯错的点。直接menu.exec(QCursor::pos())在大多数场景能用，但只要视图嵌在滚动容器里，或者表头、状态栏也要弹不同菜单，直接用全局鼠标坐标就会错位。

正确做法是通过视口的viewport坐标转换：

void MainWindow::onTableContextMenu(const QPoint &pos) { QModelIndex index = ui->table->indexAt(pos); if (!index.isValid()) return; QMenu menu(this); QAction *editAct = menu.addAction("编辑..."); QAction *deleteAct = menu.addAction("删除"); QAction *sepAct = menu.addSeparator(); QAction *propertyAct = menu.addAction("属性"); if (contextActionEnabled(index)) { deleteAct->setEnabled(false); } // 关键：先转成 viewport 的全局坐标，再弹出菜单 QPoint globalPos = ui->table->viewport()->mapToGlobal(pos); QAction *selected = menu.exec(globalPos); if (selected == editAct) { // ... } }

这里不要用ui->table->mapToGlobal(pos)，因为点击位置是相对 viewport 的，而 viewport 通常有边框和表头偏移。用viewport()->mapToGlobal()才能和鼠标点击位置完全重合。

4.3 菜单栏、工具栏、快捷键的状态联动

实际项目里一个功能通常会同时出现在菜单、工具栏、快捷键三处。用同一个QAction实例是最省心的方案，状态自动同步：

QAction *togglePanelAct = new QAction("显示侧边栏", this); togglePanelAct->setCheckable(true); togglePanelAct->setChecked(true); togglePanelAct->setShortcut(QKeySequence("Ctrl+B")); // 同一个 action 挂到菜单栏和工具栏 menuBar()->addAction(togglePanelAct); ui->toolBar->addAction(togglePanelAct); connect(togglePanelAct, &QAction::toggled, this, [this](bool on) { ui->sidePanel->setVisible(on); });

如果要给一组动作加分组显示，QActionGroup也很好用：互斥的多个状态（比如排序方式）放一个QActionGroup，菜单里点哪个勾哪个，不需要手工维护勾选状态。

5. QSS美化自定义菜单：从灰底白字到暗色圆角

自定义菜单项如果完全用paintEvent画，样式表的作用会被削弱；但如果底层是普通QAction菜单、顶部只是加了一些居中的自定义控件，QSS依然是最快的美化手段。

5.1 QMenu的QSS选择器速查表

选择器	作用范围
`QMenu`	菜单整体背景、边框、圆角
`QMenu::item`	菜单项基础样式
`QMenu::item:selected`	鼠标悬停或键盘高亮态
`QMenu::item:disabled`	禁用菜单项
`QMenu::item:checked`	勾选态
`QMenu::separator`	分隔线
`QMenu::indicator`	复选/单选指示器
`QMenu::right-arrow`	子菜单箭头

在暗色主题里，最常见的问题有两个：一是QMenu::item的height设得太夸张，导致图标与文字垂直错位；二是border-radius加在QMenu上后，子菜单弹出时会盖住父菜单的圆角区，视觉上有缺口。

我实际用下来比较稳定的暗色菜单样式：

QMenu { background-color: #2b2b2b; border: 1px solid #3c3c3c; border-radius: 8px; padding: 6px; } QMenu::item { background-color: transparent; padding: 6px 28px 6px 12px; border-radius: 4px; color: #e0e0e0; font-size: 13px; margin: 2px 4px; } QMenu::item:selected { background-color: #3a6ea5; color: #ffffff; } QMenu::item:disabled { color: #666666; } QMenu::separator { height: 1px; background-color: #3c3c3c; margin: 6px 12px; } QMenu::indicator { width: 14px; height: 14px; } QMenu::right-arrow { width: 8px; height: 8px; }

另外，如果菜单里嵌入了自定义QWidgetAction控件，给控件设置objectName之后，QSS 里也能选中这个控件并给它涂上匹配菜单的背景：

w->setObjectName("recentFileItem"); // QSS #recentFileItem { background-color: transparent; border-radius: 4px; } #recentFileItem:hover { background-color: #3a6ea5; }

注意 QSS 的:hover对QWidget默认不生效，需要setAttribute(Qt::WA_Hover, true)。这也是很多人发现样式表写了:hover但没反应的原因。

5.2 圆角菜单背后的两个隐藏问题

第一个隐藏问题是高DPI。菜单 QSS 里凡是padding、border-radius、图标尺寸，我都建议用相对字号计算，而不是写死。用户把系统缩放调到 125% 或 150% 时，写死像素值的菜单会变得很局促。我一般这么做：

const qreal scale = devicePixelRatioF(); int basePadding = qRound(6 * scale); menu->setStyleSheet(QString("QMenu::item { padding: %1px %2px; }") .arg(qRound(6 * scale)) .arg(qRound(28 * scale)));

第二个隐藏问题是菜单在弹窗前会被截断。当屏幕边缘空间不足时，Qt 会自动把菜单弹到鼠标上方或侧边。如果菜单宽高较大，最好给QMenu设置最大高度，让内部形成一个可滚动区域：

menu->setStyleSheet("QMenu { max-height: 600px; }"); // 或者在代码里 menu->setMaximumHeight(600);

配合QMenu的滚动行为，长菜单在低分辨率屏幕上不至于超出边界。

6. 两个高频工程问题：include路径报错与菜单对象生命周期

自定义菜单项涉及的工程问题，我自己踩得最深的是两个：编译期的 include 路径报错，和运行期的对象生命周期问题。这两个问题在 Qt 论坛上每天都有新人问，值得单独记录。

6.1 "depend on include" 编译错误的完整排查链路

热搜词里有一串很经典的报错信息，形如：

:-1: error: dependent '..\..\..\qt\5.15.2\msvc2019_64\include\qtwidgets\qapplication.h' does not exist

这种报错出现的时候，很多人以为是代码写错了，其实绝大多数是环境问题。我整理一下排查顺序：

确认 Qt 版本与编译器匹配。msvc2019_64表示这是用 VS2019 编译出来的 Qt 库，如果你用的 VS 版本是 2022，理论上能链接 2019 的库，但如果你混用了 2017 的库，就会出现头文件依赖缺失。打开 Qt 安装目录下的qmake -v看看输出里的 Qt 版本和编译环境。
清理构建缓存。这个报错最常见的原因是 qmake 生成的Makefile里记录了旧的头文件绝对路径，而 Qt 安装路径变了（比如从 Qt5.15.2 换到了 Qt6.x）。在 Qt Creator 里执行：构建目录右键 -> 删除目录，然后重新 qmake、重新构建。
检查INCLUDEPATH和DEPENDPATH。如果你的.pro文件手写过这两个变量，或者从网上复制过一段 Qt 路径配置，最可能粘贴了别人本机路径。删除所有绝对路径，让 Qt 的 mkspec 自动探测。
确认环境变量。MSVC 环境里QTDIR、PATH指向的是哪个 Qt 版本。命令行里执行where qmake，如果显示多个 Qt 目录下的 qmake，编译时就有冲突。
切换 Kit。Qt Creator 中有时候选择的 Kit 与实际使用的编译器不匹配（例如 Kit 选的是 MinGW 但项目用的是 MSVC 库）。在"工具 -> 选项 -> Kits"里重新选一次正确的编译器。

这个问题的本质是 Qt 的构建系统依赖一套"自洽"的头文件路径集合，任何一个环节不一致都会爆dependent ... does not exist。它跟你的菜单代码一行关系都没有，所以先冷静清环境再查代码。

6.2 菜单对象生命周期：谁创建、谁销毁、谁容易悬空

QMenu、QAction、QWidgetAction::createWidget这三者的所有权关系，是自定义菜单项里最容易造成崩溃的地方。

new QMenu(this)：菜单生命周期跟随父对象，父对象销毁时菜单自动销毁，没问题。
menu->addAction(action)：action 的父对象是menu或this，但 add 之后菜单只保存指针，不接管所有权。如果 action 是new出来且没有父对象，就要注意在菜单销毁前手动 delete，否则泄漏。
QWidgetAction::createWidget(parent)：这个parent是菜单内部的容器。菜单销毁时，这个 widget 随之销毁，不要自己在外面再持有裸指针后去 delete，会二次释放。

我踩过的坑是：在菜单里嵌入了FileItemAction，然后在外层又保留了一个FileItemWidget *m_fileWidget成员指针，用来在菜单关闭后更新数据。结果菜单 close 之后 Qt 把 widget 销毁了，成员指针变成悬空指针，下一次aboutToShow里m_fileWidget->update()直接崩溃。

正确做法是不要在成员变量里长期保存createWidget返回的指针，每次打开菜单时通过action->defaultWidget()获取：

FileItemWidget *w = qobject_cast<FileItemWidget *>(fileAction->defaultWidget()); if (w) { w->setFileInfo(newInfo); w->update(); }

或者干脆在createWidget每次重建时从数据模型拉最新数据，不保存状态。

另外，QMenu::popup()和QMenu::exec()的区别也要注意：popup是异步弹出，exec是阻塞式事件循环。如果菜单里有自定义动画或需要实时刷新进度，用popup配合aboutToShow和aboutToHide更合适；如果只是同步选择，exec更简单。我在做"同步中..."反馈那个功能时，就发现exec会阻塞 UI 线程，导致进度刷新失败，改成popup后流畅了。

7. 几个让菜单真正"好用"的小细节

最后补几个不属于技术难点但很影响体验的细节，都是我做过几轮菜单后总结出来的：

给菜单项和自定义控件提供键盘可达性。默认QMenu支持上下方向键导航菜单项，但QWidgetAction嵌入的 widget 内部控件默认不会被键盘导航到。如果菜单里有输入框，要设置QWidget的焦点策略Qt::TabFocus或Qt::StrongFocus，否则用户只能靠鼠标点。

同步 tooltip 和状态栏提示。在菜单项触发前，鼠标悬停时显示提示文字这个需求很常见。普通QAction可以用setToolTip加setStatusTip。但自定义 widget 的 tip 行为是独立的，要自己处理QEvent::ToolTip事件。如果是FileItemWidget这种自绘控件，通常我会重写event()：

bool FileItemWidget::event(QEvent *event) { if (event->type() == QEvent::ToolTip) { QHelpEvent *helpEvent = static_cast<QHelpEvent *>(event); QToolTip::showText(helpEvent->globalPos(), m_info.toolTipText()); return true; } return QWidget::event(event); }

给长菜单增加搜索或首字母定位。真正的大型应用，菜单项超过 30 个之后，用户靠鼠标滑的效率太低了。Qt 没有内置菜单搜索，但可以在QMenu里动态创建一个QLineEdit作为第一个QWidgetAction，利用textChanged过滤后面的菜单项并调用setVisible。这个做法我在一个数据管理工具里用过，效果不错。

8. 踩过一轮之后，我对"自定义菜单项"的判断

如果你问我，做自定义菜单项前最重要的准备工作是什么，我的答案是：想清楚按钮之后的动作语义。菜单不只是画出来好看，关键是它得符合用户对"菜单"的心理预期——点一下执行一个命令，或者切换一个状态。凡是这个语义不清晰的设计，不管画得多漂亮都会觉得别扭。

再分享一个实实在在的验收技巧：把菜单做到暗色主题下不会出现死黑、灰色看不清、hover 无反馈，同时在 Windows 和 Linux 下分别跑一遍高 DPI 缩放，大多数菜单的质感问题都出在这两个维度。自定义菜单项本身并不复杂，复杂的是它要和菜单系统、快捷键系统、状态系统协同工作。把这几个系统的关系理清楚，Qt 的菜单不仅能做，还能做得很好用。