企业官网建设流程全解析

简介：这是一份面向VC++/MFC开发者的BMP图像局部放大功能工程资源，基于CZoomPart类实现局部放大查看细节，适用于图像查看器、地图应用等场景。资源包共21个文件，压缩后124KB，包含6个头文件与5个cpp源文件（对应核心类实现与程序入口）、3张BMP测试图像、2个ico图标以及rc/rc2界面资源文件，可直接打开工程体验完整功能。当前已有138人学习。工程演示了读取BMP、通过双线性插值实现平滑缩放、利用CDC与BitBlt绘制放大区域，并支持鼠标交互实时更新放大视图。读者可从中掌握GDI绘图机制、MFC事件驱动编程以及图像缩放算法的落地写法，适合正在学习VC++图形编程或希望快速移植局部放大功能的开发者参考。

1. 局部放大这个看似简单的需求，为什么专门要做成组件

做图像显示类工具的人，大概率都遇到过这种场景：用户在查看一张大图或者实时画面时，想看清某个区域的细节，但又不想把整张图放大到全屏——于是需要一个矩形框，把框住的那一小块内容单独拎出来，放大显示在另一个窗口或视图里。这就是"局部放大"（局部放大镜）功能。标题里的 "BmpZoomPart_CZoomPart" 拆开看，就是一个基于位图（BMP）数据做局部区域提取，配合一个名为 CZoomPart 的视图控制类，在 VC 环境下实现局部放大交互的一套组件代码。

这套东西能解决的问题很直接：不用重新解码、不用开第二个文档视图、不需要 GPU 加速，纯 GDI 绘制就能在一个控件内部完成"框选区域 — 放大显示 — 平移/缩放 — 实时刷新"的完整链路。对做 CAD 看图、医学影像预览、工业检测画面回显、文档扫描件查看这类 MFC 老项目的开发者来说，这类组件至今仍是低成本、高兼容性的首选方案。文章适合正在维护 VC6 / VS2008 / VS2015 等 MFC 工程，想往里插入局部放大功能，又不想引入第三方图像库的开发者。下文先把原理讲透，再给出可抄的类设计与关键代码，最后是实际调试时最容易翻车的那几个细节。

2. 局部放大的底层逻辑：从 BMP 数据到视图坐标的映射关系

2.1 为什么选 BMP 而不是直接操作 DC：放大本质是像素搬运

很多初学者写局部放大，第一反应是使用 StretchBlt 把目标区域直接拉伸到目标矩形，这确实能出效果。但实战里你会发现，StretchBlt 依赖源 DC 的当前状态，一旦窗口重绘、覆盖、滚动，源 DC 的内容可能已经变了，放大窗口拿到的不是用户框选那一刻的画面。更麻烦的是，如果你要放大的是已经被缩放显示过的视图，源 DC 里存的是"显示结果"，你再放大一次，等于对已经缩过的图再做缩放，细节早就丢失了。

所以可靠的做法是：始终以原始位图数据为基准，也就是标题里的 BmpZoomPart 这个核心——把位图当作唯一数据源。放大操作的本质是像素搬运，即从源位图上按坐标取出一块矩形区域，经过采样或插值之后，填充到目标显示区域。CZoomPart 类要管理的，就是"源位图指针、源区域矩形、目标矩形、缩放的倍率或插值模式"这几个状态。

这里有一个关键取舍：放大率是整数倍还是小数倍。整数倍（2x、3x、4x）意味着每个源像素对应一个 n×n 的像素块，直接使用最近邻采样即可，速度快、实现简单，图像会呈现明显的马赛克感，但工程上完全可用。小数倍（比如 1.5x、2.7x）则需要双线性插值，否则线条会出现明显的断裂和锯齿。我一般在组件里存一个浮点型的 ZoomFactor，同时内部判断：如果值落在整数区间，走最快路径，否则走插值路径。

