企业官网建设流程全解析

托盘图标的气球通知，是我在这类桌面工具开发里被坑得最没有脾气的一个小功能。一行Shell_NotifyIcon调用，参数填完，编译零警告，运行之后右下角安安静静，什么也没有。明明图标已经在托盘里躺着了，右键菜单也正常，就这个气泡死活不弹。我第一次遇到时把窗口句柄、图标句柄、结构体大小全打印了一遍，折腾到半夜；第二次以为是系统把通知关了，把设置面板翻了个底朝天；直到第三个项目里同类问题第三次出现，我才算把Shell_NotifyIcon这套 API 的脾气摸清楚——它失败的时候往往连个FALSE都不给你，或者给了你也不会去看。

这篇东西讲的就是这件事：用 VS 开发 Windows 桌面程序时，托盘图标已经添加成功，调用Shell_NotifyIcon配合NIF_INFO发送气球通知却无效，到底是什么原因、怎么一步步定位、代码该怎么写才稳。涉及的核心点包括NOTIFYICONDATA结构体的版本差异、cbSize字段、uTimeout与uVersion的联合体、字符串字段长度、NIM_ADD与NIM_MODIFY的调用顺序，以及 Win10 之后通知通道变化带来的新问题。适合已经能把托盘图标加上去、但被通知弹不出来卡住的中级开发者，也适合刚接触 Shell API、想少走弯路的新手。下面这些内容都是我在实际项目里反复验证过的，代码片段可以直接抄。

1. 先把"无效"这个词拆开看

1.1 三种完全不同的"不弹"

很多人说"气球通知无效"，其实指的是三种截然不同的现象，排查方向完全不一样，混在一起找原因是效率最低的做法。

第一种是彻底没有任何反应。鼠标移到托盘图标上有 tooltip，右键菜单能弹出，但调用完通知接口之后，屏幕上什么都不发生，通知中心里也找不到记录。这种大概率是调用本身失败了，或者参数压根没被系统接受。

第二种是闪一下就没了，或者只在任务栏上方出现不到一秒。这种通常是调用成功了，但超时时间被设成了 0 或者一个极小的值，也可能是图标被系统判定为"不重要"而折叠掉了。

第三种是在开发机上正常、在客户机上不弹。这种最让人抓狂，因为代码逻辑本身没问题，问题出在运行环境的通知策略上。Win10 之后系统对通知的管控比以前严格得多，专注助手、通知开关、应用级通知权限，任何一道关卡关着，你的气球就出不来。

我建议第一步先做现象分类，而不是直接去改代码。具体做法很简单：在调用Shell_NotifyIcon之后立刻检查返回值，并在通知应该出现的时间段内观察通知中心（Win+A 打开的那个面板）里有没有留下痕迹。有痕迹说明通道通了，是显示策略问题；没痕迹说明根本没送进去，是调用问题。这一步能把排查范围砍掉一半。

提示：不要只看托盘区域。Win10 之后气球通知很多时候会直接进通知中心，托盘那里只是闪一下，盯着右下角看反而会误判。

1.2 返回值和 GetLastError 的信息量其实很有限

Shell_NotifyIcon返回BOOL，失败返回FALSE。理论上你可以紧接着调GetLastError()看错误码，但实际经验是——这个 API 在很多失败场景下压根不设置 last error，你拿到的是上一个无关调用残留的错误码，反而把你带偏。

我踩过最典型的一次：Shell_NotifyIcon(NIM_MODIFY, &nid)返回FALSE，GetLastError()返回 87（参数错误）。我顺着"参数错误"去查，把每个字段都打印了一遍，最后发现真正的原因是结构体大小填错了，系统读到一半就越界了。错误码没错，但它指向的是"参数错误"这个大类，具体是哪个参数、错在哪，它不会告诉你。

所以我的做法是：不要依赖GetLastError定位，而是自己把关键字段打印出来对照。至少打印这几项：cbSize的实际值、uFlags的位组合、hWnd是否有效、uID是否与添加时一致、szInfo和szInfoTitle的实际长度。这五个字段覆盖了我遇到过的大部分失败原因。

