1. 项目概述与部署前要搞明白的事1.1 若依微服务版到底长什么样先说结论若依微服务版不是“把单机版拆成几个模块塞进Spring Cloud”这么简单。我从第一次接触RuoYi-Cloud到现在前后部署过开发环境、测试环境、生产环境最大的感受是——这套系统的部署难度并不在于代码本身而在于你对微服务各组件的协作关系有没有清晰认知。若依微服务版的外观表现是这样的它是一个基于 Spring Cloud Alibaba 的微服务框架基础技术栈包括 Spring Boot、Spring Cloud、Spring Cloud Alibaba、Nacos、Gateway、Sentinel、Redis、MySQL如果接入了分布式事务还会有 Seata。整个系统默认拆成了多个独立服务比如 ruoyi-gateway网关、ruoyi-auth认证中心、ruoyi-system系统模块、ruoyi-file文件服务、ruoyi-job定时任务、ruoyi-gen代码生成等同时还有一个 ruoyi-ui 前端工程。部署若依微服务版本质上是做三件事第一把基础设施跑起来Nacos、MySQL、Redis第二把后端服务全部注册到 Nacos 并启动第三把前端构建产物部署到 Nginx 或直接用 Node 启动并通过网关转发。听起来不复杂但每一步都有很多实操细节比如application.yml中 Nacos 地址配置错了、bootstrap.yml没有正确加载、服务之间调用超时、网关白名单放行配置不对……这些问题我在踩坑过程中都遇到过后面会展开细说。1.2 部署前需要梳理的部署架构先别急着敲命令我强烈建议在动手前先把部署架构图画一遍。你不需要画得多专业但必须明确下面几个问题所有服务是否部署在同一台机器上还是网关/服务/前端分开部署这决定了你应该用内网地址还是公网地址。使用的中间件版本是什么若依官方对 Nacos、Sentinel 等版本有默认约定但如果你用了 Docker 镜像版本不一致会踩很多隐性坑。是否使用了 Sentinel 控制台是否用到了 Seata这些组件是可选的但默认配置里可能引用了它们如果不需要必须去除相关依赖或关闭配置。服务发现是走 Nacos还是需要额外做负载均衡若依已经内置了 LoadBalancer所以你只需保证每个服务能被 Nacos 正确发现即可。数据库初始化怎么做若依提供了sql目录下的脚本文件但微服务版不是所有模块共用同一个库需要注意ry-cloud主库和ry-config配置库之间的区别。我见过一个很常见的部署失误直接修改每个服务的application.yml里的数据源地址但其实微服务版用的是Nacos作为配置中心默认配置都存放在 Nacos 的配置列表里通过spring.cloud.nacos.config拉取。如果你只改了本地文件服务启动时依然会去 Nacos 里找对应的ruoyi-*.yml结果数据源还是旧的。这就是为什么部署若依微服务版必须先把“配置中心”这个概念吃透。2. 基础环境准备中间件选型与搭建2.1 中间件清单与版本选型如果说部署若依微服务版是一场演出中间件就是幕后团队。下面是我自己用下来比较稳的一套组合也标注了替代方案中间件版本建议作用备注JDK1.864位运行后端服务如果后续想用 Spring Boot 3.x可考虑 JDK17但若依官方默认是 JDK8Maven3.6项目编译打包建议使用阿里云镜像MySQL5.7 / 8.0持久化数据若依默认字符集 utf8mb4Redis5.x / 6.x / 7.x缓存、验证码存储、登录 token 存储6.x 和 7.x 实测都兼容Nacos2.x推荐 2.2.3注册中心 配置中心1.x 也能用但不推荐生产Sentinel Dashboard1.8.6流量治理控制台可选不启动不会影响系统启动Nginx1.20前端静态资源托管、反向代理推荐用 Nginx而不是直接用 Node 跑前端Docker可选最新稳定版快速部署中间件不建议把后端服务也全部容器化调试麻烦版本选型这块有一个我要单独拎出来提醒的点Nacos 的版本必须和 Spring Cloud Alibaba 版本搭配好。若依官方在pom.xml里已经管理了版本你不必自行修改。但如果你是参照某些旧教程把 Spring Cloud Alibaba 版本降低或者升高Nacos 的客户端兼容性会立刻出问题。典型的现象就是服务注册成功但控制台看不到或者服务列表时有时无。2.2 Nacos、MySQL、Redis 的搭建与初始化2.2.1 使用 Docker 快速启动中间件如果你是在自己的电脑上做本地部署验证Docker 是最省事的。但要注意Docker 容器里的服务访问宿主机服务时localhost是不能用的必须用host.docker.internal或宿主机在局域网内的 IP。先给出一个我常用的启动命令组。以 Docker 方式启动 MySQL、Redis、Nacos# MySQL docker run -d \ --name ruoyi-mysql \ -p 3306:3306 \ -e MYSQL_ROOT_PASSWORDroot123456 \ -e MYSQL_DATABASEry-cloud \ -v /opt/mysql-data:/var/lib/mysql \ mysql:5.7 \ --character-set-serverutf8mb4 \ --collation-serverutf8mb4_general_ci # Redis docker run -d \ --name ruoyi-redis \ -p 6379:6379 \ redis:6.2 \ --requirepass 123456 # Nacos内置Derby单机模式演示 docker run -d \ --name ruoyi-nacos \ -p 8848:8848 \ -p 9848:9848 \ -e MODEstandalone \ -e SPRING_DATASOURCE_PLATFORMmysql \ -e MYSQL_SERVICE_HOST宿主机IP \ -e MYSQL_SERVICE_PORT3306 \ -e MYSQL_SERVICE_DB_NAMEnacos_config \ -e MYSQL_SERVICE_USERroot \ -e MYSQL_SERVICE_PASSWORDroot123456 \ nacos/nacos-server:v2.2.3这里要注意Nacos 从 2.x 开始增加了 gRPC 端口9848如果你在云服务器上部署防火墙和安全组必须同时放通8848和9848否则服务注册会一直超时。2.2.2 初始化数据库若依微服务版的 SQL 脚本在下载源码后位于sql目录下。实际初始化时你需要创建以下数据库ry-cloud主业务库导入ry_2021xxxx.sqlry-configNacos 配置库导入nacos_config.sql如果用到定时任务可能会在ry-cloud中生成sys_job相关表不用单独建库。导入命令很简单mysql -uroot -proot123456 /path/to/ry_2021xxxx.sql mysql -uroot -proot123456 /path/to/nacos_config.sql注意如果你选用了 MySQL 8.0在导入过程中可能会遇到Unknown collation: utf8mb4_0900_ai_ci之类的提示。这是因为 Nacos 源码里的 SQL 可能兼容 MySQL 5.7解决办法是把 SQL 文件里的utf8mb4_0900_ai_ci全部替换成utf8mb4_general_ci或者在 MySQL 8.0 下忽略这个 warning通常不影响使用。2.2.3 Nacos 中导入若依的配置这步是若依微服务版部署里最容易忽略、影响又最大的环节。Nacos 不只是一个注册中心它还承担了配置中心的职责。若依的每个微服务模块在启动时都会去 Nacos 获取自己的ruoyi-xxx.yml配置文件这些配置文件的默认内容都在nacos_config.sql里。在 Nacos 控制台操作时通常不需要手动逐个创建配置因为 SQL 脚本已经导入了。但你要做两件事检查配置列表里是否存在ruoyi-gateway.yml、ruoyi-auth.yml、ruoyi-system.yml等基础配置。如果发现部分配置缺失可以手动复制一份并修改 Data ID。修改 Nacos 中ruoyi-*.yml里的数据源连接信息。比如ruoyi-system.yml中有 MySQL 连接串ruoyi-auth.yml中有 Redis 连接串。官方默认配置是localhost你看看自己的实际环境改成对应的 IP 和密码。修改保存后不需要重启 Nacos但需要重启对应的微服务才能真正生效。这是配置中心一个很重要的特点服务启动时拉取配置运行中配置变更虽然支持自动刷新RefreshScope但数据源这类核心配置通常还是需要重启。3. 后端服务部署实操3.1 配置文件里的门道若依微服务版绝不是一个服务一个application.yml就能跑起来的。每个服务都有bootstrap.yml和application.yml其中bootstrap.yml负责从 Nacos 拉取远程配置。这是整套系统最核心、也最容易迷失的地方。我建议你拿到源码后首先看一下ruoyi-gateway/src/main/resources/bootstrap.yml内容大致如下spring: application: name: ruoyi-gateway cloud: nacos: config: server-addr: 127.0.0.1:8848 namespace: file-extension: yml也就是说服务启动时会去127.0.0.1:8848找到名为ruoyi-gateway.yml的配置。如果你的 Nacos 部署在别的机器上这个server-addr必须改成对应地址。而且要注意若依源码里 Nacos 配置中心的地址和注册中心的地址是分开的bootstrap.yml里可能只写了config而application.yml里写了discovery。两处都需要同步修改。实际部署时我不建议你去改源码里的默认配置而是用 Maven 打包时通过 Profile 指定环境配置。若依官方提供了一个--spring.profiles.activedruid之类的用法但实际上更清晰的做法是在 Nacos 上为不同环境准备不同的配置比如ruoyi-system-prod.yml然后在服务的application.yml中设置spring: profiles: active: prod这个思路比较符合生产环境多套部署的实际场景。平时开发用dev生产用prod各环境配置隔离互不干扰。3.2 从打包到启动的完整流程3.2.1 打包后端先说手动打包方式。在项目根目录下执行mvn clean package -DskipTests这一步会把ruoyi-gateway、ruoyi-auth、ruoyi-system、ruoyi-file、ruoyi-job等所有可执行模块打成可运行的 jar 包。重点来了微服务版一定不要用mvn package把所有模块都打到一个大包里。它是多模块工程每个模块是独立服务所以分别进入对应的模块目录或者用 IDE 的 Maven 面板逐个打包。打包完成后的 jar 包路径一般在ruoyi-modules/ruoyi-system/target/ruoyi-system.jar。实际的 jar 包名字与pom.xml的artifactId和finalName有关。我习惯在打包前先整体编译一下mvn clean install -DskipTests这样可以把公共模块如ruoyi-common安装到本地 Maven 仓库避免下游模块引用不到。3.2.2 启动顺序微服务版启动顺序虽然没有绝对要求但实践下来最好按下面顺序Nacos、MySQL、Redis 先启动确认可用。如果使用 Sentinel 控制台启动 Sentinel Dashboard。启动ruoyi-gateway网关因为网关是所有请求的入口。启动ruoyi-auth认证中心处理登录鉴权。启动ruoyi-system系统模块提供用户、角色、菜单等基础数据接口。启动其他业务模块如ruoyi-job、ruoyi-file、ruoyi-gen等。如果你不按顺序启动其实系统一般也不会直接挂掉因为网关、认证、系统模块之间是通过 Feign 调用只要最终都能注册到 Nacos 并保持可用即可。但按顺序启动的优势是日志更清晰哪个服务依赖没满足能快速定位。比如先启动ruoyi-system它会去连数据库如果数据库没起来会报数据源连接失败服务启动失败然后退出。而如果先启动 Gateway即使后端服务还没全部就绪网关也可以先完成端口监听和路由注册这时候请求进来会返回 503等后端服务起来后自然恢复。3.2.3 启动命令与 JVM 参数启动单个服务最常见的方式是java -jar ruoyi-gateway.jar但在实际部署时我会加上 JVM 参数和日志配置java -Xms512m -Xmx512m -Xmn256m \ -Dfile.encodingUTF-8 \ -Dspring.cloud.nacos.server-addr192.168.1.100:8848 \ -jar ruoyi-gateway.jar \ --spring.profiles.activeprod这里通过-D参数覆盖 Nacos 地址可以避免修改源码里的bootstrap.yml。不过你要确认bootstrap.yml里配置中心的server-addr也支持这种动态覆盖否则可能不生效。最保险的办法还是直接修改配置文件。启动后观察日志如果出现类似Nacos registry, ruoyi-gateway 192.168.1.100:8848 register finished说明服务已经成功注册到 Nacos。接下来在 Nacos 控制台的“服务管理 → 服务列表”里应该能看到ruoyi-gateway、ruoyi-auth、ruoyi-system等几个服务状态为“健康实例数 1”。如果服务列表空空白只看到nacos自己就要回去检查 IP、端口、防火墙。3.3 网关、认证、系统服务的启动顺序3.3.1 网关整个系统的交通枢纽ruoyi-gateway基于 Spring Cloud Gateway它不像传统的 Spring MVC 那样提供 Controller而是通过路由配置将请求转发到对应的微服务。若依默认的路由规则是/auth/**转发到ruoyi-auth/system/**转发到ruoyi-system/file/**转发到ruoyi-file等。这些路由配置同样可以从 Nacos 配置中心拉取也可以在application.yml里写死。网关层的核心配置文件是ruoyi-gateway.yml里面除了路由还有白名单配置。如果你遇到“登录接口能访问但业务接口提示认证无效”问题多半出在网关白名单或者鉴权过滤器上。有一点想特别说明若依微服务版的网关默认开启了ValidateCodeFilter也就是验证码过滤器。如果你在部署测试时不想每次登录都输验证码可以在ruoyi-gateway.yml里把captchaEnabled改成false。这个配置属于业务开关不是安全问题正式环境建议保留验证码。3.3.2 认证中心单点登录的起点ruoyi-auth服务专门负责登录认证它调用ruoyi-system的用户信息服务来校验用户名密码校验通过后生成 token并把用户信息存到 Redis。token 本身是 JWT 格式网关再通过Authorization请求头解析 token把用户信息传给下游服务。启动ruoyi-auth之前务必确认 Redis 连接正常。因为用户登录的 token 会写入 Redis过期时间默认是 30 分钟可在配置中调整。如果 Redis 连不上登录接口会直接报错而且比较隐蔽的是有时候报的是“系统异常”而不是“Redis 连接失败”初次部署很容易被误导。3.3.3 系统服务数据与业务的基础支撑ruoyi-system是业务系统的核心服务它提供了用户管理、角色管理、菜单管理、部门管理等接口。这个服务启动时对数据库依赖很强数据库连接池配置和数据源 URL 一定要先确认无误。在启动ruoyi-system时我见过最多的报错是com.mysql.cj.jdbc.exceptions.CommunicationsException: Communications link failure这个报错十有八九是因为 Nacos 配置中心里的ruoyi-system.yml数据源还是localhost而你的 MySQL 并不在本地。解决办法就是登录 Nacos 控制台修改ruoyi-system.yml中spring.datasource.url为实际的数据库 IP再重启服务。4. 前端部署与单点登录改造思路4.1 前端构建与代理配置若依的前端是两个典型工程ruoyi-ui是 Vue 2 Element UI 版本ruoyi-ui-plus或若依微服务 plus 版本可能是 Vue 3。以 Vue 2 为例部署前需要安装依赖、构建cd ruoyi-ui npm install --registryhttps://registry.npmmirror.com npm run build:prod构建产物在dist目录下。如果你只是本地访问可以直接用 Nginx 托管server { listen 80; server_name localhost; location / { root /usr/share/nginx/html/ruoyi-ui; index index.html index.htm; try_files $uri $uri/ /index.html; } location /prod-api/ { proxy_pass http://127.0.0.1:8080/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }注意location /prod-api/里的/prod-api/是若依前端默认的请求前缀后端网关默认也有对应的上下文路径。如果你改了前端.env.production里的VUE_APP_BASE_APINginx 的反向代理也需要跟着改。这里容易踩的坑是前端构建后直接双击index.html打开会发现页面是空白的因为前端路由走的是history模式必须由 Nginx 的try_files配合才能正常刷新和访问。4.2 多系统单点登录的常见做法部署好若依本身是一回事但很多团队真正想做的是把多个独立的若依系统集中认证实现“一次登录处处访问”的效果。这也是我近期被问得最多的问题。若依微服务版本身已经具备一定的单点登录雏形认证中心ruoyi-auth是独立的token 放在 Redis 里多个业务模块共用同一个认证中心。但如果你手上是多个独立部署的若依系统比如一个是若依单体版、一个是若依微服务版、一个是自研系统想统一登录一般有两条改造路径基于独立认证中心改造抽出统一的登录页前端跳转到认证中心认证中心通过重定向携带 token 回调业务系统。业务系统再通过 token 解析用户信息。若依的ruoyi-auth可以承担这个角色但需要在 Redis 中共享同一个 token 存储同时要保证各系统对 token 的解析规则JWT 密钥一致。基于网关统一鉴权把多个系统收敛到同一个网关后面网关上统一做 token 校验。这样不论你的系统是若依、自研还是第三方请求统一先经过网关。网关校验通过后再把用户信息透传给下游。若依的ruoyi-gateway本身就是一个很好的突破口。我强调一下真正在项目里落地时单点登录改造的难点往往不是技术而是“多个系统之间的用户体系如何打通”。比如两个若依系统的用户表和密码加密方式一致吗如果不一致认证中心要不要做数据同步这些问题在部署阶段就要想好否则后期会陷入扯皮。5. 常见问题与排查记录5.1 Nacos 注册不上服务列表一直空这应该是若依微服务版部署最高频的问题了。现象是服务启动没报错日志里也没有异常但打开 Nacos 控制台服务列表空空如也。排查步骤我从经验角度整理一下先看 Nacos 是否正常运行。用浏览器访问http://NacosIP:8848/nacos能打开控制台页面说明基本 OK。看服务日志里的注册地址是哪个 IP。有的服务器有多块网卡Nacos 客户端可能拿到错误的网卡 IP导致服务注册到错误地址。这时可以在启动参数里强制指定java -jar ruoyi-system.jar --spring.cloud.nacos.discovery.ip192.168.1.10检查bootstrap.yml或application.yml里的 namespace。若依默认是空public如果你在 Nacos 控制台创建了命名空间两处的 namespace 必须一致否则服务会注册到不同的命名空间下互相看不到。检查防火墙端口。Nacos 2.x 需要8848和9848都放通我之前就遇到过只开通 8848服务列表时有时无最后发现是 gRPC 端口没通。5.2 网关鉴权失败总是提示“认证失败无法访问系统资源”若依网关内置了AuthFilter它会对请求头中的Authorization进行解析。出现这个提示先判断是你没带 token还是 token 无效。如果是登录后访问业务接口失败先看前端请求地址是否正确代理到了网关。如果确认代理没问题看 token 是否过期Redis 里是否有对应的登录信息。如果 Redis 里有 token但还是鉴权失败很可能是因为网关和认证中心的 JWT 密钥不一致。检查ruoyi-gateway.yml和ruoyi-auth.yml里的token.secret是否相同。还有一种可能是网关的鉴权过滤器白名单没有放行某些接口。比如你想匿名访问/system/user/list但若依默认该接口需要鉴权你需要在网关访问控制列表中加上放行规则。5.3 Docker 部署注意事项如果你采用 Docker 方式部署后端服务有个问题需要特别留意容器内的localhost和宿主机不一样。服务要连接宿主机上的 MySQL、Redis、Nacos不能写localhost要写宿主机 IP 或使用host.docker.internalLinux 下可能需要额外配置。另外Nacos 注册服务时默认会用容器 IP如果同一个容器网络下服务间调用没问题但从外部通过 Docker 端口映射访问时服务可能无法正确响应。我建议给容器指定--networkhost直接用宿主机网络运行后端服务这样注册到 Nacos 的 IP 就是宿主机 IP省去一堆网络折腾。再来说说 Docker 编排。很多教程喜欢用docker-compose up -d一键拉起所有服务但我个人不建议图省事。中间件用 Docker 可以核心业务服务还是用虚拟机或者物理机直接跑 jar 包比较好日志排查、配置修改、性能监控都方便得多。真要把服务容器化也建议一个服务一个容器别把所有服务塞到一个容器里。5.4 验证码不显示 / 登录后菜单加载不出来验证码不显示多半是 Redis 的问题。若依的验证码先由后端生成存到 Redis然后返回一个uuid给前端前端再去请求图片验证码编码后的 Base64。如果 Redis 连接失败验证码接口会直接报错前端自然显示不出来。登录后菜单加载不出来要分两层排查第一前端菜单是通过接口/getRouters从后端获取的如果这个接口返回异常看是不是ruoyi-system服务的问题第二如果接口正常但菜单还是空白打开浏览器控制台看有没有 JS 报错很可能是菜单权限标识和按钮权限标识对不上导致的。5.5 服务之间 Feign 调用报错若依微服务版中ruoyi-auth会调用ruoyi-system的 Feign 接口。这类报错常见的是feign.FeignException: [404 ] during [GET] ...大概率是FeignClient指定的服务名没有正确注册到 Nacos。比如你ruoyi-system的spring.application.name被改成了别的但ruoyi-auth里的 Feign 客户端注解还写着ruoyi-system自然找不到服务。解决办法就是保持服务名一致不要随意修改应用名。另一个隐藏坑是服务间使用了RequestHeader传递用户信息如果你在网关层对请求头做了清洗可能会导致下游服务拿不到用户信息。若依默认会向下游传递X-Forwarded-*、Authorization等头如果自定义了网关过滤器要小心不要把这些头删掉。6. 部署过程中值得坚持的实践习惯6.1 用好日志不要盯着控制台发呆微服务全家桶部署最忌“启动一个服务控制台刷一堆日志就以为它起成功了”。我的习惯是每个服务启动时重点看日志中是否有Started RuoYiXXXApplication in xxx seconds这行代表 Spring Boot 启动流程走完了。另外还要看 Nacos 注册日志是否出现register finished。两者都有才算真正 ready。日志文件路径如果没有特殊配置默认会输出到控制台。建议部署时加上日志文件输出参数java -jar ruoyi-system.jar --logging.file.path/var/log/ruoyi这样后面排查线上问题直接tail -f /var/log/ruoyi/system.log就行比翻屏方便得多。若依默认使用 Logback你也可以直接改logback.xml里的日志级别。调试期建议把关键包的日志级别调成DEBUG比如logging: level: com.ruoyi: debug org.springframework.cloud.gateway: debug6.2 环境配置统一管理避免“换环境就炸”如果你要部署多套环境开发、测试、生产强烈建议从一开始就利用 Nacos 配置中心的 namespace 区分环境。比如创建三个命名空间dev、test、prod。每个命名空间下维护自己的一套ruoyi-*.yml。服务打包时不需要改任何配置文件只需要在启动参数里指定--spring.cloud.nacos.config.namespaceprod只需要注意namespace不是别人看着舒服的名字而是 Nacos 控制台里的唯一 ID是一串类似d8b5d0f3-9d3b-4e2a-8f7c-1c0b9e1d0000的字符串。我先开始也踩过这个坑把“prod”这个名字直接填进去导致配置一直拉不下来。6.3 如果要做高可用先掌握网关和注册中心的集群模式若依微服务版的单机部署只能用于学习和功能验证。如果你想在生产环境顶住真实流量至少要保证 Nacos 和网关是高可用的。Nacos 高可用一般部署三个节点采用cluster模式节点间通过raft协议选主MySQL 做主从Redis 也做哨兵或 Cluster。网关层则可以起多个ruoyi-gateway实例前端 Nginx 通过upstream配置负载均衡upstream ruoyi-gateway { server 192.168.1.11:8080; server 192.168.1.12:8080; } server { listen 80; location /prod-api/ { proxy_pass http://ruoyi-gateway/; } }但做高可用之前你要先回答一个问题业务模块的会话保持怎么办若依的 token 是存在 Redis 中的所以网关多实例是没有会话问题的。但如果你把登录信息存在本地内存多实例就会有登录态丢失的问题。这一点若依的设计本身就很适合横向扩展。7. 写在最后的几句经验到现在为止我已经把若依微服务版从环境准备到后端部署、前端部署、常见问题排查的完整流程走了一遍。其实部署这套系统的难度并不在于哪一步操作特别高深而在于流程长、组件多任何一个环节配置不一致都会导致整个链路不通。我个人在实际操作中最深的体会是不要跳过“了解架构”这一步直接开干。如果你连网关、认证中心、Nacos 各自的职责都没搞清楚遇到报错会非常迷茫。反过来哪怕部署过程中踩了坑只要你知道每个服务在系统里的角色排查起来就会快很多。另外再分享一个小技巧如果你只想起一个后端服务来测接口建议直接启动ruoyi-auth和ruoyi-system两个服务不需要把ruoyi-file、ruoyi-job都启动。反正 Nacos 上没注册的服务不会被路由到也能减少不必要的日志干扰。最后想说的是若依微服务版虽然功能比较完整但它更像是“学习型企业级脚手架”不是一装上就能扛住大流量的生产框架。你还需要结合实际业务做很多优化比如缓存设计、数据库索引、接口限流、分布式事务处理等。但作为一套开箱即用的微服务基础平台它确实能帮你节省大量搭建系统骨架的时间。如果在部署过程中遇到问题欢迎按本文的排查思路一步步来基本上都能找到答案。