微前端中proxy_pass路径重写需对齐子应用context-path：若子应用设为/app-order，则proxy_pass应为http://sub-app:8080/app-order/；若为空则必须以/结尾；推荐用rewrite剥离前缀并配proxy_redirect修复重定向。
微前端架构下，proxy_pass 路径重写未对齐，本质是主应用与子应用在请求路径语义上“各说各话”——浏览器发来的路径、Nginx 代理转发的路径、后端服务实际期望处理的路径三者不一致，导致静态资源加载失败、API 返回 404、重定向跳转错乱甚至白屏。解决关键在于统一路径上下文，而非简单加减前缀。
明确各层路径责任边界
微前端中路径不是单纯字符串拼接，而是分层契约：
-
浏览器视角：请求路径如
/app-order/assets/logo.png或/app-order/api/user，含微应用命名空间前缀 -
Nginx 视角：location 匹配的是这个完整路径；proxy_pass 后端地址必须对应子应用真实的 context-path（如子应用自己设了
server.servlet.context-path=/app-order） -
子应用视角：它只认
/assets/logo.png和/api/user，不感知外层前缀
若子应用 context-path 是 /app-order，而 Nginx 配置为 location /app-order/ { proxy_pass http://sub-app:8080/; }，就会把 /app-order/api/user 转发成 http://sub-app:8080/app-order/api/user——多了一层前缀，必然 404。
前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。
proxy_pass 必须与子应用 context-path 严格对齐
正确做法是让 proxy_pass 的路径终点，恰好等于子应用自身配置的 context-path：
- 若子应用启动时设
--server.servlet.context-path=/app-order，则 Nginx 应写：location /app-order/ {<br> proxy_pass http://sub-app:8080/app-order/;<br>} - 若子应用 context-path 为空（即根路径），则 proxy_pass 结尾必须带斜杠：
location /app-order/ {<br> proxy_pass http://sub-app:8080/;<br>} - 绝对禁止
proxy_pass http://sub-app:8080;（无结尾斜杠）——这会导致路径自动拼接，引发前缀叠加
用 rewrite 显式剥离前缀，解耦 Nginx 与子应用配置
更健壮的做法是主动剥离命名空间，再透传给子应用，避免其 context-path 变更时反复改 Nginx：
location /app-order/ {<br> rewrite ^/app-order/(.*)$ /$1 break;<br> proxy_pass http://sub-app:8080/;<br>}- 这样无论子应用 context-path 是
/还是/v2，Nginx 都只转发干净路径，子应用只需专注自身路由逻辑 - 注意：
break表示重写后不再匹配其他 location；若需继续匹配，用last
同步修复重定向与响应头，防止路径在跳转中丢失
子应用返回 302 重定向时，常自带相对路径（如 /login）或绝对路径（如 http://localhost:8080/login），若不干预，用户会跳到错误地址或内网地址：
- 添加
proxy_redirect / /app-order/;，将后端返回的相对重定向路径补上前缀 - 添加
proxy_redirect ~^http://[^/]+/(.*)$ https://$host/app-order/$1;，统一升级协议并补全前缀 - 务必设置
proxy_set_header X-Forwarded-Proto $scheme;和proxy_set_header Host $host;，让子应用生成链接时能还原真实入口
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
