企业官网建设流程全解析

小程序地图开发里，marker 图标适配是个看着简单、一深挖全是活儿的问题。前阵子做一款带地图展示的小程序，上线后客户反馈说 iPhone 上图标大小刚好，换到安卓大屏手机上就明显偏小，还有人开了分屏模式后图标被拉伸得没法看。排查到最后发现，问题出在 marker 的 width 和 height 被我写成了固定数值。这个错误本身很低级，但为了彻底解决它，我把微信小程序的屏幕适配机制、marker 渲染逻辑、图片加载链路整个捋了一遍，也踩了不少真机上的坑。这篇文章就围绕"根据缩放屏幕大小自适应 icon 并更新 marker"这件事，把我验证过的完整方案和代码直接分享出来，希望能帮到遇到同样问题的人。

1. 先弄明白 marker 的尺寸为什么会在不同屏幕上"走样"

1.1 微信小程序的 rpx 换算逻辑，和你以为的可能不一样

微信小程序里，rpx 是一个"响应式像素"单位，官方规定所有设计稿都按宽度 750rpx 来做。具体换算方式是：1rpx 等于屏幕逻辑宽度除以 750。比如 iPhone SE 的逻辑宽度是 375px，那 1rpx 就等于 0.5px；iPhone 15 Pro Max 的逻辑宽度是 430px，1rpx 就等于 430 除以 750，约等于 0.573px。

这个机制保证了同一个 rpx 数值在不同宽度的设备上，视觉效果是"等比缩放"的。比如一个宽度为 60rpx 的按钮，在 iPhone SE 上是 30px 宽，在 iPhone 15 Pro Max 上是 34.4px 宽——视觉占比一致，不会出现小屏上显得特别大、大屏上显得特别小的问题。

这个逻辑本身没毛病，但问题恰恰出在"我们以为 marker 的 width 和 height 也支持 rpx"上。

1.2 marker 的 width 和 height 只认 px，不认 rpx

微信小程序 map 组件里的 markers 数组，每一项的 width 和 height 字段，官方文档写得很清楚：number 类型，单位是 px。也就是说，你在这里写 60rpx 不会生效，写 60 就是 60px。

这就有意思了。布局层的 rpx 会自动等比缩放，但 marker 的尺寸不会。如果你在图标的宽高里直接写死 60，那么它在 iPhone SE 上看起来跟设计稿差不多，但在 iPhone 15 Pro Max 上就会显得偏小；反过来，如果你在 iPhone 15 Pro Max 上调试觉得 40px 刚好，那到小屏设备上又偏大了。

我在实际项目里第一次踩到这个坑时，真机上的表现是：同一张地图，左侧 marker 和右侧 marker 倒是统一，但总觉得比例失调。后来用开发者工具的"切换设备"功能一比，发现同样一个 icon，在 iPhone 5 上几乎占了大半屏，在 iPad 上小到几乎看不见。

所以结论很简单：marker 的尺寸必须动态计算，不能直接写死。要让它跟随屏幕宽度等比变化，就得把设计稿里的 rpx 换算成当前设备对应的 px，再去设置宽高。

1.3 用户说的"缩放屏幕"，其实包含两种完全不同的场景

跟产品聊完需求后我发现，客户口中的"自适应缩放"其实包含了两种场景，处理方式完全不同：

第一种是"窗口尺寸变化"。包括不同设备宽度差异、用户开启分屏、iPad 上调节窗口比例、安卓折叠屏展开/折叠等情况。这种场景下，窗口的逻辑宽度变化了，rpx 基准、页面布局都会跟着变，marker 图标尺寸理论上也应该跟着变，否则视觉比例会失调。

第二种是"地图缩放级别变化"。也就是用户双指缩放地图，或者点击地图上的放大缩小按钮。这种情况下，marker 是锚定在经纬度上的元素，地图缩放时 marker 默认不会跟着变大变小，因为 marker 的宽高是固定的 px 值。

这两种场景的目标不同：窗口变化时，我们希望 marker 保持相对页面的等比尺寸；地图缩放时，我们可能需要 marker 保持绝对大小（大部分场景），也可能希望它随地图比例一起变化（比如做聚合地图、区域热力图）。我在后文会分别给出实现方案。

2. 从"设计稿宽度"出发的换算工具，是整件事的地基

2.1 手写一个 getAdaptiveSize 换算函数

既然设计稿按 750rpx 宽度来，而 marker 的宽高只接受 px，那换算公式其实很直接：