还有一个细节值得说：如果你在调试器里单步执行，某些系统上气球通知会因为调试器的窗口焦点抢占而表现异常，比如弹出来又被立刻收走。验证时最好直接跑 release 版本，或者至少让程序正常跑起来再看，别在断点状态下判断"弹没弹"。

1.3 这套 API 为什么容错这么差

要理解它为什么这么"脆"，得从它的定位说起。Shell_NotifyIcon诞生在 Win95 时代，那时候的设计哲学是"轻量、快速、够用"，参数校验做得非常宽松，很多字段是"你填错了我就当没看见"，而不是"你填错了我就报错"。这种设计在当年没问题，因为结构体小、字段少、平台单一；但到了今天，结构体经过三次扩展，字段从六七个涨到十几个，平台从 Win95 一路覆盖到 Win11，历史包袱就全压在调用方身上了。

一个具体的例子：NOTIFYICONDATA有三个历史版本（V1、V2、V3/V4），大小各不相同。系统怎么知道你传的是哪个版本？靠cbSize。你填多少，它就按多少来解析。填小了，后面的字段它不读；填大了，它可能读到你栈上的垃圾数据。这种"靠长度自描述"的设计在 C 语言里很常见，但它把版本适配的责任完全推给了开发者。

再一个例子：通知内容字段szInfo和szInfoTitle是定长数组，不是指针。你往里拷字符串的时候如果没控制长度，越界写会破坏后面的字段（比如dwInfoFlags），表现出来就是"通知发出去了但图标不对"或者"标题正常正文乱码"。这类问题编译器不会警告，运行时也不会崩，就是行为诡异。

理解了这一点，你就能明白为什么排查这类问题不能靠猜，只能靠逐字段核对。

2. NOTIFYICONDATA 结构体里最要命的三个坑

2.1 cbSize 填错：一个字段引发的连锁失败

这是所有坑里出现频率最高的一个，也是我建议每个新人第一件事就记住的。

NOTIFYICONDATA的大小在历史上变过好几次。最早 Win95 版本只有基础字段；Win2000 加了状态、通知文本、超时、标题、图标标志；XP 加了 GUID；Vista 又加了气球图标句柄。对应地，头文件里提供了NOTIFYICONDATA_V1_SIZE、NOTIFYICONDATA_V2_SIZE、NOTIFYICONDATA_V3_SIZE这几个宏，以及不带后缀的完整大小。

问题的根源在于：_WIN32_WINNT这个预处理宏会影响NOTIFYICONDATA的实际定义。如果你的工程里某个 .cpp 文件定义了_WIN32_WINNT=0x0501（XP），另一个文件没定义或者定义成0x0600（Vista），两个编译单元看到的sizeof(NOTIFYICONDATA)就不一样。这时候如果你在一个文件里构造结构体、在另一个文件里调用，cbSize填的是"你这边的大小"，系统按"你这边的大小"解析，看起来没问题；但如果两边大小不一致，就会出现一半字段读不到、一半字段读到垃圾的情况。

我的做法是：在预编译头或者工程级别的公共头文件里统一定义_WIN32_WINNT，绝不在单个 .cpp 里临时改。然后在每个使用NOTIFYICONDATA的地方都用sizeof(NOTIFYICONDATA)而不是硬编码数字。硬编码是大忌，因为不同 SDK 版本、不同字符集、32/64 位下这个值都不一样，你写死一个数字，换台机器编译就废了。

还有一种情况是结构体没清零。我见过不少代码是这么写的：

NOTIFYICONDATA nid; nid.cbSize = sizeof(NOTIFYICONDATA); nid.hWnd = m_hWnd; // ... 逐个赋值

没清零的栈变量里全是垃圾数据。你只赋了hWnd和uID，uFlags是随机值，uCallbackMessage是随机值，系统读到一个乱七八糟的 flags 组合，行为完全不可预测。正确写法是一开始就NOTIFYICONDATA nid = {};，把所有字段归零，再按需赋值。这一行看着不起眼，能省掉你至少两个小时的调试。

2.2 uTimeout 和 uVersion 是同一个位置

