企业官网建设流程全解析

不用先翻MSDN，先把这段代码跑起来再说。在Win32 GDI里，凡是做界面、搞自绘控件、写绘图工具的人，基本都绕不开DrawText这个函数。它做的事情听起来很简单：把一段字符串画进一个矩形区域里，但如果只用过最基础的调用方式，你十有八九会在换行、对齐、动态算高度、DPI适配这些地方卡壳。这篇就把DrawText从参数到底层行为、从最小示例到实际坑位完整过一遍。

1. 为什么文本绘制绕不开DrawText

1.1 它就是很多框架的地基

很多人以为窗口标题是Windows自己画出来的，控件文字也都是系统封装好了。但一旦你开始做自绘按钮、自定义列表、仪表盘、报表引擎、CAD标注，就会发现最终落到屏幕上的所有文字，底层几乎都会经过DrawText或者它的近亲ExtTextOut、TextOut。有些高级框架可能封装了DirectWrite，但老一代软件、工控界面、轻量工具，依然大量使用基于GDI的DrawText，原因很简单：足够快、足够稳、依赖少。

我见过不少用界面库的人，遇到中文乱码或者文字排版不对，翻来覆去查库文档，最后定位到源头，其实还是DrawText处理不当。理解了DrawText，很多界面问题就等于找到了关键入口。

1.2 它和其他文本API的分工

每个人刚开始学GDI文本输出时，多半会从TextOut开始，因为它只需要坐标点，不用传矩形。TextOut适合那种“我在(100, 50)这个位置画一句话”的场景，不做任何排版。ExtTextOut比TextOut多一些选项，支持字符间距和裁剪，但本质还是按指定位置输出。DrawText则完全不一样，它强调的是区域排版：你给我一个矩形，告诉我文字怎么对齐、怎么换行、超了怎么截断，剩下的交给我处理。

2. 函数签名与每个参数的实际意义

2.1 完整签名与参数解读

DrawText的常用版本有两种：DrawTextA对应ANSI编码，DrawTextW对应UTF-16宽字符编码。在Visual Studio默认的Unicode工程里，你写DrawText，实际上编译到了DrawTextW。原型如下：

