http.HandleFunc 不够用因仅支持静态路径匹配，无法解析动态段如 /users/123；应选 chi 等路由库，用 chi.URLParam 安全取值，并将解析、校验、查询拆分为可测函数。
用 net/http 搭建最简 RESTful 路由时，为什么 http.HandleFunc 不够用？
因为 http.HandleFunc 只支持固定路径字符串匹配，无法解析 /users/123 中的 123 这类动态段。你得自己写字符串切分和类型转换，容易出错且不可维护。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 优先使用轻量路由库，如
gorilla/mux或chi（推荐chi，API 设计更清晰、中间件链更自然） - 避免手写正则匹配路径——
chi的chi.URLParam(r, "id")直接取值，类型安全 - 别在 handler 里做太多逻辑，把解析、校验、DB 查询拆成独立函数，方便单元测试
chi 中如何正确处理 JSON 请求体并捕获常见解码错误？
直接 json.Decode 读 r.Body 容易忽略 io.EOF、json.SyntaxError 等错误，导致 500 泄露内部信息或静默失败。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 统一用封装函数解析 JSON，例如：
func parseJSON(r *http.Request, v interface{}) error { defer r.Body.Close() if r.ContentLength == 0 { return errors.New("empty request body") } if err := json.NewDecoder(r.Body).Decode(v); err != nil { var syntaxErr *json.SyntaxError if errors.As(err, &syntaxErr) { return fmt.Errorf("invalid JSON at position %d", syntaxErr.Offset) } return fmt.Errorf("invalid request payload: %w", err) } return nil } - 在中间件中检查
Content-Type: application/json，不匹配直接返回 415 - 结构体字段必须加
json:tag，且注意导出（首字母大写），否则解码始终为零值
RESTful 接口返回错误时，http.Error 和自定义 JSON 错误响应哪个更合适？
http.Error 返回纯文本，前端难解析；但直接写 JSON 又容易漏设 Content-Type 或状态码，导致前端收到 200 却含错误内容。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 所有错误响应走统一函数，例如：
func writeError(w http.ResponseWriter, status int, msg string) { w.Header().Set("Content-Type", "application/json; charset=utf-8") w.WriteHeader(status) json.NewEncoder(w).Encode(map[string]string{"error": msg}) } - 区分错误类型：参数校验失败用 400，资源不存在用 404，权限问题用 403，服务异常用 500
- 不要在错误响应里暴露数据库字段名、堆栈或内部路径（如
"failed to query users table"）
用 database/sql 查询时，为什么 Scan 报 sql: no rows in result set 但接口没返回 404？
这是最常被忽略的点：rows.Scan() 本身不报这个错，真正触发它的是 rows.Err() 或 rows.Next() 返回 false 后未检查 rows.Err()。很多开发者只判断 rows.Next() 就返回空结构体，结果 200 响应了 null。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 查单条记录用
db.QueryRow().Scan()，它会自动返回sql.ErrNoRows；捕获后显式返回 404 - 查列表用
for rows.Next()循环，循环结束后务必调rows.Err()判断是否有底层错误 - 别用
_ = db.QueryRow(...).Scan(...)忽略错误——Go 的错误必须显式处理
rows.Err()、漏了 Content-Type、或者把 json.SyntaxError 当普通错误透传给前端。 