这个坑隐蔽程度排第二。NOTIFYICONDATA里有一个匿名联合体：

union { UINT uTimeout; UINT uVersion; } DUMMYUNIONNAME;

也就是说，uTimeout和uVersion共用同一块内存。你设了uTimeout = 5000，同时又在某个地方调了NIM_SETVERSION传了个版本号，两者会互相覆盖。表现出来就是：要么超时时间不对，要么版本协商失败导致后续的NIF_INFO行为退化成老版本。

具体怎么用才对？我的经验是分两个阶段：

初始化阶段用NIM_ADD添加图标，这时候把uVersion设成你想要的版本（比如 4），调用一次NIM_SETVERSION，让系统知道你要用新版本的行为。这个调用要在NIM_ADD之后、发通知之前做。

发通知阶段用NIM_MODIFY配NIF_INFO，这时候才设uTimeout，单位是毫秒。设完就调，别在同一份结构体上再动uVersion相关的东西。

还有一点：uTimeout设成 0 不代表"永久显示"，不同系统上表现不一样，有的用默认值（大约 10 秒），有的直接不显示。我一般设 5000 到 8000，既能看清又不烦人。

关于版本号再补一句：uVersion的取值范围是 0 到 4，对应不同时期的行为。0 是老版本行为（通知显示在标题栏下方），3 以上是新版本行为。如果你不调NIM_SETVERSION，系统默认按老版本处理，这也是很多"通知能弹但样式很怪"的原因。

2.3 字符串字段的边界和编码

szInfo、szInfoTitle、szTip这三个字段都是定长TCHAR数组。在 Unicode 编译下，szTip是 128 个wchar_t，szInfo是 256 个，szInfoTitle是 64 个。注意是包含结尾空字符在内的长度，所以实际能放的字符数是减一的。

超长的后果分两种：如果用的是lstrcpy这类不检查长度的函数，会直接越界写坏后面的字段，表现为通知图标错乱或者干脆发送失败；如果用的是lstrcpyn这类带长度限制的，会安全截断，但截断位置如果正好在中文双字节的中间（ANSI 编译下），就会产生半个汉字，显示成乱码。

我现在的统一写法是：

lstrcpyn(nid.szInfoTitle, _T("处理完成"), ARRAYSIZE(nid.szInfoTitle)); lstrcpyn(nid.szInfo, _T("共处理 128 条记录，耗时 3.2 秒。"), ARRAYSIZE(nid.szInfo));

ARRAYSIZE宏会自动取到数组的完整长度，lstrcpyn保证不会越界，同时它会自动补结尾空字符。这一对组合用了好几年，没再出过字符串相关的问题。

编码问题也值得单独说。如果工程是 ANSI 编译的，szInfo里放中文，在某些系统区域设置下会显示成问号或者方块。最省事的解决办法是整个工程统一用 Unicode 编译，VS 工程属性里"字符集"改成"使用 Unicode 字符集"，代码里字符串用_T()或L前缀包裹。如果因为历史原因必须用 ANSI，那就得在拷贝前做一次MultiByteToWideChar转换，或者干脆保证通知内容全是 ASCII。

另外提醒一句：通知正文里不要放换行符。szInfo里塞\n在某些系统上会把整个通知撑变形或者直接不显示，想分行就分成两条通知发。

3. 从添加图标到弹出通知的正确顺序

3.1 最小可运行的托盘初始化

很多人失败的原因不是通知本身写错了，而是前一步的图标添加就没做扎实。下面这份初始化代码是我现在项目里的标准模板，Win32 和 MFC 都适用，只是成员变量换一下：

// 头文件里声明 NOTIFYICONDATA m_nid = {}; // 初始化函数 BOOL CTrayDemoDlg::InitTray() { m_nid.cbSize = sizeof(NOTIFYICONDATA); m_nid.hWnd = GetSafeHwnd(); m_nid.uID = 1; m_nid.uFlags = NIF_ICON | NIF_MESSAGE | NIF_TIP; m_nid.uCallbackMessage = WM_TRAY_NOTIFY; m_nid.hIcon = AfxGetApp()->LoadIcon(IDR_MAINFRAME); lstrcpyn(m_nid.szTip, _T("托盘示例程序"), ARRAYSIZE(m_nid.szTip)); if (!Shell_NotifyIcon(NIM_ADD, &m_nid)) { return FALSE; } // 协商通知版本，让气球走新版行为 m_nid.uVersion = 4; Shell_NotifyIcon(NIM_SETVERSION, &m_nid); return TRUE; }

