最简 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
<p>if resp.StatusCode != http.StatusOK {
return fmt.Errorf("API error: %d", resp.StatusCode)
}</p><p>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语言免费学习笔记（深入）”；
Git post-commit 钩子 + SQLite 提交索引工具。自动将每次提交的元数据（哈希值、作者、分支、仓库、主题）记录到本地 SQLite 数据库中，随后提供一个命令行接口（CLI），支持查询、列表展示、统计、删除和更新记录。 触发场景：管理 Git 钩子、跨仓库查询提交历史、定位某次提交所属的仓库、查看提交统计信息、将提交记录写入本地索引。 当用户提及“提交日志记录”、“提交索引”、“跨仓库查找提交”、“Git 钩子管理”，或希望以结构化方式查询其提交历史时（即使未明确指出该工具），请使
req, _ := http.NewRequest("GET", "https://api.example.com/private", nil)
req.Header.Set("Authorization", "Bearer "+token)
req.Header.Set("User-Agent", "myapp/1.0")
<p>resp, err := client.Do(req)
POST JSON 数据并正确处理响应结构
第三方 API 接收参数常用 JSON body，但 Go 的 json.Marshal() 默认不处理零值字段，而有些 API 要求显式传 null 或空字符串。同时，响应结构体字段名映射稍不注意就解不出数据。
- 用
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"` // 仅当有值才发
}
<p>type CreateUserResp struct {
ID int <code>json:"id"</code>
UserID string <code>json:"user_id"</code> // 注意下划线映射
CreatedAt string <code>json:"created_at"</code>
}
错误处理不能只看 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？要不要熔断？这些得在第一次集成时就想清楚，而不是上线后被报警叫醒。
