气象雷达拼图系统会把多部雷达的探测数据加工成一张覆盖大范围的回波拼图，其中基本反射率产品使用频率最高，预报员判断降水强弱、识别强对流天气基本都依赖它。这类产品在前端展示时有一个绕不开的环节：把每个格点的反射率数值转换成气象业务规定的标准颜色，也就是色标映射。这个环节看似只是查表填色，真正做起来会碰到区间归属、无回波透明处理、海量格点渲染性能等一系列细节问题，任何一处处理不当都会让回波图失真。本文结合jQuery与Canvas的配合使用，把整套映射流程的实现思路和容易踩的坑讲清楚。
先弄清楚基本反射率与色标的业务含义
基本反射率描述的是降水粒子对雷达发射电磁波的散射能力，业务上用dBZ作为计量单位。这是一个对数单位，数值每增加10，代表的降水强度大约提升一个量级，所以35 dBZ和45 dBZ看起来只差10，实际雨强差距非常可观。拼图系统在服务端完成多部雷达的数据插值与拼接后，通常会以规则格网的形式把每个格点的dBZ值下发给前端，前端拿到的是一串数值，而不是现成的图片，填色这件事必须由前端自己完成。
色标在这套体系里不是美化手段，而是一种业务语言。气象业务对反射率的显示分级有明确约定：5 dBZ以下视为无回波，界面上不显示颜色；5到15 dBZ用浅蓝色表示弱降水；35 dBZ以上进入黄色、橙色区间，意味着较强降水；一旦出现50 dBZ以上的红色甚至65 dBZ以上的紫色，往往对应强对流或冰雹天气。预报员扫一眼颜色分布就能大致判断天气形势，如果前端把区间边界映射错了一格，颜色传达的强度信息就是错的，可能直接导致误判。
因此色标映射必须满足两个硬性要求：一是区间划分严格对照业务规定，边界值归属不能有歧义；二是拼图覆盖范围内所有雷达站点使用同一份色标表。拼图系统把多部雷达的数据拼在一张图上，如果不同区域用了不同色标，同一块回波在拼缝两侧颜色跳变，整张图的可信度都会受影响。把色标表做成前端的一份独立配置数据，是保证一致性的基础做法。
色标查找表的设计与预生成
最直观的映射写法，是在渲染每个格点时遍历色标数组，逐条判断dBZ落在哪个区间。这种写法在小数据量下没问题，但拼图数据动辄几十万上百万格点，色标又有十几级，逐像素遍历意味着上千万次区间比较，再加上每次都要访问对象属性，页面掉帧会非常明显。
更合理的做法是预先构建色标查找表。dBZ的有效取值范围是有限的，比如约定-30到85 dBZ，那么可以为这个范围内的每个整数dBZ预先算好RGBA四个分量，存进一个类型化数组。渲染时只需一次减法和一次乘法就能定位到颜色，查询复杂度从与色标级数相关降到常数级，而且类型化数组占用连续内存，对CPU缓存友好。
// 基本反射率标准色标表，区间单位为 dBZ
var REF_COLOR_TABLE = [
{ min: 5, max: 10, color: [0, 236, 236] },
{ min: 10, max: 15, color: [1, 160, 246] },
{ min: 15, max: 20, color: [0, 0, 246] },
{ min: 20, max: 25, color: [0, 255, 0] },
{ min: 25, max: 30, color: [0, 232, 0] },
{ min: 30, max: 35, color: [128, 255, 0] },
{ min: 35, max: 40, color: [255, 255, 0] },
{ min: 40, max: 45, color: [255, 200, 0] },
{ min: 45, max: 50, color: [255, 144, 0] },
{ min: 50, max: 55, color: [255, 0, 0] },
{ min: 55, max: 60, color: [216, 0, 0] },
{ min: 60, max: 65, color: [144, 0, 0] },
{ min: 65, max: 70, color: [255, 0, 255] }
];
// 预生成色标查找表，任意 dBZ 值直接换算成数组索引
function buildColorLUT(minDbz, maxDbz, table) {
var size = maxDbz - minDbz + 1;
var lut = new Uint8Array(size * 4);
for (var v = minDbz; v <= maxDbz; v++) {
var offset = (v - minDbz) * 4;
var hit = null;
for (var i = 0; i < table.length; i++) {
if (v >= table[i].min && v < table[i].max) {
hit = table[i].color;
break;
}
}
if (hit) {
lut[offset] = hit[0];
lut[offset + 1] = hit[1];
lut[offset + 2] = hit[2];
lut[offset + 3] = 255;
} else {
lut[offset + 3] = 0; // 无回波区间，透明处理
}
}
return lut;
}这段代码有几个值得注意的设计。色标表采用左闭右开区间，即大于等于min且小于max，保证相邻区间不重不漏；查找表用Uint8Array而不是普通对象数组，避免装箱开销；无回波区间的alpha分量置为0，天然透明，后面把雷达图层叠加在地图底图上时不需要任何额外的抠图处理。查找表构建一次后可以全局缓存，切换时次、刷新数据都不需要重建。
jQuery配合Canvas完成像素级填色
数据获取环节交给jQuery的$.ajax，请求拼图服务返回JSON，内容包含行列数和按行优先存储的一维dBZ数组。渲染环节交给Canvas：把页面上的<canvas>元素宽高直接设置为格点数，一个格点对应一个像素，然后通过CSS把画布拉伸到显示尺寸，浏览器会自动做双线性插值，图像边缘平滑，不需要自己写缩放算法。
$(function () {
var MIN_DBZ = -30, MAX_DBZ = 85;
var canvas = $('#radarCanvas')[0];
var ctx = canvas.getContext('2d');
var lut = buildColorLUT(MIN_DBZ, MAX_DBZ, REF_COLOR_TABLE);
var grid = null, cols = 0, rows = 0;
$.ajax({
url: '/api/radar/mosaic',
method: 'GET',
dataType: 'json',
data: { product: 'ref', mode: 'latest' },
success: function (res) {
rows = res.rows;
cols = res.cols;
grid = res.values; // 一维数组，按行优先存储 dBZ
canvas.width = cols;
canvas.height = rows;
var imgData = ctx.createImageData(cols, rows);
var px = imgData.data;
for (var p = 0; p < grid.length; p++) {
var dbz = grid[p];
var base = p * 4;
// 缺测、越界、低于回波阈值统一按透明处理
if (dbz === null || dbz < MIN_DBZ || dbz > MAX_DBZ) {
px[base + 3] = 0;
continue;
}
var idx = (Math.round(dbz) - MIN_DBZ) * 4;
px[base] = lut[idx];
px[base + 1] = lut[idx + 1];
px[base + 2] = lut[idx + 2];
px[base + 3] = lut[idx + 3];
}
ctx.putImageData(imgData, 0, 0);
}
});
});这里选择putImageData一次性写入整帧像素，而不是用fillRect逐格画矩形。原因在于fillRect的调用次数等于格点数，百万格点就是百万次绘图调用，开销远大于一次批量写入。循环体内也刻意没有出现任何jQuery调用，DOM操作与数值计算彻底分离，这是保持渲染循环性能的关键习惯。
另一个细节是缺测防护。代码里对null以及越界值统一按透明处理，这一步不能省。有些后端会用-999这类哨兵值表示缺测，如果不提前过滤，-999参与索引计算会得到负数位置，读出的颜色完全错误，甚至造成数组越界。把防御逻辑写在循环最前面，比事后排查图像上的异常色块省力得多。
图例动态生成与悬停查值交互
图例是回波图的读图依据，必须与渲染共用同一份色标表，否则图例和图像对不上号。用jQuery根据色标表动态生成图例DOM，每个色块对应一个<div>元素，好处是色标配置一旦调整，图例自动跟着变化，不需要同步维护两份代码。
function renderLegend(table) {
var $box = $('#legendBox').empty();
$.each(table, function (i, item) {
var rgb = 'rgb(' + item.color.join(',') + ')';
$('<div></div>')
.addClass('legend-item')
.css('background', rgb)
.text(item.min + ' ~ ' + item.max + ' dBZ')
.appendTo($box);
});
}悬停查询是预报员常用的交互：鼠标移到某个位置，显示该格点的原始dBZ数值。实现思路是在mousemove事件里把鼠标坐标换算回格点行列号，再反查原始数据数组。注意画布被CSS拉伸过，鼠标坐标基于的是显示尺寸，必须按比例换算回格点坐标，否则查出来的值会和视觉位置对不上。
$('#radarCanvas').on('mousemove', function (e) {
if (!grid) return;
var x = Math.floor(e.offsetX * cols / this.clientWidth);
var y = Math.floor(e.offsetY * rows / this.clientHeight);
if (x < 0 || x >= cols || y < 0 || y >= rows) return;
var dbz = grid[y * cols + x];
var tip = (dbz === null || dbz < 5) ? '无回波' : dbz.toFixed(1) + ' dBZ';
$('#tip').css({ left: e.pageX + 14, top: e.pageY + 14 }).text(tip).show();
}).on('mouseleave', function () {
$('#tip').hide();
});显示原始浮点dBZ而不是颜色等级，对定量分析更有价值，预报员关心的往往不是落在哪一档，而是具体强度。同时把低于5 dBZ的值统一显示为无回波，与色标表的透明区间保持语义一致。提示框跟随鼠标移动，离开画布时隐藏，这些细节让工具更接近业务软件的使用体验。
边界情况与性能优化建议
取整方式决定边界值归属。Math.round和Math.floor对15.6这样的值会给出不同结果，落到不同的色标区间。业务规定如果写的是15到20 dBZ显示某色，就要确认15.5应该归上档还是下档，并与后端的分级逻辑核对，避免前后端口径不一。区间统一采用左闭右开写法，可以从根源上消除重叠和遗漏。
性能方面还有几件事值得做。查找表全局缓存，只在色标配置变化时重建；多时次动画场景下预加载各帧数据，切换时只执行填色循环；如果单帧渲染时间超过一次屏幕刷新周期，把渲染放进requestAnimationFrame回调，避免阻塞交互。另外要警惕在循环里拼接字符串或创建jQuery对象，这类操作看似不起眼，乘以百万格点的循环次数就是灾难。
最后是图层叠加。雷达图层因为无回波区域透明，可以直接叠在地图底图上方，用CSS定位即可，交互事件绑定在雷达图层上，底图不受影响。如果后续要做站点切换、区域裁剪，记得这些逻辑都只操作数据数组，让色标映射这一层保持纯粹，整个系统的可维护性会好很多。