WinForms自绘CheckBox ComboBox：多选下拉控件实现与避坑指南

简介：在Windows桌面应用开发中，带复选框的下拉列表是多选场景的常见方案。这份WPF工程源码演示了如何从ComboBox基类派生自定义控件，核心思路是在内部嵌入一个ListBox，用CheckBox作为每个条目的选择标记；开发者需要重写下拉区域的生成逻辑，并对每一项的点击事件进行监听，最终将选中集合回写到绑定数据源中。整个zip压缩包一共包含55个文件，核心代码集中在15个cs文件和3个xaml文件中，另有resources、resx等资源文件辅助界面配置，以及编译过程生成的pdb、exe、dll等文件，方便直接运行查看效果，而包体只有125KB，下载使用都很轻量。该Demo项目结构清晰，从解决方案文件到后台Codebehind逻辑一应俱全，覆盖了控件初始化、DataSource关联、事件驱动更新、UI布局和主题微调等环节，代码注释也便于理解，适合拿来做二次开发起点。已有495人学习浏览，对于希望掌握WPF自定义控件扩展能力、解决多选下拉交互难题的开发者，是一份实用的参考实例。

1. 带CheckBox的ComboBox：用WinForms源码把勾选能力装进原生控件

带CheckBox的ComboBox这个问题，我在好几个项目里都被业务方追着问过：下拉框要能勾选多行。原生WinForms的ComboBox只能单选，CheckedListBox又只是普通列表，和下拉交互完全不是一回事。刚好我手上维护过一套自绘实现的源码，把复选框画进ComboBox的每一行，同时处理了点击命中、文本回显、C#里指定项默认勾选这三件最常用的需求。

这套方案的好处是控件的对外接口和原生ComboBox基本一致，老代码里把ComboBox换成CheckBoxComboBox就能用，数据绑定和事件都不需要动。特别适合WinForms维护项目里快速交付一个多选下拉控件，也适合想搞懂ComboBox自绘机制的工程师照着源码一步步复现。下文从绘制模型讲到实现细节，再把五个典型的坑按现象、原因、解决拆开写。

2. 为什么原生ComboBox做不了多选：先看清绘制模型与选型

2.1 原生ComboBox的绘制流程：DrawMode才是自绘入口

很多人一开始跟我一样，想在ComboBox的Paint事件里画一个CheckBox，结果发现根本没用。原因是ComboBox不是一个简单控件，它是TextBox加按钮加内部ListBox的组合。点击下拉箭头后，真正把列表画出来的，是那个内部的ListBox窗口，不是ComboBox自己的绘图表面。所以要在每一行前方画勾选框，就得让内部ListBox进入自绘模式。

DrawMode就是入口。它有三个枚举值。Normal是完全交给系统绘制，项高度固定，不触发任何绘制事件，原生下拉就是这种。OwnerDrawFixed把每项的高度统一交给ItemHeight控制，但项的绘制逻辑全部由DrawItem事件接管，绘制时e.Bounds给出每一行的矩形区域。OwnerDrawVariable更进一步，每项的高度可以先由MeasureItem测量再决定，适合项高度不一致的情况，比如图文混排。这里选OwnerDrawFixed就够了——CheckBox是固定16像素，文本也是一行，没有理由让每项高度不同。

还有一个容易被忽略的点：ComboBoxStyle里有一个Simple模式，它会在窗体上平铺一个常驻的ListBox，视觉上完全失去了“下拉”的概念，做筛选面板根本没法用，直接排除。DropDown和DropDownList两种模式下，内部ListBox只在下拉时弹出，DrawItem的绘制才会出现在预期的位置。

还有一点容易被忽略：DrawItem事件里的e.Graphics，对应的就是内部ListBox的绘图表面。所以在这个事件里画矩形、画CheckBox，画出来的位置正好在下拉的列表区域里，而不是在主控件的文本框区域。理解了这一层，才能解释为什么用OwnerDrawFixed + DrawItem这个组合，而不是去重写OnPaint。

ItemHeight在这里是不能省的参数。它决定了两件事：第一，每一行的Bounds.Height值，也就是绘制时的可用高度；第二，鼠标点击时把ViewPoint坐标换算成行号的基准，这个换算规则在后面命中测试的代码里会直接用到。ItemHeight设置太小，CheckBox画不下；设置太大，下拉的总高度会不成比例地膨胀。

