若依前后端分离Linux部署:jar启动失败、菜单空白、跨域404三连排障

发布时间:2026/10/29 12:03:02
若依前后端分离Linux部署:jar启动失败、菜单空白、跨域404三连排障 简介本资源是一份面向Java全栈开发者与运维人员的若依RuoYi前后端分离项目实战部署指南聚焦LinuxNginx与WindowsTomcat双环境落地难点系统解决部署后404页面、跨域调用第三方API如百度地图等高频问题。文档以实操为导向完整覆盖后台jar/war包构建、Vue前端dist目录配置、Redis缓存启用、Nginx反向代理设置、Tomcat Context路径映射及WEB-INF/web.xml容错配置等关键环节并附有清晰的命令示例如nohup启动、npm build指令与配置片段截图说明。资源为1个223KB的Word文档.docx结构分明、图文结合便于快速查阅与现场执行。目前已有7766人学习下载是初学者掌握若依生产部署全流程、中级开发者排查典型环境异常的高实用性参考材料。1. 若依前后端分离部署别被“一键生成”骗了Linuxnginx 环境下 jar 启动失败、菜单空白、404 刷屏才是真实日常刚接手某高校实验室的若依项目迁移任务时我信了官网那句“代码生成器一键生成前后端代码”的宣传——结果在 CentOS 7 上跑通第一个nohup java -jar ruoyi-admin.jar后浏览器打开 IP 地址只显示白板F12 看 Network 标签全是 404第二天改完菜单重新打包登录成功却点不开任何子模块控制台报Failed to fetch menu list第三天配好 nginx 反向代理又发现百度地图 API 调用直接被拦截连Origin null都没打出来……这不是玄学是若依前后端分离版在真实生产环境里最常翻车的三连击。它不是不能跑而是对 JDK 版本、Maven 构建参数、Vue 路由模式、Nginx location 匹配顺序、Redis 连接池初始化时机这些细节极度敏感。本文专治这三类高频症状Linux 下 jar 启动后前端静态资源 404、菜单加载失败、第三方 API 跨域拦截。适合正在把若依从开发机往测试/生产服务器搬、却被文档里一句“修改 nginx.conf 即可”卡住三天的 Java 后端或全栈开发者——你缺的不是教程是一份带版本锚点、命令可复制、报错能定位的落地笔记。2. 环境准备与版本锁定为什么必须用 JDK 11 Maven 3.8.6 Node.js 16.20.2若依官方 GitHub 仓库v4.7.9明确标注支持 JDK 8/11/17但实际部署中JDK 版本错配是导致java.lang.UnsupportedClassVersionError或Caused by: java.lang.NoClassDefFoundError: javax/xml/bind/DatatypeConverter的头号原因。这不是兼容性问题是 Spring Boot 2.7.x 编译目标字节码版本与运行时 JDK 不匹配的硬伤。同样Maven 版本过低如 3.6.3会导致maven-compiler-plugin无法识别release参数而若依pom.xml中已强制设为release11Node.js 若用 18.x 以上npm run build:prod会因vue-cli-service依赖的webpack-dev-server版本冲突直接报ERR_OSSL_EVP_UNSUPPORTED。下面列出经实测验证的最小可行组合非推荐是必须组件推荐版本为什么必须这个版本验证命令JDKOpenJDK 11.0.22LTSSpring Boot 2.7.18 编译目标为 class file version 55.0JDK 17 会触发java.lang.ClassFormatError: Illegal UTF8 string in constant pool因若依部分依赖仍含非法 UTF-8 字符java -version→ 输出含11.0.22且无OpenJDK Runtime Environment (build 17...)MavenApache Maven 3.8.6支持release参数且与maven-surefire-plugin:3.0.0-M9兼容3.9.x 在 CentOS 7 上因javax.net.ssl.SSLException: Connection reset无法拉取中央仓库依赖mvn -v→ 输出Apache Maven 3.8.6Node.jsv16.20.2LTSvue-cli-service4.5.15若依前端锁死版本仅兼容 Node.js 14–16v18 触发 OpenSSL 错误v14 则因core-js版本过旧导致Promise.allSettled is not a functionnode -v→v16.20.2npm -v→8.19.2提示不要用sdk install java或nvm install自动选最新版。CentOS 7 默认yum install java-11-openjdk-devel安装的是 11.0.21需手动下载 Adoptium Temurin 11.0.22 的 tar.gz 包解压使用Node.js 必须用https://nodejs.org/dist/v16.20.2/node-v16.20.2-linux-x64.tar.xz解压后export PATH/path/to/node-v16.20.2-linux-x64/bin:$PATH。2.1 安装 JDK 11.0.22 并配置 JAVA_HOME# 下载并解压以 /opt/java 为例 cd /tmp wget https://github.com/adoptium/temurin11-binaries/releases/download/jdk-11.0.22%2B7/OpenJDK11U-jdk_x64_linux_hotspot_11.0.22_7.tar.gz tar -zxvf OpenJDK11U-jdk_x64_linux_hotspot_11.0.22_7.tar.gz -C /opt/ # 创建软链接便于切换若未来升级 ln -sf /opt/jdk-11.0.227 /opt/java11 # 配置全局环境变量 echo export JAVA_HOME/opt/java11 /etc/profile echo export PATH$JAVA_HOME/bin:$PATH /etc/profile source /etc/profile逻辑说明/opt/java11是符号链接指向具体版本目录避免硬编码路径source /etc/profile确保所有用户包括后续systemd服务都能读取到JAVA_HOME。若跳过此步nohup java -jar会 fallback 到系统默认 JDK通常是 1.8导致启动失败。2.2 安装 Maven 3.8.6 并校验插件兼容性cd /tmp wget https://dlcdn.apache.org/maven/maven-3/3.8.6/binaries/apache-maven-3.8.6-bin.tar.gz tar -zxvf apache-maven-3.8.6-bin.tar.gz -C /opt/ ln -sf /opt/apache-maven-3.8.6 /opt/maven echo export MAVEN_HOME/opt/maven /etc/profile echo export PATH$MAVEN_HOME/bin:$PATH /etc/profile source /etc/profile # 强制更新本地仓库中的 maven-compiler-plugin关键 mvn org.apache.maven.plugins:maven-dependency-plugin:3.2.0:copy \ -Dartifactorg.apache.maven.plugins:maven-compiler-plugin:3.10.1 \ -DoutputDirectory/root/.m2/repository/org/apache/maven/plugins/maven-compiler-plugin/3.10.1/参数说明最后一行命令手动将maven-compiler-plugin升级至 3.10.1因为若依pom.xml中plugingroupIdorg.apache.maven.plugins/groupIdartifactIdmaven-compiler-plugin/artifactIdversion3.10.1/version/plugin显式声明了该版本但 Maven 3.8.6 默认仓库可能缓存旧版如 3.8.1导致mvn clean package时提示Unknown lifecycle phase .1。此操作相当于给 Maven 插件库打了个补丁。2.3 安装 Node.js 16.20.2 并冻结 npm registrycd /tmp wget https://nodejs.org/dist/v16.20.2/node-v16.20.2-linux-x64.tar.xz tar -xf node-v16.20.2-linux-x64.tar.xz -C /opt/ ln -sf /opt/node-v16.20.2-linux-x64 /opt/node16 echo export NODE_HOME/opt/node16 /etc/profile echo export PATH$NODE_HOME/bin:$PATH /etc/profile source /etc/profile # 锁定淘宝镜像避免 npm install 时因网络波动失败 npm config set registry https://registry.npmmirror.com npm config set sass_binary_site https://npmmirror.com/mirrors/node-sass # 验证 vue-cli-service 是否可用 npm install -g vue/cli-service4.5.15 vue --version # 应输出 4.5.15逻辑说明vue/cli-service4.5.15是若依前端package.json中devDependencies显式指定的版本不可升级。若用npm install -g vue/cli安装最新版v5npm run build:prod会报Command build not found因为 v5 已移除build命令改用vue-cli-service build。此处强制全局安装匹配版本确保本地node_modules/.bin/vue-cli-service与项目要求一致。3. 后台 Jar 包构建与启动clean package 之前必须删掉 target 和 node_modules若依后台模块ruoyi-admin的pom.xml含多个 profiledev,test,prod默认激活dev但生产部署必须显式指定prodprofile否则application-prod.yml中的 Redis 密码、数据库连接池参数不会生效。更隐蔽的坑是若开发者在 IDEA 中用mvn compile编译过target/classes下会残留dev环境的application.yml导致mvn clean package -Pprod打包时target/ruoyi-admin.jar!/BOOT-INF/classes/里混入错误配置。血泪经验每次构建前必须物理删除target目录和根目录下的node_modules即使只改后端因为npm install会修改package-lock.json时间戳触发 Maven 的frontend-maven-plugin重新执行npm install拖慢构建速度甚至污染 classpath。3.1 正确执行 Maven 打包命令含 profile 激活与跳过测试# 进入 ruoyi-admin 目录非项目根目录 cd /path/to/ruoyi/ruoyi-admin # 彻底清理重点 rm -rf target/ ../node_modules/ # 执行 prod profile 打包跳过测试避免 test 依赖干扰 mvn clean package -Pprod -Dmaven.test.skiptrue # 验证 jar 包是否含 application-prod.yml jar -tf target/ruoyi-admin.jar | grep application-prod.yml # 应输出 BOOT-INF/classes/config/application-prod.yml参数说明-Pprod激活prodprofile使pom.xml中profilesprofileidprod/id下的properties如spring.profiles.activeprod生效-Dmaven.test.skiptrue跳过编译和运行测试防止ruoyi-quartz模块中TestJob类因缺少 Quartz 数据库表而抛SQLException。若漏掉-Pprod生成的 jar 会默认加载application.yml其中redis.hostlocalhost在生产环境必然失败。3.2 后台服务启动nohup 不是万能药systemd 才是生产标配# 创建服务目录 mkdir -p /opt/ruoyi/{logs,config} # 复制 jar 包并赋权 cp target/ruoyi-admin.jar /opt/ruoyi/ chmod x /opt/ruoyi/ruoyi-admin.jar # 复制生产配置关键 cp src/main/resources/config/application-prod.yml /opt/ruoyi/config/ # 创建 systemd 服务文件 cat /etc/systemd/system/ruoyi-admin.service EOF [Unit] DescriptionRuoyi Admin Service Afternetwork.target redis.service [Service] Typesimple Userroot WorkingDirectory/opt/ruoyi ExecStart/usr/bin/java -Xms512m -Xmx1024m -Dfile.encodingUTF-8 -Dspring.config.locationfile:/opt/ruoyi/config/application-prod.yml -jar /opt/ruoyi/ruoyi-admin.jar Restartalways RestartSec10 StandardOutputappend:/opt/ruoyi/logs/stdout.log StandardErrorappend:/opt/ruoyi/logs/stderr.log [Install] WantedBymulti-user.target EOF # 重载 systemd 并启动 systemctl daemon-reload systemctl enable ruoyi-admin systemctl start ruoyi-admin # 查看日志实时跟踪启动过程 journalctl -u ruoyi-admin -f逻辑说明-Dspring.config.location显式指定配置文件路径覆盖 jar 包内BOOT-INF/classes/config/下的默认配置避免因 jar 内置配置写死localhost导致 Redis 连接失败Restartalways确保进程崩溃后自动拉起StandardOutput/StandardError将日志定向到/opt/ruoyi/logs/比nohup生成的msg.log更易管理。若坚持用nohup必须加-Dspring.config.location参数否则nohup java -jar ruoyi-admin.jar log.out 21 会读取 jar 内application.yml连接本地 Redis 失败。3.3 Redis 部署6379 端口不是唯一要开的protected-mode 必须关若依使用 Redis 存储在线用户、验证码、定时任务等其application-prod.yml中redis.host默认为127.0.0.1但生产环境 Redis 往往独立部署。此时需修改redis.host为实际 IP并关闭 Redis 的protected-mode保护模式否则远程连接会被拒绝。# 安装 Redis以 CentOS 7 为例 yum install epel-release -y yum install redis -y # 修改配置文件 sed -i s/^bind 127.0.0.1/# bind 127.0.0.1/ /etc/redis.conf sed -i s/^protected-mode yes/protected-mode no/ /etc/redis.conf sed -i s/^# requirepass foobared/requirepass your_strong_password/ /etc/redis.conf # 开放防火墙端口 firewall-cmd --permanent --add-port6379/tcp firewall-cmd --reload # 启动并设开机自启 systemctl enable redis systemctl start redis # 验证远程连接从若依服务器执行 redis-cli -h your_redis_ip -a your_strong_password ping # 应返回 PONG参数说明bind 127.0.0.1注释掉后Redis 监听所有网卡protected-mode no关闭保护模式允许外部 IP 连接requirepass设置强密码若依application-prod.yml中redis.password必须与此一致。若漏关protected-modejournalctl -u ruoyi-admin会看到Cannot connect to Redis server但错误日志不提示具体原因这是个典型的黑匣子坑。4. 前端 Dist 包构建与 Nginx 配置Vue Router history 模式下的 location 匹配陷阱若依前端采用 Vue Router 的history模式非hash模式URL 为/dashboard而非/#/dashboard。这意味着当用户直接访问http://ip/dashboard时Nginx 必须将所有非 API 请求即非/prod-api/开头的请求都转发到index.html否则会返回 404。但若配置不当/prod-api/login这类 API 请求也会被错误重写导致后端接口调用失败。核心矛盾在于Nginx 的location匹配顺序是精确匹配 前缀匹配 正则匹配而location /会捕获一切请求必须用location ^~ /prod-api/提前截断 API 流量。4.1 Vue 项目构建build:prod --report 不是必须但 publicPath 必须为 /# 进入 ruoyi-ui 目录 cd /path/to/ruoyi/ruoyi-ui # 清理 node_modules再次强调 rm -rf node_modules/ # 安装依赖用锁定的版本 npm install # 修改 vue.config.js关键 sed -i /^module.exports/a\ \ publicPath: /, // 必须为根路径否则 dist 下资源加载 404 vue.config.js # 执行构建 npm run build:prod --report # 验证 dist 目录结构 ls -l dist/ # 应包含 index.html, static/, favicon.ico 等逻辑说明publicPath: /告诉 webpack 所有静态资源JS/CSS/IMG的引用路径以/开头例如script src/static/js/app.xxx.js。若vue.config.js中publicPath为./或生成的index.html里资源路径会变成script src./static/js/app.xxx.js当 Nginx 将请求重写到index.html时浏览器会尝试从当前 URL 路径下加载 JS如访问/user/list时去请求/user/list/static/js/app.xxx.js必然 404。这是菜单空白的最常见原因。4.2 Nginx 配置四层 location 分流精准拦截 API 与静态资源# 安装 NginxCentOS 7 yum install nginx -y # 备份默认配置 mv /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak # 创建新配置 cat /etc/nginx/nginx.conf EOF user nginx; worker_processes auto; error_log /var/log/nginx/error.log warn; pid /var/run/nginx.pid; events { worker_connections 1024; } http { include /etc/nginx/mime.types; default_type application/octet-stream; log_format main $remote_addr - $remote_user [$time_local] $request $status $body_bytes_sent $http_referer $http_user_agent $http_x_forwarded_for; access_log /var/log/nginx/access.log main; sendfile on; tcp_nopush on; tcp_nodelay on; keepalive_timeout 65; types_hash_max_size 2048; include /etc/nginx/conf.d/*.conf; } EOF # 创建 ruoyi 专用配置 cat /etc/nginx/conf.d/ruoyi.conf EOF upstream ruoyi_backend { server 127.0.0.1:8080; # 若依后台默认端口 } server { listen 80; server_name _; # 1. 精确匹配 favicon.ico避免 404 日志刷屏 location /favicon.ico { root /opt/ruoyi/dist; expires 1d; add_header Cache-Control public, immutable; } # 2. 前缀匹配 API 接口全部转发到后端 location ^~ /prod-api/ { proxy_pass http://ruoyi_backend/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_redirect off; } # 3. 正则匹配静态资源js/css/img/fonts直接由 Nginx 返回 location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|woff|woff2|ttf|eot)$ { root /opt/ruoyi/dist; expires 1y; add_header Cache-Control public, immutable; } # 4. 兜底匹配所有其他请求/dashboard, /user/list都返回 index.html location / { root /opt/ruoyi/dist; try_files $uri $uri/ /index.html; } } EOF # 创建 dist 目录并复制前端文件 mkdir -p /opt/ruoyi/dist cp -r /path/to/ruoyi/ruoyi-ui/dist/* /opt/ruoyi/dist/ # 启动 Nginx systemctl enable nginx systemctl start nginx参数说明location ^~ /prod-api/的^~表示前缀匹配且优先级最高确保/prod-api/login不被location /拦截try_files $uri $uri/ /index.html是 history 模式的核心当请求/user/list时Nginx 先查/opt/ruoyi/dist/user/list不存在再查/opt/ruoyi/dist/user/list/不存在最后返回/opt/ruoyi/dist/index.html由 Vue Router 解析路由root /opt/ruoyi/dist在location /中定义但location ~* \.(js|css|...)$中也需重复声明否则正则匹配的资源会找不到路径。若location /中漏写root所有请求都会 404。4.3 常见问题排查菜单空白、404、跨域的三分钟定位法注意以下问题均基于上述标准配置若自行修改过vue.config.js或nginx.conf请先还原再排查。现象 1浏览器打开 IP 显示白板F12 Console 报Failed to load resource: the server responded with a status of 404 ()Network 标签中index.html200但static/js/app.xxx.js404原因vue.config.js中publicPath未设为/或 Nginxlocation ~* \.(js|css|...)$中root路径错误解决检查dist/index.html源码确认script标签src属性是否以/static/开头执行curl -I http://localhost/static/js/app.xxx.js看是否返回 200若 404检查/etc/nginx/conf.d/ruoyi.conf中location ~*块的root是否指向/opt/ruoyi/dist现象 2登录成功但点击“系统监控”、“在线用户”等菜单页面空白Network 标签中/prod-api/getRouters返回 404原因Nginxlocation ^~ /prod-api/未生效请求被location /拦截并返回index.html导致前端收到 HTML 当作 JSON 解析失败解决执行curl -v http://localhost/prod-api/getRouters若返回HTTP/1.1 200 OK且 body 为 JSON则 Nginx 转发正常若返回HTTP/1.1 200 OK且 body 为 HTML则location ^~ /prod-api/未匹配检查nginx.conf中该块是否被注释或拼写错误如/prod-api少了末尾/现象 3登录后菜单可展开但点击任意按钮如“新增用户”弹窗空白Console 报Uncaught SyntaxError: Unexpected token 原因location /中try_files顺序错误或root路径指向了错误目录导致.js文件被当作 HTML 返回解决执行curl http://localhost/static/js/app.xxx.js | head -n 5若输出html标签则说明 JS 文件被location /拦截检查location ~* \.(js|css|...)$是否在location /之前定义且root路径正确现象 4调用百度地图 API 时浏览器 Network 标签显示Blocked by CORS policy: No Access-Control-Allow-Origin header is present on the requested resource原因前端直接请求https://api.map.baidu.com/...浏览器因同源策略拦截若依后端未配置反向代理或 Nginx 未配置对应location解决在nginx.conf中添加百度地图代理见第 5 章或在若依后端RestController中用RestTemplate代理请求不推荐增加后端负担5. 第三方 API 跨域处理Nginx 反向代理是唯一零侵入方案若依项目中调用百度地图、高德地图等第三方 API 时前端 JavaScript 直接发起fetch(https://api.map.baidu.com/...)请求必然触发浏览器 CORS 限制。有人试图在 Spring Boot 中加CrossOrigin(origins *)但这对第三方域名无效——CrossOrigin只控制本应用的响应头无法让api.map.baidu.com返回Access-Control-Allow-Origin: *。唯一合规且零侵入的方案是在 Nginx 层配置反向代理将/api/baidu/前缀的请求转发到百度 API使前端请求变为同源。这样既规避了浏览器限制又无需修改若依前后端一行代码。5.1 Nginx 配置百度地图反向代理location /api/baidu/ 的完整写法# 编辑 ruoyi.conf在 server 块内添加 cat /etc/nginx/conf.d/ruoyi.conf EOF # 百度地图 API 反向代理解决跨域 location /api/baidu/ { proxy_pass https://api.map.baidu.com/; proxy_set_header Host api.map.baidu.com; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_ssl_server_name on; # 关键启用 SNI否则 HTTPS 代理失败 proxy_redirect off; # 缓存控制可选 proxy_cache_valid 200 302 10m; proxy_cache_valid 404 1m; } EOF # 重载 Nginx nginx -t systemctl reload nginx参数说明proxy_pass https://api.map.baidu.com/末尾的/至关重要它表示将/api/baidu/geocoding/v3/重写为https://api.map.baidu.com/geocoding/v3/proxy_ssl_server_name on启用 TLS Server Name Indication否则 Nginx 无法正确协商百度服务器的 SSL 证书返回502 Bad Gatewayproxy_set_header Host api.map.baidu.com确保百度服务器收到正确的 Host 头否则可能返回 400。若漏掉proxy_ssl_server_name oncurl -v http://localhost/api/baidu/会看到SSL_do_handshake() failed。5.2 前端代码适配将百度 API URL 替换为相对路径# 进入 ruoyi-ui/src/api 目录找到调用百度地图的文件如 map.js cd /path/to/ruoyi/ruoyi-ui/src/api # 将所有 https://api.map.baidu.com/ 替换为 /api/baidu/ sed -i s|https://api.map.baidu.com/|/api/baidu/|g map.js # 若有多个文件批量替换 grep -rl api.map.baidu.com . | xargs sed -i s|https://api.map.baidu.com/|/api/baidu/|g逻辑说明替换后前端请求fetch(/api/baidu/geocoding/v3/?akxxx)Nginx 的location /api/baidu/拦截该请求转发到https://api.map.baidu.com/geocoding/v3/?akxxx浏览器认为这是同源请求都走http://your-ip/CORS 自然解除。此方案无需后端参与不增加若依服务负载且百度 API 的 AK 密钥仍在前端暴露——但这是公开 API 的固有特性无法避免只能靠 AK 绑定 Referer 或 IP 白名单降低风险。5.3 高德地图等其他 API 的代理配置模板# 高德地图amap location /api/amap/ { proxy_pass https://restapi.amap.com/; proxy_set_header Host restapi.amap.com; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_ssl_server_name on; proxy_redirect off; } # 腾讯地图qqmap location /api/qqmap/ { proxy_pass https://apis.map.qq.com/; proxy_set_header Host apis.map.qq.com; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_ssl_server_name on; proxy_redirect off; }逻辑说明每个第三方 API 需独立location块proxy_pass后的域名必须与Host头一致否则目标服务器可能拒绝请求proxy_ssl_server_name on对所有 HTTPS 代理均为必需。若同时配置多个Nginx 会按location定义顺序匹配因此/api/baidu/和/api/amap/不会冲突。6. 部署完成后的终极验证三步 curl 检查法与日志追踪链部署完成不等于跑通真正的验证必须绕过浏览器用curl模拟真实请求链路从 Nginx 入口一路穿透到 Redis 和 MySQL。我习惯用三步法第一步查 Nginx 是否正确分流第二步查后端 API 是否返回有效 JSON第三步查 Redis 是否写入在线用户。这套方法能在 2 分钟内定位 90% 的部署问题比开着浏览器点来点去高效得多。6.1 第一步验证 Nginx 分流是否正确curl 检查 200/404# 1. 请求首页应返回 200 且 Content-Type 为 text/html curl -I http://localhost/ | head -n 5 # 预期输出HTTP/1.1 200 OK Content-Type: text/html # 2. 请求 JS 文件应返回 200 且 Content-Type 为 application/javascript curl -I http://localhost/static/js/app.xxx.js | head -n 5 # 预期输出HTTP/1.1 200 OK Content-Type: application/javascript # 3. 请求 API 接口应返回 200 且 Content-Type 为 application/json curl -I http://localhost/prod-api/login | head -n 5 # 预期输出HTTP/1.1 200 OK Content-Type: application/json # 4. 请求百度地图代理应返回 200非 502 curl -I http://localhost/api/baidu/geocoding/v3/ | head -n 5 # 预期输出HTTP/1.1 200 OK百度返回的实际状态码逻辑说明curl -I只获取响应头速度快head -n 5限制输出行数避免长响应体干扰。若第 2 步返回 404说明location ~* \.(js|css|...)$未生效若第 3 步返回 404说明location ^~ /prod-api/未匹配若第 4 步返回 502说明proxy_ssl_server_name on未开启或百度域名解析失败。6.2 第二步验证后端 API 是否返回有效 JSONcurl 模拟登录# 发送登录请求使用若依默认账号 admin/admin123 curl -X POST http://localhost/prod-api/login \ -H Content-Type: application/json \ -d {username:admin,password:admin123} \ -v 21 | grep -E (HTTP/1.1|\code\:|\token\:) # 预期输出HTTP/1.1 200 OK code:200 token:xxxx # 用返回的 token 获取菜单验证 JWT 解析 TOKEN$(curl -s -X POST http://localhost/prod-api/login \ -H Content-Type: application/json \ -d {username:admin,password:admin123} | jq -r .token) curl -X GET http://localhost/prod-api/getRouters \ -H Authorization: Bearer $TOKEN \ -v 21 | grep -E (HTTP/1.1|\name\:|\path\:) # 预期输出HTTP/1.1 200 OK 菜单 JSON 数组参数说明-v本文还有配套的精品资源点击获取

关于本文作者

来自尧图内容编辑团队

尧图内容编辑团队 内容团队

尧图内容编辑团队

本文由尧图网络内容编辑团队执笔。团队由资深项目经理、前端工程师与设计师组成,所有内容均来自亲手交付的真实项目,先讲清问题、再给出可落地的解法。尧图深耕北京网站建设十年,服务过京华建材集团、智造科技等各行业客户,把一线经验沉淀为可复用的行业观察。

  • 十年建站经验,覆盖建材、制造、服务、文创等
  • 项目经理把关选题与事实准确性
  • 工程师与设计师联合撰写专业细节
  • 统一编辑规范,保证文风与排版一致
  • 每月复盘转化数据,迭代选题方向

延伸阅读

相关资讯与近期热门内容

深度阅读推荐

建站决策前值得细读的三篇

网站改版的5个关键决策
2024-08-12

网站改版的5个关键决策

什么时候该改版、改到什么程度、如何避免流量掉光,京华建材集团改版复盘给出答案。

获取专属建站方案

看完文章,把您的行业与预算告诉我们,免费获取一份量身定制的官网建设方案与报价。

立即免费咨询