1. 项目概述这不是一份“排行榜”而是一份数据工程师每天都在用的实战地图你打开一个新项目需求文档里写着“需要把用户行为热力图、实时订单流水折线图、多维度漏斗转化矩阵还有带下钻能力的地理分布图全部嵌入到现有Web管理后台里。”——这时候你不会去翻《JavaScript权威指南》也不会立刻打开MDN查Canvas API。你会做的第一件事是打开终端敲下npm install然后在package.json里纠结到底该选 ECharts 还是 Chart.jsHighcharts 值不值得为那几个高级交互功能付年费Plotly.js 的 React 封装会不会和你团队的 Redux Toolkit 冲突D3.js 看起来很酷但那个自定义力导向图的力模拟器真能两周内调通并上线吗这就是我们做这次评测的真实起点。不是学院派的理论比对不是厂商白皮书的参数罗列而是基于过去三年我参与过的17个真实Web数据产品交付项目涵盖电商BI看板、IoT设备监控平台、金融风控仪表盘、医疗科研数据门户把每个库当成一个“可部署的工程组件”来拆解它在Webpack打包体积上吃不吃内存在React 18并发渲染下会不会卡顿当数据量从1万条涨到50万条时渲染帧率掉到多少它的TypeScript类型定义是否覆盖了90%以上的配置项文档里的“示例代码”复制粘贴后能不能直接跑通还是得花两小时查issue里别人踩过的坑核心关键词——数据科学、Web、数据可视化、分析库、Highcharts——不是标签而是五道真实的工程关卡。数据科学意味着你要处理时间序列、分组聚合、异常值过滤等预处理逻辑Web意味着你必须面对跨域、SSR兼容、移动端适配、无障碍访问a11y这些前端基建问题数据可视化不只是“画出来”而是“可交互、可下钻、可联动、可导出”分析库这个词本身就暗示着它要和Pandas、NumPy、Dask甚至Arrow数据结构无缝衔接而Highcharts则是我们评测中一个关键的“商业闭源”锚点——它贵但它稳它文档全它客户支持响应快。我们不回避价格不神话开源也不贬低闭源。我们只问一个问题当你明天就要上线后天就要给客户演示这个库能不能让你少熬两小时夜少改三版代码少被产品经理追着问“为什么地图缩放卡顿”适合谁读如果你是刚转行的数据分析师正为毕业设计选ECharts还是AntV发愁如果你是前端工程师被PM塞过来一份“要支持200个并发图表”的需求如果你是数据平台负责人正在评估要不要把内部BI系统从Tableau迁移到自研Web方案或者你只是想搞清楚为什么同样是画柱状图有的库加载10万条数据只要400ms有的却要2.3秒——那你来对地方了。这篇评测没有“最佳答案”只有“在什么条件下哪个选择最不让你后悔”。2. 整体设计与思路拆解我们如何把“画图”这件事还原成一场工程压力测试常规的可视化库评测往往停留在“功能列表对比”层面A库支持3D散点图B库不支持C库有内置导出PDFD库需要自己写Canvas toBlob……这种对比对真实开发毫无价值。因为没人会在生产环境里只画一张静态3D散点图。真正的挑战永远藏在“组合使用”和“规模放大”之后。所以我们设计了一套四层递进的评测框架每一层都对应一个真实场景中的致命痛点2.1 第一层基础渲染性能压测“它能扛住多少数据”我们构建了一个标准化的“百万级时间序列数据集”包含100个指标如CPU使用率、请求延迟、错误率每个指标有100万条时间戳数值记录模拟IoT设备10万台设备每秒上报。然后在同一台MacBook Pro M116GB内存上用相同版本的Chromev124分别测试各库在以下场景下的首屏渲染时间、内存占用峰值、滚动/缩放帧率FPS场景1单图表渲染10万点折线图典型监控场景场景2同页面并行渲染20个独立折线图典型Dashboard场景场景3开启“动态更新”模式每秒新增1000条数据并重绘典型实时流场景提示这里我们刻意避开了“纯Canvas渲染”或“纯SVG渲染”的简单二分法。比如ECharts默认用Canvas但它的“大数据量模式”会自动切换为WebGLChart.js 4.x引入了新的“渲染器插件系统”允许你为不同图表类型指定不同底层引擎而Highcharts的boost模块本质是WebGL 数据采样策略的组合拳。评测的关键不是看它用了什么技术而是看它在你实际数据规模下表现是否稳定可预期。2.2 第二层框架集成深度“它能和我的技术栈和平共处吗”一个库再强大如果和你的React/Vue/Angular项目格格不入就是废铁。我们测试了三大主流前端框架React 18.2, Vue 3.4, Angular 17下的五个关键集成维度SSR兼容性服务端渲染时图表能否正确生成初始HTML骨架避免客户端水合hydration时的闪烁或报错状态管理耦合度当图表数据来自Zustand/Redux/Pinia时库是否提供细粒度的updateOptions()API还是必须整个组件key重置TypeScript支持完备性types/xxx包是否由官方维护类型定义是否覆盖所有配置项包括series[0].markArea.data[0].itemStyle.color这种深层路径Tree-shaking友好度import { BarChart } from echarts是否真的只打包BarChart相关代码还是把整个ECharts 5MB体积全打进Bundle错误边界Error Boundary鲁棒性当传入非法数据如null、undefined、非数组的data时库是静默失败、抛出可捕获错误还是直接让整个React应用崩溃注意我们发现一个普遍误区——很多团队认为“React Wrapper”就是集成友好。但实测发现像react-highcharts这种第三方封装其更新频率远低于Highcharts主库且对React 18的Suspense和Transition支持几乎为零。真正可靠的是官方维护的highcharts-react-official它把Highcharts实例生命周期完全交由React控制连ref回调都做了防抖优化。2.3 第三层分析能力内建度“它能帮我‘算’还是只负责‘画’”数据可视化库的价值早已超越“图形渲染引擎”。它应该是一个轻量级的分析协作者。我们重点考察了各库对以下分析原语的原生支持程度数据聚合是否内置groupBy、rollup、movingAverage等函数还是必须依赖外部Lodash或D3-array统计标注能否一键添加箱线图Boxplot、置信区间带Confidence Band、回归趋势线Linear/Polynomial Fit交互式计算用户框选区域后能否自动计算该区域内的均值、标准差、最大最小值并以Tooltip形式展示坐标系扩展是否原生支持极坐标、对数坐标、时间轴Time Axis的复杂刻度格式化如2024-03-15T14:30:00.123Z自动解析为“14:30:00”数据驱动样式能否根据数据值动态设置颜色Color Mapping、大小Size Mapping、透明度Opacity Mapping而无需手动遍历数据数组例如Plotly.js的FigureWidget在Jupyter中能直接调用fig.add_trace(go.Scatter(xx, yy, modelinesmarkers))但它的transform属性可以链式调用{type: aggregate, fields: [y], aggregations: [{target: y, func: avg}]}这已经是在做分析层的事情了。而ECharts的dataset机制通过source字段绑定原始数据再用encode声明维度映射配合transform配置ecStat:regression就能在配置层完成线性回归计算——这才是分析库该有的样子。2.4 第四层企业级工程就绪度“它能进我的CI/CD流水线吗”最后也是最容易被忽略的一层它是否符合一个成熟企业的工程规范我们检查了以下硬性指标许可证合规性MIT/BSD/Apache 2.0 是友好型GPLv3可能触发传染性风险Highcharts的免费版非商业用途和付费版商业授权条款是否清晰可审计安全漏洞扫描用npm audit --audit-level high检查各库及其依赖树是否有已知的高危CVE如Prototype Pollution、XSS注入点CI/CD友好性文档是否提供Docker镜像构建脚本是否支持--no-optional安装以跳过仅用于Demo的依赖如canvas长期支持LTS策略主版本如ECharts 5.x是否承诺至少18个月的安全补丁是否有明确的废弃deprecation通知周期可观测性埋点库自身是否提供性能监控API如chart.on(rendered, callback)方便你将其纳入公司统一的APM系统如Datadog、Sentry我们曾在一个金融客户项目中栽过跟头选用了一个轻量级库它渲染极快但其package.json里peerDependencies声明的react版本范围是^16.8.0 || ^17.0.0而客户生产环境强制要求react18.2.0。结果CI流水线每次构建都报peer dep missing警告虽然不影响运行但违反了客户“零警告”上线标准被迫临时替换。这种细节比“支持3D图”重要一百倍。3. 核心细节解析与实操要点从“能用”到“用好”的七道坎评测不是终点而是为了帮你绕开那些文档里绝不会写的坑。下面这七个核心细节是我过去三年在十几个项目里用真金白银加班费和客户投诉换来的经验。它们不炫技但每一个都直击上线前最后一刻的崩溃现场。3.1 坎一内存泄漏——你以为的“销毁”其实是“假死”几乎所有可视化库都提供dispose()或destroy()方法但它的实际效果千差万别。我们在一个实时监控大屏项目中发现ECharts 5.4.3版本当频繁切换Tab页并调用chart.dispose()后Chrome DevTools的Memory面板显示DOM节点被释放了但JS Heap里仍有大量echarts/lib/chart/line/LineSeriesModel实例残留导致页面运行2小时后内存占用飙升至1.2GB最终卡死。根因分析ECharts的dispose()方法只清理了图表实例自身的事件监听器和DOM引用但未切断其内部dataset与外部数据源的响应式连接尤其当dataset.source是MobX observable对象时。而Highcharts的chart.destroy()则更彻底它会主动调用chart.series.forEach(s s.remove(false))并清空所有chart.container上的>// ECharts 安全销毁推荐 function safeDisposeECharts(chart) { if (!chart || !chart.isDisposed) { // 先手动解除数据源响应式绑定如果用了MobX/Pinia if (typeof chart.getOption function) { const option chart.getOption(); if (option.dataset option.dataset.source) { // 如果source是observable需手动stopObserving if (option.dataset.source.stopObserving) { option.dataset.source.stopObserving(); } } } chart.dispose(); } } // Highcharts 安全销毁官方推荐 chart.destroy(); // 官方保证100%清理注意不要迷信chart.clear()。它只是清空图表内容但保留所有事件监听器和DOM结构内存泄漏风险比dispose()更高。真正的销毁必须是dispose()或destroy()。3.2 坎二字体渲染失真——为什么你的中文图表看起来“发虚”在Mac和Windows上Canvas渲染的文本模糊问题是高频投诉点。根本原因在于Canvas的ctx.font设置无法精确控制字体的Hinting字形微调和Subpixel Rendering子像素渲染。我们对比了12种字体在不同库下的渲染效果库默认字体Mac渲染效果Windows渲染效果解决方案EChartssans-serif清晰发虚尤其12px以下强制PingFang SC, Microsoft YaHei, sans-serifChart.jsHelvetica Neue, Arial, sans-serif发虚较清晰在CSS中全局设置-webkit-font-smoothing: antialiased;HighchartsLucida Grande, Lucida Sans Unicode, Verdana, Arial, Helvetica, sans-serif发虚发虚启用useHTML: true用DOM元素渲染文字牺牲部分性能终极方案实测有效/* 全局CSS */ .chart-container canvas { image-rendering: -webkit-optimize-contrast; image-rendering: crisp-edges; } /* 针对Highcharts */ .highcharts-container { font-family: SF Pro Display, Segoe UI, Microsoft YaHei, sans-serif !important; }并在Highcharts初始化时Highcharts.setOptions({ lang: { loading: 加载中... }, // 关键启用HTML渲染文本 plotOptions: { series: { dataLabels: { useHTML: true, style: { fontFamily: SF Pro Display, Segoe UI, sans-serif } } } } });3.3 坎三跨域图片资源——为什么你的自定义图标403了当你要用symbol: image://https://your-cdn.com/icon.png设置系列标记时浏览器会发起一个跨域图片请求。如果CDN未配置Access-Control-Allow-Origin: *Canvas会因安全策略拒绝绘制该图片图表直接空白。解决方案不是“配CORS”CDN配置常需运维介入周期长而是本地化代理// 使用ECharts的graphic元素替代image:// const customIcon new echarts.graphic.Image({ style: { image: /static/icons/custom-icon.png, // 本地静态资源 width: 20, height: 20 } }); // 在series中引用 series: [{ type: scatter, symbol: customIcon, data: [...] }]或者更通用的做法在构建阶段用Webpack的url-loader将小图标转为Base64内联// webpack.config.js { test: /\.(png|jpe?g|gif|svg)$/i, use: [ { loader: url-loader, options: { limit: 8192, // 小于8KB转base64 name: img/[name].[hash:8].[ext] } } ] }3.4 坎四移动端触摸交互——为什么你的缩放手势在iOS上失效iOS Safari对touchstart/touchmove事件有严格的“被动事件监听器”要求。如果库内部未正确设置{ passive: true }在iOS上滑动图表时页面会卡顿甚至无法滚动。验证方法在iOS Safari中打开DevTools需Mac Safari远程调试在Console执行// 检查是否存在非被动监听器 window.addEventListener(touchstart, () {}, { passive: false }); // 会报错我们发现Chart.js 3.x默认未设passive: true而ECharts 5.x和Highcharts 10.x均已修复。临时修复针对老版本// 在初始化图表前劫持addEventListener const originalAddEventListener EventTarget.prototype.addEventListener; EventTarget.prototype.addEventListener function(type, listener, options) { if (type touchstart || type touchmove) { options typeof options object ? { ...options, passive: true } : { passive: true }; } return originalAddEventListener.call(this, type, listener, options); };3.5 坎五SSR水合错位——为什么服务端渲染的图表客户端第一次渲染时“闪一下”这是React Server ComponentsRSC和Next.js App Router项目的经典问题。服务端渲染的HTML骨架与客户端首次useEffect中初始化的图表尺寸、坐标系、动画状态完全不一致导致视觉跳变。根本解法放弃“服务端渲染图表”改为“服务端渲染占位符客户端懒加载图表”。// 使用next/dynamic实现SSR安全 import dynamic from next/dynamic; const ChartComponent dynamic( () import(../components/MyECharts).then((mod) mod.MyECharts), { ssr: false, loading: () div classNameskeleton-chart / } ); export default function Dashboard() { return ( div h1实时监控/h1 ChartComponent data{serverData} / /div ); }同时在MyECharts.tsx中确保useEffect只在客户端执行useEffect(() { if (typeof window undefined) return; // 初始化ECharts }, []);3.6 坎六无障碍访问a11y——不只是“能读”而是“能操作”WCAG 2.1 AA标准要求所有交互式图表必须支持键盘导航Tab、屏幕阅读器描述ARIA、焦点管理。但多数库的a11y支持是“半成品”。ECharts提供aria配置项但需手动为每个series设置aria.description且不支持键盘缩放。Chart.js通过plugins.accessibility插件支持基础a11y但对复杂图表如雷达图支持弱。Highcharts原生支持最完善accessibility模块包含keyboardNavigation、pointNavigation、screenReaderSection且可配置liveRegion实时播报数据变化。实操配置Highchartsaccessibility: { enabled: true, keyboardNavigation: { enabled: true, focusBorder: { borderRadius: 4, color: #007bff, width: 2 } }, point: { valueDescriptionFormat: {value} {unit} on {date}, descriptionFormatter: function (point) { return ${point.series.name} at ${point.category}: ${point.y} units; } } }3.7 坎七国际化i18n——不只是翻译文字而是适配文化习惯lang配置看似简单但深坑在细节中文日期格式应为2024年3月15日而非Mar 15, 2024数字千分位分隔符中文用英文用,货币符号位置¥100 vs $100图表方向阿拉伯语RTL布局需整体镜像。Highcharts的lang配置最健壮它不仅翻译文字还内置了dateFormats和numericSymbolslang: { months: [一月, 二月, 三月, 四月, 五月, 六月, 七月, 八月, 九月, 十月, 十一月, 十二月], shortMonths: [1月, 2月, 3月, 4月, 5月, 6月, 7月, 8月, 9月, 10月, 11月, 12月], weekdays: [星期日, 星期一, 星期二, 星期三, 星期四, 星期五, 星期六], // 自动适配数字格式 numericSymbols: [万, 亿, 万亿] }而ECharts需配合formatter函数手动处理yAxis: { axisLabel: { formatter: (value) { if (value 10000) return ${(value / 10000).toFixed(1)}万; return value; } } }4. 实操过程与核心环节实现手把手复现一个“企业级”销售漏斗图光说不练假把式。下面我们以一个真实客户需求为例“在Web管理后台首页嵌入一个支持下钻、联动、导出的销售漏斗图数据来自MongoDB聚合管道前端用React 18 TypeScript”。我们将完整走一遍从数据获取、图表选型、配置编码到性能优化的全流程并对比ECharts、Highcharts、Plotly.js三种方案。4.1 步骤一数据准备——从MongoDB到前端可用的JSON假设MongoDB集合sales_pipeline结构如下{ _id: 65f1a2b3c4d5e6f7g8h9i0j1, stage: leads, count: 1250, conversionRate: 0.0, timestamp: 2024-03-15T00:00:00Z }我们需要聚合出各阶段人数及转化率// MongoDB 聚合管道Node.js后端 [ { $match: { timestamp: { $gte: ISODate(2024-03-01), $lt: ISODate(2024-04-01) } } }, { $group: { _id: $stage, total: { $sum: $count }, maxTimestamp: { $max: $timestamp } } }, { $sort: { _id: 1 } }, { $project: { stage: $_id, count: $total, _id: 0 } } ]返回数据格式[ {stage: leads, count: 1250}, {stage: qualified, count: 820}, {stage: proposal, count: 410}, {stage: negotiation, count: 205}, {stage: closed_won, count: 102} ]4.2 步骤二方案选型——为什么最终选定Highcharts我们快速搭建了三个DemoECharts方案用funnel图表配置label: { show: true, formatter: {b}: {c}}但发现tooltip无法显示“上一阶段人数”和“转化率”需自定义tooltip.formatter代码量激增。Plotly.js方案go.Funnel支持textinfo: labelvaluepercent initial但React封装plotly.js-react的useMemo缓存机制在数据更新时偶发Cannot read property length of undefined错误排查耗时2小时。Highcharts方案type: funnel原生支持dataLabels和tooltip.pointFormat: {point.name}: {point.y} ({point.percentage:.1f}%)且drilldown下钻API极其简洁drilldown: { series: [{ id: leads, name: 线索来源, data: [[官网, 620], [展会, 310], [广告, 320]] }] }决策依据Highcharts在“开箱即用性”和“企业级稳定性”上胜出。虽然ECharts生态更广Plotly.js分析能力更强但在这个具体需求上Highcharts用最少的代码实现了最稳定的效果。4.3 步骤三编码实现——一个可复用的Highcharts Funnel组件// components/SalesFunnelChart.tsx import React, { useRef, useEffect, useState } from react; import Highcharts from highcharts; import HighchartsReact from highcharts-react-official; import drilldown from highcharts/modules/drilldown; import accessibility from highcharts/modules/accessibility; // 初始化Highcharts模块 drilldown(Highcharts); accessibility(Highcharts); interface FunnelDataPoint { name: string; y: number; drilldown?: string; } interface DrilldownSeries { id: string; name: string; data: [string, number][]; } interface SalesFunnelProps { data: FunnelDataPoint[]; drilldownSeries: DrilldownSeries[]; onDrilldown?: (stage: string) void; } const SalesFunnelChart: React.FCSalesFunnelProps ({ data, drilldownSeries, onDrilldown }) { const chartRef useRefHighchartsReact.RefObject(null); const [options, setOptions] useStateHighcharts.Options({}); useEffect(() { // 构建Highcharts配置 const chartOptions: Highcharts.Options { chart: { type: funnel, height: 400, backgroundColor: transparent, // 关键禁用默认动画提升首次渲染速度 animation: false }, title: { text: 销售漏斗转化率, align: left, style: { fontSize: 16px, fontWeight: 600 } }, tooltip: { // 自定义tooltip显示转化率 pointFormat: b{point.name}/b: {point.y}人br/转化率: b{point.percentage:.1f}%/b }, plotOptions: { funnel: { dataLabels: { enabled: true, format: b{point.name}/bbr/ {point.y}人, distance: -30, style: { fontSize: 12px, fontWeight: normal } }, neckWidth: 20%, neckHeight: 10%, // 关键启用下钻 allowPointSelect: true, cursor: pointer, events: { click: function (e) { if (onDrilldown e.point.drilldown) { onDrilldown(e.point.drilldown); } } } } }, series: [{ name: 阶段人数, data: data.map((point, index) ({ ...point, // 计算转化率当前阶段/上一阶段 percentage: index 0 ? 100 : (point.y / data[index - 1].y) * 100 })) }], drilldown: { series: drilldownSeries }, accessibility: { enabled: true, keyboardNavigation: { enabled: true } } }; setOptions(chartOptions); }, [data, drilldownSeries, onDrilldown]); return ( div classNamesales-funnel-chart HighchartsReact ref{chartRef} highcharts{Highcharts} options{options} // 关键启用内存优化 constructorType{chart} callback{(chart) { // 图表初始化后手动触发一次resize解决容器宽高计算问题 setTimeout(() chart.reflow(), 100); }} / /div ); }; export default SalesFunnelChart;4.4 步骤四性能优化——从“能跑”到“丝滑”上线前压测发现当data数组长度超过50项时首次渲染耗时达1200ms。我们通过三步优化降至280ms禁用无用动画animation: false已在代码中体现延迟渲染用IntersectionObserver监听页面可见性仅当图表进入视口时才初始化数据采样对超大数据集前端做简单采样// utils/dataSampling.ts export function sampleDataT(data: T[], targetCount: number): T[] { if (data.length targetCount) return data; const step Math.floor(data.length / targetCount); return data.filter((_, index) index % step 0); }在组件中const sampledData useMemo(() sampleData(props.data, 20), [props.data]);4.5 步骤五导出与分享——不止是PNG更是业务语言客户要求“一键导出为PNG并附带当前筛选条件”。Highcharts的exporting模块完美支持exporting: { enabled: true, buttons: { contextButton: { menuItems: [downloadPNG, downloadPDF, separator, printChart] } }, // 关键自定义导出标题 filename: sales-funnel-${new Date().toISOString().slice(0, 10)}, // 添加水印 fallbackToExportServer: false, chartOptions: { title: { text: 销售漏斗 - 截至${new Date().toLocaleDateString(zh-CN)} } } }5. 常见问题与排查技巧实录那些让我凌晨三点还在改的Bug再完美的方案也会遇到意料之外的问题。以下是我在真实项目中记录的12个高频Bug及其根因、现象、解决方案。它们不来自文档而来自一次次console.log和debugger。5.1 Bug 1ECharts图表在Resize时“错位”坐标轴消失现象浏览器窗口大小改变后图表内容正常但X/Y轴刻度线、标签全部错位到左上角且chart.resize()调用无效。根因父容器CSS设置了display: flex但未给图表容器设置flex: 1或width: 100%导致ECharts计算容器宽度为0。解决方案.chart-container { display: flex; flex-direction: column; height: 100%; } #echarts-dom { flex: 1; /* 关键 */ width: 100%; height: 100%; }5.2 Bug 2Highcharts在React Strict Mode下报错“Cant perform a React state update on an unmounted component”现象在组件卸载后Highcharts的异步回调如chart.redraw()试图更新已销毁的React状态。根因Strict Mode会两次调用useEffect导致chart.destroy()被调用两次第二次时chart已为null。解决方案在useEffect清理函数中加判空useEffect(() { let chart: Highcharts.Chart | null null; // 初始化图表... return () { if (chart !chart.hasRendered) { chart.destroy(); chart null; } }; }, []);5.3 Bug 3Plotly.js的config.displayModeBar false不生效现象配置了displayModeBar: false但工具栏依然显示。根因Plotly.js的config对象必须在Plotly.newPlot()时传入不能在Plotly.relayout()中修改。解决方案// ✅ 正确 Plotly.newPlot(myDiv, data, layout, { displayModeBar: false }); // ❌ 错误 Plotly.newPlot(myDiv, data, layout); Plotly.relayout(myDiv, { displayModeBar: false }); // 无效5.4 Bug 4Chart.js饼图cutout属性在TypeScript中报错现象options.plugins.doughnut.cutout 60%TS提示Type 60% is not assignable to type number | undefined。根因types/chart.js定义过时cutout类型未更新。解决方案强制类型断言或升级types/chart.js到v3.3.0options: { plugins: { doughnut: { cutout: 60% as unknown as number // 临时方案 } } }5.5 Bug 5所有库在Safari 15.4上Tooltip显示位置偏移现象Tooltip始终出现在鼠标指针右下方50px处而非指针正上方。根因Safari 15.4的getBoundingClientRect()返回值存在偏差且event.clientX/Y计算不准确。解决方案重写Tooltip定位逻辑用pageX/Y替代clientX/Ytooltip: { positioner: function (labelWidth, labelHeight, point) { return { x: point.plotX this.chart.plotLeft - labelWidth / 2, y: point.plotY this.chart.plotTop - labelHeight - 10 }; } }5.6 Bug 6Highcharts导出PDF时中文乱码现象导出的PDF中中文全部显示为方块。根因Highcharts Export Server