打包和部署

环境变量

Vite 在一个特殊的 import.meta.env 对象上暴露环境变量。这里有一些在所有情况下都可以使用的内建变量：

• import.meta.env.MODE: {string} 应用运行的模式。
• import.meta.env.BASE_URL: {string} 部署应用时的基本 URL。他由base 配置项决定。
• import.meta.env.PROD: {boolean} 应用是否运行在生产环境。
• import.meta.env.DEV: {boolean} 应用是否运行在开发环境 (永远与 import.meta.env.PROD相反)。
• import.meta.env.SSR: {boolean} 应用是否运行在 server 上。

生产环境替换

在生产环境中，这些环境变量会在构建时被静态替换，因此，在引用它们时请使用完全静态的字符串。动态的 key 将无法生效。例如，动态 key 取值 import.meta.env[key] 是无效的

env文件

Vite 使用 dotenv 从你的 环境目录 中的下列文件加载额外的环境变量：

.env                # 所有情况下都会加载
.env.local          # 所有情况下都会加载，但会被 git 忽略
.env.[mode]         # 只在指定模式下加载
.env.[mode].local   # 只在指定模式下加载，但会被 git 忽略

环境加载优先级

一份用于指定模式的文件（例如 .env.production）会比通用形式的优先级更高（例如 .env）。

.env 类文件会在 Vite 启动一开始时被加载，而改动会在重启服务器后生效。

加载的环境变量也会通过 import.meta.env 以字符串形式暴露给客户端源码。

为了防止意外地将一些环境变量泄漏到客户端，只有以 VITE_ 为前缀的变量才会暴露给经过 vite 处理的代码。例如下面这些环境变量：

VITE_SOME_KEY=123
DB_PASSWORD=foobar

只有 VITE_SOME_KEY 会被暴露为 import.meta.env.VITE_SOME_KEY 提供给客户端源码，而 DB_PASSWORD 则不会。

console.log(import.meta.env.VITE_SOME_KEY) // 123
console.log(import.meta.env.DB_PASSWORD) // undefined

Vite 还支持在 HTML 文件中替换环境变量。import.meta.env 中的任何属性都可以通过特殊的 %ENV_NAME% 语法在 HTML 文件中使用：

<h1>Vite is running in %MODE%</h1>
<p>Using data from %VITE_API_URL%</p>

如果环境变量在 import.meta.env 中不存在，比如不存在的 %NON_EXISTENT%，则会将被忽略而不被替换，这与 JS 中的 import.meta.env.NON_EXISTENT 不同，JS 中会被替换为 undefined。

注意

目前已经很少去根据环境变量去判断调用的后端服务地址了，都是用nginx做转发，不然的话你需要每个不同的后端地址都得打一份包，但是用nginx转发，所有服务器都可以用一个包。要是我们想自己控制调哪个后端服务地址，又不想每次都手动修改，可以把接口前缀配置到环境变量里，例如开发环境调用/api，生产环境调用/api-prod

模式

默认情况下，开发服务器 (dev 命令) 运行在 development (开发) 模式，而 build 命令则运行在 production (生产) 模式。

这意味着当执行 vite build 时，它会自动加载 .env.production 中可能存在的环境变量：

# .env.production
VITE_APP_TITLE=My App

在你的应用中，你可以使用 import.meta.env.VITE_APP_TITLE 渲染标题。

在某些情况下，若想在 vite build 时运行不同的模式来渲染不同的标题，你可以通过传递 --mode 选项标志来覆盖命令使用的默认模式。例如，如果你想在 staging （预发布）模式下构建应用：

vite build --mode staging

还需要新建一个 .env.staging 文件：

# .env.staging
VITE_APP_TITLE=My App (staging)

由于 vite build 默认运行生产模式构建，你也可以通过使用不同的模式和对应的 .env 文件配置来改变它，用以运行开发模式的构建：

# .env.testing
NODE_ENV=development

案例：动态修改标题

新建文件.env.dev

VITE_MY_TITLE='测试环境'

新建文件.env.pro

VITE_MY_TITLE='生产环境'

修改index.html

<title>%VITE_MY_TITLE%</title>

新建脚本命令

    "dev": "vite --port 5177 --mode dev",
    "pro":"vite --port 5177 --mode pro",

分别使用npm run dev和npm run pro命令启动项目，观察网站标题

构建产物

npm run build

运行以上命令，命令执行完毕之后会生成dist文件夹，这个就是我们前端打包构建生成的产物，将其上传到服务器，配置nginx即可

配置nginx

nginx的安装网上教程有很多，我们这里主要简单说下前端也需要知道的配置

	server {
        listen       3002; # 端口号
        server_name  localhost; # 域名访问时需要用到 端口访问时可以忽略
        location / {
            root   /usr/local/nginx/apps/dist; # 指向我们构建好的前端产物文件夹 
            index  index.html index.htm; #入口文件
			try_files $uri $uri/ /index.html; # 当路由模式是history时配置这个 不然刷新会404
        	# 配置允许跨域
			add_header Access-Control-Allow-Origin '*' always;
			add_header Access-Control-Allow-Headers '*';
			add_header Access-Control-Allow-Methods '*';
			add_header Access-Control-Allow-Credentials 'true';
			if ($request_method = 'OPTIONS') {
				add_header Access-Control-Allow-Origin '*' always;
				add_header Access-Control-Allow-Headers '*';
				add_header Access-Control-Allow-Methods '*';
				add_header Access-Control-Allow-Credentials 'true';
				return 204;
			}
        }
		# 将后端服务代理到本地时使用$remote_addr
    	# 访问/api/mock/user 将会被转发到http://127.0.0.1:4523/m1/4244721-0-default/mock/user
		location /api/mock {
			rewrite ^/api/(.*)$ /m1/4244721-0-default/$1 break;
            proxy_pass http://$remote_addr:4523;
        }
		# 将请求转发到后端服务地址：http://192.168.2.39:9010;
    	# 访问/api/user 将会被转发到http://192.168.2.39:9010/user
		location /api {
		    rewrite ^/api/(.*)$ /$1 break;
            proxy_pass http://192.168.2.39:9010;
        }


    }