最简 GET 请求需用带 Timeout 的 http.Client 并 defer resp.Body.Close()，检查 StatusCode 后再 JSON 解析；认证请求须安全管理 Token 并过滤日志敏感头；POST 时注意结构体 json tag 映射与零值处理；错误处理要区分网络错误、HTTP 状态码和业务错误。
用 net/http 发起最简 GET 请求调用第三方 API
Go 原生 net/http 足够可靠，无需额外 SDK 就能完成绝大多数第三方 API 调用。关键不是“能不能”，而是怎么避免超时、连接泄漏和 JSON 解析 panic。
- 必须显式设置
http.Client的Timeout，否则默认无超时，请求可能永久挂起 - 别直接用
http.Get()—— 它返回的*http.Response.Body必须手动Close()，漏掉会积累文件描述符泄漏 - 用
json.Unmarshal()前先检查response.StatusCode，4xx/5xx 响应体也可能是 JSON 错误，直接解析会掩盖真实问题
示例：
client := &http.Client{Timeout: 10 * time.Second}
resp, err := client.Get("https://api.example.com/data")
if err != nil {
return err
}
defer resp.Body.Close() // 必须 defer
if resp.StatusCode != http.StatusOK {
return fmt.Errorf("API error: %d", resp.StatusCode)
}
var data map[string]interface{}
if err := json.NewDecoder(resp.Body).Decode(&data); err != nil {
return err
}
处理需要 Token 或自定义 Header 的认证型 API
多数第三方服务（如 Stripe、GitHub、Auth0）要求在 Authorization 或 X-API-Key 中传凭证。Header 设置本身简单，但容易忽略两点：Token 过期重试逻辑、敏感信息泄露风险。
- 不要把 Token 硬编码在代码里，从环境变量（
os.Getenv("API_TOKEN")）或配置文件读取 - 若 Token 有有效期，别在每次请求前都去刷新——应在首次失败且错误含
"invalid_token"时才触发刷新，并缓存新 Token - 调试时打印完整请求头？小心日志里意外输出
Authorization: Bearer xxx—— 日志中应过滤掉敏感 header
设置方式：
立即学习“go语言免费学习笔记（深入）”；
req, _ := http.NewRequest("GET", "https://api.example.com/private", nil)
req.Header.Set("Authorization", "Bearer "+token)
req.Header.Set("User-Agent", "myapp/1.0")
resp, err := client.Do(req)
POST JSON 数据并正确处理响应结构
第三方 API 接收参数常用 JSON body，但 Go 的 json.Marshal() 默认不处理零值字段，而有些 API 要求显式传 null 或空字符串。同时，响应结构体字段名映射稍不注意就解不出数据。
本文档主要讲述的是Android如何使用WebService接口；WebService是一种基于SOAP协议的远程调用标准。通过WebService可以将不同操作系统平台，不同语言、不同技术整合到一起。在OPhone SDK中并没有提供调用WebService的库，因此，需要使用第三方类库（KSOAP2）来调用WebService。在本文将介绍在OPhone中调用WebService的具体细节，并在最后给出一个完整的例子来演示如何使用KSOAP2来调用WebService。感兴趣的朋友可以过来看看
- 用
omitempty标签要谨慎：如果 API 要求字段存在（哪怕为空），就得去掉该 tag - 响应字段名常为
snake_case（如user_id），Go 结构体字段需用json:"user_id"显式绑定 - 别用
map[string]interface{}解析嵌套响应——类型丢失、易出错；优先定义结构体，哪怕只用一次
示例结构体定义：
type CreateUserReq struct {
Name string `json:"name"`
Email string `json:"email"`
Role string `json:"role,omitempty"` // 仅当有值才发
}
type CreateUserResp struct {
ID int json:"id"
UserID string json:"user_id" // 注意下划线映射
CreatedAt string json:"created_at"
}
错误处理不能只看 HTTP 状态码
HTTP 200 不代表业务成功，很多 API 在 body 里用 {"success": false, "error": "..."} 包装结果。只检查 status code 会漏掉这类“伪成功”响应。
- 统一约定：所有 API 响应先解析顶层 JSON，检查是否存在
error、code或success字段 - 网络错误（
net.OpError）、TLS 握手失败、DNS 解析失败等，需和业务错误区分对待——前者可重试，后者重试无意义 - 对频繁失败的 API，加简单计数器 + 指数退避，避免雪崩式重试压垮自己或对方服务
关键判断点：
if resp.StatusCode >= 400 {
// 先读 body，再决定是网络层错误还是业务错误
body, _ := io.ReadAll(resp.Body)
var apiErr struct{ Error string `json:"error"` }
if json.Unmarshal(body, &apiErr) == nil && apiErr.Error != "" {
return errors.New(apiErr.Error)
}
}
真正麻烦的从来不是“怎么发请求”，而是怎么让失败变得可观察、可恢复、不传染。比如一个上游 API 响应慢了 3 秒，是否拖垮你整个 HTTP handler？要不要熔断？这些得在第一次集成时就想清楚，而不是上线后被报警叫醒。
