反思一个问题：遇到bug之后
遇到bug 的心理。
1.怎么会有问题？beta都过了的啊
2.怎么会有问题？时而有时而无不科学啊？
3.应该不是代码问题吧？是前端node层过滤什么了呢？（开始调用前端配合查问题，这样做很有可能浪费一个人力）
3.如果node层没问题？curl正式机上也有数据？是商品xxx么？
4.确实频繁变价打回恢复了。但是另一个场次正常的商品，也是时有时无啊
5.得，打日志观察吧。避免无效日志打印，仅限填写的deviceid 打印日志。
ps.实际上没有上代码，大佬一听就知道是网关缓存问题。（所以，问最熟悉的人）
科学对待
分治思想
1.分人
划分清楚负责人。
划分清楚负责人后，划分可能出现问题的地方。
2.有效判断
避免过多猜测。避免浪费人力。
3.有效定位
直接去源头。
打日志。beta模拟。捋代码。
以下是文字demo。
1.如果很明显的判断出是自己的，那么就先从自己这边排查（避免无效的调用其他小伙伴排查。）
2.排查手段。线上接口由于经过网关经过node 层。
2.1优先上线上服务器通过curl 方式查看数据。（去最源头）
curl -x 'localhost:8080’ 'http://xxx.com/xxxx’ |jq ".data.xxx_list" | grep xxx
数据异常，那么从beta上测。
数据正常，那么打日志吧。然后进一步分析为什么c端看到为什么不正常。
3.避免猜测，如果变量多，猜来猜去，并不会有效定位。反而过多的浪费了时间。
