简介这份PDF资料面向正在准备求职面试的开发者尤其是需要梳理项目经历、优化简历表达的技术人员围绕「面试中如何表达项目、简历中如何编写项目」这一主题以中州养老系统为完整案例示范如何把真实项目讲清楚、写到位。资料共1个PDF文件压缩包约130KB篇幅精炼便于随时查阅和对照修改。内容覆盖项目概述与技术栈、微信小程序端登录与参观预约模块、后台RBAC权限控制与Spring Security认证授权机制以及需求分析、数据库设计、接口文档编写和测试优化等服务开发流程并附有可直接参考的简历描述示例包括项目背景、技术栈、个人职责与成果的写法。已有546人学习适合需要把项目经验转化为面试话术和简历亮点的初中级开发者也可作为梳理项目模块、提炼个人贡献的参考模板。1. 面试讲项目总被追问细节问题多半出在简历那一行简历上写“负责登录模块开发”面试官问一句“登录怎么做的”答“调微信接口拿 openid 生成 token”然后就没有然后了。这不是表达问题是简历里根本没有可被追问的技术锚点。中州养老系统这类单体前后端分离项目恰恰是面试素材的富矿微信登录链路、JWT 与 UUID 组合防重放、RBAC 五表模型、Xxl-job 三种调度模式、Spring Security 过滤器链每一个都能撑起十分钟的深聊。这份资源的价值不在于项目本身多复杂而在于它把“简历怎么写”和“面试怎么讲”拆成了可复用的结构简历行负责埋钩子面试叙述负责把钩子拉成完整的技术故事。适合正在准备求职面试、手里有项目但讲不出深度的初中级后端也适合带人做项目复盘的技术负责人。2. 简历项目行怎么写把“负责XX模块”改造成可追问的技术锚点简历上的项目描述不是工作汇报是给面试官出题。你写的每一行都应该预判对方会从哪个词切进来。中州养老系统原文的简历描述里“负责微信小程序登录、权限分配、参观预约、护理项目等模块的开发与设计”这句话本身没错但信息密度太低——面试官看到“登录”只会问“怎么登录的”看到“权限分配”只会问“用的什么模型”两个问题都撑不过三分钟。改造的方向是把模块名替换成“模块 技术决策 量化结果”的三段式。2.1 从功能描述到技术决策三条改写对照先看原文里几个模块的原始写法再对照改造成面试可追问的版本。改写不是堆技术名词而是把“我做了什么”换成“我在什么约束下选了什么方案”。原始写法问题改写后负责微信小程序登录模块开发只说了模块名没有技术动作基于微信 code2Session 实现小程序静默登录openid 落库做用户去重JWT 携带 UUID 写入 Redis 实现单端登录互斥负责权限分配权限分配是业务动作不是技术方案基于 RBAC 五表模型用户/角色/资源及两张关联表落地权限控制Spring Security 过滤器链完成认证授权分离使用 Xxl-job 实现定时任务只说了工具没说为什么选、怎么配采用 Xxl-job 轮询调度模式处理过期预约状态流转利用其可视化任务管理降低运维排查成本改写的核心逻辑是每个模块至少暴露一个“可被追问的技术点”。登录模块暴露的是“单端登录互斥”权限模块暴露的是“五表模型 过滤器链”定时任务暴露的是“调度模式选型”。面试官顺着任何一个词问下去你都有准备好的三层内容可以展开。2.2 技术栈列表的取舍写五个能讲透的不写十五个只听过名字的原文技术描述列了 SpringBoot、SpringMVC、SpringCache、SpringSecurity、Redis、MySQL、Swagger、OSS、XXL-job 九项。这个列表的问题不是多是平——九项并列面试官不知道哪项是你的主战场。常见做法是分两行第一行写“核心使用”三到四项第二行写“了解/集成”其余项。核心项必须满足一个条件你能在不看笔记的情况下讲清楚它在项目里解决的具体问题、配置的关键参数、以及踩过的一个坑。以中州养老系统为例核心项建议锁定 Spring Security、Redis、Xxl-job 三项。Spring Security 对应认证授权全链路Redis 对应 token 存储与热点缓存Xxl-job 对应定时任务调度。这三项每一项都能延伸出十五分钟以上的技术对话。Swagger 和 OSS 放第二行面试官问起来能说清“用 Swagger 生成在线接口文档做前后端联调”“OSS 存老人头像和护理记录附件”即可不必展开。提示技术栈里出现但讲不透的词是面试中的负资产。面试官挑一个你只写过 demo 的技术深问翻车概率远高于你少写两项。2.3 项目背景一句话用业务约束反衬技术选型原文的项目背景写的是“通过小程序端完成对老人选择服务项目实现为老人的提供生活、医疗、护理等方面的服务和照顾”这是业务价值描述放在简历里占了两行却产生不了技术追问。更有效的写法是用业务约束带出技术选型理由比如“养老院护工流动性高、后台操作人员计算机水平有限因此后台权限模型采用 RBAC 而非更细粒度的 ABAC降低角色配置的培训成本小程序端面向老人家属登录链路必须无感故采用微信静默登录 JWT 续期方案。”这样一句话同时完成了三件事交代了业务场景、解释了技术选型的约束条件、埋下了“为什么不用 ABAC”“JWT 怎么续期”两个追问点。面试官顺着问你答的是选型权衡而不是背功能列表。简历项目描述的篇幅有限每一行都要承担“引出对话”的功能纯背景铺垫能压则压。3. 面试讲登录链路从 code2Session 到 JWT 续期四层递进怎么铺微信登录是这类项目里最容易被问穿的部分因为链路长、边界多面试官稍微往下探一层就能区分“调过接口”和“设计过链路”。原文对登录的描述已经比较完整前端拿手机号校验码和微信身份校验码后端拿校验码换 openid查库判断新老用户生成 JWT 返回。但面试讲述不能照搬这段流程要按“为什么这么设计 → 关键参数怎么定 → 异常怎么兜”的顺序铺开。3.1 第一层为什么是 code2Session 而不是前端直接传 openid面试官问“登录怎么做的”很多人第一反应是“前端调微信登录拿 openid 传给后端”。这个答法直接暴露安全认知缺口——openid 由前端传递意味着可伪造任何人构造一个 openid 就能冒充用户。正确链路是前端只拿临时凭证 code后端用 code appid secret 调微信服务端换 openidsecret 永远不出现在客户端。// 小程序端只拿 code不碰 openid wx.login({ success: (res) { if (res.code) { // code 五分钟内有效且只能使用一次 wx.request({ url: https://your-domain.com/api/auth/login, method: POST, data: { code: res.code, phoneCode: phoneCode } }) } } })这段前端代码的关键约束是code 有效期五分钟、一次性消费。面试时主动说出这两个参数面试官会默认你处理过“code 过期”和“code 重复使用”的异常分支。后端侧对应逻辑是用 code 换 openid 的 HTTP 调用需要设置连接超时和读取超时常见做法是各设三秒超时后返回“登录繁忙请重试”而不是抛 500。3.2 第二层openid 落库与手机号变更的幂等处理拿到 openid 之后查本地用户表原文写的是“判断该用户是否是新用户进行添加新用户如果存在则判断手机号是否改变进行数据更新”。这段逻辑面试时要讲出幂等意识同一个 openid 并发两次登录请求可能同时走“查不到 → 插入”分支产生两条用户记录。解决办法是在 openid 字段建唯一索引插入冲突时捕获异常转为更新操作。-- 用户表关键约束openid 唯一索引是幂等的最后一道防线 ALTER TABLE sys_user ADD UNIQUE INDEX uk_openid (openid);手机号变更的判断也有讲究。微信手机号授权返回的号码可能因为用户换绑而变化更新时不能简单覆盖要记录变更时间。面试官如果追问“手机号变了历史订单怎么关联”答“订单表关联的是用户主键而非手机号手机号仅作展示和通知用途”即可闭环。这个追问点很常见提前想清楚关联关系比临场编造强。3.3 第三层JWT 里放什么、不放什么原文的设计是“将用户信息作为 JWT 的数字签名生成 token”更准确的表述是用户标识作为 payload 的一部分参与签名。面试时要能说清 payload 的取舍放用户 ID、UUID、过期时间不放手机号、角色列表、权限码。原因有两个——JWT 是 Base64 编码不是加密任何人可解码查看角色权限放进去会导致权限变更后旧 token 仍然携带旧权限必须等过期才生效。# JWT payload 构造示例只放标识权限实时查 import jwt, time, uuid payload { userId: user_id, uuid: str(uuid.uuid4()), # 与 Redis 中的 UUID 比对实现单端登录 exp: int(time.time()) 1800 # 30 分钟过期 } token jwt.encode(payload, SECRET_KEY, algorithmHS256)参数说明exp 设三十分钟是原文“低于阈值自动续期”的前提阈值一般取剩余时间小于十分钟时触发续期。uuid 的作用是单端登录互斥——同一账号后登录的请求会覆盖 Redis 中的 UUID旧 token 解析出的 uuid 与 Redis 不一致直接返回 403。面试时把“UUID 防重放”讲成“单端登录互斥 旧凭证失效”比背“防止重放攻击”更具体也更容易接住“多端登录怎么支持”的追问答UUID 按设备维度存储或改为 token 版本号机制。3.4 第四层过滤器链里的认证与授权分离原文对授权流程的描述很细取 UUID 判空、取 Redis 中 JWT 解析、比对 UUID、校验存活时间、续期、判断资源权限。面试讲述时不要平铺这个流程要按“认证过滤器”和“授权决策”两段拆。认证过滤器只做三件事token 是否存在且可解析、UUID 是否与 Redis 一致、是否需要续期。授权决策交给 Spring Security 的 AccessDecisionManager基于 RBAC 五表查出的资源列表做匹配。// 认证过滤器核心判断顺序顺序错了会出安全问题 String uuid request.getHeader(uuid); if (StringUtils.isEmpty(uuid)) { response403(); return; } String redisToken redis.get(login: uuid); if (redisToken null) { response403(); return; } Claims claims parseJwt(redisToken); // 解析失败抛异常同样 403 if (!uuid.equals(claims.get(uuid))) { response403(); return; } // 单端互斥 long remain claims.getExpiration().getTime() - System.currentTimeMillis(); if (remain 10 * 60 * 1000) { refreshToken(uuid, claims); } // 续期 chain.doFilter(request, response); // 放行到授权决策这段代码的讲述重点是判断顺序先判空再查 Redis 再解析再比对每一步失败都返回 403 而不是 401因为对前端而言都是“凭证不可用”统一状态码减少前端分支。续期逻辑放在过滤器里而不是拦截器里是因为过滤器在请求进入 Servlet 之前执行续期后的新 token 可以通过响应头带回前端。面试官如果问“续期时旧 token 还能用吗”答“续期是延长 Redis 中 token 的过期时间并签发新 token旧 token 在自然过期前仍有效但 UUID 不变所以不触发互斥”这个细节能体现你真的跑过这条链路。4. 权限与定时任务怎么讲出深度RBAC 五表与 Xxl-job 调度模式权限和定时任务是中州养老系统里两个“看起来简单、问起来有层次”的模块。RBAC 五表模型几乎所有后台项目都有但能讲清“为什么是五张表而不是三张”“多对多关系怎么查”的人不多Xxl-job 三种调度模式原文列了轮询、分片广播、故障转移但面试官更想听“你的场景为什么选轮询”。这两块讲好了能显著拉开和其他候选人的差距。4.1 RBAC 五表多对多关系为什么必须拆关联表原文说“资源和角色之间是多对多的关系需要通过第三张表来维护二者的关系角色和用户之间的关系也是多对多”。面试时要能画出表结构并解释拆表理由一个角色拥有多个资源一个资源可被多个角色引用如果直接在角色表里存资源 ID 列表比如逗号分隔字符串查询“拥有某资源的角色”需要全表扫描字符串匹配无法建索引权限校验性能随数据量线性下降。拆成 role_resource 关联表后两个字段各建索引双向查询都是索引命中。-- 五表核心结构关联表的主键组合即联合唯一索引 CREATE TABLE sys_user (id BIGINT PRIMARY KEY, username VARCHAR(64), openid VARCHAR(64)); CREATE TABLE sys_role (id BIGINT PRIMARY KEY, role_name VARCHAR(64)); CREATE TABLE sys_resource (id BIGINT PRIMARY KEY, resource_url VARCHAR(255), resource_type TINYINT); CREATE TABLE sys_user_role (user_id BIGINT, role_id BIGINT, PRIMARY KEY(user_id, role_id)); CREATE TABLE sys_role_resource (role_id BIGINT, resource_id BIGINT, PRIMARY KEY(role_id, resource_id));参数说明resource_type 区分菜单、按钮、接口三类资源授权时按类型分别处理——菜单控制前端路由显示按钮控制页面元素接口控制后端放行。面试官常追问“用户有多个角色权限怎么合并”答“查 user_role 得角色集合再查 role_resource 得资源并集去重后作为授权依据”并补一句“并集查询用 IN 加 DISTINCT角色数量少时性能可接受角色多时考虑缓存用户权限快照”。这个补充能体现你对性能边界的判断。4.2 Xxl-job 三种调度模式轮询、分片广播、故障转移的适用边界原文列了三种模式但没说选型理由面试时这正是加分点。轮询模式适合“任务可拆分、每个执行器处理一部分”的场景比如过期预约状态修改按预约 ID 取模分发到不同执行器避免单点压力。分片广播是“一次调度广播到所有执行器每个执行器都执行一次”适合“每个节点都要做本地清理”的场景比如清理本机临时文件。故障转移是“执行器故障时任务转移到其他可用执行器”适合“任务不可拆分但要求高可用”的场景。// Xxl-job 轮询模式的任务处理器分片参数决定处理范围 XxlJob(expireAppointmentHandler) public void expireAppointment() { int shardIndex XxlJobHelper.getShardIndex(); // 当前分片序号 int shardTotal XxlJobHelper.getShardTotal(); // 分片总数 // 按 id 取模分片每个执行器只处理自己那部分 ListLong ids appointmentMapper.selectExpiredIds(shardIndex, shardTotal); for (Long id : ids) { appointmentMapper.updateStatus(id, STATUS_EXPIRED); } XxlJobHelper.log(分片 {} 处理 {} 条, shardIndex, ids.size()); }参数说明shardIndex 从 0 开始shardTotal 是执行器集群数量取模条件写在 SQL 的 where 里id % #{shardTotal} #{shardIndex}避免全量数据拉到内存再过滤。面试时主动说“轮询模式下如果某个执行器宕机它负责的分片在故障转移开启前不会被处理”面试官会认可你对边界条件的认知。原文提到“项目中使用的是轮询方式”把这个选择和上面的边界一起讲比单纯背三种模式的定义有说服力得多。4.3 服务项目开发流程需求分析到联调测试的讲述顺序原文最后一段写“通过需求分析完成对数据表、实体类的设计。编写接口文档编码。联调测试”。这段在面试里容易被讲成流水账正确的讲法是突出“文档先行”和“联调前置”。接口文档用 Swagger 在编码前定义好请求响应结构前后端并行开发联调时只对字段不对逻辑。数据库表设计先画 ER 图确认多对多关系再落 DDL避免编码中途改表结构导致实体类返工。面试官如果问“需求分析具体做了什么”不要答“和产品经理开会”要答“把护理项目模块拆成项目字典、服务下单、服务记录三张表确认下单与记录是一对多、项目与记录是多对一据此定外键和索引”。用具体的表和关系回答比流程名词有信息量。联调测试阶段常见做法是先用 Swagger 的 mock 数据跑通前端页面再切真实接口减少前后端互相等待的时间。5. 避坑项目讲述里最容易翻车的五个地方5.1 现象面试官问“JWT 怎么防重放”答“加了 UUID 就防了”原因UUID 防的是“同一账号多端登录互斥”不是重放攻击。重放攻击是攻击者截获请求后原样重发UUID 在请求头里跟着走重发照样通过。真正的防重放需要时间戳 nonce 校验或一次性签名。解决面试时把 UUID 的作用准确表述为“单端登录互斥与旧凭证失效”如果被追问重放坦诚说“当前方案未做请求级防重放生产环境可加时间戳窗口校验”比硬答“防了”安全得多。5.2 现象讲 RBAC 时说“用户表里存角色 ID”原因把多对多关系简化成了一对多面试官一追问“一个用户多个角色怎么存”就露馅。解决明确说“用户与角色通过 sys_user_role 关联表维护多对多用户表不存角色字段”并主动补一句“关联表主键是 user_id role_id 联合主键天然防重复授权”。5.3 现象Xxl-job 说“用了分布式调度所以高可用”原因调度中心高可用不等于任务执行高可用执行器宕机后轮询分片无人接管除非开故障转移。解决讲清“调度中心集群 执行器集群 故障转移策略”三层并说明轮询模式下故障转移的触发条件避免把框架能力当成默认行为。5.4 现象简历写“性能调优”但说不出调了什么原因原文简历描述里有“配合测试人员进行测试和性能调优”这是典型的空话面试官必问“调优调了什么”。解决要么删掉要么换成具体动作比如“热点服务项目信息加 Spring Cache Redis 两级缓存缓存穿透用空值缓存兜底接口 P99 从 800ms 降到 120ms”。没有真实数据就写“参与压测并定位慢 SQL为预约表按状态字段加索引”具体到索引名和字段。5.5 现象项目背景讲了三分钟业务价值技术问题一个没引出原因把简历当宣传册写忽略了面试官只关心技术决策。解决背景压缩到两句话一句业务约束护工流动性高、家属用小程序一句技术结论RBAC 降培训成本、静默登录降使用门槛剩下的篇幅全部留给“为什么这么选”和“踩了什么坑”。6. 把项目讲成故事的最后一步用 STAR 骨架做一次自测简历改完、技术点梳理完还差一道自测能不能在九十秒内把一个模块讲成“背景—任务—行动—结果”的闭环。以参观预约模块为例背景是家属到院参观需要提前预约、过期预约占用护工排班资源任务是实现预约状态自动流转且不依赖单机定时器行动是选 Xxl-job 轮询模式按预约 ID 分片处理配可视化界面便于运营查看任务执行记录结果是过期预约在预约时段结束后十分钟内完成状态更新运营无需人工干预。九十秒讲完面试官自然会从“为什么不用 Spring Task”切进来你答“单体部署时 Spring Task 够用但项目预留了多实例部署可能Xxl-job 的调度中心与执行器分离避免了多实例重复执行”对话就进入了你准备好的领域。自测时准备一张模块-追问对照表每个模块预判三个追问方向模块第一层追问第二层追问兜底答法微信登录code 有效期多久code 重复使用怎么处理一次性消费二次使用微信侧报错后端转登录失败提示JWT 续期续期阈值怎么定续期时旧 token 是否失效阈值取过期时间三分之一旧 token 自然过期前有效但 UUID 不变RBAC为什么不用 ABAC权限变更后已登录用户何时生效权限实时查库不走 token下次请求即生效Xxl-job轮询分片怎么分执行器宕机分片谁接管按业务主键取模故障转移开启后由调度中心重新分配这张表不用背写一遍的过程就是查漏。哪个格子填不出来说明那个模块还没吃透回去翻代码比临场编造强。我自己的习惯是每次面试前把这张表默写一遍填不出的格子标红面试前一晚只补标红项。从那以后我每次改简历都强制走一遍“模块—追问—兜底”三列自测宁可简历少写一个模块也不留讲不透的技术词。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/11/4 23:14:34 · 阅读 1.2k 简历项目怎么写才能扛住面试追问？微信登录、JWT、RBAC与Xxl-job实战拆解
简介这份PDF资料面向正在准备求职面试的开发者尤其是需要梳理项目经历、优化简历表达的技术人员围绕「面试中如何表达项目、简历中如何编写项目」这一主题以中州养老系统为完整案例示范如何把真实项目讲清楚、写到位。资料共1个PDF文件压缩包约130KB篇幅精炼便于随时查阅和对照修改。内容覆盖项目概述与技术栈、微信小程序端登录与参观预约模块、后台RBAC权限控制与Spring Security认证授权机制以及需求分析、数据库设计、接口文档编写和测试优化等服务开发流程并附有可直接参考的简历描述示例包括项目背景、技术栈、个人职责与成果的写法。已有546人学习适合需要把项目经验转化为面试话术和简历亮点的初中级开发者也可作为梳理项目模块、提炼个人贡献的参考模板。1. 面试讲项目总被追问细节问题多半出在简历那一行简历上写“负责登录模块开发”面试官问一句“登录怎么做的”答“调微信接口拿 openid 生成 token”然后就没有然后了。这不是表达问题是简历里根本没有可被追问的技术锚点。中州养老系统这类单体前后端分离项目恰恰是面试素材的富矿微信登录链路、JWT 与 UUID 组合防重放、RBAC 五表模型、Xxl-job 三种调度模式、Spring Security 过滤器链每一个都能撑起十分钟的深聊。这份资源的价值不在于项目本身多复杂而在于它把“简历怎么写”和“面试怎么讲”拆成了可复用的结构简历行负责埋钩子面试叙述负责把钩子拉成完整的技术故事。适合正在准备求职面试、手里有项目但讲不出深度的初中级后端也适合带人做项目复盘的技术负责人。2. 简历项目行怎么写把“负责XX模块”改造成可追问的技术锚点简历上的项目描述不是工作汇报是给面试官出题。你写的每一行都应该预判对方会从哪个词切进来。中州养老系统原文的简历描述里“负责微信小程序登录、权限分配、参观预约、护理项目等模块的开发与设计”这句话本身没错但信息密度太低——面试官看到“登录”只会问“怎么登录的”看到“权限分配”只会问“用的什么模型”两个问题都撑不过三分钟。改造的方向是把模块名替换成“模块 技术决策 量化结果”的三段式。2.1 从功能描述到技术决策三条改写对照先看原文里几个模块的原始写法再对照改造成面试可追问的版本。改写不是堆技术名词而是把“我做了什么”换成“我在什么约束下选了什么方案”。原始写法问题改写后负责微信小程序登录模块开发只说了模块名没有技术动作基于微信 code2Session 实现小程序静默登录openid 落库做用户去重JWT 携带 UUID 写入 Redis 实现单端登录互斥负责权限分配权限分配是业务动作不是技术方案基于 RBAC 五表模型用户/角色/资源及两张关联表落地权限控制Spring Security 过滤器链完成认证授权分离使用 Xxl-job 实现定时任务只说了工具没说为什么选、怎么配采用 Xxl-job 轮询调度模式处理过期预约状态流转利用其可视化任务管理降低运维排查成本改写的核心逻辑是每个模块至少暴露一个“可被追问的技术点”。登录模块暴露的是“单端登录互斥”权限模块暴露的是“五表模型 过滤器链”定时任务暴露的是“调度模式选型”。面试官顺着任何一个词问下去你都有准备好的三层内容可以展开。2.2 技术栈列表的取舍写五个能讲透的不写十五个只听过名字的原文技术描述列了 SpringBoot、SpringMVC、SpringCache、SpringSecurity、Redis、MySQL、Swagger、OSS、XXL-job 九项。这个列表的问题不是多是平——九项并列面试官不知道哪项是你的主战场。常见做法是分两行第一行写“核心使用”三到四项第二行写“了解/集成”其余项。核心项必须满足一个条件你能在不看笔记的情况下讲清楚它在项目里解决的具体问题、配置的关键参数、以及踩过的一个坑。以中州养老系统为例核心项建议锁定 Spring Security、Redis、Xxl-job 三项。Spring Security 对应认证授权全链路Redis 对应 token 存储与热点缓存Xxl-job 对应定时任务调度。这三项每一项都能延伸出十五分钟以上的技术对话。Swagger 和 OSS 放第二行面试官问起来能说清“用 Swagger 生成在线接口文档做前后端联调”“OSS 存老人头像和护理记录附件”即可不必展开。提示技术栈里出现但讲不透的词是面试中的负资产。面试官挑一个你只写过 demo 的技术深问翻车概率远高于你少写两项。2.3 项目背景一句话用业务约束反衬技术选型原文的项目背景写的是“通过小程序端完成对老人选择服务项目实现为老人的提供生活、医疗、护理等方面的服务和照顾”这是业务价值描述放在简历里占了两行却产生不了技术追问。更有效的写法是用业务约束带出技术选型理由比如“养老院护工流动性高、后台操作人员计算机水平有限因此后台权限模型采用 RBAC 而非更细粒度的 ABAC降低角色配置的培训成本小程序端面向老人家属登录链路必须无感故采用微信静默登录 JWT 续期方案。”这样一句话同时完成了三件事交代了业务场景、解释了技术选型的约束条件、埋下了“为什么不用 ABAC”“JWT 怎么续期”两个追问点。面试官顺着问你答的是选型权衡而不是背功能列表。简历项目描述的篇幅有限每一行都要承担“引出对话”的功能纯背景铺垫能压则压。3. 面试讲登录链路从 code2Session 到 JWT 续期四层递进怎么铺微信登录是这类项目里最容易被问穿的部分因为链路长、边界多面试官稍微往下探一层就能区分“调过接口”和“设计过链路”。原文对登录的描述已经比较完整前端拿手机号校验码和微信身份校验码后端拿校验码换 openid查库判断新老用户生成 JWT 返回。但面试讲述不能照搬这段流程要按“为什么这么设计 → 关键参数怎么定 → 异常怎么兜”的顺序铺开。3.1 第一层为什么是 code2Session 而不是前端直接传 openid面试官问“登录怎么做的”很多人第一反应是“前端调微信登录拿 openid 传给后端”。这个答法直接暴露安全认知缺口——openid 由前端传递意味着可伪造任何人构造一个 openid 就能冒充用户。正确链路是前端只拿临时凭证 code后端用 code appid secret 调微信服务端换 openidsecret 永远不出现在客户端。// 小程序端只拿 code不碰 openid wx.login({ success: (res) { if (res.code) { // code 五分钟内有效且只能使用一次 wx.request({ url: https://your-domain.com/api/auth/login, method: POST, data: { code: res.code, phoneCode: phoneCode } }) } } })这段前端代码的关键约束是code 有效期五分钟、一次性消费。面试时主动说出这两个参数面试官会默认你处理过“code 过期”和“code 重复使用”的异常分支。后端侧对应逻辑是用 code 换 openid 的 HTTP 调用需要设置连接超时和读取超时常见做法是各设三秒超时后返回“登录繁忙请重试”而不是抛 500。3.2 第二层openid 落库与手机号变更的幂等处理拿到 openid 之后查本地用户表原文写的是“判断该用户是否是新用户进行添加新用户如果存在则判断手机号是否改变进行数据更新”。这段逻辑面试时要讲出幂等意识同一个 openid 并发两次登录请求可能同时走“查不到 → 插入”分支产生两条用户记录。解决办法是在 openid 字段建唯一索引插入冲突时捕获异常转为更新操作。-- 用户表关键约束openid 唯一索引是幂等的最后一道防线 ALTER TABLE sys_user ADD UNIQUE INDEX uk_openid (openid);手机号变更的判断也有讲究。微信手机号授权返回的号码可能因为用户换绑而变化更新时不能简单覆盖要记录变更时间。面试官如果追问“手机号变了历史订单怎么关联”答“订单表关联的是用户主键而非手机号手机号仅作展示和通知用途”即可闭环。这个追问点很常见提前想清楚关联关系比临场编造强。3.3 第三层JWT 里放什么、不放什么原文的设计是“将用户信息作为 JWT 的数字签名生成 token”更准确的表述是用户标识作为 payload 的一部分参与签名。面试时要能说清 payload 的取舍放用户 ID、UUID、过期时间不放手机号、角色列表、权限码。原因有两个——JWT 是 Base64 编码不是加密任何人可解码查看角色权限放进去会导致权限变更后旧 token 仍然携带旧权限必须等过期才生效。# JWT payload 构造示例只放标识权限实时查 import jwt, time, uuid payload { userId: user_id, uuid: str(uuid.uuid4()), # 与 Redis 中的 UUID 比对实现单端登录 exp: int(time.time()) 1800 # 30 分钟过期 } token jwt.encode(payload, SECRET_KEY, algorithmHS256)参数说明exp 设三十分钟是原文“低于阈值自动续期”的前提阈值一般取剩余时间小于十分钟时触发续期。uuid 的作用是单端登录互斥——同一账号后登录的请求会覆盖 Redis 中的 UUID旧 token 解析出的 uuid 与 Redis 不一致直接返回 403。面试时把“UUID 防重放”讲成“单端登录互斥 旧凭证失效”比背“防止重放攻击”更具体也更容易接住“多端登录怎么支持”的追问答UUID 按设备维度存储或改为 token 版本号机制。3.4 第四层过滤器链里的认证与授权分离原文对授权流程的描述很细取 UUID 判空、取 Redis 中 JWT 解析、比对 UUID、校验存活时间、续期、判断资源权限。面试讲述时不要平铺这个流程要按“认证过滤器”和“授权决策”两段拆。认证过滤器只做三件事token 是否存在且可解析、UUID 是否与 Redis 一致、是否需要续期。授权决策交给 Spring Security 的 AccessDecisionManager基于 RBAC 五表查出的资源列表做匹配。// 认证过滤器核心判断顺序顺序错了会出安全问题 String uuid request.getHeader(uuid); if (StringUtils.isEmpty(uuid)) { response403(); return; } String redisToken redis.get(login: uuid); if (redisToken null) { response403(); return; } Claims claims parseJwt(redisToken); // 解析失败抛异常同样 403 if (!uuid.equals(claims.get(uuid))) { response403(); return; } // 单端互斥 long remain claims.getExpiration().getTime() - System.currentTimeMillis(); if (remain 10 * 60 * 1000) { refreshToken(uuid, claims); } // 续期 chain.doFilter(request, response); // 放行到授权决策这段代码的讲述重点是判断顺序先判空再查 Redis 再解析再比对每一步失败都返回 403 而不是 401因为对前端而言都是“凭证不可用”统一状态码减少前端分支。续期逻辑放在过滤器里而不是拦截器里是因为过滤器在请求进入 Servlet 之前执行续期后的新 token 可以通过响应头带回前端。面试官如果问“续期时旧 token 还能用吗”答“续期是延长 Redis 中 token 的过期时间并签发新 token旧 token 在自然过期前仍有效但 UUID 不变所以不触发互斥”这个细节能体现你真的跑过这条链路。4. 权限与定时任务怎么讲出深度RBAC 五表与 Xxl-job 调度模式权限和定时任务是中州养老系统里两个“看起来简单、问起来有层次”的模块。RBAC 五表模型几乎所有后台项目都有但能讲清“为什么是五张表而不是三张”“多对多关系怎么查”的人不多Xxl-job 三种调度模式原文列了轮询、分片广播、故障转移但面试官更想听“你的场景为什么选轮询”。这两块讲好了能显著拉开和其他候选人的差距。4.1 RBAC 五表多对多关系为什么必须拆关联表原文说“资源和角色之间是多对多的关系需要通过第三张表来维护二者的关系角色和用户之间的关系也是多对多”。面试时要能画出表结构并解释拆表理由一个角色拥有多个资源一个资源可被多个角色引用如果直接在角色表里存资源 ID 列表比如逗号分隔字符串查询“拥有某资源的角色”需要全表扫描字符串匹配无法建索引权限校验性能随数据量线性下降。拆成 role_resource 关联表后两个字段各建索引双向查询都是索引命中。-- 五表核心结构关联表的主键组合即联合唯一索引 CREATE TABLE sys_user (id BIGINT PRIMARY KEY, username VARCHAR(64), openid VARCHAR(64)); CREATE TABLE sys_role (id BIGINT PRIMARY KEY, role_name VARCHAR(64)); CREATE TABLE sys_resource (id BIGINT PRIMARY KEY, resource_url VARCHAR(255), resource_type TINYINT); CREATE TABLE sys_user_role (user_id BIGINT, role_id BIGINT, PRIMARY KEY(user_id, role_id)); CREATE TABLE sys_role_resource (role_id BIGINT, resource_id BIGINT, PRIMARY KEY(role_id, resource_id));参数说明resource_type 区分菜单、按钮、接口三类资源授权时按类型分别处理——菜单控制前端路由显示按钮控制页面元素接口控制后端放行。面试官常追问“用户有多个角色权限怎么合并”答“查 user_role 得角色集合再查 role_resource 得资源并集去重后作为授权依据”并补一句“并集查询用 IN 加 DISTINCT角色数量少时性能可接受角色多时考虑缓存用户权限快照”。这个补充能体现你对性能边界的判断。4.2 Xxl-job 三种调度模式轮询、分片广播、故障转移的适用边界原文列了三种模式但没说选型理由面试时这正是加分点。轮询模式适合“任务可拆分、每个执行器处理一部分”的场景比如过期预约状态修改按预约 ID 取模分发到不同执行器避免单点压力。分片广播是“一次调度广播到所有执行器每个执行器都执行一次”适合“每个节点都要做本地清理”的场景比如清理本机临时文件。故障转移是“执行器故障时任务转移到其他可用执行器”适合“任务不可拆分但要求高可用”的场景。// Xxl-job 轮询模式的任务处理器分片参数决定处理范围 XxlJob(expireAppointmentHandler) public void expireAppointment() { int shardIndex XxlJobHelper.getShardIndex(); // 当前分片序号 int shardTotal XxlJobHelper.getShardTotal(); // 分片总数 // 按 id 取模分片每个执行器只处理自己那部分 ListLong ids appointmentMapper.selectExpiredIds(shardIndex, shardTotal); for (Long id : ids) { appointmentMapper.updateStatus(id, STATUS_EXPIRED); } XxlJobHelper.log(分片 {} 处理 {} 条, shardIndex, ids.size()); }参数说明shardIndex 从 0 开始shardTotal 是执行器集群数量取模条件写在 SQL 的 where 里id % #{shardTotal} #{shardIndex}避免全量数据拉到内存再过滤。面试时主动说“轮询模式下如果某个执行器宕机它负责的分片在故障转移开启前不会被处理”面试官会认可你对边界条件的认知。原文提到“项目中使用的是轮询方式”把这个选择和上面的边界一起讲比单纯背三种模式的定义有说服力得多。4.3 服务项目开发流程需求分析到联调测试的讲述顺序原文最后一段写“通过需求分析完成对数据表、实体类的设计。编写接口文档编码。联调测试”。这段在面试里容易被讲成流水账正确的讲法是突出“文档先行”和“联调前置”。接口文档用 Swagger 在编码前定义好请求响应结构前后端并行开发联调时只对字段不对逻辑。数据库表设计先画 ER 图确认多对多关系再落 DDL避免编码中途改表结构导致实体类返工。面试官如果问“需求分析具体做了什么”不要答“和产品经理开会”要答“把护理项目模块拆成项目字典、服务下单、服务记录三张表确认下单与记录是一对多、项目与记录是多对一据此定外键和索引”。用具体的表和关系回答比流程名词有信息量。联调测试阶段常见做法是先用 Swagger 的 mock 数据跑通前端页面再切真实接口减少前后端互相等待的时间。5. 避坑项目讲述里最容易翻车的五个地方5.1 现象面试官问“JWT 怎么防重放”答“加了 UUID 就防了”原因UUID 防的是“同一账号多端登录互斥”不是重放攻击。重放攻击是攻击者截获请求后原样重发UUID 在请求头里跟着走重发照样通过。真正的防重放需要时间戳 nonce 校验或一次性签名。解决面试时把 UUID 的作用准确表述为“单端登录互斥与旧凭证失效”如果被追问重放坦诚说“当前方案未做请求级防重放生产环境可加时间戳窗口校验”比硬答“防了”安全得多。5.2 现象讲 RBAC 时说“用户表里存角色 ID”原因把多对多关系简化成了一对多面试官一追问“一个用户多个角色怎么存”就露馅。解决明确说“用户与角色通过 sys_user_role 关联表维护多对多用户表不存角色字段”并主动补一句“关联表主键是 user_id role_id 联合主键天然防重复授权”。5.3 现象Xxl-job 说“用了分布式调度所以高可用”原因调度中心高可用不等于任务执行高可用执行器宕机后轮询分片无人接管除非开故障转移。解决讲清“调度中心集群 执行器集群 故障转移策略”三层并说明轮询模式下故障转移的触发条件避免把框架能力当成默认行为。5.4 现象简历写“性能调优”但说不出调了什么原因原文简历描述里有“配合测试人员进行测试和性能调优”这是典型的空话面试官必问“调优调了什么”。解决要么删掉要么换成具体动作比如“热点服务项目信息加 Spring Cache Redis 两级缓存缓存穿透用空值缓存兜底接口 P99 从 800ms 降到 120ms”。没有真实数据就写“参与压测并定位慢 SQL为预约表按状态字段加索引”具体到索引名和字段。5.5 现象项目背景讲了三分钟业务价值技术问题一个没引出原因把简历当宣传册写忽略了面试官只关心技术决策。解决背景压缩到两句话一句业务约束护工流动性高、家属用小程序一句技术结论RBAC 降培训成本、静默登录降使用门槛剩下的篇幅全部留给“为什么这么选”和“踩了什么坑”。6. 把项目讲成故事的最后一步用 STAR 骨架做一次自测简历改完、技术点梳理完还差一道自测能不能在九十秒内把一个模块讲成“背景—任务—行动—结果”的闭环。以参观预约模块为例背景是家属到院参观需要提前预约、过期预约占用护工排班资源任务是实现预约状态自动流转且不依赖单机定时器行动是选 Xxl-job 轮询模式按预约 ID 分片处理配可视化界面便于运营查看任务执行记录结果是过期预约在预约时段结束后十分钟内完成状态更新运营无需人工干预。九十秒讲完面试官自然会从“为什么不用 Spring Task”切进来你答“单体部署时 Spring Task 够用但项目预留了多实例部署可能Xxl-job 的调度中心与执行器分离避免了多实例重复执行”对话就进入了你准备好的领域。自测时准备一张模块-追问对照表每个模块预判三个追问方向模块第一层追问第二层追问兜底答法微信登录code 有效期多久code 重复使用怎么处理一次性消费二次使用微信侧报错后端转登录失败提示JWT 续期续期阈值怎么定续期时旧 token 是否失效阈值取过期时间三分之一旧 token 自然过期前有效但 UUID 不变RBAC为什么不用 ABAC权限变更后已登录用户何时生效权限实时查库不走 token下次请求即生效Xxl-job轮询分片怎么分执行器宕机分片谁接管按业务主键取模故障转移开启后由调度中心重新分配这张表不用背写一遍的过程就是查漏。哪个格子填不出来说明那个模块还没吃透回去翻代码比临场编造强。我自己的习惯是每次面试前把这张表默写一遍填不出的格子标红面试前一晚只补标红项。从那以后我每次改简历都强制走一遍“模块—追问—兜底”三列自测宁可简历少写一个模块也不留讲不透的技术词。希望帮到你。本文还有配套的精品资源点击获取