1

3

还有这么菜的开发吗，这种还能混下去真幸福啊

3

12

菜鸡互啄

4

想知道后续那个后端怎么处理的跨域（狗头）

5

你别说 如果是 server 开发来顶替 web 开发
确实很多浏览器的行为不是很清楚

6

虽然我觉得很菜，但是部分螺丝钉企业还这能理解。。。因为跨域本身是浏览器的行为，如果部署的时候再用容器化技术，响应头都是运维来设置，开发测试的时候前端再用个反代，后端没接触过也正常

7

8

前端自己配个代理不就完事了么。自己解决就没那多 b 事了。

8

如果是纯后端，没有深度理解跨域也很正常，感觉很多跨域问题的帖子都是前端开发提出来的

9

12

13

2

这个为啥要截图发给后端开发？为什么部署到测试环境才发现跨域？不是开发环境就应该知道跨域了并通过 dev server proxy 解决了？测试生产配个 ng 反代自己解决就是了。你还心累上了🤪

17

add_header Access-Control-Allow-Origin *;
add_header Access-Control-Allow-Headers *;
add_header Access-Control-Allow-Methods *;

18

4

@Cruzz 然后上生产还是跨域，哥两一起加班

19

从描述上无法判断楼主是后端还是前端

20

9

才十几个回复就有好几个不懂的了，跨域问题让前端配代理🤣。
AI 淘汰的人还是太少了。

21

这玩意对于 AI 就 1 分钟解决的事情。。

25

正确方法是前端配置代理+后端配置 nginx 转发解决跨域。所以这不是前后端两个人的问题么

26

@Garwih 测试环境本地 hosts 写个转发，本地 nginx 监听，转发的时候强行加个头，咋不行了，又不是发布环境，如果后端真不懂，你等他搞还真不如本地转发下

28

3

29

30

接口部署到了测试环境你不应该在本地代理测试环境或者也发到测试环境吗

31

1

@ARIInV2 #16 上纲上线来说，这是测试环境，如果你用测试环境页面访问测试环境接口跨域，找后端，找运维都没问题，自己本地连测试环境接口跨域不很正常，不解决不也正常？不上纲上线，你都说了他菜，费半天劲解决不了，浪费时间浪费精力，自己反代一下很困难么，不会就别说人家菜了。最烦 bb 赖赖的。越菜的 b 话越多。

33

2

- 如果你的应用本身只是小应用，用的人不多，那么你用「 BFF/反向代理」简易搭一个都没问题
- 但是如果你的应用相对比较大，复杂度比较高，我觉得还是应该老老实实配置 CORS ，多一层「 BFF/反向代理」反而会带来很多麻烦，包括性能、成本，还有「代理」本身还需要监控、管理，错误排查链路更复杂，SSE 之类支持更复杂等，除非你真的需要「 BFF 」，不然的话，加多一个实体就是加多一层麻烦。

34

@Cruzz 配代理如果出了问题，会说你为什么配代理，导致安全扫描 balabala 有问题。还是得后端自己启动，前端不管，后端想办法去

35

合久必分，分久必合

36

1

另外，测试环境跟生产环境有架构上的差异会导致测试环境丢失很多它原来能起到的作用。

37

这玩意不都是运维搞吗，运维会在 nginx 处拦截，判断是否是公司域名或者白名单域名，使用“add_header Access-Control-Allow-Origin 请求域名;”设置跨域，并且还要使用"proxy_hide_header Access-Control-Allow-Origin;"隐藏后端返回的跨域，防止双重跨域并且禁止使用*设置跨域值。

38

13

要么一直做前后端同源的项目
要么大公司出来的，这种事情有 SRE 来负责
要么做的项目 nginx 反代 cors 配置都是别人弄好了 不需要他关心
我也不知道楼里在优越什么。。。

39

日常前端吐槽后端不懂 CORS

40

3

@sagnitude
@andyskaura
@lscho #28 楼主都说了上测试环境了，明显开发环境已经配了反向代理。测试环境还让前端用 vite/webpack 配代理就是完全不懂 CORS 。作为 Web 后端不懂 CORS ，要么就是纯螺丝钉，工作过的公司都是运维弄好。要么就是菜了。

41

正式、开发和测试环境跨域由运维配置，前端本地联调两个方案：
1. 让运维把 localhost/127.0.0.1 加白名单；
2. 前端自己启动一个 nginx 再反代；
如果公司有明确的运维，除非你直接调用后端服务，不走任何代理，否则跨域不该后端管（我司后端在代码中手动写跨域也不生效），后端兼管反代程序的另算；

42

@X0V0X #18 可能他们不需要上生产、也不需要发测试，本地写好就可以了。请访问 http://localhost:5173

43

@Cenat 正解，很多人以为自己遇到过跨域问题并且解决了跨域问题，就想当然以为别家公司也有很多人应该懂，从来没去考虑过为啥很多人都不懂，难道大家伙天天都要面对跨域这个问题吗？有些操作后端开发其实都不需要处理的，不懂也正常，不要简单套用自己的规则强加给别的开发

44

2

46

@Garwih #40 你的主题已经飘了，以及，跨域问题你聊到反向代理，vite/webpack ，有一定联系，但还是很奇怪，不太确定。 建议你多回复几条大家再看看

47

1

48

标准方案就是前端自己配代理服务，前端既然要搞工程化就要解决这种问题，后端不仅不用帮你解决跨域而且还要限制死，毕竟这是运维的事

49

