环境变量不适合传递鉴权令牌，因其全局静态、缺乏请求级隔离且易泄露；应通过HTTP头（如Authorization）透传JWT，环境变量仅用于存放JWT_SECRET_KEY、ISSUER等静态配置。
环境变量本身不适合传递鉴权令牌——它不是为运行时动态、敏感、请求级数据设计的机制。真正可行的方式是通过请求上下文（如HTTP头）在服务间安全透传令牌，环境变量只应存放静态配置（比如密钥、issuer地址等）。
为什么不能用环境变量传令牌
环境变量在进程启动时加载，全局且静态；而每个用户每次请求的JWT都不同，具有时效性、唯一性和敏感性。把令牌塞进环境变量会导致：
- 所有请求共用同一个值，彻底破坏多用户隔离
- 无法按需刷新或失效，安全风险极高
- 日志/监控可能意外打印环境变量，泄露令牌
- 容器或K8s中环境变量对所有Pod副本可见，违背最小权限原则
正确做法：通过请求头透传JWT
标准且被广泛采用的方式是让上游服务从请求头读取 Authorization: Bearer xxx，再原样或稍作加工后，通过下游调用（如OpenFeign、RestTemplate）注入到新请求的Header中。
- 网关层统一校验并解析JWT，提取用户ID、角色等信息，可选择添加
X-User-Id、X-Roles等可信头，减轻下游解析负担 - 微服务内部调用时，Feign拦截器自动复制当前请求的认证头（示例中常见
PigFeignClientInterceptor或自定义RequestInterceptor） - 非HTTP调用（如消息队列、gRPC）需将必要身份上下文序列化进消息体或metadata，不依赖环境变量
哪些信息可以放进环境变量
适合放在环境变量里的，是与令牌处理相关的**静态配置项**：
-
JWT_SECRET_KEY或JWT_PUBLIC_KEY_PATH（用于签名验证） -
JWT_ISSUER、JWT_AUDIENCE（校验令牌签发方和受众） -
AUTH_SERVICE_URL（认证中心地址，仅用于刷新令牌等少数场景） -
TOKEN_TTL_SECONDS（令牌默认有效期，供生成逻辑参考）
特殊情况：无Token的内部调用
定时任务、后台Job、服务自检等场景确实没有原始请求Token。这时不应伪造或复用用户Token，而是：
- 使用专用的机器账号（machine-to-machine），通过客户端凭证模式（Client Credentials）获取服务级Token
- 调用时显式声明内部来源，例如设置
From: IN请求头，并配合@Inner注解限制接口仅允许内部调用 - 避免在环境变量里硬编码服务Token，应通过密钥管理服务（如Vault、K8s Secrets）动态注入
