Nginx状态码转换本质是控制对外暴露的状态码，常用error_page+proxy_intercept_errors拦截重写；map+return适用于路径级静态映射；Lua可解析响应体动态决策；add_header仅伪造提示头，不改变实际状态码。
在 Nginx 中做状态码转换，本质不是“修改后端返回值”，而是控制**对外暴露的状态码**。只要前端或调用方看到的是你设定的码，就满足了接口规范要求。关键在于拦截原始响应、终止原流程，并主动返回新状态码及对应内容。
用 error_page + proxy_intercept_errors 拦截并重写
这是最常用也最稳妥的方式，适用于后端返回标准错误码（如 404、500、502）但需统一转为业务约定码（如 200 带 error 字段，或 503 替代 502）的场景：
- 必须开启 proxy_intercept_errors on;，否则 Nginx 不会捕获 300–599 的响应
- 在 location 块中配置 error_page 404 =200 /api/ok;，表示把后端 404 改为 200 并内部跳转到 /api/ok
- 额外定义 location = /api/ok { return 200 '{"code":200,"msg":"success"}'; }，提供标准化响应体
- 注意：=200 表示“返回 200”，不是重定向；若写成 =302 就是重定向，行为完全不同
用 map + return 实现路径级状态码映射
适合按请求路径动态决定返回码，比如 /api/v1/users/ 总返回 201，/api/v1/orders/ 返回 202：
- 在 http 块中定义：map $request_uri $api_status { ~^/api/v1/users/ 201; ~^/api/v1/orders/ 202; default 200; }
- 在对应 location 中：location /api/ { proxy_pass http://backend; return $api_status; }
- ⚠️ 此方式会跳过代理，直接返回状态码（无响应体），仅适用于纯状态码透传，或配合前端自行处理数据
用 Lua 脚本精细干预（推荐复杂逻辑）
当需要读取响应体内容再决策状态码时（例如后端返回 200 JSON，但其中 "code":500 时应对外返回 500），Lua 是唯一可靠方案：
- 启用 ngx_lua 模块后，在 location 中使用 header_filter_by_lua_block 或 body_filter_by_lua_block
- 示例：解析 upstream 响应体，发现 error 字段为 true，就调用 ngx.status = 400 并重写响应头
- 注意 Lua 运行开销略高，建议只在必要时启用，且做好异常兜底
不推荐但偶见的兼容方案：add_header 伪造状态提示
某些老旧客户端无法正确识别状态码，只能靠自定义 Header 辅助判断：
- 隐藏真实状态码：proxy_hide_header Status;
- 添加业务字段：add_header X-Api-Code $upstream_http_x_api_code;（前提是后端已返回该头）
- 或注入解析依据：add_header X-Real-Status $upstream_http_status;
- ⚠️ 这只是“视觉欺骗”，HTTP 协议层面状态码未变，不能替代真正转换
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
