go 里面的 http response body 必须 close 是不是很不合理呀

[zihuyishi]

基本上每个新人写 http 请求都容易忘记这个，然后造成 goroutine 的泄漏。所以 http 请求基本都要实现一个 util 避免这种事情。
然后就是 close 在 Response.Body 上而不是 Response 本身，直觉上 close response 更符合普遍的逻辑吧。虽然可以理解是因为 body 和 response 生命周期不一样，但是用起来还是感觉不太协调

[BBCCBB]

response 和 body 是不同的资源吧, java 里 body 是 inputStream. 拿到后也是要 close 的. body close 后, response 依然可以用.
body close 只代表你把响应里的 body 读取完了.. 但 response 里还有其他信息可以继续读的, cookie, header

[tyrantZhao]

读一个 body 肯定要关，跟 http 没啥关系。

[mainjzb]

老忘记的话，可以自己封装一层 http 请求。
不这么设计的话，chunked 编码下容易遇到问题。

[777777]

有 timeout 自动会帮你关

[guanzhangzhang]

那用 head 请求呗

[mainjzb]

楼主可能没有视频开发的经验
以 b 站直播为例，打开 F12 可以发现 bilivideo.com 的请求在一直拉数据。如果客户端发生错误，可以调用 body close()主动关闭请求。例如检测到长时间无人操作关闭连接节约流量。 或者检测到浏览器缩小化，关闭画面，只拉声音，降低服务器负载。

[Mohanson]

哈哈, 看了这个帖子发现前几天写的一段代码忘记关闭 Body 了

[AoEiuV020JP]

高级一点的现代语言都有封装一些方便的方法，比如直接把 body 完整读取转成字符串并 close ，但 go 给人感觉就是现代语言却要对标上古 c/c++，这种细节小麻烦在 c/c++就是理所当然没什么不合理，

[flyv2x]

确实因为没有 close 的问题，压测发现 bug 找了一下午，火大

[zihuyishi]

@tyrantZhao go 的问题在于你不读这个 body 也要 close ，然后很多时候不读就忘记了 close 。所以普通的请求都要自己套一层实现

[zihuyishi]

@777777 golang 里不会关吧，而且他这个 body 你不读他也要关。他底层还关系到了很多 goroutine,所以经常 pprof 跑一下发现一堆 goroutine 在那里持续了几天

[lvlongxiang199]

@AoEiuV020JP 如果是个文件呢 ? 直接读到内存里, 没准会 OOM

[DefoliationM]

不然自动关了全读内存里存着？不合理呀。

[mainjzb]

理论上确实应该设计成 close response ，和文件 api 统一风格更合理。
但是短期来看没希望了。response 已经有一个 Colse 变量了。无法再创建 Close 方法。

[sujin190]

body 是流式传输吧，有最大缓冲区，超过了就不会继续下载读取

[GooMS]

我觉得要关闭更好，好控制

[seers]

已经习惯性 defer 了，还好

[jinliming2]

@AoEiuV020JP #8 能流式操作的不建议完整读取，还转字符串。性能会差，内存会炸。
除非预先知道 body 大小足够小，或者是无法流式处理操作。

[jim9606]

go 没有 using 语法糖，所以还是 defer 吧，我看 open 之后马上 defer close 还挺常见的。

[flyqie]

其实，主要是 go 不太甜的原因。。