做全栈项目最怕什么？不是技术不会，而是东西太多不知道从哪下手。这个项目标题里塞了Redis、SpringBoot、Vue-Cli、Docker，还要做邮箱注册登录、短信注册登录、支付宝支付、积分排行榜，乍一看是个大杂烩，但拆开看其实就是一套标准的互联网应用骨架：认证、支付、激励、部署，全给你串起来了。
如果你正在找那种"练完就能写进简历"的完整项目，这篇就适合你。我会按我自己做这套系统的顺序，把每个模块的设计思路、关键代码、踩坑点全部过一遍，包括验证码怎么存、支付回调怎么防重复、排行榜为什么用Redis不用MySQL、Docker怎么把前后端一次拉起来，最后再附一份事故排查清单。你可以直接照着做，也可以当成一个完整项目的参考骨架来改。
1. 项目整体设计与技术选型
1.1 核心功能拆解
先把这个项目里的功能点拎清楚，不要被标题唬住。项目一共六个核心模块：
- 邮箱注册登录：输入邮箱，后台发验证码，校验通过后注册或登录
- 短信注册登录：流程同上，但走短信通道
- 支付宝支付：用户给订单付款，走沙箱环境调试
- 用户积分：登录、注册、支付等动作产生积分
- 积分排行榜：按积分给用户排名，前端展示榜单
- Docker部署：前端、后端、Redis全部容器化
我建议你按这个顺序开发，因为模块之间有依赖。认证是基础，有了用户体系才能做积分和支付；支付又是积分的主要来源之一；排行榜依赖积分数据。把顺序理成：用户认证 → 积分体系 → 排行榜 → 支付宝支付 → Docker打包，每一步都能单独验证，不会到最后一团乱麻。
1.2 技术选型的逻辑
这套组合不是随便拼的，每个组件都干自己最擅长的活。
SpringBoot负责后端接口和业务编排，这套东西生态成熟，做注册登录、支付回调这种业务集成，社区资料最多，遇到问题基本都能搜到答案。Vue-Cli负责前端页面，单页应用体验好，配合Axios调后端接口很顺畅。Redis在这里担了三个角色：验证码存储、登录态缓存、排行榜存储。这三个场景分别对应Redis的String、String（或Hash）、ZSet数据结构，后面细说。Docker负责把环境一致性问题消灭掉，本地能跑通，服务器上就不会因为缺个依赖而翻车。
这里有个容易被忽略的点：为什么验证码和排行榜不用MySQL？验证码的特点是短期有效、高频读写、过期即删，MySQL处理这种临时数据既浪费又麻烦，Redis带过期时间天然合适。排行榜需要频繁做分数更新和排序，Redis的ZSet是专门为此设计的有序集合，一条指令搞定，MySQL里去ORDER BY一张大表，性能和实现成本完全没法比。这就是选Redis的核心原因，不是因为它时髦，是因为它在这个场景下真的最快。
1.3 整体数据流设计
在动手写代码前，我先画了张数据流的图，不画图越写越乱。整个系统跑起来的数据流大概是这样的：
用户打开前端页面 → 输入邮箱或手机号 → 前端调后端发送验证码接口 → 后端生成6位随机码存入Redis并设置5分钟过期 → 通过邮件或短信通道发给用户 → 用户回填验证码 → 后端从Redis取出比对 → 匹配成功则生成登录Token → 用户后续请求携带Token → 后端校验Token并从Redis获取用户信息 → 操作积分等业务 → 支付时调支付宝接口 → 支付宝异步回调通知后端 → 后端验签并更新订单状态、发放积分 → 排行榜数据实时更新 → 前端拉取榜单展示。
这个流程理清楚以后，每个模块的接口边界也就明确了：验证码接口、登录接口、用户信息接口、支付下单接口、回调接口、积分排行榜接口，各管一段，不会互相纠缠。
2. 注册登录模块：邮箱与短信双通道
2.1 验证码的生成与Redis存储方案
这是整个项目第一个核心点，也是新手最容易写糙的地方。
验证码生成的代码很简单，用Java的Random或者SecureRandom生成6位数字就行。但我建议你用SecureRandom而不是Random，原因是在安全场景下，Random的随机性不够，理论上存在被预测的风险，虽然验证码攻击场景在真实项目里需要配合频率限制才可能发生，但养成习惯用SecureRandom成本为零，收益是合规和安全。
生成验证码后，Redis的Key设计我这样定：
verify:email:{邮箱地址} verify:sms:{手机号}Value存验证码本身，过期时间设为5分钟，对应SET key value EX 300的指令。这里有个细节，开发时多用SET key value EX time这种命令，不要用SET加单独的EXPIRE两步，因为两步操作之间如果程序崩溃，这个Key就永远不过期了，Redis里会堆一堆垃圾数据。
再一个关键点：同一个邮箱或手机号，用户可能因为没收到验证码而反复点发送。如果每次发送都直接覆盖旧的Key，那么旧的验证码立即失效，这是没问题的。但连接发送频率上要加限制，我用的方案是给"发送动作"也设一个Key：
sms:sent:{手机号} → 1过期时间60秒。每次发送前先检查这个Key是否存在，存在就直接返回"发送太频繁，请稍后再试"。实测下来，这种防刷逻辑比单纯在验证码Key上做文章更有效，因为验证码Key存的是"正确性"，频率Key管的是"节奏"，两个维度分开管理才清晰。
2.2 邮箱验证码发送
邮箱发送这块，SpringBoot直接用spring-boot-starter-mail，配置文件里指定SMTP服务器、端口、账号、授权码。注意不是登录密码，是授权码，这个很多第一次做的人会卡住。
配置大概是这样的：
spring: mail: host: smtp.qq.com port: 465 username: 你的邮箱 password: 授权码 properties: mail.smtp.ssl.enable: true写一个发送方法，用SimpleMailMessage或MimeMessageHelper。个人建议改用MimeMessageHelper，因为后面如果你想在邮件正文里加HTML模板、加链接，SimpleMailMessage就力不从心了。注册验证码邮件里放个"您本次的验证码是：XXXX，5分钟内有效，请勿泄露给他人。"就够了。
这里要补一个细节，邮件服务在本地开发时经常会遇到连接超时或被当成垃圾邮件的情况。连接超时一般检查端口和SSL配置对不对，被当成垃圾邮件就没什么好办法，只能让收件人把发件地址加入白名单，这个属于邮箱服务商的行为，不是代码能完全控制的。
2.3 短信验证码发送
短信通道和邮箱最大的区别是：短信是付费的，而且有严格的模板审核机制。所以发送前一定要做好频率限制，否则用户手滑点几次，你的短信费用就烧掉了。
短信服务商的接入大同小异：注册账号、申请签名、申请模板、拿到AccessKey，然后调用SDK发短信。模板一般长这样："您的验证码为${code}，请勿泄露。"签名和模板都要过审，测试阶段可以用服务商提供的测试模板，正式环境必须用自己的。
代码层面，我把短信发送封装成一个接口，将来换服务商不用改业务代码。接口长这样：
public interface SmsSender { void send(String phone, String code); }发送方法里，第一步查Redis里的频率Key，第二步调服务商SDK，第三步写入验证码Key。这里有个顺序问题：先限频，再发送，最后存验证码。如果先存验证码再发送，万一发送失败，Redis里残留一个验证码，用户永远收不到但验证码Key还在，体验就会很怪。发送失败时要把已存的验证码Key删掉，同时把频率Key也删掉，让用户可以马上重试。
短信这块我在实际项目中遇到最多的坑有三个：签名不匹配报错、模板变量名对不上、手机号格式校验缺失。前两个是服务商控制台的问题，仔细看报错信息就能解决。手机号校验建议用正则做一次预校验，格式不对直接不调短信接口，既省钱又不浪费用户时间。
2.4 登录态管理：Token与Redis结合
验证码校验通过后，用户就完成注册或登录了。这时要解决的问题是：怎么让用户后续请求不需要再验证码？
方案有Session和Token两种。传统Session是Tomcat自己维护的，集群部署时要么粘滞会话要么做Session共享。这个项目我们直接用Token方案，更符合前后端分离的架构。
我用的Token方案是：生成一个UUID作为Token，把这个Token当Key，用户ID做Value，存入Redis并设置过期时间（比如30分钟）。前端拿到Token后存到本地，每次请求放在请求头里：
Authorization: Bearer {token}后端写个拦截器统一处理：从Header取出Token，去Redis查用户ID，查到了就放行，查不到就返回401让前端跳登录页。
为什么不直接用JWT？我当时考虑了这个问题，JWT的好处是无状态，但坏处是没法主动失效，用户改了密码、被封号，JWT还是有效的，只能等它过期。用Redis存Token，管理端一个命令就能把用户踢下线，虽然多了一次Redis查询，但这个成本完全可接受，而且和验证码、排行榜共用Redis，没有额外维护负担。这个选择我觉得很值，后来在做支付回调时，我利用同一个Redis查用户信息，非常顺手。
登录成功后，顺手给用户加积分，我用Redis的INCRBY命令直接加，然后记录一条积分流水。关于积分流水稍微多说一句，正式项目里积分一定要配流水表，不能只改一个数字，否则用户说"我积分少了"你就完全没法查。这个项目里我没有把流水接入数据库，但接口设计上保留了埋点，你自己做的时候建议加一张points_log表，字段就是用户ID、变动值、原因、时间，成本很低但排查问题时价值巨大。
3. 支付宝支付集成：从沙箱到回调
3.1 沙箱环境准备
支付宝支付在真实项目里上线是需要企业资质审核的，但开发阶段完全可以在沙箱环境联调，个人开发者也能申请。这里有个关键认知，沙箱环境和正式环境的区别：
- 沙箱的商家账号、买家账号都是平台提供的测试账号
- 支付金额是虚拟的，不产生真实扣款
- APPID、密钥、网关地址都和正式环境不同
- 回调通知会正常打到你的本地接口，但需要内网穿透工具辅助
开发时我用沙箱商家的APPID和支付宝公钥、应用私钥配置在application.yml里，然后把网关地址指向沙箱地址。注意一定要把网关和正式网关区分开，我犯过一次配置错误，沙箱的APPID配合正式网关去调，直接报"无效的APPID"，当时排查了半小时才反应过来是网关配错了。
密钥这块是现代支付集成的核心，支付宝用RSA2签名，逻辑是：你用自己的应用私钥对请求参数签名，支付宝用你的应用公钥验签；支付宝回传的通知和响应，你用支付宝公钥去验签。密钥生成工具在开放平台的文档里有，建议配一个alipay工具类统一管理签名验签逻辑。
3.2 支付下单与唤起支付
业务流程是：用户提交订单 → 后端创建订单数据 → 后端调支付宝下单接口获取支付表单 → 返回给前端 → 前端用表单跳转到支付宝收银台。
订单表这里要注意，至少包含：订单号、用户ID、商品信息、金额、状态、创建时间、支付时间。订单号必须保证唯一，我用的是时间戳+用户ID+随机数的组合，或者直接生成UUID去掉横线。
调用支付宝接口，官方SDK的用法大致如下，我用最简单的方式：
AlipayClient alipayClient = new DefaultAlipayClient( gatewayUrl, appId, privateKey, "json", "UTF-8", alipayPublicKey, "RSA2"); AlipayTradePagePayRequest request = new AlipayTradePagePayRequest(); request.setNotifyUrl("你的后端回调地址"); request.setReturnUrl("支付完成后前端跳转地址"); request.setBizContent("{\"out_trade_no\":\"订单号\"," + "\"total_amount\":\"金额\"," + "\"subject\":\"商品描述\"," + "\"product_code\":\"FAST_INSTANT_TRADE_PAY\"}"); AlipayTradePagePayResponse response = alipayClient.pageExecute(request); // 把response.getBody()返回给前端前端拿到这段HTML表单字符串，用document.write输出或者直接跳转到一个临时页面渲染它，就会自动跳到收银台。这个过程看起来有点土，但它就是PC端网页支付的官方做法，浏览器兼容性最好。
金额参数尤其注意，total_amount是字符串类型，以元为单位，不要传成分。前端展示用元，后端数据库如果存的是分，拼接参数前要除100，并且注意浮点精度问题，最好用BigDecimal做转换。
3.3 异步回调验签与幂等处理
支付完成后，支付宝会异步POST通知到notifyUrl，这是整个支付模块最需要小心的地方。
回调逻辑我按四步走：
- 验签：用支付宝公钥对通知参数验签，验签失败直接忽略
- 校验业务参数：比如
out_trade_no是不是本系统生成的订单、total_amount是否和订单金额一致、app_id是否正确 - 查订单状态：如果订单已经是"已支付"，直接返回success，不再处理
- 更新订单、发积分：状态改成已支付，给用户加分
第二步和第三步是防伪造和防重复的关键。回调通知是可以被伪造的，所以验签必须第一位。金额校验特别容易漏，有些攻击手段就是诱导你给小额订单付钱，然后通过改参数达到低价买高价商品的效果，虽然支付宝在签名机制下改参会验签失败，但你仍然要开发层面再校验一遍金额，双保险。
第三步的幂等处理我实测最稳的方式是：给订单状态加一个更新条件，用SQL或MyBatis的更新语句：
UPDATE orders SET status = 'PAID', pay_time = NOW() WHERE order_no = #{orderNo} AND status = 'UNPAID'如果更新影响行数为0，说明订单已经处理过了，直接忽略本次回调。这样即使支付宝重复通知，或者你的回调处理代码中间断点重试，都不会重复加分。我见过不少项目回调不加幂等，用户付一次款积分加了三次，排行榜直接错乱，这种问题在排查时非常难定位，因为日志里每次回调都"成功"了。
回调处理完以后，响应给支付宝的必须是字符串success，其他任何内容都表示通知失败，支付宝会按策略重试。很多人这里返回JSON格式的{"code":200}，数据也被处理了，但支付宝不认，就会不断重试，造成垃圾请求堆积。
4. 用户积分排行榜：Redis ZSet实战
4.1 积分规则怎么定
积分排行榜的前提是积分规则。我在这套系统里定了这么几条最基础的：
- 注册成功：+50分
- 完善资料：+20分
- 每日首次登录：+5分，一天最多一次
- 支付成功：按支付金额的10%加分，1元加10分，取整
积分规则一定要在白名单里配置清楚，不要在业务代码里散落各种数字。我习惯把规则常量集中在一个类里，比如PointRule，后面想调规则只改一个地方。
这里有个很关键的设计：积分变动必须记录原因，不管是加分还是扣分。查排行榜的时候只需要看最终分，但用户如果投诉积分算错了，你得能回答"这笔分是哪里来的"。
4.2 为什么用Redis ZSet做排行榜
排行榜需求本身不复杂：按照积分从高到低排序，取前100名，展示头像、昵称、积分。如果用MySQL，做法是查用户表按积分字段倒序LIMIT 100，如果用户量小确实没问题，但一旦用户上万，每次排行榜刷新都全表排序，数据库压力立刻上来。Redis的ZSet就是专门干这个的：
- 成员（member）存用户ID
- 分数（score）存积分
- 天然按分数排序
- 增删改都是O(logN)复杂度
新增或更新积分用：
ZINCRBY user_rank 50 10001意思是给用户10001的分数加50。这个命令原子执行，并发情况下也不会丢失更新。排行榜查询用：
ZREVRANGE user_rank 0 99 WITHSCORES按分数从高到低取前100名。想要某个用户自己的排名：
ZREVRANK user_rank 10001三条命令覆盖了排行榜所有核心操作，这在MySQL里至少得写好几条SQL还要考虑索引优化。
4.3 榜单查询与前端展示
后端接口设计成返回一个列表，每个元素包含排名、用户ID、昵称、头像、积分。注意ZSet里只存了用户ID和积分，昵称头像在用户表里。所以查询流程是：先从Redis取榜单前100的ID列表，再用这些ID批量查MySQL组装信息，最后返回。
批量查用户信息可以用WHERE id IN (...)，但要注意SQL的IN列表长度限制和性能，100个ID完全没问题。如果你想省一次数据库查询，也可以把用户昵称头像缓存到Redis，但考虑到用户量级和一致性维护成本，我建议前期直接查库，简单可靠。
前端排行榜页面我用Vue跑起来以后，就是一个表格组件，列是排名、头像、昵称、积分，排名前三的样式搞点特殊颜色。这里有个交互细节，当前登录用户的名字不在前100名时，榜单下面要单独显示"您的排名：第123位，积分：456"，这个用ZREVRANK key userId单独查一下就行，不需要拉全表排序。
还有一个并发要注意的点：ZINCRBY虽然原子，但如果你在加积分前先查了当前积分，做了业务判断（比如每日首登判断），那这个"判断+加分"就不是原子的。解决方式有几种，最简单的就是用Redis的SETNX加一个每日首次登录的标记Key：
SETNX daily_login:{userId}:{yyyyMMdd} 1返回1表示第一次，加积分；返回0表示已经加过了。这个操作我自己实测在生产逻辑里很稳，比在代码里先查再判要安全得多。
5. Docker容器化部署
5.1 后端镜像构建
开发完以后，部署环节直接用Docker把这套东西打包。后端是SpringBoot应用，核心就是打成JAR包再写Dockerfile。我用多阶段构建，第一阶段用Maven镜像编译，第二阶段用JRE镜像跑：
FROM maven:3.8-openjdk-11 AS builder WORKDIR /app COPY pom.xml . RUN mvn dependency:go-offline COPY src ./src RUN mvn package -DskipTests FROM openjdk:11-jre-slim WORKDIR /app COPY --from=builder /app/target/*.jar app.jar EXPOSE 8080 ENTRYPOINT ["java", "-jar", "app.jar"]多阶段构建的好处是最终镜像里只有运行环境和JAR包，没有Maven和源码，体积小很多。我见过不少新手直接把源码和Maven都塞进去，镜像动辄一个多G，部署和拉取都痛苦。上面的写法，最终镜像大概200M出头，如果你用JRE的基础镜像还会更小。
5.2 前端镜像与Nginx配置
Vue-Cli开发完以后npm run build会生成dist静态目录，部署方式是用Nginx托管这些静态文件，同时做接口反向代理。Dockerfile同样多阶段：
FROM node:16-alpine AS builder WORKDIR /app COPY package*.json ./ RUN npm install COPY . . RUN npm run build FROM nginx:alpine COPY --from=builder /app/dist /usr/share/nginx/html COPY nginx.conf /etc/nginx/conf.d/default.conf EXPOSE 80Nginx配置里最核心的是接口代理，前端页面在80端口，后端接口在容器网络的8080端口，通过代理把/api开头的请求转发过去：
server { listen 80; server_name localhost; location / { root /usr/share/nginx/html; index index.html; try_files $uri $uri/ /index.html; } location /api { proxy_pass http://backend:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }try_files $uri $uri/ /index.html这行不能省，Vue是单页应用，前端路由在浏览器端控制，刷新一个子页面路径时如果Nginx找不到对应文件就会404，这一行把所有未知路径都回退到index.html，路由交给前端处理。
5.3 docker-compose编排
三个容器各有各的网络配置，手动一个个docker run容易出错，我用docker-compose统一编排：
version: "3" services: redis: image: redis:6-alpine container_name: project-redis ports: - "6379:6379" volumes: - redis-data:/data backend: build: ./backend container_name: project-backend ports: - "8080:8080" environment: - SPRING_REDIS_HOST=redis - SPRING_DATASOURCE_URL=jdbc:mysql://mysql:3306/project depends_on: - redis frontend: build: ./frontend container_name: project-frontend ports: - "80:80" depends_on: - backend volumes: redis-data:这里有个特别重要的点：容器里配置Redis和MySQL地址时，不能用localhost或127.0.0.1，要用服务名。docker-compose会在内部创建一个网络，服务名就是容器间的域名，redis这个服务名在backend容器里直接可以当主机IP用。我第一次部署本地能跑、容器里连不上Redis，就是因为在application.yml里写了localhost，改成redis就好了。
前端Nginx里proxy_pass http://backend:8080同理，backend是服务名。
数据库这块我上面配置里也提了MySQL，这个项目如果你用了MySQL存用户订单表，就在compose里加一个mysql服务。不想引入MySQL的，用H2或者SQLite也能顶，但正式项目还是建议上MySQL，毕竟用户、订单这类核心数据需要可靠的持久化存储，Redis不适合当唯一的数据库用。
6. 常见问题与排查实录
6.1 验证码收不到
我实测最频繁的问题是邮件验证码发不出去，总结下来原因主要三种：
第一种是配置问题，SMTP端口选错或者没开SSL。我遇到过QQ邮箱用25端口连不上，换成465加SSL就好了的情况。第二种是授权码错误，这个只能回控制台重新生成。第三种是邮件进了垃圾箱，特别是阿里企业邮这种过滤规则的邮箱，加白名单基本能解决。
短信收不到相对来说问题更集中：要么是模板审核没过，要么是签名不匹配，要么是手机号格式错误导致服务商静默丢弃。排查思路是先看服务商控制台的消息记录，那里有完整的发送日志和失败原因，比自己在代码里打日志定位快得多。
6.2 支付回调重复和不生效
回调重复的问题，前面的幂等更新方案已经能兜底。但还有一个问题值得单独说：本地开发时支付宝无法访问你的localhost，回调会一直失败。解决方式是用内网穿透工具把本地端口映射成一个公网地址，然后把这个地址配到notifyUrl里。如果你用的是某某穿透工具，映射后可能是一个临时域名，注意支付宝回调要求域名可访问且不带本地IP。
回调不生效还有一个隐蔽原因，notifyUrl必须是公网能POST访问的URL，不能带query参数，有些版本的SDK对参数处理有差异，我用的是直接在setNotifyUrl里拼接参数的方式，后来发现某些场景下参数会丢失，改成不带参数、回调里再从请求体解析就好了。
6.3 排行榜分数不对
排行榜分数异常的情况我在开发中就遇到过。典型场景是：用户支付成功后加了10分，但排行榜上找不到这个人，或者分数不对。
排查思路是先看Redis里的实际分数：
redis-cli ZSCORE user_rank 10001如果分数不存在，说明加分逻辑没执行或者执行的用户ID不是10001；如果分数少了，说明加分被重复执行了某次覆盖，而不是累加。这时候回到支付回调的幂等逻辑和加分流水表去查，基本能定位。我当时的坑是：回调里先更新订单状态再发积分，但订单更新成功了积分却没加到，原因是在加分之前抛了个异常，事务回滚把加分也回滚了，后来把加分逻辑挪到独立事务里，或者放到订单更新成功之后再单独执行，问题解决。
6.4 容器间网络不通
本机能跑、一上Docker就各种连不上，这是容器化部署最经典的坑，原因基本都是IP配置问题。记住一句话：容器之间用服务名，不要用localhost。后端连Redis用redis:6379，连MySQL用mysql:3306，前端Nginx代理后端用http://backend:8080。
另外检查一下端口映射，redis容器如果不加ports映射，宿主机是访问不到的，但容器间不受这个限制。depends_on只是控制启动顺序，不保证依赖服务已经就绪，所以你可能会遇到后端启动时Redis还没就绪的情况，SpringBoot的Redis连接重试机制通常会帮你挺过去，但如果在启动阶段就强依赖Redis，建议在application.yml里配一下spring.redis.timeout和连接重试参数。
开发这套项目时，我最大的体会是：表面上是把这几个技术栈拼在一起，实际上练的是模块划分和边界管理。验证码、登录、支付、积分、部署，每个模块单独拎出来都不难，但把它们串起来的时候，你会被迫去思考接口怎么设计、状态怎么流转、异常怎么兜底、重复请求怎么处理。这些才是真实项目里最值钱的东西。
最后分享一个我做这种实战项目的小习惯：每完成一个模块，先提交一次代码，注释里写明这个模块做了什么、有什么坑、下一步做什么。整项目做完回头看，这本Git提交记录就是你最好的复习笔记，面试时讲项目也能一条线串下来，比临时翻代码回忆强太多。
