Go 中 http.Post 接收 io.Reader 类型的请求体，而 *os.File 确实实现了该接口；但若未显式设置 Content-Length，部分服务端（如 requestb.in）会忽略无长度声明的流式请求体，导致接收 0 字节。
go 中 `http.post` 接收 `io.reader` 类型的请求体，而 `*os.file` 确实实现了该接口；但若未显式设置 `content-length`，部分服务端（如 requestb.in）会忽略无长度声明的流式请求体，导致接收 0 字节。
在 Go 的 HTTP 客户端中，将文件直接作为请求体看似合理：*os.File 满足 io.Reader 接口，http.Post 函数也接受该类型参数。然而，实际运行时服务端却收不到任何数据——根本原因不在于 Go 的实现缺陷，而在于 HTTP 协议层对请求体长度的语义要求 与某些服务端的严格校验逻辑。
标准 HTTP/1.1 规范允许两种方式传递消息体：通过 Content-Length 头明确声明字节数，或使用 Transfer-Encoding: chunked 进行分块传输。http.Post 内部调用 http.DefaultClient.Do 时，若传入的 io.Reader 不是已知长度类型（如 []byte、strings.Reader 或实现了 io.Seeker 且可 Stat() 的文件），则默认不设置 Content-Length，也不启用分块编码，最终发出一个既无长度头、也无分块标记的请求体。此时，像 requestb.in 这类轻量级调试服务端会选择静默丢弃请求体，仅处理头部，造成“发送成功但服务端收不到内容”的假象。
✅ 正确做法是绕过 http.Post 的便捷封装，改用 http.NewRequest 手动构造请求，并显式设置 ContentLength：
package main
import (
"fmt"
"net/http"
"os"
)
func main() {
file, err := os.Open("lala.txt")
if err != nil {
fmt.Printf("file open error: %v\n", err)
return
}
defer file.Close()
// 获取文件大小，用于设置 Content-Length
stat, err := file.Stat()
if err != nil {
fmt.Printf("stat error: %v\n", err)
return
}
req, err := http.NewRequest("POST", "http://requestb.in/1fry3jy1", file)
if err != nil {
fmt.Printf("request creation error: %v\n", err)
return
}
req.Header.Set("Content-Type", "text/plain")
req.ContentLength = stat.Size() // 关键：显式声明长度
client := http.DefaultClient
resp, err := client.Do(req)
if err != nil {
fmt.Printf("HTTP request error: %v\n", err)
return
}
defer resp.Body.Close()
fmt.Printf("Response status: %d\n", resp.StatusCode)
}⚠️ 注意事项：
- req.ContentLength 必须在 client.Do(req) 前赋值，且值需为非负整数；
- 若文件过大无法全部加载到内存，此方案仍保持流式上传优势，无需 ioutil.ReadAll 或 bytes.Buffer 缓存；
- os.File 支持 Stat()，因此可安全获取长度；但若使用其他 io.Reader（如 os.PipeReader、网络流），则需预估长度或改用分块编码（需自定义 Request.Body 并设置 TransferEncoding）；
- 生产环境建议使用更健壮的调试服务（如 https://httpbin.org/post），它支持并回显任意请求体，便于验证。
总结：Go 的 HTTP 客户端设计遵循协议规范而非“自动适配”，直接传入文件句柄本身没有问题，但服务端是否接收取决于是否提供可推断的消息体边界信息。显式设置 Content-Length 是最简单、兼容性最好的解决方案，兼顾效率与可靠性。
