Invidious：界面、媒体路径与运维责任
阅读 Invidious 搜索源码：URL 识别只是分流，不是清理器
结合十六个明确独立的离线教学案例，理解 Query 初始化、过滤器优先级及后续 URL 规范化的职责。
你将学会
- 初始化决定到底是哪一种搜索
- URL 判断回答的是狭窄的路由问题
- 得出安全结论之前，继续追踪下一次调用
开始前需要
- 了解 HTTP 和容器基础
- 区分应用状态与媒体流量
解释依赖和信任边界，准备可核验的试验，并在真实范围内理解源码与模型证据。
先看结论
- 查询模式与过滤器优先级属于搜索语义。
- 通过 URL 启发式，不等于验证或播放了视频。
- 路由在分类之后还会调用独立清理器。
初始化决定到底是哪一种搜索
Search::Query 读取 q，并且在普通搜索中可以回退到 search_query。它去除首尾空白，遇到开头反斜杠时将其移除，同时设置智能功能抑制标志。随后解析页码，并分别处理普通、频道、订阅和播放列表模式。不能只看文件末尾的一条正则表达式，就推断完整搜索行为。
所检查分支为 sp 参数提供 YouTube 兼容解析路径。否则先读取 Invidious URL 过滤器，仅在这些过滤器仍为默认值、且文本具有相关语法时，再考虑旧式查询过滤器。上游测试中包含优先级案例，本次只是阅读这些测试，没有执行。现代过滤器可能让一个看似旧式过滤指令的词保留为普通查询文本。
URL 判断回答的是狭窄的路由问题
Query.url? 会先拒绝被抑制的智能功能、非普通模式和非默认过滤器，再应用 YouTube 域名前缀启发式。在独立 JavaScript 模型中，普通观看链接、短链接和无协议路径通过；大写形式、缺少斜杠、前置文字、非默认过滤器或开头反斜杠则不通过。十六个模型案例均通过，期间没有网络活动。
模型也接受以斜杠结尾的 YouTube 根 URL。这只表示狭窄的分流条件将文本归为类似 URL 的输入，并不能证明存在有效视频、重定向成功或资源可播放。模型显式接收模式和过滤器标志，案例使用 ASCII 文本；它没有执行 Crystal、解析所有过滤器，也没有证明 Unicode 和 URI 边界上的等价性。
得出安全结论之前，继续追踪下一次调用
搜索路由在重定向类似 URL 的查询之前，会调用 UrlSanitizer.process。清理器创建新的相对 URI，筛选路径片段，并按目标路径类别复制允许的查询参数；处理重复参数的循环会取最后一个允许值。这些后续转换与分流判断是不同工作，本次只检查了源码，并未由教学模型执行。
有价值的后续工作，是编写源语言回归测试，验证冲突参数、异常路径和不同查询模式的最终重定向目标。该测试集只是提案，并未在这里交付或运行。现有证据支持控制流解释和明确的模型输出，不能据此宣称发现漏洞、完成安全审计或通过端到端搜索测试。
实施步骤
- 1
先阅读初始化，再阅读 Query.url?。
- 2
检查正向分类结果的实际调用方。
- 3
在明确边界下运行十六个独立教学案例。
- 4
为最终规范化目标另行设计 Crystal 测试。
可复制示例
{
"modelCases": 16,
"rootUrlWithSlash": true,
"leadingBackslash": false,
"nondefaultFilters": false,
"upstreamCrystalExecuted": false,
"sanitizerExecuted": false,
"playbackVerified": false
}常见问题
十六个案例运行了 Invidious 应用吗？
没有。它们运行的是独立 JavaScript 教学模型；Crystal、完整过滤器解析、清理器和播放均未执行。
URL 判断通过，是否证明安全或可播放？
不是。规范化、路由、上游可用性和实际播放是需要分别检查的阶段。
资料来源
- invidious/src/invidious/search/query.cr来源核查 2026-09-08
- invidious/spec/invidious/search/query_spec.cr来源核查 2026-09-08
- invidious/src/invidious/routes/search.cr来源核查 2026-09-08
- invidious/src/invidious/yt_backend/url_sanitizer.cr来源核查 2026-09-08