够用，但仅限学习和本地调试；真实项目中直接用map存用户会导致数据丢失、并发panic、无法查重分页，需第一版就考虑存储边界与并发安全。
用 map 做内存用户存储够不够用？
够，但仅限学习和本地调试。真实项目里直接用 map 存用户会导致数据重启就丢、并发读写 panic、无法查重或分页——这些不是“以后再改”的问题，而是写第一版时就必须想清楚的边界。
实操建议：
- 初学阶段可用
sync.Map替代普通map，它自带并发安全，适合快速验证登录/注册逻辑 - 避免在
map[string]User中直接存密码明文，哪怕只是 demo，也该调用bcrypt.GenerateFromPassword做一次哈希 - 如果后续要加数据库，提前把用户结构体字段对齐常见 ORM（比如加
ID uint64 `gorm:"primaryKey"`），别让 demo 结构体和真实模型不兼容
注册接口怎么防重复邮箱？
靠前端校验或后端简单查 map 键存在是无效的。并发注册时两个请求几乎同时执行 if _, ok := users[email]; !ok，都判断为“不存在”，结果写入两条相同邮箱。
正确做法是引入检查 + 写入的原子性：
立即学习“go语言免费学习笔记（深入）”；
- 用
sync.Map.LoadOrStore：传入邮箱作为 key，用户指针作为 value，它会返回是否为新存入的布尔值 - 更贴近生产的方式是模拟唯一约束：先
Load，存在则返回错误；不存在再Store，并捕获可能的竞态（虽然sync.Map本身线程安全，但业务逻辑仍需显式控制流程） - 别忽略大小写问题：邮箱
ABC@EX.COM和abc@ex.com应视为同一账号，入库前统一转小写
http.HandleFunc 路由太散，怎么组织用户相关 handler？
把所有 handler 写在 main.go 里，很快就会变成回调地狱。Go 没有内置 MVC，但可以用组合+闭包收敛逻辑。
推荐结构：
- 定义一个
UserService结构体，内嵌*sync.Map或将来替换的数据库 client - 每个 handler 写成方法：比如
(s *UserService) Register(w http.ResponseWriter, r *http.Request) - 注册路由时用闭包绑定实例：
http.HandleFunc("/register", userSvc.Register) - 这样测试时可直接 new 一个
UserService，注入 mock storage，不用启动 HTTP server
为什么不用 gorilla/mux 或 gin？
因为它们会掩盖 Go 原生 HTTP 的关键细节。比如 gin.Context 封装了 request/response，新手容易误以为“取参数就该调 c.Param()”，却不知道底层仍是 r.URL.Query().Get() 或 json.NewDecoder(r.Body).Decode()。
建议顺序：
- 第一版坚持用标准库：
net/http+encoding/json处理 POST body - 手动解析
r.Body并检查Content-Type是否为application/json，否则返回 400 - 等跑通注册→登录→获取用户全流程后，再换框架——那时你才知道
gin的中间件到底在帮你省哪几行代码
func (s *UserService) Register(w http.ResponseWriter, r *http.Request) {
var req struct {
Email string `json:"email"`
Password string `json:"password"`
}
if err := json.NewDecoder(r.Body).Decode(&req); err != nil {
http.Error(w, "invalid JSON", http.StatusBadRequest)
return
}
if req.Email == "" || req.Password == "" {
http.Error(w, "email and password required", http.StatusBadRequest)
return
}
email := strings.ToLower(req.Email)
if _, loaded := s.users.LoadOrStore(email, &User{Email: email}); loaded {
http.Error(w, "email already registered", http.StatusConflict)
return
}
w.WriteHeader(http.StatusCreated)
}
真正卡住人的从来不是语法，而是“这个结构体该放哪儿”“这个错误该在哪层处理”“并发时谁负责加锁”。把这些决策点在第一版就钉死，后面加 JWT、加 MySQL、加 Redis 都只是替换某个具体实现，而不是推翻整个骨架。 
