如果你计划构建一个正式的应用程序，那么在你开始寻找一个图表库之前，你需要知道创建好的数据可视化是一个极大的时间投资。对于数据可视化你究竟要实现哪些功能，将在哪些设备上使用，以及你有多长时间来构建应用程序等问题有明确的答案，将帮助对下述指南物尽其用。
跨浏览器兼容性
无论你是需要一个图表库，兼容所有浏览器兼容，还是只兼容现代浏览器，这取决于你的目标受众。如果你是为政府或企业用户构建应用程序的话，那么他们很有可能仍然在用旧版本的 IE。所以说，那些仅能在现代浏览器内工作的图表库可能不是一个好的选择。
处理跨浏览器的兼容性问题是非常痛苦的，我认为你选择的库应该帮你解决这事。
跨设备兼容性
你的应用程序主要使用在桌面，或者说你针对手机用户吗？如果只是为了大屏浏览，那么大多数图表库可用于你的可视化；但如果你想确保在手持设备一致的体验，你选择的图表库应该为你负责。最近，改变用户习惯变得越来越重要。
输入数据格式
虽然 JSON 正逐渐成为标准格式，尤其是涉及到图表库时，但仍有很多情况，你不得不处理 XML。如果你的可视化需要 XML 格式的数据，那就得了解你的图表库是否支持 XML 了。
可定制性
可定制性，至少对于我来说，是最大的决定因素。图表库是足够灵活，以便我能做我想做的事，还是在默认情况下看起来很好，定制仍需“自己动手，丰衣足食”呢？
我喜欢玩弄数以百计的东西，如添加自定义形状、配置图例、附加事件（点击、悬停、按键），利用数据钻取（drill-down of data），以及应用主题等。如果你想创建一个漂亮的设计，有一个容易定制的库将是很好的，这样你可以根据你应用程序的设计去改造。
可用图表的范围
这是一个无需用脑的事。无论你想要创建怎样的可视化，它都应该是库中的一部分。但是对于各种包含集体包（collective packages）的图库来说，将不是那么容易，它们将类似的图表组在一起，如地图（maps），小工具（widgets）和股票图（stock charts）。因此，根据不同的使用场景，你可能只想要一个特定类型的图表， 或者得到一个完整的包。
如果你想要根据可用的图表范围比较不同的图库的话，你会发现这个资源会很有帮助。
学习曲线
一些可视化库，如D3.js，有一个陡峭的学习曲线。毫无疑问D3.js是非常强大的，但如果你时间紧迫或者第一次用，我不推荐它。
换句话说，如果你刚开始做数据可视化且有大量的时间去尝试，那么你应该全力去尝试那些漂亮但需要时间投资的库。
与其他代码的兼容性
假想你是一个对 JavaScript 不太熟悉的 PHP 或 ASP.NET 战神，如果你可以不写任何 JavaScript 代码创建图表，岂不妙哉？一些库有免费的插件和封装器，帮你生成在浏览器页面上渲染图表所需的 JavaScript 和 HTML 代码。例子：FusionCharts Extensions 和 Highcharts extension。
性能
性能取决于很多因素，如库的大小，渲染时内存使用量，垃圾回收以及浏览器重绘的时钟周期数。我非常看重性能，但仅为性能的优化并不总是好的想法。这听起来似乎自相矛盾，所以让我用一个例子来解释一下我的观点。
假设你将构建一个用于局域网的仪表板（dashboard）：你认为在这种情况下，使用一个最小的库有意义吗？在这种情况下，我会选择一个基于这里讨论的其他因素最好的库。节省库的大小，将是我最不关心的事。
导出
这一点不适用于所有使用场景，但仅适用于像报告和仪表板（dashboard）这样的情况。如果你为商业用户构建一个仪表板，那么你的用户可能会希望将图表导出到PDF或者图片。你选择支持开箱即用的导出功能的图表库会更好。常见的导出格式有JPEG、PNG、PDF 还有 SVG。
设计与交互
设计不仅仅是一个图表的外观，它不仅应该好看（主题、配色），而且应该有好的交互。比如，如果你创建一个扇形图，那么在默认情况下，当你点击一个扇形区域时，该区域应该被拉出来（或在其圆周上添加边框）。不应该需要自定义代码。在多序列折线图（multi-series line chart）上，点击一个图例图标时，应该切换相关数据图。
定价和许可条款
现在，当你购买一个许可证后，绝大多数的库会分发它们的源代码，但这并不意味着你可以自由地做任何你想做的。重要的是要知道你项目所需的所有权限和购买相关许可证。条款和定价取决于像用户数量，应用类型（SaaS，intranet，web）和服务器数量等因素。
支持
当你构建一个应用程序时，数据可视化可能不是你的核心力量。所以当你遇到一个问题时，你可能需要借助外面的支持来解决它。支持可以来自多种形式，如个人、论坛或者社区，如 StackOverflow。如果你日程很紧，等不了 StackOverflow的答案，那么在这种情况下，个人支持或专门的论坛将是非常有用的。
就流行的库而言，大多数常见问题的答案都是很容易获得的。但是我在测试边缘多次遇到死角。如果你认为你可能需要专门的支持的话，那么我推荐你购买一个图表组件，而非使用一个开源的解决方案（即便它满足所有其他的需求）。
开源
我热衷于开源，但我相信它不是一切问题的正确的解决方案。特别是它涉及到图表的解决方案时，GitHub上有成千上万小的、开源库。但你尝试在项目中使用其中的一个之前需小心谨慎。
我一个朋友，因为他喜欢的几个功能，曾经在他的商业项目中使用过一个小开源库。 一年后，当他试图实现一些高级功能时，他卡住了。当他试图联系库的创建者时，他才知道这个项目早已被丢弃了。我确信这不会发生在大的开源库上，如D3.js、Google Charts，morris.js，但最好是考虑这种可能性，而不是后面后悔。
这有一篇文章回答了何时一个商业库比一个开源库更有意义。
为了做出明智的选择，我认为知道所有这些因素是重要的。如果你认为我错过了一些因素，请在评论中提到它们。
— Merrily
Vikas，你谈及了很多重要的点 ，都考虑得不错。还有一个要考虑的是，数据点的个数以及图表的个数。一个库能支撑大量数据点且保持项目所需的交互功能吗？当一个页面上有多个图表时，性能又怎样呢？
你也提到了交互功能。虽然从图例切换数据集，点击移动扇形分片，以及深入到图表的能力是非常重要的，但在实际应用中，这些功能都是相当基础的。要记住对于数据可视化应用，考虑真正发挥客户端交互性的交互，如批注（annotations）和操作数据集，也是非常重要的。
— Merrily
