一句话定义：影子流量（Shadow Traffic），也叫流量镜像（Traffic Mirroring），是把线上真实的用户请求复制一份，发给正在测试的新系统（比如一个新版本的模型），但不把它的返回结果发给用户——用户那边完全无感，照旧拿到旧系统的答案。
它解决什么问题
上线新模型最怕两件事：一是效果变差，二是把线上搞挂。可问题是，你没法凭空知道新模型在真实场景下表现如何——离线评测集再大，也长不出真实用户那种千奇百怪的提问、奇怪的输入长度、突然的并发高峰。
影子流量就是给这个难题开的药方：让新模型在"真枪实弹"里跑一遍，但不开火。
打个比方
想象一家餐厅要换主厨。直接换？万一客人不满意，口碑就砸了。于是老板让新主厨每天照着老主厨接到的点单，在同一时间做出一模一样的菜——但只端进后厨，给评委尝，不上桌。顾客吃的还是老主厨的菜，毫不知情。这样连做一个月，老板手里就有了新主厨在各种真实点单下的完整表现数据。
影子流量就是这个"只做不端"的过程。
它是怎么跑起来的
典型做法是在请求入口（比如网关、反向代理或服务网关层）挂一个复制规则：
1. 用户的请求正常走主链路，原样返回。
2. 同一份请求被异步复制，发往影子环境。
3. 影子系统的输出被完整记录：结果内容、耗时、报错、AI 词典：Token">Token 消耗等，但丢弃不返回。
4. 事后比对主链路和影子链路的输出差异，做评估。
有个容易忽略的细节：复制请求时通常要"洗掉"副作用。比如一个"下单"请求被镜子里的系统真的执行了，就会多出一笔订单。所以影子流量一般只用于读操作，或者影子环境连的是隔离的、只读的数据副本。另外要留意隐私与合规——真实请求里可能带用户数据，能脱敏的就先脱敏，具体以各家合规要求与官方页面为准。
和相邻概念的区别
| 概念 | 用户拿到谁的答案 | 新系统是否处理真实请求 | 主要目的 |
|---|---|---|---|
| 影子流量 | 旧系统 | 是（复制一份） | 用真实数据评估新系统 |
| 灰度发布 / A/B 测试 | 可能拿到新系统的 | 是（真分一部分） | 小比例上线并观察业务指标 |
| 离线评测 | 不涉及 | 否（用测试集） | 快速迭代、卡基本门槛 |
| 压测 | 旧系统 | 否（造合成流量） | 验证容量与稳定性 |
关键差别在于"有没有真的让用户承担风险"。影子流量把风险压到零，代价是它拿不到业务指标——因为用户根本没看到新模型的回答，你只能比"输出质量"，没法比"用户是否更满意"。
对从业者意味着什么
对新模型上线来说，影子流量是"灰度发布"之前的一道安全垫：先在影子里看几天，发现答非所问、胡编乱造、耗时不达标，就地回炉；一切正常，再放进灰度，让 1% 的真实用户真的用上。
对普通职场人，它其实是一个通用思路：任何系统改造，都可以先让它"跟着跑一阵"，只记录不生效，用真实数据验证，再决定是否切流。这个思路不限于 AI，换数据库、换推荐算法、重构后端服务，都是同一套打法。
一句提醒：影子环境要尽量贴近生产，配置不同、数据版本不同，测出来的结论也会跑偏；同时做好流量比例控制，别让复制出来的请求把下游压垮。