项目开发 on acye's blog

CSS小案例，讲布局（Flex+Grid）

Sun, 14 Dec 2025 22:36:00 +0000

从新闻页面 CSS+成果图看布局设计：实用 Flex 与结构化布局技巧

在前端开发中，布局是页面的骨架，直接决定了内容呈现的逻辑性和视觉舒适度。最近落地了一个新闻列表页面（如下成果图所示），其布局设计简洁高效，尤其适合信息密集型页面（如新闻、资讯类），今天就结合成果图+对应 CSS 代码，拆解其中的布局思路和实用技巧。

（注：下图即为本次分析对应的页面成果，后续会一一对应布局模块）

一、布局基础：全局样式与容器搭建（成果图整体框架）

任何布局的第一步都是打“地基”——成果图里的整个内容区域，就是通过以下代码实现的核心容器：

* {
  margin: 0;
  padding: 0;
  box-sizing: border-box;
}
body {
  background: orange;
  background-attachment: fixed;
  padding-top: 25px;
}
.big_box {
  width: 80%;
  margin: 0 auto;
  padding: 20px;
  background: linear-gradient(180deg, #f0f0f0 0%, whitesmoke 100%);
  border-radius: 20px;
}

对应成果图的效果：

成果图里的所有内容（左侧新闻+右侧热搜）都包裹在big_box中，实现了水平居中+左右留白，适配不同屏幕；
容器的渐变背景+圆角，让成果图里的内容区和外部橙色背景区分开，视觉更整洁。

二、核心布局：Flex 的灵活运用（成果图主次分栏+内容排列）

成果图的“左主新闻区+右热搜区”“单图/多图新闻”等结构，全靠 Flex 布局实现：

1. 主次分栏布局（成果图左+右区域）

.box {
  max-width: 1200px;
  display: flex;
  gap: 50px;
  align-items: flex-start;
}
.left {
  flex: 1;
} /* 成果图左侧主新闻区 */
.right {
  width: 360px;
  flex-shrink: 0;
} /* 成果图右侧热搜区 */

对应成果图的效果：

左侧主区（left）自动占满剩余空间，呈现多条新闻；右侧热搜区（right）固定宽度不收缩，保证榜单布局稳定（成果图右侧的热搜列表不会被挤压）；
两者顶部对齐（align-items: flex-start），对应成果图里左、右区域的顶部是齐平的。

2. 单图新闻布局（成果图“2024 高考倒计时”那条）

.row_box {
  display: flex;
  gap: 16px;
}
.img1 {
  width: 32%;
  aspect-ratio: 4/3;
  flex-shrink: 0;
  border-radius: 8px;
}
.text_box {
  flex: 1;
  display: flex;
  flex-direction: column;
  justify-content: space-between;
}

对应成果图的效果：

成果图里“2024 高考倒计时”左侧的空白块，就是img1（固定宽占比+比例），不会因文本长度变形；
右侧文本区上下分布（标题在上、时间/来源在下），对应成果图里这条新闻的文字区域布局均匀。

3. 多图新闻布局（成果图第三条新闻的三个图）

.img3_box {
  display: flex;
  gap: 6px;
  margin: 10px 0;
}
.img3 {
  flex: 1;
  aspect-ratio: 16/10;
  border-radius: 6px;
}

对应成果图的效果：

成果图第三条新闻下方的三个空白块，就是通过flex: 1实现的均等分栏，无需手动算宽度，保证三张图整齐排列。

4. 热搜榜单布局（成果图右侧列表）

.hot_li {
  display: flex;
  align-items: flex-start;
  margin-bottom: 14px;
}
.rank {
  width: 18px;
  flex-shrink: 0;
  font-weight: 700;
}
.hot_text {
  white-space: nowrap;
  overflow: hidden;
  text-overflow: ellipsis;
}

对应成果图的效果：

成果图右侧的“1、2、3…”排名，是rank（固定宽度不位移）；
超长热搜标题自动省略（比如成果图里的第一条热搜），避免换行打乱布局。

三、布局设计的核心思路总结（结合成果图）

这个页面的布局之所以在成果图里呈现得清晰舒适，核心是“结构化+灵活性”的平衡：

先骨架后内容：先通过big_box/box定整体框架（成果图的大容器+分栏），再填内部组件；
Flex 适配场景：分栏用 Flex、单图/多图用 Flex、榜单用 Flex，替代浮动/定位，代码简洁且适配成果图的各种排列需求；
固定+灵活结合：热搜区/图片/排名固定（保证成果图里的关键区域稳定），主新闻区灵活伸缩（适配不同屏幕）；
细节控体验：文本省略、统一间距、固定比例，让成果图里的布局既规整又不呆板。

如何将vue cli 写的前端文件转换为vite（详细板）

Sun, 14 Dec 2025 22:36:00 +0000

从 Vue CLI 迁移到 Vite 的完整指南

📋 迁移概览

将项目从 Vue CLI 迁移到 Vite 确实如你所说，主要包括以下几个核心步骤。

🗺️ 迁移路线图

步骤 1：备份原有项目

1
2

# 在开始前一定要备份
cp -r my-project my-project-backup

步骤 2：删除旧配置文件

# 删除 Vue CLI 相关配置文件
rm vue.config.js
rm babel.config.js  # 如果存在
rm .eslintrc.js     # 如果使用单独的配置文件

步骤 3：清理项目依赖

1
2
3

# 删除 node_modules 和锁文件
rm -rf node_modules
rm package-lock.json  # 或 rm yarn.lock

📝 详细步骤说明

1. 修改 package.json

主要变化：

{
  "type": "module", // 新增：声明为 ES 模块
  "scripts": {
    // Vue CLI 脚本 → Vite 脚本
    "serve": "vue-cli-service serve", // 删除
    "build": "vue-cli-service build", // 删除
    "dev": "vite", // 新增
    "build": "vite build", // 修改
    "preview": "vite preview" // 新增
  },
  "dependencies": {
    // 移除 Vue CLI 特定的依赖
    // 保持应用层依赖不变
  },
  "devDependencies": {
    // 完全替换开发依赖
    "@vue/cli-*": "~5.0.0", // 删除所有
    "@vitejs/plugin-vue": "^5.0.5", // 新增
    "vite": "^5.4.8", // 新增
    "sass-embedded": "^1.83.0" // 推荐使用 sass-embedded
  }
}

为什么要这样改？

Vue CLI 基于 Webpack，而 Vite 是全新的构建工具
type: "module" 让 Node.js 支持 ES6 模块语法
Vite 的命令更简洁直观

2. 配置文件迁移

从 vue.config.js 到 vite.config.js

// vue.config.js (旧)
module.exports = {
  devServer: {
    proxy: {
      "/api": {
        target: "http://10.245.30.86:8080",
        changeOrigin: true,
      },
    },
  },
};

// vite.config.js (新)
import { defineConfig } from "vite";

export default defineConfig({
  server: {
    proxy: {
      "/api": {
        target: "http://10.245.30.86:8080",
        changeOrigin: true,
      },
    },
  },
});

关键差异：

Vite 使用 ES 模块语法 (import/export)
配置结构更扁平
热更新速度显著提升

3. 环境变量处理

Vue CLI 方式：

// .env.development
VUE_APP_BASE_API=/api
VUE_APP_PROXY_TARGET=http://10.245.30.86:8080

// 代码中使用
process.env.VUE_APP_BASE_API

Vite 方式：

// .env.development
VITE_BASE_API=/api
VITE_PROXY_TARGET=http://10.245.30.86:8080

// 代码中使用
import.meta.env.VITE_BASE_API

或者保留 Vue 前缀：

// vite.config.js 中配置
envPrefix: ["VUE_APP_", "VITE_"],
  // 这样可以使用两种前缀
  import.meta.env.VUE_APP_BASE_API;

4. 请求配置文件修改

修改 src/utils/request.js（或类似文件）：

// 原来的 Vue CLI 方式
const service = axios.create({
  baseURL: process.env.VUE_APP_BASE_API || "/api",
  timeout: 10000,
});

// 修改为 Vite 方式
const service = axios.create({
  baseURL: import.meta.env.VUE_APP_BASE_API || "/api",
  timeout: 10000,
});

重要说明：

process.env → import.meta.env
只有以 VITE_ 或配置的前缀开头的变量才会被暴露
环境变量在构建时被替换

5. HTML 文件处理

Vue CLI：

1
2
3

public/
  index.html
src/

Vite：

1
2
3

根目录/
  index.html  # 移动到根目录
src/

修改 index.html：

<!-- 原来的 -->
<script src="/js/chunk-vendors.js"></script>
<script src="/js/app.js"></script>

<!-- 现在：删除所有显式的脚本引入 -->
<!DOCTYPE html>
<html lang="zh-CN">
  <head>
    <meta charset="UTF-8" />
    <link rel="icon" type="image/svg+xml" href="/vite.svg" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Vite App</title>
  </head>
  <body>
    <div id="app"></div>
    <!-- Vite 会自动注入脚本 -->
    <script type="module" src="/src/main.js"></script>
  </body>
</html>

6. 静态资源引用方式

Vue CLI：

import logo from '@/assets/logo.png';
<img :src="logo" />

// 或
<img src="@/assets/logo.png" />

Vite：

// 方式1：使用相对或绝对路径
<img src="/src/assets/logo.png" />

// 方式2：使用 import
import logoUrl from '@/assets/logo.png';
<img :src="logoUrl" />

// 方式3：使用 public 目录（不经过构建）
<img src="/logo.png" />  // 放在 public/logo.png

7. 路径别名配置

vite.config.js 中配置：

import path from "path";

export default defineConfig({
  resolve: {
    alias: {
      "@": path.resolve(__dirname, "./src"),
      // 可以添加更多别名
      "@components": path.resolve(__dirname, "./src/components"),
    },
  },
});

🔧 常见问题解决

问题 1：CommonJS 模块报错

// 错误：require is not defined
const module = require("module");

// 解决：改为 ES6 导入
import module from "module";

问题 2：process 变量报错

// 错误：process is not defined
if (process.env.NODE_ENV === "development") {
}

// 解决：使用 import.meta.env
if (import.meta.env.MODE === "development") {
}

问题 3：CSS 预处理器错误

// vite.config.js 中正确配置
export default defineConfig({
  css: {
    preprocessorOptions: {
      scss: {
        additionalData: `@import "@/styles/variables.scss";`,
      },
    },
  },
});

📦 完整迁移脚本

#!/bin/bash
# migrate-to-vite.sh

echo "🚀 开始迁移 Vue CLI 到 Vite..."

# 1. 备份
echo "📦 备份原项目..."
cp -r ./ ./backup-$(date +%Y%m%d-%H%M%S)

# 2. 删除旧文件
echo "🗑️  删除旧配置文件..."
rm -f vue.config.js
rm -f babel.config.js

# 3. 清理依赖
echo "🧹 清理 node_modules..."
rm -rf node_modules
rm -f package-lock.json

# 4. 移动 HTML 文件
echo "📄 移动 HTML 文件..."
if [ -f "public/index.html" ]; then
    mv public/index.html ./
    rm -rf public
fi

# 5. 更新 package.json
echo "📝 更新 package.json..."
# 这里可以编写 sed 命令或手动修改

# 6. 创建 vite.config.js
echo "⚙️  创建 Vite 配置文件..."
cat > vite.config.js << 'EOF'
import { defineConfig } from "vite";
import vue from "@vitejs/plugin-vue";
import path from "path";

export default defineConfig({
  plugins: [vue()],
  resolve: {
    alias: {
      "@": path.resolve(__dirname, "./src"),
    },
  },
  server: {
    port: 8081,
    open: true,
    proxy: {
      "/api": {
        target: "http://localhost:8080",
        changeOrigin: true,
      },
    },
  },
});
EOF

echo "✅ 迁移完成！"
echo "📦 请运行: npm install"
echo "🚀 然后运行: npm run dev"

📊 迁移前后对比

特性	Vue CLI (Webpack)	Vite
启动速度	20-30 秒	1-3 秒
热更新	1-3 秒	50-300 毫秒
配置复杂度	复杂	简单
插件生态	成熟	快速增长
构建速度	中等	快速

🎯 迁移后的优势

极速启动：Vite 启动速度比 Vue CLI 快 10-100 倍
闪电热更新：无论项目大小，热更新几乎瞬间完成
更简单配置：配置文件更简洁易懂
现代工具链：原生支持 ES 模块、TypeScript 等
更好的开发体验：按需编译，无需等待整个应用构建

📚 总结

迁移到 Vite 确实是一个相对简单的过程，主要就是：

改配置：package.json + vite.config.js
改代码：环境变量访问方式
改结构：HTML 文件位置
改引用：静态资源导入方式

跨域问题讲解

Sat, 29 Nov 2025 22:36:00 +0000

前言

在前后端分离开发模式下，跨域是前端开发者绕不开的问题。浏览器的同源策略限制了不同域名/端口间的资源请求，而解决跨域的核心方案主要有两种：CORS（跨域资源共享） 和反向代理。本文结合全域生活平台的示例，详解这两种方案的原理、应用场景及踩坑要点。

注：后文会详细讲解 Nginx 反向代理（这是前端程序员的必备知识）

一、问题背景：为什么会跨域？

先看我们的项目环境：

前端（Vue）运行在 http://localhost:8081（通过vue.config.js配置）；
后端（Express）运行在 http://localhost:8080（接口路径如/api/merchant）。

浏览器的同源策略要求“协议+域名+端口”完全一致，因此前端直接请求后端接口会触发跨域错误——比如控制台提示No 'Access-Control-Allow-Origin' header is present on the requested resource。

二、CORS：后端主导的跨域解决方案

CORS 是 W3C 标准，通过后端设置响应头允许指定源的跨域请求，是最直接的跨域方案之一。以下是两种常见的 CORS 配置方式：

1. 方案 1：使用`cors`中间件（便捷高效）

Express 生态提供了cors包，可一键配置跨域规则，也是项目中最常用的方式：

// 使用cors中间件的Express代码
const express = require("express");
const cors = require("cors");
const app = express();

app.use(express.json());
// 全局启用cors，默认允许所有源（生产环境建议指定具体源）
app.use(
  cors({
    origin: "http://localhost:8081", // 仅允许前端8081端口访问
    methods: ["GET", "POST", "PUT", "DELETE", "OPTIONS"], // 允许的请求方法
    allowedHeaders: ["Content-Type", "Authorization"], // 允许的请求头
  })
);

// 接口路由
const merchantRouder = require("./routes/merchant");
const customerRouder = require("./routes/service");
const orderRouder = require("./routes/order");
app.use("/api/merchant", merchantRouder);
app.use("/api/service", customerRouder);
app.use("/api/order", orderRouder);

app.listen(8080, () => {
  console.log("服务器启动成功！");
  console.log("http://localhost:8080");
});

这种方式无需手动处理预检请求，cors包会自动拦截OPTIONS请求并返回正确响应头。

2. 方案 2：手动配置 CORS（深入原理）

若不想依赖第三方包，可手动设置响应头并处理预检请求（适合理解 CORS 底层逻辑）：

// 手动处理CORS的Express代码
const express = require("express");
const app = express();

app.use(express.json());

// 自定义跨域中间件
app.use((req, res, next) => {
  // 允许前端8081端口访问
  res.setHeader("Access-Control-Allow-Origin", "http://localhost:8081");
  // 允许的请求方法（覆盖所有常用HTTP方法）
  res.setHeader(
    "Access-Control-Allow-Methods",
    "GET, POST, PUT, DELETE, OPTIONS"
  );
  // 允许的请求头（支持JSON、Token等）
  res.setHeader("Access-Control-Allow-Headers", "Content-Type, Authorization");

  // 处理OPTIONS预检请求（非简单请求必加）
  if (req.method === "OPTIONS") {
    return res.sendStatus(200); // 预检请求直接返回200，不进入业务路由
  }

  next(); // 非预检请求，继续执行后续中间件/路由
});

// 接口路由不变
app.use("/api/merchant", require("./routes/merchant"));
app.use("/api/service", require("./routes/service"));
app.use("/api/order", require("./routes/order"));

app.listen(8080, () => {
  console.log("服务器启动成功！http://localhost:8080");
});

3. CORS 的关键细节

预检请求（OPTIONS）：前端发送PUT/DELETE或带自定义头的请求时，浏览器会先发OPTIONS请求“探路”，后端必须正确响应才能触发真实请求；
Access-Control-Allow-Origin：生产环境需指定具体域名（如https://your-domain.com），而非通配符*（否则前端无法携带 Cookie/Token）；
简单请求豁免预检：GET/POST/HEAD请求且请求头仅含Accept/Content-Type等基础字段时，无需预检。

三、devServer 反向代理：前端开发环境的跨域捷径

虽然 CORS 能解决跨域，但开发阶段频繁修改后端配置效率低。Vue CLI 的devServer.proxy通过反向代理绕过浏览器跨域限制，是更优雅的开发方案。

1. 反向代理的工作原理

devServer.proxy让前端开发服务器充当“中间人”：

前端请求同源的开发服务器（如http://localhost:8081/api/merchant）；
开发服务器将请求转发给后端（http://localhost:8080/api/merchant）；
后端响应结果由开发服务器回传给前端。

整个过程中浏览器仅与同源的localhost:8081交互，自然不会触发跨域限制。

2. 前端配置源码解析（vue.config.js）

// web-admin/vue.config.js
module.exports = {
  devServer: {
    port: 8081, // 前端开发端口（避开后端8080端口冲突）
    open: true, // 启动后自动打开浏览器
    proxy: {
      "/api": {
        target: "http://localhost:8080", // 后端接口真实地址
        changeOrigin: true, // 模拟后端服务器的Origin（关键！避免后端跨域拦截）
        // pathRewrite: { "^/api": "" }, // 后端接口无/api前缀时启用（如后端是/merchant）
      },
    },
  },
};

3. 关键配置说明

target：后端接口的根地址；
changeOrigin: true：让后端误以为请求来自localhost:8080（同源），避免后端的跨域拦截逻辑；
pathRewrite：示例中注释掉是因为后端接口带/api前缀（如/api/merchant），若后端接口无/api，需通过此配置去掉前缀。

4. 踩坑实录：为什么去掉 CORS 仍报错？

很多开发者疑惑：“明明配了devServer.proxy，为什么后端去掉 CORS 还是报跨域错？”
核心原因是非简单请求的OPTIONS预检请求会被代理转发到后端，而后端未处理预检——哪怕前端用了代理，浏览器收到后端非法的预检响应后，仍会判定跨域失败。

（1）预检请求的“转发陷阱”

前端devServer.proxy会转发所有请求（包括OPTIONS预检请求）到后端。比如前端发送POST /api/merchant（带 JSON 数据，属于非简单请求）：

浏览器先发送OPTIONS /api/merchant到前端开发服务器（localhost:8081）；
开发服务器把这个OPTIONS请求转发到后端（localhost:8080/api/merchant）；
若后端没配置 CORS、也没手动处理OPTIONS，会返回无跨域响应头的默认响应（甚至 404）；
浏览器收到这个非法响应，直接抛出跨域错误，真实的POST请求根本不会发送。

你的后端代码（去掉cors且无预检处理）：

// 后端未处理OPTIONS预检请求
app.use(express.json());
// 无CORS配置，也无OPTIONS处理逻辑
app.use("/api/merchant", merchantRouder);

此时后端对OPTIONS请求的响应里没有Access-Control-Allow-Origin等头，浏览器自然判定跨域失败。

（2）开发环境最优解：保留代理+后端极简预检处理

所谓“后端无需配置 CORS”，并非完全不用处理跨域，而是不用依赖cors包，但需手动处理预检请求（仅需几行代码）：

const express = require("express");
const app = express();

app.use(express.json());

// 极简预检处理（开发环境够用）
app.use((req, res, next) => {
  // 允许前端源（开发环境可直接用*，生产环境需指定域名）
  res.setHeader("Access-Control-Allow-Origin", "*");
  // 允许的请求方法和头（覆盖非简单请求需求）
  res.setHeader(
    "Access-Control-Allow-Methods",
    "GET, POST, PUT, DELETE, OPTIONS"
  );
  res.setHeader("Access-Control-Allow-Headers", "Content-Type");

  // 拦截OPTIONS预检请求，直接返回200
  if (req.method === "OPTIONS") {
    return res.sendStatus(200);
  }
  next();
});

app.use("/api/merchant", merchantRouder);
// ...其他路由

app.listen(8080);

这样后端能合法响应预检请求，前端代理就能正常工作——既不用装cors包，也能避免跨域错误。

（3）简单请求的“例外情况”

如果前端只发简单请求（比如GET /api/merchant，无自定义头、无复杂数据），即使后端没处理预检，也可能成功：

简单请求不会触发OPTIONS预检，前端代理直接转发GET请求到后端；
后端返回数据给前端服务器，前端服务器再返回给浏览器（浏览器只看前端服务器的同源响应，不会校验后端的跨域头）。

但只要涉及POST（JSON 数据）、PUT/DELETE等非简单请求，必须处理预检，否则必报错。

四、Nginx 反向代理：生产环境的终极方案

devServer.proxy仅适用于开发环境，生产环境需用 Nginx 反向代理——既能解决跨域，又能优化资源加载和接口转发，是前端部署的标配。

1. Nginx 反向代理的优势

统一域名：将前端静态资源和后端接口代理到同一域名下（如https://your-domain.com）；
性能优化：支持缓存、压缩、负载均衡；
安全防护：隐藏后端真实地址，降低攻击风险。

2. Nginx 配置示例

# nginx.conf 或 conf.d/your-project.conf
server {
    listen 80; # 监听80端口（HTTP）
    server_name your-domain.com; # 生产环境域名

    # 前端静态资源配置（Vue打包后的dist目录）
    location / {
        root /usr/share/nginx/html/your-project; # 前端dist目录路径
        index index.html index.htm; # 默认首页
        try_files $uri $uri/ /index.html; # 解决Vue History路由刷新404问题
    }

    # 后端接口反向代理
    location /api {
        proxy_pass http://localhost:8080; # 转发到后端服务地址
        proxy_set_header Host $host; # 传递请求主机名
        proxy_set_header X-Real-IP $remote_addr; # 传递客户端真实IP
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # 传递代理链IP
    }
}

3. HTTPS 配置（生产环境必加）

若需支持 HTTPS，只需添加 SSL 证书配置：

server {
    listen 443 ssl;
    server_name your-domain.com;

    # SSL证书路径
    ssl_certificate /etc/nginx/ssl/your-domain.crt;
    ssl_certificate_key /etc/nginx/ssl/your-domain.key;

    # 前端静态资源+接口代理配置同上...
}

五、总结

开发环境：优先使用devServer.proxy反向代理，无需频繁修改后端配置；
生产环境：推荐 Nginx 反向代理（统一域名+性能优化），或后端配置 CORS（不常用，这算黑魔法）；
CORS 核心：处理预检请求+设置正确的响应头；
反向代理核心：让前端请求同源地址，由代理服务器转发到后端。

结合源码理解这两种方案，跨域问题就能迎刃而解！

项目开发 on acye's blog

CSS小案例，讲布局（Flex+Grid）

从新闻页面 CSS+成果图看布局设计：实用 Flex 与结构化布局技巧

一、布局基础：全局样式与容器搭建（成果图整体框架）

对应成果图的效果：

二、核心布局：Flex 的灵活运用（成果图主次分栏+内容排列）

1. 主次分栏布局（成果图左+右区域）

对应成果图的效果：

2. 单图新闻布局（成果图“2024 高考倒计时”那条）

对应成果图的效果：

3. 多图新闻布局（成果图第三条新闻的三个图）

对应成果图的效果：

4. 热搜榜单布局（成果图右侧列表）

对应成果图的效果：

三、布局设计的核心思路总结（结合成果图）

如何将vue cli 写的前端文件转换为vite（详细板）

从 Vue CLI 迁移到 Vite 的完整指南

📋 迁移概览

🗺️ 迁移路线图

步骤 1：备份原有项目

步骤 2：删除旧配置文件

步骤 3：清理项目依赖

📝 详细步骤说明

1. 修改 package.json

2. 配置文件迁移

3. 环境变量处理

4. 请求配置文件修改

5. HTML 文件处理

6. 静态资源引用方式

7. 路径别名配置

🔧 常见问题解决

问题 1：CommonJS 模块报错

问题 2：process 变量报错

问题 3：CSS 预处理器错误

📦 完整迁移脚本

📊 迁移前后对比

🎯 迁移后的优势

📚 总结

跨域问题讲解

前言

一、问题背景：为什么会跨域？

二、CORS：后端主导的跨域解决方案

1. 方案 1：使用cors中间件（便捷高效）

2. 方案 2：手动配置 CORS（深入原理）

3. CORS 的关键细节

三、devServer 反向代理：前端开发环境的跨域捷径

1. 反向代理的工作原理

2. 前端配置源码解析（vue.config.js）

3. 关键配置说明

4. 踩坑实录：为什么去掉 CORS 仍报错？

（1）预检请求的“转发陷阱”

（2）开发环境最优解：保留代理+后端极简预检处理

（3）简单请求的“例外情况”

四、Nginx 反向代理：生产环境的终极方案

1. Nginx 反向代理的优势

2. Nginx 配置示例

3. HTTPS 配置（生产环境必加）

五、总结

1. 方案 1：使用`cors`中间件（便捷高效）