在 Windows 窗口程序里，定时器更新列表框，看起来是最普通的入门功能。你定义一个SetTimer，过一会儿往ListBox里AddString一行文字，界面就会自动出现新内容。但只要你真在项目里用它做过日志窗口、设备状态列表、消息通知区域，就会发现事情没有这么简单：定时器不触发、列表越来越长、界面越来越卡、关闭窗口偶尔直接崩溃。这些问题和SetTimer本身的用法有关，也和消息循环、控件重绘、线程模型有关。我见过不少新手在这个功能上反复调试几小时，最后发现不是不会用 API，而是没把“定时器—消息—控件更新—资源回收”这条链路打通。
1. 先搞清楚定时器更新列表框时，底层到底发生了什么
1.1 定时器不是一个“到点自动执行的后台线程”
在 Windows 中，SetTimer创建的不是并行逻辑。系统在间隔到达后，会向创建定时器的窗口投递WM_TIMER消息。UI 线程必须从消息队列里取出消息，分发到窗口过程，最后才会走到OnTimer。这意味着：
- 如果消息循环被阻塞，比如在
OnTimer里Sleep、弹模态框、执行耗时操作，后续WM_TIMER不会准时执行； WM_TIMER的优先级较低，和鼠标消息、绘制消息、外部消息同时出现时，可能被延后处理；- 当间隔很小时，系统还可能合并
WM_TIMER消息，不会严格保证每次都触发一次回调。
很多人会拿它和 51 单片机里的定时器做类比，但两者模型完全不同。单片机里的定时器主要靠硬件计数器，溢出后可以触发中断，中断服务程序会打断当前主流程。Windows 用户态定时器依赖消息循环，本质上是一种软件调度。哪怕你把SetTimer的间隔写成 10ms，系统在忙的时候也可能每隔 30ms 甚至更久才发一次WM_TIMER。理解这一点，就不会误以为“定时器更新”等于“精确计时”。
1.2 列表框更新本质上是一连串窗口消息
CListBox本身是一个控件窗口。AddString看起来只是把一个字符串加进列表，实际过程会走LB_ADDSTRING消息，让控件维护内部字符串数组，然后触发界面重绘。如果控件启用了自绘，还会涉及WM_MEASUREITEM、WM_DRAWITEM等消息。
所以，当你用定时器高频更新ListBox时，CPU 消耗并不只是在“加字符串”，更多是在“重新布局和绘制控件”。很多人发现“每秒加一条没问题，每秒加一百条就开始卡”，真正的原因不是AddString变慢了，而是WM_PAINT的频率上来了。解决思路不是继续压缩定时器间隔，而是控制更新节奏，把多次写入合并成一次批量刷新。
1.3 小实验前先建立正确认知
我建议把这条链路画出来：
SetTimer → WM_TIMER → OnTimer → AddString → WM_PAINT
之后排查所有问题，都沿着这条链路找。比如定时器不触发，问题可能在SetTimer或消息映射；内容没显示，问题可能在控件重绘；界面卡顿，问题可能在刷新频率或字符串数量。这个框架比单独背 API 更有用。你现在要做的不只是“每隔一段时间加一行文字”，而是设计一个“受控的 UI 更新策略”。
2. 在对话框程序中做出第一个可运行版本
2.1 准备工作：控件和变量
以一个 MFC 对话框程序为例。在资源编辑器里添加：
- 一个
ListBox控件，ID 设为IDC_LIST_LOG，关联控件变量CListBox m_listLog； - 一个“开始定时”按钮，ID 设为
IDC_BTN_START； - 一个“停止定时”按钮，ID 设为
IDC_BTN_STOP； - 可选一个
Edit控件或Spin控件，用来配置刷新间隔。
关联控件变量后，类中会自动出现DDX_Control(pDX, IDC_LIST_LOG, m_listLog)。这样后续你才可以直接写m_listLog.AddString(...)。如果只是用 Win32 API，也可以先通过GetDlgItem拿到HWND，再发送LB_ADDSTRING消息，但原理是相同的。
2.2 声明消息处理函数和消息映射
在对话框类的头文件里声明：
afx_msg void OnTimer(UINT_PTR nIDEvent);在源文件的消息映射里加上：
BEGIN_MESSAGE_MAP(CXXXDlg, CDialogEx) ON_WM_TIMER() ON_BN_CLICKED(IDC_BTN_START, &CXXXDlg::OnBnClickedStart) ON_BN_CLICKED(IDC_BTN_STOP, &CXXXDlg::OnBnClickedStop) END_MESSAGE_MAP()很多新手只写了OnTimer函数，却漏掉ON_WM_TIMER()宏，结果OnTimer怎么都不被调用。MFC 的消息映射是消息和函数绑定的关键，不是声明了成员函数就能自动生效。
2.3 用固定 ID 管理定时器
建议先定义一个常量：
#define ID_TIMER_REFRESH 1固定 ID 的好处是同一个窗口可以管理多个定时器，OnTimer里可以通过nIDEvent判断是哪一个定时器到期了。如果直接在代码里写数字 1、2、3，时间长了很容易混乱。
启动按钮：
void CXXXDlg::OnBnClickedStart() { if (m_bTimerRunning) { AfxMessageBox(_T("定时器已经在运行")); return; } if (SetTimer(ID_TIMER_REFRESH, 1000, NULL) == 0) { AfxMessageBox(_T("创建定时器失败")); return; } m_bTimerRunning = true; }停止按钮：
void CXXXDlg::OnBnClickedStop() { if (m_bTimerRunning) { KillTimer(ID_TIMER_REFRESH); m_bTimerRunning = false; } }在头文件里声明BOOL m_bTimerRunning;，构造函数里初始化为FALSE。这个标志位可以防止用户重复点击“开始”，导致多个定时器同时运行。
2.4 在 OnTimer 中把内容写进列表框
第一版可以设计成“每秒添加一次当前时间”：
void CXXXDlg::OnTimer(UINT_PTR nIDEvent) { if (nIDEvent == ID_TIMER_REFRESH) { CString strTime = CTime::GetCurrentTime().Format(_T("%H:%M:%S")); m_listLog.AddString(strTime); int nCount = m_listLog.GetCount(); const int MAX_LOG_LINES = 100; while (nCount > MAX_LOG_LINES) { m_listLog.DeleteString(0); nCount = m_listLog.GetCount(); } if (m_listLog.GetCount() > 0) { m_listLog.SetTopIndex(m_listLog.GetCount() - 1); } } CDialogEx::OnTimer(nIDEvent); }这里有几个关键点：
DeleteString(0)删除最旧的一条记录，避免列表无限增长；SetTopIndex(GetCount() - 1)让最新一条滚动到可视区域；- 不要在
OnTimer里写耗时逻辑，否则下一次定时消息会被推迟。
2.5 窗口销毁时回收定时器
窗口关闭时，最好显式杀掉定时器：
void CXXXDlg::OnDestroy() { KillTimer(ID_TIMER_REFRESH); m_bTimerRunning = false; CDialogEx::OnDestroy(); }虽然系统在定时器关联的窗口销毁后会清理资源，但显式KillTimer是更安全的习惯。尤其当定时器回调里会访问窗口成员变量时，如果不清理，窗口销毁后可能访问到无效对象。
3. 别急着调快间隔：先解决刷爆 UI 的几个坑
3.1 为什么定时器不是越快越好
WM_TIMER是低优先级消息。系统在忙碌时不会保证每个间隔都产生消息；如果上一次WM_TIMER还在队列里，新通知可能被合并。所以，SetTimer只适合“周期性提醒”，不适合“精确计时”。
在真实项目里，把刷新间隔设为 50ms，实际触发可能是 50ms 到 100ms 之间的某个值。如果只是日志展示，这没什么问题；但如果要画实时曲线、做输入捕获、做高精度测量，就应该另选方案。很多人一遇到“刷新不够快”就调小定时器间隔，其实是走错了方向。你需要的往往是减少单次刷新的工作量，而不是让定时器更频繁地跑。
3.2 列表无限增长是隐形炸弹
如果只把字符串不断AddString，不去管列表项数量，程序运行一小时后，列表里可能积累几千项。CListBox内部需要维护字符串数组和绘制区域，项数越多，添加和重绘都会变慢。更麻烦的是，用户会看到列表框越来越长，记忆负担也会变大。
我的建议是：从第一版开始就加上最大行数。新消息到达后，如果超过设定上限，就把最旧的记录删掉。这个策略虽然粗暴，但对日志窗口非常有效。你可以在类里定义一个常量，例如MAX_LOG_LINES = 200，让列表始终保持在可控范围。
3.3 高频刷新时用 SetRedraw 暂时关闭重绘
假设一次从缓冲区拿到 50 条日志，你直接循环调用AddString，控件会触发 50 次潜在的绘制。实际上，AddString不一定每次都立刻重绘，但多次修改控件内容后，绘制成本依然存在。更稳妥的做法是先关闭重绘，批量写入，再恢复：
m_listLog.SetRedraw(FALSE); for (int i = 0; i < arr.GetCount(); i++) { m_listLog.AddString(arr[i]); } while (m_listLog.GetCount() > MAX_LOG_LINES) { m_listLog.DeleteString(0); } m_listLog.SetRedraw(TRUE); m_listLog.Invalidate();注意SetRedraw(FALSE)和SetRedraw(TRUE)必须成对。如果中间有一行代码提前return，就很容忘记恢复。恢复后调用Invalidate()，是为了确保控件重新绘制。经验是：定时器里的刷新函数，尽量设计成“一次性把准备好的数据全部写完”，不要在OnTimer里做大量字符串拼接、文件读取、网络请求。如果数据源需要耗时获取，让工作线程去做，完成后发消息给 UI。
经验：如果某个更新逻辑可能提前退出，可以用简单的作用域类来管理
SetRedraw状态，保证析构时恢复。刚开始不需要过度设计，但至少要在正常路径上保证成对调用。
3.4 跨线程调用 ListBox 是最隐蔽的崩溃源
常见场景是串口接收线程或 Socket 接收线程拿到数据，直接调用m_listLog.AddString(...)。这在 MFC 里不一定立刻崩溃，但会产生随机问题：界面不刷新、句柄无效、内存越界。原因是控件属于 UI 线程，跨线程操作窗口不是安全行为。
正确做法有两种：
- 把数据先放入线程安全缓冲区，然后由
OnTimer在 UI 线程里取数据并更新列表； - 在工作线程里向主窗口
PostMessage一条自定义消息，把字符串指针或数据引用传给 UI 线程。
要特别提醒的是：定时器不是线程，它只是消息循环的一部分。把数据生产放在OnTimer里，UI 线程会被数据源拖住；把 UI 更新放在数据线程里，又会破坏窗口消息模型。所以，更好的位置中间加一个安全缓冲。
3.5 多个定时器 ID 冲突
如果程序里还有其他定时器，比如光标闪烁、状态检查、心跳包检测，都要使用不同的 ID。OnTimer里先判断nIDEvent，再分支处理。ID 一旦冲突，不同逻辑会混在一起，排查起来非常痛苦。建议用枚举或宏集中管理定时器 ID，比如：
#define TIMER_ID_REFRESH_LIST 1 #define TIMER_ID_HEARTBEAT 2 #define TIMER_ID_CURSOR_FLASH 3这样代码可读性更高，也不容易在多个文件里产生魔法数字。
4. 升级：定时器 + 缓冲区 + 批量刷新
4.1 为什么需要一个缓冲区
假设有一个后台线程持续产生文本行，我们想每 500ms 在列表框中展示一批新消息。如果后台线程每来一条直接更新 UI，会有两个问题：一是跨线程访问不安全，二是一次只更新一条会导致重绘频繁。
引入缓冲区后，数据生产端只负责写入缓冲区，UI 定时器只负责“把缓冲区内容倒进ListBox”。生产者和 UI 通过锁或队列解耦，各管一段。
4.2 一个简单的日志缓冲区实现
用 MFC 的CStringArray和CCriticalSection做一个极简版本。需要包含<afxmt.h>：
class CLogBuffer { public: CLogBuffer() {} ~CLogBuffer() {} void Append(LPCTSTR szText) { CSingleLock lock(&m_cs,