2.2 三条实现路线的取舍：OwnerDraw自绘、CheckedListBox托管、商业库兜底

动手之前我对比过三条路线，各自代价差别不小。

第一条路线是拿CheckedListBox直接当面板。CheckedListBox自带CheckBox绘制、ItemCheck事件，看起来什么都现成，但它是普通列表，不是下拉。要模拟下拉弹出效果，得把CheckedListBox放进一个浮动Panel里，自己控制窗口位置、失去焦点关闭、层级置顶。做出来的交互和原生ComboBox差很多：点击列表项后CheckedListBox的ItemCheck只改变勾选，不会自动收起面板，你还要额外监听一个悬停时间或LostFocus事件来关掉它，多显示器时面板位置还容易跑到副屏外面。老代码里替换成这个控件时还要额外改事件，工作量并不小。

第二条路线是继承ComboBox，用OwnerDrawFixed自绘。这条路线能完整保留原生下拉的展开、收起、键盘导航、滚动条行为，因为我们没有动ComboBox的窗口逻辑，只是在绘制层插入了一个CheckBox，并靠命中测试区分用户点击的是CheckBox区域还是文本区域。对外暴露的接口和原生ComboBox一致，代码替换成本最低，但勾选状态的管理需要自己写，不能像CheckedListBox那样直接订阅ItemCheck。

第三条路线是引入商业库，比如DevExpress的CheckedComboBoxEdit。功能齐全，还有样式、搜索这些额外能力，但对一个进销存维护型的项目来说，为了一个下拉控件引一套UI库授权，成本和风险都偏高。除非项目里已经用了这套商业库，否则不建议为了单个控件去引入。

三条路线对比下来，我选了OwnerDraw自绘。核心原因只有一条：它复用了原生ComboBox的下拉窗口逻辑，我们只补绘制和点击两个缺口，其他行为全部免费继承。下面是三条路线的对比：

后面的第三、四章，我按这条OwnerDraw自绘路线把实现拆开讲。

3. 核心实现：重写OnDropDown与DrawItem，把CheckBox画进下拉列表

3.1 继承ComboBox的最小骨架：DrawMode与ItemHeight先行

先上一个最小的可编译骨架。这一小步的目的不是画CheckBox，而是把ComboBox所处的状态调到“自绘模式”，并确认每一行的高度。

using System; using System.Collections.Generic; using System.Drawing; using System.Windows.Forms; public class CheckBoxComboBox : ComboBox { private List<int> _checkedIndexes = new List<int>(); private bool _isClickOnCheckBox; public CheckBoxComboBox() { DrawMode = DrawMode.OwnerDrawFixed; DropDownStyle = ComboBoxStyle.DropDownList; ItemHeight = 24; } protected override void OnDrawItem(DrawItemEventArgs e) { base.OnDrawItem(e); } }

逻辑说明：DrawMode设置为OwnerDrawFixed后，内部ListBox就进入固定行高自绘状态，每一行的绘制都会触发OnDrawItem。DropDownStyle设为DropDownList是为了禁止用户直接编辑文本框，因为自绘状态下编辑框的文本和勾选状态是两套数据，混在一起会互相干扰。ItemHeight是每一行的高度基准，24可以理解为16像素的CheckBox加上下各4像素间距的结果。

这个骨架类已经能替代原生ComboBox使用，只是绘制出来的下拉列表和默认样式没有差别。接下来要做的，就是在OnDrawItem里把CheckBox画上去。

3.2 DrawItem里画CheckBox：勾选状态与文本绘制的细节

下面的代码把每一行画成“CheckBox + 文本”的结构，勾选状态存在我自己的_checkedIndexes集合里。这样选中的行在下拉展开时就会带勾，折叠后重新打开也保持。

protected override void OnDrawItem(DrawItemEventArgs e) { if (e.Index < 0 || Items.Count == 0) { return; } e.DrawBackground(); bool isChecked = _checkedIndexes.Contains(e.Index); Rectangle checkRect = new Rectangle( 2, e.Bounds.Top + (e.Bounds.Height - 16) / 2, 16, 16); CheckBoxRenderer.DrawCheckBox( e.Graphics, checkRect, isChecked ? CheckBoxState.CheckedNormal : CheckBoxState.UncheckedNormal); Rectangle textRect = new Rectangle( checkRect.Right + 6, e.Bounds.Top, e.Bounds.Width - checkRect.Width - 12, e.Bounds.Height); TextRenderer.DrawText( e.Graphics, GetItemText(Items[e.Index]), e.Font, textRect, e.ForeColor, TextFormatFlags.Left | TextFormatFlags.VerticalCenter); if ((e.State & DrawItemState.Selected) == DrawItemState.Selected) { e.DrawFocusRectangle(); } }

