记一次go耗时操作的查询实战。
背景：
处于php to go的过程，有些接口迁移到go服务里面去了。目前我们的流量转发是在应用层做的转发，这样其实是不好的。回归正传，最近上了个接口，功能很简单，取一组id，过滤，组成count个再返回，count是前端传来的，可以理解为一页的个数。但是有个特别的对方，就是过滤这个条件，会导致数据需要多次循环去凑够这个count，开发中就意料到这种很危险了，没想到果然在意料中，上了线后还是出现问题了。
现象：
在app上调用这个接口时，发现数据没有更新。抓包请求发现接口报400，然后去查询了php的日志，发现php调用这个接口报了读写超时的错误。检查了php配置文件后，发现超时时间设置的是1.5秒，已经很高了，由此断定了这个接口有问题。但是由于对自己的自信，觉得没什么问题，然后就直接调go服务的接口，去复现，证明自己没有问题。打脸的是复现了，这时候还是觉得调别人的东西慢，但是看了半天代码，也没发现有什么问题。
排查：
开始尝试使用pprof查看代码。之前写过一篇pprof的基础篇，链接如下：
https://blog.csdn.net/qq_28119741/article/details/109711641
已经讲的很清楚了，说几个问题
1.可以远程执行go tool pprof 去采集对应的远程服务
go tool pprof 'http://url/debug/pprof/profile'
2.可以不在远程服务器上安装graphviz，在本机上安装，然后在远程服务器上开启go tool pprof服务端，即可以在本机浏览器上查看。
go tool pprof -http=0.0.0.0:8090 ?pprof.server.samples.cpu.001.pb.gz
本次我是在测试机上采集的远程服务，然后在测试机上安装的graphviz，然后开启的pprof服务端，然后在本机上浏览器远程访问测试机。（主要是本机上安装不上graphviz）
下面直接展示采样数据
list 函数名后，产生如下数据
可以看出来，确实死循环了。知道问题在哪了，就认命吧，分析一下代码。在list 函数名时，遇到一个问题，就是找源码的路径不对，这个我查了下，大概会在执行go tool pprof命令的路径找，所以可以把包拷到项目里执行go tool pprof。在执行list? func 就没这个问题了。
主要是测试环境不好复现，并发的情况下会出现这个问题。所以说不要以为测试环境不能复现，就觉得没有问题，毕竟和线上总是会有些差异的。
结论：问题原因找到了，还是自己写的有问题，同时代码边界也没考虑全（其实这个也不算根本原因吧），吃一堑长一智吧。要考虑周全。