uni-app 一个域名下部署多个应用：技术实现与优化指南

在当今多应用生态的场景下，企业或开发者常面临一个核心问题：如何在有限的服务器资源下，通过一个域名部署多个uni-app应用，同时保证各应用的独立性、性能与安全性？本文将从技术实现、配置优化、安全防护三个维度，系统阐述uni-app在一个域名下部署多应用的完整方案，覆盖从基础配置到高级优化的全流程。

一、技术背景与需求分析

1.1 多应用部署的典型场景

微前端架构：大型企业需将不同业务模块拆分为独立应用（如电商、社区、个人中心），通过统一域名访问。
多租户系统：SaaS平台需为不同客户部署独立应用实例，共享域名但数据隔离。
资源复用：中小团队希望降低服务器成本，通过单一域名托管多个测试/生产环境应用。

1.2 uni-app的多应用部署优势

uni-app作为跨端框架，其编译产物（H5、小程序）具备轻量化特性，天然适合多应用共存部署。通过合理配置路由与服务器规则，可实现：

统一入口：用户通过https://domain.com/app1、https://domain.com/app2访问不同应用。
独立更新：各应用可独立发布版本，不影响其他应用。
资源隔离：静态资源、Cookie、LocalStorage等数据按应用隔离。

二、核心实现方案

2.1 路由配置：子目录部署

方案一：uni-app原生路由配置

在pages.json中配置basePath（仅H5生效）：

{
  "h5": {
    "router": {
      "mode": "hash",
      "base": "/app1/"  // 应用1的子目录
    }
  }
}

注意事项：

需确保服务器将/app1/*请求转发至对应应用目录。
小程序端需通过环境变量区分应用，因小程序不支持子目录路由。

方案二：前端路由拦截（推荐）

通过uni.onAppRoute监听路由变化，结合window.location.pathname动态加载配置：

// main.js
const appPath = window.location.pathname.split('/')[1]; // 获取/app1或/app2
if (appPath === 'app1') {
  // 加载应用1的配置
  Vue.prototype.$appConfig = require('@/config/app1.js');
} else if (appPath === 'app2') {
  Vue.prototype.$appConfig = require('@/config/app2.js');
}

2.2 服务器配置：Nginx反向代理

配置示例

server {
  listen 80;
  server_name domain.com;
  # 应用1：/app1
  location /app1 {
    alias /var/www/app1/dist;
    try_files $uri $uri/ /app1/index.html;
  }
  # 应用2：/app2
  location /app2 {
    alias /var/www/app2/dist;
    try_files $uri $uri/ /app2/index.html;
  }
  # 静态资源缓存优化
  location ~* \.(js|css|png|jpg)$ {
    expires 1y;
    add_header Cache-Control "public";
  }
}

关键点：

alias需指向编译后的dist目录。
try_files确保单页应用路由正确回退到index.html。
静态资源缓存可显著提升加载速度。

2.3 数据隔离方案

方案一：Cookie/Session隔离

通过document.cookie的Path属性限制作用域：

// 应用1设置Cookie
document.cookie = `token=xxx; Path=/app1; Secure; SameSite=Lax`;

方案二：独立后端API

各应用调用独立API接口，通过域名子路径或Header区分：

// 应用1请求
fetch('https://api.domain.com/app1/user', {
  headers: { 'X-App-ID': 'app1' }
});

三、进阶优化与安全

3.1 性能优化

CDN加速：将静态资源部署至CDN，通过子目录规则回源。
预加载：利用<link rel="preload">提前加载关键资源。
Service Worker：按应用注册SW，缓存独立资源。

3.2 安全防护

CSP策略：限制各应用的资源加载域。

add_header Content-Security-Policy "default-src 'self' domain.com; script-src 'self'";

XSS防护：对动态内容转义，启用X-XSS-Protection。
CSRF令牌：按应用生成独立令牌，防止跨应用攻击。

3.3 监控与日志

应用级监控：通过Nginx的$request_uri区分应用流量。
错误隔离：各应用使用独立Sentry项目，避免错误混淆。

四、实际案例：某电商平台的部署实践

4.1 需求背景

某电商平台需部署：

主站（/）：商品展示与交易。
商家后台（/merchant）：商户管理。
营销活动（/promotion）：独立活动页。

4.2 实施步骤

编译配置：
- 主站：默认配置，编译至/var/www/main/dist。
- 商家后台：设置base: '/merchant/'，编译至/var/www/merchant/dist。

Nginx配置：

location /merchant {
  alias /var/www/merchant/dist;
  try_files $uri $uri/ /merchant/index.html;
}

数据隔离：
- 前端：通过window.location.pathname加载不同配置。
- 后端：API添加/merchant前缀，数据库按商户ID分区。

4.3 效果评估

资源复用：服务器成本降低40%。
独立发布：商家后台更新不影响主站。
性能提升：静态资源缓存命中率达92%。

五、常见问题与解决方案

5.1 路由冲突

问题：不同应用的页面路径可能重复（如/pages/index/index）。
解决：

前端：通过$appConfig.prefix动态拼接路径。
后端：API接口添加应用前缀（如/app1/api/user）。

5.2 静态资源加载失败

问题：Nginx配置错误导致CSS/JS 404。
解决：

检查alias路径是否包含dist目录。
确保try_files规则正确回退到index.html。

5.3 Cookie跨应用共享

问题：应用1设置的Cookie在应用2可读取。
解决：

显式设置Path=/app1限制Cookie作用域。
使用HttpOnly Cookie防止XSS攻击。

六、总结与建议

6.1 实施要点

统一规划：提前设计子目录结构与API规范。
渐进式迁移：先部署非核心应用，逐步验证稳定性。
自动化工具：编写脚本自动编译与部署多应用。

6.2 未来方向

容器化部署：通过Docker隔离各应用环境。
Serverless架构：按请求路由至不同Function。
边缘计算：利用CDN节点就近处理应用请求。

通过上述方案，开发者可在uni-app框架下高效实现一个域名部署多应用，兼顾灵活性与安全性。实际实施时，建议结合团队技术栈选择最适合的组合方案，并持续监控优化性能与成本。