企业官网建设流程全解析

1. 从字到像素：GDI文字渲染的整体逻辑与设计思路

1.1 为什么GDI里的文字如此“麻烦”？

做过Win32原生界面开发的人都有这种体会：Win32里画图其实不难，MoveToEx、LineTo、Rectangle这几个是填饭吃的API。但一旦碰文字，事情就开始复杂了——同样是“画一行字”，你至少得先回答这几个问题：文字用多大字体、用什么颜色、文字是否带背景、是否要居中、是否要自动换行、字符串是ANSI还是Unicode、按什么标准量宽度。这些问题不算刁钻，任何现代界面框架都有自己的“标准答案”，可GDI里没有默认答案，一切得自己来。

这事得从GDI的定位说起。GDI（Graphics Device Interface）是Windows最底层的二维图形接口，它不管你的文字是控件里的标题还是按钮上的文字，它只管一件事情：把“字符串+字体+位置”变成像素。所以文字只是一个“画笔模板+文本内容”的组合，至于文字要排成什么样、在哪里截断、如何对齐、如何适配控件尺寸，这些都属于应用层的逻辑，GDI不给现成方案。好在它给的工具足够全：TextOut负责最朴素的单行输出，DrawText负责多行排版，GetTextMetrics、GetTextExtentPoint32负责度量尺寸。把这几个函数用熟，你就能把界面文字任意揉捏。

1.2 文字渲染的本质：先墨迹后落笔

用生活里的事来类比：TextOut就像拿沾了墨的印章往纸上盖，印泥颜色是文字颜色，章面大小是文字尺寸，你给个坐标，它就盖一行字。DrawText则更像排版工人手里拿着铅字块，除了盖印，它还会帮你把文字块对齐到矩形范围里，该居中居中，该换行换行。而文字度量则像一把尺子——在盖印之前先量一量这个字符串实际占多宽多高，方便你提前算好位置，避免文字印到别的元素上去。

既然是“先墨迹后落笔”，那落笔前就必须搞清楚两件基础装备的状态。第一件是字体（HFONT），它决定文字的长相和大小；第二件是颜色（SetTextColor、SetBkMode），它决定墨迹的颜色和是否保留背景色块。多数新手写的文字渲染代码出现“鬼影”“叠字”“文字跟背景糊在一起”的现象，十有八九是在这两件装备上出了问题——字体没有选入DC，或者背景模式没设成TRANSPARENT。

1.3 三个核心API的分工：不重叠、不互相替代

TextOut、DrawText、GetTextExtentPoint32虽然都和文字相关，但职责不同，不能互相替代，实际项目中经常是“配合使用”而不是“二选一”。

TextOut是纯粹的“输出”：把字符串画在指定坐标上，不做任何排版。它没有对齐概念，也没有换行概念，所有位置计算都得你手动做好。适合那些你已经精确计算好坐标的场景，比如表格里某个单元格的文字、坐标轴上某个刻度标签。

DrawText把“排版”这件事揽了过来：你给一个矩形和字符串，它能帮你按对齐方式（左、中、右）、按换行规则（自动换行、截断、省略号）把文字摆放妥当。它内部实际上替你做了一堆你不想自己写的算术。按钮上的文字、静态文本控件的内容、列表头的标题，这些“文字在一小块区域里需要对齐”的场景，DrawText是最优解。

文字度量则是“只量不画”：GetTextMetrics拿字体本身的通用信息（字高、行距、最大字符宽度），GetTextExtentPoint32拿特定字符串在这把字体下的精确尺寸。度量函数永远不会把文字画上去，它们存在的唯一意义是给你提供“数据”，让你在其他地方把尺寸用起来。

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

2.1 TextOut：最朴素的单行输出

先说函数原型，这是老一辈程序员再熟悉不过的API：

