本教程详细探讨了php和javascript应用中常见的跨域资源共享（cors）错误及其解决方案。文章深入解析了cors机制，特别是预检请求（options）的处理，并提供了专业的php后端配置示例，指导开发者如何正确设置access-control-allow-origin、access-control-allow-methods等http头，以确保前端javascript能够安全、顺畅地与后端api进行跨域通信。
理解跨域资源共享（CORS）
在Web开发中，浏览器的同源策略（Same-Origin Policy）是一项重要的安全机制，它限制了来自一个源的文档或脚本如何与来自另一个源的资源进行交互。当前端JavaScript代码（例如运行在http://example.com）尝试向不同源（例如http://api.example.com或https://another-domain.com）的后端API发送请求时，浏览器会触发跨域限制，导致请求被阻止，出现“Cross-Origin Request Blocked”错误。
跨域资源共享（CORS）机制正是为了解决这一问题而设计的。它允许服务器声明哪些源被授权访问其资源。当浏览器检测到跨域请求时，它会向服务器发送一个特殊的请求（通常是预检请求），以获取服务器的CORS策略。如果策略允许，浏览器才会发送实际的请求。
常见的CORS错误与预检请求
当您遇到“Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource... (Reason: CORS request did not succeed). Status code: (null).”这类错误时，通常意味着以下两种情况之一：
- 服务器未发送正确的CORS响应头：服务器没有在响应中包含必要的Access-Control-Allow-Origin等头信息。
- 预检请求（Preflight Request）处理失败：对于非简单请求（例如，使用了POST、PUT、DELETE方法，或自定义了Content-Type等头信息），浏览器会先发送一个HTTP OPTIONS请求，这就是预检请求。它的目的是询问服务器是否允许实际的请求。如果服务器没有正确响应这个OPTIONS请求，或者响应中没有包含正确的CORS头，浏览器就会阻止后续的实际请求，并报告CORS错误，此时Status code: (null)尤其常见。
以下是一个典型的JavaScript fetch POST请求示例，它可能会触发预检请求：
const url = 'https://your-backend-api.com/customapi/test';
fetch(url, {
method: 'POST',
headers: {
'Content-Type': 'application/json', // 非简单请求头
},
body: JSON.stringify({ key: 'value' })
})
.then(response => response.json())
.then(data => {
console.log(data);
})
.catch(error => {
console.error('Error:', error);
});PHP后端CORS配置详解
为了正确处理跨域请求，PHP后端需要进行适当的配置，核心在于设置正确的HTTP响应头。
1. 不足的CORS配置示例
最初，开发者可能尝试在PHP中添加如下CORS头：
true);
echo json_encode($response);
}
}
?>这种配置虽然设置了一些CORS头，但存在两个主要问题：
- Access-Control-Allow-Origin: * 在某些情况下可能不被所有浏览器完全支持，且存在安全隐患，因为它允许任何网站访问您的资源。
- 最重要的是，它没有单独处理预检请求（OPTIONS方法）。当浏览器发送OPTIONS请求时，服务器会执行完整的PHP逻辑，甚至可能尝试返回业务数据，这与预检请求的预期行为不符，导致浏览器判断预检失败。
2. 完善的PHP CORS配置策略
一个健壮的CORS解决方案需要明确指定允许的来源，并专门处理OPTIONS预检请求。
核心思路：
- 白名单机制：明确指定允许进行跨域请求的源。
- 预检请求处理：当请求方法为OPTIONS时，快速响应CORS头并终止脚本执行，不进行实际业务逻辑处理。
以下是完善的PHP CORS配置代码示例：
true,
'message' => '数据已成功接收并处理',
'received_data' => $data
);
echo json_encode($response);
}
}
?>代码解释：
- $allowedOrigins 数组：定义了一个白名单，只允许列出的前端域名进行跨域访问。这是最推荐的安全实践。
-
HTTP_ORIGIN：这是浏览器在跨域请求中发送的请求头，包含了发起请求的源。我们应该根据这个头来决定是否设置Access-Control-Allow-Origin
。 - Access-Control-Allow-Origin：如果请求源在白名单中，就将其作为允许的源返回。
- Access-Control-Allow-Credentials: true：如果前端的fetch请求设置了credentials: 'include'（用于发送Cookie、HTTP认证等），则后端必须设置此头为true。注意，当此头为true时，Access-Control-Allow-Origin不能设置为*，必须是具体的源。
- Access-Control-Max-Age：设置预检请求结果的缓存时间。在此时间内，浏览器不会为相同的跨域请求再次发送OPTIONS请求，从而提高性能。
- if ($_SERVER['REQUEST_METHOD'] == 'OPTIONS')：这是处理预检请求的关键。当请求方法是OPTIONS时，我们只发送CORS相关的响应头，然后立即使用die('OK')终止脚本执行，不进行任何业务逻辑处理。
- Access-Control-Allow-Methods：指定服务器允许的HTTP方法（GET, POST, PUT, DELETE等）。
- Access-Control-Allow-Headers：指定服务器允许的自定义请求头。通常，您应该回显浏览器在HTTP_ACCESS_CONTROL_REQUEST_HEADERS中发送的头信息。
- 实际业务逻辑：只有当请求方法不是OPTIONS时，才会执行您的API业务逻辑。
。客户端（JavaScript）注意事项
前端JavaScript代码通常不需要为CORS做特殊处理，因为CORS是服务器和浏览器之间协商的机制。但是，如果您的请求需要发送Cookie或其他认证凭据，您需要在fetch请求中添加credentials: 'include'：
fetch(url, {
method: 'POST',
headers: {
'Content-Type': 'application/json',
},
credentials: 'include', // 如果需要发送Cookie等凭据
body: JSON.stringify({ key: 'value' })
})
.then(response => response.json())
.then(data => {
console.log(data);
})
.catch(error => {
console.error('Error:', error);
});请确保在PHP后端也设置了 header('Access-Control-Allow-Credentials: true');。
调试与验证
-
浏览器开发者工具：使用浏览器的开发者工具（通常按F12打开），切换到“Network”标签页。
- 查找您的跨域请求，您应该会看到两个请求：一个OPTIONS请求和一个实际的请求（如POST）。
- 检查OPTIONS请求的响应头，确保Access-Control-Allow-Origin、Access-Control-Allow-Methods和Access-Control-Allow-Headers都正确设置。
- 检查实际请求的响应头，确保Access-Control-Allow-Origin也存在。
- HTTP状态码：OPTIONS请求通常返回200 OK或204 No Content。如果返回其他错误码，说明预检请求处理有问题。
总结
解决PHP与JavaScript之间的CORS问题，关键在于理解同源策略、CORS机制以及预检请求（OPTIONS）的作用。通过在PHP后端实施一套完善的CORS配置，特别是针对OPTIONS请求的独立处理和基于白名单的Access-Control-Allow-Origin设置，可以有效解决“Cross-Origin Request Blocked”错误，确保前后端应用的顺畅通信。始终牢记，CORS配置不仅关乎功能实现，更是Web安全的重要组成部分，应谨慎配置。