几个关键点解释一下。uFlags在添加阶段必须是NIF_ICON | NIF_MESSAGE | NIF_TIP这三项的组合，缺一不可：没有NIF_ICON图标不显示，没有NIF_MESSAGE收不到鼠标事件，没有NIF_TIP鼠标悬停没提示。uCallbackMessage是你自定义的消息 ID，一般用WM_USER + 100往上的值，避免和系统消息冲突。

NIM_SETVERSION这一步很多人省掉了，结果就是通知能弹但样式老气，或者在多显示器环境下位置不对。这一步不费事，加上更稳。

有一点必须强调：添加图标这一步一定要检查返回值。如果这里就失败了，后面的通知必然无效，你却在通知那边找半天原因，纯属浪费时间。失败的原因通常是hWnd无效（窗口还没创建完就调了）或者hIcon为空（资源 ID 写错了）。

3.2 气球通知该怎么发

图标添加成功之后，发通知是独立的一次调用，用NIM_MODIFY，uFlags里带NIF_INFO。标准写法：

void CTrayDemoDlg::ShowBalloon(LPCTSTR title, LPCTSTR content, DWORD flags) { m_nid.uFlags = NIF_INFO; m_nid.dwInfoFlags = flags; // NIIF_INFO / NIIF_WARNING / NIIF_ERROR m_nid.uTimeout = 6000; lstrcpyn(m_nid.szInfoTitle, title, ARRAYSIZE(m_nid.szInfoTitle)); lstrcpyn(m_nid.szInfo, content, ARRAYSIZE(m_nid.szInfo)); if (!Shell_NotifyIcon(NIM_MODIFY, &m_nid)) { // 这里可以打日志，但别指望 GetLastError 给出精确原因 } }

dwInfoFlags有几个可选值值得知道：NIIF_INFO是信息图标（蓝色 i），NIIF_WARNING是黄色感叹号，NIIF_ERROR是红色叉，NIIF_NONE是不带图标。还有一个NIIF_NOSOUND，加上之后不播放提示音——这个在批量通知场景下很有用，否则连着弹五条能把人吓一跳。

这里有个顺序问题必须讲清楚：NIF_INFO只能通过NIM_MODIFY设置，不能挂在NIM_ADD上。我见过有人图省事，在初始化的时候就把uFlags写成NIF_ICON | NIF_MESSAGE | NIF_TIP | NIF_INFO，然后把szInfo也填上，指望添加图标的同时弹一条通知。在某些系统上这确实会弹，但更多时候是静默失败，或者弹出来的内容对不上。原因是添加阶段系统还在建立图标上下文，通知字段的时机不成熟。

还有一个细节：每次调ShowBalloon之前，uFlags最好重新赋一次NIF_INFO，而不是指望上次的值还在。因为在两次通知之间，你可能会用同一个结构体去做别的操作（比如更新 tooltip），把uFlags改掉了。结构体复用是好事，但每次用之前重置关键字段是必须的。

3.3 消息回调里能拿到什么

托盘图标的事件是通过uCallbackMessage指定的消息送回来的。在窗口过程里处理的时候，wParam是图标 ID，lParam是具体事件。和气球通知相关的事件有四个：

处理函数大概长这样：

LRESULT CTrayDemoDlg::OnTrayNotify(WPARAM wParam, LPARAM lParam) { if (wParam != 1) return 0; switch (LOWORD(lParam)) { case NIN_BALLOONUSERCLICK: // 用户点了通知，把主窗口拉到前台 ShowWindow(SW_RESTORE); SetForegroundWindow(); break; case NIN_BALLOONTIMEOUT: // 超时消失，可以记个日志 break; } return 0; }

需要提醒的是NIN_BALLOONHIDE这个事件。文档里说它在气泡被系统移除时触发，但实测在很多场景下根本不来，尤其是用户手动关掉通知中心的时候。所以不要把这个事件当成业务逻辑的必要环节，比如"通知关闭后自动执行下一步"这种设计，在部分机器上会卡死流程。

还有一个坑：如果你在NIN_BALLOONUSERCLICK里调SetForegroundWindow把窗口拉到前台，有些情况下会失败（系统不让后台进程抢焦点）。稳妥的做法是先ShowWindow(SW_RESTORE)，再调一次SetForegroundWindow，如果还不行就FlashWindowEx闪任务栏按钮提示用户。

4. 代码写对了还是不弹，问题多半在系统侧

4.1 通知开关和专注助手是第一嫌疑人

我遇到过至少三次"代码完全正确、开发机上能弹、客户机上不弹"，最后查下来全是系统通知策略的问题。Win10 之后系统把通知权限收得很紧，用户可以在好几个地方把通知关掉，而且这些开关的状态不会通过任何 API 反馈给你，你的调用照样返回成功，只是通知被系统默默丢掉了。

第一个地方：设置 → 系统 → 通知和操作，最上面有个总开关，关掉之后所有应用的通知都不显示。这个开关在"平板模式"或者某些优化工具里会被自动关闭，用户自己都不一定知道。

第二个地方：同一个页面往下拉，有每个应用的通知开关。你的程序会以可执行文件名出现在这个列表里，如果用户不小心把它关了，你的气球就永远出不来。

第三个地方：专注助手（后来改名叫"请勿打扰"）。这个功能开启时，通知会被静默收集到通知中心，但不弹横幅。用户开了它自己往往忘了，你在那边调试代码，怎么调都不弹。

我在排查这类问题时有个固定动作：先让用户打开通知中心，看里面有没有你的通知记录。有记录但没横幅，就是专注助手的问题；连记录都没有，才是代码或者应用级开关的问题。这个判断只需要十秒钟，能省掉大量往返沟通。

还有一个更隐蔽的：组策略。企业环境里管理员可能通过策略统一关闭了通知，这种情况下普通用户改设置也没用，需要联系管理员。这类环境我一般会提供一个"降级方案"——通知弹不出来时，改用窗口内嵌的提示条或者状态栏文字，保证信息不丢失。

4.2 Win10 之后气球通知走了另一条通道

这是近几年最让人困惑的变化。在 Win7 及以前，气球通知是真正意义上的"气球"，从托盘图标位置冒出来，带个小尖角指向图标。从 Win10 开始，系统把Shell_NotifyIcon发出的通知重定向到了 Toast 通知通道，表现形式变成了屏幕右下角的横幅，和系统自带的通知长得一样。

这个重定向带来两个后果。第一个是通知必须归属到某个应用。纯 Win32 程序如果没有设置应用标识，通知可能会显示成一个通用的名字，或者在部分系统版本上干脆不显示。解决办法是调用一次SetCurrentProcessExplicitAppUserModelID，给进程一个稳定的标识字符串，这个标识要和你程序快捷方式里配置的一致。这个调用只需要在程序启动时做一次。

// 程序入口处调用一次 SetCurrentProcessExplicitAppUserModelID(L"MyCompany.MyTrayApp.1");

第二个后果是通知的显示时机和优先级由系统统一调度。即使你的调用成功，系统也可能因为当前有全屏应用、有会议模式、或者通知队列拥堵而延后显示。表现出来就是"有时候弹有时候不弹"，让你怀疑代码有随机 bug。这种情况没法从代码层面解决，只能接受它是系统行为。

还有一个相关的变化：szInfoTitle和szInfo的显示规则变了。老版本气球里标题是粗体、正文是普通字，中间有分隔线；新版本 Toast 里两者的视觉层级不一样，正文太长会被折叠成"展开"按钮。所以如果你在通知里塞了一大段文字，用户可能根本看不到后半段。我的原则是标题控制在 20 字以内，正文控制在 60 字以内，超出的部分让用户点通知到主界面看。

4.3 explorer 重启之后图标没了，通知当然也没了

这个坑在开发阶段几乎遇不到，一到用户手里就频繁出现。任务栏崩溃重启、系统更新、远程桌面切换，都可能导致 explorer.exe 重启。重启之后，所有托盘图标都会被清空，你的图标没了，后续发的通知自然也就无效——因为通知是挂在图标上的。

系统为这种情况准备了一个广播消息TaskbarCreated，explorer 重启后会向所有顶层窗口广播。你需要注册这个消息，收到之后重新调NIM_ADD把图标加回去：

// 在初始化时注册消息 UINT WM_TASKBARCREATED = RegisterWindowMessage(_T("TaskbarCreated")); // 窗口过程里处理 if (message == WM_TASKBARCREATED) { InitTray(); // 重新添加图标 return 0; }

这个处理逻辑很短，但不加的话，用户的托盘图标会在某次系统更新后凭空消失，然后来找你说"你们的程序有 bug"。加上之后，至少图标能自愈。

顺带说一句，重新添加之前最好先调一次NIM_DELETE清理残留，虽然图标已经没了，但内部状态可能还挂着，不清理在某些系统上会导致重复添加失败。

4.4 消息循环和线程模型的隐性约束

Shell_NotifyIcon要求调用它的线程有一个正在运行的消息循环，而且hWnd对应的窗口必须已经创建完成。这两条听着像废话，但违反的例子非常多。

最常见的是在OnInitDialog或者窗口构造函数里调InitTray()。OnInitDialog时窗口句柄已经有了，一般没问题；但如果在构造函数里调，GetSafeHwnd()返回的是空，NIM_ADD直接失败，后面所有通知都无效。正确的位置是OnInitDialog的最后、或者WM_CREATE处理完之后。

第二种是在工作线程里直接调。有些人为了让通知在后台任务完成时弹出，就在工作线程里调Shell_NotifyIcon。这个 API 本身不要求必须在 UI 线程，但hWnd属于 UI 线程，跨线程传递窗口消息会有同步问题。稳妥做法是工作线程里PostMessage给 UI 线程，让 UI 线程去发通知：

// 工作线程里 ::PostMessage(m_hMainWnd, WM_SHOW_BALLOON, 0, 0); // UI 线程的消息处理里 case WM_SHOW_BALLOON: ShowBalloon(_T("任务完成"), _T("后台处理已结束。"), NIIF_INFO); break;

这个模式多写两行代码，但避开了所有跨线程的坑。

第三种是控制台程序或者服务程序想弹通知。技术上可以创建一个隐藏窗口然后调 API，但如果程序运行在会话 0（服务），通知是弹不到用户桌面的。这种需求本身就不该用托盘通知实现，换别的方案。

5. 排查速查表和几个反直觉的坑

5.1 一页速查：从现象定位原因

我把这些年遇到的问题整理成一张表，遇到"通知不弹"时从上往下过一遍，基本能在十分钟内定位：

这张表我自己贴在显示器边上用了很久，后来背下来了就撕了。建议你也照着做一份，遇到问题先查表再动手改代码，效率差好几倍。

5.2 几个反直觉的坑，文档里不会写

坑一：连续发两条通知，第二条石沉大海。系统对同一个图标的气球通知有节流机制，短时间内连续调用NIM_MODIFY配NIF_INFO，后面的会被合并或者丢弃。我试过在循环里给十条数据各发一条通知，实际只弹出来一条。解决办法是做一个简单的队列，每条通知间隔至少 3 秒，并且在发下一条之前等上一条的NIN_BALLOONTIMEOUT或者NIN_BALLOONUSERCLICK。如果业务上确实需要批量提醒，就别用气球，改用主界面里的消息列表。

坑二：改了通知内容，弹出来还是旧的。这是因为你复用了同一个NOTIFYICONDATA结构体，但上次调用之后系统可能缓存的还是老内容。我遇到过一次，szInfo明明已经用lstrcpyn覆盖了，弹出来还是上一次的文字。后来发现是字符串长度变短时，后面的残留字符没清掉——lstrcpyn只保证在指定长度内补空，但如果新字符串比旧的短，旧内容可能还留在缓冲区的后半段。彻底的做法是每次发通知前先ZeroMemory掉szInfo和szInfoTitle两个字段。

坑三：NIIF_ERROR的红色叉在 Win10 上变成了通用图标。老版本气球里NIIF_ERROR是明确的红色叉，新版本 Toast 通道下这个图标标志部分被忽略了，显示的是应用自己的图标。所以不要指望通过图标颜色传达信息，重要程度要靠文字写清楚。这是个典型的"老 API 在新系统上行为漂移"的例子。

坑四：调试时能弹，直接运行不弹。这个我前面提了一句，但值得展开。原因是调试器启动的进程和双击启动的进程，在应用标识、工作目录、权限上下文上都可能不同。尤其是应用标识这一项，VS 调试时进程名可能带.vshost后缀（旧版本），导致通知归属到另一个"应用"上，而那个应用的通知开关是关的。验证方法很简单：编译出 release 版本，直接双击 exe 跑，别用 F5。

坑五：远程桌面会话里通知不弹。远程桌面连接时，通知的显示位置和本地会话不一样，有时候会跑到本地机器的通知中心里，你在远程画面里看不到。这个不是 bug，是系统的会话隔离机制。测试通知功能一定要在本地物理会话里做。

5.3 比气球通知更稳的替代方案

用了这么多年，我的结论是：气球通知适合做"锦上添花"的提示，不适合承载关键信息。因为它的显示与否受太多外部因素影响，你无法保证用户一定看到。

所以在关键业务场景里，我会做双通道：

第一个通道是气球通知，负责"打扰"——任务完成、状态变化这类可以错过但不能不知道的事。

第二个通道是程序内部的可见状态，比如主窗口底部的状态栏文字、任务列表里的状态标记、或者一个消息中心面板。用户就算错过了气球，回头打开程序也能看到发生了什么。

如果提示的紧急程度再高一级，比如需要用户立刻确认的操作，那就别用通知了，直接弹一个模态对话框。虽然体验上重一些，但至少能保证用户看到。

还有一个方案是任务栏按钮的进度和状态叠加（ITaskbarList3接口），可以把进度条直接画在任务栏图标上，比气球通知直观得多，而且不受通知开关影响。这个接口在 Win7 之后都有，用起来也不复杂。我在做长时间任务的时候会用它配合气球通知：进度用任务栏叠加显示，完成时再弹一条气球。

代码层面大概是这样：

ITaskbarList3* pTaskbar = nullptr; CoCreateInstance(CLSID_TaskbarList, nullptr, CLSCTX_INPROC_SERVER, IID_PPV_ARGS(&pTaskbar)); pTaskbar->SetProgressState(m_hWnd, TBPF_NORMAL); pTaskbar->SetProgressValue(m_hWnd, 30, 100);

最后再分享一个小技巧。如果你实在搞不清通知为什么不弹，可以在发通知之前临时把dwInfoFlags设成NIIF_NONE，也就是不显示图标，然后看能不能弹出来。如果能弹，说明问题出在图标资源或者图标标志上；如果还是不能弹，说明问题在通道层面。这个二分法能快速排除掉一半的可能性，比逐个字段猜要快得多。

我在最近一个项目里就靠这一招定位到了问题：客户机上NIIF_ERROR的气球永远不弹，NIIF_INFO的正常。最后查下来是那台机器的通知设置里把"错误类通知"单独关掉了，改回NIIF_INFO加文字说明之后一切正常。这种问题，代码层面再怎么检查也发现不了，只能靠这种试探性验证。

托盘这块的 API 就是这样，简单的东西藏着一堆历史包袱，但只要把结构体版本、字段边界、调用顺序这几个基础点做扎实，剩下的就交给时间和经验去填。我现在的习惯是每个用到托盘的项目都写一个独立的CTrayIcon封装类，把初始化的返回值、TaskbarCreated的重建、通知的节流队列全塞进去，上层只调ShowBalloon(title, text)一个方法。这样新项目直接复用，不用每次重新踩一遍这些坑。