本文介绍一种简洁高效的方式，在 go 应用中根据输入字符串是否含 ‘@’ 符号，动态选择按 username 或 email 字段查询用户，避免重复错误处理与代码冗余。
本文介绍一种简洁高效的方式，在 go 应用中根据输入字符串是否含 ‘@’ 符号，动态选择按 `username` 或 `email` 字段查询用户，避免重复错误处理与代码冗余。
在实现用户登录逻辑时，支持“用户名或邮箱任一方式登录”是常见需求。但若采用条件分支分别查询 username 和 email，不仅导致重复的错误处理逻辑（如两次 if err != nil），还降低了可维护性与可读性。更优解是将查询字段动态化，使核心查询逻辑只出现一次。
核心思路是：先判断 login 字符串是否为邮箱格式（通常以 ‘@’ 为标志），据此确定要匹配的数据库字段名；再构造统一的 bson.M 查询条件，执行单次查询并集中处理错误。
以下是推荐的重构写法：
// 确定查询字段：含 @ 则查 email，否则查 username field := "username" if strings.Contains(login, "@") { field = "email" } // 统一执行查询 err := collection("users").Find(bson.M{field: login}).One(&user) if err != nil { // 错误消息中动态包含实际使用的字段名，便于调试与前端提示 msg := fmt.Sprintf("No user found with %s: %s", field, login) api.WriteError(w, 400, "USER_NOT_FOUND", msg) return } // ✅ 此处继续校验密码、生成 token 等后续流程 // ...✅ 优势说明：
- 逻辑内聚：字段判定与查询解耦，错误处理集中，符合单一职责原则；
- 可扩展性强：未来若需支持手机号登录，仅需扩展 field 判定逻辑，无需改动查询结构；
- 提示友好：错误消息明确指出是 username 还是 email 未匹配，提升排查效率；
- 类型安全：仍使用原生 bson.M，无反射或 Interface{} 带来的运行时风险。
⚠️ 注意事项：
- 仅依赖 ‘@’ 判断邮箱存在局限性（如 admin@ 非法邮箱），生产环境建议结合正则校验（如 ^[^s@]+@[^s@]+.[^s@]+$）或使用标准库 mail.ParseAddress 做轻量验证；
- 数据库需确保 username 和 email 字段均有唯一索引，否则可能因重复值导致意外交互；
- 若使用 mongodb v4.2+，可考虑聚合管道 + $or 实现单次查询双字段匹配，但本方案在绝大多数场景下更简洁、易测、性能相当。
通过这一微小重构，你不仅消除了重复代码，更让身份认证入口逻辑更健壮、清晰且易于演进。