不用先翻MSDN先把这段代码跑起来再说。在Win32 GDI里凡是做界面、搞自绘控件、写绘图工具的人基本都绕不开DrawText这个函数。它做的事情听起来很简单把一段字符串画进一个矩形区域里但如果只用过最基础的调用方式你十有八九会在换行、对齐、动态算高度、DPI适配这些地方卡壳。这篇就把DrawText从参数到底层行为、从最小示例到实际坑位完整过一遍。1. 为什么文本绘制绕不开DrawText1.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, LMicrosoft YaHei); HFONT hOldFont (HFONT)SelectObject(hdc, hFont); // 设置文字颜色和背景模式 SetTextColor(hdc, RGB(30, 60, 120)); SetBkMode(hdc, TRANSPARENT); // 绘制居中文本 DrawText(hdc, LWindows 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, LMicrosoft 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_NOPREFIXGDI把它当助记符解析不仅输出少字符连排列都变了。所以组合标志位时我的习惯是分组检查是不是同一组里放了两个互斥标志比如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的理解已经入门了。再有类似问题记住一个原则先简化标志位再检查矩形最后检查字体。大多数坑都能顺着这条路找到答案。