1. 项目概述：Windows GDI文本绘制的基石

在Windows桌面应用开发中，界面上的每一个文字都不是凭空出现的。无论是记事本里的一段话，还是资源管理器中的一个文件名，其背后都离不开图形设备接口（GDI）的文本绘制功能。对于刚接触Windows GUI编程的开发者来说，TextOut和DrawText这两个API函数几乎是绕不开的“老朋友”。它们看似简单，一个负责在指定位置输出字符串，另一个能处理多行文本和格式化，但实际用起来，里面的门道可不少。选错了函数，或者参数没设对，轻则文本显示效果不佳、性能低下，重则可能导致界面闪烁、内存泄漏甚至程序崩溃。

我自己在早期做项目时就踩过不少坑。比如，用TextOut去画一个长段落，结果所有文字都挤在一行，超出客户区部分直接“消失”了；又或者，用DrawText时没处理好DT_CALCRECT标志，导致动态计算出的矩形区域总是不对，文本排版乱七八糟。这些经历让我意识到，这两个函数绝非“调用一下就行”那么简单。它们代表了两种不同的文本绘制哲学：TextOut是精准的“点对点”绘制，给你最大的控制权，但也把排版、换行这些“脏活累活”都留给了你；而DrawText更像一个“文本排版小助手”，内置了换行、对齐、裁剪等常见功能，用起来省心，但灵活性相对受限。

理解它们，不仅仅是记住函数原型，更要明白其背后的GDI文本绘制模型、设备上下文（DC）的状态影响，以及如何根据不同的场景做出最合适的选择。这篇文章，我就结合自己十多年的踩坑和填坑经验，把TextOut和DrawText从原理到实践，从基本用法到高级技巧，彻底讲透。无论你是正在学习Win32 API的新手，还是需要优化现有代码的老手，相信都能从中找到有用的东西。

2. 核心原理与设计思路拆解

2.1 GDI文本绘制模型：一切的基础

在深入两个函数之前，必须先把Windows GDI的文本绘制模型搞清楚。你可以把设备上下文（Device Context, DC）想象成一张画布和一套绘画工具的集合。当我们调用TextOut或DrawText时，并不是直接往屏幕上“戳”字，而是通过当前选入DC的“工具”在这张“画布”上作画。

这套“工具”里，直接影响文本外观的有几个关键属性：

1. 字体（Font）：这是最重要的工具，决定了文字的“长相”（如宋体、Arial）、大小、粗细（是否加粗）、样式（是否斜体）。你必须通过SelectObject函数将一种字体选入DC，后续的文本绘制才会使用这种字体。如果没选，GDI会使用一个默认的系统字体（通常是“System”），这往往不是你想要的效果。
2. 文本颜色（Text Color）：通过SetTextColor设置，它决定了文字笔画本身的颜色。
3. 背景模式（Background Mode）：通过SetBkMode设置。这是极易被忽略但至关重要的设置。它有两种模式：
   • OPAQUE（不透明）：在绘制文本前，会用当前背景色（通过SetBkColor设置）填充文本字符的矩形背景区域。这会导致文字背后有一块纯色矩形，可能会覆盖掉背景图像或其他内容。
   • TRANSPARENT（透明）：只绘制文字笔画，背景区域保持原样。这是大多数现代UI场景下的首选，能让文字自然地叠加在背景之上。
4. 背景色（Background Color）：当背景模式为OPAQUE时，此颜色用于填充文本背景矩形。
5. 文本对齐方式（Text Alignment）：通过SetTextAlign设置。它决定了你传递给TextOut的坐标点（x, y）与文本矩形之间的对齐关系。例如，是坐标点对应文本矩形的左上角、基线左端，还是右下角？错误的对齐设置会导致文本位置严重偏离预期。

TextOut和DrawText都工作在这个模型之下。它们共享DC的当前状态。因此，一个常见的错误是只关注函数调用本身，而忽略了DC的前置状态配置。一个黄金法则是：在绘制文本前，务必显式地、逐一地设置好DC的字体、文本颜色和背景模式。不要依赖DC的默认或未知的残留状态。