逻辑说明：e.DrawBackground()先把系统默认的行背景画出来，避免出现透明底或重影。checkRect的左边距离边界2像素，垂直方向用(e.Bounds.Height - 16) / 2把16像素的CheckBox在行内垂直居中。CheckBoxRenderer.DrawCheckBox是System.Windows.Forms里的静态方法，会按照当前Windows主题绘制标准的勾选框，比自己画矩形好看，也省去了处理主题差异的麻烦。

文本区域从CheckBox右侧偏移6像素开始，右边界留12像素空隙，防止长文本贴边被截断。GetItemText(Items[e.Index])是关键，它不管Items里存的是字符串还是对象，都能取到该行要显示的文本；如果直接ToString，遇到DataSource绑定的自定义对象时很容易拿到全类名。

参数说明：16像素是CheckBoxRenderer使用的标准尺寸，ItemHeight设为24时这个值是比较舒服的。如果把ItemHeight降到18，CheckBox仍然画得下，但行内只剩下1像素的上下空隙，点击时很容易误触相邻行。

这里再补一个细节：很多人会顺手在DrawItem里写GetItemText(Items[e.Index])和GetItemText(Items[e.Index])两次，其实没有必要，GetItemText本身做了DisplayMember解析，对它来说Text属性优先。还有一点，如果列表项是空字符串，CheckBox会画出来但文本区域是空的，视觉上像缺了一列，建议绑定前过滤掉空白项。

3.3 鼠标命中测试：点CheckBox区域才切换，点文本区不误触

绘制解决的是“看起来有CheckBox”，但用户点击CheckBox那一块的时候，ComboBox默认会把这一行当成普通选择项，触发SelectedIndexChanged。我们要做的是把点击区分成两种情况：点中CheckBox区域就切换勾选状态，点中文本区域则保持原生选中行为。

