没想到 2026 年，还要浪费大量时间在跨域问题上

跨域

开发

问题

159 replies • 2026-04-25 23:29:25 +08:00

1 2

❮

❯

101

lan894734188

4 days ago

所有跨科的问题时不时都会抬出来

102

xuanbg

4 days ago

跨域这个问题早就有比较成熟的解决方案了啊，一般情况下都碰不到了。所以，现在都 6202 年了，不知道跨域问题也正常。

103

ajax10086

4 days ago

如果前端是本地调接口发现的跨域，那确实该吐槽，现在大四的本科生都知道用 vite 或 webpack 解决跨域

104

yiqiao

4 days ago

@yakumo520 #4 当然是「*」啦#逃

105

LandCruiser

4 days ago

站里这么多人找不到工作，然后这种菜鸟还能找到工作？工资得多低啊

106

dengji85

4 days ago

1

跨域算是前端该解决的问题。只是后端解决起来方便很多

107

KinBob

4 days ago

后端：我写的 rpc 接口，你问我跨域干什么？

108

kristofer

4 days ago

不理解这玩意有啥好吵的。

虽然我知道跨域这东西，但在比较正规的公司里，都不需要开发人员去搞吧，都有网关。

这玩意遇到了互相提一下，AI 问一下解决就行了，前后端合作的伙伴，至于这么互相仇视吗...

真牛逼遇到你老板不会东西，希望你也会去 diss

109

prosgtsr

4 days ago

跨域都 tm 成经验帖了，每次发就有人讨论到底是谁的问题。
楼上有人 #105 说的很对，“跨域算是前端该解决的问题。只是后端解决起来方便很多”

按照我的看法来说是，公司如果有人要我这个后端来解决跨域的话，我会给他解决，因为这样最快。实际情况下，很多前端是不懂的，很多时候都不是后端代码问题，而是网关问题，但是你指望一个前端开发去解决网关的问题，那还是算了，还不如我搞一下。

但如果你说这是后端的责任的话就搞笑了，明明是浏览器的行为，干我后端吊事，说是我的问题？

110

Ketteiron

4 days ago

@yuhangch 生产和开发的区别在于此时前端代码不是托管在 dev server ，而是 nginx/bff ，而要实现相同的效果，就要加配置

111

feikeq

4 days ago

首先跨域问题的本质是浏览器的同源策略，生产环境下的跨域，确实应该由后端通过配置 CORS 响应头来解决，这是标准做法。其次前端开发环境用代理解决跨域，只是开发阶段的临时方案，不能带到生产环境。

用“2026 年了还不懂跨域”来否定别人，本身就是一种傲慢的偏见。把沟通问题变成了对同事的公开嘲讽，自然会被大家吐槽。

112

yuhangch

4 days ago

@Ketteiron sorry 没看到已经部署了😂

113

nekochyan

4 days ago

不是，上面那些测试环境让前端自己本地配置代理是什么逻辑，只有前端一个人用测试环境吗？有没有可能产品、QA 也在用，你让他们也去本地配置代理？你看产品喷你后端就完不完事了

114

livelyyongheng1

4 days ago

还好吧，我做了好几年后端开发了，负责后端服务入口和网关还有用户权限啥的都有专门的团队，我就写好业务就完事了，完全不了解跨域是啥

115

isnullstring

4 days ago

2

你说的后端是除了前端，后面全算后端？

116

onedge

4 days ago

@programMrxu h 啊哈哈哈笑死我了

117

yungo8

4 days ago via Android

@isnullstring 因为很多公司一般要后端把运维给包了

118

HaibaraDP

4 days ago

哪里出的问题就得哪里解决，解决不了再找上面，前端和后端之间还有层网关呢，不是说后端经常除了页面开发外什么都得干就一定得后端干。真的搞不懂全栈这个词为什么和前端联系的多，页面加个 api 就叫全栈了？基础设施扬了？

119

RoccoShi

4 days ago

正经项目不都有 gateway 么

120

yyzcl

4 days ago

1

看了上面的回复，怪不得 2026 还要浪费时间在跨域上。
跨域的原因可以去搜 cors 。
解决的本质就是修改请求的「响应头」，添加一些参数，那么谁能动响应头？
1.后端（只不过现在基本不在后端直接处理响应头
2.运维（改 nginx 啥的
3.前端（只局限于本地开发环境，本质就是在页面和后端直接加了一个本地 node 服务器进行请求转发，在这里处理了响应头

一旦前端页面上线了，不管是测试还是生产环境，前端都无能为力

121

PromiseResolve

4 days ago

@xd666888 前端打包发布到服务器后，配置代理这个活，要说不归前端管也确实可以这么说

122

dtdths1

4 days ago

挺多纯后端还真不懂这个，因为这是浏览器的行为。一般谁有权限改 nginx 就找谁，稍微正规点的都有网关运维

123

itechify

PRO

4 days ago

服务器给你，后端代码给你，你来啊，bb 的真的是。

我最近就遇到过很诡异的，页面能展示，下载就报错，你觉得问题出在哪里？

技术栈：aws s3 ，配置了跨域域名，method ，header 。用了 cloudfront 做 cdn ，加了单独的域名 cname 到 cloudfront 。

你觉得问题出在哪个环节，处理问题的指责到底是后端 crud 开发还是运维？

124

tuomasi

4 days ago

