浏览器说跨域失败，服务器就一定没收到吗？

对普通 HTTP 地址，同源比较涉及协议、主机和端口。本例主机与协议相同，但程序为页面和 API 分配两个不同端口，因此跨源。浏览器通常不允许页面脚本直接读取另一个源的响应，需要由响应中的 CORS 头说明是否共享；这个机制叫跨源资源共享。

“页面脚本可以读响应”与“服务端愿意处理这次业务”是不同判断。CORS 不能代替登录、对象权限与业务校验，也不能把来自任意客户端的请求都挡在服务器外。命令行 HTTP 客户端一般不替浏览器执行这套读取限制，因此命令行能拿到正文，并不能证明页面调用也能成功。

下载本篇练习包，解压后在 cors_local.py 所在目录运行 python cors_local.py。终端会打印页面地址和 API 地址；端口由系统选择，每次启动可能不同。用浏览器打开打印的页面地址，不要直接把源码另存成文件后用 file 地址打开，否则实验前提已经变化。

每次点击都会生成新的试验编号，页面显示浏览器结果、API 收到的方法和模拟写入次数；终端按同一编号打印记录。页面随后通过自己的同源 /state 接口读取观察记录，避开被研究的跨源响应限制。favicon、页面加载和观察查询不计入 API 写入，避免把无关请求算成结果。

点击“普通 POST：响应不共享”。它用 POST、text/plain 和短文本，没有额外自定义请求头，也不携带凭据。在本例的条件下，浏览器可以直接发送实际请求，无需先做 CORS 预检。API 收到后增加一次模拟写入，并返回 200，却故意不提供允许共享的响应头。

预期页面报告无法读取响应，但同编号记录包含 POST，模拟写入次数为一。这证明的是本机假服务记录过这次效果，不是任何真实订单已经入库。若拿同类页面错误当成“服务端肯定没做事”的证据，自动换一个业务编号重试，就可能制造重复效果；真实系统应另有结果查询和重试约定。

点击“JSON POST：预检不放行”。本次仍然是 POST，但显式使用 application/json，这不在本例无需预检的 Content-Type 范围里。浏览器先向目标地址发 OPTIONS，带上准备使用的方法及请求头信息，让服务器表明是否接受这种跨源调用。预检不是业务提交，不应在它里面执行保存。

假服务对 OPTIONS 返回 204，却没有给出 CORS 允许头。状态码看起来成功仍不够：预检需要满足跨源检查。预期同编号仅记录 OPTIONS，模拟写入次数为零，浏览器也报告无法读取。它与第一种错误文案可能相似，但方法记录说明二者停在不同阶段；不能只靠一个 TypeError 判断服务端发生了什么。

点击“JSON POST：预检与响应都放行”。这条路径只为本次页面的准确源返回 Access-Control-Allow-Origin，并声明 POST 与 Content-Type 可用于调用。实际 POST 的响应同样带允许共享的头，所以页面能够读出 200 和 stored=true。预期记录先有 OPTIONS，再有 POST，模拟写入一次。

只给 OPTIONS 加头还不够，后面的实际响应也要通过 CORS 检查。项目为每次试验换新编号并关闭预检缓存的保存时长，便于观察；真实浏览器可能复用有效的预检结果，所以没看到新的 OPTIONS，不能独立证明没有走过预检策略。本例主动省略凭据，不讨论 Cookie、第三方 Cookie 政策或带凭据的通配符规则。

验收时为三个按钮各保存一次独立编号，记录脚本可否读取、API 方法序列和效果数。需要解释具体拒绝原因时查看浏览器控制台与网络面板；脚本捕获到的错误通常不包含完整的 CORS 诊断。如果三个按钮全都失败，先检查服务是否仍运行、地址是否来自本次启动，以及本机浏览器策略，不要修改预期来迁就现象。

本篇在 2026 年 10 月 13 日通过 Codex 内置的 Chromium 浏览器实际点击了三条路径，观察到前两条脚本报错、第三条读到正文，以及一、零、一的模拟效果数；同编号方法记录与预期一致。这份记录仅支持该次本机浏览器与假服务的组合，没有覆盖所有浏览器，也没有测试任何真实保存接口。

实验只研究两个本机源之间的 fetch 行为，没有 HTTPS、代理、重定向、身份认证和持久业务。Python 的 http.server 也不是生产服务器模板。结束后回终端按 Ctrl+C，两个端口关闭，内存记录消失。正式接口应独立检查身份与业务权限；CORS 负责浏览器如何共享响应，无法替这些检查收尾。