protected override void WndProc(ref Message m) { if (m.Msg == 0x0201) // WM_LBUTTONDOWN { Point clickPoint = PointToClient(Cursor.Position); int index = IndexFromPoint(clickPoint); if (index >= 0) { Rectangle checkRect = new Rectangle( 2, index * ItemHeight + (ItemHeight - 16) / 2, 16, 16); if (checkRect.Contains(clickPoint)) { _isClickOnCheckBox = true; } } } base.WndProc(ref m); } protected override void OnSelectedIndexChanged(EventArgs e) { if (_isClickOnCheckBox) { int index = SelectedIndex; if (_checkedIndexes.Contains(index)) { _checkedIndexes.Remove(index); } else { _checkedIndexes.Add(index); } Invalidate(); _isClickOnCheckBox = false; } base.OnSelectedIndexChanged(e); }

逻辑说明：WndProc拦截WM_LBUTTONDOWN消息（0x0201），此时用户刚按下鼠标左键，下拉列表还处于打开状态。先拿鼠标位置和IndexFromPoint算出点击的行号，再构造和绘制时一致的checkRect做命中判断。注意这里Y坐标用的是index * ItemHeight，而不是某个bound的值，因为WndProc里拿不到当前行的DrawItemEventArgs，但这个公式和绘制时e.Bounds.Top是同一个坐标体系。

如果命中CheckBox区域，就把_isClickOnCheckBox置true，然后继续走base.WndProc让ComboBox完成原生行为，包括将这一行设为SelectedIndex。OnSelectedIndexChanged随后触发，这时候看到_isClickOnCheckBox为true，就只切换勾选状态、刷新绘制，不执行任何选中操作。如果用户点的是文本区域，_isClickOnCheckBox保持false，OnSelectedIndexChanged里不进入if分支，行为就和普通ComboBox完全一致。

参数说明：WM_LBUTTONDOWN硬编码0x0201是C# WinForms里常见的做法，Win32消息常量不随系统版本变化，可以放心用。IndexFromPoint返回的是当前可视范围内鼠标位置对应的行索引，已经处理了滚动偏移，比自己用Point.Y除以ItemHeight再减滚动条位置可靠得多。

这里还有一个必须补的开关。下拉列表默认高度在106像素左右，自绘模式下如果项比较多，列表高度不够，CheckBox会被滚动条压住。我一般在OnDropDown里把高度撑开：

protected override void OnDropDown(EventArgs e) { base.OnDropDown(e); DropDownHeight = Math.Max(Items.Count, 1) * ItemHeight + 8; }

逻辑说明：Items.Count乘以ItemHeight得到所有项平铺的总高度，加8是给下拉边框留的余量。DropDownHeight如果设为0，ComboBox会自己按项数计算，但那个上限约是屏幕高度的1/3，行为不够可控，我在需要固定交互的项目里都用这个公式。

4. 数据源绑定与选中项取值：让“指定项勾选”直接可用

4.1 包装类给每个列表项加Checked属性，DataTable别拿来直接用

用List 或DataTable直接当DataSource，会发现一个尴尬的问题：勾选状态没有地方存。字符串项就是一个文本，DataRow里也没有天然的三态列，强行加一列数据又污染了业务表。我给列表项做了一个包装类，把这些运行时状态独立出来：

public class CheckComboItem { public string Text { get; set; } public object Tag { get; set; } public bool Checked { get; set; } public override string ToString() { return Text ?? string.Empty; } }

逻辑说明：Text是显示给用户看的文本，Tag是背后对应的业务主键，Checked是勾选状态。ToString重写为返回Text，是因为ComboBox在未设置DisplayMember时，显示列表项文本用的就是ToString；包装类重写ToString后，DrawItem里的GetItemText也能稳定拿到文本。DataSource绑定方式如下：

List<CheckComboItem> source = new List<CheckComboItem> { new CheckComboItem { Text = "生产物料", Tag = "MAT-001" }, new CheckComboItem { Text = "办公用品", Tag = "MAT-002" }, new CheckComboItem { Text = "外协加工", Tag = "MAT-003" }, }; checkBoxCombo.DataSource = source; checkBoxCombo.DisplayMember = "Text";

逻辑说明：这里把List 直接赋给DataSource后，Items里的每个元素就是CheckComboItem实例。DisplayMember设为Text，ComboBox在显示和取值时都会优先用这个属性名。绑定和绘制是天然解耦的——DrawItem只负责画CheckBox和文本，勾选状态从CheckComboItem.Checked读，而不依赖DataSource的列结构。

4.2 GetCheckedItems与SetCheckedItems：读取和回显的一对接口

读取选中项是个很常见但又容易被做错的需求。原生ComboBox下只有一个SelectedIndex，自绘多选模式下，SelectedIndex记录的是最后点击的那一行，根本不能代表“用户勾选了哪些”。所以必须用下面这个方法：

public List<CheckComboItem> GetCheckedItems() { List<CheckComboItem> result = new List<CheckComboItem>(); foreach (object item in Items) { if (item is CheckComboItem checkItem && checkItem.Checked) { result.Add(checkItem); } } return result; }

逻辑说明：遍历的是Items集合不是DataSource，是因为ComboBox内部Items始终是数据源的映射，遍历Items拿到的每个元素就是当初绑定的CheckComboItem。过滤条件只看Checked属性，所以勾选顺序、点击先后都不会影响结果顺序。

对应的回填方法是C#里给ComboBox指定项默认勾选的核心入口。业务上经常是“默认勾选A和B”，或者编辑单据时要回显之前保存的选择，这个方法就是为这个场景写的：

public void SetCheckedItems(params object[] tags) { foreach (object item in Items) { if (item is CheckComboItem checkItem) { checkItem.Checked = tags != null && Array.Exists(tags, tag => tag.Equals(checkItem.Tag)); } } Invalidate(); UpdateTextDisplay(); }

逻辑说明：SetCheckedItems接收的是Tag数组而不是文本数组，这是有意的。在生产环境里，后端返回的往往是物料编号这类业务主键，文本可能重复，Tag才是唯一的。Array.Exists遍历传入的tags，只要当前项的Tag被包含，就把Checked置true。Invalidate强制在下拉未展开的情况下也刷新控件外观，UpdateTextDisplay刷新主显示区的文本。

这里要提一个C# ComboBox指定项相关的细节：如果列表项没有Tag，只有Text，那调用SetCheckedItems时可以直接传Text，但前提是Text保证唯一。我在实际项目里都是让固资编码、物料编号这类字段做Tag，因为多选框就是为了解决多个值的问题，重名非常常见。

4.3 DropDownClosed里刷新文本：选中项拼成字符串的规则

勾选完之后，用户要看到主文本框里显示的是什么。如果是单选ComboBox，SelectedIndexChanged就是最终结果；但多选自绘下，勾选过程中SelectedIndexChanged会触发好几次，每次更新Text都会闪。正确的时机是下拉列表关闭之后。

private void UpdateTextDisplay() { List<string> selectedTexts = GetCheckedItems() .Select(item => item.Text) .ToList(); if (selectedTexts.Count == 0) { Text = "请选择"; } else if (selectedTexts.Count <= 3) { Text = string.Join("、", selectedTexts); } else { Text = string.Format("已选择 {0} 项", selectedTexts.Count); } } protected override void OnDropDownClosed(EventArgs e) { base.OnDropDownClosed(e); UpdateTextDisplay(); }

逻辑说明：OnDropDownClosed在下拉区域收起时触发，这时用户已经完成一次勾选交互。GetCheckedItems先拿到所有勾选项，再投影出Text列表。条数在1到3时直接拼接全部文本，超过3条时显示汇总数量，这个规则适合筛选项比较多的场景，不至于把主显示区撑成一长串文本。

参数说明：3不是固定值，项目里下拉项文本短时我会放宽到4，文本长时降到2，看界面效果调。另外SetCheckedItems里也要调用UpdateTextDisplay，否则程序里回填勾选状态后，文本框还是空的，一定要同时刷新。

现在控件已经可以正常使用了。如果你是在外部代码里订阅DropDownClosed而不是重写OnDropDownClosed，记得把UpdateTextDisplay这个private方法换成public，否则订阅不到。

5. 避坑指南：自绘下拉常见的五个翻车现场

5.1 下拉列表只露出一行：DropDownHeight没接管

现象：绑定数据源后，点击下拉箭头，列表只显示一行，剩下全是滚动条，CheckBox和文本都挤在一个狭小的窗口里。

原因：ComboBox默认DropDownHeight在106像素左右，OwnerDrawFixed把每行高度提到24后，可视行数只剩4行左右。系统并不会因为行高变大自动撑开列表。

解决：在OnDropDown里用DropDownHeight = Math.Max(Items.Count, 1) * ItemHeight + 8撑开，或者直接把DropDownHeight设为0，让WinForms按项数自动计算。我一般用前一种写法，因为自动计算的高度上限在不同屏幕分辨率下表现不一致，手动公式更可控。

5.2 CheckBox画出来是歪的：ItemHeight与字体间距失配

现象：下拉列表每行都能看到一个CheckBox，但勾选框和文字不在一条垂直中心线上，有的项文字被上下截断，字稍微大一点就顶到行边缘。

原因：CheckBox用的是16像素固定尺寸，checkRect的垂直居中依赖(e.Bounds.Height - 16) / 2，如果ItemHeight小于16，这个值变成负数，CheckBox就会顶到行上边缘；如果ItemHeight过大，行之间空隙太大，看起来像隔行。

解决：ItemHeight用Font.Height + 6这条经验公式来调。Font.Height是当前字体实际测量出的行高，加上6像素让CheckBox上下各有3像素余量。直接用固定24的前提是字体是常规的9号宋体或微软雅黑，遇到大字号一定要重新设置ItemHeight。

5.3 点击复选框却选中了整行：WndProc里的坐标没换算

现象：明明点到的是CheckBox，勾选状态也切换了，但那一行同时被高亮选中，点击空白处还会误触相邻行的勾选。

原因：WndProc拿到的Cursor.Position是屏幕坐标，PointToClient转换后才是控件客户区坐标。如果直接用屏幕坐标传给IndexFromPoint，坐标差一个控件左上角的位置，按到的行号就错位了。另外checkRect的Y坐标用(index * ItemHeight + (ItemHeight - 16) / 2)，这里的index必须是IndexFromPoint返回的可视行索引，不能用SelectedIndex。

解决：统一用PointToClient(Cursor.Position)取客户区坐标，再进入IndexFromPoint换算行号。这个错误在我第一次实现的时候出现过，症状就是“点第三行却改了第四行的勾”，血泪经验。从那以后WndProc里的坐标换算我都强制写到一个常量方法里，不允许散落多处。

5.4 重新绑定后勾选全丢：Checked属性被重建

现象：程序里重新设置DataSource后，之前勾选的项全部变回未勾选，看起来就像控件失忆了。

原因：重新赋值DataSource会触发ComboBox重建Items集合，每个CheckComboItem都是一次new出来的新实例，之前的Checked属性自然全部是默认值false。即使传入的是同一个List对象，内部刷新机制也不会保留实例状态。

解决：在重新绑定前把选中的Tag存下来，绑定完成后用SetCheckedItems回填：

object[] selectedTags = checkBoxCombo.GetCheckedItems() .Select(item => item.Tag) .ToArray(); checkBoxCombo.DataSource = newItems; checkBoxCombo.SetCheckedItems(selectedTags);

逻辑说明：这里保存的是Tag而不是对象引用，因为新数据源里的对象是全新实例，旧的引用拿过去也没用。Tag通常是业务主键，能在新数据源里稳定匹配。这三行代码的顺序不能乱，先取状态，再绑数据，最后回填。

5.5 关闭下拉列表后文本没变化：SelectedIndexChanged覆盖不了Dropdown关闭

现象：勾选了好几个项，下拉列表收起来后，主文本框还是显示原来的值，或者只显示最后点击的那一项文本。

原因：SelectedIndexChanged在多选自绘下代表的是“当前选中行发生了变化”，它会在下拉展开期间多次触发。如果在这个事件里刷新Text，每点一下CheckBox都改一次主文本，而且最后一次点击的那一行会覆盖掉前面的结果，看起来就像只选了一个。

解决：把文本刷新放到OnDropDownClosed里。这个是很多人忽略的细节，原生单选的ComboBox不需要处理DropDownClosed，但多选下拉必须靠这个事件收口。我在4.3已经把这个逻辑放在OnDropDownClosed里了，如果你继承的是外部封装类而不是直接改源码，记得把UpdateTextDisplay订阅到DropDownClosed事件上。

6. 进阶：一个ToggleAll方法加一组验证步骤，把勾选逻辑钉死

6.1 把全选/反选封装成SetAll

工具型下拉控件基本都会遇到“全选”“清空”两个按钮，封装一个方法比在调用方写foreach干净得多：

public void SetAll(bool check) { foreach (object item in Items) { if (item is CheckComboItem checkItem) { checkItem.Checked = check; } } Invalidate(); UpdateTextDisplay(); }

逻辑说明：SetAll(true)把所有CheckComboItem的Checked置true，SetAll(false)全部清空。这个方法直接复用GetCheckedItems和UpdateTextDisplay，不需要额外维护一个全选标记。页面上的“全选/清空”按钮，一行代码就能接到这个方法。

6.2 三分钟验证清单

每次改动完控件，我会按下面这份清单跑一遍，能覆盖掉大部分自绘控件的隐藏问题：

1. 绑定8条以上的数据，展开下拉，确认所有项都显示完整，没有滚动条压住CheckBox的情况。
2. 点击第二、第四行的CheckBox区域，确认勾选状态切换正常，文本区域不误触。
3. 点击某一行文本区域，确认只高亮不勾选，和原生ComboBox行为一致。
4. 折叠后重新展开，确认勾选状态还在，没有闪回。
5. 调用SetCheckedItems回填指定项，确认勾选和主文本同步更新。
6. 点击“全选”按钮，确认所有项勾选且文本变为“已选择 N 项”。

这套验证步骤里，第2和第3步最容易暴露坐标换算问题，第4步最容易暴露状态存储问题。我在自动化回归里会额外用SendMessage模拟WM_LBUTTONDOWN，走的是和手工点击同一条WndProc路径，能验证命中测试的改动有没有引入新的边界问题。

这个控件我现在还在用，每次新建WinForms窗体需要多选下拉时，直接把它拖进去绑定数据源就行。从那次进销存项目之后，我做自绘下拉都会先把DropDownHeight、ItemHeight、WndProc坐标换算这三件套列出来，再写业务逻辑，这习惯帮我少翻了好几次车。希望帮到你。

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