必须在服务端用中间件硬性拦截：提取可信来源注入的X-Env请求头，仅允许值为staging或test的请求通过，缺失或非法则立即返回403 Forbidden，且响应体、日志、字段均需严格隔离。
直接禁止测试版 API 被生产环境客户端调用，靠文档或约定根本不可靠。必须在服务端做硬性拦截——用明确的请求来源标识（如 X-Env、X-Client-ID）配合中间件校验，缺一不可。
怎么用中间件拦截非授权环境的请求
测试版 API（比如路径含 /v1/test/ 或 Host 为 test.api.example.com）不能只靠路由区分，得绑定明确的环境上下文。推荐在入口中间件里统一检查：
- 提取
X-Envheader，只允许值为staging或test的请求通过 - 若 header 缺失或值非法，立即返回
403 Forbidden，不进业务逻辑 - 避免 fallback 到默认值（如
if env == "" { env = "prod" }），这会让误调用静默成功 - 不要仅校验 Host 或 URL 路径——这些容易被伪造，且和实际调用方身份脱钩
为什么不能只靠 API 版本路径或子域名控制
路径 /test/v1/users 或子域 test-api.example.com 本身不携带“谁在调用”的信息。问题在于：
- 前端可能把
test-api地址写死在构建产物里，上线后仍调用测试接口 - Postman、curl 等工具可随意构造任意 Host 和路径，绕过前端限制
- 内部灰度流量若没带
X-Env，也会被当成合法测试请求放行 - API 网关层若未同步透传该 header，中间件读到的就是空值
如何确保 header 不被绕过或伪造
X-Env 这类标识必须由可信边界注入，而非依赖客户端填写：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 前端调用前，由 BFF 层（或网关）根据当前部署环境自动注入
X-Env: staging，客户端无权修改 - 移动端 SDK 内置环境标识，启动时从 bundle 配置读取，不暴露给 JS 层
- 内部服务间调用，用 service mesh（如 Istio）的 EnvoyFilter 在出口自动加 header
- 测试用例中手动设 header 是 OK 的，但生产代码里绝不能允许
X-Env由用户输入决定
测试版 API 的响应体也要做隔离
即使拦截成功，返回内容也得和正式版严格区隔，防止前端意外解析：
- 响应头加
X-API-Mode: test，便于前端日志打标 - JSON body 顶层加
"mode": "test"字段，让前端可主动丢弃该响应 - 禁止返回正式版才有的敏感字段（如
billing_info），哪怕数据库里存在 - 日志中显式标记
env=test，避免和 prod 日志混在一起排查困难
真正难的不是加一行 if env != "test" { return 403 }，而是确保这个 env 值从可信源头来、全程不被篡改、且所有调用链路（包括重试、回调、异步任务）都继承它——漏掉任一环节，测试接口就等于裸奔。
