diff --git "a/src/content/blog/\344\273\212\345\244\251,\346\210\221\347\273\210\344\272\216\346\220\236\346\207\202\344\272\206\350\267\250\345\237\237.md" "b/src/content/blog/\344\273\212\345\244\251,\346\210\221\347\273\210\344\272\216\346\220\236\346\207\202\344\272\206\350\267\250\345\237\237.md"
new file mode 100644
index 0000000..1d01191
--- /dev/null
+++ "b/src/content/blog/\344\273\212\345\244\251,\346\210\221\347\273\210\344\272\216\346\220\236\346\207\202\344\272\206\350\267\250\345\237\237.md"
@@ -0,0 +1,82 @@
+
+## 跨域请求是什么？
+
+跨域请求（Cross-Origin Resource Sharing, CORS）是指从一个域名的网页去请求另一个域名资源的行为。这包括协议、域名或端口的差异。
+
+## 为什么要这么设计？
+
+这种设计基于浏览器的同源策略，主要是为了安全性。同源策略确保一个源的文档或脚本在没有明确授权的情况下无法读取或操作另一个源的资源。这有助于保护用户免受数据盗窃等网络攻击。
+
+## 它是为了避免什么情况？
+
+同源策略主要是为了避免恶意网站窃取敏感数据（如Cookies、Session等），并通过模拟用户的操作来攻击另一个网站，这类攻击称为跨站点请求伪造（CSRF）。
+
+## 为什么它不能规避发送请求到攻击者的服务器上的问题？
+
+同源策略不能阻止从一个网站向另一个网站发送HTTP请求。例如，恶意脚本可以向第三方服务器发送用户数据，特别是当该服务器设置允许所有来源的CORS策略时。
+
+## 我们应该怎么做来解决跨域问题？
+
+在处理跨域问题时，可以采取以下策略：
+
+- **服务器设置CORS头**：服务器可以通过设置CORS响应头来明确允许某些或所有域名访问特定资源。
+- **使用代理服务器**：在开发和生产环境中配置反向代理，将请求从一个域名转发到另一个，同时改变请求的源。
+
+## 在前端开发中怎么解决？
+
+在开发环境中，通常使用如Vite或Webpack等工具配置开发服务器，通过代理设置将API请求转发到后端服务器，绕过浏览器的同源策略限制。
+
+## 在生产环境中怎么解决？
+
+在生产环境中，可以使用Nginx或其他Web服务器作为反向代理，将前端应用和后端API的请求统一到同一个域名和端口下。同时配置CORS响应头来控制允许的请求源，增强应用的安全性。
+
+## 反向代理如何解决跨域问题？
+
+反向代理可以解决跨域问题，因为它允许将来自客户端的请求中继到一个或多个服务器，并将响应返回给客户端。从客户端的视角看，所有请求都似乎来自同一个源（即代理服务器）。这样，原本涉及不同源的请求就可以绕过浏览器的同源策略限制。
+
+## 分析Vite配置
+
+以下是一段Vite配置代码，涵盖了几个重要的服务器设置部分：
+
+```javascript
+server: {
+  port: 4000,
+  host: '0.0.0.0',
+  // open: true,
+  proxy: {
+    '/api': {
+      target: 'http://124.221.130.112:5002',
+      changeOrigin: true,
+      rewrite: (path) => path.replace('/api/', '/'),
+    },
+  },
+  headers: {
+    'Access-Control-Allow-Origin': '*',
+  },
+},
+```
+
+### 代理细节 (`/api` 代理设置)
+
+#### 功能
+
+- **目的**：代理的主要目的是让开发环境中的前端应用能够透明地与后端API进行交互，尤其是当后端API部署在不同的服务器或域时。
+- **工作流程**：当前端应用尝试访问`/api`路径时，Vite服务器会接收这些请求，并根据配置将它们转发到指定的`target` URL。这样做的好处是，前端开发者无需修改本地代码即可测试与实际后端服务的交互。
+
+#### 为何选择`changeOrigin`？
+
+- **改变来源**：`changeOrigin: true`这一设置是为了确保请求头中的`host`字段被改为目标服务器的host。这对于一些校验请求来源Host的后端服务来说是必需的，因为它可以使请求看起来像是直接发至目标服务器，从而绕过对源的检查。
+
+#### 路径重写的作用
+
+- **去除API前缀**：通过`rewrite`函数，`/api/example`会被重写为`/example`。这意味着开发中的前端应用无需调整API请求路径就可以直接对接部署后的后端路径。
+
+### CORS配置细节
+
+#### 功能
+
+- **开放跨域访问**：在开发阶段，由于前后端分离的开发模式，前端应用经常需要从不同的端口（或可能的不同域）访问到开发服务器。设置`'Access-Control-Allow-Origin': '*'`确保了所有的跨源请求都被接受。
+
+#### 安全考虑
+
+- **开发环境中的宽松策略**：在生产环境中，通常不建议使用`'*'`这样的宽松CORS策略，因为这可以允许任何网站请求数据。但在开发环境下，使用`'*'`可以简化配置并避免跨域错误，提高开发效率。