矩形树图Treemap这几年在BI报表、数据大屏和资源管理工具里几乎成了标配尤其是那种既要表达“谁大谁小”、又要能把父子层级关系压缩进一张图的场景。很多人把它当成饼图的替代品但真上手用Highcharts做treemap的时候才会发现布局算法怎么选、层级数据怎么组织、面积权重怎么按业务规则自定义、下钻交互怎么配每一步都有讲究。这篇文章我基于Highcharts的treemap模块把从基础配置到自定义布局算法的完整链路拆开讲讲。适合两类人一类是刚开始用treemap做层级占比可视化的前端另一类是已经被产品经理要求“把矩形面积改成按我们业务的权重规则来算”的开发者——后一半内容基本就是给你们写的。先说我自己的结论Highcharts的treemap最值钱的地方不是它默认渲染出来多好看而是layoutAlgorithm这个配置项把布局算法做成了可替换的扩展点。搞清楚这一点矩形树图就从“一个图表组件”变成了“一个按你的面积规则生成层级图的框架”。下面从原理开始。1. 先搞清楚矩形树图在解决什么问题1.1 面积即权重嵌套即层级矩形树图的核心只有一句话用矩形面积表达数据权重用嵌套关系表达树形层级。父节点是一个大矩形子节点按各自的value分摊这个大矩形的面积孙子节点继续在子节点的矩形里切分。视觉上你一眼就能看出哪个分支占的比重最大同时还能顺着嵌套关系往下追踪到具体是哪个叶子节点贡献的。这和饼图最大的区别在于层级。饼图只适合一层占比treemap可以往下钻好几层而不需要切换页面。和普通柱状图、条形图的区别在于空间利用效率当节点数量达到几百上千时条形图只能靠滚动和分页treemap一张图能装下还能保持一定的可读性。当然它也有天生的短板——人眼对面积的感知精度远低于对长度和高度的感知所以treemap更适合“看趋势、找异常、比大小”不适合“读出精确数值”。真要精确读数tooltip和数据标签必须做好。1.2 哪些场景真正适合用它我实际做过的项目里treemap用得最顺的场景有这么几类磁盘和存储空间分析这是经典中的经典各类网盘清理工具、系统资源管理器都是这么干的、销售和营收按地区-产品-渠道的层级拆分、市场份额构成、库存总量按品类的分布、日志错误类型按服务-模块的归类统计。这些场景的共同点是数据天然带层级而且每一层都要按某个指标比较大小。不适合的场景也要说清楚。如果你的数据只有一层直接用饼图或者横向条形图更直观如果层级超过四层且不能下钻嵌套矩形会越来越小标签根本放不下反而失去意义如果用户需要精确对比数值treemap的视觉编码精度不够这时候表格加排序是更好的选择。判断标准就一条用户的核心任务是“快速定位哪个子集最大或最小”而不是“精确知道它是多少”。1.3 三种内置布局算法的来龙去脉treemap听起来简单但“把一堆矩形不重叠地塞进父矩形还要好看”这件事本身就是经典的可视化研究课题。Highcharts内置了几种layoutAlgorithm选项sliceAndDice最早期的切法横一刀竖一刀交替切。实现最简单但会产生大量细长条矩形标签几乎没法放。strip先按固定方向排成一条条带子再在条带内朝另一方向切。比sliceAndDice好一些适合大量需要标签的场景。squarified目前默认算法也叫方块化布局核心思想是尽可能让每个矩形接近正方形减少长宽比的极端值视觉上最整齐。squarified这个名字来自论文Squarified Treemaps思路我用大白话说一下先把子节点按value从大到小排序然后一行一行地摆。每摆一个新节点之前先计算一下把它加入当前行这一行的“最差长宽比”是变大还是变小。如果加了之后长宽比更差就停止当前行另起一行。这个判定过程很像是贪心每一步都选择让当前矩形更接近正方形的做法。最终效果就是那种方块拼贴感读起来最舒服。这里说一句题外话treemap布局算法和平时刷题遇到的排序、搜索、动态规划是两类东西它更依赖几何切分和贪心策略但也同样讲究复杂度。后面自定义算法时你也会发现排序预处理、递归切分、边界条件这些基本功一个都跑不掉。2. Highcharts Treemap 基础接入与数据格式2.1 模块引入与最小配置Highcharts的treemap不在默认包里需要单独引入模块。用npm的同学import Highcharts from highcharts; import treemapModule from highcharts/modules/treemap; import heatmapModule from highcharts/modules/heatmap; // 如果要用colorAxis连续色阶 treemapModule(Highcharts); heatmapModule(Highcharts);注意顺序treemap模块要先注册heatmap模块是为了让colorAxis可用因为treemap的颜色映射底层依赖heatmap的colorAxis能力不引入也能画但没有连续色阶功能。最基础的一个配置大概是这样的Highcharts.chart(container, { title: { text: 营收占比 }, series: [{ type: treemap, layoutAlgorithm: squarified, data: [{ id: east, name: 华东, value: 180 }, { id: north, name: 华北, value: 120 }] }] });只要两步type设为treemapdata给一组带name和value的对象。没有parent属性的节点会被当成根节点的直接子节点在画布上平铺。很多人第一次画出来发现一片空白99%的情况是treemap模块没引入先查这个比检查数据快得多。2.2 层级数据的两种组织方式treemap的层级数据有平铺和嵌套两种写法实际项目里平铺更常见因为后端接口返回扁平列表再映射父子关系很方便。平铺写法靠id和parent建立父子关系const data [ { id: root, name: 集团, value: 500, color: #e8e8e8 }, { id: east, parent: root, name: 华东, value: 200 }, { id: hangzhou, parent: east, name: 杭州, value: 80 }, { id: shanghai, parent: east, name: 上海, value: 120 }, { id: north, parent: root, name: 华北, value: 300 }, { id: beijing, parent: north, name: 北京, value: 180 } ];注意一个细节父节点的value决定了它在父级里的面积占比但实际渲染时父节点矩形会被子节点完全覆盖所以父节点的value只是用来在上级切分时确定区域大小真正画出来的颜色和标签以子节点为准。如果父节点没有value它会尝试用子节点的value之和补上Highcharts内部会做这个累加但如果数据量很大建议后端直接算好省得前端遍历。嵌套写法适合数据结构天然就是树形的情况比如递归接口const data [{ id: east, name: 华东, value: 200, children: [ { id: hangzhou, name: 杭州, value: 80 }, { id: shanghai, name: 上海, value: 120 } ] }];两种写法最后渲染结果一样。我个人更推荐平铺因为它在局部更新时好处理你只需要知道某条记录的id和parent就能定位不需要递归查找整棵树。嵌套写法在数据更新时容易踩坑改了某个子节点整个树要重新序列化图也跟着整体重绘。2.3 颜色、标签与默认样式先说颜色。treemap配色有三种做法直接给每个节点写color最直观但数据一变颜色就要跟着改适合静态报告。colorByPoint按节点顺序从调色板取色适合想快速区分兄弟节点但不在乎颜色语义的场景。levels加colorAxis按层级和数值综合着色这是可维护性最好的方案。levels配置是按深度控制样式比如第一层用浅色边框、第二层加粗描边、第三层字体缩小levels: [{ level: 1, borderColor: #fff, borderWidth: 2, dataLabels: { enabled: true, fontSize: 14px } }, { level: 2, borderColor: #fff, borderWidth: 1, dataLabels: { enabled: true, fontSize: 11px } }]colorAxis适合“颜色深浅代表数值大小”的需求。比如营收越高颜色越深这时候把colorAxis的min、max和stops配好节点颜色就会自动根据value映射不需要人工介入colorAxis: { min: 0, max: 500, stops: [ [0, #f7fbff], [0.5, #6baed6], [1, #08306b] ] }标签方面默认dataLabels只在矩形宽度足够时显示放不下就自动隐藏。常用format可以是{point.name}加{point.value}也可以加百分比。矩形很小时还想显示可以把allowOverlap设为true但结果通常是标签互相压在一起不建议这么做后面实战部分我会给一套更好的方案。3. 自定义布局算法把矩形面积控制权拿回自己手里3.1 layoutAlgorithm选项背后是一个可替换的函数这是整篇最核心的部分。很多教程讲到treemap的layoutAlgorithm就停在内置的几个选项上但实际上Highcharts的设计很有趣layoutAlgorithm的取值对应的不是一段写死的分支判断而是treemap series原型上的一个同名方法。也就是说你传入squarified它内部就去调用prototype上的squarified(...)传入sliceAndDice就调用sliceAndDice(...)。这意味着什么意味着你可以往原型上挂一个自己的函数然后把layoutAlgorithm设成你的函数名你的布局逻辑就会被执行。这一步操作完全不需要修改Highcharts源码属于官方设计留出来的扩展点只是文档里没怎么展开讲。明白了这一点后面所有“自定义算法”的需求都有了落点。这里也要提醒一句不同版本的Highcharts内部布局函数的参数签名多少有点差别。8.x、10.x、11.x我都实际用过大方向一致但box参数是用left/top还是x/ychildren是已经排好序还是原始顺序版本之间确实不一样。动笔写函数之前先在你的项目里打一行console.log搞清楚参数长什么样再开始写逻辑这个“5分钟侦查”能帮你省下一下午的排查时间。3.2 自定义算法的套路挂原型方法加设置layoutAlgorithm先看一个最简骨架。假设我们要实现一个halfSplit布局函数的职责是拿到父节点的矩形区域和子节点列表给每个子节点算出x、y、width、height写回到子节点对象上。Highcharts.seriesTypes.treemap.prototype.halfSplit function (parent, children, box) { const x box.x ?? box.left ?? 0; const y box.y ?? box.top ?? 0; const w box.width; const h box.height; function place(nodes, px, py, pw, ph) { if (!nodes.length) return; if (nodes.length 1) { const p nodes[0]; p.x px; p.y py; p.width pw; p.height ph; p.shapeArgs { x: px, y: py, width: pw, height: ph }; return; } const total nodes.reduce((sum, p) sum p.value, 0); const vertical pw ph; // 宽了就竖着切高了就横着切 let acc 0; let i 0; for (; i nodes.length; i) { acc nodes[i].value; if (acc total / 2) { i 1; break; } } i Math.min(Math.max(i, 1), nodes.length - 1); const leftValue nodes.slice(0, i).reduce((sum, p) sum p.value, 0); const split (vertical ? pw : ph) * (leftValue / total); if (vertical) { place(nodes.slice(0, i), px, py, split, ph); place(nodes.slice(i), px split, py, pw - split, ph); } else { place(nodes.slice(0, i), px, py, pw, split); place(nodes.slice(i), px, py split, pw, ph - split); } } const sorted children.slice().sort((a, b) b.value - a.value); place(sorted, x, y, w, h); };然后在series配置里直接写series: [{ type: treemap, layoutAlgorithm: halfSplit, data: data }]如果一切顺利你的图表就会按“每次从中间按价值对半分、宽了就竖切、高了就横切”的规则来布局。注意几个细节children要自己排序因为内置squarified在布局前会排序但你的自定义函数里Highcharts不会自动帮你排要给point同时写x/y/width/height和shapeArgs因为渲染路径里直接拿shapeArgs画矩形x/y则被用来定位递归出口必须处理好单节点和空数组的情况否则要么死循环要么把整个画布尺寸写坏。3.3 半值递归切割和squarified到底差在哪我特意用这个halfSplit做例子因为它足够简单能让你看清楚“布局算法是在做什么”。halfSplit的思路是每次找到子节点价值总和的一半作为分割线分成左右两块然后递归。它的优点是实现只有二十行逻辑好验证缺点是分割点只看一半不保证两边矩形长宽比都合理可能出现一边特别扁的情况。squarified则不同。它先把子节点按value降序排好然后维护“当前行”每加入一个新节点都计算当前行矩形的最差长宽比如果加入后变得更差就结束这一行、开新行。这种做法不会出现“硬切一半”的粗暴结果而是让同等级的矩形尽量都以接近正方形的形态出现。说白了squarified是在逐行贪心halfSplit是在递归二分两者都是合法的treemap布局算法只是优化目标不同。你要真去实现一个和squarified效果接近的算法工作量比halfSplit大不少因为要实时维护行的长宽比、判断行内如何填充、处理最后一个不满的行。这也是为什么我建议除非业务确有特殊的几何要求比如必须按某个维度对齐、必须保留特定长宽比例否则先别急着挑战squarified用halfSplit或者调整value权重来满足业务需求性价比高得多。3.4 更常见的“自定义”先改权重再谈布局实际项目里“自定义算法用矩形面积表达数据权重”这句话绝大多数时候指的是权重的计算方法而不是矩形的排列方法。比如说业务方要求面积大小不由销售额决定而是由“销售额乘毛利率”决定或者要弱化头部大值的影响、让中小品类也能看清这时候根本不需要动布局函数。做法很简单进入图表之前把原始数据映射成value。比如const raw [ { name: 手机, sales: 1200, profitRate: 0.18 }, { name: 配件, sales: 300, profitRate: 0.45 } ]; const data raw.map(d ({ name: d.name, value: (d.sales * d.profitRate).toFixed(2) }));甚至可以做非线性变换。数据分布极端时比如头部占80%、尾部都是零头直接线性映射会让小矩形几乎看不见这时候用value Math.sqrt(sales)或者value Math.log(sales 1)能把差距压缩所有层级都保有可见性。但要注意一旦用了非线性变换tooltip里显示的数字和面积代表的含义就不再一致最好在tooltip的formatter里把原始值重新展示出来避免误导。我踩过的坑是客户要求“面积代表利润”我直接把利润字段当成value传进去结果负利润的节点直接报错。treemap的value不支持负数这不是Highcharts的bug而是矩形面积本身没法表达负数的视觉约束。解决办法是在映射阶段把负利润做平移或者单独聚合再在标签和tooltip里说明。4. 交互、钻取与视觉细节打磨4.1 下钻能力一张图承载整个树矩形树图真正的价值要在层级多了之后才体现。如果只显示一层它和饼图没有本质区别所以下钻交互几乎必配。Highcharts的下钻有两套配置取决于版本。老版本10之前用allowDrillToNode加traverseUpButtonseries: [{ type: treemap, allowDrillToNode: true, traverseUpButton: { position: { align: right, verticalAlign: top } } }]新版本10.x以后推荐allowTraversingTree配合breadcrumbsseries: [{ type: treemap, allowTraversingTree: true }], breadcrumbs: { position: { align: right, verticalAlign: top } }启用之后点某个有子节点的矩形图就会下钻到那一层把它的子节点铺满画布面包屑会记录路径点上一级可以返回。这个机制解决了一个核心矛盾层级太深放不下标签时不是缩小矩形硬塞而是把视觉焦点下钻到当前层让每层都能看得清。我实际使用中的建议是下钻动画不要关点下去时的平滑过渡能帮助用户建立“层级移动”的心理模型虽然几百个点时会有点卡但权衡下来值得。另外一定要给可点击的节点一个视觉暗示比如鼠标移上去高亮、光标变pointer不然用户根本不知道能下钻。4.2 标签防重叠与面积适配数据标签是treemap最容易翻车的地方。矩形面积大的节点想显示大字号、面积小的只能显示一两行甚至不显示靠默认配置做不到这种自适应。我的做法是不开allowOverlap用dataLabels的formatter加上矩形大小判断在样式上做动态适配dataLabels: { enabled: true, allowOverlap: false, formatter: function () { return this.point.width 80 ? this.point.name br this.point.value : this.point.width 30 ? this.point.name : ; }, style: { textOverflow: ellipsis, fontSize: 11px } }有人会问formatter里能拿到point.width吗能而且这个width就是布局算法算完之后的最终矩形宽度正好可以用来做分级显示。这个技巧比依赖Highcharts内部的crop判定要可靠因为crop只会隐藏放不下的标签不会根据面积大小调整内容详略。另外多行文本时把useHTML设为true再配合自定义样式控制换行和省略号会顺手很多。标签字体大小也可以做成动态的比如fontSize: Math.min(14, Math.max(9, this.point.width / 30))这样大矩形字大、小矩形字小整体观感会自然很多。不过这个方案要小心矩形宽度取的是屏幕像素不同图表尺寸下同一个字号的可用性不一样建议在resize回调里重新渲染图表。4.3 大数据量下的性能策略treemap容器里的DOM节点数量跟数据点数量成正比而且每个节点还有SVG矩形、文字标签和hover交互几千个点之后性能会明显下滑。我在一个监控大盘项目里塞过8000多个叶子节点默认配置直接卡成幻灯片后来做了三件事才救回来。第一数据扁平化。嵌套对象写法在内部要递归解析平铺数组加id/parent可以减少一次树形序列化的开销。第二关掉不必要的动画和模糊效果animation: false、turboThreshold适当调高关闭阴影和渐变。第三按需可见。默认渲染所有层级但很多深层节点在父级矩形里根本小到看不见可以先用levels把深层的dataLabels全部关掉下钻到那一层时再动态开启这样DOM数量不变、渲染压力却小很多。还要强调一点别指望boost模块能救treemap。boost主要是给散点图和柱状图做WebGL加速的treemap是SVG渲染不在boost支持范围内。真到了几万节点的时候该做的是在数据源做聚合——比如把城市级聚合成省级、把千个SKU聚合成品类展示粒度够用就好。5. 完整实战用营收数据做一个可下钻的Treemap5.1 数据准备与权重设计假设这样一个业务场景集团下面有华东、华北、华南三个大区每区有若干城市每个城市卖两类产品。需求是面积代表“贡献营收”但还要能下钻到城市、再到产品线。原始数据从接口拿到的大概是这样const raw [ { region: 华东, city: 杭州, line: 硬件, revenue: 820 }, { region: 华东, city: 杭州, line: 软件, revenue: 430 }, { region: 华东, city: 上海, line: 硬件, revenue: 1200 }, { region: 华东, city: 上海, line: 软件, revenue: 650 }, { region: 华北, city: 北京, line: 硬件, revenue: 980 }, { region: 华北, city: 北京, line: 软件, revenue: 720 }, { region: 华南, city: 深圳, line: 硬件, revenue: 1100 }, { region: 华南, city: 深圳, line: 软件, revenue: 380 } ];需要把它转成treemap需要的三层扁平结构。我的习惯是先手动维护id用区域-城市-产品线做id的组成部分既保证唯一性又方便调试时从id直接读出层级const data []; const regionMap {}; const cityMap {}; raw.forEach(item { const rid r- item.region; const cid c- item.region - item.city; const pid p- item.region - item.city - item.line; if (!regionMap[rid]) { regionMap[rid] true; data.push({ id: rid, name: item.region, value: 0 }); } if (!cityMap[cid]) { cityMap[cid] true; data.push({ id: cid, parent: rid, name: item.city, value: 0 }); } data.push({ id: pid, parent: cid, name: item.line, value: item.revenue }); });父节点的value先填0Highcharts会自动用子节点value求和但如果想省掉前端遍历也可以在循环里累加。数据量不大时两种都行我自己倾向于让后端把每层的value算好前端只负责映射。5.2 完整配置代码这一步把前面讲到的配置全部组合起来。注意这里用的是新版API如果你还在用老版本把allowTraversingTree那一行换成allowDrillToNode即可Highcharts.chart(container, { chart: { animation: false }, title: { text: 各区域产品线营收占比 }, tooltip: { pointFormatter: function () { return this.name : this.value 万; } }, colorAxis: { min: 0, max: 1300, stops: [ [0, #edf8b1], [0.5, #7fcdbb], [1, #0c2c84] ] }, series: [{ type: treemap, layoutAlgorithm: squarified, allowTraversingTree: true, dataLabels: { enabled: true, formatter: function () { if (this.point.width 40) return ; return this.point.name; }, style: { textOverflow: ellipsis, fontSize: 11px } }, level: 1, levels: [{ level: 1, dataLabels: { fontSize: 14px }, borderWidth: 2, borderColor: #fff }, { level: 2, dataLabels: { fontSize: 12px }, borderWidth: 1, borderColor: #fff }], data: data }], breadcrumbs: { position: { align: right } }, responsive: { rules: [{ condition: { maxWidth: 600 }, chartOptions: { series: [{ dataLabels: { style: { fontSize: 9px } } }] } }] } });几个关键点说一下。tooltip里我用pointFormatter而不是默认的HTML这样hover时能看到当前节点的精确值和完整名称弥补面积感知精度的不足。colorAxis的max选1300是因为最大的单条产品线营收是1200留一点余量颜色不容易顶到最深色。responsive规则是给移动端降字号用的treemap在手机上看字号不降根本没法看而这个配置不影响桌面端。5.3 从渲染效果倒推参数调整配完之后不是完事要按实际渲染结果调。常见三种情况第一种整体全是细长条。说明squarified没能发挥作用多半是子节点数量太少或者value差距太大。子节点只有三四个时squarified和sliceAndDice差别不大这时直接看看是不是某个节点的value是0或者极小把异常值处理掉。第二种颜色的层次感不对。比如大区之间颜色分不开都是同一个色系。这时候不要把每个大区都靠colorAxis而是给大区节点直接指定color子节点再用colorAxis按数值着色让“区域”和“数值”两个维度分开编码。这个做法其实来自一个实践技巧嵌套结构里不同层级适合承载不同信息维度一层靠颜色区分身份另一层靠颜色深浅区分大小。第三种下钻之后用户迷路。breadcrumbs虽然有路径但顶部一行文字太弱。我的做法是给标题加一个当前层级的同步显示或者用chart.setTitle在钻取事件里更新chart: { events: { drilldown: function (e) { if (e.point) { this.setTitle({ text: e.point.name 营收占比 }); } } } }这样用户下钻到哪个节点页面标题就跟着变配合breadcrumbs导航就清晰多了。6. 常见问题与排查实录6.1 节点不显示或面积变成0最容易中招的一个原因是value为0或undefined。treemap里value为0的节点面积就是0等于没这个节点undefined则可能导致整段布局计算出NaN更严重。排查时先打印series data看每个节点的value和parent是否齐全。另一个原因是parent指向了不存在的id节点找不到父级会被当成孤儿挂到根上表现是所有节点都挤在一起。这种问题在动态更新数据时特别容易出因为接口可能返回了已经被删掉的父节点id。6.2 矩形极度细长如果选了squarified还是出细长条先看数据量。少于5个子节点时什么算法都摆不出方块感这是数学上的物理限制不是配置错了。如果子节点数量正常但依然细长检查是不是有几个value特别大的节点挤压了其他节点极端分布下squarified也只能尽量优化不能保证所有矩形都是正方形。想要更均匀要么做对数变换压缩差距要么换strip算法让标签更好放。6.3 自定义算法不生效排查顺序固定三步第一步确认Module有没有注册不注册整个图就是白的。第二步确认layoutAlgorithm字符串和prototype上的函数名完全一致大小写也敏感。第三步在函数最前面加console.log看看函数到底有没有被调用如果没被调用说明你的版本里layoutAlgorithm不是走原型方法查找的机制这时候改用Highcharts.wrap去包一层内部的布局方法也能达到目的。实在不想绕直接退回改value权重的方案一样能表达“自定义权重”的需求。6.4 大数据量卡顿前面提过数据扁平化、关动画、按层级开关标签这些常规操作之外还有一个容易忽略的点tooltip的useHTML不要随便开。HTML模式的tooltip在hover时会频繁重建DOM几千个点的情况下会明显卡顿SVG模式的tooltip虽然样式限制多一点但性能稳定得多。另外resize时如果图表很大会触发整图重绘考虑用chart.reflow()配合debounce把频繁的resize事件合并成一次。再补一个不太常见的坑dataLabels的formatter里如果访问this.point.width在初始渲染阶段可能拿到的是undefined因为布局算法还没跑完。遇到这种问题用this.point.shapeArgs.width来替代shapeArgs在布局完成后一定存在。这两个字段大多数时候一致但时序上shapeArgs更可靠。写在最后的实践体会玩了几年Highcharts treemap我最深的体会是这个组件的能力边界不在图表库本身而在你对“权重”和“布局”的理解。绝大多数业务需求根本不需要改布局算法把value的映射逻辑想清楚就够了少数确实需要特殊几何排列的Highcharts也留了原型扩展的口子只是需要你花点时间摸清版本内部的参数结构。我的建议是先做最简单的那版squarified默认布局加上自定义权重映射跑通后再根据产品反馈决定要不要动算法。能通过数据和样式解决的问题别急着碰代码真要碰也记得先console.log那个box参数长什么样。这些看起来笨拙的确认步骤往往就是老手和新手之间最大的差距。