别再用“先查出来再判断”写登录了：一段验证逻辑的两种写法，差距不在风格

最近帮朋友看一个后台登录的小问题：用户说“密码明明是对的，偶尔就是登不进去”。翻到验证那段代码，问题不在框架，也不在数据库，而在一个很常见的写法习惯——先把记录查出来，再在代码里逐条比对。今天拿这段逻辑做个正误对比，顺便聊聊为什么“能跑”和“可靠”之间差着一层。

错误写法：先查后判，把校验散在业务里

常见版本是：按用户名查出整行记录，然后依次判断用户是否存在、状态是否正常、密码哈希是否匹配，每一步都写一个 if。问题有三：查询条件只带了用户名，等于把“是否有效”的决策全压到应用层；状态判断和密码判断混在一起，出错时分不清是账号问题还是凭证问题；一旦有人后续加个“软删除”字段，这段逻辑很容易漏判。更隐蔽的是，这种写法让“查”和“验”耦合，缓存、索引、审计都很难插进去。

正确写法：把约束交给查询，把结果交给分支

更稳的做法是把“有效用户”的定义收进查询条件：用户名、状态、删除标记一次性带进 where，查不到就直接返回统一的失败提示，不区分“用户不存在”还是“密码错误”。查到之后只做一件事——校验密码哈希。这样职责清晰：数据库负责筛选有效记录，应用层负责凭证比对。好处是逻辑短、分支少、失败路径统一，后续加登录日志或限流也有明确的挂载点。

总结

两种写法都能让登录“跑起来”，但前者把判断散落在流程里，后者把约束前置到查询中。差别不在代码长短，而在出错时你能不能一眼定位。写验证逻辑时，先问一句：这个条件该由谁来判？欢迎交流你踩过的类似坑。