Go语言发送HTTP POST请求最常用net/http包的http.Post或http.Client.Do方法;前者适合简单表单,后者支持自定义头、超时等;上传文件需用multipart.Writer构造请求体;响应需关闭Body并检查状态码与错误。
Go 语言中发送 HTTP POST 请求最常用的方式是使用 net/http 包的 http.Post 或更灵活的 http.Client.Do 方法。前者适合简单场景,后者更适合控制请求头、超时、认证等细节。
适用于向服务器提交 application/x-www-form-urlencoded 类型的数据(如登录表单)。
http.Post(url, contentType, body),其中 body 需为 io.Reader 类型strings.NewReader 包装 URL 编码后的字符串Content-Type 头(http.Post 不自动设,需手动或改用 http.NewRequest)示例:
resp, err := http.Post("https://www./link/dc076eb055ef5f8a60a41b6195e9f329", "application/x-www-form-urlencoded",
strings.NewReader("name=alice&age=30"))
if err != nil {
log.Fatal(err)
}
defer resp.Body.Close()
body, _ := io.ReadAll(resp.Body)
fmt.Println(string(body))这是更推荐的方式,尤其在需要自定义请求头(如 Authorization、Accept)、设置超时、复用连接时。
json.Marshal 序列化结构体或 mapbytes.NewReader 将 JSON 字节切片转为 io.Reader
http.NewRequest 创建请求,再手动设置 Content-Type: application/json
http.Client(可设超时)调用 Do
示例:
data := map[string]string{"title": "Hello", "content": "World"}
jsonBytes, _ := json.Marshal(data)
req, _ := http.NewRequest("POST", "https://www./link/dc076eb055ef5f8a60a41b6195e9f329", bytes.NewReader(jsonBytes))
req.Header.Set("Content-Type", "application/json")
req.Header.Set("User-Agent", "MyApp/1.0")
client := &http.Client{Timeout: 10 * time.Second}
resp, err := client.Do(req)
if err != nil {
log.Fatal(err)
}
defer resp.Body.Close(
)
当需要同时传文本字段和文件时,必须构造 multipart 请求体。
multipart.Writer 创建请求体,它会自动生成边界(boundary)和对应头w.WriteField 添加普通字段,w.CreateFormFile 添加文件字段w 的输出作为请求 body,并设置 Content-Type 为 w.FormDataContentType()
示例(仅传文本字段,模拟表单):
body := &bytes.Buffer{}
w := multipart.NewWriter(body)
w.WriteField("username", "bob")
w.WriteField("email", "bob@example.com")
w.Close()
req, _ := http.NewRequest("POST", "https://www./link/dc076eb055ef5f8a60a41b6195e9f329", body)
req.Header.Set("Content-Type", w.FormDataContentType())
resp, _ := http.DefaultClient.Do(req)
无论哪种方式,响应处理逻辑一致,但容易忽略几个关键点:
resp.Body.Close(),否则可能造成连接泄漏resp.StatusCode,2xx 不一定代表业务成功(比如 400 可能返回 JSON 错误信息)io.ReadAll 读取完整响应体,避免只读前几字节导致 body 未关闭Do 阶段;服务端返回错误状态码属于正常响应,需业务判断基本上就这些。不复杂但容易忽略细节,尤其是超时控制和资源释放。