很多做后端的朋友应该都有过这种经历一个项目刚开始只有 PC 端登录代码简单一个 login 方法里写死用户名密码校验。过了半年 App 端上线了加一个分支。再后来小程序扫码登录、内部系统免密登录、第三方授权登录……每个需求来都是往原来那个 login 方法里怼代码最后那个方法变成几百行 if-else 不说改一处还怕动到另一处。今天这篇就来聊怎么用工厂模式加策略模式把这堆乱成一团的登录逻辑拆干净让多端登录从“能跑”变成“容易改”。这个方案不是什么新奇发明它就是把两种经典设计模式组合起来用策略模式负责“每种登录方式各管各的”工厂模式负责“根据请求参数找到该用哪个策略”。再加上 Spring Boot 自身的依赖注入能力连自己 new 对象的步骤都省了。适合在原有单体项目上渐进式改造也适合新项目一开始就把登录模块搭规整。后面我讲的全是 Spring Boot 项目里的落地细节代码都是可以直接抄的。在这之前我先把结论说在前面登录逻辑乱的根源不是因为“登录”这个动作复杂而是因为“登录来源”的差异被揉进了一个方法里。我们真正的目标不是把代码写得更高深而是让每种来源的差异约束在一个类里新增来源时不去碰老代码。后面所有设计都是围绕这一句话展开的。1. 登录逻辑差的根源一段代码是怎么变成一团乱麻的1.1 多端登录的典型混乱场景先描述一下典型症状。我接手过的一个老项目登录入口长这样Controller 里有一个 login 方法接收一个 Map 参数然后里面从头到尾就是一堆 if-else 判断 loginType。PC 密码走这段App 短信验证码走那段微信登录又走另一段。每个分支里还夹杂着验验证码、查用户、生成 token、更新最后登录时间、记录登录日志这些通用逻辑写到后面整整一个方法五六百行同事跟我说“改登录没人敢动”。这种写法带来的问题不止是难看更麻烦的是它把“登录方式独有的逻辑”和“登录成功后的通用逻辑”焊死在了一起。今天要加一个扫码登录你得在一个巨大方法中间找位置插入新分支旁边没有任何隔离。测一次密码登录得从头走一遍所有分支判断改一个通用逻辑所有端的行为都跟着变风险根本不可控。如果再碰上团队几个人同时改这个文件那 git 冲突能把人逼疯。1.2 为什么用策略加工厂而不是继续堆 if-else要解决这个混乱第一步是让“不同的登录方式”变成“不同的策略”各自封装成一个类。策略模式解决的是算法族的封装问题每种登录方式自己知道怎么验证身份、怎么获取用户信息、怎么组装登录结果。第二步是用工厂来承接“根据请求类型找到策略”这件例行公事。工厂模式解决的是创建与选择逻辑的集中避免调用方到处写 switch-case。我把这套方案选型的关键理由拆成三条。第一条单一职责每个策略类只做自己这一类登录的事类小、易读、易测第二条开闭原则新增登录方式时新增一个策略类就行不需要改任何老类第三条配合 Spring 容器后策略自动注册连工厂里的 map 注册逻辑都不用改。这三条对工程化维护的价值比任何炫技都实在。你可能觉得“又多了一层类”但实际上每一层都在回应一个明确的职责变化点。2. 工厂加策略的架构设计先定契约再管路由2.1 策略接口登录动作的统一契约设计策略接口的时候不能设计得太具体否则每种策略都要被迫实现一堆用不上的方法也不能设计得太抽象否则调用方又要做类型判断。经过反复调整我最后用的接口长这样。public interface LoginStrategy { /** * 当前策略支持的登录方式标识 * 例如pc_password、app_sms、wx_scan */ String supportLoginType(); /** * 执行登录逻辑返回统一结果结构 */ LoginResult login(LoginRequest request); }这个接口就两个方法。第一个是 supportLoginType用来让工厂知道这个策略服务哪种登录方式第二个是 login真正干活的入口。有人可能会问为什么不在抽象类里把公共逻辑比如“登录成功后的埋点”也写了。我的建议是公共逻辑可以放在抽象模板类里但策略接口本身一定要保持克制。接口越轻扩展成本越低。2.2 工厂类从登录类型到策略实例的转换器工厂类的核心就是把一个字符串类型的登录类型转换成对应的策略对象。Spring 容器里如果所有策略都注册成 Bean那么在工厂构造时通过构造器注入一个 List Java 8 之后的写法非常清爽。这里我直接给出一版在实际项目里跑过的实现。Component public class LoginStrategyFactory { private final MapString, LoginStrategy strategies; public LoginStrategyFactory(ListLoginStrategy loginStrategyList) { this.strategies loginStrategyList.stream() .collect(Collectors.toMap(LoginStrategy::supportLoginType, Function.identity())); } public LoginStrategy getStrategy(String loginType) { LoginStrategy strategy strategies.get(loginType); if (strategy null) { throw new IllegalArgumentException(未找到对应的登录策略: loginType); } return strategy; } }这里用 List 注入Spring 会自动把容器里所有 LoginStrategy 实现类的 Bean 丢进来。toMap 会把每个策略的 supportLoginType 当作 key策略实例当作 value。调用方只依赖于 getStrategy 这一个方法不用关心策略怎么来的。如果登录类型不支持直接抛出异常这个异常在统一异常处理器里会被转成友好提示。这比你返回 null 再让调用方判断要安全得多。2.3 Spring Bean 自动注册带来的扩展红利用这个方案的另一个好处是因为策略本身就是一个普通 Spring 托管 Bean新加登录方式的时候你只需要在项目中新增一个实现 LoginStrategy 的类标注 Component 或者在其配置类中注册为 Bean然后它就自动出现在工厂的 List 里了。工厂不需要加 if不需要加 switch原来的策略类也一个都不用改。这在多人协作的场景下特别有用。A 同事在加 App 扫码登录B 同事在加微信小程序登录两个人各自写各自的策略类互相不碰文件提交代码基本没有冲突。配合代码评审也能一眼看出新策略实现有没有问题因为每个策略类都足够小。我之前在一个项目里用这套方式二十多个登录入口代码结构始终没乱过。3. 实操落地用统一登录入口替换掉几百行 if-else3.1 工程准备与基础依赖我用的是 Spring Boot 2.7.x 加 JDK 8即便你用的是更高版本甚至 Spring Boot 3.x核心思路完全一致。工程里需要引入的基础依赖基本就是 spring-boot-starter-web加上你自己项目里已有的 MyBatis 或 JPA 等持久层框架。登录的时候涉及 JWT 生成 token 的话再引入一个 jjwt 依赖就可以。dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdio.jsonwebtoken/groupId artifactIdjjwt/artifactId version0.9.1/version /dependencyJWT 的细节不是这篇的重点重点是token 生成这套逻辑属于“登录成功后的通用动作”我建议放在一个单独的 TokenService 里每个策略需要发 token 的时候直接调用它而不是每个策略自己重新搓一遍。后面会看到这样做对多端互斥、token 失效这些需求帮助非常大。3.2 登录请求与响应 DTO 设计多端登录的参数其实差异不小。PC 密码登录要账号密码验证码App 短信登录要手机号验证码微信扫码登录要临时 code。虽然参数不一样但 HTTP 入口最好统一所以我会用一组带可变字段的 DTO 去承接同时把登录类型字段放在最前面。public class LoginRequest { private String loginType; // pc_password / app_sms / wx_scan private String username; private String password; private String captchaKey; private String captchaCode; private String phone; private String smsCode; private String wxCode; private String clientType; // pc / app / mini_program // getter/setter 省略 }这样的 DTO 虽然不完美但胜在实用。所有可选字段都在一个对象里策略内部取自己需要的字段取不到就抛业务异常。相比每个登录方式各写一个 Request 类这个方案在接口入口上更统一前端的联调成本也更低。当然如果你对接口文档要求更高可以在 Controller 层做分组校验那是后续优化的事。3.3 三种策略的具体实现先看最简单的 PC 密码登录策略。它做的事情是校验图形验证码按用户名查用户比对密码生成 token返回结果。Component public class PcPasswordLoginStrategy implements LoginStrategy { private final UserMapper userMapper; private final TokenService tokenService; private final CaptchaService captchaService; private final PasswordEncoder passwordEncoder; public PcPasswordLoginStrategy(UserMapper userMapper, TokenService tokenService, CaptchaService captchaService, PasswordEncoder passwordEncoder) { this.userMapper userMapper; this.tokenService tokenService; this.captchaService captchaService; this.passwordEncoder passwordEncoder; } Override public String supportLoginType() { return pc_password; } Override public LoginResult login(LoginRequest request) { captchaService.validate(request.getCaptchaKey(), request.getCaptchaCode()); if (StringUtils.isBlank(request.getUsername()) || StringUtils.isBlank(request.getPassword())) { throw new BusinessException(账号密码不能为空); } User user userMapper.selectByUsername(request.getUsername()); if (user null || !passwordEncoder.matches(request.getPassword(), user.getPassword())) { throw new BusinessException(用户名或密码错误); } String token tokenService.generateToken(user.getId(), request.getClientType()); return LoginResult.success(token, user); } }这种代码就是“一个类一个世界”。图形验证码校验、密码校验、用户查询这些逻辑被清楚地分层。假如验证码校验逻辑在密码登录里要用而在注册流程里也要用这种跨功能的公共能力就抽成 CaptchaService策略只在需要时注入不强塞。再看 App 短信登录策略。它的特殊之处在于不再有用户名密码互查而是直接用手机号查用户用户不存在则走快速注册流程。Component public class AppSmsLoginStrategy implements LoginStrategy { private final UserMapper userMapper; private final TokenService tokenService; private final SmsValidateService smsValidateService; public AppSmsLoginStrategy(UserMapper userMapper, TokenService tokenService, SmsValidateService smsValidateService) { this.userMapper userMapper; this.tokenService tokenService; this.smsValidateService smsValidateService; } Override public String supportLoginType() { return app_sms; } Override public LoginResult login(LoginRequest request) { smsValidateService.validate(request.getPhone(), request.getSmsCode()); User user userMapper.selectByPhone(request.getPhone()); if (user null) { user userMapper.createQuickUser(request.getPhone()); } String token tokenService.generateToken(user.getId(), request.getClientType()); return LoginResult.success(token, user); } }这里有个实操细节像 smsValidateService.validate 校验失败抛异常时最好抛业务异常 BusinessException便于统一异常处理器捕捉。千万避开在策略内部返回 LoginResult.error 之类的对象让策略只负责业务成败统一结果对象的结构由外层封装职责会更清晰也避免调用方还要处理半成功半失败的状态。最后一个微信扫码登录策略。拿到的 wxCode 是临时授权码需要向微信接口换取 openId 和用户信息再在自己的系统里找到对应的用户。这个策略跟另外两个核心差异在于要调外部接口而且有网络超时、code 过期这些风险异常处理要额外关注。Component public class WxScanLoginStrategy implements LoginStrategy { private final UserMapper userMapper; private final TokenService tokenService; private final WxAuthService wxAuthService; public WxScanLoginStrategy(UserMapper userMapper, TokenService tokenService, WxAuthService wxAuthService) { this.userMapper userMapper; this.tokenService tokenService; this.wxAuthService wxAuthService; } Override public String supportLoginType() { return wx_scan; } Override public LoginResult login(LoginRequest request) { String openId wxAuthService.getOpenIdByCode(request.getWxCode()); User user userMapper.selectByOpenId(openId); if (user null) { throw new BusinessException(该微信尚未绑定任何账号); } String token tokenService.generateToken(user.getId(), request.getClientType()); return LoginResult.success(token, user); } }三个策略写下来你会发现它们各自只关心自己的登录来源登录成功之后的 token 生成、用户信息返回全都在各策略内部依赖同一个 TokenService 完成这样保证多端的登录结果结构一致。对前端来说不管什么端登录拿到的都是 token 加用户信息使用体验是统一的。3.4 统一入口的 Controller 层改造Controller 这层就非常简单了因为真正的复杂性已经被策略和工厂消化掉了。RestController public class LoginController { private final LoginStrategyFactory strategyFactory; public LoginController(LoginStrategyFactory strategyFactory) { this.strategyFactory strategyFactory; } PostMapping(/login) public ResultLoginResult login(RequestBody Validated LoginRequest request) { return Result.ok(strategyFactory.getStrategy(request.getLoginType()).login(request)); } PostMapping(/logout) public ResultVoid logout(RequestHeader(Authorization) String token) { tokenService.invalidate(token); return Result.ok(); } }一个 login 接口一个 logout 接口所有端共用。新增登录方式时Controller 一行不用改工厂一行不要动只要新增策略类。这就是我们前面说的“扩展开放、修改关闭”真正落到代码上的样子。前端调登录接口时只需要多传一个 loginType 字段成本几乎可以忽略。3.5 策略选择器的兜底与日志虽然有了统一入口我还是建议在工厂的 getStrategy 上加一个兜底登录类型不合法的时候不要返回 null直接抛异常。这能省掉 Controller 层的判空逻辑也避免前端拿空对象以为登录成功了。我再补一个判断技巧如果你发现某个策略里需要根据字段再走一大段 if-else那说明你策略粒度没拆分好。比如同样是 App 端密码登录、验证码登录、生物识别登录就应该继续拆成三个策略类。宁可多几个小类也不要在一个类里再次出现分支地狱。判断粒度是否合适的标准很简单这个类能不能用一句话说清自己的职责能就继续用不能就继续拆。4. 向真实场景延伸验证码、扫码登录与多端互斥4.1 用策略模式快速扩展新的登录方式我们的工厂方案天然适合不停新增登录方式。假设下一版要支持“管理后台 OTP 动态口令登录”就新增一个 AdminOtpLoginStrategysupportLoginType 填 admin_otp然后实现校验 OTP、查询管理员用户、生成 token 的逻辑。完成后它自动被 Spring 发现工厂的 List 注入时自动带上它无需改动任何老代码。这种扩展带来的直接收益是产品经理每提一个新登录需求我们不用再评估“改登录方法会不会影响其他端”因为从设计上就已经切割干净了。这种安全感是做登录模块最需要的。我见过太多项目因为登录逻辑不敢动导致新需求一拖再拖最后拖成技术债。有了这套结构新需求来了就是“复制一个类改一改”的事效率完全不一样。4.2 多端互斥与 token 管理方案多端登录有时候不只是“都能登录”还要控制“同一账号能否同时在多端在线”。这在运营后台、财务后台这类安全要求高的场景里很有必要。我一般在 TokenService 里做两个动作一是生成 token 时带上用户唯一标识和端标识二是维护一张 token 状态表记录 token 与用户、端的绑定关系。如果业务要求互斥就在生成新 token 时把该用户其他端或者同端旧 token 标记失效。这里最容易被忽略的是“端标识”。如果所有端生成的都是同一种无差异 token那互斥就没法做到精细颗粒度。我们的策略类里应该把 clientType 从 LoginRequest 里取出来再传给 tokenService.generateToken。这样 TokenService 在生成 token 时可以拼上端信息互斥逻辑也能按端做不同策略同端互斥、多端各自在线还是只能单一在线这些都是配置化的。给一个更简洁的做法TokenService 里维护一个存有效 token 的关系表key 是 userId 加 clientTypevalue 是当前有效 token。登录时如果发现已有有效 token 且要求互斥则先把旧 token 加入黑名单再签新的。因为工厂模式下各策略都走同一个 TokenService所以互斥策略能一致地生效不会出现某个端绕开了规则。黑名单可以用 RedisTTL 设置为 token 剩余有效期自然过期也不怕。4.3 兼容老接口渐进式改造怎么过渡如果你跟我的情况一样不是从零写新项目而是改造一个已经上线多年的老登录接口那别急着把老接口拆掉。稳妥的做法是保留老的 /login/auth 接口对外不可变内部把它适配到工厂模式的调用上也就是让老接口也调用 strategyFactory.getStrategy(pc_password)这样前端不用改后端换了一颗“新心脏”等全量验证通过后再让前端切换新接口。渐进式改造的关键在于灰度。我建议在改造后加上一行日志把 loginType 和策略类名打出来可以很方便地在链路里确认实际执行了哪个策略类避免“明明切了新逻辑线上却还在走老分支”这种尴尬。上线之后先观察几天重点看错误率有没有变化登录成功率是否正常确认没问题后再切流量这一步不能省。5. 踩坑记录与排查套路5.1 策略 Bean 没有被注入现象是启动报错或者调用时提示策略找不到。我遇到过的一个高发原因是策略类放在扫描包之外Spring 没有把它注册成 Bean自然就不在工厂的 List 里。解决办法很简单要么把类移进扫描路径要么在配置类里用 Bean 方式显式注册。第二种高发原因是有两个类返回了相同的 supportLoginType。Collectors.toMap 在遇到重复 key 时默认会抛 IllegalStateException启动时就失败反而帮我们提前暴露了问题。我自己的习惯是把登录类型的常量统一放在一个枚举或者常量类里禁止用裸字符串到处散落这样重复的概率就低很多。5.2 Bean 命名冲突与类型区分当策略类名以相同单词开头时Spring 默认的 Bean 名字可能会冲突。比如你的策略实现类叫 WxQrcodeLoginStrategy 和 WxScanLoginStrategy同时你还想手动写 Bean 方法可能会遇到 Bean 名重复的问题。我的建议是策略类一律采用“端加方式加 Strategy”的命名风格是否显式命名 Bean 都不要紧因为我们的工厂是通过 supportLoginType 来区分的不依赖 Bean 名字。真正要警惕的是 Bean 方法重名。如果两个配置类里都有 Bean 方法返回 LoginStrategy而且方法名一样Spring 会直接报错。遇到这种情况我给 Bean 方法加上不同的名字或者干脆让策略类自己加 Component不要重复注册。越是依赖自动装配越要留意这些隐式规则。5.3 策略对象里的循环依赖如果一个策略依赖 ServiceBServiceB 又反过来依赖策略那在 Spring 里就会形成循环依赖。虽然 Spring Boot 2.6 开始把循环依赖默认禁止了但老项目开着允许开关代码会继续转起来只是性能有损耗而且结构上有隐患。遇到这种情况我的做法是调整依赖方向抽出一个中间层。比如把 token 生成抽成独立的 TokenService让 ServiceB 依赖 TokenService 而不是依赖具体策略这样策略和服务之间的耦合就切开了。循环依赖看起来是配置问题其实是设计问题别用 Lazy 敷衍把依赖方向理清楚才是根治。5.4 快速定位当前执行了哪个策略线下调试的时候最直接的办法是在工厂的 getStrategy 方法里加一行日志打印登录类型和找到的策略类名。public LoginStrategy getStrategy(String loginType) { LoginStrategy strategy strategies.get(loginType); if (strategy null) { throw new IllegalArgumentException(未找到对应的登录策略: loginType); } log.info(获取到登录策略: {} - {}, loginType, strategy.getClass().getSimpleName()); return strategy; }线上排查时这行日志是救命稻草。用户反馈某个端登录不了我们第一反应就是看日志里走的是哪个策略类。如果登录类型值和策略类对不上基本就是前端传错参数或者配置没有刷到最新版本。如果日志显示策略类正确但没有拿到业务数据就得往下面去查具体策略里依赖的 Service 和外部接口排查范围一下子就能缩小。5.5 单测怎么写才有效最后补一个我自己的测试习惯。策略类因为职责单一单测反而非常好写。针对每个策略覆盖成功分支、参数缺失分支、校验失败分支、用户不存在分支就够了。工厂类只需要测试两个点存在的 loginType 能返回正确策略不存在的 loginType 抛异常。Controller 层做接口级测试时直接通过 MockMvc 调用再断言返回的 token 是否生成成功。这样一套测试下来改动任何一个策略都不会波及其他端的测试回归范围小信心足。这套方案我在好几个项目里落地过最大的体会不是“代码变好看了”而是“功能迭代的压力变小了”。以前听到新登录需求就头大现在拿到需求基本就是新建一个策略类写自己的业务测试也只需要针对这个新类做单测。不是所有场景都需要设计模式但登录这种天然带有多种变体、且变体会不断增长的业务确实是策略加工厂最典型的适用场景。如果你现在正被一段几百行的 login 方法折磨可以先按这个思路把接口抽出来再把分支挪到策略类里跑通一个端之后再逐步迁移其他端。这中间踩坑的过程能让你对 Spring 容器和设计模式的理解深一个档次。
很多做后端的朋友应该都有过这种经历一个项目刚开始只有 PC 端登录代码简单一个 login 方法里写死用户名密码校验。过了半年 App 端上线了加一个分支。再后来小程序扫码登录、内部系统免密登录、第三方授权登录……每个需求来都是往原来那个 login 方法里怼代码最后那个方法变成几百行 if-else 不说改一处还怕动到另一处。今天这篇就来聊怎么用工厂模式加策略模式把这堆乱成一团的登录逻辑拆干净让多端登录从“能跑”变成“容易改”。这个方案不是什么新奇发明它就是把两种经典设计模式组合起来用策略模式负责“每种登录方式各管各的”工厂模式负责“根据请求参数找到该用哪个策略”。再加上 Spring Boot 自身的依赖注入能力连自己 new 对象的步骤都省了。适合在原有单体项目上渐进式改造也适合新项目一开始就把登录模块搭规整。后面我讲的全是 Spring Boot 项目里的落地细节代码都是可以直接抄的。在这之前我先把结论说在前面登录逻辑乱的根源不是因为“登录”这个动作复杂而是因为“登录来源”的差异被揉进了一个方法里。我们真正的目标不是把代码写得更高深而是让每种来源的差异约束在一个类里新增来源时不去碰老代码。后面所有设计都是围绕这一句话展开的。1. 登录逻辑差的根源一段代码是怎么变成一团乱麻的1.1 多端登录的典型混乱场景先描述一下典型症状。我接手过的一个老项目登录入口长这样Controller 里有一个 login 方法接收一个 Map 参数然后里面从头到尾就是一堆 if-else 判断 loginType。PC 密码走这段App 短信验证码走那段微信登录又走另一段。每个分支里还夹杂着验验证码、查用户、生成 token、更新最后登录时间、记录登录日志这些通用逻辑写到后面整整一个方法五六百行同事跟我说“改登录没人敢动”。这种写法带来的问题不止是难看更麻烦的是它把“登录方式独有的逻辑”和“登录成功后的通用逻辑”焊死在了一起。今天要加一个扫码登录你得在一个巨大方法中间找位置插入新分支旁边没有任何隔离。测一次密码登录得从头走一遍所有分支判断改一个通用逻辑所有端的行为都跟着变风险根本不可控。如果再碰上团队几个人同时改这个文件那 git 冲突能把人逼疯。1.2 为什么用策略加工厂而不是继续堆 if-else要解决这个混乱第一步是让“不同的登录方式”变成“不同的策略”各自封装成一个类。策略模式解决的是算法族的封装问题每种登录方式自己知道怎么验证身份、怎么获取用户信息、怎么组装登录结果。第二步是用工厂来承接“根据请求类型找到策略”这件例行公事。工厂模式解决的是创建与选择逻辑的集中避免调用方到处写 switch-case。我把这套方案选型的关键理由拆成三条。第一条单一职责每个策略类只做自己这一类登录的事类小、易读、易测第二条开闭原则新增登录方式时新增一个策略类就行不需要改任何老类第三条配合 Spring 容器后策略自动注册连工厂里的 map 注册逻辑都不用改。这三条对工程化维护的价值比任何炫技都实在。你可能觉得“又多了一层类”但实际上每一层都在回应一个明确的职责变化点。2. 工厂加策略的架构设计先定契约再管路由2.1 策略接口登录动作的统一契约设计策略接口的时候不能设计得太具体否则每种策略都要被迫实现一堆用不上的方法也不能设计得太抽象否则调用方又要做类型判断。经过反复调整我最后用的接口长这样。public interface LoginStrategy { /** * 当前策略支持的登录方式标识 * 例如pc_password、app_sms、wx_scan */ String supportLoginType(); /** * 执行登录逻辑返回统一结果结构 */ LoginResult login(LoginRequest request); }这个接口就两个方法。第一个是 supportLoginType用来让工厂知道这个策略服务哪种登录方式第二个是 login真正干活的入口。有人可能会问为什么不在抽象类里把公共逻辑比如“登录成功后的埋点”也写了。我的建议是公共逻辑可以放在抽象模板类里但策略接口本身一定要保持克制。接口越轻扩展成本越低。2.2 工厂类从登录类型到策略实例的转换器工厂类的核心就是把一个字符串类型的登录类型转换成对应的策略对象。Spring 容器里如果所有策略都注册成 Bean那么在工厂构造时通过构造器注入一个 List Java 8 之后的写法非常清爽。这里我直接给出一版在实际项目里跑过的实现。Component public class LoginStrategyFactory { private final MapString, LoginStrategy strategies; public LoginStrategyFactory(ListLoginStrategy loginStrategyList) { this.strategies loginStrategyList.stream() .collect(Collectors.toMap(LoginStrategy::supportLoginType, Function.identity())); } public LoginStrategy getStrategy(String loginType) { LoginStrategy strategy strategies.get(loginType); if (strategy null) { throw new IllegalArgumentException(未找到对应的登录策略: loginType); } return strategy; } }这里用 List 注入Spring 会自动把容器里所有 LoginStrategy 实现类的 Bean 丢进来。toMap 会把每个策略的 supportLoginType 当作 key策略实例当作 value。调用方只依赖于 getStrategy 这一个方法不用关心策略怎么来的。如果登录类型不支持直接抛出异常这个异常在统一异常处理器里会被转成友好提示。这比你返回 null 再让调用方判断要安全得多。2.3 Spring Bean 自动注册带来的扩展红利用这个方案的另一个好处是因为策略本身就是一个普通 Spring 托管 Bean新加登录方式的时候你只需要在项目中新增一个实现 LoginStrategy 的类标注 Component 或者在其配置类中注册为 Bean然后它就自动出现在工厂的 List 里了。工厂不需要加 if不需要加 switch原来的策略类也一个都不用改。这在多人协作的场景下特别有用。A 同事在加 App 扫码登录B 同事在加微信小程序登录两个人各自写各自的策略类互相不碰文件提交代码基本没有冲突。配合代码评审也能一眼看出新策略实现有没有问题因为每个策略类都足够小。我之前在一个项目里用这套方式二十多个登录入口代码结构始终没乱过。3. 实操落地用统一登录入口替换掉几百行 if-else3.1 工程准备与基础依赖我用的是 Spring Boot 2.7.x 加 JDK 8即便你用的是更高版本甚至 Spring Boot 3.x核心思路完全一致。工程里需要引入的基础依赖基本就是 spring-boot-starter-web加上你自己项目里已有的 MyBatis 或 JPA 等持久层框架。登录的时候涉及 JWT 生成 token 的话再引入一个 jjwt 依赖就可以。dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdio.jsonwebtoken/groupId artifactIdjjwt/artifactId version0.9.1/version /dependencyJWT 的细节不是这篇的重点重点是token 生成这套逻辑属于“登录成功后的通用动作”我建议放在一个单独的 TokenService 里每个策略需要发 token 的时候直接调用它而不是每个策略自己重新搓一遍。后面会看到这样做对多端互斥、token 失效这些需求帮助非常大。3.2 登录请求与响应 DTO 设计多端登录的参数其实差异不小。PC 密码登录要账号密码验证码App 短信登录要手机号验证码微信扫码登录要临时 code。虽然参数不一样但 HTTP 入口最好统一所以我会用一组带可变字段的 DTO 去承接同时把登录类型字段放在最前面。public class LoginRequest { private String loginType; // pc_password / app_sms / wx_scan private String username; private String password; private String captchaKey; private String captchaCode; private String phone; private String smsCode; private String wxCode; private String clientType; // pc / app / mini_program // getter/setter 省略 }这样的 DTO 虽然不完美但胜在实用。所有可选字段都在一个对象里策略内部取自己需要的字段取不到就抛业务异常。相比每个登录方式各写一个 Request 类这个方案在接口入口上更统一前端的联调成本也更低。当然如果你对接口文档要求更高可以在 Controller 层做分组校验那是后续优化的事。3.3 三种策略的具体实现先看最简单的 PC 密码登录策略。它做的事情是校验图形验证码按用户名查用户比对密码生成 token返回结果。Component public class PcPasswordLoginStrategy implements LoginStrategy { private final UserMapper userMapper; private final TokenService tokenService; private final CaptchaService captchaService; private final PasswordEncoder passwordEncoder; public PcPasswordLoginStrategy(UserMapper userMapper, TokenService tokenService, CaptchaService captchaService, PasswordEncoder passwordEncoder) { this.userMapper userMapper; this.tokenService tokenService; this.captchaService captchaService; this.passwordEncoder passwordEncoder; } Override public String supportLoginType() { return pc_password; } Override public LoginResult login(LoginRequest request) { captchaService.validate(request.getCaptchaKey(), request.getCaptchaCode()); if (StringUtils.isBlank(request.getUsername()) || StringUtils.isBlank(request.getPassword())) { throw new BusinessException(账号密码不能为空); } User user userMapper.selectByUsername(request.getUsername()); if (user null || !passwordEncoder.matches(request.getPassword(), user.getPassword())) { throw new BusinessException(用户名或密码错误); } String token tokenService.generateToken(user.getId(), request.getClientType()); return LoginResult.success(token, user); } }这种代码就是“一个类一个世界”。图形验证码校验、密码校验、用户查询这些逻辑被清楚地分层。假如验证码校验逻辑在密码登录里要用而在注册流程里也要用这种跨功能的公共能力就抽成 CaptchaService策略只在需要时注入不强塞。再看 App 短信登录策略。它的特殊之处在于不再有用户名密码互查而是直接用手机号查用户用户不存在则走快速注册流程。Component public class AppSmsLoginStrategy implements LoginStrategy { private final UserMapper userMapper; private final TokenService tokenService; private final SmsValidateService smsValidateService; public AppSmsLoginStrategy(UserMapper userMapper, TokenService tokenService, SmsValidateService smsValidateService) { this.userMapper userMapper; this.tokenService tokenService; this.smsValidateService smsValidateService; } Override public String supportLoginType() { return app_sms; } Override public LoginResult login(LoginRequest request) { smsValidateService.validate(request.getPhone(), request.getSmsCode()); User user userMapper.selectByPhone(request.getPhone()); if (user null) { user userMapper.createQuickUser(request.getPhone()); } String token tokenService.generateToken(user.getId(), request.getClientType()); return LoginResult.success(token, user); } }这里有个实操细节像 smsValidateService.validate 校验失败抛异常时最好抛业务异常 BusinessException便于统一异常处理器捕捉。千万避开在策略内部返回 LoginResult.error 之类的对象让策略只负责业务成败统一结果对象的结构由外层封装职责会更清晰也避免调用方还要处理半成功半失败的状态。最后一个微信扫码登录策略。拿到的 wxCode 是临时授权码需要向微信接口换取 openId 和用户信息再在自己的系统里找到对应的用户。这个策略跟另外两个核心差异在于要调外部接口而且有网络超时、code 过期这些风险异常处理要额外关注。Component public class WxScanLoginStrategy implements LoginStrategy { private final UserMapper userMapper; private final TokenService tokenService; private final WxAuthService wxAuthService; public WxScanLoginStrategy(UserMapper userMapper, TokenService tokenService, WxAuthService wxAuthService) { this.userMapper userMapper; this.tokenService tokenService; this.wxAuthService wxAuthService; } Override public String supportLoginType() { return wx_scan; } Override public LoginResult login(LoginRequest request) { String openId wxAuthService.getOpenIdByCode(request.getWxCode()); User user userMapper.selectByOpenId(openId); if (user null) { throw new BusinessException(该微信尚未绑定任何账号); } String token tokenService.generateToken(user.getId(), request.getClientType()); return LoginResult.success(token, user); } }三个策略写下来你会发现它们各自只关心自己的登录来源登录成功之后的 token 生成、用户信息返回全都在各策略内部依赖同一个 TokenService 完成这样保证多端的登录结果结构一致。对前端来说不管什么端登录拿到的都是 token 加用户信息使用体验是统一的。3.4 统一入口的 Controller 层改造Controller 这层就非常简单了因为真正的复杂性已经被策略和工厂消化掉了。RestController public class LoginController { private final LoginStrategyFactory strategyFactory; public LoginController(LoginStrategyFactory strategyFactory) { this.strategyFactory strategyFactory; } PostMapping(/login) public ResultLoginResult login(RequestBody Validated LoginRequest request) { return Result.ok(strategyFactory.getStrategy(request.getLoginType()).login(request)); } PostMapping(/logout) public ResultVoid logout(RequestHeader(Authorization) String token) { tokenService.invalidate(token); return Result.ok(); } }一个 login 接口一个 logout 接口所有端共用。新增登录方式时Controller 一行不用改工厂一行不要动只要新增策略类。这就是我们前面说的“扩展开放、修改关闭”真正落到代码上的样子。前端调登录接口时只需要多传一个 loginType 字段成本几乎可以忽略。3.5 策略选择器的兜底与日志虽然有了统一入口我还是建议在工厂的 getStrategy 上加一个兜底登录类型不合法的时候不要返回 null直接抛异常。这能省掉 Controller 层的判空逻辑也避免前端拿空对象以为登录成功了。我再补一个判断技巧如果你发现某个策略里需要根据字段再走一大段 if-else那说明你策略粒度没拆分好。比如同样是 App 端密码登录、验证码登录、生物识别登录就应该继续拆成三个策略类。宁可多几个小类也不要在一个类里再次出现分支地狱。判断粒度是否合适的标准很简单这个类能不能用一句话说清自己的职责能就继续用不能就继续拆。4. 向真实场景延伸验证码、扫码登录与多端互斥4.1 用策略模式快速扩展新的登录方式我们的工厂方案天然适合不停新增登录方式。假设下一版要支持“管理后台 OTP 动态口令登录”就新增一个 AdminOtpLoginStrategysupportLoginType 填 admin_otp然后实现校验 OTP、查询管理员用户、生成 token 的逻辑。完成后它自动被 Spring 发现工厂的 List 注入时自动带上它无需改动任何老代码。这种扩展带来的直接收益是产品经理每提一个新登录需求我们不用再评估“改登录方法会不会影响其他端”因为从设计上就已经切割干净了。这种安全感是做登录模块最需要的。我见过太多项目因为登录逻辑不敢动导致新需求一拖再拖最后拖成技术债。有了这套结构新需求来了就是“复制一个类改一改”的事效率完全不一样。4.2 多端互斥与 token 管理方案多端登录有时候不只是“都能登录”还要控制“同一账号能否同时在多端在线”。这在运营后台、财务后台这类安全要求高的场景里很有必要。我一般在 TokenService 里做两个动作一是生成 token 时带上用户唯一标识和端标识二是维护一张 token 状态表记录 token 与用户、端的绑定关系。如果业务要求互斥就在生成新 token 时把该用户其他端或者同端旧 token 标记失效。这里最容易被忽略的是“端标识”。如果所有端生成的都是同一种无差异 token那互斥就没法做到精细颗粒度。我们的策略类里应该把 clientType 从 LoginRequest 里取出来再传给 tokenService.generateToken。这样 TokenService 在生成 token 时可以拼上端信息互斥逻辑也能按端做不同策略同端互斥、多端各自在线还是只能单一在线这些都是配置化的。给一个更简洁的做法TokenService 里维护一个存有效 token 的关系表key 是 userId 加 clientTypevalue 是当前有效 token。登录时如果发现已有有效 token 且要求互斥则先把旧 token 加入黑名单再签新的。因为工厂模式下各策略都走同一个 TokenService所以互斥策略能一致地生效不会出现某个端绕开了规则。黑名单可以用 RedisTTL 设置为 token 剩余有效期自然过期也不怕。4.3 兼容老接口渐进式改造怎么过渡如果你跟我的情况一样不是从零写新项目而是改造一个已经上线多年的老登录接口那别急着把老接口拆掉。稳妥的做法是保留老的 /login/auth 接口对外不可变内部把它适配到工厂模式的调用上也就是让老接口也调用 strategyFactory.getStrategy(pc_password)这样前端不用改后端换了一颗“新心脏”等全量验证通过后再让前端切换新接口。渐进式改造的关键在于灰度。我建议在改造后加上一行日志把 loginType 和策略类名打出来可以很方便地在链路里确认实际执行了哪个策略类避免“明明切了新逻辑线上却还在走老分支”这种尴尬。上线之后先观察几天重点看错误率有没有变化登录成功率是否正常确认没问题后再切流量这一步不能省。5. 踩坑记录与排查套路5.1 策略 Bean 没有被注入现象是启动报错或者调用时提示策略找不到。我遇到过的一个高发原因是策略类放在扫描包之外Spring 没有把它注册成 Bean自然就不在工厂的 List 里。解决办法很简单要么把类移进扫描路径要么在配置类里用 Bean 方式显式注册。第二种高发原因是有两个类返回了相同的 supportLoginType。Collectors.toMap 在遇到重复 key 时默认会抛 IllegalStateException启动时就失败反而帮我们提前暴露了问题。我自己的习惯是把登录类型的常量统一放在一个枚举或者常量类里禁止用裸字符串到处散落这样重复的概率就低很多。5.2 Bean 命名冲突与类型区分当策略类名以相同单词开头时Spring 默认的 Bean 名字可能会冲突。比如你的策略实现类叫 WxQrcodeLoginStrategy 和 WxScanLoginStrategy同时你还想手动写 Bean 方法可能会遇到 Bean 名重复的问题。我的建议是策略类一律采用“端加方式加 Strategy”的命名风格是否显式命名 Bean 都不要紧因为我们的工厂是通过 supportLoginType 来区分的不依赖 Bean 名字。真正要警惕的是 Bean 方法重名。如果两个配置类里都有 Bean 方法返回 LoginStrategy而且方法名一样Spring 会直接报错。遇到这种情况我给 Bean 方法加上不同的名字或者干脆让策略类自己加 Component不要重复注册。越是依赖自动装配越要留意这些隐式规则。5.3 策略对象里的循环依赖如果一个策略依赖 ServiceBServiceB 又反过来依赖策略那在 Spring 里就会形成循环依赖。虽然 Spring Boot 2.6 开始把循环依赖默认禁止了但老项目开着允许开关代码会继续转起来只是性能有损耗而且结构上有隐患。遇到这种情况我的做法是调整依赖方向抽出一个中间层。比如把 token 生成抽成独立的 TokenService让 ServiceB 依赖 TokenService 而不是依赖具体策略这样策略和服务之间的耦合就切开了。循环依赖看起来是配置问题其实是设计问题别用 Lazy 敷衍把依赖方向理清楚才是根治。5.4 快速定位当前执行了哪个策略线下调试的时候最直接的办法是在工厂的 getStrategy 方法里加一行日志打印登录类型和找到的策略类名。public LoginStrategy getStrategy(String loginType) { LoginStrategy strategy strategies.get(loginType); if (strategy null) { throw new IllegalArgumentException(未找到对应的登录策略: loginType); } log.info(获取到登录策略: {} - {}, loginType, strategy.getClass().getSimpleName()); return strategy; }线上排查时这行日志是救命稻草。用户反馈某个端登录不了我们第一反应就是看日志里走的是哪个策略类。如果登录类型值和策略类对不上基本就是前端传错参数或者配置没有刷到最新版本。如果日志显示策略类正确但没有拿到业务数据就得往下面去查具体策略里依赖的 Service 和外部接口排查范围一下子就能缩小。5.5 单测怎么写才有效最后补一个我自己的测试习惯。策略类因为职责单一单测反而非常好写。针对每个策略覆盖成功分支、参数缺失分支、校验失败分支、用户不存在分支就够了。工厂类只需要测试两个点存在的 loginType 能返回正确策略不存在的 loginType 抛异常。Controller 层做接口级测试时直接通过 MockMvc 调用再断言返回的 token 是否生成成功。这样一套测试下来改动任何一个策略都不会波及其他端的测试回归范围小信心足。这套方案我在好几个项目里落地过最大的体会不是“代码变好看了”而是“功能迭代的压力变小了”。以前听到新登录需求就头大现在拿到需求基本就是新建一个策略类写自己的业务测试也只需要针对这个新类做单测。不是所有场景都需要设计模式但登录这种天然带有多种变体、且变体会不断增长的业务确实是策略加工厂最典型的适用场景。如果你现在正被一段几百行的 login 方法折磨可以先按这个思路把接口抽出来再把分支挪到策略类里跑通一个端之后再逐步迁移其他端。这中间踩坑的过程能让你对 Spring 容器和设计模式的理解深一个档次。