后端能解决,前端也能解决,看谁去解决

50

前后端互相看不起，那看看谁先被 AI 淘汰咯

51

@lscho #28 有时候感觉前端挺迷惑的，本来专心写写页面改改样式就好了，数据就让前后端联调，他们非要搞一套工程化，一上来就安装各种服务各种包，越搞越复杂，但是稍微涉及到点原理的他们又理解不了

52

@Cruzz #31 上纲上线来说，测试环境出的问题不解决，反而取巧，正式仍然会出问题。

54

不知道为什么很多人有优越感 很多大公司大项目复杂度高 有专门一个团队来做 项目部署上线 服务器管理与交互
一般开发者不懂不是很正常 还是说大家都是做小项目全栈一把梭？没有任何分工？

58

59

vue dev server 的 proxy 不就完事了，大家在聊啥啊

60

搞了半天还是要运维去解决，吐槽后端干什么呢，后端有权限修改 nginx 解决？

61

2

@andyskaura #46 开发环境用 vite/webpack 配置 proxy 就是本地 node.js 开发服务器的反向代理。
部署到测试环境之前，要么用 CI/CD 工具自动化打包，要么前端手动打包，最后提交到测试服务器只会有静态文件。
楼上很多让前端在测试环境配置代理的，至少一大半都觉得前端可以用 vite/webpack 配置来解决这个问题。什么草台班子会在测试服务器安装 vite/webpack 还启动开发服务器做代理？
Web 后端在纯螺丝钉的工作流程中，有运维处理这种问题，没配过可以理解。但是工作多年多多少少会遇到过这种问题，连跨域报错都看不懂，这是一个合格的 Web 后端？

62

这东西不是在 nginx 里反向代理，转发请求给到后端服务？后端服务看看是不是监听在 0.0.0.0.问题在于 nginx 在哪里配置的问题罢了。

64

看了下时间，确实是 2026 年

66

@Garwih #61 不好意思 刚刚戾气重，先道个歉。
你说的这种场景下确实不应该前端配，毕竟和前端没关系了。
但 op 说的是接口部署到测试环境，理解上有偏差。
最后 我支持你的观点，专职 web 的后端必须要理解跨域。

67

1

直接上 BFF 算了，给那帮菜鸡擦屁股又不是一次两次了。都 2026 年了，还以为前端完全不懂后端，就能把锅全给前端是吧

68

你这话说的, 那 claude 把源代码打包 push 上去的,算什么,还两次,低频次的问题花点时间解决有什么问题吗? 又不是每天都能遇到跨域问题,可能职业生涯也就能遇到 2,3 次需要后端自己解决配置跨域

71

72

俺一直不理解，不是前端早就可以全栈了吗，难道用 nodejs 转发下请求都不行吗

73

这不是 nginx 上配置一下就可以了么？我们当时是这样操作

74

这不应该由前端自己解决吗，开发有 vite 生产有 nginx ，不然后端天天改白名单。

75

在大厂，其实我也至今不知道怎么解决跨域。因为前端到我具体服务后端套了 n 层服务和网关，我也不知道中间哪一层拦截的，找谁或者找哪个服务配置，或者具体怎么配置

76

前端眼里的后端：产品+运维+后端，深有体会

77

我们公司的前段连 nginx 配置都不懂

78

看了这个帖子，唉

80

1

81

9

82

顶楼上，不知道大量是多大量

85

后端真难。要懂运维，要做 dba ，甚至还要做 ba 。 不会一种就是菜。 为啥前端没试过自己去尝试？我们公司部署前端都要后端来，也没说过他们这都不懂。 本地代理能解决的自己解决，线上我觉得开放全部或者指定域名也不是两个开发拍个脑袋能决定的。 你自己也可以去配 nginx 代理，为什么默认这是后端的工作呢

86

如果是额外加了 header 导致跨域，你给我个截图 我问你什么报错的意思大概是要你复制文字吧

87

这个问题，一般是 infra 网管层去解决，既然提了这个问题，那估计直连后端 server 了。

89

1

本人后端，api server 从来不会去设置和配置跨域等相关配置。为什么呢，因为 api server 压根不会直接暴露给前端，而是通过网关（简单点的可能是 nginx ）转发过去的，所以跨域这一层，肯定是网关上配置的。优先权限级别低的后端，压根不了解网关这一层该怎么处理。所以嘛，都是草台班子。

90

明明是浏览器的问题，关我后端批屁事？ /s

91

CORS 应该是运维解决的问题吧？

93

一个简单问题炸出来这么多自以为是的人

94

我呆过的这种问题都是 infra 解决，不是业务后端该考虑的

95

5

熟悉了 v 站回来了，比那些家庭类、情感类、选车类的破贴有意思多了

96

不理解，一个跨域为什么需要浪费大量时间

97

后端：我用 Postman 测过了，接口完全正常。前端怎么还能出错？真的水，难怪说前端娱乐圈。
前端：奶奶滴，要不是你们不搞跨域，我完全可以用代理解决啊。但这代理一搭，后面又出各种问题，天天踩坑，谁受得了？

98

直接 chrome --disable-web-security

99

1

公司里不会跨域的后端现在送外卖可溜了，一送一个不吱声

100

1

CORS （跨域资源共享）是浏览器的安全限制，不是后端拦截了你，而是浏览器拦截了后端的响应，不交给前端。
解决方案有三个:后端声明;前端代理;运维反代
无脑把问题甩给后端那就是纯菜鸡