ทีมที่ใช้ Go เรียก API แล้วสนใจแค่ status code มักปิด response body โดยไม่ได้อ่านให้หมด บทความของทีม Go วันที่ 14 ตุลาคม 2026 อธิบายว่า Go 1.27 ช่วยนำ connection ของ HTTP/1 กลับมาใช้ในกรณีนี้ได้มากขึ้น ข่าวนี้เป็นคำอธิบายพฤติกรรมที่มีในรุ่น 1.27 แล้ว ไม่ใช่การเปิดตัวรุ่นใหม่วันที่ 14 ตุลาคม

เมื่อเรียก resp.Body.Close() ตัว net/http.Transport จะพยายามอ่านส่วนที่เหลือทิ้งเบื้องหลัง โดยจำกัดไว้ที่ 50 มิลลิวินาทีหรือ 256 KB ตามบทความต้นทาง ถ้ามี Connection: close ก็ข้ามงานนี้ เพราะ connection นั้นนำกลับมาใช้ไม่ได้อยู่แล้ว การปิด body จึงยังจำเป็น แต่หลายโปรแกรมไม่ต้องเขียนตัวช่วย drain เอง

ตัวเลขบนปกบอกอะไร

Nicholas Husin และ Damien Neil รายงานผลเรียก GET ไปยัง index.golang.org ต่อเนื่อง 100 ครั้ง โดยฟังก์ชันอ่านเฉพาะ status แล้วปิด body: Go 1.26 ใช้เวลาประมาณ 710 ms ส่วน Go 1.27 ประมาณ 150 ms บนเครื่องของผู้เขียน กรณีนี้ปิด HTTP/2 ด้วย GODEBUG=http2client=0 จึงไม่ใช่ผลทดสอบ HTTP/2 หรือคำรับรองว่าแอปทุกตัวจะเร็วขึ้นเท่ากัน กราฟปกวาดใหม่จากตัวเลขนี้; ReefSight ไม่ได้รัน benchmark เพิ่ม

โค้ดแบบไหนควรกลับไปดู

สิ่งที่แอปทำสิ่งที่ควรตรวจ
อ่านเฉพาะ status หรืออ่าน body ไม่หมดบน HTTP/1ยังคงปิด body ทุกครั้ง; เมื่อใช้ Go 1.27 ให้ประเมินว่าตัวช่วย drain เดิมยังจำเป็นหรือไม่
รับ body ใหญ่หรือข้อมูลไหลช้าการอ่านทิ้งมีเพดาน จึงไม่รับประกันว่าจะใช้ connection เดิมได้ทุกครั้ง
ใช้ HTTP/2กลไก multiplex ต่างจาก HTTP/1 อย่านำผลวัดบนปกไปสรุปแทน

ก่อนตัดตัวช่วยเดิมออก ให้ตรวจ Go รุ่นที่ใช้จริงและทดสอบกับ API ของทีม หากมี custom transport หรือโค้ดที่พึ่งพาพฤติกรรมการปิด body ให้ตรวจส่วนนี้แยกด้วย ดูสัญญาของ Response.Body และ Transport ใน เอกสาร net/http สำหรับ Go 1.27.2

Release notes ของ Go 1.27 ยังเตือนว่าโปรแกรมที่ปล่อย idle connection ค้างมากเกินไปอาจมีประสิทธิภาพลดลงในบางกรณี จึงควรดูการใช้ client/transport และจำนวน connection ควบคู่กับเวลาเรียก API ก่อนปรับระบบจริง