/** * 将设计稿中的 rpx 尺寸换算为当前设备对应的 px 尺寸 * @param {number} rpxSize 设计稿中的尺寸，单位 rpx * @returns {number} 当前设备对应的 px 尺寸 */ function getAdaptiveSize(rpxSize) { let windowWidth = 375; // 兜底值 try { const info = wx.getWindowInfo ? wx.getWindowInfo() : wx.getSystemInfoSync(); windowWidth = info.windowWidth; } catch (e) { console.warn('获取窗口信息失败，使用默认宽度 375'); } const ratio = windowWidth / 750; return Number((rpxSize * ratio).toFixed(2)); }

这里有几个细节值得说一下。为什么保留两位小数？因为地图组件在部分安卓机型上如果传入的小数位数过多，可能出现图标渲染偏移或模糊的问题，保留两位足够精确又不会引发额外渲染问题。

为什么用wx.getWindowInfo而不是wx.getSystemInfoSync？因为从基础库 2.20.1 开始，微信官方推荐使用wx.getWindowInfo来获取窗口信息，它更轻量，且返回的windowWidth就是逻辑像素（CSS 像素），跟设计稿换算的语义完全一致。不过在低版本基础库上它可能不存在，所以代码里做了兼容判断，回退到wx.getSystemInfoSync。

2.2 把换算函数抽成公共工具模块

实际项目中，我不建议在页面里内联这段逻辑。小程序页面多了之后，每个页面都要换算，抽成公共模块是更合理的选择。我习惯在 utils 目录下建一个adaptive.js：

// utils/adaptive.js const DESIGN_WIDTH = 750; // 设计稿总宽度 function getWindowWidth() { try { const info = wx.getWindowInfo ? wx.getWindowInfo() : wx.getSystemInfoSync(); return info.windowWidth; } catch (e) { return 375; } } export function getAdaptiveSize(rpxSize) { const windowWidth = getWindowWidth(); const ratio = windowWidth / DESIGN_WIDTH; return Number((rpxSize * ratio).toFixed(2)); } export function getAdaptiveRatio() { return getWindowWidth() / DESIGN_WIDTH; } export function getMarkerSize(rpxWidth, rpxHeight) { return { width: getAdaptiveSize(rpxWidth), height: getAdaptiveSize(rpxHeight || rpxWidth), }; }

getMarkerSize是我后加的。因为大多数 marker 图标是等宽高的正方形，传一个 rpx 值就能同时得到宽和高。如果图标不是正方形，再单独传高度参数。这样在页面里调用起来特别简洁。

2.3 这套方案比"直接用 rpx"稳在哪里

有人可能会问：既然小程序内部 rpx 换算机制就是这样，为什么不在 icon 图片上用 rpx 单位？问题在于 map 组件的 marker 宽高字段不接受字符串形式的 rpx 单位，你传"60rpx"进去它不会识别。

比"写死 px"更进一步的问题是，有些开发者做了妥协，直接用计算好的固定数值（比如 30px），但这在窗口宽度变化时依然不会自适应。比如折叠屏展开、iPad 分屏，窗口宽度变大，图标比例就失调了。

我的方案核心思路是：marker 的尺寸永远由"当前窗口宽度 / 设计稿宽度"这个比例驱动。窗口宽度一变，尺寸就跟着变，和页面上用 rpx 的布局元素保持相同的缩放逻辑。这样不管在什么设备上，地图 icon 始终和页面整体设计保持一致。

3. 图标加载链路里那些不起眼却很致命的坑

尺寸计算解决了，icon 图片本身的加载还有不少坑。这些坑大多不会在模拟器里暴露，但真机上会把你折腾得够呛。

3.1 iconPath 路径的三种写法，只有两种靠谱

marker 的 iconPath 支持三种写法：

本地绝对路径：以/开头，比如/images/marker.png。这是最推荐的方式，路径从项目根目录出发，不管页面在哪个目录下都能正确找到。

本地相对路径：比如../../images/marker.png。这种写法在部分真机环境下容易出问题，因为小程序的相对路径是相对当前页面文件解析的，页面层级一变路径就失效。我不推荐在这种场景下用相对路径。

网络路径：比如https://yourcdn.com/marker.png。这种方式能用，但有额外的加载延迟和域名配置要求。

这里要注意，iconPath 报错时不会有明显的提示，marker 会直接显示成一个默认的红色图钉。如果你发现图标没显示出来但地图渲染正常，第一件事就是检查这个路径在当前环境能不能访问到。

3.2 图片尺寸和显示尺寸：清晰度的关键

marker 的 width 和 height 决定显示尺寸，但图片本身的像素尺寸决定了清晰度。如果你拿一张 60x60 的图片，放大到 120px 显示，在 Retina 屏幕上必然模糊，因为物理像素不够用。

我的经验是：图片像素尺寸至少是显示尺寸的 2 倍，最好能做到 3 倍。比如设计稿里图标是 60rpx，在 iPhone 15 Pro Max 上换算后大约显示 34px，那图片本身建议做 100px 左右。如果未来要兼容更高分辨率的安卓旗舰机，直接上 3 倍图（约 180px）也没问题。

另外图标格式强烈建议用 PNG 且带透明通道。JPG 不支持透明背景，就算你做了圆角标，边缘也会出现白底或黑底，在地图上特别突兀。

3.3 网络图标的加载策略和"闪红点"问题

使用网络图片作为 iconPath 时，map 组件是异步加载图片的。首次渲染时图片还没下载完成，组件会先显示默认的红图钉，图片加载完后再替换成你的自定义图标。在弱网环境下，这个"闪红点"的过程可能持续一两秒，体验很差。

如果项目对首屏展示要求高，建议把常用图标放到本地包里。小程序本地图片加载是同步的，不会出现闪烁。如果图标数量很大（比如每个门店一个自定义图），那就只能走网络路径，但可以在页面 onLoad 时先做一次预下载，把图片下载到本地临时目录，再在 marker 里引用临时文件路径。这样虽然不能完全消除首屏延迟，但至少能改善一部分体验。

需要特别提醒的是，网络图标必须在小程序后台配置 downloadFile 合法域名，否则真机上会加载失败。模拟器里不会校验域名，很多人因此没发现这个问题，一上真机就露馅。

4. 完整实战：页面初始化、屏幕变化监听、地图缩放联动

下面这一段是核心实现。我会按一个真实页面需要的顺序，把完整代码和关键设计思路过一遍。

4.1 定义 marker 的数据模型，给每个 marker 留好"基础尺寸"字段

实际项目中，marker 的初始定位数据（经纬度、id）和尺寸数据是两回事。我习惯在 data 里维护两类字段：baseMarkers存基础位置信息，markers存最终渲染到 map 组件上的数据。每个 baseMarker 里预留_baseWidth和_baseHeight，记录它在设计稿中的 rpx 尺寸。

Page({ data: { // 基础位置数据，不参杂任何尺寸计算 baseMarkers: [ { id: 1, latitude: 39.909, longitude: 116.397, _baseWidth: 60, // 设计稿中的 rpx 宽 _baseHeight: 60, // 设计稿中的 rpx 高 storeName: '东城店' }, { id: 2, latitude: 31.2304, longitude: 121.4737, _baseWidth: 60, _baseHeight: 60, storeName: '徐汇店' } ], markers: [], mapScale: 14 } })

为什么要在 baseMarkers 里存 rpx 尺寸而不直接存换算后的 px？因为窗口宽度变化后需要重新换算，如果只存换算结果，原始数据就丢了。这个设计一开始可能觉得多余，但在接屏幕变化监听后特别好用。

4.2 onLoad 初始化：计算尺寸并渲染第一批 marker

页面加载时，调用freshMarkers来完成第一次的尺寸换算和渲染。

const { getAdaptiveSize } = require('../../utils/adaptive'); Page({ // ... onLoad() { this.freshMarkers(); }, freshMarkers() { const markers = this.data.baseMarkers.map((item) => { const width = getAdaptiveSize(item._baseWidth); const height = getAdaptiveSize(item._baseHeight); return { ...item, width, height, anchor: { x: 0.5, y: 0.5 }, callout: { content: item.storeName, display: 'BYCLICK', fontSize: getAdaptiveSize(24), borderRadius: getAdaptiveSize(8), padding: getAdaptiveSize(8), bgColor: '#ffffff', color: '#333333' } }; }); this.setData({ markers }); } })

这里有几个关键点：

第一，anchor必须和尺寸一起设置。marker 的默认锚点是底边中点{ x: 0.5, y: 1 }，这意味着经纬度点会落在图标底部中间。如果你的图标是以中心对准某个位置点（比如门店坐标），不设置 anchor 就会偏。而且尺寸变化前后，如果 anchor 不一致，重新渲染时标记点会"跳一下"。

第二，callout 的fontSize、padding、borderRadius也是 px 单位，同样需要做自适应换算。很多人在自适应 marker 时只改了 width 和 height，弹窗还是旧尺寸，打开后显得特别突兀。

4.3 onResize 监听窗口尺寸变化：节流很重要

当用户开启分屏、旋转屏幕或者窗口尺寸变化时，页面会触发onResize生命周期。这是实现"自适应缩放屏幕后更新 marker"的核心入口。

Page({ // ... onResize(res) { if (!res || !res.size) return; const { windowWidth } = res.size; // 宽度变化小于 2px 时直接忽略，减少无效渲染 if (this._lastWindowWidth && Math.abs(this._lastWindowWidth - windowWidth) < 2) { return; } this._lastWindowWidth = windowWidth; this.freshMarkers(); } })

这里的节流逻辑值得解释一下。onResize 在某些安卓机型上会连续触发多次，如果不做限制，每次都会对 markers 做全量 setData，可能造成卡顿。我用一个_lastWindowWidth字段记录上次处理过的宽度，只有宽度确实发生变化时才重新渲染。2px 的阈值是为了过滤掉细微的像素抖动，实测下来这个值比较合适。

res.size.windowWidth是 onResize 回调里直接给出的最新窗口宽度。你也可以在 freshMarkers 里重新调用wx.getWindowInfo获取，两种方式结果是一样的，但能少一次 API 调用就少一次。

4.4 地图缩放联动：让图标可以跟随 scale 变化

如果你需要 marker 随地图缩放级别变化而变化，方式是在 map 组件的regionchange事件里做处理。注意 regionchange 会在缩放开始和结束时各触发一次，通过e.type可以区分：'begin'表示开始，'end'表示结束。我们只关心结束时的 scale 值。

Page({ // ... onRegionChange(e) { if (e.type !== 'end') return; const scale = e.detail.scale; if (!scale || scale === this.data.mapScale) return; const factor = scale / this.data.mapScale; const markers = this.data.markers.map((m) => { // 在原始 rpx 尺寸基础上乘以缩放因子 const baseW = m._baseWidth || 60; const baseH = m._baseHeight || 60; const nextWidth = getAdaptiveSize(baseW * factor); const nextHeight = getAdaptiveSize(baseH * factor); return { ...m, width: nextWidth, height: nextHeight }; }); this.setData({ markers, mapScale: scale }); } })

这样缩放地图时，图标会跟着一起变大变小。但生产环境里你需要给 factor 加上下限，避免缩放到最大级别时图标大得遮住整条街，或者缩放到最小级别时图标小到看不见。我习惯把 factor 限制在 0.5 到 3 之间：

const factor = Math.min(3, Math.max(0.5, scale / this.data.mapScale));

这里有个容易忽略的坑：如果用户快速连续缩放，regionchange 的 end 事件里拿到的 scale 是"上一次结束"和"本次结束"的差值。连续计算 factor 时，如果用最开始的 mapScale 作为基准，会导致误差累计。所以我在每次 setData 后把mapScale更新为最新值，这样每个因子都是相对于上一次状态的，不会累计误差。

5. 真机实测：不同机型、分屏与特殊屏幕的表现记录

理论说得再多，不如真机跑一圈。我把这套方案在几台真机上跑过的数据整理一下，供参考。

5.1 主流机型下 60rpx 图标的换算结果

这里以 60rpx 的设计尺寸为例，列出几款常见设备的 windowWidth 和实际渲染尺寸：

可以看到，如果固定写死 31px，在 iPhone SE 上偏大，在 iPhone 15 Pro Max 上偏小，在 iPad 上会严重失调。用动态换算后，图标保持和设计稿一致的视觉比例，这是最基本的适配目标。

5.2 iOS 和 Android 的渲染差异，以及注意事项

同样的代码，iOS 和 Android 上 marker 的表现有几个明显的差异：

iOS 上 marker 的渲染顺序更稳定，图片加载后替换红点几乎无感。Android 上部分机型在同时更新多个网络图标时，会出现短暂的"图标闪烁"或"红点延迟替换"，这个问题在低端安卓机上尤其明显。如果 marker 数量不大，建议全部使用本地图标。

anchor在 iOS 和 Android 上的默认行为也有差异。虽然文档说明默认是{ x: 0.5, y: 1 }，但低版本基础库在 Android 上偶尔会表现出默认居中（y=0.5）的状态。如果发现同一份代码在两端坐标点偏离不同，检查 anchor 的设置。

5.3 分屏、折叠屏和 iPad 上的补充适配

分屏场景下，onResize 会触发，但触发时机可能滞后于用户拖动分屏分隔线的动作。这段滞后时间里，marker 尺寸还是旧值。实测在 iPad 分屏拖拽过程中，界面会有几帧的尺寸不匹配，拖拽结束后才会对齐。如果对体验要求高，可以在 WXML 里给 map 加一个 debounce 的样式类，或者在拖拽结束后手动触发一次 freshMarkers。

折叠屏展开时，windowWidth 通常从 360 左右变到 680~720，换算比例直接从 0.48 跳到 0.95。这种大幅变化下，如果 anchor 设置不正确，图标位置的偏移会特别明显。所以我在 4.2 节里特别强调 anchor 和尺寸要同步更新，这个在折叠屏上真的是血泪教训。

6. 进一步优化：setData 性能、本地图片缓存和 callout 适配

6.1 marker 数量多时，setData 的节流和 diff 策略

如果你页面里的 marker 数量很多，比如几十上百个，每次 onResize 都对整个 markers 数组做 setData，性能压力会比较大。微信的 setData 是全量 diff 的，数据量大时照样会卡。

我的做法是引入一个简单的防抖函数，只在连续触发结束后执行一次 freshMarkers：

function debounce(fn, delay = 200) { let timer = null; return function (...args) { if (timer) clearTimeout(timer); timer = setTimeout(() => { fn.apply(this, args); }, delay); }; } // 在 onLoad 里初始化 this._debouncedFreshMarkers = debounce(this.freshMarkers, 200);

onResize 里直接调用this._debouncedFreshMarkers()而不是 freshMarkers，这样即使 resize 连续触发几十次，实际计算也只执行最后那一次。对用户体验来说，200ms 的延迟完全感知不到，但渲染性能会好很多。

6.2 iconPath 变更后的本地图片缓存问题

这是另一个容易踩的坑：你在代码里把 marker 图标从marker_v1.png换成了marker_v2.png，模拟器和开发版上都正常，但正式版发布后，部分老用户的手机上显示的还是旧图标。

原因是微信小程序的本地图片有缓存策略，尤其是那些路径没变但内容变了的图片，客户端可能直接走了缓存。解决方式很简单：图片文件变更时，同时改文件名。比如marker_v1.png改成marker_v2.png，路径和文件名都变了，就不会走旧缓存。这听起来像是工程洁癖，但在正式环境里真的能省掉一堆"图标没更新"的工单。

6.3 callout 弹窗和 label 的统一缩放

marker 的 width 和 height 自适应后，callout 如果不跟着缩放，会出现图标很大、弹窗很小，或者图标很小、弹窗特别突兀的情况。callout 里的fontSize、padding、borderRadius都是 px 单位，建议统一用getAdaptiveSize计算。

label 也是同理。如果你在每个 marker 上方显示一个门店名称的 label，fontSize 和 padding 同样要做换算。这里有一个统一的处理思路：把 callout 和 label 的样式配置也放到一个公共方法里，跟 getMarkerSize 一样封装在 utils 里，这样所有页面都遵循同一套缩放逻辑。

除了尺寸，label 的锚点 offset 也是 px 单位。在图标变大后，label 离图标的距离如果不调整，可能直接盖住图标。我习惯让 label 的位置跟随 anchor 做相对偏移，用自适应后的 px 值去设置 offset，这样它和图标之间始终保持着设计稿里的视觉间距。

在实际项目里把以上方案完整跑过一遍之后，我的体会是我们做小程序地图时，经常默认 map 组件的标记点尺寸和普通 WXML 布局一样会自动适配，但 map 组件内置的原生渲染机制并没有这一步。它给了你 width 和 height，却没说这些属性不会随窗口缩放。所以只要你理解了 rpx 的换算基准是窗口宽度、而 marker 尺寸需要手动执行这个换算，后面所有问题都会顺理成章。最后再分享一个小细节：做自定义图标时，我建议把透明安全边距留足 10% 以上，因为 Android 部分机型在渲染带阴影或描边的 PNG 图标时，边缘会被裁切，留一点余量可以避免图标周围出现"被切掉一圈"的尴尬。希望这篇内容能帮你在小程序地图开发里少走一段弯路。