YouTube 关联频道分析的技术原理、采用方案、指标定义与合规约束。本文为 InnerTube_Sidebar 标签页的配套规则文档，供研究人员理解结果含义、复用 研究方法、并避免触发平台风控。
YouTube 没有"同类作者推荐"独立模块，但通过多个推荐位事实上承担了 同类作者发现的功能。其策略偏向以视频为单位推荐，而非以频道为单位 推荐。研究关联频道时，主要观测点如下：
| 位置 | 触发场景 | 稳定性 | 是否本系统采用 |
|---|---|---|---|
| Up Next 右侧推荐栏 (接下来播放) |
播放页主推荐位，根据当前视频内容、标签、观众画像生成相似主题视频 | 最高 | 是 |
| 视频下方"来自相关频道" (From related channels) |
移动端及部分桌面端布局聚合同类作者的视频 | 中 | 否（移动端布局，难批量化） |
| 首页 Feed / 搜索结果 | 观看后混入同类型创作者的隐性推荐 | 中 | 否（高度个性化，难匿名复现） |
| People also watched | 移动端"其他人也观看了"模块 | 中 | 否（信号子集已包含在 Up Next） |
综合稳定性、可批量化、可匿名复现三个维度，Up Next 右侧推荐栏 是关联频道分析的最佳锚点，也是本系统唯一采用的数据源。
"拿到 Up Next sidebar"在工程上有两条路：直接调用 YouTube 内部 InnerTube API，或用 headless 浏览器模拟真实播放。我们选择前者， 原因如下：
| 维度 | InnerTube 直调 本系统 | 模拟浏览器 (Playwright) |
|---|---|---|
| 个性化 | 无 — 匿名 + 算法默认推荐 | 可登录账号拿到个性化结果 |
| 速度 | 毫秒级 HTTP 调用 | 10–30 秒每页 (要等渲染) |
| 可批量 | 极易 (并发限流即可) | 难 (CDP 资源密集) |
| 稳定性 | API 层稳定，schema 偶尔变 | 受 DOM 反爬、A/B 渲染影响大 |
| 能否做链式追踪 | 要自己重复调 next 串起来 | 天然支持（连续点击） |
| ToS 风险 | 灰色地带（开源生态广泛使用） | 同等灰色，且更易被识别为爬虫 |
研究"该达人在标准推荐池里和谁绑定"用 InnerTube 直调最干净； 研究"被推荐链条会把用户带到哪里"才需要模拟浏览器。本系统聚焦前者。
InnerTube 端点形如 https://www.youtube.com/youtubei/v1/<name>，
所有调用 POST JSON，必须带 context.client 表明客户端身份。
key 是 YouTube Web 客户端发请求时一直在用的公共 key，多年未变。
| 端点 | 用途 | 本系统使用 |
|---|---|---|
/search |
搜索视频 / 频道 / 播放列表 | 否 |
/browse |
浏览频道、播放列表、首页 Feed | 间接（HTML scrape 替代） |
/player |
视频播放数据 (流地址、字幕) | 否 |
/next watchNext |
播放页下一首推荐、评论入口、相关视频列表 — Up Next 真正来源 | 主用 |
/resolve_url |
把短链或 vanity URL 解析成内部 ID | 否（用 HTML 反查） |
本系统的解析逻辑参考以下开源项目，遇到 schema 变动可对照修复：
| 项目 | 语言 | 用途 |
|---|---|---|
| LuanRT/YouTube.js | Node / TS | 当前最完整的 InnerTube 客户端，youtube.getInfo(videoId) 直接返回 watch_next_feed，是端点结构的首要参考 |
| yt-dlp/yt-dlp | Python | extractor 内有大量 InnerTube 调用细节，包括签名绕过和不同 client 配置 |
| TeamNewPipe/NewPipeExtractor | Java | Android 客户端 NewPipe 的核心库，把 InnerTube 各端点封装得很清楚 |
| iv-org/invidious | Crystal | 开源 YouTube 前端代理，大量调用 InnerTube |
| tombulled/innertube | Python | 偏文档性质，README 列出主要端点和用途，适合快速了解全貌 |
从一个达人 handle 出发，到最终生成 Top 10 关联频道榜：
@handle 或 UCxxx/next
Sidebar 在 InnerTube 响应中曾用 compactVideoRenderer
schema，新版改用 lockupViewModel，路径为
metadata.lockupMetadataViewModel.metadata.contentMetadataViewModel.metadataRows。
本系统按精确路径优先提取，再用一个 _deep_find_uc
兜底——整棵渲染器子树扫一遍找 UC 开头的 browseId，几乎不可能漏。
支持同时分析多个达人，聚合时按 Source coverage（在多少个源 频道里出现）排序，能区分"该圈子核心同类"和"单达人特定关联"。
每条视频解析时会记录"items 数"和"with channelId 数"，差距大说明
schema 又变了；对应视频的原始 JSON 会自动落到
raw_next_<videoId>.json，便于后续修复定位。
在 N 条源视频的 sidebar 中，该关联频道出现在多少条里（每条只算一次）。
5/5 = 该频道在所有 5 条源视频的 sidebar 里都出现过，
是"无论该达人发什么内容 YouTube 都稳定推"的结构性同类绑定证据。
1/5 或 2/5 更多是单视频上下文相关。
该关联频道在所有源视频 sidebar 里出现的总次数， 同一条 sidebar 里出现 2 次也分别计为 2，不去重。
Hits ≈ Videos → 出现即只出现一次，关系平稳但不密集Hits > Videos → 某条 sidebar 一次性塞了它的多条视频，
系统性同类绑定信号更强（例：hits=14, videos=11/15
意味着 14−11=3 条 sidebar 一次推了它两条视频）
在 K 个源频道（每个源跑了 N 条视频）中，该关联频道出现在多少个源
频道的 sidebar 里。K/K 是"该达人圈子内通用核心"，
(K−1)/K 是"几乎通用，仅缺一个源"。这两档默认勾选，
映射自单源版本的 5/5 + 4/5 规则。
hl/gl
参数（en/US、zh/CN、ja/JP、pt/BR、ko/KR、ar/EG、tr/TR、th/TH、vi/VN）
各跑一次，对比 sidebar 差异，能暴露 YouTube 怎么把内容路由到不同
地区市场。
channel_push_rank.csv，能直观看出 YouTube 算法把
不同达人聚到了哪些不同的圈子。
短时间内同一账号 / IP 大量请求会触发：
| 维度 | 本系统约束 |
|---|---|
| 请求间隔 | 每次 sidebar 请求间隔 ≥ 1 秒（加随机抖动 0.5–2 秒） |
| 批量大小 | 单次分析最多 20–30 个频道的 sidebar，不要一次跑几百个 |
| 每日上限 | 带登录态的请求每天不超过 200 次 |
| 错误处理 | 遇到 429 立即暂停，等待 5–10 分钟后重试 |
| 缓存策略 | 同一 (videoId, hl, gl) 30 分钟内复用结果，避免重复请求 |
| 并发上限 | 后端默认 concurrency=3，可通过环境变量 INNERTUBE_CONCURRENCY 调节 |
pm2 logs innertube-api，确认错误状态码