BOOL TextOut( HDC hdc, // 设备上下文 int x, // 左下角？不！是左上角X坐标 int y, // 左上角Y坐标 LPCTSTR lpString, // 字符串 int cchString // 字符个数，注意是字符数不是字节数 );

注意这里X和Y的坐标基准是字符串“左上角”还是“基线”？很多教材说是左上角，但严格来说Y是字符串外框的顶部。TextOut不会自动换行，也不会为你做任何对齐，你给它一个起点，它就从起点开始往右画。如果要实现居中，只能自己先量出字符串宽度，再用“目标区域宽度－文本宽度再除以2”算出X的偏移量。听起来麻烦，但好处是可控，比如当你需要把一行文字叠在一个自定义绘制的图形中间时，TextOut这种“纯输入坐标”的接口反而最容易做精确计算。

使用TextOut时有个常见误区：cchString是按“字符”数计算的，不是按“字节”数。用ANSI字符串时一个汉字占两个字节，写strlen(str)会算成字节数，导致函数把半个汉字当结束符，出现乱码。正确做法是_tcslen(str)（TCHAR版本）或者对ANSI字符串用strlen后再乘以每个字符的字节数，但更推荐直接编译成Unicode工程，全部走宽字符路径，一劳永逸。

2.2 DrawText：排版是最值钱的能力

DrawText的签名比TextOut复杂：

int DrawText( HDC hdc, // 设备上下文 LPCTSTR lpchText, // 字符串 int cchText, // 字符串长度，-1表示自动按\0计算 LPRECT lprcRect, // 目标矩形 UINT uFormat // 格式控制标志 );

这里最需要下功夫的是uFormat这一堆标志位的组合。常用的有这么几组：

• 对齐控制：DT_LEFT、DT_CENTER、DT_RIGHT
• 垂直对齐：DT_TOP、DT_VCENTER、DT_BOTTOM
• 排版控制：DT_WORDBREAK（自动换行）、DT_SINGLELINE（单行）、DT_END_ELLIPSIS（结尾省略号）
• 特殊行为：DT_CALCRECT（只计算矩形尺寸，不画文字）

实际开发中最经典的组合是按钮文字的绘制：DrawText(hdc, text, -1, &rc, DT_CENTER | DT_VCENTER | DT_SINGLELINE)。这三个标志合在一起，就能做到文字在按钮矩形内水平垂直都居中，完全不用自己算坐标。

DT_CALCRECT是最容易被低估的标志。它的作用是“只量不画”：传入你想给文字限定的矩形范围，函数会根据文字内容和换行规则重新计算矩形的高度（宽度不变），让你知道这段文字真正需要占多大高度。这在动态生成控件、自动调整窗口大小时非常有用。比如你要动态创建一个多行文本区域，可以先拿DT_CALCRECT量一下文字需要的高度，再按这个高度去调整控件尺寸。

> 提示：DrawText的换行行为是“单词级”的。它会尽量在空格处断开，这与某些语言没有空格分隔的习惯不太一样。如果你要处理连续无空格的超长字符串（比如路径），可以配合DT_WORDBREAK和DT_END_ELLIPSIS一起用，至少保证结尾有省略号提示。

2.3 前后景色与背景：透明度是画质的分水岭

很多人在GDI文字上栽的第一个跟头就是“文字背景色块”。默认情况下，GDI绘制文字时会用背景色填充整个文字外框。你在窗口上写自定义绘制代码时，如果不特意设置SetBkMode(hdc, TRANSPARENT)，画出来的文字背后会拖着一个矩形色块，和窗口背景色不融合。

解决办法就一行：

SetBkMode(hdc, TRANSPARENT); // 文字背景透明

如果确实想要带背景色的文字（比如标签式UI），用SetBkColor(hdc, RGB(...))设置背景色，但注意背景色的作用范围是整个文字外框矩形，不是每个字符背后单独一块，所以做“高亮关键词”这类效果时，用背景色块是不合适的，得自己先画一个填充矩形，再在矩形上透明输出文字。

文字颜色用SetTextColor(hdc, RGB(...))设置。这个颜色一旦设置，本次DC内所有文字绘制都使用它，直到再次修改。也正因如此，如果在一个循环里画多段不同颜色的文字，每段文字前都要重新调用一次SetTextColor，不要以为TextOut会“记住”颜色参数——TextOut本身没有颜色参数，颜色全看DC状态。

3. 文字度量：让文字站得稳、排得齐

3.1 度量结构体解析：TEXTMETRIC与SIZE

要精确排版，先要把“字体在这个DC下到底长什么样”搞清楚。GDI提供两个层次的度量：

第一个层次是整把字体：GetTextMetrics(hdc, &tm)，拿到的TEXTMETRIC结构体包含这些关键字段：

• tmHeight：字符的总高度（行高）
• tmAscent：基线以上高度（从顶部到基线）
• tmDescent：基线以下高度（从基线到底部）
• tmInternalLeading：字符顶部的内部留白
• tmExternalLeading：行与行之间的额外行距
• tmMaxCharWidth：该字体下最宽字符的宽度

这些字段里有几个很关键：tmAscent（上升部）和tmDescent（下降部）加起来构成行高。排版时，两行文字之间的空白距离应该由tmHeight + tmExternalLeading决定，而不是简单地相邻行首对齐。英文编辑器里常见“行距过大”或“行距过紧”，就是因为没有按这两个字段算行距。

第二个层次是具体某个字符串：GetTextExtentPoint32(hdc, str, 字符数, &size)，返回SIZE结构体，包含cx（字符串宽度）和cy（字符串高度）。这个函数是按具体字体和DC状态实时计算的，所以你换了字号、换了字体，宽度结果都会变，必须动态测量，不能静态缓存（除非同一字体同一字符串在同一个DC上反复使用）。

3.2 计算字符串的像素宽度与水平对齐

绘制居中文字最经典的做法：

RECT rcClient; GetClientRect(hwnd, &rcClient); wchar_t szText[] = L"Hello, GDI Text"; SIZE sizeText; GetTextExtentPoint32(hdc, szText, wcslen(szText), &sizeText); int x = (rcClient.right - rcClient.left - sizeText.cx) / 2; int y = (rcClient.bottom - rcClient.top - sizeText.cy) / 2; TextOut(hdc, x, y, szText, wcslen(szText));

也可以用DrawText一步到位，但上面的手写方式适合“其它元素也要按同一坐标对齐”的场景。GetTextExtentPoint32测出来的宽度是“字符串实际像素宽度”，与字体是否斜体、是否加粗有关。同一篇文字在不同标题字号下占的宽度差异很大，所以界面设计中只要字号会变化，就一定走动态测量这一条路。

3.3 行高与行距：按度量结果算，别拍脑袋

多行文本绘制时，新手最容易犯的错误是“我用一个固定值当行距”。不同字号、不同字体（比如从宋体切到微软雅黑）的行高差异极大，固定行距会导致文字重叠或者看起来稀松。

正确的多行步进方式是这样算的：

TEXTMETRIC tm; GetTextMetrics(hdc, &tm); int lineHeight = tm.tmHeight + tm.tmExternalLeading; // 一行文字+行间空白 for (int i = 0; i < nLines; i++) { TextOut(hdc, x, y, lines[i], wcslen(lines[i])); y += lineHeight; // 用行高累加，不要自己拍一个数字 }

这段代码在实际项目中极其常用，尤其是绘制日志列表、信息面板时。如果你处理的是中文文本，注意中文字体的tmExternalLeading通常为0，因为中文字体内部自带了行间距，但英文衬线字体（比如宋体西文部分）这个字段往往非0，所以跨语言文本混排时，行高务必用上面这个公式。

4. 实操实战：一个完整的文字渲染Demo

4.1 构建窗口框架与绘制入口

先搭一个标准Win32窗口，核心在WM_PAINT里做GDI文字绘制。下面是一个独立的可运行Demo，演示了TextOut、DrawText和度量函数的联合使用：

LRESULT CALLBACK WndProc(HWND hwnd, UINT msg, WPARAM wp, LPARAM lp) { PAINTSTRUCT ps; HDC hdc; static HFONT hFontTitle, hFontBody; switch (msg) { case WM_CREATE: // 创建两把字体：标题用22pt加粗，正文用16pt常规 hFontTitle = CreateFont(-22, 0, 0, 0, FW_BOLD, FALSE, 0, 0, 0, 0, 0, 0, 0, L"微软雅黑"); hFontBody = CreateFont(-16, 0, 0, 0, FW_NORMAL, FALSE, 0, 0, 0, 0, 0, 0, 0, L"微软雅黑"); return 0; case WM_PAINT: { hdc = BeginPaint(hwnd, &ps); RECT rcClient; GetClientRect(hwnd, &rcClient); // 1. 标题区使用 DrawText 居中显示 SetBkMode(hdc, TRANSPARENT); SetTextColor(hdc, RGB(30, 30, 30)); SelectObject(hdc, hFontTitle); RECT rcTitle = rcClient; rcTitle.bottom = 60; DrawText(hdc, L"GDI 文字渲染 Demo", -1, &rcTitle, DT_CENTER | DT_VCENTER | DT_SINGLELINE); // 2. 正文区域使用 TextOut 逐行输出，展示行高度量 SelectObject(hdc, hFontBody); SetTextColor(hdc, RGB(70, 70, 70)); TEXTMETRIC tm; GetTextMetrics(hdc, &tm); int lineHeight = tm.tmHeight + tm.tmExternalLeading; int yPos = 70; int xPos = 20; const wchar_t* lines[] = { L"第一行：TextOut 手动计算坐标绘制", L"第二行：行高来自 GetTextMetrics", L"第三行：宽度来自 GetTextExtentPoint32", }; for (int i = 0; i < 3; i++) { TextOut(hdc, xPos, yPos, lines[i], wcslen(lines[i])); yPos += lineHeight; } // 3. 用 GetTextExtentPoint32 画一个带边框的标签 SIZE sizeTag; const wchar_t* tag = L"标签"; GetTextExtentPoint32(hdc, tag, wcslen(tag), &sizeTag); RECT rcTag = { 20, yPos + 10, 20 + sizeTag.cx + 16, yPos + 10 + sizeTag.cy + 8 }; Rectangle(hdc, rcTag.left, rcTag.top, rcTag.right, rcTag.bottom); DrawText(hdc, tag, -1, &rcTag, DT_CENTER | DT_VCENTER | DT_SINGLELINE); // 清理 DeleteObject(hFontTitle); DeleteObject(hFontBody); EndPaint(hwnd, &ps); return 0; } case WM_DESTROY: PostQuitMessage(0); return 0; } return DefWindowProc(hwnd, msg, wp, lp); }

这段代码里有个细节值得说明：CreateFont的第一个参数是负数（-22、-16），这表示“字符高度22像素”。正数则表示“字符点大小（point size）”，两者在DPI不同环境下的实际显示效果会有差异。传统桌面开发习惯用负像素值，因为GDI在默认96DPI下负值更直观。

4.2 多行文本排版：动态计算行高与矩形扩展

上面Demo展示了最基础的用法，但实际项目里多行文本往往来自配置文件或动态拼接。有一种很常见的页面布局场景：界面上有一块区域，需要显示一组自动换行的说明文字，而且这块区域的高度要刚好包住文字，不能多也不能少。

做法是先量后画：

RECT rcText = { 20, 100, 380, 1000 }; // 先给一个足够大的临时矩形 const wchar_t* longText = L"这是一段需要自动换行的说明文字，" L"内容可能比较长，我们需要保证它在指定的宽度内排版，" L"并计算出它实际需要的高度。"; // 第一遍：只计算，不绘制 DrawText(hdc, longText, -1, &rcText, DT_WORDBREAK | DT_CALCRECT); // 此时 rcText.bottom 已经从 1000 变成了实际需要的高度 int textHeight = rcText.bottom - rcText.top; // 第二遍：真正绘制 RECT rcActual = { 20, 100, 380, 100 + textHeight }; DrawText(hdc, longText, -1, &rcActual, DT_WORDBREAK | DT_LEFT);

这种“先量后画”的方式还能避免文字被矩形裁剪。如果直接把rcText.bottom设成1000然后画，DrawText只会在矩形内绘制，超出的部分直接看不见；用DT_CALCRECT量完再画，既能保证全部显示，又能准确知道控件需要多大。

4.3 结合GetTextExtentPoint32处理自定义控件

自定义控件是GDI文字渲染的主战场。举一个实际例子：绘制一个进度条上的百分比文字，文字需要居中在进度条内部。进度条的填充部分会动态变化，这导致文字的背景区域也要跟着变化。做法是画完进度条填充后，在整条区域上画一个居中的透明文字：

// 画完进度条矩形后： wchar_t szPercent[16]; swprintf_s(szPercent, L"%.0f%%", percent); SetBkMode(hdc, TRANSPARENT); SetTextColor(hdc, RGB(255, 255, 255)); SelectObject(hdc, hFontBody); SIZE sizeText; GetTextExtentPoint32(hdc, szPercent, wcslen(szPercent), &sizeText); int xText = rcBar.left + (rcBar.right - rcBar.left - sizeText.cx) / 2; int yText = rcBar.top + (rcBar.bottom - rcBar.top - sizeText.cy) / 2; TextOut(hdc, xText, yText, szPercent, wcslen(szPercent));

这里用GetTextExtentPoint32测量目的只有一个：在进度条内部居中。用DrawText也能做到，但用TextOut方式的好处是你能明确拿到落笔坐标，方便在文字左右追加其他图形元素（如图标、小箭头）。这种“测量＋定位”的编程模型贯穿整个GDI应用开发。

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

5.1 字符集混乱：ANSI与Unicode的致命差异

这是GDI文字渲染里最容易踩、也最难看出来的坑。如果你在项目中使用TCHAR进阶方案，字符串字面量必须写成_T("...")；如果项目是Unicode（VS默认），字符串要用L"..."，否则遇到中文会变成乱码。

按API函数名来看，GDI提供的其实是两个函数：TextOutA（ANSI版）和TextOutW（宽字符版）。TextOut只是一个宏，根据工程是否定义了UNICODE自动映射到其中一个。如果你在一个Unicode工程里给TextOut传了char*字符串，编译器会报类型不匹配；反之在ANSI工程里传wchar_t*也一样。实际代码里最常见的错误是用strlen去量宽字符字符串的长度，结果文字只画出前一半。正确做法是量字符数，用_tcslen、wcslen或对TCHAR的_tcslen宏。

> 提示：从开发效率角度，建议新建工程一律Unicode字符集。Win32 API在Unicode路径下的行为一致性更好，中文、英文混排不用来回转换编码，碰到的乱码问题会少一大半。

5.2 文字遮挡矩形与DC状态污染

还有一个高频问题：文字画出来“带框”，或者画完文字后矩形边线被文字背景遮住一块。这两种现象本质都是SetBkMode没设置成TRANSPARENT。

代码如下：

// 错误示范：先画了一个填色矩形，再在矩形上画文字 FillRect(hdc, &rc, (HBRUSH)GetStockObject(WHITE_BRUSH)); TextOut(hdc, 10, 10, L"hello", 5); // 没设SetBkMode，文字背后会多一块白底 // 正确示范：设置透明背景后再输出 SetBkMode(hdc, TRANSPARENT); FillRect(hdc, &rc, (HBRUSH)GetStockObject(WHITE_BRUSH)); TextOut(hdc, 10, 10, L"hello", 5);

设置一次SetBkMode后，DC会记住这个状态，直到被修改。但如果你在代码里SaveDC/RestoreDC则另说，RestoreDC会恢复到Save时的状态，所以多段绘制逻辑间要么统一管理，要么每次绘图前都设一遍，后一种看起来多花几行代码，但出问题概率要小得多。

另外注意：SelectObject选择字体后，绘制完文字最好选回旧字体。GetStockObject拿来的系统字体不会出问题，但你自己CreateFont创建出来的字体如果不删除，就会内存泄露。建议在WM_PAINT里“创建→使用→DeleteObject”，生命周期短，不容易出错。

5.3 高DPI缩放与字体失真

在高DPI显示器上（125%、150%、200%缩放），GDI默认逻辑坐标到物理像素不是1:1。如果你的程序没有声明DPI感知，系统会帮你做位图拉伸，文字看起来发虚。解决方法是程序启动时（入口处或WinMain里）调用SetProcessDPIAware()，主动声明DPI感知：

#include <windows.h> int WINAPI WinMain(HINSTANCE hInst, HINSTANCE hPrev, LPSTR lpCmdLine, int nCmdShow) { SetProcessDPIAware(); // 告知系统本程序自己处理DPI缩放 // 后续窗口创建、字体创建都基于实际物理像素 }

声明DPI感知之后，字体创建时也要注意：CreateFont(-22, ...)里的-22是像素值，在150%缩放下，22像素物理高度在96DPI坐标下只相当于14.7逻辑像素。所以如果你希望“22像素视觉大小在任意缩放下都成立”，需要在运行时获取系统的缩放比例，手动放大字号：

UINT dpi = GetDpiForWindow(hwnd); // Windows 10 1607+ 可用 int fontSize = MulDiv(-22, dpi, 96); HFONT hFont = CreateFont(fontSize, 0, 0, 0, FW_NORMAL, FALSE, 0, 0, 0, 0, 0, 0, 0, L"微软雅黑");

如果不处理DPI，同一套代码在100%缩放和150%缩放的电脑上，界面文字大小会不一致，要么挤成一团，要么空荡荡一片。

6. 文字度量的进阶应用：表格列宽与混排适配

文字度量除了用来居中、对齐，还有一个非常务实的用途——计算控件或表格列宽。比如你要做一个简单的列表控件，每一列显示不同长度的文本，列宽要“刚好容下最长的那条文字”。这个逻辑听上去简单，但实际操作时如果你用“字符数×固定宽度”来估算，结果一定不准，因为英文字母和汉字的宽度差异巨大，英文字母中大写W和小写i的宽度也不同。唯一可靠的方式就是拿你要使用的字体去实测。

方法就是遍历文本，每一条都调用GetTextExtentPoint32，取宽度最大值，再乘上一个调节系数（通常1.1到1.2，留出内边距），就是列宽的下限：

int maxWidth = 0; for (int i = 0; i < itemCount; i++) { SIZE sz; GetTextExtentPoint32(hdc, items[i], wcslen(items[i]), &sz); if (sz.cx > maxWidth) { maxWidth = sz.cx; } } int colWidth = (int)(maxWidth * 1.15) + 24; // 15%余量 + 左右各12px边距

同理，制作一个可以动态调整行高的网格视图时，行高也应该来自GetTextMetrics的tmHeight + tmExternalLeading，不能用一个常量死顶。

混排情况比较复杂。中英文混排时，GDI会按各自的字体回退规则渲染（英文走英文字体，中文走中文字体），此时GetTextExtentPoint32测量的宽度已经包含了这种回退，所以放心用测量结果即可。但要注意：混排文本的换行点不能简单按字符边界切，建议做整段换行而非逐字拼接，否则会出现“一个汉字后面跟着半个英文字母”的视觉断裂。

7. GDI文字渲染的局限与后续演进方向

讲到这里，GDI文字渲染的核心工具链已经完整了：TextOut画单行、DrawText做排版、GetTextMetrics和GetTextExtentPoint32做度量，再加上字体创建和颜色设置，足以应付绝大多数传统Windows桌面应用的界面文字需求。

不过要说这类方案全无短板也不现实。GDI是纯CPU光栅化，文字量大时（比如同时绘制上千行日志）会有性能压力；它不擅长旋转、透视等复杂字形变换；对亚像素抗锯齿（ClearType）的支持也依赖系统设置，不能全自动保证。如果你做的是一个现代UI框架，比如需要GPU加速、毛玻璃背景、复杂动画文字，那应该考虑Direct2D，它拥有更完善的文字排版接口（DirectWrite）和多层级的抗锯齿能力。但从另一个角度看，GDI这套东西仍是Windows界面编程的基石，很多传统框架（MFC、WTL）的底层都在直接间接使用它，学清楚GDI文字的坐标、度量模型，再切换到Direct2D时也能更快上手。

我个人在实际项目里的选择标准是这样的：纯工具类软件、性能不敏感的管理界面、需要快速上手的Win32原生工具，用GDI文字渲染完全没有问题，代码也轻巧；如果你是做一个需要长期维护、界面复杂度高、动画多的桌面软件，趁早整体迁移到Direct2D会更稳妥。GDI和Direct2D没有绝对的优劣，关键看场景，但无论走哪条路，“先理解文字度量、再谈绘制”这个原则始终不变。

最后再分享一个小技巧：调试文字排版问题时，别只在内存里算，先打开系统自带的“放大镜”工具，把窗口放大到200%，仔细观察文字边缘和元素之间的间距。GDI的许多排版问题在正常缩放下非常隐蔽，放大之后原形毕露——背景块是否透明、间距是否均匀、对齐是否偏移，一眼就能看清楚。这个习惯帮我省下了大量和用户来回确认界面细节的时间。