做后端管理系统开发的朋友对 RuoYi 应该都不陌生。这个框架在国内 Java 圈子里的普及度相当高绝大多数情况下你拿到手改改就能交付。但真正用到生产环境尤其是涉及多系统统一登录、第三方授权登录这些场景时RuoYi 自带的单点登录能力就比较基础了。我最近在折腾一个开源项目 ruoyi-sso-oauth2目标很明确在 RuoYi 框架上把 SSO单点登录和 OAuth2 协议完整落地做成可以二次开发的基础工程。这篇文章是系列第一篇先把环境配置整套讲清楚包括 JDK、Maven、Node.js、MySQL、Redis以及 RuoYi 基础框架的初始化启动。如果你正在用 RuoYi 做企业级项目或者想搞清楚 OAuth2 认证服务在自己的系统里该怎么落地那么这个系列应该能帮到你。环境配置这部分虽然看着基础但恰恰是后面所有事情的地基版本选不对、依赖拉不下来、Redis 连不上后面每一步都会踩坑。我在这个项目里踩过的那些版本坑、依赖坑都会在系列文章里老老实实写出来这篇先讲环境把跑通这条链路的最低配置和最佳实践给到大家。1. 项目整体思路与系列内容预览1.1 这个项目到底要解决什么问题先说一个比较典型的场景公司里同时有 OA 系统、运维平台、客户管理后台每个系统都独立维护一套账号密码用户要在三个系统里注册三次、记三套密码体验很差。管理员更痛苦离职员工要在每个系统里分别删账号漏一个就是安全隐患。RuoYi 本身有登录功能但它是单系统认证每个 RuoYi 实例都用自己的用户表和 token 机制。如果只是简单地把三个 RuoYi 部署起来它们之间完全不互通。ruoyi-sso-oauth2 这个项目要做的就是引入统一认证中心所有子系统都不再自己验证账号密码而是把登录请求交给认证中心处理。认证中心签发一个全局 token用户拿着这个 token就可以在所有接入的子系统里自由切换不需要重新登录。这就是 SSO 单点登录的核心价值。而 OAuth2 在这个场景里扮演的是什么角色呢它负责解决授权问题。简单说OAuth2 不直接登录它定义了一套标准化的授权流程让第三方应用或者说其他子系统可以在用户授权的前提下安全地拿到用户的身份信息。比如你的 RuoYi 后台想去调用另一个平台的 API但又不想把账号密码暴露给对方这时候就可以通过 OAuth2 的授权码模式让用户在认证中心确认授权然后换取一个访问令牌。令牌拿到了权限也校验了全程不碰密码安全性比直接在系统间传密码高一个量级。所以这个项目的定位就是在 RuoYi 框架之上补全统一认证和授权分发的短板让你拿到手之后既可以当作学习 OAuth2 协议落地的参考工程也可以直接在真实项目里改成自己的认证中心。1.2 系列文章的规划与技术选型方向既然标题里带了一那这个系列肯定不止一篇。按照我的实践路线整个项目会分成这么几个阶段环境配置本篇、数据库与基础工程初始化、认证中心的搭建OAuth2 授权服务器、客户端的接入资源服务器改造、SSO 单点登录流程打通、最后是安全加固和性能优化。技术选型这块我参考了几个主流方案后做了一个组合这里提前交代清楚基础框架用 RuoYi-Vue 单体版本Java 8 Spring Boot 2.7 的组合。为什么不直接上 JDK 17 和 Spring Boot 3因为 RuoYi 的老版本对 Spring Boot 3 的适配还不算特别成熟升级过程中会引入大量兼容性问题对于学习 OAuth2 这个主线目标来说没必要一开始就增加这个负担。当然等后面基础功能跑通我会再出一篇专门讲 Spring Boot 3 Spring Security 6 的迁移方案毕竟官方在 Java 17 上确实做了不少性能和安全上的优化长期来看是趋势。认证服务器方面我选择的是 Spring Authorization Server 项目。这里有一个很容易踩的坑很多人一搜 OAuth2 的 Java 实现会找到 spring-security-oauth2 这个旧项目但它在 2022 年就已经结束维护了官方把功能迁移到了 Spring Authorization Server 这个独立项目里。如果你现在直接引入旧的 spring-security-oauth2-autoconfigure 依赖在 Spring Boot 2.7 下还能用但到了 3.x 就有明显的兼容性问题。学习新项目直接上 Spring Authorization Server 是正确的选择。提示如果你准备在自己的生产项目里集成 OAuth2建议先确认你的 Spring Boot 大版本再决定引入哪种 OAuth2 依赖。旧项目能用但已停止维护新项目是官方未来的主力方向。2. 环境配置全景图与版本选型2.1 基础运行环境清单在开始动手之前先把整个项目运行需要的东西列个清单。很多人在环境配置上出问题不是因为某个软件不会装而是各个软件的版本之间互相不兼容。我用表格把推荐版本和备选版本都列出来了你可以直接照做。软件推荐版本备选版本说明JDK1.88u20117RuoYi 官方支持 JDK 8兼容性最稳Maven3.6.33.8.8高版本 Maven 需要 JDK 8注意匹配Node.js16.20.x14.21.x适配 RuoYi-Vue 前端的 Vue CLI 4MySQL5.78.0建议用 8.0需注意认证插件Redis5.x / 6.x7.x单机即可生产建议加密码IDEA2023 或更新-社区版即可满足需求Git最新版-拉取源码用这里要特别解释一下 Node.js 版本的选择。RuoYi-Vue 的前端工程是基于 Vue 2 Element UI 的Vue CLI 4 对 Node 的版本要求比较保守。Node 17 及以上版本默认启用了 OpenSSL 3.0会导致老版本 webpack 构建时报错具体的报错信息是error:0308010C:digital envelope routines::unsupported。很多人第一次跑 RuoYi 前端就卡在这里。我的建议是直接用 Node 16.20.x这个版本在兼容性和性能之间是最平衡的实测跑 RuoYi-Vue 前端没有任何问题。2.2 版本选型背后的几个坑版本这东西看着不起眼但每一个都是实际跑出来的教训。JDK 8 和 JDK 17 的选择很多人纠结。如果你只是学习这个项目JDK 8 绝对够用而且 RuoYi 的代码对整个生态的兼容性在 JDK 8 下是最完善的。但如果你本身就在规划新项目而且不打算用 RuoYi 老版本那我建议直接学习 Spring Boot 3 JDK 17 路线毕竟官方对老版本的支持周期是有终点的。我这篇文章后面讲配置的时候以 JDK 8 为主同时会在关键位置标注 JDK 17 下需要改动的地方。MySQL 这里有一个很典型的坑MySQL 8.0 默认的认证插件是caching_sha2_password而 RuoYi 的数据库驱动在旧版本上对这个插件的兼容性不好连数据库的时候会报Unable to load authentication plugin caching_sha2_password。解决办法有两个要么在创建数据库用户的时候明确指定mysql_native_password要么把 MySQL 驱动的版本升级到 8.x。我建议直接升级驱动因为改认证插件在 MySQL 8 的新版本里也渐渐不被推荐了治标不治本。Redis 版本就简单多了RuoYi 底层主要用 Redis 来做 token 缓存和验证码缓存单机模式完全够用。如果你用的是 Redis 7有一点要注意Redis 7 开始 ACL 功能更严格如果开启了默认账号的密码配置里必须同步修改。另外生产环境强烈建议至少设置密码不要裸奔在公网上。注意整个环境配置过程中最容易出问题的不是安装步骤而是环境变量和版本匹配。建议每装完一个组件都先在命令行里敲一下版本号确认别等到最后一起报错才开始排查。2.3 环境变量配置实操Windows 环境下JDK 和 Maven 的环境变量配置是很多人绕不过去的一道坎特别是刚入门的朋友。这里给出最简单的配置流程照着做就行。JDK 部分安装完成后需要新增JAVA_HOME环境变量指向 JDK 的安装目录比如C:\Program Files\Java\jdk1.8.0_201。然后在Path变量里追加%JAVA_HOME%\bin。配置完成后打开新的命令行窗口敲java -version如果能看到类似java version 1.8.0_201的输出说明成功了。Maven 的配置思路完全一样新增MAVEN_HOME指向 Maven 的安装目录然后在Path里追加%MAVEN_HOME%\bin。装完验证的方式是mvn -v。这里有一个细节Maven 本身依赖 JDK所以必须先完成 JDK 环境变量配置再配置 Maven顺序不能倒。很多人在命令行窗口里执行mvn出现无法将mvn项识别为 cmdlet、函数、脚本文件或可运行程序的名称这个报错根本原因就是 Path 环境变量没配好。如果你确认变量已经配置了但还是报这个错多半是命令行窗口没有重启环境变量的修改必须要新开一个终端窗口才能生效。一个小技巧Windows 下可以在命令行输入where mvn如果能看到 Maven 的安装路径说明环境变量没问题接着就是刷新终端的问题。3. 核心依赖安装与初始化配置3.1 Maven 镜像与仓库配置Maven 安装好之后第一件事不是急着拉代码而是先把镜像源配置好。默认的中央仓库服务器在国外国内网络环境下拉取依赖速度很慢尤其是大项目几十上百个依赖每一个都超时的话体验相当煎熬。Maven 的配置文件在安装目录下的conf/settings.xml也可以放在用户目录的.m2目录下。我建议直接用用户目录下的配置文件这样升级 Maven 的时候配置不会丢。在mirrors标签里增加一个阿里云镜像mirror idaliyunmaven/id mirrorOfcentral/mirrorOf name阿里云公共仓库/name urlhttps://maven.aliyun.com/repository/public/url /mirror这里解释一下mirrorOf的含义central表示对中央仓库生效也就是说所有通过中央仓库下载的依赖都会改走阿里云镜像。如果你的项目里还用了其他私服仓库可以根据需要调整这个配置。另外如果你有公司内部的 Maven 私服可以在profiles里配置repository和snapshotRepository这样既能用私服里的内部构件又能通过镜像加速第三方依赖。还有一个常用配置是本地仓库的位置。默认的本地仓库在~/.m2/repository如果你 C 盘空间紧张建议改到其他盘。在settings标签里调整localRepositorylocalRepositoryD:/maven/repository/localRepository这样做的直接好处是就算系统重装本地仓库的依赖不会丢能省下大量重新下载的时间。3.2 Node.js 安装与 npm 镜像配置Node.js 的安装在 Windows 下就是一路下一步这里重点说两个事第一是版本选择第二是 npm 镜像源。版本选择我在前面已经提过这里再强调一下RuoYi-Vue 前端用 Node 16 是最省心的。安装完成后命令行执行node -v和npm -v确认版本。如果你机器上已经装了其他版本的 Node建议用 nvmNode Version Manager来管理多个 Node 版本需要哪个切哪个比卸载重装高效得多。npm 默认源在国外npm install的时候下载速度经常让人抓狂。配置镜像源很简单npm config set registry https://registry.npmmirror.com配置完成后执行npm config get registry检查。如果看到https://registry.npmmirror.com说明设置成功了。这个配置是全局的没有网络风险只是一次简单的镜像切换后续跑前端工程的时候不管是安装依赖还是下载 build 产物速度都会明显提升。提示RuoYi 前端工程用到的部分依赖体积较大网络不好的时候很容易卡住。我个人的建议是配置好镜像后先执行一次npm cache clean --force清掉可能存在的脏缓存然后再npm install这样能减少很多莫名其妙的报错。3.3 MySQL 与 Redis 的初始化准备数据库和缓存是后端启动的前置条件。MySQL 这边RuoYi 的数据库脚本通常放在工程目录的sql文件夹下命名类似ry_2023xxxx.sql。用命令行或者图形化工具Navicat、DataGrip 都可以创建数据库然后导入这个脚本。这里有一个容易忽略的点数据库的字符集一定要设置为utf8mb4排序规则选用utf8mb4_general_ci即可。如果不设置后面存入中文或者特殊字符的时候可能出现乱码或者长度不足的报错。导入完成之后建议先手动执行一条查询语句比如SELECT * FROM sys_user;确认脚本是否完整导入。如果表结构正常、能看到初始化的管理员数据说明数据库这步就完成了。Redis 的初始化更像是一个确认能连上的过程。默认 Redis 在本机的 6379 端口启动没有密码。如果你在本地开发用默认配置就行。但有一点要特别注意如果你的 Redis 设置了密码必须在 RuoYi 的配置文件里同步修改否则后端启动的时候会报Unable to connect to Redis的错误。另外RuoYi 默认会使用 Redis 的 db 0如果你在同一个 Redis 实例上跑了多个项目建议给这个项目单独分配一个 database比如 db 10在配置文件里调整即可。4. RuoYi 基础框架的下载与启动验证4.1 获取 RuoYi 后端源码并导入 IDEARuoYi 官方提供了多个版本的源码常见的有单体版 RuoYi、前后端分离版 RuoYi-Vue、微服务版 RuoYi-Cloud。我们这个项目基于 RuoYi-Vue 来做因为 SSO 和 OAuth2 的改造在前后端分离的架构下更清晰也更贴近大多数企业级应用的现状。源码直接通过 Git 拉取到本地git clone https://gitee.com/y_project/RuoYi-Vue.git国内网络环境下Gitee 的速度通常比 GitHub 快很多。拉取完成之后用 IDEA 打开工程。这里要提醒一句IDEA 打开 Maven 工程之后会自动开始下载依赖第一次打开的时候下载量大耗时长属于正常现象。如果等待时间过长检查一下 Maven 配置是不是已经指向了阿里云镜像以及 IDEA 的 Maven 设置是否正确Settings - Maven - Maven home path 和 User settings file 都要指向你配置好的路径。实际工作中我遇到过不少朋友IDEA 里 Maven 用的是自带的配置导致之前设置的镜像完全没生效。这里建议在 IDEA 的 Maven 设置页面手动把 User settings file 选到你自定义的settings.xml路径并在后面的 Override 复选框上打勾这样 IDEA 就会使用你配置的镜像和本地仓库了。4.2 后端启动前需要修改的三处配置RuoYi 的后端工程结构里核心配置文件是ruoyi-admin/src/main/resources/下的application.yml但它一般不做主改真正的数据源和缓存配置通常是分开的。这里最容易踩的坑就是改错文件。主要需要动的地方有三处第一处是数据源配置一般在application-druid.yml里。需要修改url、username、password三个字段spring: datasource: druid: url: jdbc:mysql://localhost:3306/ry-vue?useUnicodetruecharacterEncodingutf8mb4zeroDateTimeBehaviorconvertToNulluseSSLfalseserverTimezoneGMT%2B8 username: root password: 你的密码第二处是 Redis 配置在application-redis.yml里核心是 host、port、password 和 databasespring: redis: host: localhost port: 6379 password: 你的密码 database: 0如果你本地 Redis 没设密码password 这一行留空或者注释掉就行。第三处是application.yml里关于应用启动端口和上下文路径的配置RuoYi 默认端口是 8080一般不需要改但如果你的机器 8080 被占了改成你自己习惯的端口也行。注意改完配置文件之后一定要留意 IDEA 的 Maven 面板是不是已经正确识别了工程。如果右侧 Maven 面板里显示项目名是灰色的或者有红色波浪线说明依赖还没完全解析这时候直接启动后端大概率会报package com.ruoyi.common.utils.StringUtils does not exist之类的错误。解决方法是先执行一次mvn clean install -DskipTests把公共模块先安装到本地仓库。4.3 前端工程初始化与启动RuoYi-Vue 的前端工程在源码的ruoyi-ui目录下。用 IDEA 或者 VS Code 打开这个目录然后在终端里执行依赖安装npm install这个命令跑完后如果遇到了版本依赖冲突比如提示ERESOLVE unable to resolve dependency tree大概率是 Node 版本的问题。前面建议的 Node 16 就是为了避免这个问题的。如果你确实只能在高版本 Node 下运行可以退而求其次用npm install --legacy-peer-deps这个命令会让 npm 忽略 peerDependencies 的冲突检查但我不建议把它当作常规手段因为它可能掩盖真实的问题。启动前端npm run devRuoYi-Vue 的前端默认端口是 80启动成功后浏览器直接访问http://localhost就能看到登录页面。如果 80 端口被占用改前端工程根目录下的vue.config.js找到devServer里的port配置改成你需要的端口即可。4.4 后端和联调环境的启动顺序全栈项目的启动顺序有讲究。正确的顺序是先启动 Redis再启动 MySQL然后启动后端最后启动前端。后端启动之后日志里如果出现类似Started RuoYiApplication in xx seconds的输出说明后端已经跑起来了。之后用浏览器打开前端登录页如果验证码能正常显示输入默认的管理员账号admin、密码admin123能成功登录进去说明整条链路是通的。这里说一个我实际遇到过的问题前端页面能打开但验证码一直显示不出来刷新也没用。这个问题的常见原因有两个一个是 Redis 没启动或者连不上因为验证码是存在 Redis 里的另一个是前端访问后端接口时跨域被拦截了。RuoYi-Vue 的前端工程里配置了开发环境的代理vue.config.js里有一个 proxy 配置如果你把后端端口改了这里的代理目标也要同步改。改了之后必须重启前端代理配置才会生效。5. SSO 与 OAuth2 模块引入前的前置检查5.1 梳理 RuoYi 既有的登录与鉴权机制在动手改造之前先花一点时间把 RuoYi 的登录链路摸清楚这一步做得越细致后面改造就越轻松。RuoYi 的完整登录流程大概是这样的前端把用户名、密码和验证码发给后端后端先校验验证码再调用SysLoginService.login方法去查数据库验证账号密码。验证通过后TokenService会生成一个唯一的 token把这个 token 作为 key用户信息作为 value 存到 Redis 里并设置一个过期时间。前端拿到 token 之后后续每个请求都会在请求头里带上Authorization: Bearer token。后端通过过滤器拦截所有需要登录的接口从 Redis 里根据 token 取出用户信息有则放行没有则返回 401。理解了这套机制就能明白为什么 RuoYi 要依赖 Redis不是简单地做缓存而是 token 本身就是存在 Redis 里的Redis 一旦挂了所有需要登录的接口都会失效。这套设计其实已经具备了 SSO 的一部分雏形因为 token 是全局的但它缺少的是统一认证入口和跨系统令牌校验这两块。OAuth2 的引入本质上是把验证用户名密码这个动作从各个业务系统里剥离出来集中到一个认证服务里处理。5.2 代码结构该如何为后续扩展做准备这是我认为整个系列里最有价值的一节。RuoYi 原来的工程结构是按模块划分的ruoyi-common公共模块、ruoyi-framework框架配置、ruoyi-system系统管理、ruoyi-admin启动入口。在做 SSO 和 OAuth2 改造之前我建议你先在工程里增加一个独立的模块比如ruoyi-auth专门负责认证相关逻辑。为什么要这么做因为如果直接改 RuoYi 原有的登录逻辑代码耦合度会越来越高后面想升级 RuoYi 版本的时候你会发现自己改过的地方全部要重新适配。独立模块的好处是原有的 LoginService 可以不动新写的 OAuth2 认证逻辑全部放在新模块里。两个逻辑短期内可以共存等 SSO 完全接入后再一步步把旧登录逻辑替换掉整个迁移过程平滑可控。依赖关系上ruoyi-auth模块只依赖ruoyi-common和ruoyi-system不依赖ruoyi-admin。后续如果要拆成微服务这个模块可以很方便地直接变成一个独立的认证服务逻辑不需要做大的调整。如果你本来就有微服务改造的规划这一步的前置准备尤其重要。5.3 权限模型与安全配置的预留OAuth2 的令牌分为授权码、刷新令牌、访问令牌等几种每一种都有自己的生命周期。在环境配置阶段我们不急着写代码但要在数据库设计上做预留。RuoYi 的库表里有几个表是后面一定要用到的sys_user用户表、sys_role角色表、sys_menu菜单权限表。OAuth2 认证中心一般需要额外维护一张客户端表记录哪些子系统接入了认证中心每个子系统的 client_id、client_secret、回调地址、授权类型等。在环境配置阶段建议先不新建表但可以在工程里预留一个目录或者包结构比如在ruoyi-system的 domain 目录下把 OAuth2 客户端的实体类预留出来。这样后面写数据库脚本的时候结构是不是合理哪些字段是不是够用都能提前想清楚。另外RuoYi 里的安全配置集中在ruoyi-framework模块的SecurityConfig中它定义了哪些接口可以匿名访问、哪些需要登录。后面引入 OAuth2 之后认证相关的接口必须在这个配置里放行比如/oauth2/authorize、/oauth2/token这些端点否则会被拦截器挡在门外。我建议在还没改之前先在本地启动一次工程用 Postman 调一下 RuoYi 自带的验证码接口和登录接口确认这个过滤链路是通的然后再动手改造。6. 常见环境问题与排查技巧实录6.1 Maven 依赖相关问题的处理Maven 最常见的问题就是依赖下载失败或者启动时报Cannot resolve symbol。这类问题大部分是镜像源和本地仓库的问题。如果某个依赖一直下载不下来可以先试试直接手动删除本地仓库里的对应目录然后回到 IDEA 里刷新 Maven 工程重新拉取。如果还是不行检查一下是不是镜像源没有覆盖到该依赖所在的仓库。阿里云有一个 public 仓库聚合了中央仓库、Spring 仓库等主流源理论上覆盖了 99% 的场景。另外有一个细节IDEA 的 Maven 面板里有一个Reload All Projects按钮修改了 pom.xml 之后一定要点这个按钮重新加载工程光靠自动加载有时候会漏掉一些配置变更。加载完成之后如果还报错执行一次mvn clean compile看看具体是哪个依赖有问题报错信息里通常会把原因写得比较清楚。6.2 数据库连接的典型报错数据库相关的问题我整理了一张排查表都是实际操作中比较常见的报错信息可能原因解决办法Access denied for user rootlocalhost用户名或密码错误检查application-druid.yml里的账号密码Unable to load authentication plugin caching_sha2_passwordMySQL 8 认证插件兼容问题升级 MySQL 驱动到 8.x或改用户认证插件Table ry-vue.sys_user doesnt exist数据库脚本未导入执行sql目录下的初始化脚本Unknown database ry-vue数据库不存在先创建数据库注意大小写和字符集Communications link failureMySQL 服务未启动或端口不对确认 MySQL 已启动检查端口和连接串这里特别要提一下 MySQL 8 的驱动版本问题。RuoYi 老版本默认带的 MySQL 驱动是 5.1.47如果你本地装的是 MySQL 8.0建议把驱动版本升级到 8.0.x比如dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId version8.0.28/version /dependency升级驱动之后连接串里的useSSLfalse最好显式保留避免出现 SSL 握手的告警日志。6.3 前端启动与构建问题的排查前端的问题往往比后端更难排查因为报错信息有时候指向不明确。最常见的两个问题我都遇到了一个是 Node 版本不兼容导致的 webpack 构建失败另一个是端口被占用导致启动失败。webpack 构建失败报错信息里如果有digital envelope routines::unsupported几乎可以确定是 Node 版本过高。解决办法前面说过了换用 Node 16。如果你不愿意换版本可以在启动脚本里加一句NODE_OPTIONS--openssl-legacy-provider让 OpenSSL 以兼容模式运行但这样只是绕过了问题不推荐长期使用。端口占用的问题Windows 下可以通过命令行查找占用进程netstat -ano | findstr :80找到占用 80 端口的进程 PID 之后在任务管理器里结束对应进程或者直接修改前端工程的vue.config.js里的port配置改成 8081 之类的端口。这里提醒一下改完端口之后代理配置里的 target 地址如果写的是后端接口地址那边不受影响但如果你用 Nginx 做了转发那边也要同步改。6.4 Redis 连接问题的排查节奏Redis 连接问题在环境配置阶段出现的频率也很高集中表现在后端启动时日志里出现Unable to connect to Redis或者RedisConnectionFailureException。排查顺序我建议是先看 Redis 服务有没有启动。Windows 下如果用的是压缩包方式运行 Redis需要手动打开一个命令行窗口运行redis-server.exe关掉窗口 Redis 就停了。然后看端口是不是默认的 6379如果改了端口配置文件里也要对应改。最后看密码Redis 配置文件redis.conf里如果设置了requirepass那application-redis.yml里的password必须填一致。这里有一个我踩过的坑我在本机跑过多个 Redis 服务一个带密码一个不带密码每次切换项目都要改配置。后来我养成了一个习惯本地开发环境的 Redis 统一用同一个密码所有项目的配置都复用同一个虽然看起来不优雅但确实省了很多维护成本。环境配置阶段怎么方便怎么来生产环境再谈严格隔离的事。最后再分享一点个人体会环境配置这件事说实话没有什么高深的技术含量但它最考验人的耐心和对细节的把控。我在这个项目的开始阶段几乎把上面提到的每个报错都经历了一遍最让人崩溃的不是报错本身而是明明照着文档一步步做结果还是不行。后来我才慢慢意识到这些文档里没写的版本对应关系才是环境配置真正的核心。所以我把自己的踩坑过程整理成这篇内容希望能帮你少走一些弯路。最后给大家一个实用的小建议每配置完一个环境变量或者依赖立刻去验证对应的命令行命令是否生效。例如配完 JDK 验证java -version配完 Maven 验证mvn -v配完 Node 验证node -v和npm -v配完 Redis 再验证redis-cli ping返回PONG。把这些都摆平了再启动项目基本是一气呵成的事。下一步我会接着写数据库表的初始化和 OAuth2 认证中心的搭建有需要的朋友可以继续关注这个系列。