若依Cloud框架部署_代码修改器使用详解
若依 Cloud 框架部署与代码修改器使用详解
课程位置：第四阶段「微服务项目 + AI 应用」第 5 课
前置知识：微服务体系架构、Nacos、Feign、Sentinel、Gateway、Redis、MySQL、Maven、Git
本课主题：若依 Cloud 框架部署｜代码修改器使用
后续课程：智途 AI 旅行微服务实战——数据库设计与短信验证
学习目标：真正看懂 RuoYi-Cloud 的模块结构，理解前面学习的 Nacos、Feign、Sentinel、Gateway 在完整脚手架中的位置；能够从零完成 Spring Boot 3 分支下载、数据库初始化、Redis/Nacos 启动、核心服务启动、前端联调；掌握若依框架包名/项目名修改器的正确使用方法，并学会修改后的完整检查清单，避免“改了名字但项目启动不了”。
一、这一课和前四课有什么不同
前四课我们是：
自己搭一个最小项目
例如：
gateway
user-service
order-service
然后一步一步加入：
Nacos
Feign
Sentinel
Gateway
这一课开始：
不再从零造轮子
而是打开一个已经搭好的：
企业级微服务脚手架
也就是：
RuoYi-Cloud
二、可以把前四课理解成“学零件”
我们已经知道：
Nacos
→ 服务注册发现 + 配置中心
Feign
→ 服务间远程调用
Sentinel
→ 限流、熔断、降级
Gateway
→ 微服务统一入口
现在若依 Cloud：
把这些零件
组装成了完整系统
三、这一课最重要的目标不是“把项目跑起来”
单纯：
启动成功
只是最低要求。
真正目标：
你能解释：
每一个模块为什么存在
四、RuoYi-Cloud 是什么
RuoYi-Cloud 是若依官方的：
前后端分离
+
Spring Cloud & Alibaba
+
分布式微服务
版本。
官方当前说明其后端使用：
Spring Boot
Spring Cloud
Spring Cloud Alibaba
基础设施包括：
Nacos
Redis
Sentinel
Seata
五、不要把三种若依混淆
常见：
RuoYi
RuoYi-Vue
RuoYi-Cloud
六、RuoYi
传统：
单体
七、RuoYi-Vue
前后端分离：
Spring Boot 单体后端
+
Vue 前端
八、RuoYi-Cloud
Spring Cloud 微服务
+
前后端分离
九、所以你现在学习的是
RuoYi-Cloud
不是前面我们学过的：
RuoYi-Vue 单体版本
十、当前版本必须先确认
截至本笔记整理时间：
2026-09-10
若依 Cloud 当前发布版本：
3.6.8
十一、最重要的分支变化
当前官方仓库：
master
已经是：
Spring Boot 4.x
JDK 17+
Nacos 3.x
十二、你现在应该用哪个分支
你当前学习主线：
JDK17
+
Spring Boot 3
所以应该使用：
springboot3
十三、官方当前分支关系
master
→ Spring Boot 4.x
springboot3
→ Spring Boot 3.x
springboot2
→ Spring Boot 2.x
十四、这一点非常重要
如果你直接：
git clone ...
然后什么都不做，
当前默认：
master
会进入：
Spring Boot 4
这和我们前面课程：
Spring Boot 3
会出现版本差异。
十五、正确克隆方式
git clone https://gitee.com/y_project/RuoYi-Cloud.git
进入：
cd RuoYi-Cloud
切分支：
git checkout springboot3
十六、然后一定确认
git branch
应该看到：
* springboot3
十七、不要只相信 IDEA 左下角分支文字
命令再确认一次：
git status
十八、为什么这么谨慎
因为：
你后面如果报版本错
首先要排除：
自己下错分支
十九、当前 springboot3 分支技术基线
当前仓库 POM 已经是若依：
3.6.8
并使用：
Java 17
Spring Boot 3.5.x
Spring Cloud 2025.0.x
Spring Cloud Alibaba 2025.0.x
二十、当前仓库会持续更新
所以不要死记：
某一个 patch 版本永远不变
应该记：
分支和主版本关系
二十一、为什么官方旧文档里还会看到 JDK8
若依的部分环境部署文档：
历史很久
其中可能仍写：
JDK 1.8
MySQL 5.7
Nacos 2.x
二十二、这是不是说明 springboot3 也用 JDK8
不是。
当前官方仓库已经明确：
springboot3
= JDK17+
二十三、以后遇到“文档和代码不一致”
优先顺序：
当前目标分支代码
↓
当前 README / POM
↓
当前版本更新日志
↓
通用旧文档
二十四、为什么代码分支更重要
因为：
你真正要运行的是当前代码
二十五、RuoYi-Cloud 当前后端模块
官方当前仓库大体结构：
RuoYi-Cloud
├─ ruoyi-auth
├─ ruoyi-gateway
├─ ruoyi-api
├─ ruoyi-common
├─ ruoyi-modules
├─ ruoyi-visual
├─ docker
├─ sql
└─ pom.xml
二十六、先不要急着打开所有 Java 文件
第一步：
先看顶层模块
二十七、为什么
微服务项目最怕：
一上来打开某个 Controller
却不知道：
它属于哪个服务
二十八、ruoyi-gateway
端口通常：
8080
职责：
统一入口
路由
鉴权
验证码过滤
黑名单/白名单
Sentinel Gateway 流控
二十九、它对应你刚学的
Spring Cloud Gateway
三十、ruoyi-auth
端口常见：
9200
职责：
认证中心
主要处理：
登录
Token
退出
认证流程
三十一、为什么 Auth 单独拆服务
认证属于：
系统公共能力
多个业务模块：
都会使用
三十二、ruoyi-system
位于：
ruoyi-modules
常见端口：
9201
三十三、system 负责什么
最核心后台系统数据：
用户
角色
菜单
部门
岗位
字典
参数
三十四、这和单体若依中的 system 类似
区别：
现在它是一个独立微服务
三十五、ruoyi-gen
常见端口：
9202
职责：
代码生成
三十六、ruoyi-job
常见端口：
9203
职责：
定时任务
三十七、ruoyi-file
常见端口：
9300
职责：
文件服务
三十八、ruoyi-visual-monitor
常见端口：
9100
职责：
服务监控
三十九、ruoyi-api
这是非常关键的模块。
它不是：
一个独立运行服务
而是：
远程接口契约模块
四十、你前面自己写过什么
我们前面设计过：
user-api
里面放：
Feign Client
Remote DTO
四十一、若依 Cloud 已经替你做了
例如：
ruoyi-api-system
四十二、所以你会看到
RemoteUserService
等远程接口。
四十三、这就是前面学 Feign 的意义
你现在看到：
RemoteXXXService
应该想到：
@FeignClient
四十四、ruoyi-common
这个模块非常重要。
它不是：
一个服务
而是：
公共依赖模块集合
四十五、常见子模块
当前官方 README 包括：
ruoyi-common-core
ruoyi-common-datascope
ruoyi-common-datasource
ruoyi-common-log
ruoyi-common-redis
ruoyi-common-seata
ruoyi-common-security
ruoyi-common-sensitive
ruoyi-common-swagger
四十六、ruoyi-common-core
放：
核心常量
通用工具
基础对象
通用异常
公共模型
四十七、ruoyi-common-security
负责：
安全相关公共能力
例如：
SecurityUtils
自定义注解
远程认证上下文
Feign 安全配置
四十八、ruoyi-common-redis
负责：
Redis 公共封装
四十九、ruoyi-common-datascope
负责：
数据权限
你之前若依单体已经学过：
DataScope
五十、微服务里数据权限为什么仍然需要
因为：
Gateway 只负责入口
真正查询数据：
发生在业务服务
所以：
数据权限仍要在业务服务执行
五十一、ruoyi-common-log
负责：
操作日志
五十二、ruoyi-common-datasource
负责：
多数据源支持
五十三、ruoyi-common-seata
负责：
Seata 分布式事务支持
五十四、你现在为什么先不启用 Seata
这节课目标：
跑通基本微服务
不要一开始把：
Seata
也加进排错范围。
五十五、ruoyi-common-sensitive
负责：
数据脱敏
例如：
手机号
身份证
邮箱
展示时脱敏。
五十六、ruoyi-common-swagger
负责：
API 文档公共配置
当前版本实际依赖：
Springdoc
而不是老版本 Swagger2。
五十七、ruoyi-visual
主要：
图形化管理类服务
例如：
监控中心
五十八、最小启动到底需要哪些服务
官方传统环境部署文档把核心模块列为：
Gateway
Auth
System
必需。
五十九、所以第一次学习不要全部启动
不需要先启动：
Gen
Job
File
Monitor
Seata
六十、第一次最小运行集
MySQL
Redis
Nacos
ruoyi-gateway
ruoyi-auth
ruoyi-system
再加：
前端
六十一、为什么这样最适合你
如果一次启动：
10 个模块
出现一个报错：
控制台全乱
六十二、推荐学习顺序
基础设施
↓
核心后端
↓
前端
↓
可选模块
六十三、基础设施第一层：MySQL
若依核心数据需要：
业务数据库
传统名称：
ry-cloud
六十四、Nacos 数据
若依项目还会准备：
Nacos 配置相关 SQL
传统数据库名：
ry-config
六十五、最重要规则
一定使用：
你当前 springboot3 分支 sql 目录里的脚本
不要：
从博客下载一个 2021 年的 SQL
六十六、为什么
当前若依更新日志已经多次：
更新数据库结构
更新 Nacos 表结构
不同版本：
SQL 可能不完全一致
六十七、数据库脚本原则
代码版本
=
SQL 脚本版本
六十八、不要代码 3.6.8
配：
SQL 3.2.0
六十九、MySQL 版本
官方项目长期兼容：
MySQL 5.7+
当前你平时学习环境：
MySQL 8.0
通常可以使用。
七十、MySQL 8 常见额外问题
例如：
时区
字符集
保留关键字
认证插件
遇到数据库启动问题：
看实际异常
不要直接怀疑若依所有代码。
七十一、建议字符集
utf8mb4
七十二、为什么不是 utf8
MySQL utf8mb4：
支持更完整 Unicode
七十三、第二层：Redis
若依 Cloud 权限认证：
依赖 Redis
七十四、Redis 用来做什么
典型：
登录会话
Token 状态
验证码
缓存
在线用户
七十五、如果 Redis 没启动
常见表现：
Auth/Gateway/System
连接 Redis 失败
七十六、不要只看最后一行
例如：
Application run failed
真正原因可能在上面：
Unable to connect to Redis
七十七、第三层：Nacos
Nacos 在若依 Cloud 中同时承担：
注册中心
配置中心
七十八、为什么 Nacos 必须先启动
因为业务服务启动时需要：
读取配置
注册服务
七十九、官方环境部署也明确说明
运行若依 Cloud 前：
先启动 Nacos
八十、Nacos 版本
当前 springboot3 分支：
JDK17+
Nacos 3.x
八十一、当前仓库 Docker 示例
官方当前 springboot3 Docker Compose 使用：
nacos/nacos-server:v3.0.2
并映射：
8848
9848
9849
八十二、这说明什么
不要继续照老教程：
Nacos 1.4.1
作为当前 springboot3 主线。
八十三、Nacos 3 安全配置也变了
Docker 示例中已经包含：
NACOS_AUTH_TOKEN
NACOS_AUTH_IDENTITY_KEY
NACOS_AUTH_IDENTITY_VALUE
所以：
新版认证不能完全照老版默认账户思维
八十四、本地学习两种基础设施方式
第一种：
本地安装
MySQL、Redis、Nacos：
分别启动
八十五、第二种
Docker Compose
仓库已经提供：
docker/docker-compose.yml
八十六、你当前基础阶段推荐哪种
如果 Docker 还不熟：
先本地单独启动
因为你能清楚看到：
哪个组件出了问题
八十七、Docker 熟悉以后
再：
docker compose
一键拉起基础环境。
八十八、为什么不建议第一次就全 Docker
一旦：
容器网络
volume
镜像
Nacos
数据库
一起出问题，
对新手：
排查层太多
八十九、IDEA 导入项目
建议：
直接打开顶层 pom.xml 所在目录
九十、IDEA 版本
你目前：
IDEA 2024.3
完全可以用于：
JDK17 + Spring Boot 3
九十一、JDK 选择
IDEA：
File
→ Project Structure
→ Project SDK
选择：
JDK17
九十二、Maven
你本地目前是：
Maven 3.6.3
满足若依传统要求。
但现代 Boot/插件如果后续出现兼容问题：
可考虑升级 Maven 3.9.x
课程当前先：
不强制改
九十三、为什么不建议一遇到错误就升级所有东西
因为：
变量太多
排错原则：
一次只改一个关键变量
九十四、第一次 Maven 导入
可能：
下载大量依赖
耐心等 Maven：
完成解析
九十五、如果 IDEA 全红
第一件事不是：
改代码
先确认：
Maven 是否完成导入
九十六、右侧 Maven
点击：
Reload All Maven Projects
九十七、命令行验证
在根目录：
mvn clean package -DskipTests
九十八、为什么命令行很重要
IDEA 显示异常时：
命令行能帮助区分
IDE 问题 vs Maven 项目问题
九十九、父 POM 先看什么
当前 springboot3 顶层：
groupId=com.ruoyi
artifactId=ruoyi
version=3.6.8
一百、还要看版本属性
核心：
java.version
spring-boot.version
spring-cloud.version
spring-cloud-alibaba.version
一百零一、为什么先看这些
后续任何：
NoSuchMethodError
ClassNotFoundException
Starter 版本错误
都可能与它们有关。
一百零二、若依父工程已经统一依赖
所以：
不要随便给子模块某个 Spring Cloud Starter
手动升级版本
一百零三、尤其不要
看某篇博客说最新版更好
然后只升级：
Gateway
Nacos Client
Feign
一百零四、正确
若依框架：
先保持官方版本整体一致
一百零五、第一遍部署不要改包名
非常重要。
正确顺序：
原版项目先跑通
↓
确认环境没问题
↓
Git 提交
↓
再使用修改器改名
↓
再次跑通
一百零六、为什么不能先改名
如果你：
下载以后立刻改 500 个文件
然后启动失败，
你不知道：
原项目环境问题
还是改名问题
一百零七、这是本课最重要的工程习惯之一
Baseline First
先建立：
可运行基线
一百零八、建议 Git 操作
原项目确认跑通后：
git checkout -b customize
一百零九、提交基线
git add .
git commit -m "chore: verify original ruoyi cloud baseline"
一百一十、为什么要提交
改名以后：
git diff
可以清楚看到：
修改器到底动了哪些文件
一百一十一、如果修改器改坏
直接：
git reset
或：
重新切基线分支
一百一十二、所以 Git 是你的保险绳
不要在：
唯一一份项目
上直接运行批量替换工具。
一百一十三、启动顺序总览
课程推荐：
1. MySQL
2. Redis
3. Nacos
4. ruoyi-system
5. ruoyi-auth
6. ruoyi-gateway
7. 前端
一百一十四、官方说核心模块没有严格先后
这是因为：
服务注册发现能够动态感知
但学习阶段：
按固定顺序更容易排错
一百一十五、为什么先 System
Auth 登录通常需要：
查询用户信息
最终会涉及：
system 服务
先启动它：
更直观
一百一十六、为什么 Gateway 最后启动也可以
因为：
内部核心服务已经可用
Gateway 一启动：
路由就有目标
一百一十七、真正硬前置
主要：
MySQL
Redis
Nacos
一百一十八、Nacos 配置导入
若依 Cloud 很多配置：
不直接放在各模块 application.yml
而是在：
Nacos Config
一百一十九、这就是为什么你打开服务配置
会觉得：
怎么这么少
因为：
真正数据库/Redis/MyBatis 等配置
可能在 Nacos
一百二十、先找 sql 目录
你应该寻找：
业务 SQL
Nacos 配置 SQL
一百二十一、为什么 Nacos 配置会用 SQL 初始化
若依已经准备：
默认 DataId
比如：
application-dev.yml
ruoyi-gateway-dev.yml
ruoyi-auth-dev.yml
ruoyi-system-dev.yml
具体名称：
以当前分支 SQL 为准
一百二十二、不要自己从零创建所有 DataId
先：
导入官方当前版本 SQL
一百二十三、再去 Nacos Console 观察
你会理解：
哪些配置是共享
哪些配置属于 Gateway
哪些属于 Auth
哪些属于 System
一百二十四、配置中心学习方法
不要：
一股脑复制配置
建议逐个看：
application-dev.yml
→ 公共配置
ruoyi-gateway-dev.yml
→ Gateway
ruoyi-auth-dev.yml
→ Auth
ruoyi-system-dev.yml
→ System
一百二十五、公共配置通常可能包含
Redis
Spring 公共设置
Feign
Sentinel
日志
具体：
看当前分支
一百二十六、system 配置通常重点
DataSource
MyBatis
业务参数
一百二十七、gateway 配置重点
Route
白名单
Sentinel
安全
一百二十八、auth 配置重点
认证相关
一百二十九、配置修改第一原则
不要：
看到 127.0.0.1 就全部改
先分清：
这个地址是从哪个进程视角访问
一百三十、本机直接运行
如果：
所有服务都在 Windows 本机
那么：
127.0.0.1
通常就是本机。
一百三十一、Docker 中就不同
容器里的：
127.0.0.1
指：
当前容器自己
一百三十二、所以 Docker 服务之间
常使用：
容器服务名
例如：
ruoyi-mysql
ruoyi-redis
ruoyi-nacos
一百三十三、这是为什么 Docker Compose 配置看起来不同
不是：
框架逻辑变了
而是：
网络环境变了
一百三十四、第一次本机运行建议
统一：
MySQL localhost:3306
Redis localhost:6379
Nacos localhost:8848
先跑通。
一百三十五、修改 Nacos 数据库配置
重点确认：
URL
username
password
database
一百三十六、不要把数据库密码改在 Java 文件
正确：
Nacos 配置
一百三十七、Redis 同理
确认：
host
port
password
一百三十八、Nacos 3 认证
如果你的 Nacos：
开启认证
各服务就必须：
配置正确用户名/密码或对应认证参数
一百三十九、出现 403
例如：
user not found
往往：
不是 MyBatis 问题
而是：
Nacos 认证失败
一百四十、启动 ruoyi-system
在 IDEA 找：
RuoYiSystemApplication
启动。
一百四十一、启动成功应该关注
Server port
Nacos register
DataSource
Redis
MyBatis
一百四十二、Nacos Console
应该能看到：
ruoyi-system
一百四十三、如果 System 启动失败
先从异常底部向上看：
Caused by
一百四十四、常见原因
MySQL 未启动
数据库名错误
账号密码错误
Nacos 配置没导入
Redis 未启动
JDK 错
Maven 依赖未下载
一百四十五、再启动 ruoyi-auth
找：
RuoYiAuthApplication
一百四十六、Nacos 中
应该出现：
ruoyi-auth
一百四十七、Auth 与 System 怎么通信
这里就会看到你前面学的：
Feign
Auth：
通过 RemoteUserService
去获取：
系统用户信息
一百四十八、这就是完整项目里的 Feign
不再是课程里的：
UserClient
而是：
RemoteXXXService
一百四十九、再启动 ruoyi-gateway
找：
RuoYiGatewayApplication
一百五十、Nacos
应该看到：
ruoyi-gateway
ruoyi-auth
ruoyi-system
一百五十一、Gateway 请求如何进入
大致：
Vue
↓
Gateway : 8080
↓
Route
├─ auth
└─ system
一百五十二、登录流程大图
Vue Login Page
↓
Gateway
↓
ruoyi-auth
↓
RemoteUserService
↓
ruoyi-system
↓
查询用户/角色/权限
↓
Auth 生成 Token / 登录状态
↓
Redis
↓
返回前端
一百五十三、后续普通请求
Vue
↓
Gateway
↓
校验 Token
↓
写入用户上下文 Header
↓
业务服务
↓
权限校验
一百五十四、这是不是和我们前面 Gateway 课一样
是。
你会看到：
前面的理论
现在全部落地
一百五十五、Gateway AuthFilter
若依 Cloud 中：
网关有鉴权 Filter
会做类似：
白名单判断
Token 获取
Token 解析
Redis 登录状态验证
用户信息 Header 传递
一百五十六、为什么你现在能看懂了
因为前一课已经学过：
GlobalFilter
ServerWebExchange
Header
白名单
一百五十七、若依为什么从 Header 传用户信息
内部业务服务：
需要知道当前登录用户
Gateway：
在入口完成身份解析
然后：
传递可信上下文
一百五十八、但为什么还要 common-security
因为下游：
需要统一读取和校验这些上下文
一百五十九、不要自己改成“前端直接传 userId”
这是：
严重安全错误
一百六十、登录成功后 Redis
会保存：
登录用户状态
所以 Gateway：
可以验证登录是否仍有效
一百六十一、登录流程继续拆
登录请求：
Vue
↓
Gateway
↓
/auth/login
↓
ruoyi-auth
一百六十二、Auth 不应该自己直接访问所有 system 表
微服务边界下：
Auth
↓ Feign
System
一百六十三、System 返回登录所需用户信息
例如：
用户基本信息
角色
权限标识
状态
一百六十四、Auth 做什么
校验密码
创建登录状态
生成 Token
写 Redis
一百六十五、后续请求
Gateway：
拿 Token
↓
解析身份
↓
校验 Redis 登录状态
↓
放行
一百六十六、你前面学过的 Nacos 在哪里
所有运行服务：
启动
↓
注册 Nacos
例如：
ruoyi-gateway
ruoyi-auth
ruoyi-system
一百六十七、Feign 怎么知道 system 地址
不是：
写死 9201
而是：
服务名
+
Nacos
+
LoadBalancer
一百六十八、你前面学过的 Gateway 在哪里
就是：
ruoyi-gateway
一百六十九、你前面学过的 Sentinel 在哪里
若依 Gateway 配置中：
有 Sentinel 流控集成
官方项目也明确：
流量控制框架选型 Sentinel
一百七十、为什么这一课突然容易很多
因为你不是：
第一次看到框架
而是：
已经知道每个底层组件为什么存在
一百七十一、前端应该选哪个
若依 Cloud 当前前端提供：
Vue2
Vue3 JavaScript
Vue3 TypeScript
一百七十二、官方当前维护重心
README 明确：
Vue3 是官方主推活跃版本
一百七十三、你当前学习建议
选择：
RuoYi-Cloud-Vue3
技术：
Vue3
Vite
Element Plus
Pinia
Vue Router 4
一百七十四、为什么不建议你现在选 Vue2
你已经：
学 Vue3
并且后面项目：
更适合现代 Vue3 技术栈
一百七十五、前端仓库是独立的
当前官方 README 给出的 Vue3 Cloud 前端：
RuoYi-Cloud-Vue3
不是：
普通 RuoYi-Vue3
一百七十六、不要下错前端
RuoYi-Vue3
主要配：
RuoYi-Vue 单体后端
而：
RuoYi-Cloud-Vue3
配：
RuoYi-Cloud
一百七十七、前端克隆
官方当前地址对应：
git clone https://gitcode.com/yangzongzhuan/RuoYi-Cloud-Vue3.git
一百七十八、进入目录
cd RuoYi-Cloud-Vue3
一百七十九、安装依赖
仓库 README 当前示例使用：
yarn --registry=https://registry.npmmirror.com
一百八十、启动
yarn dev
一百八十一、如果你习惯 npm
先看：
package.json
lock 文件
README
尽量：
跟项目原本包管理器
不要混着：
npm
yarn
pnpm
导致 lock 混乱。
一百八十二、为什么包管理器不要乱换
可能：
依赖解析结果不同
然后出现：
别人能跑
你不能跑
一百八十三、Node 版本
不要只照很老文档：
Node >= 12
当前 Vue3/Vite 项目：
实际要求要看 package.json engines / 当前 Vite
一百八十四、正确动作
node -v
然后：
对照当前前端仓库要求
一百八十五、推荐 Node 管理器
Windows 可以使用：
nvm-windows
这样不同项目：
切不同 Node
一百八十六、前端环境配置
通常关注：
.env.development
.env.production
vite.config.js
一百八十七、开发代理
Vue3 Vite：
通常把 /dev-api
或者项目定义的 API 前缀
代理到 Gateway
一百八十八、最终结构
Vue Dev Server
↓
Proxy
↓
Gateway : 8080
↓
Auth / System
一百八十九、前端不是直接访问 9201
不要：
Vue → ruoyi-system:9201
一百九十、正确
Vue
↓
Gateway
↓
System
一百九十一、为什么
这样：
统一鉴权
统一路由
隐藏内部服务
一百九十二、如果登录页能打开但登录失败
前端本身：
大概率已经启动
接下来查：
Gateway
Auth
System
Redis
数据库
一百九十三、浏览器 Network 是第一工具
按：
F12
看：
Request URL
Status
Response
Request Headers
一百九十四、401
通常先查：
Token / 登录认证
一百九十五、404
通常先查：
前端 API 路径
Gateway Route
一百九十六、503
通常先查：
Nacos 服务实例
一百九十七、500
需要：
看对应后端服务日志
不能只看浏览器：
500
一百九十八、第一次部署验收
必须完成：
Nacos 有 Gateway/Auth/System
前端登录页打开
admin 登录成功
用户管理能查询
菜单正常显示
一百九十九、默认管理员密码
若依传统文档默认：
admin / admin123
但是：
以当前分支初始化 SQL 和 README 为准
不要在真实生产：
保留默认密码
二百、如果能登录说明什么
至少说明：
Vue
Gateway
Auth
System
Redis
MySQL
Nacos
这条核心链：
基本跑通
二百零一、接下来再启动 ruoyi-gen
为什么：
后面要生成业务代码
二百零二、Gen 是可选服务
核心登录：
不需要它
二百零三、所以应该在核心系统跑通以后启动
这样出现问题：
只定位 Gen
二百零四、ruoyi-job
定时任务：
当前也可不启动
二百零五、ruoyi-file
如果你暂时：
不测试上传
也可以不启动。
二百零六、Monitor
学习初期：
可选
二百零七、为什么若依拆这些服务
它们的特点：
业务职责相对独立
可以按需运行
可以单独演进
二百零八、但为什么 System 还是比较大
因为若依本身：
是通用权限后台脚手架
系统管理能力：
高度相关
没必要把：
用户/角色/菜单
各拆一个服务。
二百零九、这正好证明
微服务不是一张表一个服务
二百一十、如何阅读若依 Cloud 代码
不要：
从第一行看到最后一行
二百一十一、推荐顺序
顶层 pom
↓
模块结构
↓
每个启动类
↓
bootstrap/application 配置
↓
Nacos 配置
↓
Gateway
↓
Auth
↓
Remote API
↓
System
↓
Common
二百一十二、第一条主线：登录
跟代码：
前端 login()
↓
Gateway
↓
Auth Controller
↓
Login Service
↓
RemoteUserService
↓
System
↓
Redis
二百一十三、第二条主线：用户列表
前端 user list
↓
Gateway
↓
ruoyi-system
↓
Controller
↓
Service
↓
Mapper
↓
MySQL
二百一十四、第三条主线：文件上传
Vue
↓
Gateway
↓
ruoyi-file
二百一十五、第四条主线：代码生成
Vue
↓
Gateway
↓
ruoyi-gen
↓
读取数据库表
↓
生成模板
二百一十六、这样阅读比“按文件夹一个个看”有效得多
因为：
你在跟业务链路
二百一十七、现在进入本课第二大主题：代码修改器
课程里说的：
代码修改器
主要指：
若依框架包名/项目名修改器
二百一十八、官方项目扩展页仍然列出
若依框架包名修改器
例如：
RuoYi-common-tools
RuoYi-MT
二百一十九、它主要能改什么
公开工具说明包括：
项目包名
项目名
模块文件夹名称
pom
站点标题
部分配置
脚本
二百二十、例如
原项目：
com.ruoyi
你想改：
com.zhitu
二百二十一、原模块
ruoyi-gateway
ruoyi-auth
ruoyi-system
可能想改：
zhitu-gateway
zhitu-auth
zhitu-system
二百二十二、为什么人肉全局 Replace 很危险
因为“ruoyi”可能出现在：
包路径
Maven artifactId
目录名
YAML
SQL
Nacos DataId
Docker 路径
启动脚本
前端标题
环境变量
二百二十三、普通 IDEA Replace 不一定改目录
例如：
文件内容改了
但是：
文件夹还是 ruoyi-xxx
二百二十四、也可能误改不该改的内容
例如：
网址
第三方配置
历史注释
数据库字段值
二百二十五、修改器的价值
批量完成机械替换
减少：
人工漏改
二百二十六、但是修改器不是魔法
当前公开的 RuoYi-MT 工具：
最主要版本发布于较早时期
而当前若依：
3.6.8
Boot3/Boot4
Nacos3
项目结构已经继续变化。
二百二十七、所以正确态度
修改器：
= 批量替换助手
不是：
= 100% 正确迁移器
二百二十八、使用修改器前必须做什么
第一：
原版项目跑通
二百二十九、第二
Git commit
二百三十、第三
复制一份项目
例如：
RuoYi-Cloud-original
RuoYi-Cloud-custom
二百三十一、不要直接改唯一原版
这是：
最重要保护措施
二百三十二、修改器使用前关闭 IDEA
为什么：
IDEA 文件索引和自动重构
可能和外部批量修改：
同时操作
导致混乱。
二百三十三、修改器官方扩展提示
工具说明曾建议：
Windows 尽量避免在 C 盘权限受限位置运行
或：
必要时使用合适权限
二百三十四、为什么
批量：
改目录
改文件
重命名
需要：
文件写权限
二百三十五、最安全目录
例如：
D:\Projects\RuoYi-Cloud-custom
二百三十六、修改第一项：包名
原：
com.ruoyi
目标例如：
com.zhitu
二百三十七、包名怎么选
通常：
反向域名
例如公司域名：
example.com
包名：
com.example
二百三十八、毕设项目
没有真实域名也可以：
com.zhitu
com.nuo
com.project
但：
项目内保持统一
二百三十九、不要频繁改包名
一旦业务大量开发后：
再全局重命名
风险更高。
二百四十、所以改名时机
原版基线跑通后
↓
正式业务开发前
最好。
二百四十一、修改第二项：项目名
原：
ruoyi
例如改：
zhitu
二百四十二、项目名会影响
artifactId
module 名
脚本名
Docker 路径
项目显示标题
二百四十三、不要把所有“ruoyi”都理解成同一个概念
有：
Java 包名 com.ruoyi
Maven artifactId ruoyi-xxx
服务名 ruoyi-system
前端标题 RuoYi
数据库名称 ry-cloud
Nacos DataId ruoyi-system-dev.yml
这些：
可以改
也可以部分保留
取决于你想做什么。
二百四十四、第一次学习不建议全部改
建议先：
项目展示名称
+
Java 包名
+
业务模块
再考虑：
所有基础设施命名
二百四十五、为什么
改得越彻底：
需要同步修改的地方越多
二百四十六、修改第三项：站点名称
例如：
若依管理系统
改：
智途 AI 旅行管理平台
二百四十七、这类修改风险相对低
通常：
前端 title
Logo 文案
配置参数
二百四十八、但不要只改 index.html
当前 Vue3：
标题可能来自环境配置/系统配置
需要：
全局搜索
二百四十九、修改第四项：数据库/Redis 等配置
RuoYi-MT 历史说明支持：
部分连接配置替换
二百五十、当前若依 Cloud 为什么要更谨慎
因为很多配置：
存在 Nacos SQL / DataId
不一定只在：
本地 YAML
二百五十一、所以修改器运行后
必须检查：
sql 目录
特别：
Nacos 配置初始化 SQL
二百五十二、修改器历史说明也明确提到
RuoYi-Cloud 改完后：
可重新导入修改后的 ry_config SQL
因为：
配置内容也可能被替换
二百五十三、当前项目更要先备份数据库
如果你已经：
有自己的业务数据
不要：
随便重新导入覆盖
二百五十四、学习阶段
最简单：
使用新数据库
重新初始化。
二百五十五、修改器运行后第一件事
不是：
马上启动
而是：
git status
二百五十六、第二
git diff --stat
看：
改了多少文件
二百五十七、第三
git diff
抽查：
pom
配置
启动类
关键 Common
二百五十八、为什么要 diff
批量工具可能：
误改
漏改
Git：
让所有变化可见
二百五十九、修改后全局搜索旧包名
IDEA：
Ctrl + Shift + F
搜索：
com.ruoyi
二百六十、理想状态
如果你目标是彻底改包名：
不应残留业务 Java 引用
二百六十一、但不要看到任意 ruoyi 字符就全删
例如：
原项目 License
官方链接
说明文档
是否保留：
取决于许可和说明需求
二百六十二、一定尊重开源许可证
改项目名：
不等于可以删除许可证义务
二百六十三、第二个全局搜索
ruoyi-
检查：
Maven 模块
服务名
DataId
Docker
二百六十四、第三个搜索
RuoYi
检查：
类名
启动类
前端标题
日志提示
二百六十五、第四个搜索
ry-
看看：
数据库名
是否需要保留。
二百六十六、包目录必须一致
例如 package：
package com.zhitu.system;
目录最好：
src/main/java/com/zhitu/system
二百六十七、虽然 Java 编译不强制目录完全一致
但标准项目：
必须整理一致
二百六十八、Maven groupId 检查
顶层原：
<groupId>com.ruoyi</groupId>
如果改包名：
是否也计划改 groupId
要统一决定。
二百六十九、groupId 和 Java package 不是必须一样
但通常项目：
保持同一组织语义
更清晰。
二百七十、模块 artifactId 检查
例如：
ruoyi-common-core
如果改成：
zhitu-common-core
所有依赖：
必须同步
二百七十一、为什么这里最容易 Maven 爆红
子模块：
artifactId 已改
但另一个模块：
还依赖旧 artifactId
二百七十二、解决
执行：
mvn clean install -DskipTests
二百七十三、如果提示找不到 com.ruoyi:xxx
说明：
还有旧 Maven 坐标
二百七十四、全局搜索
<groupId>com.ruoyi</groupId>
以及：
<artifactId>ruoyi-
二百七十五、Spring Application 类名检查
例如：
RuoYiGatewayApplication
修改器可能：
不一定按你期待改类名
二百七十六、类名不改能不能运行
通常：
能
因为：
类名不是包名
二百七十七、但是项目品牌化
你可能希望：
ZhiTuGatewayApplication
二百七十八、这种类名重构最好怎么做
推荐 IDEA：
Shift + F6
Rename Refactor。
二百七十九、为什么不要纯文本替换 Java 类名
IDEA Refactor：
会更新引用
更安全。
二百八十、Spring 自动配置文件检查
这是改包名特别容易漏的地方。
现代 Spring Boot 可能使用：
META-INF/spring/
org.springframework.boot.autoconfigure.AutoConfiguration.imports
二百八十一、旧项目还可能有
META-INF/spring.factories
二百八十二、为什么必须搜
里面可能写：
com.ruoyi.xxx.SomeAutoConfiguration
二百八十三、如果包名改了但这里没改
表现：
ClassNotFoundException
或：
某个自动配置完全没加载
二百八十四、RuoYi-MT 历史版本更新中特别提过
曾修复：
RuoYi-Cloud .imports 未修改问题
这正说明：
自动配置 imports 是批量改名高风险点
二百八十五、所以当前 Boot3 更要检查
全局搜索：
com.ruoyi
一定包括：
resources/META-INF
二百八十六、Nacos DataId 检查
原：
ruoyi-gateway-dev.yml
如果服务名改：
zhitu-gateway
你必须决定 DataId：
是否同步改
二百八十七、服务名、DataId、配置加载关系必须保持一致
否则：
服务注册成功
但配置加载失败
二百八十八、为什么这是 Cloud 改名最难的地方
单体改包名：
主要改代码
Cloud：
代码 + 配置中心 + 服务名
必须同步。
二百八十九、Nacos 服务名检查
例如原：
ruoyi-system
如果改：
zhitu-system
所有 Feign：
必须找到新服务名
二百九十、常量里可能存服务名
例如：
ServiceNameConstants
二百九十一、修改器后必须重点检查这个类
因为 Feign：
可能不是直接写字符串
而是引用：
服务名常量
二百九十二、Gateway Route 也要检查
Nacos 中原：
lb://ruoyi-system
如果服务改名：
必须同步
二百九十三、否则
Gateway：
503
二百九十四、Feign 和 Gateway 都依赖服务名
所以改服务名：
影响范围非常大
二百九十五、初学者是否一定要改所有服务名
不一定。
你可以：
保留框架底层 ruoyi-xxx
只新增：
zhitu-travel
自己的业务服务。
二百九十六、这往往更稳
尤其：
毕业设计
时间有限
没有必要为了“看起来完全原创”：
把所有基础设施名字都改掉
二百九十七、真正体现你开发能力的是
业务模块
数据库设计
接口
AI 功能
缓存
检索
微服务治理
不是：
把 ruoyi 六个字母改掉
二百九十八、项目修改的三档方案
方案 A：最稳
保留：
com.ruoyi
ruoyi-gateway
ruoyi-auth
ruoyi-system
只新增：
自己的业务服务
二百九十九、适合
学习
时间紧
课程项目
三百、方案 B：中等改造
改：
前端标题
Logo
业务模块名
新增业务包
保留：
底层若依公共模块
三百零一、这是我更推荐的课程方式
因为：
风险较低
又能：
体现业务项目
三百零二、方案 C：彻底品牌化
改：
com.ruoyi
所有 ruoyi-xxx 模块
服务名
Nacos DataId
Docker
脚本
前端品牌
三百零三、适合
企业二次发行
有充分测试时间
三百零四、不适合
第一次接触若依 Cloud
就直接做。
三百零五、为什么课程仍讲修改器
因为你需要知道：
批量品牌化工具怎么工作
和：
改 Cloud 框架为什么比单体复杂
三百零六、修改器操作顺序建议
Step 1
复制原项目
Step 2
Git 建分支
Step 3
记录目标包名/项目名
Step 4
关闭 IDEA
Step 5
运行修改器
Step 6
选择项目目录
Step 7
配置包名替换
Step 8
配置项目名替换
Step 9
配置标题
Step 10
执行
Step 11
查看工具日志
Step 12
git diff
Step 13
全局搜索旧关键字
Step 14
mvn clean install
Step 15
重新导入 SQL/Nacos 配置
Step 16
逐服务启动
三百零七、不要直接做“修改后全服务启动”
应该：
先 Maven 编译
三百零八、Maven 编译通过后
再：
System
三百零九、System 成功后
再：
Auth
三百一十、再 Gateway
三百一十一、然后前端
这样：
每次只增加一层
三百一十二、修改后 Maven 第一类错误
Could not find artifact
通常：
模块坐标没改全
三百一十三、第二类
package com.ruoyi.xxx does not exist
说明：
Java 引用残留
三百一十四、第三类
ClassNotFoundException
重点：
自动配置 imports/spring.factories
三百一十五、第四类
No qualifying bean
可能：
包扫描范围变了
三百一十六、为什么包扫描会受影响
启动类：
位于根包
Spring Boot 默认：
扫描启动类所在包及子包
三百一十七、如果改包时目录层级乱了
Bean：
可能不再被扫描
三百一十八、第五类
Feign no instances available
重点：
服务名改了
但：
Feign/Gateway/Nacos 没同步
三百一十九、第六类
Could not resolve placeholder
可能：
Nacos DataId 改名后配置没加载
三百二十、第七类
数据库连接失败
如果修改器改过配置：
重新检查 Nacos SQL
三百二十一、第八类
Redis 连接失败
检查：
Host
Port
Password
三百二十二、第九类
前端一直 404
检查：
.env
Vite proxy
Gateway Route
服务名
三百二十三、第十类
登录失败但所有服务都启动
检查链：
Gateway
↓
Auth
↓
RemoteUserService
↓
System
↓
DB
↓
Redis
三百二十四、修改后完整搜索清单
搜索：
com.ruoyi
三百二十五、搜索
ruoyi-
三百二十六、搜索
RuoYi
三百二十七、搜索
ry-cloud
三百二十八、搜索
ry-config
三百二十九、搜索
lb://ruoyi-
三百三十、搜索
ruoyi-system
三百三十一、搜索
ruoyi-auth
三百三十二、搜索
ruoyi-gateway
三百三十三、搜索范围
一定包括：
Java
XML
YAML
properties
SQL
Docker
Shell
Batch
Vue
JSON
META-INF
三百三十四、IDEA 全局搜索快捷键
Ctrl + Shift + F
三百三十五、类/包重构快捷键
Shift + F6
Rename。
三百三十六、查引用
Alt + F7
三百三十七、为什么 IDEA Refactor 和修改器要配合
修改器：
适合大规模机械替换
IDEA：
适合精确 Java 符号重构
三百三十八、不要让 Cursor 直接全局“随便改若依”
AI 批量修改一样：
可能漏隐藏配置
三百三十九、正确给 Cursor 的任务
先分析所有 ruoyi/com.ruoyi 引用
按类别输出
不要修改
三百四十、再分批改
第一批：
Java package
第二批：
Maven module
第三批：
服务名
第四批：
Nacos
第五批：
前端
三百四十一、为什么 AI 也必须分批
一次改：
上千文件
你无法 Review。
三百四十二、代码修改器和代码生成器不是一回事
这一点必须区分。
修改器：
改框架自身名称/包名
代码生成器：
根据数据库表生成 CRUD
三百四十三、RuoYi-Cloud 自带 Gen
就是：
ruoyi-gen
三百四十四、所以不要把两个概念混在一起
RuoYi-MT
→ 改若依框架
ruoyi-gen
→ 生成业务 CRUD
三百四十五、当前课为什么顺便认识 Gen
因为部署完成以后：
你很快就会用它生成业务模块
三百四十六、代码生成基本流程
先建数据库表
↓
启动 ruoyi-gen
↓
系统工具
↓
代码生成
↓
导入表
↓
配置字段
↓
预览
↓
生成
三百四十七、生成内容通常包括
Controller
Service
Mapper
Mapper XML
Domain/Entity
前端 API
Vue 页面
菜单 SQL
三百四十八、为什么不能“生成完直接提交”
因为生成器只能：
生成通用 CRUD 骨架
不知道你的：
复杂业务规则
三百四十九、例如旅行订单
生成器可以生成：
新增
修改
删除
查询
但不知道：
订单什么时候能取消
三百五十、所以生成代码后必须二次开发
加入：
状态机
权限
唯一约束
事务
业务校验
VO/DTO
三百五十一、这和你前面淘车湾项目一致
不能：
Controller 直接万能 CRUD
三百五十二、代码生成前数据库表要设计好
因为生成器：
读取数据库字段和注释
三百五十三、表字段注释很重要
例如：
status char(1) comment '状态（0正常 1停用）'
可以帮助：
生成字段说明
三百五十四、字典字段
生成器可以结合：
系统字典
生成下拉/标签。
三百五十五、代码生成不是 AI
它是：
模板引擎
若依项目中使用：
Velocity
三百五十六、为什么生成很稳定
同一个模板：
输入同样表结构
输出：
可预测
三百五十七、AI 和代码生成器可以配合
代码生成器：
搭 CRUD 骨架
Cursor：
分析业务规则并二次开发
三百五十八、这是后面项目非常高效的工作流
数据库设计
↓
若依 Gen
↓
生成基础 CRUD
↓
Cursor 阅读生成代码
↓
添加业务逻辑
↓
人工 Review
三百五十九、不要让 AI 先生成所有 CRUD
若依已经有：
成熟模板
重复造：
没必要
三百六十、什么时候手写页面
复杂页面：
生成器模板不合适
就：
手工 Vue3
后面的智途项目会逐渐实践。
三百六十一、在若依 Cloud 中增加自己的业务应该放哪里
例如下一阶段：
智途 AI 旅行
不要：
把景点、酒店、排行榜
全部塞进 ruoyi-system
三百六十二、为什么
ruoyi-system：
是框架系统管理服务
不是：
你的万能业务模块
三百六十三、推荐新增业务服务
例如：
ruoyi-modules
├─ ruoyi-system
├─ ruoyi-gen
├─ ruoyi-job
├─ ruoyi-file
└─ ruoyi-travel
三百六十四、如果彻底业务品牌化
可以叫：
zhitu-travel
但如果框架基础模块保持若依原名：
ruoyi-travel
也完全可以。
三百六十五、课程推荐
先：
保留若依基础框架命名
新增：
ruoyi-travel
这样：
最稳
三百六十六、ruoyi-travel 应该是什么
一个：
独立 Spring Boot 微服务
拥有：
自己的启动类
自己的 Controller
Service
Mapper
数据库业务表
Nacos 配置
三百六十七、服务名
例如：
spring:
application:
name: ruoyi-travel
三百六十八、端口
例如：
9301
只要：
不与现有服务冲突
三百六十九、为什么端口本身不是前端契约
前端：
只访问 Gateway
所以内部：
9301
属于：
服务部署细节
三百七十、Nacos 注册
新增服务必须：
注册 Nacos
否则 Gateway：
lb://ruoyi-travel
找不到实例。
三百七十一、Gateway 增加路由
例如外部：
/travel/**
转：
lb://ruoyi-travel
三百七十二、具体路径前缀
应：
按当前若依 Gateway Route 规范
不要凭空另起一套。
三百七十三、为什么要跟脚手架规范
前端、Gateway、权限、Swagger：
都已经有统一约定
三百七十四、业务服务需要哪些 common
通常按需求：
core
security
datasource
log
swagger
redis
三百七十五、不要一股脑依赖全部 common
例如服务根本不用：
Seata
就：
暂时不要引入
三百七十六、业务服务是否需要 api 模块
如果：
其他服务要 Feign 调它
可以增加：
ruoyi-api-travel
三百七十七、如果没人远程调用
暂时：
不用为了架构好看创建 api
三百七十八、为什么
过度模块化：
也增加维护成本
三百七十九、以后 AI Service
如果多个服务都要调用 AI：
可以独立：
ruoyi-ai
三百八十、但课程当前
先：
不要提前拆
等后面 AI 功能真正出现：
再决定
三百八十一、哪些若依核心代码尽量不要乱改
第一：
ruoyi-common-core
三百八十二、第二
ruoyi-common-security
三百八十三、第三
Gateway 核心鉴权
三百八十四、第四
Remote Service 公共调用机制
三百八十五、第五
权限注解和数据权限基础设施
三百八十六、为什么
这些属于：
脚手架稳定基础层
随意修改：
可能影响所有业务服务
三百八十七、什么情况下可以改
你已经：
明确理解调用链
并且：
有业务需求
+
有测试
再改。
三百八十八、不要为了“原创率”重写 Security
这会：
增加漏洞风险
三百八十九、毕设/项目应该把精力放哪里
真实业务模型
数据库
AI
缓存
搜索
排行榜
接口
用户体验
三百九十、框架不是你项目的全部
若依只是：
基础设施
三百九十一、如何证明你真正会若依 Cloud
不是说：
“我会下载若依”
而是能解释：
登录从哪走
服务怎么发现
Feign 怎么调用
Gateway 怎么路由
权限怎么传
配置在哪里
业务服务怎么新增
三百九十二、第一次运行常见错误 1：下错分支
表现：
教程代码完全对不上
或者：
Spring Boot 4 API
三百九十三、排查
git branch
三百九十四、你当前应看到
springboot3
三百九十五、常见错误 2：JDK 不是 17
执行：
java -version
三百九十六、再检查 Maven 实际 JDK
mvn -v
三百九十七、为什么两个都要查
IDEA JDK：
17
但 Maven：
可能仍然使用另一个 JAVA_HOME
三百九十八、你以前遇到过类似问题
所以以后固定：
java -version
mvn -v
一起检查。
三百九十九、错误 3：Maven 依赖下载失败
表现：
Could not resolve artifact
四百、检查
网络
Maven settings.xml
镜像
本地仓库
四百零一、不要随便删除整个 .m2
除非：
确认本地缓存真的损坏
四百零二、错误 4：Nacos 连接失败
表现：
get config error
server check fail
connection refused
四百零三、检查
Nacos 是否启动
8848
认证
IP
Namespace
四百零四、Windows 看端口
netstat -ano | findstr 8848
四百零五、错误 5：Nacos 403
重点：
认证
不是：
Java 包名
四百零六、错误 6：Nacos 有服务但配置读取失败
说明：
Discovery 和 Config 是两条链
四百零七、检查
配置 DataId
Group
Namespace
配置内容
四百零八、错误 7：Redis connection refused
确认：
6379
Redis 服务
密码
四百零九、Windows
netstat -ano | findstr 6379
四百一十、错误 8：MySQL access denied
说明：
账号密码错误
四百一十一、错误 9：Unknown database
说明：
数据库还没建/名称不一致
四百一十二、错误 10：Table doesn’t exist
很可能：
SQL 脚本没导入完整
或者：
版本不匹配
四百一十三、错误 11：Mapper XML 解析失败
检查：
XML
typeAlias
跨模块类
MyBatis 配置
四百一十四、如果你自己改过包名
优先检查：
XML 中旧全限定类名
四百一十五、例如
resultType="com.ruoyi.xxx.Xxx"
改包后：
必须同步
四百一十六、错误 12：Feign 找不到服务
表现：
No instances available
四百一十七、查
Nacos 服务列表
service name
Namespace
四百一十八、如果刚用修改器改服务名
优先查：
ServiceNameConstants
@FeignClient
Gateway Route
四百一十九、错误 13：Gateway 503
大概率：
目标服务无可用实例
四百二十、错误 14：Gateway 404
查：
Route
Path
StripPrefix/Rewrite
Controller
四百二十一、错误 15：登录返回 401
先查：
Auth
账号密码
Token
Redis
四百二十二、错误 16：提示登录状态过期
可能：
Redis 登录 Key 不存在
四百二十三、错误 17：提示没有权限
不要马上改代码。
先查：
用户角色
角色菜单
权限标识
后台权限字符串
四百二十四、为什么
若依权限是：
配置 + 代码
必须一致。
四百二十五、错误 18：前端菜单看不到
可能：
权限
菜单配置
动态路由
四百二十六、错误 19：前端接口一直走错地址
查：
.env.development
Vite Proxy
baseURL
四百二十七、错误 20：修改器后 Maven 模块消失
检查：
父 pom modules
和：
真实文件夹名
是否一致。
四百二十八、错误 21：包名改了但 Spring Bean 找不到
查：
启动类包位置
@ComponentScan
@MapperScan
@EnableFeignClients
四百二十九、错误 22：AutoConfiguration 不加载
重点：
META-INF/spring/*.imports
spring.factories
四百三十、错误 23：Nacos 配置名称仍是旧项目名
表现：
服务启动但大量 placeholder 缺失
四百三十一、错误 24：Gateway 路由还指向旧 serviceName
表现：
503
四百三十二、错误 25：Docker 修改后路径报错
查：
docker-compose.yml
build context
Dockerfile
volume path
container name
四百三十三、为什么 Docker 是修改器高风险区
因为：
文件夹名
一改：
build context 也要改
四百三十四、错误 26：脚本启动找不到 jar
查：
bin/*.sh
*.bat
里面：
旧 artifact 名
四百三十五、错误 27：前端标题还是若依
查：
.env
index.html
系统参数
Layout
Logo 组件
四百三十六、错误 28：浏览器 Logo 还是旧的
静态资源：
public
src/assets
单独替换。
四百三十七、错误 29：修改器日志有错误
不要立即认为：
整个项目失败
工具自身说明也提到：
某些文件替换失败需要人工检查
四百三十八、真正判断标准
Git Diff
+
全局搜索
+
Maven Build
+
逐模块运行
四百三十九、错误 30：改名后数据库 SQL 仍有旧配置
尤其：
ry_config SQL
重新检查：
Nacos DataId
服务名
数据库 URL
Redis
四百四十、修改器验证矩阵
修改完成后按顺序：
Maven
↓
System
↓
Auth
↓
Gateway
↓
Vue
↓
Gen
四百四十一、第一阶段：静态验证
git diff
Ctrl+Shift+F
四百四十二、第二阶段：编译验证
mvn clean install -DskipTests
四百四十三、第三阶段：基础设施验证
MySQL
Redis
Nacos
四百四十四、第四阶段：服务验证
System
Auth
Gateway
四百四十五、第五阶段：端到端验证
前端登录
四百四十六、第六阶段：业务验证
用户列表
菜单
字典
代码生成
四百四十七、如果任何阶段失败
不要：
继续下一阶段
先：
把当前层修好
四百四十八、这叫分层排错
四百四十九、本地端口表
可以自己做：
Nacos 8848
Gateway 8080
Auth 9200
System 9201
Gen 9202
Job 9203
File 9300
Monitor 9100
Redis 6379
MySQL 3306
四百五十、为什么要维护端口表
微服务多以后：
端口冲突非常常见
四百五十一、IDEA Run Configuration 命名
RuoYi-Gateway-8080
RuoYi-Auth-9200
RuoYi-System-9201
四百五十二、Services 窗口
IDEA：
View
→ Tool Windows
→ Services
统一看：
多个 Spring Boot
四百五十三、控制台不要混看
每次报错先确认：
这是 Gateway 日志？
Auth 日志？
System 日志？
四百五十四、一个请求怎么找对应日志
例如用户列表：
前端
↓
Gateway
↓
System
主要业务异常：
System
四百五十五、登录：
Gateway
↓
Auth
↓
System
三个：
都可能有日志
四百五十六、为什么 TraceId 很有价值
以后请求跨服务：
搜索同一个 TraceId
就能：
串起调用链
四百五十七、若依 Cloud 更新策略
如果你直接修改：
框架核心几百处
以后同步官方：
非常痛苦
四百五十八、所以企业二开建议
尽量：
新增
>
修改
四百五十九、例如业务功能
新增：
ruoyi-travel
比：
把 travel 写进 ruoyi-system
更利于维护。
四百六十、公共能力也不要一上来改 core
先问：
能不能在自己的 common 扩展模块实现
四百六十一、例如
ruoyi-common-ai
未来有必要：
再新增
四百六十二、不要为了一个工具类就新建 common-ai
仍然：
按真实复用价值决定
四百六十三、若依升级时怎么减少冲突
核心思路：
减少对官方基础模块的侵入式修改
四百六十四、Git Remote 策略
可以保留：
upstream
指向若依官方。
自己的：
origin
指向自己的仓库。
四百六十五、例如
git remote -v
四百六十六、同步官方更新时
先：
看 changelog
不要：
直接 merge 后祈祷
四百六十七、为什么 changelog 很重要
例如当前 3.6.8：
升级 Boot/Cloud
代码生成 TypeScript 支持
安全/功能优化
这些可能：
影响你的二次开发
四百六十八、当前 3.6.8 一个明显事实
默认 master：
已经切 Spring Boot 4
四百六十九、但 springboot3 继续维护
这对你非常友好：
可以继续用 JDK17 + Boot3
四百七十、不要误解为 Boot3 已经不能用
官方：
仍然并行维护 springboot3
四百七十一、代码修改器安全清单
运行前：
[ ] 原版能启动
[ ] 当前分支正确
[ ] Git 工作区干净
[ ] 已创建备份/分支
[ ] 已记录原包名
[ ] 已记录目标包名
[ ] 已记录原项目名
[ ] 已记录目标项目名
[ ] IDEA 已关闭
四百七十二、运行后：
[ ] git status
[ ] git diff
[ ] 搜 com.ruoyi
[ ] 搜 ruoyi-
[ ] 搜 RuoYi
[ ] 检查 pom
[ ] 检查 META-INF
[ ] 检查 Nacos SQL
[ ] 检查 ServiceNameConstants
[ ] 检查 Feign
[ ] 检查 Gateway Routes
[ ] 检查 Docker
[ ] 检查脚本
[ ] 检查前端 env
四百七十三、构建后：
[ ] mvn clean install
[ ] MySQL 正常
[ ] Redis 正常
[ ] Nacos 正常
[ ] System 正常
[ ] Auth 正常
[ ] Gateway 正常
[ ] Vue 登录成功
四百七十四、为什么清单这么长
Cloud 项目：
不是单个 Java 工程
而是：
代码
+
服务名
+
配置中心
+
数据库
+
前端
+
Docker
+
脚本
四百七十五、Cursor 提示词：先读若依 Cloud
请先阅读当前 RuoYi-Cloud 项目，不修改任何代码。
当前分支必须是 springboot3。
请输出：
1. 顶层 Maven 模块
2. 每个可运行服务及端口
3. ruoyi-gateway 职责
4. ruoyi-auth 职责
5. ruoyi-system 职责
6. ruoyi-api 的 Feign 契约
7. ruoyi-common 每个子模块作用
8. Nacos 配置从哪里读取
9. Redis 在登录中的作用
10. 登录完整调用链
禁止先重构。
四百七十六、Cursor 提示词：部署检查
我要在 Windows + IDEA + JDK17 环境运行 RuoYi-Cloud springboot3。
请按顺序检查：
1. git branch
2. java -version
3. mvn -v
4. MySQL
5. Redis
6. Nacos 3.x
7. 当前分支 sql 目录
8. Nacos 配置 SQL
9. ruoyi-system
10. ruoyi-auth
11. ruoyi-gateway
每一步给出“成功判据”。
不要一次让我启动所有可选模块。
四百七十七、Cursor 提示词：登录链追踪
请从前端登录按钮开始追踪 RuoYi-Cloud 登录链。
按调用顺序列出：
Vue API
→ Gateway Route/Filter
→ ruoyi-auth Controller
→ 登录 Service
→ RemoteUserService
→ ruoyi-system
→ Redis
→ Token 返回
每一步给出：
类名
方法
服务名
输入
输出
只分析，不修改。
四百七十八、Cursor 提示词：Feign 关系
请扫描当前 RuoYi-Cloud springboot3 中所有主要 @FeignClient。
输出：
1. Feign 接口
2. 所在 ruoyi-api 子模块
3. 目标 serviceName
4. 哪些业务服务调用
5. fallback/fallbackFactory
6. 对应 Provider Controller
目的是画出服务依赖图。
四百七十九、Cursor 提示词：包名修改前审计
我准备把 com.ruoyi 改为 com.zhitu。
现在不要修改。
请全项目搜索并分类所有 com.ruoyi 引用：
1. Java package/import
2. pom groupId
3. XML resultType/typeAlias
4. META-INF/spring/*.imports
5. spring.factories
6. YAML/properties
7. SQL
8. Docker
9. Shell/Batch
10. Vue/JSON
输出风险清单和数量。
四百八十、Cursor 提示词：修改器后审计
我刚用若依框架修改器完成批量替换。
请不要继续批量修改。
先审计：
1. git diff
2. 残留 com.ruoyi
3. 残留旧 artifactId
4. 父 pom modules 与真实目录
5. ServiceNameConstants
6. @FeignClient
7. Gateway lb://
8. Nacos DataId
9. META-INF AutoConfiguration.imports
10. spring.factories
11. Docker build context
12. 前端 env/title
输出“必须修”“建议修”“可保留”三类。
四百八十一、Cursor 提示词：Maven 改名错误
修改若依项目名后 Maven 构建失败。
请根据实际错误和 dependency tree 检查：
1. parent 坐标
2. groupId
3. artifactId
4. modules
5. 子模块 dependency
6. dependencyManagement
7. 是否还有 com.ruoyi:ruoyi-* 坐标
不要直接修改版本号。
四百八十二、Cursor 提示词：新增 Travel 微服务
请基于当前 RuoYi-Cloud springboot3 新增一个最小业务服务 ruoyi-travel。
要求：
1. 放在 ruoyi-modules
2. 父 pom 正确聚合
3. 使用现有 common 模块，不重写框架
4. 注册 Nacos
5. 独立端口
6. 独立 Nacos 配置 DataId
7. Gateway 增加 lb://ruoyi-travel Route
8. 创建一个 /travel/health 测试接口
9. 暂时不要加数据库业务
10. 给出逐层验证步骤
四百八十三、Cursor 提示词：框架侵入审查
请审查我的二次开发是否过度修改若依核心。
统计我对以下模块的改动：
ruoyi-common-core
ruoyi-common-security
ruoyi-gateway
ruoyi-auth
ruoyi-system
判断哪些业务代码应该迁移到：
新的 ruoyi-modules 业务服务
或独立扩展 common 模块。
目标：
减少未来同步若依官方更新时的冲突。
四百八十四、Cursor 提示词：前端联调
当前后端 Gateway 8080，
前端使用 RuoYi-Cloud-Vue3。
请检查：
1. .env.development
2. API base URL
3. Vite proxy
4. 登录 URL
5. Network 实际 Request URL
6. Gateway 是否收到
7. CORS 是否重复配置
不要让前端直接访问 ruoyi-system:9201。
四百八十五、Cursor 提示词：部署故障树
若依 Cloud 登录失败。
请按状态码建立故障树：
无法连接
→ Gateway 是否启动
404
→ 前端路径/Gateway Route
503
→ Nacos/目标实例
401
→ Auth/Token/Redis
500
→ Auth/System/数据库业务异常
每一种都列：
应该看哪个服务日志
应该检查哪个配置
禁止无依据重装环境。
四百八十六、面试题 1：RuoYi-Cloud 和 RuoYi-Vue 区别
答：
RuoYi-Vue 是前后端分离的 Spring Boot 单体后端，
主要业务模块运行在同一个应用中。
RuoYi-Cloud 是基于 Spring Cloud & Alibaba 的微服务版本，
将 Gateway、认证中心、系统服务、文件、代码生成等能力
拆分为多个服务，并使用 Nacos、Feign、Sentinel、Redis 等组件治理。
四百八十七、面试题 2：RuoYi-Cloud 中 Gateway 做什么
答：
ruoyi-gateway 是外部统一入口。
它负责路由到内部服务，并承担白名单、
基础鉴权、安全 Header、异常处理以及入口流量治理等横切能力。
业务 CRUD 不应该集中写在 Gateway。
四百八十八、面试题 3：ruoyi-auth 为什么独立
答：
ruoyi-auth 是认证中心，
负责登录校验、Token 和登录状态相关逻辑。
它通过远程接口获取 system 服务中的用户、角色和权限信息，
从而使认证职责与系统业务数据职责分离。
四百八十九、面试题 4：ruoyi-api 是什么
答：
ruoyi-api 主要承载微服务之间的远程接口契约。
其中可以定义 Feign Client、远程 DTO 和服务调用常量。
它不是一个独立启动的业务服务，
而是供 Consumer 和 Provider 共享接口契约的 Maven 模块。
四百九十、面试题 5：ruoyi-common 是什么
答：
ruoyi-common 是若依 Cloud 的通用基础依赖集合。
其中按职责拆分 core、security、redis、datascope、
datasource、log、seata、sensitive、swagger 等模块。
业务微服务按需要引用它们，
从而复用框架基础能力。
四百九十一、面试题 6：Nacos 在若依 Cloud 中做什么
答：
Nacos 同时承担服务注册发现和集中配置管理。
Gateway、Auth、System 等服务启动后注册到 Nacos，
服务间可以通过服务名动态发现实例。
同时数据库、Redis、Gateway 路由等公共或服务配置
也可以从 Nacos Config 加载。
四百九十二、面试题 7：Redis 在登录流程中做什么
答：
Redis 用于保存登录会话和 Token 对应的用户状态等缓存数据。
Gateway 收到请求后，可以结合 Token 和 Redis 中的登录状态
判断用户是否仍然有效。
因此 Redis 异常可能直接影响登录和鉴权链路。
四百九十三、面试题 8：若依 Cloud 登录链路怎么走
答：
前端登录请求先进入 Gateway，
再路由到 ruoyi-auth。
Auth 通过 RemoteUserService 调用 ruoyi-system 获取用户信息，
校验登录后创建 Token/登录状态并保存到 Redis，
最后将 Token 返回前端。
后续请求由 Gateway 检查 Token 和登录状态后再转发业务服务。
四百九十四、面试题 9：为什么不能把业务都写 ruoyi-system
答：
ruoyi-system 的职责是用户、角色、菜单、部门、字典等系统管理能力。
自己的旅行、电商或工单业务应该建立独立业务微服务，
避免 system 演变成新的超级单体。
这也有利于独立部署、扩容和后续维护。
四百九十五、面试题 10：为什么修改包名前要先跑通原版
答：
原版跑通可以建立一个可运行基线。
如果下载后立刻批量修改数百个文件再出现故障，
很难判断问题来自环境、原框架还是修改操作。
先建立基线，再通过 Git diff 审查修改，
能显著降低排错难度。
四百九十六、面试题 11：若依修改器主要修改什么
答：
若依框架修改器主要用于批量替换项目包名、
项目名、模块名称、POM、站点标题和部分配置或脚本。
它解决的是框架品牌化和机械重命名问题，
与根据数据库表生成 CRUD 的代码生成器不是同一种工具。
四百九十七、面试题 12：为什么不能完全相信修改器
答：
批量修改器只能根据预设规则处理已知文件结构。
若依 Cloud 会持续升级，
Boot 3/4、自动配置 imports、Nacos DataId、
Docker 和前端结构都可能发生变化。
因此修改器应该作为辅助工具，
运行后仍必须通过 Git diff、全局搜索、Maven 构建和逐模块启动验证。
四百九十八、面试题 13：改服务名为什么比改 Java 包名危险
答：
服务名不仅存在于 Java 代码，
还可能被 Nacos 注册、Feign Client、
ServiceNameConstants、Gateway lb:// Route
以及配置中心 DataId 引用。
任意一处漏改都会导致服务发现或配置加载失败，
因此服务名属于分布式系统契约的一部分。
四百九十九、面试题 14：为什么检查 META-INF/spring/*.imports
答：
Spring Boot 自动配置类可能通过
META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports
进行注册。
包名批量修改后如果这些全限定类名仍然是旧 com.ruoyi，
可能产生 ClassNotFoundException 或自动配置不加载。
所以它是改包名后的重点检查位置。
五百、面试题 15：代码修改器和 ruoyi-gen 区别
答：
代码修改器针对的是若依框架本身的包名、项目名和品牌等批量重命名。
ruoyi-gen 是代码生成服务，
根据数据库表结构通过模板生成 Controller、
Service、Mapper、XML、前端页面和菜单 SQL 等 CRUD 骨架。
一个是改框架，一个是生成业务代码。
五百零一、面试题 16：为什么代码生成后还要二次开发
答：
代码生成器只知道数据库表结构和模板，
不知道具体业务规则。
订单状态流转、重复提交、权限、事务、
金额计算、复杂校验等仍然需要开发人员设计和实现。
所以生成器适合减少机械 CRUD，
不能替代业务建模。
五百零二、面试题 17：RuoYi-Cloud 为什么适合学习微服务
答：
它把 Gateway、Nacos、Feign、Sentinel、
Redis、认证、远程接口等常见微服务组件组织在完整项目中。
学习者可以从真实调用链理解组件如何协作，
而不是只看孤立 Demo。
五百零三、面试题 18：为什么业务服务应尽量少改框架核心
答：
官方框架核心会持续升级。
如果自己的业务大量侵入 common、auth、gateway 等基础模块，
未来同步官方安全修复和版本升级时会产生大量冲突。
因此更推荐新增业务模块，
以扩展方式复用框架基础能力。
五百零四、面试题 19：springboot3 分支为什么重要
答：
当前 RuoYi-Cloud 默认 master 已经采用 Spring Boot 4.x。
如果项目主线仍然是 JDK17 + Spring Boot 3，
应该切换官方 springboot3 分支。
选错分支会导致课程依赖、API 和配置方式与代码不匹配。
五百零五、面试题 20：部署若依 Cloud 最好的排错方式
答：
采用分层验证。
先验证 MySQL、Redis、Nacos，
再逐个验证 System、Auth、Gateway，
最后验证 Vue 端到端登录。
根据 404、401、503、500 等状态码
定位 Gateway、认证、服务发现或业务服务，
而不是一次性修改所有组件。
五百零六、本章知识树
RuoYi-Cloud
│
├─ Version
│ ├─ master → Boot 4
│ ├─ springboot3 → Boot 3
│ ├─ JDK17
│ └─ v3.6.8
│
├─ Infrastructure
│ ├─ MySQL
│ ├─ Redis
│ ├─ Nacos
│ ├─ Sentinel
│ └─ Seata
│
├─ Runtime Services
│ ├─ ruoyi-gateway
│ ├─ ruoyi-auth
│ ├─ ruoyi-system
│ ├─ ruoyi-gen
│ ├─ ruoyi-job
│ ├─ ruoyi-file
│ └─ ruoyi-monitor
│
├─ API
│ └─ ruoyi-api-system
│ ├─ Feign
│ └─ Remote DTO
│
├─ Common
│ ├─ core
│ ├─ security
│ ├─ redis
│ ├─ datascope
│ ├─ datasource
│ ├─ log
│ ├─ seata
│ ├─ sensitive
│ └─ swagger
│
├─ Login Flow
│ ├─ Vue
│ ├─ Gateway
│ ├─ Auth
│ ├─ Feign
│ ├─ System
│ └─ Redis
│
├─ Frontend
│ ├─ Vue3
│ ├─ Vite
│ ├─ Element Plus
│ ├─ Pinia
│ └─ Gateway Proxy
│
├─ Modifier
│ ├─ Package
│ ├─ Project Name
│ ├─ Maven
│ ├─ Service Name
│ ├─ Nacos DataId
│ ├─ Docker
│ ├─ Script
│ ├─ Vue
│ └─ META-INF
│
├─ Generator
│ ├─ DB Table
│ ├─ Velocity
│ ├─ Java
│ ├─ XML
│ ├─ Vue
│ └─ SQL
│
└─ Custom Service
├─ ruoyi-travel
├─ Nacos
├─ Gateway Route
├─ Common Dependencies
└─ Optional API Module
五百零七、前五课终于完整串起来了
第 1 课
系统为什么需要微服务
↓
第 2 课
Nacos 找服务
Feign 调服务
↓
第 3 课
Sentinel 保护服务
↓
第 4 课
Gateway 统一入口
↓
第 5 课
RuoYi-Cloud
把上面全部组装起来
五百零八、若依 Cloud 完整调用图
Vue3
│
▼
ruoyi-gateway
/ \
/ \
▼ ▼
ruoyi-auth ruoyi-system
│ ▲
│ Feign │
└───────────────────┘
RemoteUser
│
▼
Redis
所有运行服务
│
▼
Nacos
注册中心 + 配置中心
入口/资源稳定性
│
▼
Sentinel
五百零九、以后自己的业务
Vue
↓
Gateway
↓
ruoyi-travel
├─ MySQL
├─ Redis
├─ ES
├─ OSS
└─ AI
如果要系统用户：
ruoyi-travel
↓ Feign
ruoyi-system
五百一十、本章最重要的 30 条原则
1. 当前默认 master 是 Boot4，Boot3 学习必须切 springboot3
2. 下载代码后第一件事是确认 Git 分支
3. 当前 Boot3 分支使用 JDK17+
4. 当前版本 SQL 必须配当前版本代码
5. Nacos、Redis、MySQL 是核心基础设施
6. 第一次只启动 Gateway/Auth/System 核心服务
7. 不要一次启动所有可选模块
8. ruoyi-gateway 是统一入口
9. ruoyi-auth 是认证中心
10. ruoyi-system 是系统管理服务
11. ruoyi-api 是远程接口契约，不是运行服务
12. ruoyi-common 是公共依赖集合
13. Nacos 同时承担注册发现和配置管理
14. Redis 对登录状态非常重要
15. 登录主链一定要会画
16. 前端 Cloud 版和普通单体 Vue3 版不要下载错
17. 业务不要全部写进 ruoyi-system
18. 新业务优先新建 ruoyi-modules 服务
19. 不要为了“原创”乱改 Security 核心
20. 原版先跑通再做二次修改
21. 批量修改前必须 Git 提交和备份
22. 修改器只是助手，不是 100% 迁移保证
23. 改服务名比改 Java 包名影响更广
24. 改包名必须检查 META-INF 自动配置
25. Cloud 改名必须检查 Nacos DataId
26. Cloud 改名必须检查 Feign 与 Gateway Route
27. 修改后先 mvn build，再逐模块启动
28. 修改器和 ruoyi-gen 完全不是一回事
29. Gen 生成的是 CRUD 骨架，不是完整业务
30. 二次开发应尽量新增业务模块，降低对官方核心侵入
五百一十一、本章最终验收
学完这一章，你应该能够独立完成：
1. 区分 RuoYi / RuoYi-Vue / RuoYi-Cloud
2. 找到官方 RuoYi-Cloud 仓库
3. 切换 springboot3 分支
4. 验证 java -version
5. 验证 mvn -v
6. 看懂顶层 pom
7. 看懂 ruoyi-gateway
8. 看懂 ruoyi-auth
9. 看懂 ruoyi-system
10. 看懂 ruoyi-api
11. 看懂 ruoyi-common
12. 理解 ruoyi-gen
13. 理解 ruoyi-job
14. 理解 ruoyi-file
15. 理解 monitor
16. 初始化当前版本 MySQL SQL
17. 初始化当前版本 Nacos 配置
18. 启动 Redis
19. 启动 Nacos
20. 启动 System
21. 启动 Auth
22. 启动 Gateway
23. 在 Nacos 看见服务
24. 启动 Cloud Vue3 前端
25. 完成端到端登录
26. 画出登录调用链
27. 找到 RemoteUserService
28. 理解 Feign 如何连接 System
29. 理解 Gateway 如何鉴权
30. 理解 Redis 登录状态
31. 使用若依框架修改器前建立基线
32. 用 Git Diff 审计修改
33. 全局搜索旧包名
34. 检查 Maven 坐标
35. 检查 META-INF imports
36. 检查 ServiceNameConstants
37. 检查 Feign serviceName
38. 检查 Gateway lb://
39. 检查 Nacos DataId
40. 检查 Docker 路径
41. 检查 Shell/Batch
42. 检查前端标题/env
43. 修改后 Maven 构建
44. 修改后逐服务启动
45. 区分代码修改器和代码生成器
46. 使用 ruoyi-gen 生成 CRUD 骨架
47. 知道生成代码需要二次开发
48. 知道新业务应放独立业务服务
49. 创建最小 ruoyi-travel 思路
50. 根据 401/404/503/500 分层定位故障
五百一十二、你现在最应该做的一次实践
从空目录开始：
D:\Java\RuoYiCloudPractice
第一步：
git clone https://gitee.com/y_project/RuoYi-Cloud.git
五百一十三、第二步
cd RuoYi-Cloud
git checkout springboot3
git branch
五百一十四、第三步
java -version
mvn -v
确保：
JDK17
五百一十五、第四步
打开：
sql
只使用：
当前分支提供的 SQL
五百一十六、第五步
准备：
MySQL
Redis
Nacos3
五百一十七、第六步
逐个启动：
System
Auth
Gateway
五百一十八、第七步
Nacos Console 确认：
ruoyi-system
ruoyi-auth
ruoyi-gateway
五百一十九、第八步
再下载：
RuoYi-Cloud-Vue3
启动前端。
五百二十、第九步
完成：
登录
五百二十一、第十步
不要改任何代码，
先在 IDEA：
Ctrl + Shift + F
搜索：
RemoteUserService
五百二十二、然后跟完整登录链
这一步：
比背 100 个类名更有用
五百二十三、第十一步
创建 Git：
customize
分支。
五百二十四、第十二步
复制项目：
custom
版本。
五百二十五、第十三步
再练：
包名修改器
不要在原版：
直接练
五百二十六、实践完成标准
你必须同时做到：
原版能跑
修改版也能跑
这样你才能真正知道：
修改器影响了什么
五百二十七、下一课
按照课程表，下一篇正式进入项目：
《智途 AI 旅行微服务实战（一）：数据库设计与短信验证》
下一课会从：
“我们到底要做一个什么旅行系统？”
开始。
五百二十八、下一课会做什么
第一：
分析智途 AI 旅行平台核心业务
五百二十九、确定微服务边界
例如：
系统服务
旅行内容服务
用户业务
AI 能力
但不会：
为了微服务而过度拆分
五百三十、设计数据库
会涉及：
地区
景点
分类
用户旅行数据
验证码
并为后面：
多级菜单
网站导航
排行榜
OSS
搜索
AI 推荐
提前设计合适的数据结构。
五百三十一、短信验证码完整流程
用户输入手机号
↓
Gateway
↓
发送验证码接口
↓
校验手机号格式
↓
防刷
↓
生成验证码
↓
发送短信
↓
Redis 保存
↓
设置 TTL
↓
用户提交验证码
↓
Redis 校验
↓
一次性消费/失效
五百三十二、会重点讲安全
包括：
60 秒发送间隔
单手机号频控
单 IP 频控
验证码过期
验证码错误次数
Redis Key 设计
不能把验证码返回前端
短信 SDK 失败处理
重复提交
幂等
五百三十三、为什么这一课开始真正像企业项目
前五课：
主要学习微服务基础设施
下一课：
开始把基础设施用于真实业务
五百三十四、最终路线
RuoYi-Cloud
↓
新增智途业务模块
↓
数据库
↓
短信验证码
↓
多级菜单
↓
导航
↓
OSS
↓
排行榜
↓
缓存
↓
ES
↓
AI
↓
MQ
五百三十五、本章一句话总结
若依 Cloud 不是一个需要你重新发明的框架，
而是一套已经把微服务基础设施组装好的脚手架。
你真正需要学会的是：
先跑通，
再看懂，
再扩展，
最后才修改框架本身。
五百三十六、最值得背下来的部署口诀
先分支
再环境
先基础设施
再核心服务
先原版跑通
再修改名字
先 Git Diff
再修残留
先业务扩展
少碰框架核心