Gin适合做轻量Mock服务因其启动快、路由简洁、中间件易插拔，无反射或ORM开销，一行gin.Default()即可运行，契合Mock只需返回固定JSON的需求。
为什么 Gin 适合做轻量 Mock 服务
Gin 启动快、路由简洁、中间件易插拔，没有框架级反射或 ORM 开销，gin.Default() 一行就能跑起来。它不强制你写结构体或数据库层，正好匹配 Mock 场景里“只返回固定 JSON”的需求。但要注意：别用 gin.H 直接拼嵌套 map 太深，容易漏字段或类型错；更别在 handler 里调用外部 HTTP 请求——那不是 Mock，是代理。
用 gin.JSON 返回静态数据的正确姿势
Mock 的核心就是可控、可预测、无副作用。直接用 c.JSON(200, data) 最安全，但 data 必须是 Go 原生可序列化类型（map、struct、slice）。常见错误是传入含函数、channel 或未导出字段的 struct，会 panic 并返回空响应。
- 避免用
map[string]interface{}嵌套三层以上，读起来像俄罗斯套娃，改起来容易漏 key - 推荐定义小 struct（哪怕只用一次），字段首字母大写，
json:tag 显式控制键名 - 若需动态字段（比如根据 query 参数切换返回值），用
c.Query("type")判断，别用c.GetHeader()模拟鉴权——Mock 不该承担权限逻辑
type UserResp struct {
ID int `json:"id"`
Name string `json:"name"`
}
func mockUser(c *gin.Context) {
c.JSON(200, UserResp{ID: 123, Name: "mock-user"})
}处理不同 HTTP 方法和路径参数的常见陷阱
Mock 往往要模拟 RESTful 接口，比如 GET /api/users/:id 和 POST /api/users 返回不同结构。Gin 路由注册没问题，但容易踩两个坑：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
:id参数没校验类型，c.Param("id")总是 string，直接转int可能 panic；加strconv.Atoi错误检查，或干脆全当字符串用 -
POST请求若没设Content-Type: application/json，c.ShouldBindJSON()会静默失败（返回 400 但无提示），建议先用c.Request.Header.Get("Content-Type")打日志确认 - 多个相似路径（如
/v1/users和/v2/users）别靠 if 判断前缀，用独立路由组更清晰
启动时加载 JSON 文件比硬编码更可持续
硬编码数据难维护，尤其字段多、版本多时。用 ioutil.ReadFile（Go 1.16+ 改用 os.ReadFile）读取本地 mock-data/user.json 是折中方案：不用数据库，又支持编辑和 Git 管理。
立即学习“go语言免费学习笔记（深入）”；
- 文件路径别写死相对路径，用
filepath.Join(".", "mock-data", "user.json")，启动前用os.Stat检查是否存在，避免运行时报错 - JSON 文件里避免注释或 trailing comma——Go 的
json.Unmarshal不认，会直接返回invalid character错误 - 如果 mock 数据需按环境切换（dev/staging），别用 build tag，用命令行参数或环境变量控制文件名，比如
go run main.go --mock-env=staging
实际项目里，最常被忽略的是 Content-Type 响应头缺失导致前端解析失败，以及路径参数未做边界检查（比如 /users/-1 返回了不该存在的数据）。Mock 的价值不在“像不像”，而在“稳不稳定”和“改得快不快”。
