Go用户信息API核心在于结构组织：User字段须大写导出并配json标签，如ID int json:"id"；路由用gorilla/mux正则提取参数并校验；查无结果需用errors.Is(err, sql.ErrNoRows)判404而非500。
Go 语言写用户信息 API，核心不是“能不能”，而是「结构怎么组织才不踩坑」——比如 User 结构体字段要不要导出、json 标签漏写导致返回空对象、用 database/sql 查不到数据却没报错、HTTP 路由参数解析失败静默忽略。
定义 User 结构体时，字段首字母大小写和 json 标签缺一不可
Go 的 JSON 序列化只处理导出字段（首字母大写），且默认 key 是字段名全小写。常见错误是写成小写字段或漏标 json 导致前端收不到数据：
-
type User struct { ID int; Name string }→ 前端收到{"id":0,"name":""}（小写 key，但值为零值） -
type User struct { id int `json:"id"` }→id不导出，序列化后该字段消失 - 正确写法：
type User struct { ID int `json:"id"` Name string `json:"name"` } - 额外建议：加
omitempty避免返回空字符串或零值字段，如Name string `json:"name,omitempty"`
用 http.ServeMux 或 gorilla/mux 处理 /users/{id} 路由时，别依赖 URL 拆分
手动 strings.Split(r.URL.Path, "/") 解析路径极易出错（比如多斜杠、编码字符）。标准做法是用路由库提取参数：
根据ui图生成前端页面
下载
将一个或多个 UI 原型图、线框图、产品截图或设计稿转换为标准化、可直接交付的 PRD 风格文档，供产品、设计、前端和测试共同使用。适用于 Codex 需要分析 PC 网页、桌面端、移动端、响应式页面、独立弹窗、表单、表格、看板、数据大屏或多页面流程截图，还原页面结构与交互，强制套用固定文档模板，抽取跨页面共享规则，或把一组原型沉淀为单页规范文档加整体业务流程文档的场景。不适用于纯视觉审美点评、代码实现、接口设计、埋点方案、竞品分析或无 UI 输入的业务需求创作。
- 原生
http.ServeMux不支持路径参数，必须换库或自己解析 —— 不推荐 -
gorilla/mux示例：r.HandleFunc("/users/{id:[0-9]+}", getUserHandler).Methods("GET")，然后在 handler 中用mux.Vars(r)["id"]取值 - 注意：
{id:[0-9]+}正则能过滤非法 ID，避免后续转int时 panic - 别忘了对
vars["id"]做strconv.Atoi并检查 error，否则 400 请求可能返回 500
数据库查询返回 sql.ErrNoRows 时，不能当成普通 error 忽略
查单条用户（如 SELECT * FROM users WHERE id = ?）最常遇到这个错误，但它不是异常，而是「查无此记录」的正常信号：
立即学习“go语言免费学习笔记（深入）”；
- 直接
if err != nil { return err }会导致 404 被当成 500 返回 - 正确判断：
if errors.Is(err, sql.ErrNoRows) { http.Error(w, "user not found", http.StatusNotFound); return } - 用
Scan接收单行结果时，务必传指针：err := row.Scan(&u.ID, &u.Name)，传值会 panic - 如果用
QueryRow，记得调用Scan；只调Err()不扫描，字段不会赋值
真正难的不是写完接口，而是每个环节都得主动防御：结构体标签写错一行，前端就收不到数据；路由没校验 ID 格式，恶意请求可能拖垮数据库；sql.ErrNoRows 当普通 error 处理，404 就变成了 500。这些点不写测试很难暴露。
