问题现象： 对于测试报告，我们一般应当包含：测试对比环境的软件架构、输入、可视化的对比结果、原因分析&总结
从go 自带的profile 图 只能看出 如题所示，对于问题排查，我们从不吝啬更多信息 用于分析： 结合 sys-cpu perf 以及 火焰图分析：可以得到更多的调用栈 对比的两个软件 V1 有问题 、V2 没有问题。 这里看出有问题的 是Read 场景：Read 触发的调度。我们的测试场景是代理和源站在同一个集群，确实会存在大量Read event 唤醒，但是线上 回源响应的数据 以及并发协程数不是更多吗？
https://github.com/golang/go/issues/18237 https://groups.google.com/g/golang-nuts/c/6zKXeCoT2LM
V2 有个重要的机制是Read 源站 和响应客户端做了流式控制，V1 没有 也就是说触发Read 调用频率更低（我们可以动态追踪对比V2 和 V1 的read频度），所以没有问题（后面随着并发连接数 提升 V2也出现了一样的问题）V1 并发1000 就出问题了。把流式buffer 调大 发现V2 也出现和V1 一样的问题了。
为什么线上不会出现？ 用C 做的代理也会存在问题吗？ 代理和源站不在同一个集群会出问题吗？go 的runtime 调度还需要深入研究加粗样式
