wheelg

打错了，是 @mixin.one 发送不了

[email protected] 邮箱似乎发送不了邮件

有什么经验要求吗？

看了各位的回答后，我的理解是这样的：

浏览器在设计之初并没有一个很好的身份认证手段，于是采用了 cookie 用作身份认证，为了鉴定用户身份，浏览器不得不每次发送请求时都带上请求网站的 cookie ，因此为了考虑兼容性，不能阻止`a.com`向`b.com`发送请求时带上`b.com`的 cookie 。

所以为了避免恶意网站利用这个 cookie ，对于非同源请求，浏览器选择了先向服务器询问`a.com`是不是可信任的（ OPTIONS 预检），得到确认后才会向服务器发送真正的请求，也就是同源策略。

如今大部分本地应用采用的是 jwt 方式保存登录信息，因此也就避免了浏览器 cookie 的漏洞，所以不需要同源策略，虽然现在的网页也可以使用 jwt 方式认证，但是为了兼容性，浏览器依然需要使用原有的 cookie 发送策略，才会有同源策略这一限制。

那么以后会不会出现某种新的浏览器 API ，使用此 API 时可以抛弃原有的 cookie 策略，允许开发者自由访问其他域名的请求呢？

@pursuer 有一定的道理，不知道如果以后添加 pwa 也可以被视为“用户知道自己在做什么”的话，会不会取消一定程度的同源限制，postman pwa 版多好啊

真极简还得看这个 https://glink25.github.io ，基于 vitepress 的，简得不能再简

各位可以换个角度想想这个问题，为什么浏览器对网页的限制要比操作系统对本地应用的限制要多得多？

理论上来说，本地应用能获取到的信息、对用户系统的危害远大于网页，为什么反而是浏览器的安全措施更严格（特指网络请求方面）？仅仅是因为本地应用需要下载安装这个步骤比较麻烦吗？那如果以后应用体积越来越小，例如 App Clip 和安卓快应用这类轻量的应用也需要收到类似同源策略的限制吗？

还是说，因为浏览器本身的历史原因，它无法做到和本地应用一样的安全性，才不得已选择了同源策略这种较为严格的手段呢？

@jiangzm 换个角度想想，为什么操作系统没有对本地应用程序设置类似同源策略的限制，目前的 web 应用已经基本上可以做到和本地应用一样的登录认证逻辑了吧，那为什么浏览器要格外严格呢？
如果我在我的应用程序代码里也嵌入了很多其他网站的请求，这是不是也属于非预期请求呢？浏览器对网页如此严格的限制看起来还是有其他的原因在

@lscho 第二个解释里，浏览器如果不能代替网站提供商做决定的话，就更不需要如此严厉的同源策略才对，应该把这些东西都交给 js 去控制，这不是更好吗？