核心是通过Nginx的proxy_cookie_path按location统一重写Cookie Path，确保各子服务Cookie仅在其对应前端路径（如/shop/、/user/）下生效；同时需配合proxy_redirect和X-Forwarded-Prefix处理跳转与资源路径。
核心是让每个子服务返回的 Cookie 只在它对应的前端路径下生效，浏览器才不会错发、漏发——不是改后端代码，而是在 Nginx 代理层统一做路径映射。
按 location 分别配置基础路径映射
每个子服务对应一个独立的 location 块，proxy_cookie_path 写在 proxy_pass 后面，只影响该路径下的响应头：
- location /shop/ { proxy_pass http://shop_backend/; proxy_cookie_path / /shop/; }→ 把后端 Set-Cookie 中的 Path=/ 改成 Path=/shop/
- location /user/ { proxy_pass http://user_backend/; proxy_cookie_path / /user/; }→ 同理，确保 /user/ 下的 Cookie 不会跑到 /shop/ 请求里
- location /admin/ { proxy_pass http://admin_backend/; proxy_cookie_path / /admin/; }
处理后端自带非根路径的 Cookie
有些服务自身部署在子路径（如后端返回 Path=/api/v1/），但你希望它对外暴露为 /shop/api/v1/。这时不能一刀切全替成 /shop/，否则 API 路径错乱：
- 后端返回 Path=/api/v1/，前端访问路径是 /shop/ → 配置：proxy_cookie_path /api/v1/ /shop/api/v1/;
- 后端同时返回 Path=/（主页面 Cookie）和 Path=/api/v1/ → 可叠加一条：proxy_cookie_path / /shop/;（Nginx 按顺序匹配，更具体的规则优先）
用正则支持路径结构变化
当子服务升级路径含变量（如 /v2/product、/v3/order）或有嵌套前缀（如 /project/user/abc123），正则能避免每次改配置：
- 统一将所有 /v\d+/ 开头的原始 Path 映射到 /shop/ 下： proxy_cookie_path ~^/v(\d+)/(.*)$ /shop/v$1/$2;
- 把后端写的 Path=/project/user/xxx 动态转成 /user/xxx： proxy_cookie_path ~^/project/(.*)$ /$1;
必须同步处理跳转与资源路径
只改 Cookie Path 不够。后端返回的 Location 头（如 302 跳转到 /dashboard）或 JS 中硬编码的 /api/login，仍指向原始路径，会导致二次请求因路径不匹配而丢失 Cookie：
- 加 proxy_redirect / /shop/; 重写跳转地址
- 前端资源请求需带 X-Forwarded-Prefix 或由后端读取该头生成正确链接
- 必要时配合 proxy_set_header X-Forwarded-Prefix /shop/;
