
1. 腾讯位置服务热力图到底能做什么先想清楚需求再动手刚接手一个数据可视化的需求时很多人第一反应是我要做个热力图但真正落地前得先回答一个问题这张热力图是给谁看的看完之后要做什么决策。腾讯位置服务Tencent Location Service后简称腾讯位置服务提供的地图能力配合它自带的可视化图层做出一张能上线、能扛量、能讲清楚业务故事的热力图并不难难的是选对方案和参数。热力图本质上是把一堆离散的点按照空间密度聚合成连续的颜色分布密度越高颜色越烫一眼就能看出人流、订单、设备、事件在空间上的聚集规律。它能解决的问题其实非常实在连锁门店选址想知道哪片区域客源最密集、物流调度想看清订单在哪些片区堆积、运营大屏想把某个城市的活动热度实时投出来、物联网平台想把海量设备的信号强度在地图上铺开这些都是热力图的主场。腾讯位置服务在这类场景里的优势是它的地图底图、坐标体系、可视化工具体系是打通的申请一个 Key 就能同时用地图、用可视化图层省去了自己搭瓦片服务和坐标系转换的麻烦。这篇文章适合谁看做过前端但没碰过地图可视化的开发者、需要用地图讲故事的数据分析师、以及手里有一堆经纬度数据却不知道怎么变成好看大屏的产品同学。我会把选型逻辑、参数怎么定、代码怎么写、坑怎么填都讲透你照着抄作业就能跑起来。需要提前说清楚的是热力图不是万能药。当你的数据点只有几十个、且每个点都有独立业务含义时散点图比热力图更合适当你需要精确到某条街道的数值时热力图那种糊的聚合特性反而会误导人。所以第一步永远是判断场景选错了可视化类型后面参数调得再细也是白费。2. 方案选型为什么是腾讯位置服务而不是自己搭或换个库2.1 从免费数据可视化大屏到企业级数据可视化的取舍逻辑市面上做数据可视化的路子大致分三类。第一类是纯前端图表库比如 ECharts它在地图叠加和基础图形上很强大屏里那些仪表盘、柱状图、折线图用起来很顺手但要在地图上做地理热力你得自己准备 GeoJSON 地图数据、自己处理经纬度投影城市级别还行全国级别就容易卡。第二类是三维场景引擎比如 Cesium 热力图方案适合做地形、三维建筑、轨迹这种带高度和空间感的场景代价是学习曲线陡、包体大、移动端不友好。第三类是地图厂商提供的位置服务腾讯位置服务就属于这一类它把底图、坐标系、可视化图层、检索、路线都打包好了你调用接口就行。那到底怎么选我的一般判断标准是如果你的核心诉求是把数据铺在地图上并且要能对外上线优先用地图厂商的服务如果只是内部汇报用一张静态图ECharts 或 PowerBI 这类数据可视化工具更快如果业务本身是三维数字孪生再考虑 Cesium 那条线。企业级数据可视化最怕的不是图不好看而是上线之后坐标系对不上、底图加载慢、数据量一大就崩。腾讯位置服务把 GCJ-02 坐标体系内置好了你只要保证喂进去的数据是同一套坐标出图基本不会出现点飘到海里这种事。成本这块也得算。很多团队预算有限做免费数据可视化大屏时会纠结是自己搭地图服务还是用厂商 API。自搭意味着你要维护瓦片服务器、处理并发、还要应对地图合规问题隐性成本很高。腾讯位置服务的可视化能力有免费额度中小规模项目基本够用量大了再按调用量付费这个模型对早期项目很友好。所以我的结论是地理热力图这种强依赖底图和坐标系的场景用现成的位置服务性价比最高。2.2 腾讯位置服务可视化工具体系速览腾讯位置服务的 JavaScript API GL 里有一整套可视化图层热力图只是其中之一。搞热力图之前先把这套体系摸清楚后面做叠加、做联动会省很多事。可视化图层适用场景和热力图的关系Heat热力图密度分布、热度聚集本文主角Scatter散点图精确点位展示常和热力图叠加标注关键点Cluster点聚合海量点归并展示数据点太多时先聚合再上热力LineFlow弧线流向、迁徙展示热区之间的流动关系Trail轨迹移动轨迹配合热力看路径热度这套图层的好处是共用同一份地图实例和坐标系你可以在一个 map 上同时挂热力图和散点互不打架。Heat 图层内部做了聚合优化几万个点也能比较顺滑地渲染这一点比很多自己用 canvas 手撸热力图的方案要稳。理解了这个体系你会发现在免费数据可视化大屏这类需求里用腾讯位置服务做地理底座再用 ECharts 补齐非地理的图表是一个很常见的组合拳。2.3 热力图不适合什么场景提前避坑我见过不少项目硬把热力图用在它不擅长的场景上结果越做越别扭。第一类是数据点太少比如某公司全国只有 20 个仓库做热力图就是一片绿底加几个红点还不如直接在地图上标点。第二类是要求精确读数热力图是密度表达颜色深浅和具体数值之间不是一一对应如果你需要这个格子有 37 个订单这种精度应该用格网或分色区域图。第三类是数据分布极度不均一个超大城市热得发红其他区域全是冷的梯度被压缩得看不出来这时要做对数处理或者分区域看。还有一个容易忽略的点是隐私。热力图聚合之后虽然看不清单个人但如果点足够少、区域足够小还是可能反推出个体位置。做对外发布的图聚合半径不能设太小这是合规层面的基本意识。想清楚这些边界再动手写代码方向才不会偏。3. 核心细节解析数据、参数、阈值到底怎么定3.1 数据准备经纬度、权重、坐标系三件套热力图能不能出效果七分看数据三分看参数。喂给 Heat 图层的数据标准结构大概是这样每个点包含经度、纬度再加一个权重值通常叫 count 或 weight。这个权重决定了这个点贡献多少热度是热力图最关键的业务字段。比如做门店客流热力图权重就是该点位的到访人数做设备信号热力图权重可以是信号强度或告警次数做订单热力图权重就是订单量。数据结构用代码表示如下[ { lat: 39.908, lng: 116.397, count: 120 }, { lat: 39.912, lng: 116.401, count: 85 }, { lat: 39.905, lng: 116.392, count: 200 } ]正文字段名一定要和图层要求的一致腾讯位置服务 Heat 图层默认读lat、lng、count这三个字段你也可以通过配置映射自己的字段名。这里我要重点强调坐标系这个坑腾讯位置服务用的是 GCJ-02 坐标系。如果你的原始数据来自 GPS 设备那是 WGS-84如果来自百度系产品那是 BD-09。坐标不统一热力图整体会偏移几百米在城市级看好像还行一放大就露馅。所以在数据清洗阶段务必先做坐标转换或者直接调用位置服务提供的坐标转换接口把源头统一到 GCJ-02这是所有地理可视化的地基。权重的量纲也要统一。有的数据源权重是 0 到 100 的评分有的是几万的订单数混在一起热力图的颜色梯度就乱了。我的做法是先做归一化把权重映射到一个可控区间或者干脆用真实值但把max参数设合理。数据里如果有经纬度为空、超出合理范围的脏点一定要在进图层前过滤掉否则热力图会出现莫名其妙的孤岛。3.2 半径、权重、透明度参数背后的计算逻辑Heat 图层的参数里radius半径是新手最容易踩坑的一个。它的单位是像素不是米。这意味着一