2.2 CZoomPart 类的骨架设计：先定状态，再定绘制函数

一个能嵌入现有 MFC 工程的 CZoomPart 类，通常不需要从 CWnd 继承，而是作为一个纯 C++ 逻辑类被视图类或控件类持有。这样做的最大好处是解耦：不管你把它用在 CView、CStatic 还是自定义控件上，它只关心"给我一个 HDC、给我源位图、给我矩形，我就给你画出来"。

类的核心状态我一般设计成这样：

class CZoomPart { public: // 设置要显示的源位图（不持有所有权，外部保证生命周期） void SetSourceBitmap(CBitmap* pBmp); // 设置源位图上被放大的矩形区域，坐标基于位图原始像素 void SetSrcRect(CRect rcSrc); // 设置目标绘制矩形，坐标基于目标窗口客户区 void SetDstRect(CRect rcDst); // 设置放大倍率，支持小数 void SetZoomFactor(double dZoom); // 执行绘制，由外部传入目标 DC 和位图数据指针 BOOL Draw(CDC* pDC); private: CBitmap* m_pBmp; // 源位图，外部所有 CRect m_rcSrc; // 源区域，单位是像素 CRect m_rcDst; // 目标矩形，单位是像素 double m_dZoom; // 放大倍数 BOOL m_bInit; // 位图信息是否已初始化 };

代码逻辑说明：SetSourceBitmap 只保存指针，不复制对象，因为大位图复制一次就是几十兆内存的拷贝，代价太高。SetSrcRect 和 SetDstRect 分离的设计是为了适配"源区域跟随鼠标移动、目标矩形固定在角落"这种最常见的交互模式——用户鼠标在图上移动时，你只需要不断调用 SetSrcRect 并触发重绘，DstRect 可以一次设置好不变化。Draw 函数内部负责把源矩形内的像素取样后填到目标区域。

参数说明：m_rcSrc 的坐标基准是位图原始尺寸，不是视图缩放后的显示尺寸。这是最容易搞错的一点——如果你在视图上做了一次 0.5 倍的缩小显示，鼠标点击位置要先除以 0.5 换算回位图坐标，再传进 SetSrcRect，否则放大窗口里看到的内容跟鼠标所指的位置永远差一倍。

2.3 获取位图数据：GetBitmap 和像素数组之间隔着一层 DIB

Draw 函数要真正干活，必须先拿到位图数据指针。很多人的代码卡在这一步：CBitmap 对象拿到了，但不知道如何访问其内部像素。正确路径是：先把 CBitmap 转成 BITMAP 结构拿到 bmWidth、bmHeight 和 bmBitsPixel，再用 GetDIBits 或直接构造一个 DIB 内存块来操作。

我一般会选择把源位图在初始化时转成一种内部统一的 24 位或 32 位 DIB 数据，后续所有取样操作都在这块内存上进行，而不是每次都调用 GetDIBits。

BOOL CZoomPart::InitFromBitmap() { if (!m_pBmp) return FALSE; BITMAP bm; m_pBmp->GetBitmap(&bm); m_nWidth = bm.bmWidth; m_nHeight = bm.bmHeight; // 创建兼容的内存 DC 并选入位图 CDC memDC; memDC.CreateCompatibleDC(NULL); CBitmap* pOld = memDC.SelectObject(m_pBmp); // 分配一块 24 位 DIB 内存 BITMAPINFO bmi = {0}; bmi.bmiHeader.biSize = sizeof(BITMAPINFOHEADER); bmi.bmiHeader.biWidth = m_nWidth; bmi.bmiHeader.biHeight = -m_nHeight; // 负值表示自顶向下存储 bmi.bmiHeader.biPlanes = 1; bmi.bmiHeader.biBitCount = 24; bmi.bmiHeader.biCompression = BI_RGB; if (m_pDibData) delete[] m_pDibData; m_pDibData = new BYTE[m_nWidth * m_nHeight * 3]; // GetDIBits 将位图数据按 DIB 格式拷贝到内存 ::GetDIBits(memDC.GetSafeHdc(), (HBITMAP)m_pBmp->GetSafeHandle(), 0, m_nHeight, m_pDibData, &bmi, DIB_RGB_COLORS); memDC.SelectObject(pOld); m_bInit = TRUE; return TRUE; }

逻辑说明：这段代码先把 CBitmap 选入内存 DC，然后用 GetDIBits 把像素数据按 24 位 DIB 格式拷贝到我们分配的内存块。为什么要用负高度？因为 BMP 文件默认是自底向上的行序，而我们在屏幕上画图时习惯自顶向下，负高度让 GetDIBits 输出顶行在前的数据，后面取样代码可以少做一次行序反转。

参数说明：biBitCount 选 24 而不是 32，是因为 24 位是 BMP 最通用的格式，内存占用也更小，对工业现场常见的灰度图或真彩图都适用。如果源图带 Alpha 通道需要透明效果，再改用 32 位。GetDIBits 的最后一个参数 DIB_RGB_COLORS 表示颜色表用 RGB 值而非调色板索引，8 位及以上的位图都该用这个参数。

3. 实现框选交互：鼠标消息、源矩形计算和视图坐标反变换

3.1 鼠标交互的最小命令集：按下、移动、抬起三态设计

放大组件在实际使用时，交互方式基本是两种。一种叫"固定视窗模式"：放大镜窗口固定在界面右上角，鼠标在源图上移动时，放大窗口跟随显示以鼠标为中心的区域。另一种叫"框选模式"：用户按下鼠标左键拖出一个矩形，松开后矩形内容被放大并显示在放大视窗中。实战项目中后者更常用，因为用户通常要观察的是一个特定目标区域，而不是漫游式地看。

框选交互在视图中只需要处理三个消息：WM_LBUTTONDOWN、WM_MOUSEMOVE、WM_LBUTTONUP。按下时记录起点，移动时更新橡皮筋矩形，抬起时把矩形转换为源图坐标并触发放大显示。

void CMyView::OnLButtonDown(UINT nFlags, CPoint point) { // 记录框选起点，坐标是视图客户区坐标 m_ptAnchor = point; m_bSelecting = TRUE; SetCapture(); // 捕获鼠标，保证拖出窗口外也能收到移动消息 CView::OnLButtonDown(nFlags, point); } void CMyView::OnMouseMove(UINT nFlags, CPoint point) { if (m_bSelecting) { // 用 XOR 模式绘制橡皮筋矩形，避免背景重绘闪烁 CClientDC dc(this); CRect rcOld(m_ptAnchor, m_ptLast); CRect rcNew(m_ptAnchor, point); dc.DrawFocusRect(rcOld); // 擦掉上一次的框 dc.DrawFocusRect(rcNew); // 画新的框 m_ptLast = point; } CView::OnMouseMove(nFlags, point); } void CMyView::OnLButtonUp(UINT nFlags, CPoint point) { if (m_bSelecting) { m_bSelecting = FALSE; ReleaseCapture(); // 计算源图上的矩形：视图坐标 -> 位图坐标 CRect rcSel(m_ptAnchor, point); rcSel.NormalizeRect(); // 换算：需要除以视图当前的缩放比例 double dViewScale = m_dViewScale; // 视图缩放倍率 CRect rcSrc; rcSrc.left = (LONG)(rcSel.left / dViewScale); rcSrc.top = (LONG)(rcSel.top / dViewScale); rcSrc.right = (LONG)(rcSel.right / dViewScale); rcSrc.bottom = (LONG)(rcSel.bottom / dViewScale); // 限制在源位图范围内 rcSrc.IntersectRect(rcSrc, CRect(0, 0, m_bitmapWidth, m_bitmapHeight)); if (rcSrc.Width() < 2 || rcSrc.Height() < 2) { // 区域太小，直接忽略本次框选 return; } m_zoomPart.SetSrcRect(rcSrc); GetZoomView()->Invalidate(); // 触发放大视图重绘 } CView::OnLButtonUp(nFlags, point); }

逻辑说明：框选完成后，关键动作是把视图上的像素距离除以视图缩放比例，得到位图上的真实像素区域。举例来说，视图按 50% 显示，用户在屏幕上拖出一个 100×80 的框，源图上的实际区域是 200×160。如果不做这个换算，放大窗口显示的细节会比用户框选的范围小一半，看起来就像"放大了但内容不对"。DrawFocusRect 用 XOR 方式画框，同一矩形画两次就自动擦除，比用 InvalidateRect 重绘整个视图要快得多，也不会造成背景闪烁。

参数说明：SetCapture 和 ReleaseCapture 成对出现，作用是保证鼠标拖出窗口之后依然能收到 WM_MOUSEMOVE 消息。rcSel.NormalizeRect() 用来处理用户从右下往左上拖拽的情况，不调用它的话矩形可能出现负宽度。框选区域小于 2×2 像素时直接忽略，这是为了避免用户误点击时放大出一个只有一两个像素的无效区域。

3.2 放大视图的绘制：把整数倍最近邻和分数倍双线性拆成两条路

绘制是 CZoomPart 里最核心的代码。直接把源矩形拉伸到目标矩形时，GDI 的 StretchBlt 有两个问题：一是默认的 COLORONCOLOR 拉伸模式在缩小和放大时会产生严重的颜色失真和摩尔纹；二是它不支持插值选项，放大后的图像锯齿感非常明显。所以我选择手动实现像素搬运逻辑，同时提供两档绘制策略。

BOOL CZoomPart::Draw(CDC* pDC) { if (!m_bInit || !pDC) return FALSE; int dstW = m_rcDst.Width(); int dstH = m_rcDst.Height(); int srcW = m_rcSrc.Width(); int srcH = m_rcSrc.Height(); if (srcW <= 0 || srcH <= 0 || dstW <= 0 || dstH <= 0) return FALSE; // 计算实际放大倍率（目标矩形尺寸 / 源矩形尺寸） double dZoomX = (double)dstW / srcW; double dZoomY = (double)dstH / srcH; // 判断是否接近整数倍——整数倍走最近邻快速路径 BOOL bIntZoom = (fabs(dZoomX - floor(dZoomX + 0.5)) < 1e-6) && (fabs(dZoomY - floor(dZoomY + 0.5)) < 1e-6); if (bIntZoom) return DrawNearest(pDC, (int)(dZoomX + 0.5)); else return DrawBilinear(pDC); }

BOOL CZoomPart::DrawNearest(CDC* pDC, int nFactor) { // 源区域左上角在 DIB 内存中的偏移 int srcStartX = m_rcSrc.left; int srcStartY = m_rcSrc.top; int srcWidth = m_rcSrc.Width(); int srcHeight = m_rcSrc.Height(); // 逐块绘制：每个源像素画一个 nFactor x nFactor 的实心矩形 for (int y = 0; y < srcHeight; y++) { for (int x = 0; x < srcWidth; x++) { // 从 DIB 内存读取像素颜色 BYTE* pPixel = m_pDibData + ((srcStartY + y) * m_nWidth + (srcStartX + x)) * 3; COLORREF clr = RGB(pPixel[2], pPixel[1], pPixel[0]); CRect rcBlock( m_rcDst.left + x * nFactor, m_rcDst.top + y * nFactor, m_rcDst.left + (x + 1) * nFactor, m_rcDst.top + (y + 1) * nFactor); pDC->FillSolidRect(rcBlock, clr); } } return TRUE; }

逻辑说明：整数倍路径的逻辑非常直白，每个源像素在目标区域上占据一个 nFactor×nFactor 的色块。这个循环的性能瓶颈在于 FillSolidRect 的调用次数——一个 200×150 的源区域放大 3 倍，要调用 3 万次 GDI 绘制函数。实际测试中这已经能跑出每秒 20 帧以上的刷新率，对静态图像的放大显示足够用了。如果想进一步提速，可以用 SetPixel 逐点填色代替 FillSolidRect，但那样代码可读性会更差，优化收益有限时就保持现状。

参数说明：m_pDibData 里每像素占 3 字节，存储顺序是 BGR，所以取颜色时写的 RGB(pPixel[2], pPixel[1], pPixel[0])，这个顺序反了就全图偏色。源区域坐标乘以 3 是因为每像素三字节的偏移计算，漏掉这一步读取到的颜色全部错位。

BOOL CZoomPart::DrawBilinear(CDC* pDC) { int dstW = m_rcDst.Width(); int dstH = m_rcDst.Height(); int srcW = m_rcSrc.Width(); int srcH = m_rcSrc.Height(); // 双线性插值：遍历目标像素，映射回源坐标做加权混合 for (int dy = 0; dy < dstH; dy++) { for (int dx = 0; dx < dstW; dx++) { // 目标像素中心映射到源图中的浮点坐标 double srcX = m_rcSrc.left + (dx + 0.5) * srcW / dstW - 0.5; double srcY = m_rcSrc.top + (dy + 0.5) * srcH / dstH - 0.5; // 边界钳制 if (srcX < m_rcSrc.left) srcX = m_rcSrc.left; if (srcY < m_rcSrc.top) srcY = m_rcSrc.top; if (srcX >= m_rcSrc.right - 1) srcX = m_rcSrc.right - 1.001; if (srcY >= m_rcSrc.bottom - 1) srcY = m_rcSrc.bottom - 1.001; int x0 = (int)srcX; int y0 = (int)srcY; double fx = srcX - x0; double fy = srcY - y0; COLORREF c00 = GetPixelColor(x0, y0); COLORREF c10 = GetPixelColor(x0 + 1, y0); COLORREF c01 = GetPixelColor(x0, y0 + 1); COLORREF c11 = GetPixelColor(x0 + 1, y0 + 1); // 各颜色通道按权重混合 int r = (int)((1-fx)*(1-fy)*GetRValue(c00) + fx*(1-fy)*GetRValue(c10) + (1-fx)*fy*GetRValue(c01) + fx*fy*GetRValue(c11)); int g = ...; // 同样的公式 int b = ...; pDC->SetPixel(m_rcDst.left + dx, m_rcDst.top + dy, RGB(r, g, b)); } } return TRUE; }

逻辑说明：双线性插值的思路是：目标像素反过来映射回源图坐标，找到它周围的四个源像素，按距离加权混合颜色。这个方法能让小数倍放大时线条保持平滑，代价是计算量成倍上升——每个目标像素要读四个源像素并做多次乘法。所以在实际工程中，我会给用户提供一个开关：需要高清放大时走双线性，需要流畅跟随时走最近邻。

参数说明：目标像素中心映射公式里的正负 0.5 是一个视觉校准细节。如果直接用 dx * srcW / dstW 映射，目标图像的左边缘会因为采样偏移而产生半像素级别的错位，放大后整体看起来会微微向右上偏移。加上 0.5 偏移量后，采样点对齐到源像素中心，视觉上更准确。边界钳制是为了防止读取源图之外的像素导致花屏。

4. 坐标换算与倍率的坑：缩放过视图、负高度的行序、30 万像素大图的性能

4.1 视图缩放后框选坐标偏移：先乘后除还是先除后乘

做局部放大最容易翻车的场景，就是源视图本身带了缩放。假设视图类用 SetScrollSizes 设置了映射模式，或者通过 SetViewportOrgEx / SetWindowExtEx 做了 1:2 的缩放显示，那么鼠标点按到视图客户区的坐标跟位图里真正的像素坐标之间就隔了一层变换。

有个某公司同事把代码写成：先对鼠标坐标做屏幕到逻辑坐标的转换，再用 CRect::IntersectRect 把选区限制在位图尺寸内，看起来每一步都合理，但放大窗口显示的内容始终是偏的。最后定位到问题：视图做了 2 倍放大显示，鼠标在屏幕上框出来的 200 像素宽矩形，对应位图里只有 100 像素。他在逻辑坐标层面对矩形取了交，交完之后的区域再除以 2，数值上等于先除 2 再取交，面积只有用户预期的一半。

我的习惯做法是：视图缩放比例在视图类里单独保存，框选交互拿到的是客户区坐标，直接除以缩放比例得到位图坐标，然后立刻和位图尺寸取交，不做中间层转换。这条规则写成注释贴在 OnLButtonUp 里，后续维护的人不会改出岔子。

4.2 负高度 DIB 的隐藏陷阱：行序、stride 和 24 位对齐

还有一类问题出在 GetDIBits 的行为差异上。用负高度获取数据时，行序是自上而下的，这跟很多图像处理库里"第 0 行是图像顶部"的约定一致。但需要注意的是，DIB 的每行字节数不一定等于 宽度 × 3，而是按 4 字节对齐的：

int stride = ((m_nWidth * 24 + 31) / 32) * 4; // 每行字节数，4 字节对齐

如果源图宽度是 100 像素，100 × 3 = 300 字节，300 正好可以被 4 整除，不会有问题。但当宽度是 101 时，303 字节，DIB 规定每行要补一个字节到 304。如果在取样代码里用 m_nWidth * 3 去计算行偏移，从第二行开始全部错位，放大图上会出现一条条 45 度的斜纹——这就是典型的 stride 错误导致的图像撕裂。

我处理这个问题的方法：在所有计算行偏移的地方统一用 stride 而不是 宽度 × 3。类里加一个成员 m_nStride，在 InitFromBitmap 里算好，后续读取像素全部走 GetPixelColor 内部封装，避免在多个循环里散落地写偏移公式。

4.3 大图放大的性能瓶颈：逐像素 SetPixel 慢到怀疑人生

双线性插值路径里如果直接用 pDC->SetPixel 逐点绘制，一个 300×200 的放大窗口意味着 6 万次 GDI 调用。在 Debug 模式下每秒只能刷新 3～5 帧，鼠标拖动时画面明显卡顿，而且窗口一被遮挡再露出来，重绘需要几百毫秒，交互体验非常差。

上线前性能优化我一般这样做：放大窗口的目标区域如果只有几千像素宽，直接建一个与目标区域等尺寸的内存位图，用 CreateDIBSection 拿到内存指针，在内存里把像素值算好填好，最后一次性 BitBlt 到窗口 DC。

BOOL CZoomPart::DrawToMemDC(CDC* pDC) { // 创建目标区域大小的 24 位 DIB 内存 BITMAPINFO bmi = {0}; bmi.bmiHeader.biSize = sizeof(BITMAPINFOHEADER); bmi.bmiHeader.biWidth = m_rcDst.Width(); bmi.bmiHeader.biHeight = -m_rcDst.Height(); bmi.bmiHeader.biPlanes = 1; bmi.bmiHeader.biBitCount = 24; bmi.bmiHeader.biCompression = BI_RGB; BYTE* pBits = NULL; HBITMAP hBmp = ::CreateDIBSection(NULL, &bmi, DIB_RGB_COLORS, (void**)&pBits, NULL, 0); if (!hBmp) return FALSE; // 直接在 pBits 上按目标坐标写入像素 for (int dy = 0; dy < m_rcDst.Height(); dy++) { for (int dx = 0; dx < m_rcDst.Width(); dx++) { // 插值计算得到 clr BYTE* pDst = pBits + (dy * m_rcDst.Width() + dx) * 3; pDst[0] = GetBValue(clr); pDst[1] = GetGValue(clr); pDst[2] = GetRValue(clr); } } // 一次性画到目标 DC CDC memDC; memDC.CreateCompatibleDC(pDC); HBITMAP hOld = (HBITMAP)::SelectObject(memDC.GetSafeHdc(), hBmp); pDC->BitBlt(m_rcDst.left, m_rcDst.top, m_rcDst.Width(), m_rcDst.Height(), &memDC, 0, 0, SRCCOPY); ::SelectObject(memDC.GetSafeHdc(), hOld); ::DeleteObject(hBmp); return TRUE; }

逻辑说明：CreateDIBSection 会返回一块可以直接读写的内存，这块内存同时也能被选入 DC 当作位图使用。整个放大过程改成两步：先在内存里填像素，再把内存整块搬到目标 DC。这样 GDI 绘制调用从几万次降到一次 BitBlt，性能提升是数量级的。实测一个 400×300 的放大窗口，从原来每秒 4 帧提升到每秒 40 帧以上，鼠标拖动时基本无卡顿。

参数说明：CreateDIBSection 的 pBits 是系统返回的指针，不能自己释放，必须通过 DeleteObject 删除 HBITMAP 来间接释放。写入时同样要注意行对齐，但这里我们创建的 DIB 宽度对应的 stride 直接用 宽度 × 3 就可以，因为 CreateDIBSection 内部会自动按 4 字节对齐，只要写入时按矩阵索引走，交给系统处理即可。

5. 实战避坑：位图生命周期、窗口遮挡重绘、多显示器 DPI 下框选不准的排查

5.1 源位图被提前释放导致放大区花屏

现象：局部放大窗口工作正常，但用户在主视图里滚动或切换文档之后，放大区出现随机颜色的噪点，有时干脆整块黑屏。

原因：CZoomPart 只保存了 CBitmap 指针，没有持有所有权。视图类里如果重新加载了位图，旧位图对象被 delete，而放大组件还拿着那个已失效的指针去 GetDIBits，读取到的是堆上已被释放的残留数据。

解决：约定源位图生命周期规则——视图类负责保证"位图加载完成后到下一次加载前"这个时间段内，CZoomPart 的指针一直是有效的。在视图类加载新位图时，先调用 zoomPart.SetSourceBitmap(NULL) 清空引用，再替换位图对象。如果视图销毁顺序不确定，可以在 CZoomPart 的析构函数里只做置空操作，不做 delete，从根上避免双删。

5.2 放大窗口被遮挡后重绘画出残影

现象：放大视图弹出后，用户拖一个对话框盖住它，再移开，放大区域变成一块灰白色的残留，内容迟迟不刷新。

原因：放大视图类如果没有在 WM_PAINT 里做完完整的背景擦除和重绘，而是依赖之前的 DC 内容，Windows 在窗口被遮挡后不会自动保存底层窗口的绘制结果。另一个常见原因是 OnEraseBkgnd 里直接返回 TRUE，跳过了背景擦除，导致新图画在旧画之上造成重叠残影。

解决：在放大视图的 OnPaint 里先调用 InvalidateRect 全区域无效化，再设置背景色为白色或黑色后执行 BitBlt。建议在 OnEraseBkgnd 里调用 CView::OnEraseBkgnd 做完整擦除，不要为了省一次重绘而返回 TRUE。这里的血泪经验是：省掉一次背景擦除，换来的是用户拖动窗口时满屏残影，得不偿失。

5.3 双显示器不同缩放比例下框选偏移

现象：系统设置了 150% DPI 缩放，用户把主窗口拖到扩展显示器上，框选放大时选取区域明显偏右、偏下。

原因：MFC 的鼠标坐标在 DPI 感知变化后，如果进程没声明 Per-Monitor DPI Aware，系统会对客户区坐标做虚拟化处理，屏幕上看到的坐标和逻辑坐标之间出现缩放偏差。在跨显示器的场景下，两个屏幕的 DPI 不同，坐标变换更加不可预测。

解决：在程序入口处调用 SetProcessDpiAwarenessContext 声明 Per-Monitor DPI Aware，然后所有坐标按物理像素处理。这需要同时在项目清单文件里指定 dpiAware 和 dpiAwareness 字段。如果项目对老系统的兼容性有硬性要求，可以在初始化时用 GetDpiForWindow 动态获取当前窗口 DPI，再将鼠标坐标除以 DPI/96 做转换。

5.4 连续框选后放大内容停留在上一次选择

现象：用户第一次框选正常，第二次框选后放大视图不变，仍然显示第一次的内容。

原因：第二次框选后只改了 SrcRect，但目标 DC 里画的是旧数据，且视图的 OnPaint 里没有根据 SrcRect 的变化做 Invalidate。更隐蔽的情况是框选区域和上一次完全相同，系统认为无需重绘窗口，拖动窗口后内容才对。

解决：在 SetSrcRect 后强制调用放大视图的 Invalidate(FALSE)——注意参数用 FALSE，只让客户区无效而不擦除背景，然后 RedrawWindow 立即触发重绘。不要依赖窗口系统自动检测矩形区域变化来判定是否需要重绘。

6. 进阶技巧：放大跟随模式、像素交叉准星和滚动同步

放大组件做到能框选显示只是第一步，实际项目里用户用得顺手的，通常是两种增强模式。第一种叫"跟随模式"：鼠标在主视图上移动时，放大区实时显示以鼠标指针为中心的局部区域，相当于一个数字放大镜。实现方式是把 OnMouseMove 里的框选逻辑替换为：以鼠标位置为中心点，取一个固定矩形（比如源图 200×150 范围），然后实时更新 SrcRect 并重绘放大视图。跟随模式的关键是把重绘频率控制在合理范围——建议只在鼠标移动距离超过 2 个像素时才触发刷新，避免高频消息风暴拖慢主线程。

第二种增强是"准星指示"：放大区中央画一个十字准星，同时主视图里对应位置画一个红色半透明矩形框。这样用户能同时看到"放大的内容"和"放大内容在源图中的具体位置"。实现方式是在视图 OnPaint 的最后叠加绘制一个 CRectTracker 或用 DrawFocusRect 画红色框，放大区里则在中心画一个灰色十字线。这两处是纯绘制逻辑，不参与交互，实现成本极低但体验提升非常明显。

我个人的一个技巧习惯：放大组件在测试阶段始终保留一个调试宏，开启后把源矩形和倍率以文字形式绘制到放大区的左上角。开发期用 Visual Studio 调试器看到的数值跟屏幕上画出来的不一致时，对比这个调试信息能快速定位到底是坐标换算错还是绘制逻辑错。这个习惯帮我节省过好几次因为视图缩放比例没同步导致的排查时间。

另一个值得做的优化是滚动同步。如果主视图是可滚动的（比如 CScrollView），框选放大内容后，用户在主视图里滚动一段距离，放大区应该重新计算并跟随。做法是在 OnVScroll 和 OnHScroll 里调用 zoomPart.SetSrcRect 中的偏移量做增量减法，然后触发放大区重绘，这种联动比让用户重新框选一次友好得多。

写这套组件的经验里，最大的教训是：局部放大的实现从来不复杂，复杂的是坐标体系的一致性。只要源位图坐标、视图显示坐标、鼠标客户区坐标三者之间建立一条单向的转换链路，并且全程只用这一条链路，放大功能就能稳定工作。凡是出现"放大区显示的位置不对"这类玄学问题，百分之九十都是某一处转换路径绕了原路或走了捷径。希望这篇笔记能帮你少踩几个类似的坑，也希望你项目里的放大组件一次写对。

本文还有配套的精品资源，点击获取