2.2 TextOut：精准控制的“狙击步枪”

TextOut的函数原型非常直接：

BOOL TextOut( HDC hdc, // 设备上下文句柄 int x, // 文本起始位置的x坐标（逻辑单位） int y, // 文本起始位置的y坐标（逻辑单位） LPCWSTR lpString, // 要绘制的字符串 int cchString // 字符串长度 );

它的设计哲学是“简单粗暴”：在指定的逻辑坐标点（x, y）开始，绘制指定长度的字符串。它不关心字符串是否太长，也不管是否需要换行，更不会帮你做对齐（除了受SetTextAlign影响）。它只管“画”。

这种设计的优势在于极致的高性能和低开销。因为它内部逻辑简单，没有复杂的排版计算，所以绘制速度极快。在需要频繁绘制大量静态文本、或者在对实时性要求极高的场景（如游戏HUD、动态图表的数据标签）中，TextOut是首选。

但优势也带来了责任。使用TextOut，开发者需要自己处理所有高级排版功能：

• 换行：你需要自己计算字符串宽度（用GetTextExtentPoint32），判断是否超出边界，然后手动分割字符串，并在下一行调整y坐标再次调用TextOut。
• 对齐：除了基本的左对齐（通过坐标控制），要实现右对齐或居中，你需要先计算文本总宽度，然后从目标矩形的右边或中心反推起始x坐标。
• 裁剪：如果文本超出绘制区域，你需要自己通过IntersectClipRect设置裁剪区域，或者先进行边界判断。

所以，TextOut就像一把狙击步枪。它精度高、响应快，但要求射手（开发者）自己计算风速、距离（排版逻辑）。

2.3 DrawText：功能集成的“瑞士军刀”

DrawText的函数原型则复杂得多，因为它承载了更多功能：

int DrawText( HDC hdc, // 设备上下文句柄 LPCTSTR lpString, // 字符串 int nCount, // 字符串长度（-1表示自动计算到NULL结尾） LPRECT lpRect, // 定义绘制区域的矩形 UINT uFormat // 文本格式选项 );

它的设计哲学是“开箱即用”。你给它一个矩形区域（lpRect）和一堆格式标志（uFormat），它就能在这个矩形里帮你把文本安排好、画出来。

它的核心能力体现在uFormat参数这个庞大的标志集合里，主要包括：

• 换行与矩形控制：DT_WORDBREAK（在单词边界处自动换行）、DT_EDITCONTROL（模拟多行编辑控件的换行行为）、DT_END_ELLIPSIS/DT_PATH_ELLIPSIS（文本太长时用“...”省略）。
• 对齐方式：DT_LEFT（左对齐）、DT_RIGHT（右对齐）、DT_CENTER（水平居中）、DT_TOP（顶部对齐）、DT_VCENTER（垂直居中）、DT_BOTTOM（底部对齐）。
• 单行处理：DT_SINGLELINE（强制单行显示，此时垂直对齐标志才有效）。
• 矩形计算：DT_CALCRECT（这是一个极其有用的标志）。当设置此标志时，DrawText不会执行任何绘制操作，而是根据给定的矩形宽度（或高度）和格式要求，计算出容纳文本所需的最小矩形尺寸，并更新lpRect的bottom（或right）成员。这在动态布局中必不可少。
• 其他：DT_NOPREFIX（禁止将“&”字符处理为快捷键前缀）、DT_EXTERNALLEADING（在行高计算中包含字体外部行间距）。

DrawText就像一把瑞士军刀，集成了多种常用工具。你不需要自己写换行算法、对齐计算，大部分需求通过组合标志就能实现。这在开发通用UI控件（如按钮、标签、列表框）、处理用户输入的多行文本、实现动态大小的文本区域时，能节省大量代码，减少错误。

然而，它的便利性是有代价的。由于其内部需要根据标志进行复杂的布局计算，其性能开销明显高于TextOut。在需要快速、大量绘制文本的场景中，频繁调用DrawText可能成为性能瓶颈。

2.4 核心选择逻辑：何时用谁？

基于以上分析，我们可以得出清晰的选择策略：

实操心得：在实际项目中，我通常会采用混合策略。在窗体的WM_PAINT消息处理中，对于大量、静态的文本元素（如列表项、网格数据），使用TextOut进行批量绘制以优化性能。而对于那些需要复杂格式、动态布局的文本块（如状态栏信息、弹窗提示），则使用DrawText来简化代码逻辑。记住，没有绝对的好坏，只有适合与否。

3. 核心细节解析与实操要点

3.1 TextOut的坐标系统与对齐陷阱

TextOut的x和y参数使用的是设备上下文的当前逻辑坐标。这意味着它们受SetMapMode、SetViewportOrg等坐标变换函数的影响。在默认的MM_TEXT映射模式下，一个逻辑单位对应一个像素，原点(0,0)在客户区的左上角，x向右递增，y向下递增。

最容易出问题的是y坐标。它指定的是文本基线的位置，而非文本矩形顶边的位置。英文字母如“y”、“g”的下沉部分（descender）会绘制在基线以下，而大写字母和上行部分（ascender）在基线以上。如果你误以为y是文本顶部坐标，那么不同字体的文本可能会无法在视觉上对齐。

解决方案：如果需要精确地将文本顶部对齐到某个y坐标，你需要先获取字体的度量信息。

TEXTMETRIC tm; GetTextMetrics(hdc, &tm); int yTop = yDesired + tm.tmAscent; // 将期望的顶部坐标转换为基线坐标 TextOut(hdc, x, yTop, L"Hello", 5);

这里，tm.tmAscent是从基线到字符顶部的距离。

另一个陷阱是SetTextAlign。它的默认值通常是TA_LEFT | TA_TOP | TA_NOUPDATECP。TA_LEFT和TA_TOP意味着你提供的(x,y)坐标对应文本矩形的左上角（注意，这里的“TOP”在默认MM_TEXT且背景透明模式下，实际参考的是字符单元框的左上角，与基线无关，这本身就是一个容易混淆的点）。如果你不小心改成了TA_BASELINE，那么y坐标就会参考基线，而x坐标的参考点也可能因TA_CENTER或TA_RIGHT而改变，导致文本“乱飞”。

注意事项：在调用TextOut前，最好显式调用一次SetTextAlign(hdc, TA_LEFT | TA_TOP | TA_NOUPDATECP)来重置为最常用的对齐方式，避免受到其他代码段对DC状态的影响。这是一个良好的防御性编程习惯。

3.2 DrawText的矩形与标志位详解

DrawText的lpRect参数是一个指向RECT结构的指针，它定义了文本绘制的“舞台”。这个矩形的理解至关重要。

• 输入矩形：在调用时，它指定了文本可以布局的最大边界。DrawText会根据uFormat标志，将文本排列在这个矩形内。
• 输出矩形（当使用DT_CALCRECT时）：如果包含了DT_CALCRECT标志，函数会修改这个矩形（通常是right或bottom成员），返回恰好能容纳文本的矩形尺寸。一个关键细节是：DT_CALCRECT必须与DT_WORDBREAK或DT_SINGLELINE等标志结合使用，否则计算可能不准确。

uFormat标志可以组合使用，但有些组合是互斥或无意义的。例如：

• DT_LEFT、DT_RIGHT、DT_CENTER是互斥的，只能选一个。
• DT_TOP、DT_VCENTER、DT_BOTTOM是互斥的，只能选一个。并且，它们仅在同时指定了DT_SINGLELINE标志时才有效！对于多行文本，垂直对齐是无效的，文本总是从矩形顶部开始绘制。
• DT_WORDBREAK用于多行换行，而DT_SINGLELINE用于强制单行。它们也是互斥的。

一个高级技巧：使用DT_MODIFYSTRING标志。当与DT_END_ELLIPSIS或DT_PATH_ELLIPSIS一起使用时，DrawText会直接修改你提供的字符串缓冲区，插入省略号“...”。这非常方便，但务必确保你传入的缓冲区有足够的空间（通常需要额外3个字符的空间来存放“...”），并且该缓冲区是可写的。如果传入的是字符串常量，会导致访问违规崩溃。

3.3 字体选择与文本度量

无论使用哪个函数，字体选择都是第一步，也是最关键的一步。使用CreateFont或CreateFontIndirect创建逻辑字体，然后用SelectObject将其选入DC。务必保存旧的字体句柄，在绘制完成后用SelectObject将其选回DC。这是一个经典的GDI资源管理规范，防止资源泄漏和状态污染。

HFONT hOldFont = (HFONT)SelectObject(hdc, hMyFont); // ... 进行文本绘制操作 ... SelectObject(hdc, hOldFont); // 恢复旧字体

获取文本的尺寸对于布局计算至关重要。

• GetTextExtentPoint32：最常用，用于计算指定字符串在DC当前字体下的宽度和高度（以逻辑单位）。对于TextOut的手动换行和居中计算，这是必备函数。
• GetTextMetrics：获取当前选中字体的全局度量信息，如字符高度（tmHeight）、上行高度（tmAscent）、下行高度（tmDescent）、平均字符宽度（tmAveCharWidth）等。这对于计算行高、基线位置等非常有用。
• DrawTextwithDT_CALCRECT：这是计算一段多行文本整体占据矩形区域的最便捷方法，尤其当文本包含换行符或需要自动换行时。

实操心得：在复杂布局中，我经常混合使用这些方法。例如，先用GetTextMetrics确定标准行高，再用DrawText和DT_CALCRECT计算某段文本的精确宽度和高度，最后用TextOut在计算好的位置进行高性能绘制。不要局限于一个函数。

3.4 双缓冲与减少闪烁

在WM_PAINT消息处理中直接绘制文本，如果区域较大或内容复杂，很容易引起界面闪烁。这是因为GDI直接向屏幕DC绘制，中间过程用户可能看到。

双缓冲技术是解决闪烁的终极方案。其原理是：先在内存中的一个“兼容位图DC”上完成所有绘制操作，然后将这个位图一次性“贴”到屏幕DC上。

case WM_PAINT: { PAINTSTRUCT ps; HDC hdc = BeginPaint(hWnd, &ps); // 1. 创建内存兼容DC HDC hMemDC = CreateCompatibleDC(hdc); // 2. 创建与客户区同样大小的兼容位图 RECT rcClient; GetClientRect(hWnd, &rcClient); HBITMAP hBmp = CreateCompatibleBitmap(hdc, rcClient.right, rcClient.bottom); HBITMAP hOldBmp = (HBITMAP)SelectObject(hMemDC, hBmp); // 3. 可选：用背景色填充内存DC（模拟背景） FillRect(hMemDC, &rcClient, (HBRUSH)GetStockObject(WHITE_BRUSH)); // 4. 在内存DC上进行所有文本绘制（使用TextOut或DrawText） // ... 你的绘制代码 ... // 5. 将内存DC内容一次性传输到屏幕DC BitBlt(hdc, 0, 0, rcClient.right, rcClient.bottom, hMemDC, 0, 0, SRCCOPY); // 6. 清理资源 SelectObject(hMemDC, hOldBmp); DeleteObject(hBmp); DeleteDC(hMemDC); EndPaint(hWnd, &ps); } break;

对于文本绘制，双缓冲不仅能消除闪烁，还能将多次独立的TextOut/DrawText调用合并为一次BitBlt操作，显著提升复杂界面的绘制性能。这是开发流畅桌面应用的必备技能。

4. 实操过程与核心环节实现

4.1 场景一：实现一个高性能的日志列表控件

假设我们需要实现一个类似控制台或日志查看器的控件，需要快速、连续地追加多行文本。

设计思路：性能是关键。我们将使用TextOut进行绘制，并自己维护换行逻辑。为了快速滚动，我们还需要支持只绘制无效区域。

步骤实现：

1. 数据结构：维护一个std::vector<std::wstring>来存储所有日志行。同时，维护一个std::vector<int>存储每一行在特定字体下的像素高度（用于快速计算滚动位置）。
2. 字体与度量：在初始化时，创建等宽字体（如Consolas），并获取其TEXTMETRIC，特别是tmHeight（行高）和tmExternalLeading（建议的行间距）。
3. 添加日志：

   void LogView_AddLine(HDC hdc, const std::wstring& line) { // 1. 将行存入数组 logLines.push_back(line); // 2. 计算该行是否需要换行（假设控件宽度为clientWidth） SIZE size; GetTextExtentPoint32(hdc, line.c_str(), line.length(), &size); int lineHeight = tm.tmHeight + tm.tmExternalLeading; if (size.cx > clientWidth) { // 需要手动换行：这里简化处理，按字符数粗略分割 // 实际应用中应使用更精细的按单词或字符边界分割算法 int charsPerLine = clientWidth / tm.tmAveCharWidth; for (size_t i = 0; i < line.length(); i += charsPerLine) { std::wstring sub = line.substr(i, charsPerLine); logLines.push_back(sub); lineHeights.push_back(lineHeight); } } else { lineHeights.push_back(lineHeight); } // 3. 标记需要重绘的区域（通常是最后一行对应的矩形区域） InvalidateRect(hWnd, &rectOfLastLine, FALSE); }

4. 绘制（WM_PAINT）：

   // ... 使用双缓冲 ... // 计算当前可见区域（基于滚动条位置） int startY = -scrollPosY; int currentY = startY; for (size_t i = 0; i < logLines.size(); ++i) { int lineY = currentY; currentY += lineHeights[i]; // 判断该行是否在裁剪区域内（ps.rcPaint） if (lineY + lineHeights[i] < ps.rcPaint.top || lineY > ps.rcPaint.bottom) { continue; // 不在可见区域，跳过 } // 绘制该行 TextOut(hMemDC, MARGIN_LEFT, lineY, logLines[i].c_str(), logLines[i].length()); } // ... BitBlt ...

核心要点：通过GetTextExtentPoint32预计算宽度，自己管理换行和行高数组，在绘制时根据裁剪区域跳过不可见行，并采用双缓冲。这套组合拳能保证即使有上万行日志，滚动和追加依然流畅。

4.2 场景二：实现一个支持自动换行和居中的文本标签控件

这是一个更常见的UI控件需求，文本内容可能变化，控件大小也可能变化，文本需要自动适应。

设计思路：使用DrawText是更合适的选择，因为它内置了换行、对齐和矩形计算。

步骤实现：

1. 控件状态：存储文本字符串、字体句柄、对齐方式标志、控件矩形。
2. 计算理想大小（WM_MEASUREITEM或自布局时）：

   void Label_CalculateIdealSize(HDC hdc, const std::wstring& text, int maxWidth, SIZE* pSize) { RECT rcCalc = {0, 0, maxWidth, 0}; // 高度设为0，让DrawText计算所需高度 UINT format = DT_WORDBREAK | DT_CALCRECT | DT_LEFT; // 假设左对齐 DrawText(hdc, text.c_str(), -1, &rcCalc, format); pSize->cx = rcCalc.right - rcCalc.left; pSize->cy = rcCalc.bottom - rcCalc.top; }

   这个函数返回在给定最大宽度下，显示完整文本所需的最小矩形尺寸。你可以用这个尺寸来设置控件的大小。
3. 绘制文本（WM_PAINT）：

   void Label_Paint(HDC hdc, const RECT& rcClient, const std::wstring& text, HFONT hFont, UINT alignFlags) { HFONT hOldFont = (HFONT)SelectObject(hdc, hFont); SetBkMode(hdc, TRANSPARENT); // 通常标签背景透明 SetTextColor(hdc, RGB(0, 0, 0)); // 设置文本颜色 RECT rcDraw = rcClient; // 组合对齐标志。注意：垂直对齐标志只在DT_SINGLELINE时有效。 // 对于多行标签，我们通常只需要水平对齐和顶部对齐。 UINT format = DT_WORDBREAK | DT_TOP | alignFlags; // alignFlags 如 DT_LEFT, DT_CENTER, DT_RIGHT DrawText(hdc, text.c_str(), -1, &rcDraw, format); SelectObject(hdc, hOldFont); }

4. 处理文本更新：当文本或控件大小改变时，调用InvalidateRect触发重绘即可。DrawText会在新的矩形内重新布局文本。

优势：代码极其简洁。所有复杂的换行、对齐逻辑都交给了DrawText。开发者只需要关心内容和外观属性。

注意事项：DrawText在计算DT_CALCRECT时，返回的矩形高度可能包含最后一行文字的下沉部分（descender）。如果你希望行与行之间有一些额外的间距，可以在计算结果上手动增加一个偏移量。另外，对于单行文本并需要垂直居中时，务必加上DT_SINGLELINE和DT_VCENTER标志。

4.3 场景三：混合使用以优化复杂界面绘制

在一个复杂的表单设置对话框中，可能有静态标题（固定位置）、动态帮助提示（多行，自适应大小）和大量属性网格项（需要快速绘制）。

优化策略：

• 静态标题：在对话框初始化时，用DrawText和DT_CALCRECT计算好每个标题的位置和大小，并将结果存储起来。在WM_PAINT中，直接使用存储的坐标和TextOut进行绘制。避免在每次绘制时都重新计算。
• 动态帮助提示：当鼠标移动到某个控件上时，显示帮助文本。这个文本块使用DrawText绘制，因为它需要自动换行，并且可能根据内容调整提示框的大小（结合DT_CALCRECT）。
• 属性网格：这是一个典型的大量文本项场景。每个属性有“名称”和“值”两列。在WM_PAINT中，使用TextOut批量绘制所有可见行的文本。可以预先为每一列计算好x坐标，在循环中只改变y坐标进行绘制。对于可能过长的值，可以提前用DrawText和DT_END_ELLIPSIS | DT_CALCRECT | DT_SINGLELINE计算截断后的字符串和显示宽度，然后将处理好的字符串用TextOut绘制，避免在绘制循环中调用更耗时的DrawText。

这种混合模式，将DrawText用于离线的布局计算和字符串处理，将TextOut用于在线的、批量的高性能绘制，能很好地平衡开发效率和运行时性能。

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

即使理解了原理，在实际编码中还是会遇到各种奇怪的问题。下面是我总结的一些典型“坑”及其解决方法。

5.1 文本不显示或显示乱码

• 问题描述：调用了函数，但窗口上什么都没有，或者显示一堆问号“???”或乱码。
• 排查步骤：
  1. 检查DC和句柄：确保传入的hdc是有效的。在WM_PAINT中，必须使用BeginPaint获得的DC，或者在WM_CTLCOLOR等消息中使用给定的DC。自己用GetDC获得的DC，用完必须ReleaseDC。
  2. 检查字符串和长度：对于TextOut，确保cchString参数正确。如果字符串以NULL结尾，可以传-1（仅TextOutW在特定条件下？注意：TextOut的cchString应传实际长度，而DrawText的nCount可以传-1表示自动计算）。最稳妥的做法是始终传入明确的长度，如lstrlen(str)。
  3. 字符集问题（乱码）：这是最常见的问题。Win32 API有TextOutA(ANSI)和TextOutW(Unicode)两个版本。确保你的项目字符集设置（在Visual Studio中是“项目属性 -> 配置属性 -> 高级 -> 字符集”）与你的代码和字符串字面量匹配。
     • 如果项目设置为“使用Unicode字符集”，则调用TextOut会被编译为TextOutW，你需要使用L"字符串"或_T("字符串")（如果定义了UNICODE）。
     • 如果设置为“使用多字节字符集”，则编译为TextOutA，使用普通字符串。
     • 强列推荐：所有新项目都应使用Unicode字符集。在代码中，使用TCHAR相关宏（如_T()）或直接使用wchar_t和L前缀来保证一致性。
  4. 检查字体：确保已成功创建字体并用SelectObject选入了DC。一个简单的测试方法是，在绘制代码后立刻调用GetTextMetrics，看看返回的字体信息是否是你创建的字体。

5.2 文本位置不对

• 问题描述：文本没有出现在预期的坐标位置。
• 排查步骤：
  1. 确认坐标系统：检查是否在之前改变了映射模式（SetMapMode）。除非有特殊需求，否则在绘制文本时保持默认的MM_TEXT模式。
  2. 检查SetTextAlign：调用SetTextAlign(hdc, TA_LEFT | TA_TOP | TA_NOUPDATECP)重置对齐方式。TA_NOUPDATECP很重要，它阻止TextOut调用后更新DC的当前位置，避免影响后续其他绘制操作。
  3. 理解TextOut的y坐标：记住y是基线位置。如果你希望文本矩形的顶部在yDesired，那么TextOut的y参数应该是yDesired + tm.tmAscent。
  4. 对于DrawText：检查RECT参数的值是否正确。特别是right和bottom成员，它们代表的是矩形** exclusive **的边界（即不包含右/下边线）。一个常见的错误是将宽度赋值给right，实际上right应该是left + width。

5.3 背景色覆盖了原有内容

• 问题描述：文字显示出来了，但文字后面有一块纯色矩形，把背景图片或其他控件遮住了。
• 原因与解决：这是因为DC的背景模式被设置成了OPAQUE。在大多数情况下，我们需要的是透明背景。

  SetBkMode(hdc, TRANSPARENT); // 在绘制文本前调用

  如果你确实需要不透明背景（比如高亮选中文本），那么记得通过SetBkColor设置一个合适的背景色。

5.4 DrawText的DT_CALCRECT计算不准确

• 问题描述：使用DT_CALCRECT计算出的矩形高度或宽度与预期不符，导致布局错位。
• 排查步骤：
  1. 检查字体：确保计算时DC中选中的字体与最终绘制时使用的字体一致。
  2. 检查标志组合：DT_CALCRECT必须与DT_WORDBREAK（多行）或DT_SINGLELINE（单行）一起使用，否则函数可能无法正确计算换行。
  3. 理解矩形参数：传入的RECT，其left和top通常为0或起始坐标，right应设置为允许的最大宽度，bottom应设置为一个足够大的值（或者0，函数会忽略并更新它）。函数会修改right和bottom。计算出的宽度是rc.right - rc.left，高度是rc.bottom - rc.top。
  4. 外部行间距（External Leading）：默认情况下，DrawText计算的高度不包含字体度量中的tmExternalLeading。如果你希望行间距更大，可以添加DT_EXTERNALLEADING标志，或者手动在计算结果上增加一个偏移。

5.5 性能问题

• 问题描述：界面滚动或更新时卡顿，CPU占用高。
• 优化方向：
  1. 减少不必要的绘制：在WM_PAINT中，只绘制ps.rcPaint指定的无效区域。对于列表类控件，计算哪些行在无效区域内，只绘制这些行。
  2. 使用双缓冲：如前所述，这是消除闪烁和提升批量绘制性能的有效手段。
  3. 缓存布局信息：对于静态文本或变化不频繁的文本，不要每次WM_PAINT都调用GetTextExtentPoint32或DrawTextwithDT_CALCRECT。在文本内容改变时计算一次，并将结果（坐标、尺寸、甚至预处理的字符串）缓存起来。
  4. 评估函数选择：在需要绘制大量文本的循环中，将DrawText替换为TextOut，并自己管理简单的布局，通常能获得可观的性能提升。
  5. 检查字体创建：避免在绘制循环中频繁创建和销毁字体（CreateFont,DeleteObject）。在初始化时创建好所需字体，在整个生命周期内重复使用。

掌握TextOut和DrawText，本质上是在掌握Windows GDI文本绘制的平衡艺术。在控制与便利、性能与功能之间，根据具体场景做出最合适的选择。经过这些年的项目锤炼，我的体会是，越是基础的API，越值得深挖。它们构建了上层所有华丽框架的基石，理解透彻了，无论遇到多古怪的显示问题，你都能从容地向下追踪，找到那个被错误设置的标志或那个被误解的坐标，从而真正地掌控你的程序界面。