17370845950

够用，但仅限学习和本地调试；真实项目中直接用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，都判断为“不存在”，结果写入两条相同邮箱。

正确做法是引入检查 + 写入的原子性：

• 用 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 都只是替换某个具体实现，而不是推翻整个骨架。