概述之前搭好了工程骨架并跑通了验证码登录这条完整链路今天要做的是在这条链路之上把用户资料补齐——文件存储、人脸识别、资料保存与头像上传外加两项横切优化统一 token 处理、统一异常处理。本文以回顾之前为主线把第一天的登录链路完整串一遍说清每个环节沉淀了什么可复用的东西再看它们如何被今天的任务逐一复用。纲要之前做了什么五个必须掌握的知识点回顾登录链路时序短信验证码 → Redis 校验 → Dubbo 查库/自动注册 → JWT 颁发 token每个环节沉淀的可复用产出自动装配套路、Dubbo 服务三件套、JWT 工具、BasePojo 自动填充这些地基今天怎么被复用对照表现在要做什么五个板块一句话预告将来结束时工程新增了哪些类实际工程结构学习建议与常见误解澄清之前做了什么之前的知识点不算多但每一个都直接决定了今天怎么写代码。先把五个点摆出来知识点关键内容落地的代码前后端分离开发思想前后端只通过 API 接口约定交互接口传 JSON 数据接口文档YApi驱动开发工程结构与调用过程客户端请求进mf-app-server内部以 Dubbo 形式构建微服务7 个 Maven 模块的聚合工程公共组件抽取借助 SpringBoot 自动装配把发短信抽成公共组件跨模块复用mf-autoconfig模块 SmsTemplateJWT 鉴权思想登录成功颁发 token其余接口校验 tokenJwtUtils工具类用户登录两步走获取登录验证码、用验证码完成登录校验LoginControllerUserService光看表格还不够这些点在登录链路里是连成一条线的。登录链路时序MySQLUserApi (Dubbo)RedisSmsTemplateUserServiceLoginController客户端(APP)MySQLUserApi (Dubbo)RedisSmsTemplateUserServiceLoginController客户端(APP)alt[用户不存在首次登录]POST /user/login (mobile)sendCode(mobile)生成随机验证码sendSms(mobile, code)下发短信SET CHECK_CODE_{mobile} codePOST /user/loginVerification (mobile, code)login(mobile, code)GET CHECK_CODE_{mobile} 并比对DEL 验证码一次性使用findByMobile(mobile)select * from tb_usersave(user) 自动注册isNew trueJwtUtils.getToken(id, mobile)token isNew两个分支值得留意验证码校验失败直接抛异常结束校验通过后findByMobile返回null时走自动注册分支isNewtrue会传给前端客户端据此跳转完善信息页——这正是今天 day02 的入口场景。每个环节产出了什么可复用的东西回顾的目的不是背流程而是认出昨天留下的套路。之前真正值钱的是四套可复用的模式。自动装配套路SmsTemplate 四件套。发短信这种第三方能力被抽成公共组件靠的是 SpringBoot 自动装配的标准四件套spring.factories声明、自动装配类、属性配置类、模板对象。业务模块只注入SmsTemplate就能用不感知 AccessKey、签名、模板编号这些细节。packagecom.mf.autoconfig;importcom.mf.autoconfig.properties.SmsProperties;importcom.mf.autoconfig.template.SmsTemplate;importorg.springframework.boot.context.properties.EnableConfigurationProperties;importorg.springframework.context.annotation.Bean;EnableConfigurationProperties({SmsProperties.class})publicclassmfAutoConfiguration{BeanpublicSmsTemplatesmsTemplate(SmsPropertiessmsProperties){returnnewSmsTemplate(smsProperties);}}packagecom.mf.autoconfig.properties;importlombok.Data;importorg.springframework.boot.context.properties.ConfigurationProperties;DataConfigurationProperties(prefixmf.sms)publicclassSmsProperties{privateStringsignName;privateStringtemplateCode;privateStringaccessKey;privateStringsecret;}配套的/META-INF/spring.factories只有两行org.springframework.boot.autoconfigure.EnableAutoConfiguration\ com.mf.autoconfig.mfAutoConfigurationDubbo 服务三件套。任何一类数据要跨服务访问都是同一套动作mf-model里定义实体mf-dubbo-interface里定义 Api 接口mf-dubbo-db里用DubboService给出实现并注入 Mapper。昨天为User建了UserApi/UserApiImpl/UserMapper这三件UserApiImpl的实现短到只有几行——因为 MyBatis-Plus 的BaseMapper把 SQL 都包了。JWT 工具与 ErrorResult。JwtUtils提供三个静态方法getToken签发写入 id/mobile1 小时有效期、getClaims解析、verifyToken校验有效性异常一律返回 false。错误响应则统一走ErrorResult用静态工厂方法枚举各类错误loginError、faceError……错误码字符串约定成俗。BasePojo 与自动填充。所有实体的created/updated字段抽进BasePojo基类配合 MyBatis-Plus 的MetaObjectHandler在插入和更新时自动填充时间业务代码从此不用手动 setpackagecom.mf.dubbo.server.handler;importcom.baomidou.mybatisplus.core.handlers.MetaObjectHandler;importorg.apache.ibatis.reflection.MetaObject;importorg.springframework.stereotype.Component;importjava.util.Date;ComponentpublicclassMyMetaObjectHandlerimplementsMetaObjectHandler{OverridepublicvoidinsertFill(MetaObjectmetaObject){ObjectcreatedgetFieldValByName(created,metaObject);if(nullcreated){//字段为空可以进行填充setFieldValByName(created,newDate(),metaObject);}ObjectupdatedgetFieldValByName(updated,metaObject);if(nullupdated){//字段为空可以进行填充setFieldValByName(updated,newDate(),metaObject);}}OverridepublicvoidupdateFill(MetaObjectmetaObject){setFieldValByName(updated,newDate(),metaObject);}}这些地基今天怎么被复用这是本文最想让你带走的一张表。现在的每个板块都不是从零开始而是把昨天的套路原样再用一遍之前的产出现在怎么用自动装配套路spring.factories Properties Template 四件套照此封装OssTemplate阿里云 OSS 文件存储和AipFaceTemplate百度人脸识别mfAutoConfiguration里各加一个BeanDubbo 服务三件套Api 接口 / DubboService 实现 / Mapper为用户资料域新增UserInfoApi/UserInfoApiImpl/UserInfoMapper动作和昨天的UserApi一模一样拦截器 ThreadLocal 雏形JwtUtils.verifyToken 已能校验 token今天把它正式成型TokenInterceptor统一鉴权 UserHolder存取当前用户各控制器不再重复解析 tokenJWT 工具token 里存了 id、mobile查询/更新资料时直接从 token 取当前用户 id作为tb_user_info的主键来源BasePojo 自动填充UserInfo实体继承BasePojo创建/更新时间零代码维护ErrorResult 错误码约定今天升级为BusinessExceptionRestControllerAdvice的统一异常处理同一套自动装配模式一天之内会写两遍OSS、人脸这不是重复劳动而是在验证套路的通用性——这也是导引篇想强调的今天每一块都站在昨天的地基上。现在要做什么内容比昨天多五个板块各一句话板块一句话概括完善用户信息新用户首次登录后强制完善详细资料并上传头像涉及阿里云 OSS、百度人脸识别两个第三方组件的接入与模板抽取用户信息管理用户资料的查询与更新修改手机号、所在地等本质是对tb_user_info的增删改查统一 token 处理用拦截器 ThreadLocal 消灭每个接口里重复的 token 解析与校验代码统一异常处理用RestControllerAdvice把散落各处的 try-catch 收拢到一处这里只做导引不展开实现细节——每个板块的接口文档、执行流程、代码步骤与验收标准见同目录的《完善用户信息-业务概述》那里是 现在的开工任务书。将来结束时工程长什么样以实际工程快照为准相对 之前 新增的类如下标注新增mf ├── mf-app-server │ └── src/main/java/com/mf/server │ ├── AppServerApplication.java │ ├── controller │ │ ├── LoginController.java │ │ ├── UserController.java # 新增保存资料/上传头像 │ │ └── UsersControler.java # 新增资料查询/更新 │ ├── exception │ │ ├── BusinessException.java # 新增业务异常对象 │ │ └── ExceptionAdvice.java # 新增统一异常处理 │ ├── interceptor │ │ ├── TokenInterceptor.java # 新增统一鉴权拦截器 │ │ ├── UserHolder.java # 新增ThreadLocal 工具类 │ │ └── WebConfig.java # 新增注册拦截器 │ └── service │ ├── UserService.java │ └── UserInfoService.java # 新增 ├── mf-autoconfig │ └── src/main/java/com/mf/autoconfig │ ├── mfAutoConfiguration.java # 修改注册 Oss/AipFace 两个 Bean │ ├── properties │ │ ├── SmsProperties.java │ │ ├── OssProperties.java # 新增 │ │ └── AipFaceProperties.java # 新增 │ └── template │ ├── SmsTemplate.java │ ├── OssTemplate.java # 新增 │ └── AipFaceTemplate.java # 新增 ├── mf-commons │ └── .../utils/JwtUtils.java ├── mf-model │ └── src/main/java/com/mf/model │ ├── domain │ │ ├── BasePojo.java │ │ ├── User.java │ │ └── UserInfo.java # 新增用户资料实体 │ └── vo │ ├── ErrorResult.java │ └── UserInfoVo.java # 新增资料返回值对象 └── mf-dubbo ├── mf-dubbo-interface │ └── .../api │ ├── UserApi.java │ └── UserInfoApi.java # 新增 └── mf-dubbo-db └── src/main/java/com/mf/dubbo ├── api │ ├── UserApiImpl.java │ └── UserInfoApiImpl.java # 新增 ├── handler/MyMetaObjectHandler.java └── mappers ├── UserMapper.java └── UserInfoMapper.java # 新增一天下来新增约 15 个类但拆开看几乎没有新模式OssTemplate/AipFaceTemplate是 SmsTemplate 的翻版UserInfoApi三件套是UserApi的翻版真正的新东西只有拦截器 ThreadLocal 和RestControllerAdvice这两处。学习建议昨天的自动装配套路今天会原样复用两次OSS、人脸建议边写边对比同一套路在不同能力上的差异属性项不同OSS 是 endpoint/bucket/accessKey人脸是 appId/apiKey/secretKey、模板方法不同上传 vs 检测骨架却完全一致。能在差异中认出共性这套模式才算真正学会。今天有两个安全主题——统一鉴权与统一异常处理别急着抄代码先理解动机鉴权统一是为了消灭N 个接口各写一遍 token 解析的重复异常统一是为了让ErrorResult的约定不再依赖每个人自觉 try-catch。动机清楚了TokenInterceptor和ExceptionAdvice的写法都是自然推导。UserHolder用完要remove()。线程池里的线程是复用的ThreadLocal 不清理上一个请求的用户信息会串到下一个请求——这是这套方案最经典的坑。常见误解澄清误解实际情况JWT 是加密payload 看不懂JWT 只做签名防篡改payload 部分A.B.C 中的 BBase64 解码即可读。所以 token 里只放 id、mobile 这类非敏感字段绝不能放密码首次登录自动注册 用户点了注册按钮没有注册页。验证码校验通过后findByMobile查不到用户就落库一条passwordmd5(123456)的记录isNewtrue由前端引导去完善资料自动装配只是课上为了发短信做的特殊处理spring.factories ConfigurationProperties 模板对象是编写 starter 的标准做法今天接 OSS 和人脸识别时原样复用属于全项目通用的基础设施模式拦截器和过滤器是一回事两者都能前置/后置处理请求但拦截器是 SpringMVC 的机制能拿到 handler 信息、依赖 Spring 容器配合 ThreadLocal 做登录校验更顺手过滤器工作在 Servlet 层粒度更粗总结之前 表面只交付了一个登录功能实际沉淀了四套可复用模式自动装配四件套、Dubbo 服务三件套、JWT 工具、BasePojo 自动填充。现在 的五个板块全部建立在这些地基上——OSS 与人脸识别是装配套路的第二次、第三次落地UserInfoApi是 Dubbo 三件套的复制统一 token 处理则把昨天登录成功颁发 token的下半句其余接口校验 token补齐成型。带着昨天怎么做的去读今天每个板块代码会好懂很多实现层面的任务拆解与验收标准直接翻《完善用户信息-业务概述》。