现在有个订单表单布局如下
头部和明细的组合布局，现在出现的问题是明细加载很慢，前端用的是layui实现的，因为form初始化和table都是异步加载，通过谷歌的开发者工具查看页面加载的过程发现明细的异步加载需要10秒以上，尽管后端加了redis缓存，前端的效率还是上不去，开始以为是数据库查询太慢了，不过通过后台执行查询SQL语句，发现并不慢1秒就完成了，那是什么原因呢？！
首先，还是从前端加载开始分析，开始总是盯着明细的异步加载慢的优化，一直改善不了，包括IIS服务器的应用程序池的最大进程数量的调整，提高并发的响应速度，调整了，有效果但是不明显。
然后，开始查看页面的加载顺序，发现了一个比明细加载还慢的异步请求，如图
这个getEntity的异步请求7秒多，比明细加载还慢，于是追查下去发现这个请求了一个跨数据库的查询24万条记录的视图，查询很慢，于是初步分析判断是不是因为这个查询慢的异步请求在明细异步请求getList之前导致，明细的请求被后台数据库处理堵塞在了慢查询的后面等待队列中，导致整个明细查询结果返回慢，于是将慢查询的getEntity放在table明细的异步加载成功后再处理，是不是会提高加载速度？！于是调整了顺序，如上图所示，结果560ms就加载完明细了！尽管getEntiy还是7秒多，但是不影响整体页面呈现效果了！
下一步就是对getEntity整个慢查询的优化了。
总结，现在前端如果响应慢很多时候总是固化的思维模式“哪慢查哪的问题”这么来解决问题，对于常规的问题的确可以找到问题原因，但是特殊情况会如这个问题一样，很多因素导致加载慢的问题出现，这样往往忽略了问题的真正根源在哪？需要跳出固化思维从全局来看待，这才是更好的解决思路！