记得前阵子有个哥们儿找我，说前端页面死活调不通后端接口，报错全是红彤彤的 CORS 错误，急得跟热锅上的蚂蚁似的。他问我：“是不是浏览器又抽风了？”我直接泼他冷水：别赖浏览器，这锅前端背不动，得让后端来扛。
咱们干技术的都知道，同源策略是浏览器的安全底线，但也是开发者的噩梦。很多人一遇到跨域，第一反应是在前端搞各种骚操作，比如代理服务器、JSONP，或者干脆在浏览器装插件屏蔽安全限制。这路子走不通还容易埋雷。真正懂行的老鸟，早就把跨域问题甩给服务端去处理了。为什么？因为服务端做处理跨域，才是从根儿上解决问题，干净利落，不拖泥带水。
我就拿我自己最近折腾的一个项目举例吧。当时我们要对接一个第三方数据接口，域名完全不同，端口也不一样。前端同事试遍了各种 headers 配置，还是被浏览器拦截。最后我直接在 Node.js 的服务端加了个中间件，简单几行代码，问题迎刃而解。
具体咋弄？别整那些虚的，直接上干货。
第一步，确认你的后端框架支持 CORS 头设置。不管是 Java 的 Spring Boot，还是 Python 的 Django，或者是 Node 的 Express，都有现成的库或者原生支持。别自己手写 HTTP 响应头，容易漏字段，出 bug 找半天都找不到原因。
第二步，配置允许的源（Origin）。这一步最关键。别图省事直接写 * 通配符，虽然方便，但在涉及用户登录、Cookie 传递的场景下，浏览器会直接拒绝。你得明确指定哪些域名可以访问。比如，你的前端域名是 app.example.com，那就只允许这个域名。这样既安全，又符合规范。
第三步，处理预检请求（Preflight）。对于 PUT、DELETE 或者自定义 Header 的请求，浏览器会先发一个 OPTIONS 请求。如果你的后端没处理好这个 OPTIONS 响应，后面的正式请求根本发不出去。我在调试的时候，经常发现 OPTIONS 返回 403，导致后续请求全部失败。这时候，检查后端日志，确保 OPTIONS 请求返回 200，并且带上正确的 Access-Control-Allow-Headers 和 Access-Control-Allow-Methods。
第四步，凭证传递。如果接口需要携带 Cookie 或 Authorization 头，记得在前端设置 withCredentials: true，同时后端要返回 Access-Control-Allow-Credentials: true。注意，这时候 Origin 绝对不能是 *，必须指定具体域名。很多新人在这儿栽跟头，明明代码没错，就是传不过去，多半是这里没配对。
我见过太多团队，前端后端扯皮，前端说后端没开跨域，后端说前端没传 Header。其实，只要服务端把跨域处理做好了，前端只需要正常发请求，剩下的交给浏览器去验证。这种分工明确的方式，能省下大量调试时间。
当然，服务端做处理跨域也不是万能的。如果你的接口涉及敏感数据，或者需要严格的权限控制，还得配合 JWT 或 OAuth2 使用。跨域只是网络层面的问题，安全层面的事儿，还得另外下功夫。
总之，遇到跨域别慌，先看看后端配置。别在前端代码里打补丁，那样只会让代码越来越臃肿。让专业的人做专业的事，后端搞定跨域，前端专注业务逻辑，这才是高效开发的正道。下次再遇到 CORS 错误，先别急着改前端，去后端日志里瞅瞅，说不定问题就在那儿等着你呢。
