共计 1100 个字符，预计需要花费 3 分钟才能阅读完成。
【我的项目背景形容】
有一个表格，形容的是 Snapshot- 1 和 Snapshot- 2 之间的比照，数据比照的后果是由后端算进去的，前端只有负责渲染就能够。
后端返回的数据实质是一个“森林”，每棵“树”都是三层，别离是：type/ class name/ object name。因为每棵树的计算量比拟大，孩子节点也比拟多，所以在前端渲染的时候，应用懒加载做了优化，即只有当用户开展某层的时候才会 call 到后端申请数据。所以，页面第一次渲染的时候，显示的是森林里所有树的第一层。
除了页面的数据展现，Diff 表格还反对 csv download，因为 csv 须要拿到全量的比照数据，也就是整片森林，所以当用户点击 CSV 下载的时候，会先 call 后端拿到全量数据，再 csv format，最初输入。
【呈现问题】
有用户反馈说：CSV 下载等了良久都在 loading，问怎么回事？
【排查过程】
1. 前述环境
- 咱们有本地开发环境（对应本人本地的数据库，能够操作后端代码 and 前端代码）
- 用户呈现问题的是 prod 环境（本地的前端是无奈 call 到 prod 环境的 DB 的）
2. 找到瓶颈
- 关上用户的报告，的确数据量很大，点击 csv download，感觉下载一个 diff 文件，大略须要 30s 左右的工夫。也就是说代码逻辑没有问题，就是慢。
- 关上控制台，看数据返回工夫。其实工夫不是很长，只有 7s，因而，工夫的瓶颈不在这里。
- 接下来，就是看 api callback 外面的解决逻辑有什么能够优化的中央了。然而，如何拿到用户的数据呢？因为本地开发环境是没有方法连上 prod 的数据库的。
- 【解决方案】：能够在开发者模式下，拿到 api 返回的数据，并将其保留成 json，在前端代码里 import 进来进行解决。
- 然而，因为返回的后果过于宏大，response 无奈 load，“复制粘贴”的打算失败。
- 【解决方案】：右击 url，找到 Copy as cURL，并在命令的结尾加上“>> 1.txt”，能够将 response 后果间接输入到文件，而不是命令行，不便复制。
- 万事俱备，开始查看瓶颈。在 csv format 中的每个函数前面，console.log 一个工夫戳，便于查看到底哪里比拟耗时。最终发现，sort 函数占用了大量的工夫，因为有 2 层 for 循环。从新查看代码，其实 call 回来的 api 在后端解决的时候，其实曾经是排好程序的，因而，前端无需“多此一举”。
- 综上所述，删除前端 sort 函数即可。（省略后续测试步骤 ……）
【知识点回顾】
curl 是罕用的命令行工具，用来申请 Web 服务器。它的名字就是客户端（client）的 URL 工具的意思。有很多不同的命令行参数，不便开发者在 cmd 里申请 api。
正文完
