本文介绍在 Go 语言中，如何安全、优雅地从不同响应结构体（如 Response 和 ErrorResponse）中统一获取 HTTP 状态码，避免重复传参与类型断言冗余，推荐使用接口抽象 + 方法约定的工程化方案。
本文介绍在 go 语言中，如何安全、优雅地从不同响应结构体（如 `response` 和 `errorresponse`）中统一获取 http 状态码，避免重复传参与类型断言冗余，推荐使用接口抽象 + 方法约定的工程化方案。
在构建 RESTful API 时，常需对成功响应与错误响应分别建模（如 Response 和 ErrorResponse），二者均携带 Status 字段用于设置 HTTP 状态码。但若将响应体作为 interface{} 传入通用序列化函数（如 JSON()），则无法直接访问 Status 字段——因为 Go 的空接口不支持字段访问，编译器会报错：response.Status undefined (type interface {} has no field or method Status)。
❌ 错误做法：直接访问接口字段
以下代码无法通过编译：
func JSON(rw http.ResponseWriter, response interface{}) {
payload, _ := json.MarshalIndent(response, "", " ")
rw.WriteHeader(response.Status) // 编译错误！
}⚠️ 可行但不推荐：运行时类型断言
可通过 switch r := response.(type) 分支处理具体类型，实现运行时安全访问：
func JSON(rw http.ResponseWriter, response interface{}) {
payload, _ := json.MarshalIndent(response, "", " ")
switch r := response.(type) {
case Response:
rw.WriteHeader(r.Status)
case ErrorResponse:
rw.WriteHeader(r.Status)
default:
rw.WriteHeader(http.StatusInternalServerError)
}
rw.Header().Set("Content-Type", "application/json")
rw.Write(payload)
}该方式虽能工作，但存在明显缺陷：
- 每新增一种响应类型，都需手动扩展 switch 分支；
- 逻辑耦合度高，违反开闭原则；
- 无编译期检查，易遗漏类型或拼写错误。
✅ 推荐方案：定义行为契约接口
最佳实践是抽象共性行为，而非依赖结构共性。我们定义一个 Statuser 接口，约定所有可序列化响应必须实现 Status() int 方法：
type Statuser interface {
Status() int
}
// 注意：为避免与 JSON tag 冲突，结构体字段名建议重命名为 ResStatus
type Response struct {
ResStatus int `json:"status"`
Data interface{} `json:"data"`
}
type ErrorResponse struct {
ResStatus int `json:"status"`
Errors []string `json:"errors"`
}
// 实现接口方法
func (r Response) Status() int { return r.ResStatus }
func (r ErrorResponse) Status() int { return r.ResStatus }
// 通用 JSON 响应函数 —— 参数类型升级为接口，语义清晰且类型安全
func JSON(rw http.ResponseWriter, response Statuser) {
payload, err := json.MarshalIndent(response, "", " ")
if err != nil {
http.Error(rw, "JSON marshal error", http.StatusInternalServerError)
return
}
rw.WriteHeader(response.Status())
rw.Header().Set("Content-Type", "application/json")
rw.Write(payload)
}✅ 优势总结：
- 编译期保障：调用 response.Status() 时，Go 编译器强制要求传入值实现 Statuser，杜绝运行时 panic；
- 易于扩展：新增响应类型只需实现 Status() int 方法，无需修改 JSON() 函数；
- 职责分离：状态码获取逻辑内聚于各结构体，序列化逻辑专注 IO 与协议处理；
- 命名建议：将原 Response 重命名为 DataResponse，将接口命名为 Response（更符合领域语义），例如：
type Response interface { Status() int } // 顶层行为接口 type DataResponse struct { ... } // 具体数据响应 type ErrorResp struct { ... } // 具体错误响应
最后提醒：实际项目中还应补充错误处理（如 json.MarshalIndent 失败）、HTTP 头标准化（如 Content-Type）、以及日志/监控埋点等生产就绪要素。但核心原则不变——用接口表达能力，用方法封装状态，让多态成为可维护性的基石。
