Body io.ReadCloser
The http Client and Transport guarantee that Body is always non-nil, even on
responses without a body or responses with a zero-length body. It is the caller's
responsibility to close Body. The default HTTP client's Transport does not attempt to
reuse HTTP/1.0 or HTTP/1.1 TCP connections ("keep-alive") unless the Body is read to
completion and is closed.
http客戶端(Client)和傳輸(Transport)保證響應(yīng)體總是非空的，即使響應(yīng)沒有響應(yīng)體或0長響應(yīng)
體瞒大。關(guān)閉響應(yīng)體是調(diào)用者的責(zé)任系洛。默認(rèn)http客戶端傳輸(Transport)不會嘗試復(fù)用keep-alive的
http/1.0俊性、http/1.1連接，除非請求體已被完全讀出而且被關(guān)閉了描扯。
以上是http包文檔說明磅废。但是為什么body需要被關(guān)閉呢，不關(guān)閉會如何荆烈？那就讀源碼唄。
要了解body竟趾，首先要了解http事務(wù)是如何處理的憔购。http事務(wù)是交由底層的Transport處理的。
第一步是從連接池獲取一個連接岔帽，這個連接的功能由3個goroutine協(xié)同實現(xiàn)玫鸟，一個主goroutine，一個readLoop犀勒，一個writeLoop屎飘，后兩個goroutine生命周期和連接一致。雖說readLoop和writeLoop名字叫循環(huán)（也確實是for循環(huán)）贾费，但實際上一次循環(huán)就完整處理一個http事務(wù)钦购，循環(huán)本身僅僅是為了連接復(fù)用，所以為了便于理解其邏輯可以忽略它的循環(huán)結(jié)構(gòu)褂萧。
接下來三個goroutine協(xié)同完成http事務(wù)：
- 主goroutine將request同時發(fā)給readLoop和writeLoop押桃。
- writeLoop發(fā)送request，然后將狀態(tài)（error）發(fā)送給主goroutine和readLoop导犹。
- readLoop解析頭部response唱凯，然后將狀態(tài)（error）和response發(fā)送給主goroutine。
- 主goroutine返回用戶代碼谎痢，readLoop等待body讀取完成磕昼。
- readLoop回收連接。
了解http事務(wù)的處理流程节猿，然后我們回過頭來看看神秘的body到底是什么
//源碼版本1.8.3
// src/net/http/transfer.go:405 body解析方法
func readTransfer(msg interface{}, r *bufio.Reader) (err error)
// src/net/http/transfer.go:485 解析chunked
t.Body = &body{src: internal.NewChunkedReader(r), hdr: msg, r: r, closing: t.Close}
// src/net/http/transfer.go:490 產(chǎn)生eof
t.Body = &body{src: io.LimitReader(r, realLength), closing: t.Close}
// src/net/http/transport.go:1560 發(fā)送eof信號
body := &bodyEOFSignal{
// src/net/http/transport.go:1583 gzip解碼
resp.Body = &gzipReader{body: body}
body實際上是一個嵌套了多層的net.TCPConn：
- bufio.Reader票从，這層嘗試將多次小的讀操作替換為一次大的讀操作，減少系統(tǒng)調(diào)用的次數(shù)，提高性能纫骑；
- io.LimitedReader蝎亚，tcp連接在讀取完body后不會關(guān)閉，繼續(xù)讀會導(dǎo)致阻塞先馆，所以需要LimitedReader在body讀完后發(fā)出eof終止讀确⒖颉；
- chunkedReader煤墙，解析chunked格式編碼（如果不是chunked略過）梅惯；
- bodyEOFSignal，在讀到eof仿野，或者是提前關(guān)閉body時會對readLoop發(fā)出回收連接的通知铣减；
- gzipReader，解析gzip壓縮（如果不是gizp壓縮略過）脚作；
從上面可以看出如果body既沒有被完全讀取葫哗，也沒有被關(guān)閉，那么這次http事務(wù)就沒有完成球涛，除非連接因超時終止了劣针，否則相關(guān)資源無法被回收。
如果請求頭或響應(yīng)頭指明Connection: close呢亿扁？還是無法回收捺典，因為close表示在http事務(wù)完成后斷開連接，而事務(wù)尚未完成自然不會斷開从祝，更不會回收襟己。
從實現(xiàn)上看只要body被讀完，連接就能被回收牍陌，只有需要拋棄body時才需要close擎浴，似乎不關(guān)閉也可以。但那些正常情況能讀完的body毒涧，即第一種情況退客，在出現(xiàn)錯誤時就不會被讀完，即轉(zhuǎn)為第二種情況链嘀。而分情況處理則增加了維護(hù)者的心智負(fù)擔(dān)萌狂，所以始終close body是最佳選擇。
