简介EeceChart.zip 是一份面向 C# 开发者与数据分析可视化学习者的实战项目包围绕 Excel 数据读取、曲线绘制和交互式图形操作展开可用于桌面端小型分析工具的原型搭建与技能练习。压缩包共 216 个文件约 46.67MB包含 cs 源码、dll 依赖库、xml/config 配置、nupkg 安装包、txt 说明与图片预览等便于理解项目结构、复现实验流程并定位关键实现。项目涉及 Office Interop 读写 Excel、随机抽样、GDI 或 WPF 曲线映射、鼠标右键拖动缩放、曲线平均值计算、图形重绘与异常处理等知识点并演示将处理结果写回表格。已有 245 人学习适合希望把 Excel 处理、统计计算与图形交互串成完整案例的读者对照实践也可供课程设计参考。1. 解压 EeceChart.zip 之前先分清「自己画图」和「调库画图」的边界前阵子有人问我一个纯 C# 的桌面小工具要画三条折线、一根柱状、带图例、能导出 PNG装第三方图表组件要授权发布时还得跟着一串 DLL能不能自己写。能而且这类需求里最省事的路径往往就是拿一份现成的 C# 自绘图表源码改。EeceChart.zip 就是这一类东西基于 System.Drawing 的图表绘制源码包把坐标轴、刻度、折线/柱状/饼图的绘制、图例和导出这几件事封在若干类里不依赖外部组件放进 WinForms 工程就能跑。它适合内部报表、采集上位机、测试工装、打印单据附页这种「图不复杂但不能没有」的场景也适合拿来当学习 GDI 坐标系和绘制的脚手架不适合做交互复杂的大屏、实时百万点渲染或者需要 3D 的场合。先认清这个边界后面每一步才不会走偏。2. 拆包与工程接入把 zip 变成能 F5 跑起来的 C# 工程拿到一个源码包最忌讳的是双击 .sln 看到能跑就以为接入完成了真正要拿走的是「绘图核心」那一层示例窗体只是说明书。这一章按解压、看结构、选接入方式、跑通第一张图的顺序走一遍。2.1 解压后先看三样东西解决方案、绘图核心、示例窗体解压出来的目录结构各家不一样但负责的事情大同小异。下面这张表是我拆这类 C# 图表包时的固定检查清单你对照着自己那份看一眼就知道哪部分是「要拿走的」、哪部分是「看完就删的」。位置职责处理方式根目录 .sln / .csproj把核心库和示例串起来保证能编译只用来验证环境不带走Chart / Drawing 之类目录坐标轴、序列、绘制、图例的真正实现这是要拿走的全部Demo / Form 之类目录演示数据怎么灌、属性怎么设当文档读读懂了删Properties / Resources默认图标、字体、配色注意字体授权能删就删bin / obj上次编译产物直接删别混进你的仓库值得多花十分钟的是绘图核心里的命名空间划分。常见做法是按「模型 渲染 交互」三层拆模型层放数据点和序列渲染层放坐标轴和画笔交互层放命中测试和缩放。如果解压后这三层混在一个几千行的 Form 里说明这份源码是「能跑优先」的风格你接入时最好先自己分层否则改到第三个需求就会失控。提示先看 .csproj 里的 TargetFramework。老包多半是 .NET Framework 4.x代码里大量 System.Drawing 的同步调用迁到 .NET 6/8 的 Windows 目标框架下基本能直接编但 System.Drawing.Common 在非 Windows 平台已经不被支持这点在选型时就要认下来。2.2 接入方式项目引用还是源码拷贝先定死两种接入方式各有代价我的经验是按「这个图会不会长期演进」来选。项目引用新建一个类库工程装绘图核心主程序引用它。核心有 bug 时集中改一处多个内部工具共享同一份代价是多一个 DLL 要发布。源码拷贝把绘图核心目录整个拖进主工程的一个子目录。发布只有一个 exe代价是改核心时容易和原始版本分叉后面想合回来很麻烦。给一段最小接入流程用 .NET SDK 风格的工程演示老式 csproj 需要手动加Compile IncludeSDK 风格默认会把子目录下所有 .cs 编译进去# 1. 建一个 WinForms 工程目标框架按需改 net48 / net6.0-windows / net8.0-windows dotnet new winforms -n ChartDemo -f net8.0-windows # 2. 进入工程目录把 EeceChart 的绘图核心目录整个拷到 Chart/ 下 cd ChartDemo mkdir Chart # 拷贝操作按你的解压路径来这里只表达「整目录搬过去」这个动作 # 3. 编译先确认没有任何第三方 DLL 依赖 dotnet build编译阶段最常见的两类报错一类是未能找到类型或命名空间名说明命名空间和你 using 的对不上去文件头看一眼namespace补上即可另一类是System.Drawing.Common 在此平台上不受支持那是目标框架写成了跨平台的net8.0而不是net8.0-windows改框架而不是改代码。注意如果你顺手把 bin/obj 一起拷进了仓库第一次编译可能出现「重复定义」之类的怪错。清掉这两个目录再编一次比重装 SDK 快得多。2.3 第一个图三步把数据灌进去看到线下面的示例是我接入这类图表包时的固定模板。里面出现的EeceChartControl、ChartSeries、ChartPoint是我在接入层统一过的包装名你解压后看到的具体类名可能叫别的对照着换掉即可方法体和参数含义是通用的。using System; using System.Drawing; using System.Windows.Forms; public class MainForm : Form { // 图表控件铺满窗体先跑通再谈布局 private readonly EeceChartControl _chart new EeceChartControl(); public MainForm() { Text EeceChart 最小示例; ClientSize new Size(900, 520); _chart.Dock DockStyle.Fill; _chart.BackColor Color.White; Controls.Add(_chart); Load (s, e) BindDemoData(); } private void BindDemoData() { // 序列 名字 颜色 一串点 var series new ChartSeries(温度, Color.FromArgb(0x2E, 0x86, 0xDE)); for (int i 0; i 60; i) { // X 用索引Y 造一个正弦方便肉眼判断画得对不对 series.Points.Add(new ChartPoint(i, 20 5 * Math.Sin(i / 6.0))); } _chart.Series.Add(series); // 轴标题只是标签真正决定范围的是数据本身这点后面第 3 章展开 _chart.AxisX.Title 采样点; _chart.AxisY.Title 温度 / 摄氏度; // 手动触发一次重绘避免依赖控件自己的刷新时机 _chart.Invalidate(); } }这段代码有三个点值得说清楚。第一Load事件里绑数据而不是构造函数里是为了让控件先完成句柄创建避免早期版本里在OnPaint之前访问Graphics抛异常。第二Invalidate()走的是「异步标记 消息循环重绘」比直接调Refresh()温和连续改数据时不会把 UI 线程拖死。第三X 轴用索引而不是时间戳是因为第一次跑通时你最想确认的是「线画得直不直、抗锯齿开没开」不是「时间格式对不对」。跑通之后先做一次自检把窗体拉大拉小看线和文字有没有跟着重排把数据改成 0 到 1 之间的小数看 Y 轴刻度是不是自动变成 0.1/0.2把某条序列的点清空看控件是消失还是抛异常。这三个动作能暴露绝大部分「示例能跑、接进去就翻车」的问题。3. 坐标映射与绘制流程一条折线是怎么落到像素上的跑通之后就该看内部了。图表包最容易出问题的地方不是「画不出来」而是「画出来了但对不上」——刻度和数据错位、Y 轴方向反了、0 值不在轴上。这一章把数据域到像素域的换算、刻度步长的选取、双缓冲与重绘顺序拆开讲这些都是你后面调参数时绕不开的。3.1 数据域到绘制域四个必须自己算清楚的量任何一张图无论多简单绘制前都要先把这四个量确定下来数据最小值dataMin、数据最大值dataMax、绘图区左上角像素坐标plotLeft/plotTop、绘图区宽高plotWidth/plotHeight。绘图区不等于控件区域还要扣掉左侧 Y 轴标签宽度、底部 X 轴标签高度、右上角留白和图例占位。换算本身是一行线性映射坑都藏在边界条件里。下面这段是我在接入层统一改写过的版本把几个必踩的坑提前堵住/// summary /// 把数据值换算成像素坐标 /// /summary /// param namevalue原始数据值/param /// param namepixelStart绘制区起点X 轴用 leftY 轴用 top/param /// param namepixelLength绘制区长度宽或高/param /// param nameinvertedY 轴为 true因为屏幕坐标向下为正/param public float DataToPixel(double value, float pixelStart, float pixelLength, bool inverted) { // 坑 1整条序列最大值等于最小值时span 为 0除法后整条线变成 NaN 直接不画 double span _dataMax - _dataMin; if (Math.Abs(span) 1e-12) span 1.0; double ratio (value - _dataMin) / span; // 归一化到 0..1 float px pixelStart (float)(ratio * pixelLength); // 坑 2屏幕 Y 轴向下数据 Y 向上不翻转的话图是上下颠倒的 if (inverted) px pixelStart pixelLength - (px - pixelStart); // 坑 3浮点换算出的边缘值可能刚好落在绘制区外一像素被裁剪掉一截 return Math.Max(pixelStart, Math.Min(pixelStart pixelLength, px)); }三个参数里最容易含糊的是inverted。很多实现图省事直接在设置dataMin/dataMax时把大小反过来传结果 X 轴和 Y 轴共用一套逻辑图例、命中测试、导出全跟着错。我一般坚持「数据域永远小到大翻转只在像素映射这一层做」改起来只有一行。另一件必须在接入时就定死的事是dataMin/dataMax的来源自动还是手动。自动计算的常见做法是遍历所有可见序列取极值再向上下各留 5% 到 10% 的余量手动则通过轴的属性直接赋值。两者混用时一定要有优先级规则否则会出现「设置了手动范围、加一条序列又被自动改回去」的玄学现象。3.2 刻度步长为什么你的 Y 轴刻度是 0.3333、0.6666自动范围算出来了刻度怎么切最粗暴的做法是把跨度除以固定份数比如 10 份得到的刻度标签往往是 0.3333、3.6667 这种没人想看的东西。合格的实现要引入「好看的数字」步长只能是 1、2、5 乘以 10 的整数次幂。/// summary /// 把粗糙步长规整成 1/2/5 × 10^n 的「好看步长」 /// /summary private static double NiceStep(double roughStep) { if (roughStep 0) return 1; double exp Math.Floor(Math.Log10(roughStep)); double baseUnit Math.Pow(10, exp); double f roughStep / baseUnit; // 落在 1..10 之间 double niceF f 1 ? 1 : f 2 ? 2 : f 5 ? 5 : 10; return niceF * baseUnit; }这个函数本身只有十行关键是怎么算入参roughStep。我给的经验是先用(dataMax - dataMin) / targetTickCount得到粗糙步长其中targetTickCount不写死而是按绘制区高度除以「相邻刻度最小像素间距」估算折线图纵向给 50 到 70 像素一个刻度横向给 80 到 100 像素这样在 900×520 的窗口里大约 6 到 8 个刻度放大窗口刻度自动变密视觉效果比较稳。有了步长还要处理起点常见做法是dataMin向下取整到步长的整数倍dataMax向上取整然后把轴范围按整刻度重新赋值。这一步不做的话轴的两端会出现半截刻度视觉上很别扭。负数和跨零数据在这里要多看一眼0 刻度必须落在真实位置不能因为取整把 0 挪走了很多「零值不在轴上」的投诉都出在这里。3.3 绘制顺序与双缓冲图会闪、拖窗口一片白问题都在这GDI 绘制图表有严格的层次顺序顺序错了会出现网格盖住折线、图例被裁剪、轴标签被背景刷掉之类的怪象。我固定按这个次序写OnPaint背景填充 → 网格线 → 坐标轴与刻度标签 → 数据序列 → 数据标签 → 图例 → 交互高亮十字线、选中点。数据序列必须画在网格之后、图例之前理由简单——网格是参考线不能压住数据图例是覆盖层必须最后画。闪烁的根源几乎总是同一件事控件先被系统用背景色擦一遍再画你的内容两个动作之间被用户看见了。解法是把三件事一起做public class EeceChartControl : Control { public EeceChartControl() { // 四件套自己擦背景 双缓冲 全部绘制走 OnPaint 尺寸变化就重绘 SetStyle(ControlStyles.AllPaintingInWmPaint | ControlStyles.OptimizedDoubleBuffer | ControlStyles.UserPaint | ControlStyles.ResizeRedraw, true); UpdateStyles(); } protected override void OnPaint(PaintEventArgs e) { var g e.Graphics; g.SmoothingMode SmoothingMode.AntiAlias; // 折线抗锯齿 g.TextRenderingHint TextRenderingHint.ClearTypeGridFit; // 文字清晰 g.PixelOffsetMode PixelOffsetMode.HighQuality; // 细线不糊 DrawBackground(g); DrawGrid(g); DrawAxes(g); DrawSeries(g); // 数据量大时这一行最慢后面第 5 章专门说 DrawLegend(g); } }ControlStyles.UserPaint不允许系统帮你擦背景OptimizedDoubleBuffer让绘制先落到内存位图再一次性贴到屏幕。这两个合起来拖窗口和实时刷新都不会再闪。代价是内存多一张与控件等大的位图900×520 大约 1.8MB可以接受但如果你在界面上摆十个图表控件就得考虑按需创建。还有一个容易被忽略的点抗锯齿是全局开关开了之后细线和高密度数据都会变慢。我的习惯是交互过程中拖动、缩放、实时刷新关掉抗锯齿交互停止后 150 毫秒再开回来重绘一次。用户在动的时候看不出锯齿停下来看到的又是平滑的版本卡顿感能明显下降。4. 交互补全命中测试、缩放平移与图片导出图能画对之后用户的下一个要求通常是「鼠标指上去要显示数值」。这一章讲三件事怎么判断鼠标点中了哪个数据点、怎么在不改数据的前提下做缩放平移、怎么把当前视图导出成一份能贴进文档的图片。4.1 命中测试不要用矩形去套点用距离新手写命中测试最常见的写法是判断鼠标是否落在数据点周围 5×5 的矩形里。这个做法在折线上会漏掉「两个点之间那一段线」用户点了线上却选不中体验很差。我一般做成两级先找最近的顶点再判断是否落在线上。/// summary /// 命中测试返回鼠标附近的数据点索引找不到返回 -1 /// /summary /// param namemouseX鼠标 X控件坐标/param /// param namemouseY鼠标 Y控件坐标/param /// param namehitRadius命中半径按 DPI 缩放后传入通常 6~8 像素/param public int HitTest(float mouseX, float mouseY, float hitRadius) { int bestIndex -1; double bestDistSq hitRadius * hitRadius; for (int i 0; i _visibleCount; i) { float px DataToPixel(_xs[i], _plotLeft, _plotWidth, false); float py DataToPixel(_ys[i], _plotTop, _plotHeight, true); double dx px - mouseX; double dy py - mouseY; double distSq dx * dx dy * dy; if (distSq bestDistSq) { bestDistSq distSq; bestIndex i; } } return bestIndex; }这段的复杂度是 O(n)点数在一两千以内完全够用鼠标移动触发的频率也就几十赫兹。点数上万时就得换方法按 X 像素排序后二分查找近邻再只对邻近的若干个点做距离判断把 O(n) 降到 O(log n)。hitRadius不建议写死成 5要按当前 DPI 缩放否则 150% 缩放的屏幕上会出现「看着点中了但选不中」的怪事。命中之后的高亮绘制也很讲究。常见做法是在命中点画一个半径 3 到 4 像素的实心圆加一圈白边再在附近弹一个轻量提示框。提示框不要用 ToolTip 控件那个有几毫秒延迟跟随鼠标会很迟钝自己在OnPaint的最后一步画一个圆角矩形更跟手代价是要自己算边界防止提示框跑出控件外。4.2 缩放与平移改视窗不动数据很多人实现缩放的第一反应是「缩放时把数据乘以系数」这是错的。正确做法是维护一个「可视窗口」——也就是当前 X 轴和 Y 轴的显示范围viewMinX/viewMaxX/viewMinY/viewMaxY所有绘制、命中测试、导出都用这四个值原始数据一个字节都不动。这样做的好处是缩放随时可以无损还原也不会因为反复乘除引入精度误差。滚轮缩放的难点是「以鼠标位置为锚点」不处理的话会变成以控件中心缩放用户想放大的那块总是跑出视野。/// summary /// 以鼠标位置为锚点做 X 轴缩放 /// /summary /// param namemouseX鼠标在控件内的 X 坐标/param /// param namefactor缩放因子向上滚 0.8缩小范围放大向下滚 1.25/param private void ZoomAtX(float mouseX, double factor) { // 1. 鼠标位置换算成当前视窗里的数据值这个值在缩放前后要保持不变 double anchor PixelToData(mouseX, _plotLeft, _plotWidth, _viewMinX, _viewMaxX); // 2. 视窗范围按因子收缩或扩张 double leftSpan anchor - _viewMinX; double rightSpan _viewMaxX - anchor; _viewMinX anchor - leftSpan * factor; _viewMaxX anchor rightSpan * factor; // 3. 限制最小跨度防止滚到无穷小之后全是 NaN if (_viewMaxX - _viewMinX 1e-9) { /* 还原到上一步 */ return; } ClampToDataRange(); // 可选不允许滚出数据边界 Invalidate(); }factor取 0.8/1.25 是为了让「放大三步、缩小三步」大致回到原位因为它俩互为倒数。如果取 0.9/1.1用户会感觉缩小比放大慢越缩越远。平移同理用鼠标按下时的坐标差换算成数据差直接加到viewMin/viewMax上注意要在按下时把Capture true不然鼠标移出控件就丢了事件。4.3 导出图片不要用 DrawToBitmap 截屏导出是这类图表包最容易被低估的功能。用户要的是「把这张图贴进报告」不是「截一张 900×520 的屏幕图」。有些实现直接调Control.DrawToBitmap简单是简单但有两个硬伤一是走窗口 DC受 DPI 虚拟化影响150% 缩放下导出的图会被系统拉伸导致模糊二是控件不可见或部分被遮挡时导出内容不完整。我一般改用「离屏位图 同一套绘制方法」/// summary /// 把图表渲染到指定像素尺寸的位图供导出或打印使用 /// /summary /// param namewidthPx目标宽度像素/param /// param nameheightPx目标高度像素/param /// param namedpi目标 DPI屏幕用 96打印用 300/param public Bitmap RenderToBitmap(int widthPx, int heightPx, float dpi 96f) { var bmp new Bitmap(widthPx, heightPx); bmp.SetResolution(dpi, dpi); using (var g Graphics.FromImage(bmp)) { g.SmoothingMode SmoothingMode.AntiAlias; g.TextRenderingHint TextRenderingHint.ClearTypeGridFit; // 关键让绘制逻辑里的像素常量跟着 DPI 走而不是被硬编码成 96 float scale dpi / 96f; g.ScaleTransform(scale, scale); // 绘制区按缩放后的逻辑尺寸传入保证布局比例一致 DrawChart(g, (int)(widthPx / scale), (int)(heightPx / scale)); } return bmp; }这样做的意义在于屏幕显示和导出用的是同一个DrawChart只有尺寸和 DPI 两个入参不同不会出现「屏幕上一个样、导出后另一个样」。dpi参数必须真的传进SetResolution否则 PNG 里记录的还是 96插进 Word 之后尺寸会变成原图的 3 倍多排版直接乱掉。提示导出大尺寸时比如 3000×2000记得临时关掉抗锯齿再打开或者分块绘制。GDI 对超大位图上的抗锯齿路径有性能悬崖一张图卡上两三秒很常见。5. 踩坑记录五个把图画出错地方的常见问题前面讲的都是「应该怎么做」这一章全是「做错了会怎样」。下面五条都是我在接入这类 C# 图表包时真实撞见过的按现象、原因、解决三段写能对上号就直接抄。5.1 图是空的只有坐标轴和网格现象控件显示出来了轴、网格、图例都在就是没有折线也不报错。原因有两类。一类是数据进去了但轴的自动范围没重算dataMin和dataMax还停在 0 和 1所有数据点都落在绘制区之外被裁剪掉了。另一类是序列被加到了Series集合里但控件的_visibleCount缓存没更新绘制循环遍历的是 0 个点。解决把「范围重算」挂到序列集合的变更事件里而不是依赖调用方记得手动调同时在OnPaint开头做一次防御性检查若_visibleCount与实际集合数量不符就重建缓存。更省事的办法是在Invalidate之前强制调用一次RecalculateRange()代价是每帧多一次遍历数据量大时要注意。5.2 高 DPI 屏幕上文字发虚、线粗细不对现象笔记本外接 4K 显示器程序界面被系统放大后图表里的轴标签糊成一团1 像素的网格线变成 3 像素粗。原因进程没有声明 DPI 感知Windows 把整个窗口当成位图整体拉伸相当于把 96 DPI 的画面放大 2 倍任何文字都必然模糊。解决在应用清单里声明 PerMonitorV2 支持让程序自己处理缩放。?xml version1.0 encodingutf-8? assembly manifestVersion1.0 xmlnsurn:schemas-microsoft-com:asm.v1 application xmlnsurn:schemas-microsoft-com:asm.v3 windowsSettings dpiAwareness xmlnshttp://schemas.microsoft.com/SMI/2016/WindowsSettingsPerMonitorV2/dpiAwareness dpiAware xmlnshttp://schemas.microsoft.com/SMI/2005/WindowsSettingstrue/dpiAware /windowsSettings /application /assembly声明之后还要在代码里响应DpiChanged事件把字体大小、刻度间距、命中半径这些「按像素写死」的常量按DeviceDpi / 96f重算一遍否则图不会糊了但标签会挤在一起。5.3 数据上万点后鼠标一动就卡现象静态显示还行鼠标划过或者拖动缩放立刻掉到十几帧任务管理器里 CPU 单核跑满。原因每次OnPaint都对全量点做抗锯齿的DrawLines还要为每个点计算并绘制标记GDI 在这些路径上没有做任何优化。再加上鼠标移动触发的高亮又调用了一次全量重绘等于一帧干了两遍活。解决三件事一起做——按像素抽稀把每个像素列内的多条数据聚合成最小值和最大值两个点一万点画在 900 像素宽的图上抽稀后只有 1800 个点交互过程中关闭抗锯齿和数据点标记只画线高亮改成局部失效只重绘变化的那一小块矩形区域。5.4 负数和跨零数据的刻度全挤在 0 附近现象数据在 -3 到 3 之间轴范围自动算成 -3 到 3但刻度标签显示成 -2、-1、0、1、20 的两边挤着两行字。原因NiceStep只按总跨度算步长没考虑「跨零时 0 必须是一个真实刻度」这个约束。跨度 6 除以目标刻度数 8 得到 0.75规整成 1从 -3 开始切分得到 -3、-2、-1、0、1、2、3正好七个刻度本身没错出问题的是范围起点用了dataMin而不是规整后的整刻度0 落在两个刻度的中间位置。解决范围起点和终点都按步长向下、向上取整保证 0 一定落在刻度点上同时按标签最长字符串的实际像素宽度反算最小刻度间距宽度不够就减少刻度数量宁可少画两个刻度也不要叠字。5.5 导出的 PNG 和屏幕上看到的不是一张图现象屏幕上字体大小正常导出后字体变得很大图例位置也偏了。原因导出时复用了控件当前的绘制参数包括按屏幕 DPI 算好的字体大小和绘图区尺寸但位图的物理尺寸和 DPI 是另一套。两套坐标系混在一起所有「先算好再画」的常量都错位了。解决把绘制逻辑抽成一个只接受Graphics、逻辑宽高、DPI 三个入参的函数屏幕绘制和导出绘制都调它禁止在绘制函数里读控件属性。改完之后屏幕和导出就是同一个函数的两组参数不会再出现两套行为。6. 从能看 to 能交付把输出对齐全场景图在屏幕上对了不代表交付就完成了。实际项目里这张图大概率要进打印、进 PDF、进 Word甚至被贴到别的系统里这时候高 DPI 和字号就成了新的战场。我的习惯是先统一单位。绘制函数内部一律用「逻辑像素」也就是 96 DPI 下的像素所有硬编码的常量线宽 1、刻度长 5、标签间距 6都按逻辑像素写真正落到Graphics之前用一个scale dpi / 96f的ScaleTransform一次性放大。这样同一份绘制代码在 96 DPI 的屏幕、192 DPI 的外接屏、300 DPI 的打印输出上比例关系完全一致不会出现「屏幕上线很细、打印出来看不见」的情况。字体是第二个要单独立规矩的东西。不要用new Font(宋体, 9)这种写死字号的方式改成按逻辑像素反算fontSize 12 / 96f * dpi或者干脆声明时用点pt为单位让 GDI 自己做换算。中英文混排时还要注意默认的 ClearType 在打印输出上会失效打印前把TextRenderingHint切成AntiAliasGridFit字形边缘会干净很多。验证方法我给一个笨但有效的准备一份已知答案的数据比如 X 从 0 到 10 步长 1、Y 等于 X 的平方然后写一个断言检查绘制前算出的关键点像素坐标是否落在预期位置容差给 1 像素。// 用已知数据验证坐标映射比肉眼盯着看靠谱 var chart new EeceChartControl(); chart.SetRange(0, 10, 0, 100); // X: 0~10, Y: 0~100 chart.SetPlotArea(50, 20, 800, 400); // left, top, width, height // X10 应该落在绘制区最右边Y100 应该落在最上边 AssertNear(810f, chart.DataToPixelX(10), 1f); AssertNear(20f, chart.DataToPixelY(100), 1f); // Y0 应该落在最下边这条最容易因为翻转写错而出问题 AssertNear(420f, chart.DataToPixelY(0), 1f);这四个断言覆盖了 X 正向、Y 翻转、边界裁剪三种情况每次改完坐标映射相关代码跑一遍比截图对比快得多。导出和打印也走同一套断言只是入参换成对应 DPI能一次把「屏幕对、导出错」的问题挡在提交之前。血泪经验是我曾经因为导出时忘了给位图设SetResolution一份 300 DPI 的图在文档里被当成 96 DPI 显示尺寸放大了三倍多排版全部重做。从那以后我每次动导出相关的代码都强制走一遍「96 和 300 两个 DPI 各导一张、量一下物理尺寸」的检查哪怕只改了一个颜色常量。希望帮到你。本文还有配套的精品资源点击获取