文档补充三通道cookie依赖矩阵：商城WSS/HTTP RPC原始cookie即可，仅活动WSS需补齐

docs/HUYA_CHAT_缺失字段补齐方案.md

@@ -106,6 +106,30 @@ cd /Users/yml/codes/live-hub-py
 
 ## 六、风险与验证要求
 
+## 七、各通道 Cookie 依赖矩阵（2026-09-01 晚实测）
+
+不同通道对网页设备态字段的依赖不同，补齐策略按通道区别：
+
+| 通道 | 代表接口 | Cookie 使用方式 | 原始 16 字段能否工作 |
+| --- | --- | --- | --- |
+| 活动 WSS（`mobileui`/`webActUI`） | getConfig / getUserScore / checkUserBindGameAccount / scoreExchangePrize | AUTH 帧 + 业务 tReq 均带完整 cookie，wsLaunch 会话 guid 需回写 | ❌ 缺 4 核心字段时 getConfig 超时；**需补齐**（已接入 elite_session） |
+| 商城 WSS（`shopMiddleUI`，m-shop.yaoguo.com） | getGoodsInfoV5 / createOrderV5 / payOrderSubmit | 业务 tReq `UserId.sCookie` 带完整 cookie，`sGuid` 置空（HAR 实证） | ✅ 实测原始 cookie 正常响应（403 只是业务参数校验） |
+| HTTP RPC（cdnws.api.huya.com POST） | query_user_score / get_act_prize_list / build_bind_urls / get_livelink_mini_qrcode | baseinfo + 业务 tReq 带完整 cookie，`_resolve_cookie_guid` 自动用 guid→udb_guiddata→sha256 派生 | ✅ 实测原始 cookie 直接返回 status=200（积分 4880） |
+
+要点：
+
+1. **活动 WSS 是唯一强校验网页设备态的通道**：AUTH/getConfig 前置就失败（无响应），
+   补齐字段后成功（commit `5dc7365`）。
+2. **商城 WSS 不校验**：`UserId.sGuid=""` 且 cookie 原样发送，服务端接受原始登录态
+   （实测 getGoodsInfoV5 返回业务 403 而非连接/解析错误）。
+3. **HTTP RPC 自带 guid 派生**：缺 `guid` 时依次用 `udb_guiddata[:32]`、`yyuid|udb_uid|
+   udb_passport|username|udb_biztoken` 的 sha256 派生，业务请求体可带原始 cookie
+   直接成功 —— 这是「活动接口当前主要依赖核心认证字段」的佐证（与
+   `HUYA_COOKIE合并审计与来源矩阵.md` 结论一致）。
+4. 因此**没有其他必须补齐的 cookie 字段**：活动 WSS 之外，商城 WSS 与 HTTP RPC 用
+   原始登录态即可跑通。剩余未实测的链路（商城下单/支付等）依赖的仍是同一份
+   原始 cookie + `udb_cred/biztoken` 登录态，不涉及网页设备字段的新增要求。
+
 1. `guid/_qimei_uuid42/__yamid_new/game_did` 的**真实性/关联性**服务端是否校验未知；
    必须用生成值跑通线上活动 WSS 全链路才能定论，不能只过长度测试。
 2. 统计字段随机值不影响接口语义，但**顺序**建议与 9.1 cookie 保持一致以便对照。