int DrawText( HDC hdc, // 设备上下文句柄 LPCWSTR lpchText, // 要绘制的字符串 int cchText, // 字符串长度，-1表示自动计算 LPRECT lprcRect, // 目标矩形区域 UINT uFormat // 格式控制标志 );

先逐个理解，别急着抄代码。

• hdc：当前要绘制的画布。窗口客户区用BeginPaint或者GetDC拿到的HDC，内存位图用CreateCompatibleDC创建的兼容DC，打印机DC也可以直接用。
• lpchText：字符串指针。这里要特别注意，如果你用的是简体中文系统加Unicode编译，字符串要带上L前缀，例如L"你好，GDI"。
• cchText：要画的字符个数。传-1时函数自动根据字符串的终止符计算长度。多数情况下传-1就行，但如果你明确知道长度，或者字符串中间有多个\0却想全部输出，就需要自己给真实长度。
• lprcRect：矩形指针。它既是“绘制范围”，也是“排版容器”。绘制的文字会在这个矩形内进行对齐和换行。这里有个很多人忽略的细节：函数返回值是文字实际绘制的高度（像素），而这个矩形对象本身的内容不会被改掉。
• uFormat：一系列以DT_开头的常量，用位运算组合。你需要从里面选一个水平对齐、一个垂直对齐、一个换行策略，其他按需加。

2.2 矩形区域的物理意义与坐标转换

很多初学者喜欢直接填一个“看起来差不多大”的矩形，然后发现画出来的文字位置总差一截。原因在于DrawText的矩形是逻辑坐标里的矩形，它受当前映射模式、窗口原点偏移、DC裁剪区同时约束。

在默认的MM_TEXT映射模式下，逻辑单位等于像素，矩形坐标就是客户区坐标，这是最常见也最好理解的情况。如果你在别的地方改了SetMapMode，比如用了MM_ISOTROPIC做视口缩放，那矩形坐标必须跟着当前逻辑坐标系走。自绘控件里最常见的错误就是：从父窗口拿到相对坐标，却在子窗口DC里直接用，导致文字被画到预期位置之外。

举个例子，在一个自绘按钮里绘制文字时，客户区矩形的左上角通常不是(0, 0)，而是(0, 0)。但如果你在WM_PAINT里用GetClientRect，拿到的一定是当前控件自己的客户区，这个没问题。绘图前最好还要配合GetClipBox确认一下实际可视区域，避免出现文字画到矩形外被裁剪的怪问题。

2.3 uFormat常用标志位拆解

DrawText的格式标志位很多，但不是每个都用得上。按功能分几个组来记会容易很多。

水平对齐组：

• DT_LEFT：默认左对齐。
• DT_CENTER：文字水平居中。注意这里居中的参考线是整个矩形，而不是字符本身的视觉中心。
• DT_RIGHT：右对齐。

垂直对齐组：

• DT_TOP：默认顶部对齐。
• DT_VCENTER：垂直居中，仅在单行绘制时可靠。
• DT_BOTTOM：底部对齐。

换行与截断组：

• DT_WORDBREAK：按单词换行。英文场景很好用，中文场景则表现为按字符单位换行，因为中文没有明显的空格边界。
• DT_SINGLELINE：强制单行绘制，忽略换行符。
• DT_END_ELLIPSIS：如果文字超宽，在末尾显示省略号。
• DT_PATH_ELLIPSIS：路径风格省略，尽量保留后半段路径文本。
• DT_EDITCONTROL：模拟多行编辑控件的行为，对末尾空白行的处理更接近记事本。

裁剪与计算组：

• DT_NOCLIP：不做裁剪，允许文字画出矩形边界。这个标志在绘制文本用于测量时常用，但在实际绘制时容易把文字画到界面上，需要谨慎。
• DT_CALCRECT：只计算文字排版所需矩形尺寸，不真正绘制。这是动态布局的关键。

还有一个DT_NOPREFIX需要单说。默认情况下，DrawText会解析字符串里的“&”符号，把它当作助记符前缀，通常做法是给下一个字符加下划线，而且会把“&”本身吞掉。如果你在画路径名或者日志文本时发现字符串里的“&”莫名消失了，就是没加DT_NOPREFIX。这是很典型的隐蔽问题，排查半天才发现是这个标志位导致的。

3. 从零开始的完整绘制流程

3.1 最小示例：在客户区绘制一段居中文本

先写一个能直接运行的例子。假设我们创建一个窗口，在WM_PAINT里绘制一段文本，水平居中、垂直居中。

case WM_PAINT: { PAINTSTRUCT ps; HDC hdc = BeginPaint(hWnd, &ps); RECT rc; GetClientRect(hWnd, &rc); // 先设置字体，让绘制效果更清晰 HFONT hFont = CreateFont( 28, 0, 0, 0, FW_NORMAL, FALSE, FALSE, FALSE, DEFAULT_CHARSET, OUT_DEFAULT_PRECIS, CLIP_DEFAULT_PRECIS, DEFAULT_QUALITY, DEFAULT_PITCH | FF_SWISS, L"Microsoft YaHei"); HFONT hOldFont = (HFONT)SelectObject(hdc, hFont); // 设置文字颜色和背景模式 SetTextColor(hdc, RGB(30, 60, 120)); SetBkMode(hdc, TRANSPARENT); // 绘制居中文本 DrawText(hdc, L"Windows API 一日一练", -1, &rc, DT_CENTER | DT_VCENTER | DT_SINGLELINE); SelectObject(hdc, hOldFont); DeleteObject(hFont); EndPaint(hWnd, &ps); return 0; }

这段代码里有几个关键点。SelectObject把字体选入DC之后，后续文字绘制才会使用这个字体；用完要选回旧字体，再删除自己创建的字体对象。SetBkMode设为TRANSPARENT，可以让文字背后不出现白色背景块，这在叠加绘制、透明控件里几乎是必选项。

如果不加DT_SINGLELINE，那么DT_VCENTER在矩形较高时可能会失效。因为多行模式下，DrawText会把整段文本当作多行排版，垂直居中地作用于第一行或者最后一块区域，表现和直觉差异很大。想真正垂直居中，单行模式最可靠。

3.2 换行、截断与自动缩放：format组合的实战差异

多行绘制时最基础的做法是DT_WORDBREAK加DT_LEFT。假设有一段长文本要放进固定宽度区域，不做任何截断处理，看它如何换行。

RECT rcText = rc; rcText.left += 16; rcText.top += 16; rcText.right -= 16; rcText.bottom -= 16; DrawText(hdc, L"这是一段比较长的文本，用来演示DrawText的换行行为，" L"在没有显式使用\\n的情况下，如果启用WORD_BREAK，文本会按照" L"区域宽度自动换行。", -1, &rcText, DT_WORDBREAK | DT_LEFT | DT_NOPREFIX);

中文环境下，DT_WORDBREAK的“按单词”体现在中文时，其实是按字符进行换行，因为中文不具备空格分词结构。如果区域宽度太小，每个字符都放不下，GDI仍然会强行把溢出的字符画出去，因为换行需要至少一个完整单元。这也是为什么有时你把一个控件压得很窄，文字会横向溢出的原因。

如果你希望超宽内容以省略号收尾，组合是DT_END_ELLIPSIS。但要注意，单行模式和省略号同时使用时，才能真正稳定地画出一行加省略号。一旦加上DT_WORDBREAK，省略号行为可能变得不直观。通常我会把字符串长度限制在1000以内再启用ELLIPSIS，否则长文本的性能和显示效果都不够好。

还有一类场景值得单独说：既想要换行，又想要超宽时出省略号。直接同时使用DT_WORDBREAK和DT_END_ELLIPSIS并不是最优解，因为GDI对多行省略号的支持相当原始。更稳妥的做法是：先用DT_CALCRECT + DT_WORDBREAK算高度，判断是否超过容器高度，再决定用完整内容还是逐行截断。这个技巧在报表单元格压缩文本时特别好用。

3.3 计算文本高度与画布动态布局

动态布局是DrawText最常被低估的能力。很多自绘控件的尺寸需要根据内容高度自动伸缩，比如气泡提示、列表项高度、图例文本区。用DT_CALCRECT就能在绘制前得到精确的文本矩形高度。

它的用法很有意思：你传入一个初始RECT，设置宽度，调用后函数会修改这个RECT的高度和宽度，其中宽度保持不变，高度被设为内容实际所需高度。注意，DT_CALCRECT是“只计算不绘制”，它会忽略DT_CENTER、DT_VCENTER等对齐标志，因为这些标志只对实际绘制有意义。

RECT rcMeasure = {0, 0, 200, 0}; DrawText(hdc, L"根据当前字体计算这段文本实际需要多少行", -1, &rcMeasure, DT_CALCRECT | DT_WORDBREAK); int neededHeight = rcMeasure.bottom;

拿到neededHeight之后，就能动态调整控件高度或者让下方内容避让。这里有个经验：计算时用的字体必须和实际绘制时完全一致，否则高度结果可能会偏差3到8个像素。中文和英文字体、默认字体和微软雅黑，行高差异非常明显。

实际开发中，我常把这个逻辑封装成一个工具函数：

int MeasureTextHeight(HDC hdc, const std::wstring& text, int width) { RECT rc = {0, 0, width, 0}; DrawTextW(hdc, text.c_str(), (int)text.size(), &rc, DT_CALCRECT | DT_WORDBREAK | DT_NOPREFIX); return rc.bottom - rc.top; }

这个函数可以在任何需要“先量后画”的场景复用。注意字符串长度建议显式传入，避免字符串里含有嵌入式\0时自动计算长度产生偏差。

4. 字体、颜色和背景处理的组合玩法

4.1 字体选择与混排输出

字体是决定DrawText输出效果的首要因素。如果你直接使用系统默认字体，英文和数字显示还行，中文在低DPI下容易出现发虚和锯齿。更好的做法是创建业务字体，随窗口DPI变化动态调整字号。

字体的创建并不复杂，但有几个参数值得注意。nHeight用正值表示字符高度，负值表示字体高度包含行间距，通常我们会用正值，再配合GetDeviceCaps(hdc, LOGPIXELSY)计算实际像素高度，以便在不同缩放级别下保持一致。

int pixelHeight = -MulDiv(12, GetDeviceCaps(hdc, LOGPIXELSY), 72); HFONT hFont = CreateFont( pixelHeight, 0, 0, 0, FW_NORMAL, FALSE, FALSE, FALSE, DEFAULT_CHARSET, OUT_DEFAULT_PRECIS, CLIP_DEFAULT_PRECIS, CLEARTYPE_QUALITY, DEFAULT_PITCH | FF_SWISS, L"Microsoft YaHei");

这里用负的pixelHeight，是让字符整体在DC行高内垂直居中，如果使用正的pixelHeight，英文字体通常看起来会偏上。中文字体差异不大，但MFC里有两种风格混排时，建议统一用负数高度，视觉更稳。

混排输出时，很多人想的是在同一个DrawText里换字体，这是做不到的。DrawText接受的是DC当前选中的字体，你不能让一段文字前半部分用宋体、后半部分用雅黑。可行的方案是拆成多次DrawText，或者使用DrawTextEx配合字符范围数组设置，但后者效率低且控制繁琐。实际工程里，我更倾向拆矩形：先画左边的图标文字，再画右边的主文本，两个矩形宽度和位置都提前算好。

4.2 透明背景与渐变矩形内文字的层次

绘制文字到带背景色的区域时，SetBkMode默认不透明，意味着每个字符背后会填当前背景色。如果背景色不是白色，就会出现难看的“文字白底”。解决办法很简单：SetBkMode(hdc, TRANSPARENT)。

一旦设置成透明，文字颜色就完全由SetTextColor决定。如果想在渐变背景上画文字，直接叠加即可，文字区域不会破坏渐变效果。但要注意，透明模式下SetBkColor依然影响文字阴影的光晕算法，在抗锯齿边缘会有细微变化。使用ClearType字体渲染时，最好保持系统默认的透明度参数，不要随意改ClearType的对比度。

颜色选择方面，白字加黑色阴影是比较稳妥的方案。阴影可以先在偏移1像素的位置用SetTextColor(RGB(0,0,0))画一次文本，再在正常位置用白色画一次。先用TextOut画阴影，再用DrawText画正常文字，顺序不能反。如果直接在同一矩形里调用两次DrawText，第二次绘制会把第一次覆盖，看起来没有阴影，所以阴影偏移得靠调整矩形坐标实现：

RECT rcShadow = rc; OffsetRect(&rcShadow, 1, 1); SetTextColor(hdc, RGB(0, 0, 0)); DrawText(hdc, text.c_str(), -1, &rcShadow, format); SetTextColor(hdc, RGB(255, 255, 255)); DrawText(hdc, text.c_str(), -1, &rc, format);

这样文字层次感会好很多，特别适合状态栏、地图标注、标题栏覆层。

5. 踩坑记录与排查思路

5.1 矩形高度丢失导致的输出消失

我见过最经典的Bug是：创建一个RECT，初始化为{0, 0, 200, 0}，然后调用DrawText，期望能自动往下排版，结果文字根本没显示出来。问题就出在bottom为0，虽然DrawText会按内容扩展高度，但初始矩形高度为0代表没有可用绘制区域，很多版本直接返回而不绘制。

正确做法是给bottom一个足够大的值，比如用客户区高度，或者在DT_CALCRECT时先给一个合理的初始宽度和临时高度。很多人以为DrawText靠DT_CALCRECT会自动扩展，但它只扩展“测量用矩形”，绘制时必须给一个真实存在的空间。

RECT rc = {0, 0, 200, 50}; // 高度先给个足够的值 DrawText(hdc, text, -1, &rc, DT_WORDBREAK | DT_LEFT);

同样的道理，绘制前如果矩形宽度比最宽的单词还小，DT_WORDBREAK不会拆单词，而是直接横向溢出。这个行为和浏览器CSS的overflow-wrap有差异，需要自己处理。

5.2 DPI缩放导致文字位置偏移

在DPI缩放为125%、150%的屏幕上，如果你不处理DPI感知，窗口会被系统虚拟化缩放，而绘制逻辑仍然按96 DPI计算。此时DrawText矩形坐标看似正确，实际上系统会把位图拉伸，文字边缘模糊，位置也经常偏出预期区域。

最直接的解决办法：在程序入口声明DPI感知，或者调用SetProcessDpiAwareness。声明之后，所有的窗口客户区尺寸、字体大小、矩形坐标都必须按当前DPI计算。

// 在 WinMain 开头调用 SetProcessDpiAwarenessContext(DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE_V2);

之后用GetDpiForWindow拿到实际DPI值，再用MulDiv计算字体和间距。如果项目是老的MFC工程，可以调用AfxEnableControlContainer等方式做兼容，但本质还是要让字体大小和矩形尺寸保持同一缩放比例。

我实测下来，只要把字体高度和控件边距按DPI换算，DrawText本身不需要额外改逻辑。因为GDI的坐标换算发生在更底层，你给的逻辑矩形和字体大小只要同步放大，最终效果就是一致的。

5.3 包含与截断标志位同时使用的冲突

有几次项目反馈，列表项文字明明设置了DT_END_ELLIPSIS，但末尾省略号始终不出现。排查到最后，发现代码同时写了DT_WORDBREAK、DT_END_ELLIPSIS和DT_SINGLELINE。单行模式和外号模式同时存在时，GDI会优先处理单行，导致省略号失效。还有一次是路径字符串里包含“&”字符，因为没有DT_NOPREFIX，GDI把它当助记符解析，不仅输出少字符，连排列都变了。

所以组合标志位时，我的习惯是分组检查：

• 是不是同一组里放了两个互斥标志，比如DT_LEFT和DT_CENTER同时出现。
• 是否因为启用单行模式，导致垂直居中失效。
• 是否因为启用DT_NOCLIP，导致文字超出矩形边界，进入异常位置。
• 是否忘记处理DT_NOPREFIX，导致特殊字符被吞。

如果绘制结果和预期不符，先把格式标志全部简化到“DT_LEFT”，然后逐步加标志，每加一个测试一次，能很快定位罪魁祸首。

6. 封装建议与性能优化

6.1 避免重复创建资源的几种写法

在WM_PAINT里每次创建字体、选择DC、删除对象，是初学者最容易出现性能问题的地方。虽然系统有缓存机制，但高频绘制时，频繁CreateFont和DeleteObject会带来可感知的卡顿。尤其在使用动画或者拖拽预览时，每秒几十上百次绘制，每次都创建字体对象不太划算。

合理做法是：在窗口初始化时创建字体对象，缓存到成员变量；需要更换时再删除旧的、创建新的。同一字体在多个DC之间反复使用时，只要不同时在两个DC中SelectObject，就不会出问题。

字体对象之外，DC里的其他属性也尽量一次性设置。比如SetTextColor、SetBkMode这些操作本身很轻，但每次重复设置也不必要。把DC的绘制状态统一封装到一个函数里，传入文本、矩形、颜色、字体，内部完成SelectObject和绘制，外部只管调用。

6.2 批量绘制场景的内存与状态保存

如果要在内存位图上批量绘制大量文本框，比如一屏几百个标签，直接用客户区DC绘制会有闪烁。常规做法是创建内存兼容DC和位图，把所有内容绘制到内存位图，再一次性BitBlt到窗口。这招对DrawText同样有效。

伪代码如下：

HDC hMem = CreateCompatibleDC(hdc); HBITMAP hBmp = CreateCompatibleBitmap(hdc, width, height); HBITMAP hOldBmp = (HBITMAP)SelectObject(hMem, hBmp); // 在hMem上执行所有DrawText调用 // ... BitBlt(hdc, 0, 0, width, height, hMem, 0, 0, SRCCOPY); SelectObject(hMem, hOldBmp); DeleteObject(hBmp); DeleteDC(hMem);

批量绘制时，每个DC只能同时拥有一块位图，建议复用同一块位图。如果文本数量非常大，每行都先Measure再Draw会有两次排版成本，此时可以把Measure缓存到结构体里，同一矩形和同一字体组合的结果缓存起来，下次直接取用。这个技巧在表格类控件里能节省不少时间。

还有个小经验：绘制中文和英文混合文本时，如果字体没有包含某些符号，GDI会回退到系统字体，DrawText每次绘制都可能触发字体回退查找。这样在调试时看不出问题，但大量文本时开销很高。解决方案是统一使用一个覆盖常用范围的大字体，比如微软雅黑或系统UI字体，避免频繁回退。

7. 一些很实用的最后心得

在我日常写代码的习惯里，DrawText从来不是孤立的。我通常会给它配上三个固定伙伴：预先缓存字体、SetBkMode(TRANSPARENT)、显式处理矩形坐标。这三个习惯能解决大多数文字绘制问题。

如果你是在做自绘控件，我建议调试阶段顺手开一个开关：把所有DrawText调用前后，用FrameRect给矩形描上边框。这样能一眼看出文字排版区域是不是自己心里想的区域，字体有没有超出容器，对齐是否居中。这个方法很土，但排查定位效率极高。

还有一个容易忽视的点，就是字符串里的换行符。DrawText默认会处理\n，但如果你在MFC的CString里拼接了\r\n，某些标志位组合下会多产生一个空行。最好的做法是统一使用\n，并在需要时用DT_EDITCONTROL来规避末尾换行的额外空行。

关于DrawText本身的限制，也要提前有认知。它的排版能力类似于简化的富文本渲染，不支持字间距、段间距、缩进、图片混排。如果是重排版需求，建议升级到DirectWrite并配合IDWriteTextLayout，那才适合真正的排版引擎。但日常90%的界面文本，DrawText已经完全够用，而且兼容性和性能都远高于那些华而不实的自定义方案。

文本绘制这件事，看起来一点点API调用，实际上涉及的坐标、字体、DPI、标志位组合问题很细碎。能把DrawText用得顺手，说明对GDI的理解已经入门了。再有类似问题，记住一个原则：先简化标志位，再检查矩形，最后检查字体。大多数坑都能顺着这条路找到答案。