Postman中添加Origin头应填合法源格式如http://localhost:8080或https://example.com，Key为Origin而非HTTP_ORIGIN；PHP需用$_SERVER['HTTP_ORIGIN'] ?? ''安全读取，且预检请求还需补充Access-Control-Request-Method和Access-Control-Request-Headers头。
Postman里加Origin头要填什么值
直接在Headers选项卡里新增一行，Key填 Origin，Value填一个合法的源格式即可，比如 http://localhost:8080 或 https://example.com。这个值不需要和你当前Postman运行环境一致，也不需要真实存在——它只是用来触发服务端的CORS逻辑判断。
常见错误是填成 http_origin（带下划线）或 HTTP_ORIGIN（全大写），这会导致PHP里读不到：$_SERVER['HTTP_ORIGIN'] 只认 Origin 请求头被转成大写+下划线的规则，Postman传的是 Origin，PHP自动映射为 HTTP_ORIGIN；如果填错名字，$_SERVER 里根本不会出现这个键。
PHP后端怎么安全读取Origin头
不能直接写 $_SERVER['HTTP_ORIGIN']，否则会报 Notice: Undefined index: HTTP_ORIGIN。Postman不发这个头，浏览器跨域才发，非浏览器调用（如curl、脚本）也常不带。
必须做空值兜底：
- 用空合并运算符：
$origin = $_SERVER['HTTP_ORIGIN'] ?? ''; - 或者用isset判断：
$origin = isset($_SERVER['HTTP_ORIGIN']) ? $_SERVER['HTTP_ORIGIN'] : ''; - 后续做CORS响应时，如果
$origin为空，通常跳过Access-Control-Allow-Origin设置，避免暴露内部逻辑
为什么加了Origin还是被拒绝
单纯加 Origin 头不够，很多API会做预检（preflight）校验，尤其当请求含自定义头、Content-Type不是 application/x-www-form-urlencoded 等基础类型时。
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
这时你需要额外补两个头：
-
Access-Control-Request-Method：填实际要用的动词，比如POST -
Access-Control-Request-Headers：填你实际带的非简单头，比如Authorization, X-Requested-With
注意：这两个头只在OPTIONS预检请求中需要，Postman发POST时若被重定向或服务端强制校验，就得手动加上；否则服务端可能直接返回403或500。
Origin值影响CORS响应头的生成逻辑
服务端通常会把收到的 Origin 值原样反射回 Access-Control-Allow-Origin 响应头（白名单校验通过的前提下）。这意味着：
- 如果前端是
http://localhost:3000，但你在Postman里填了https://evil.com，服务端又没做白名单过滤，响应头就会变成Access-Control-Allow-Origin: https://evil.com—— 这在开发期容易埋下安全隐患 - 填
*是无效的：浏览器不接受Origin: *，且服务端一般也不会允许通配符作为请求头值 - 本地调试建议统一用
http://localhost:8080或http://127.0.0.1:8080，和前端开发服务器保持一致，减少环境差异
真正容易被忽略的是：Origin头的协议、域名、端口三者必须完全匹配才算同源。哪怕只是端口不同（:3000 vs :8080），后端CORS逻辑就可能拒绝——别只盯着域名看。
