接口在命令行能调用，浏览器却拒绝读取结果，可能是跨域访问规则而不是服务器没启动。
本文使用ECMAScript 5.1 与浏览器 DOM，代码可放入独立演示页。JavaScript（脚本语言）的作用域、函数调用与事件调度，需要与浏览器提供的接口区分。本文主体使用当时已经可用的语法，不把语言版本和宿主环境混为一谈。
1. 从现象推到机制
同源由协议、主机和端口共同决定。某些跨域请求先发 OPTIONS 预检，服务器需明确允许相应来源、方法与请求头。浏览器的读取限制不等于接口具备身份认证，非浏览器客户端不受同样机制约束。
图中的四个节点分别表示来源判断、预检协商、真实请求、浏览器读取。顺着实线检查输入如何变成输出，再沿虚线核对反馈条件。图示表达的是本文讨论的关系，不是实测曲线或现场截图。
2. 最小实现与输入条件
在两个演示端口间发送请求，查看网络面板中的预检与实际请求。携带凭据时按规则使用具体来源，不能随意组合通配来源。
1
2
3
4
Origin -> compare scheme / host / port
OPTIONS -> allowed origin, method, headers
actual request -> authentication and business authorization
response -> browser checks access headers
先记录输入、调用位置与控制台结果，再逐个改变条件。事件和异步实验保留触发顺序，避免在生产页面执行带有未知副作用的调试代码。
3. 用对照区分原因
下表列出需要主动改变的条件。预期行为来自机制分析，复现时还需记录运行环境和原始输出，不能将预期当作已经测得的结果。
| 改变的条件 | 需要验证的行为 |
|---|---|
| 预检失败 | 业务请求可能根本未发送 |
| 实际接口返回四零一 | 应区分认证失败与跨域读取限制 |
| 用命令行调用正常 | 不能证明浏览器同源规则通过 |
对照 1：预检失败
业务请求可能根本未发送。观察时记录OPTIONS 的状态和响应头。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 2：实际接口返回四零一
应区分认证失败与跨域读取限制。观察时记录服务端日志与浏览器错误。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 3：用命令行调用正常
不能证明浏览器同源规则通过。观察时记录客户端类型与 Origin 头。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
4. 适用条件与取舍
跨域配置不是访问控制的替代品。允许来源应按真实入口设置，接口仍需鉴权、数据权限与必要的防伪请求措施。
一次正常运行只覆盖了这组输入。继续扩展前，应把上面的异常对照保留下来，尤其关注“用命令行调用正常”这一分支。后续方案若改变了图中任意一处依赖，原来的判断就要重新验证，不能仅凭界面相似或返回值相同沿用结论。