猪养肥了再裁呗，一个人负责一个功能或者多个功能是大势所趋，还搞前后端联调或者产品研发分开的后面全会被 ai 替代，

125

SpiritQAQ

4 days ago

穿越了...以后作为年经贴一年来一次吧，下个时代也能找找当年的感觉

126

go522000

4 days ago

全栈，前后端全包就不用年年吵这个了。

127

nianyu

4 days ago

@Cenat 这都能谈上优越，LZ 说了跨域截图发给后端它看不懂你能在这扯运维

128

brsyrockss

4 days ago

@YanSeven 放心你这种二五仔肯定第一个被宰了

129

QS0x01

4 days ago

@yhxx 请求 www.taobao.com/api/xxyyzz 代理转发到 api.taobao.com/xxyyzz 不就行了，哪里不能代理？

130

BenHunDun

4 days ago

我感觉如果框一下，然后说是跨域问题，后端那么说有问题。不然有时候真不懂要表达什么。
剩下的就看项目的架构到底是如何的了。

131

chenluo0429

4 days ago via Android

@itechify 猜一猜，ing 标签加载图片实际上是可以非同源 no-cors 的，这时候资源被缓存了。fetch 拉取不行，就直接跨域了

132

sampeng

4 days ago via iPhone

AI 淘汰的人还是太少了

133

wangtian2020

4 days ago

上班好几年才知道，公司里菜逼是占多数的
直接让他去 AI 自己查跨域怎么解决，有些菜逼一教他就脾气爆炸，让他自己问 AI 才管用

134

Lockroach

4 days ago

2026 了，讨论跨域的 post 还有这么多讨论🥲新鲜血液太多了

135

lg487

4 days ago

@yuanxiaosong 小公司没有运维，后端兼职运维

136

ca2oh4

4 days ago

或许 op 的公司需要一个网关代理

137

abolast

4 days ago

@giter 跨域是 http 规范被反复提及的，http 规范是任何方向的程序员都该通晓的，不能说没遇到过不会就可以理解

@lscho 你说响应头都是运维来设置？那运维要如何精细化控制允许白名单？我认为不合适在反代层面写太复杂的逻辑。说句不好听的，nginx 现在支持 lua 和 js 了，前后端的代码层面工作交给运维配置的 nginx 的 lua/js 来实现也可以的，就是不合适。反代层面必需要简洁高效率和耦合性低

138

abolast

4 days ago

@wysnxzm 一切能参与到 http 协议的环境都能定义响应头，谁合适的问题了，我是不赞成在运维层面配置的，不合适。说真的，写教程教所有用户在浏览器层面实现修改响应头，也是可行的，但是不合适

139

aino

4 days ago

1

跨域是个好东西，保护用的

140

abolast

4 days ago

@yuanxiaosong 问一个问题，你们公司有精细化管理允许跨域的意识么？我认为应该最小化权限配置允许跨域，这就应该由具体功能的实现者来做了。如果是不懂业务的其他技术人员，只能用通配符了。但是不应该用通配符的。

141

lscho

4 days ago

@abolast 有运维的公司大概率都是容器化、微服务这一套了，当然是在网关配置啊。。。。运维的意义就是打通开发、测试、上线、监控报警这一套东西。正经公司别说响应头是运维配置的，就是 host 和路由都是运维做的。前后端专注业务开发就完事了。

142

rahuahua

4 days ago

说个另外一个事，之前我们接口一直没有开启 gzip 压缩，开启后发现客户端没法正确解压缩，我让客户端去解决，给我说解决了。后面我去复查才发现客户端把 content-encoding header 给移除了。

143

HQKM

4 days ago

我是很讨厌那种只发给截图啥都不说，要你去猜的。你这么在意时间就不会把问题和解决方案的关键词甩过去。

144

abolast

4 days ago

@lscho 我想问，你们运维是如何获取哪个某个接口会给哪个前端使用这个信息的，如果能获取到，那就是下一个问题，如果网关是 nginx/caddy/haproxy 这些来实现的话，我是不建议在运维层面写逻辑的，如果是其他实现的话可能是我见知少我不怎么清楚。我的主要思想是没有必需是谁来做，重要的是谁来做最合适。

145

lscho

4 days ago

1

@abolast 怎么就我们运维了？我不是运维。。。你是不是没做过微服务、k8s 、云原生这种项目（没别的意思，就是单纯的问一下）

至于你问运维是怎么知道的，当然是开发前就定好了啊，开发文档又不是只给前后端看的。

单体应用确实没必要运维层面写逻辑，但是云原生肯定要写逻辑了啊，要不然怎么做流量调度、故障隔离、监控报警之类的东西啊。

话说回到跨域上，稍微大点的项目，可能一个前端页面会调用不同的后端服务，这些后端服务不会来自于一个后端工程师，甚至不会来自于一个团队。你说这种情况下，是不是只有运维来处理最合适？

146

abolast

4 days ago

@lscho 只能说我司的前后端水平太低，我是带不动使用微服务和 k8s(中小公司老项目用不上，我也没用过，不过这种我不认为有什么难度)，不过云容器化这种在新项目我倒是在推进，不过进度缓慢，容器是新技术(十几年前的东西了)他们很难接受。所以我还是摸鱼写自己的项目吧，能给我们运维环境用，也能顺手开源，这就是我的一个个孩子。