运行期环境染色需实现租户标识的可识别、携带、路由与隔离，依托统一前置过滤器提取上下文，策略化热更打标，跨协议穿透并驱动路由、限流、追踪与日志闭环。
运行期环境染色不是给请求加个 header 就完事，而是让租户标识可识别、可携带、可路由、可隔离——尤其在多协议（HTTP/gRPC/消息）、多部署环境（公有云/私有云/边缘）混跑时。关键靠过滤器做流程控制，而不是零散硬编码。
租户识别必须前置且统一
过滤器要第一时间从请求中提取真实租户上下文，不能依赖路径或域名这种弱标识：
- 优先检查标准请求头，如 X-Tenant-ID 或 JWT 中的 tenant claim
- 缺失时 fallback：从 Cookie 读 tenant_hint，或按源 IP 段查白名单映射表（适合专线接入）
- gRPC 请求需从 metadata 提取等效字段，并统一转为 tenant.id、tenant.env 等标准属性
- 所有结果写入网关上下文（如 Spring Cloud Gateway 的 ServerWebExchange.getAttributes()），供后续环节复用
染色逻辑要策略化、可热更
避免把“打标”逻辑写死在某个 filter 里，应封装成可插拔的策略：
- 定义接口 TrafficStainPolicy.apply(ExchangeContext)，返回结构化标签（如 env=private-cloud;level=gold）
- 常见策略包括：SLABasedStainPolicy（按租户等级打标）、EnvAwareStainPolicy（按部署环境自动染色）、TrafficPatternStainPolicy（结合 QPS 和文本长度预测打 heavy-context 标）
- 策略列表由配置中心驱动，支持运行期开关切换与顺序调整，无需重启网关
染色信息要跨协议穿透且语义一致
不同调用方式不能成为染色断点，下游服务看到的标签含义必须统一：
- HTTP 流量：注入 X-Tenant-Tag header，用分号分隔多维属性（便于解析）
- gRPC 流量：写入 metadata，要求客户端 wrapper 自动透传（禁止服务端手动 copy）
- Kafka 等消息流量：在消息 headers 写 tenant-tag；若消费端收到无 tag 消息，按 topic 前缀默认补 env=staging 等兜底值
- 所有协议最终在服务网格入口（如 Istio Ingress Gateway）完成语义对齐与上下文归一
配套闭环：路由、限流、追踪都要感知染色
染色本身没价值，价值在于驱动后续动作：
- 路由层根据 X-Tenant-Tag 把流量导向对应集群（如 env=edge → 边缘节点专属服务实例）
- 限流组件识别 level=gold 租户，分配更高配额；traffic=heavy-context 则触发降级熔断
- 全链路追踪（OpenTelemetry）自动注入染色字段，监控大盘可按租户维度切片分析延迟、错误率
- 日志采集器提取染色标签，实现租户级日志隔离与快速检索
