微信生态内的H5页面常常需要与地图能力结合，比如展示配送范围、规划路径、标记热区等等。开发者很快就发现微信map组件能展示地图，却很难做到在地图上自由绘制多边形、折线、圆这些矢量图形。本文将围绕这个问题展开，先剖析map组件自带的局限性，然后给出基于Canvas的覆盖层方案，结合代码一步步说明坐标换算、绘制和交互的完整链路。
理解map组件的局限与自定义图层的思路
微信小程序的map组件能力并不弱，支持标记点、路线规划、热力图等丰富功能，但它的一个天然短板是：组件原生渲染层级非常高，普通view元素无法覆盖在其上方。尝试用position:fixed或z-index强行盖在地图上，兼容性极差，特别是在iOS的WebView环境中会出现各种奇怪的层级表现。若是想在H5里通过JS-SDK调用地图SDK，也存在同样的覆盖层问题，因为地图本身是一个Native组件。
既然普通DOM元素盖不上去，就得另辟蹊径。目前业界比较成熟的方案是使用Canvas作为地图的兄弟节点，也就是把Canvas定位到地图正上方，实时同步地图的经纬度范围和画布尺寸，再在Canvas中完成矢量图形的绘制。开发者只需要维护一份经纬度坐标数组，在每次地图视野变化时重新做投影换算，就能保证图形跟着地图移动、缩放，看起来就像绘制在真实地图上的图层。
这个方案的另一个优势是性能可控。地图瓦片渲染由SDK本身负责，Canvas只负责绘制矢量图形，两者天然分层。多边形、折线、圆这些图形在Canvas中的绘制成本极低，即使同时渲染几百个锚点也不会造成明显卡顿。整体架构上，需要三层结构配合：map组件负责展示底图，Canvas负责矢量图形覆盖，JavaScript逻辑层负责坐标换算和交互事件绑定。
经纬度与屏幕坐标的换算原理
在绘制任何矢量图形之前，必须先解决一个核心数学问题：如何把经纬度坐标换算成Canvas上的像素坐标。地图引擎在展示时，内部会维护一个视野中心点和缩放级别。对于开发者来说，最简单的方式是通过SDK暴露的API直接取到经纬度对应的投影坐标。微信map组件提供getRegion和getScale接口，一个返回当前可见区域的东北、西南角经纬度，一个返回缩放级别，这两个值配合Canvas的宽高，就能完成一次线性换算。
假设东北角经纬度为（neLat, neLng），西南角经纬度为（swLat, swLng），Canvas显示区域宽为width、高为height。任意一点经纬度（lat, lng）对应的Canvas像素坐标（x, y）可以这样计算：x = (lng - swLng) / (neLng - swLng) * width，y = (neLat - lat) / (neLat - swLat) * height。这里需要注意纬度方向是反向的，因为屏幕坐标系Y轴向下，而纬度向上递增。
这种换算方式在处理跨越大范围区域的图形时会暴露出精度问题。因为经纬度是球面坐标，直接线性映射到平面必然产生形变。不过在微信公众号H5的使用场景下，绘制的基本都是配送范围、园区边界这类小范围区域，线性误差可以忽略不计。如果确实需要高精度投影，可以引入Web Mercator投影公式，将经纬度先在投影平面上换算，再做线性映射。下面给出一个Web Mercator的坐标换算示例，可以直接在项目中使用：
// 经纬度转Web Mercator投影坐标
function lonLatToMercator(lon, lat) {
var earthRadius = 6378137;
var x = lon * Math.PI / 180 * earthRadius;
var y = Math.log(Math.tan((90 + lat) * Math.PI / 360)) * earthRadius;
return { x: x, y: y };
}
// 通过投影坐标反推屏幕坐标
function mercatorToPixel(mercatorPoint, mapBounds, canvasSize) {
var xRatio = (mercatorPoint.x - mapBounds.minX) / (mapBounds.maxX - mapBounds.minX);
var yRatio = (mapBounds.maxY - mercatorPoint.y) / (mapBounds.maxY - mapBounds.minY);
return {
x: xRatio * canvasSize.width,
y: yRatio * canvasSize.height
};
}
实际开发中使用getRegion返回的东北角和西南角坐标，转换为Mercator投影后得到地图可视区域的minX、minY、maxX、maxY。这个投影方法比直接用经纬度线性映射精准得多，也多花不了几行代码，建议作为基础工具沉淀在项目里，方便日后复用。
Canvas覆盖层绘制多边形、折线与圆
坐标换算逻辑准备完毕，接下来的重点就是绘制。先把Canvas定位到map组件覆盖的区域，这一步通常用一个绝对定位的容器封装map和Canvas，保证两个元素在同一个布局上下文里，尺寸完全一致。需要注意Canvas需要设置固定的width和height属性，同时用CSS把Canvas的尺寸锁定在容器尺寸上，避免高分屏下Canvas被拉伸模糊。
多边形的绘制核心是路径拼接。把多边形的顶点坐标数组依次用lineTo连接，最后闭合路径，再填充颜色。折线的绘制类似，区别在于不需要闭合。圆的绘制则更简单，圆心坐标通过经纬度换算得到，半径要处理成像素距离。这里有一个常用技巧：在地图上取圆心附近的一点，计算该点到圆心的经纬度差，再换算成像素距离作为半径，而不是直接把圆的物理半径当像素用。示例代码如下：
function drawPolygon(ctx, points) {
ctx.beginPath();
ctx.moveTo(points[0].x, points[0].y);
for (var i = 1; i < points.length; i++) {
ctx.lineTo(points[i].x, points[i].y);
}
ctx.closePath();
ctx.fillStyle = 'rgba(64, 158, 255, 0.3)';
ctx.strokeStyle = '#409EFF';
ctx.lineWidth = 2;
ctx.fill();
ctx.stroke();
}
function drawPolyline(ctx, points) {
ctx.beginPath();
ctx.moveTo(points[0].x, points[0].y);
for (var i = 1; i < points.length; i++) {
ctx.lineTo(points[i].x, points[i].y);
}
ctx.strokeStyle = '#ff6b6b';
ctx.lineWidth = 4;
ctx.lineCap = 'round';
ctx.lineJoin = 'round';
ctx.stroke();
}
function drawCircle(ctx, center, pixelRadius) {
ctx.beginPath();
ctx.arc(center.x, center.y, pixelRadius, 0, Math.PI * 2);
ctx.fillStyle = 'rgba(255, 165, 0, 0.2)';
ctx.strokeStyle = '#ff8c00';
ctx.lineWidth = 2;
ctx.fill();
ctx.stroke();
}
绘制本身不复杂，真正的挑战在于每次地图视野变化时同步重绘。map组件提供了bindregionchange事件，在视野开始变化和结束变化时都会触发，事件回调里通过type字段区分。通常在视野变化结束后触发一次redraw方法，重新读取region和scale，换算所有图形坐标，然后清空Canvas画布并逐一绘制。整个流程看起来简单，但要注意避免在视野拖拽过程中频繁重绘，否则会造成视觉抖动。
除了基本的形状绘制，还可以把文本标注、光晕点、渐变圆环都集成到同一个Canvas绘制管线中。文本使用ctx.font和ctx.fillText即可，配合基础图形可以做出非常丰富的地图可视化效果。值得注意的是，Canvas绘制的文字会随着地图缩放而大小不变，这与地图引擎中的marker自动缩放行为不同，需要在实际项目中根据需求自行取舍。
事件交互与命中检测的实践方案
覆盖层绘制完成只是第一步，实际项目中往往需要用户点击某个多边形查看详情，或者拖拽圆形调整范围。由于Canvas是一整块画布，无法像DOM元素那样直接绑定点击事件，必须自己实现命中检测。命中检测的基本思路是：监听Canvas的tap或touch事件，取到触摸点坐标，然后遍历所有图形元素，判断该点是否在图形内部。
对于圆形，命中检测十分简单。计算触摸点与圆心之间的像素距离，若小于半径则判定为命中。对于多边形，需要用到射线法：从触摸点向任意方向画一条射线，统计射线与多边形各边的交点个数，交点个数为奇数则点在多边形内部，为偶数则在外部。这个算法在各种图形学库中都有成熟实现，二三十行代码就能写出来。折线的命中检测则比较特殊，需要计算点到各线段的距离，若距离小于一定阈值（比如6像素）即判定为命中。
处理完命中检测后，还需要解决点击穿透问题。正常情况下，用户点击地图本应触发地图的交互，但由于Canvas盖在上面，触摸事件会被Canvas拦截。解决方案是：绘制层默认设置pointer-events: none，让所有触摸事件穿透到地图组件；当Canvas上存在可交互图形时，再动态恢复pointer-events: auto，此时点击事件由Canvas处理，命中检测后通过回调函数通知业务层。这套方案既保证了图形区域的正常交互，又避免了非图形区域阻碍地图手势操作。
项目实践中的高频踩坑与优化建议
谈到真实的项目落地，有几个坑比较常见。第一个是Canvas尺寸和地图组件尺寸不一致导致的偏移。在iPhone X这类带安全区域的设备上，地图若使用了bottom安全距离，而Canvas没有同步边距，两者就会出现错位。遇到这种情况，最好的解决方案是统一使用一个包装容器，让Map和Canvas都填充整个容器，由容器统一处理安全区域边距，规避内部两颗组件之间的同步问题。
第二个坑是图形在连续缩放时出现残影。这通常是Canvas重绘逻辑没做好，没有在每次绘制前清屏。正确的顺序是：先调用ctx.clearRect清空整个Canvas矩形区域，再执行图形绘制，最后再调用ctx.draw()方法把缓冲区的图形真正渲染到画布上。如果使用了离屏Canvas做缓存，务必在视野变化结束后清理缓存Canvas，否则缓存中的旧坐标会让图形在缩放途中跑到错误位置。
第三个坑集中在性能和内存方面。在低端Android机上，每次视野变化都全量重绘所有图形会带来卡顿。优化方案是引入可视区域裁剪：只绘制与当前视野区域相交的图形，完全在视野之外的图形直接跳过。对于包含几百个点的复杂多边形，还可以使用LOD策略，在低缩放级别时简化顶点的数量。同时，Canvas实例需要注意复用，避免每次重绘都重新创建Canvas对象导致内存泄漏。如果配合requestAnimationFrame做批量更新，能让重绘过程更加顺滑。
从实际的工程角度看，这套自定义图层方案还有不少扩展空间，比如将图形的绘制逻辑封装成独立的绘制引擎，把客户数据和绘制管线拆分，让业务层只需要维护数据源就能驱动视图更新。无论项目体量大小，保持清晰的分层逻辑，始终是这类定制化地图功能稳定运行的保障。衷心希望本文的讲解能帮读者少走一些弯路，更快地完成微信H5地图坐标系上的这张自定义画布。