Adquira o hábito de escrever juntos! Este é o 4º dia da minha participação no "Nuggets Daily New Plan·April Update Challenge", clique para ver os detalhes do evento .
1. Plano recomendado (produtos secos)
Sabemos que devido à limitação da política de mesma origem do navegador , o front-end terá problemas entre domínios ao enviar solicitações para a interface de back-end. Existem várias soluções na Internet. Aqui estão as duas soluções mais comuns em desenvolvimento. . Não há muito a dizer, vá direto para os produtos secos.
Plano recomendado:
| ambiente de desenvolvimento | Ambiente de produção |
|---|---|
| Configurar CORS no servidor | Configurar CORS no servidor |
| Configure um servidor proxy de desenvolvimento, como vite-server.proxy | Configure um proxy de servidor de produção, como nginx |
二、O que é CORS?
O nome completo do CORS é Compartilhamento de Recursos de Origem Cruzada. Esta solução não tem carga de trabalho para o front-end, e não é diferente do método normal de escrita de requisições de envio Ajax. A carga de trabalho é basicamente no back-end (na verdade, não há carga de trabalho, basta configurar alguns protocolos HTTP).
Não vou explicar detalhadamente o princípio do CORS aqui, recomendo dois bons artigos para ajudar a compreendê-lo:
- Compartilhamento de recursos entre origens do MDN
- Explicação detalhada do CORS de compartilhamento de recursos entre domínios do log da Web de Ruan Yifeng
3. Proxy do servidor
Talvez alguns desenvolvedores de back-end sintam que configurar o CORS é problemático e não querem fazê-lo (recomenda-se que essas pessoas o arrastem ~ dog head.jpg), então existe uma solução para front-end puro.
No modo de desenvolvimento, você pode usar a função proxy (proxy) do servidor de desenvolvimento, como vite-server.proxy de vite .
Mas esse método não pode ser usado em um ambiente de produção . No ambiente de produção, o servidor de produção (como nginx, Apache, etc.) precisa ser configurado para proxy reverso . No entanto, o princípio de configuração de proxies em serviços locais e serviços de produção é o mesmo: construindo um servidor de retransmissão para encaminhar solicitações para evitar problemas entre domínios.
简单说明一下上面这个图你就能理解了。既然浏览器页面直接请求接口服务有同源策略的限制，那么我们可以想到这样一种方式：让浏览器页面请求本地开发服务器(生产服务器)，再让开发/生产服务器去请求真实的接口服务，这样不就绕过了浏览器同源策略的限制了吗？也就是说，开发/生产服务器其实就是一个中转站，将真实接口响应回的数据再发送给客户端。
之所以可以这样做是因为同源策略是浏览器才有的，而服务器与服务器之间的请求不存在跨域限制。
四、在vite项目中配置服务器代理
我们以vite创建的一个vue项目的配置为例说明一下,初始工程结构如下:
我们再在src/utils目录下创建一个发送ajax请求的文件request.js
然后我们在App.vue中引入request.js并写一个简单的事例向http://localhost:4567/api/userInfo 发送请求（注意此时还没有在vite.config.js中配置代理）
用express简单写一个后端服务,运行nodemon app.js把服务开启在4567端口
然后执行命令npm run dev,运行前端项目,发现浏览器报错：
原因是在没有配置代理之前，浏览器默认是向开发服务器也就是http://localhost:3000/api/userInfo发送请求了,但是开发服务器是没有这个接口的，真实的接口是在localhost:4567上，因此需要在vite.config.js这个文件中配置代理服务:
这样当浏览器发送以/api开头的请求时，开发服务器会向target(目标地址)转发请求，并且请求地址拼接为http://localhost:4567/api/userInfo,这样就能正常收到真实接口服务发送回的请求啦：
五、注意事项
A parte de código deste artigo demonstra apenas brevemente o encaminhamento de proxy no servidor de desenvolvimento, mas se o projeto for ficar online, ainda é necessário configurar o proxy do servidor de produção, como o nginx como proxy reverso, caso você precise aprender , você mesmo pode pesquisar no Google.