Stash Apple TV 怎么设置

围绕 Stash 面板小组件的使用，很多用户会先把注意力放在界面呈现上，却忽略了入口来源与配置基础。更稳妥的顺序是：先确认官方下载入口，再区分 Apple TV 与其他平台的能力边界，最后整理可复用的配置文件与规则集。本文只讨论这些可核实的内容，不涉及任何具体节点、售卖信息或无法确认的菜单操作。

一、官方入口：先确认下载与文档来源

Apple TV 端的 Stash 通过 App Store 获取。这一点来自官方总下载页 https://stash.ws/zh/download 的说明，即 Apple TV 来源指向 App Store。除此之外，不应假定存在其他旁路安装方式；若在 App Store 中找不到对应条目，应以官方页面和官方文档后续更新为准。

另一个必须放置在前面的入口是官方文档 https://stash.wiki/。本文无法确认 Apple TV 的具体面板菜单、版本号或某一项功能开关的位置，因此凡是涉及具体点击路径、按钮名称、界面层级的操作，都应以官方文档为准。把官方文档当作唯一依据，可以避免跟着过时的截图或口口相传的步骤走偏。

Stash 面板小组件的讨论也应建立在这个前提上：面板与小组件属于界面呈现的一部分，其可用形态、可配置项和呈现效果需要在对应设备上按官方说明确认，而不是从其他平台的界面直接推演。

二、Apple TV Stash 设置的第一步：分清设备与来源

“stash apple tv 设置”与“apple tv stash 设置”指向同一件事：在 Apple TV 上完成安装并进入可用状态。基于已知事实，能确定的是来源为 App Store，配置来源是同一份 YAML。至于安装后在电视端如何进入具体设置页、如何切换某个面板、如何添加小组件，这些细节本文不展开，统一引导到 https://stash.wiki/ 查询。

这里需要强调一个常见误区：不要因为 macOS 端有 HTTP 引擎、可以捕获并修改请求响应、官方页面还说明可用 JavaScript 处理请求，就默认 Apple TV 端具备同样的能力组合。已知事实只说明这些能力与 Mac 端相关，并未说明 Apple TV 端拥有相同的引擎或脚本处理方式。跨设备讨论时，应把“同一份配置”与“同一套能力”区分开。

同理，Mac 端使用 Network Extension 接管流量，这一机制也只应放在 Mac 语境下描述。Apple TV 端的具体网络接管方式，本文无法从给定事实确认，因此不做推断。

三、同一份 YAML：跨设备复用的基础

同一份 YAML 配置可用于 macOS、iOS、Android。这是组织 Stash 规则集时最重要的一条约束：配置应当尽量做成设备无关的公共部分，把设备差异留给各端自行处理。

实践上可以把 YAML 分成三层来整理：

第一层是公共骨架，包括配置的整体结构、规则集的引用关系、通用策略组命名等。这部分在三类设备之间保持一致，便于统一维护。

第二层是规则集引用。规则集通常以远程列表或本地文件的形式被引用，配置文件里只保留引用条目，而不把大段规则内容直接内联。这样更新规则时只需替换或刷新规则集，不必反复改动主配置。

第三层是设备专属部分。由于同一份 YAML 要跑在 macOS、iOS、Android 上，任何依赖特定平台能力的写法都应单独隔开，避免因为某端不支持而导致整份配置在另一端报错或行为异常。

需要说明的是，Apple TV 并不在“同一份 YAML 可用于 macOS、iOS、Android”这一表述的列举范围内。因此在规划 stash apple tv 设置时，不应直接宣称 Apple TV 与上述三端共用完全相同的配置处理方式。是否复用、复用哪一部分、以何种形式导入，应以 Apple TV 端实际支持的配置能力和官方文档说明为准。稳妥做法是：公共骨架与规则集引用保持通用，涉及平台能力的部分先不写入，等官方文档给出明确说明后再补。

四、规则集准备：先结构，后内容

Stash 规则集的准备不在于一次写全，而在于结构清晰、来源可控、更新方便。可以从以下几点入手：

命名统一：规则集文件名、引用名、策略组名使用一致的命名习惯，避免同名不同义。

分层引用：按用途拆分规则集，例如基础直连、常见域名分类、特定服务分类等，主配置只做引用与顺序编排。

顺序明确：规则匹配通常有先后，配置文件中的规则集排列顺序应固定下来并写入注释，防止后续调整时打乱优先级。

来源可追溯：每个远程规则集保留来源地址与更新方式的记录，便于核查某条规则来自哪里。

避免内联膨胀：规则内容放在规则集里，主配置保持精简，减少跨设备同步时的体积和出错面。

对于 stash 面板小组件所依赖的展示信息，也应在配置整理阶段考虑：面板与小组件呈现的内容通常与策略组、规则命中情况相关，如果策略组命名混乱、规则集层次不清，展示侧也会跟着难以阅读。因此先把配置结构理顺，再去看面板与小组件的呈现，顺序更合理。

五、Mac 端能力边界：可以作为参考，不能直接照搬

已知 Mac 端使用 Network Extension 接管流量，HTTP 引擎可捕获并修改请求响应，官方页面还说明可用 JavaScript 处理请求；系统要求为 macOS 12.4 及以上，支持 Apple 芯片和 Intel。这些信息对理解 Stash 的能力范围有帮助，但它们是 Mac 端的描述。

在写 Stash 规则集时，如果某条规则或某段脚本依赖 HTTP 引擎的请求响应处理，就应把它视为平台相关部分，单独标注适用范围。不要因为 Mac 端可用，就默认 Apple TV 端同样可用；也不要把 Mac 端的系统版本要求、芯片支持情况套用到 Apple TV 上。跨设备配置的核心原则是：公共部分共享，平台相关部分隔离，无法确认的部分留到官方文档确认之后再补。

六、把无法确认的操作交还给官方文档

Apple TV 端的界面细节是最容易产生臆测的地方。以下类型的问题，本文均不给出具体步骤，统一以 https://stash.wiki/ 为准：

安装后在 Apple TV 上进入设置的具体路径；

面板的开关位置、分组方式和显示项；

小组件的添加方式、尺寸与刷新行为；

配置文件的导入入口与导入后的确认提示；

版本差异带来的界面变化。

这样处理不是回避，而是保证说明的可靠性。stash 面板小组件属于强界面相关的部分，一旦照着未经确认的步骤操作，很容易在菜单层级上卡住。以官方文档为入口，能确保看到的是当前有效的说明。

七、一份可执行的准备清单

综合以上内容，可以把“从官方入口到规则准备”的流程压缩为一份清单：

1. 从 https://stash.ws/zh/download 确认 Apple TV 的 App Store 来源；
2. 打开 https://stash.wiki/ 查阅 Apple TV 相关说明，记录当前可确认的操作范围；
3. 整理公共 YAML 骨架，保持 macOS、iOS、Android 可复用的部分一致；
4. 拆分并命名 stash 规则集，主配置只保留引用与顺序；
5. 把依赖平台能力的写法单独隔离，不默认 Apple TV 与 Mac 能力相同；
6. 在配置结构稳定后，再按官方文档确认面板与小组件的呈现方式；
7. 对任何无法从事实确认的菜单、版本和功能，回到官方文档查看。

按这个顺序推进，stash apple tv 设置就不会变成对界面的猜测，而是从可信入口出发、以可复用配置为基础、以官方文档为边界的完整准备过程。