Windows上Shell_NotifyIcon菜单无响应的根本原因是托盘消息必须由拥有消息循环的UI线程处理，且右键菜单需在捕获WM_TRAYICON消息后，通过GetCursorPos、SetForegroundWindow和TrackPopupMenu手动弹出，缺一不可。
Windows 上用 Shell_NotifyIcon 为什么菜单点不动？
直接调用 Shell_NotifyIcon 注册托盘图标后，右键弹出的菜单常无响应，根本原因是 Windows 要求托盘消息必须由拥有消息循环的线程处理，且菜单需通过 TrackPopupMenu 在鼠标坐标处手动弹出，不能依赖系统自动关联。
常见错误是：在子线程调用 Shell_NotifyIcon、没处理 WM_TRAYICON 自定义消息、或用 CreatePopupMenu 后没调用 SetForegroundWindow 再 TrackPopupMenu —— 这会导致菜单瞬间消失或无法点击。
- 必须在主线程（UI 线程）初始化托盘，并运行标准 Win32 消息循环（
GetMessage+DispatchMessage） - 注册托盘时设置
NIF_MESSAGE，指定自定义消息 ID（如WM_TRAYICON），并在窗口过程里捕获该消息 - 收到右键消息后，用
GetCursorPos获取坐标，调用SetForegroundWindow提升前台权限，再TrackPopupMenu - 菜单项 ID 必须是整数（如
ID_EXIT），后续通过WM_COMMAND中的wParam区分操作
macOS 上用 NSStatusBar 为何编译报错 Use of undeclared identifier 'NSStatusBar'？
这不是代码写错了，而是没链接 AppKit 框架，且 C++ 文件默认不支持 Objective-C 语法 —— NSStatusBar 是 Objective-C 类，不能直接在 .cpp 里用。
正确做法是把托盘逻辑单独拆到 .mm（Objective-C++）文件中，头文件用纯 C 接口暴露，内部用 Objective-C 实现。否则即使加了 -framework AppKit，编译器仍会拒绝解析 OC 类型。
立即学习“C++免费学习笔记（深入）”；
- 新建
tray_mac.mm，开头加#import <AppKit/AppKit.h>，实现函数如tray_init()、tray_add_item(const char* label, void (*cb)()) - C++ 主文件只包含简单声明头，调用时传入 C 函数指针，OC 层用 block 或全局 map 绑定回调
- 链接时必须加
-framework AppKit -ObjC，否则类方法不会被加载 - macOS 托盘不支持子菜单嵌套，所有菜单项必须是一级；图标尺寸建议 18×18px，过大显示异常
Linux 上用 libappindicator 还是 GtkStatusIcon？
GtkStatusIcon 已废弃（GTK 3.14+ 移除），强行用会链接失败或运行崩溃；libappindicator 是 Ubuntu/Unity 专用，GNOME 和 KDE 默认不支持，且依赖 D-Bus 服务，普通发行版可能没装 indicator-application-service。
真正跨桌面兼容的做法是退回到 X11 原生协议：用 libx11 + libxext 实现系统托盘区通信（通过 _NET_SYSTEM_TRAY_S0 选择器注册），再用 libgtk-3 绘制菜单 —— 但开发成本高。更现实的选择是只支持 GNOME/KDE 主流环境，用各自 D-Bus 接口。
- GNOME 推荐用
gdbus调用org.gnome.Shell.Extensions.AppIndicator（需用户安装扩展） - KDE 可监听
org.kde.StatusNotifierWatcher的RegisterStatusNotifierItem方法，传入本地 D-Bus 对象路径 - 统一做法：检测桌面环境（
getenv("XDG_CURRENT_DESKTOP")），再加载对应后端；fallback 到纯文本通知（notify-send）而非强行显示托盘 - 不要尝试用 Qt 的
QSystemTrayIcon—— 它在 Wayland 下基本不可用，且对非 Qt 应用有隐式依赖风险
如何让三个平台共用同一套菜单逻辑？
关键不是“复用 UI”，而是“复用行为描述”：把菜单结构定义为数据（如 JSON 或 C 结构体），各平台后端只负责渲染和事件转发，不参与业务判断。
例如定义一个 struct tray_menu_item，含 label、id、is_separator、callback（函数指针），主程序构造数组后传给平台初始化函数。回调触发时，只传 id 回来，由主逻辑决定做什么 —— 这样新增菜单项无需改任何平台相关代码。
- 避免在平台层做字符串翻译或图标加载，全部由上层提供已处理好的 UTF-8 字符串和内存内图标数据（如 PNG raw bytes）
- macOS 不支持禁用菜单项，Linux D-Bus 接口也不提供 enable/disable 控制，所以“灰化”状态只能靠隐藏项模拟
- 点击菜单后，Windows/macOS 是同步回调，Linux D-Bus 是异步信号，需确保回调函数可重入（比如用原子标志防重复触发）
- 图标更新最易出错：Windows 要重新调用
Shell_NotifyIcon(NIM_MODIFY, ...)，macOS 需替换NSImage*并调用setImage:，Linux 则要发新 D-Bus 属性信号 —— 不能共用同一张内存图
跨平台托盘真正的难点不在 API 调用，而在于事件时序和生命周期管理：Windows 图标随窗口销毁自动清理，macOS 需显式调用 [statusItem release]，Linux D-Bus 对象要主动注销。漏掉任意一项，都会导致下次启动时托盘残留或崩溃。
