Shadowrocket
完整使用手册

App Store 获取与正版核对

先打开App Store 正版核验页，对照应用名称、开发者和应用 ID，再进入商店购买。Shadowrocket 是 Apple 平台的付费闭源商业应用，唯一获取入口是 App Store。下文操作以 iPhone、iPad 为主；Mac、Apple TV、Apple Vision 的兼容性、系统要求及通用购买适用情况，以 App Store 页面标注为准，不根据设备名称推断是否可用。

购买前核对三个位置

在产品页先看名称是否为 Shadowrocket，再看图标是否与本站使用的官方图标一致，最后向下查找开发者信息。开发者应为 Shadow Launch Technology Limited。搜索时可能遇到名称近似的应用，因此不能只凭中文别称或搜索排名确认。名称便于识别，开发者和应用 ID 才能进一步确定正在查看的具体产品。

在商店产品链接中核对 id932747118，其中数字 932747118 是应用 ID，不是购买凭证或当前版本。分享出来的产品地址也可以用它定位同一应用。如果链接跳转后显示不同产品，应停止购买并回到核验页重新打开；不要以相似图标、介绍里的关键词或他人转述替代这一步。

确认购买内容与设备条件

在价格按钮附近查看当前店面的金额，再完成系统购买确认。美区定价约为 2.99 美元，一次性买断；实际金额、税费及货币显示以商店页面为准。购买对象是客户端使用资格，而不是服务器账户。客户端一次性买断 ≠ 线路套餐：后续连接仍需用户已有自己的订阅或服务器信息，本站只解释如何使用这些信息，不提供线路服务。

在兼容性栏检查当前设备和系统能否安装。系统要求以 App Store 页面标注为准，不要用旧教程里的系统数字判断当前可用性。若商店暂时无法完成购买，先检查账户状态、付款方式和店面可用情况；这是商店交易环节，与客户端中的 Address、Port 或分流规则没有关系，此时修改服务器参数不会改变购买结果。

安装后保留恢复依据

安装完成后，从主屏幕打开 Shadowrocket，先确认应用能够正常启动，再准备导入配置。购买记录与 App Store 账户关联，换机或重新安装时应在同一购买账户的已购项目中查找。是否支持家人共享、跨设备适用范围以及具体恢复条件，以 App Store 页面和账户实际显示为准，不能把一次成功安装推断为所有设备都可直接使用。

在恢复前区分购买资格和应用数据。已购记录可以帮助重新获取客户端，但不等同于服务器列表、订阅地址、规则修改和私有密钥已经恢复。应用重新出现后仍应逐项核对这些内容；若只恢复了软件而没有配置，Home 中缺少可用服务器是正常的准备阶段，不表示购买失效。配置的备份与迁移将在维护章节单独说明。

首次启动与 VPN 配置权限

首次打开 Shadowrocket 后，先识别 Home、Config、Data、Settings 的位置，再执行导入和连接。Home 主要用于查看服务器、选择项目及控制连接；Config 用于管理分流配置；Data 用于观察流量与请求记录；Settings 集中放置运行选项。不同设备布局可能有差异，应按英文界面词辨认，不以按钮的固定像素位置作为操作依据。

在首次连接时处理系统弹窗

在 Home 打开连接开关时，系统可能请求添加 VPN 配置。核对弹窗对应 Shadowrocket 后，按系统流程允许，并完成设备身份验证。这个权限用于建立系统网络扩展所需的配置，使客户端能够按当前模式处理进入隧道的流量；它不是向服务商购买连接资格，也不表示服务器参数已经通过远端验证。

如果当时选择了拒绝，先回到应用再次发起连接，观察是否重新出现授权流程。仍无法继续时，在系统 Settings 中查找 VPN 相关配置，检查是否存在对应项目或受管理限制。系统设置的具体层级随设备环境变化，按页面实际名称查找即可。不要在不了解用途时批量删除网络配置，特别是设备上仍有工作所需连接的情况。

允许添加配置后，再观察 Home 的连接状态。系统授权成功只解决本机能否建立网络扩展的问题，不会自动修正 Address、Password、SNI 等字段。若授权已完成但连接失败，应进入后续的参数与网络排查，而不是反复撤销权限。把系统权限和远端认证分开判断，可以避免在错误环节重复操作。

区分按需权限与可选入口

通过 Scan QR Code 扫描用户已有的服务器二维码时，应用可能请求相机访问。只有实际使用扫码入口才需要处理这项请求；手动填写或粘贴已有链接并不依赖相机。扫描结果应先检查协议类型和关键字段，再保存。二维码包含的内容可能是服务器认证信息，避免把原图放进公开相册或在提问时直接上传。

从剪贴板导入时，系统可能提示粘贴访问。先确认刚刚复制的确实是用户自己的配置，再允许本次读取。剪贴板里的普通网页地址不一定是订阅地址，复制了一整段说明文字也可能无法识别。出现解析失败时，应回到原始信息中只复制完整链接，保留必要的标点和编码，不要在不了解格式时自行删改末尾字符。

检查设备当前的网络接管状态

首次验证前，先确认设备能正常访问当前 Wi-Fi 或蜂窝网络。如果 Wi-Fi 需要网页认证，先在未连接 Shadowrocket 时完成认证，再回到应用操作。基础网络本身未通时，客户端的服务器测试也会失败。用这一顺序可以把本地接入故障和服务器故障分开，避免把所有超时都归因于同一份订阅。

如果设备存在其他 VPN 配置，先确认当前实际启用的是哪一个。多个会接管网络的配置可能相互影响，排查时只保留本次测试需要的连接状态。受组织管理的设备还可能有限制条件，应按管理要求处理，不修改自己不了解的策略。系统显示 VPN 标识只是隧道运行的线索，仍需结合应用状态和真实请求判断是否可用。

首次测试时，暂不启用 On Demand，先用手动开关完成一次明确的连接与断开。否则网络条件变化触发自动连接后，用户可能误以为开关操作没有生效。手动连接稳定以后，再在 Settings 中逐项配置自动行为。这样可以让每次状态改变都有可解释的原因，后续遇到自动重连也更容易定位。

添加已有服务器与订阅

先确认用户已有的信息属于单个服务器参数、服务器分享链接、订阅地址，还是规则配置文件，再选择入口。这些内容不是同一种对象：服务器描述如何连接远端，订阅用于更新一组服务器，配置文件用于描述分流与其他运行设置。把规则文件当订阅导入，或把产品介绍网页当服务器链接粘贴，都可能得到解析错误，而非可连接项目。

用 Add Server 核对字段

在 Home 的 Add Server 入口选择 Type，然后按原始资料填写 Address 和 Port。Address 通常是域名或 IP 地址，不应随意附加网页路径；Port 是服务端监听端口，不是协议名称。接下来填写该类型要求的认证字段，例如 Password、UUID 或密钥。Type 选错会让后续表单结构不匹配，即使地址和端口正确，也不能完成预期握手。

涉及 TLS 时，按服务商资料核对 SNI 和证书条件。Address 是连接目标，SNI 用于 TLS 握手中的服务器名称识别，二者可能相同，也可能不同，不能机械复制。出现证书错误时，应检查名称、设备时间与服务端证书，不应把 Allow Insecure 当成常规修复开关。具体字段可继续查阅Trojan 参数说明。

使用 Subscribe 与链接导入

有订阅地址时，在当前界面的 Subscribe 或订阅添加入口粘贴完整地址，设置容易辨认的名称，再执行更新。Config 页中的远程配置入口还可能接收规则配置地址，导入前要核对对象类型；不能仅因入口都接受 URL 就混用。成功后应看到预期服务器或配置对象，若只出现一段网页内容，应检查是否复制了介绍页面而不是实际资源地址。

订阅地址中的查询参数往往参与身份识别，大小写、编码和末尾字符都可能有意义。先清除复制时夹带的空格与换行，再核对完整性；不要为了让链接变短而删除参数。更新失败时记录是域名解析失败、请求超时、认证拒绝还是内容无法解析。不同结果对应不同环节，重复添加同一个地址通常只会制造重复分组。

单条分享链接可以通过应用支持的链接识别、剪贴板或 Scan QR Code 导入。导入后打开项目详情，对照 Type、Address、Port 和认证字段，确认识别结果完整。自动识别只是减少手填，不意味着所有可选参数都符合当前服务器要求。几种入口的操作差异见订阅与服务器导入入口说明。

保存后建立可维护的列表

在列表中选择刚保存的服务器，确认选中标识实际移动到目标项目，再进行测试。建议备注采用用途或来源标识，不在名称里写密码。订阅生成的项目与手动添加的项目应能区分；更新订阅可能重新生成部分字段，直接修改生成项目不一定长期保留。需要长期维护的差异，应先确认应用的覆盖或独立保存方式。

首次导入先保留一个确定来源的对象，不要同时导入多份含义不明的配置。若服务商只给出部分字段，应向原信息来源核实，不自行猜测认证类型或端口。本站不提供、不销售、不推荐服务器或订阅。完成本章时，应能说明正在使用哪条服务器记录、来自哪份已有资料，以及后续需要在哪个入口更新它。

Global Routing 三姿态与规则顺序

在 Home 打开 Global Routing，先确认当前选择的是 Config、Proxy 还是 Direct。三者分别对应配置、代理、直连姿态，决定流量采用怎样的处理方式；它们不是三条不同服务器。选择服务器解决“代理连接用谁”，选择 Global Routing 解决“哪些请求需要怎样处理”。把这两个层次分开，才能解释为什么同一服务器下不同网站会出现不同结果。

先确认生效的 Config

在 Config 页面查看当前启用的配置，必要时打开内容核对，而不是只看文件名。列表中存在某份文件，不代表它正在生效。使用 Config 姿态时，规则通常按从上到下的顺序匹配，先命中的规则决定处理策略；因此应把具体条件放在较宽泛条件之前，把 FINAL 留作末尾兜底，避免后面的规则永远没有机会被使用。

下面是用于解释语法的 .conf 规则片段，不是包含服务器参数的完整配置。example.com 是教学域名，PROXY 表示代理策略引用，使用时须确认当前配置能够解析该策略。仅复制这些行不会获得服务器，也不会自动建立与用户已有服务器的关联；请先备份现有内容，再按实际配置结构调整。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY

理解匹配条件与处理策略

DOMAIN 匹配指定完整域名，DOMAIN-SUFFIX 匹配域名后缀及其子域名，DOMAIN-KEYWORD 按域名中的关键字匹配。后者覆盖范围较宽，不能只凭一个看似独特的单词判断不会误匹配。IP-CIDR 与 IP-CIDR6 按地址网段匹配，填写时要保留前缀长度；它与按域名判断属于不同条件。

GEOIP 根据目标 IP 在地理数据库中记录的归属地区匹配，不用于判断网站的经营主体。一个网站可能由多个分布式地址提供内容，不能因为页面文字相同就推断所有请求都命中同一地区。DIRECT 表示直接连接，REJECT 表示拒绝处理，其他策略名称应能在配置中找到对应定义。FINAL 不是“再次检查所有规则”，而是前面都未匹配时使用的末尾处理方式。

用对照方法定位规则问题

某个目标在 Proxy 下正常、在 Config 下异常时，先记录该请求命中的规则与策略，再检查顺序和条件。不要立即更换所有服务器，因为代理路径已提供了一个可用对照。相反，如果 Proxy 下同样失败，应先排查服务器、认证、TLS 和网络条件。Direct 能否访问只能说明直接路径的结果，不足以证明代理参数正确。

修改规则时一次只调整一项，保存后按当前界面要求使配置生效，再重新发起目标请求。已有长连接可能继续沿用先前路径，浏览器页面也可能使用缓存，必要时关闭相关页面后重试。规则测试应覆盖实际失败的子域名，而不只是首页域名；页面中的图片、接口和登录请求可能属于不同域名，从而命中不同规则。

连接、验证与分层排查

在 Home 选择已核对的服务器，确认 Global Routing，再打开连接开关。等待应用完成状态变化后，先访问一个自己熟悉、可以重复测试的目标，再检查实际请求记录。不要把“开关打开”“系统出现 VPN 标识”“测试出现数值”合并成同一个成功结论：它们分别反映运行状态、系统隧道状态及特定测试条件下的结果。

把测试结果与实际访问分开

在 Connectivity Test 中执行测试，可以了解所选服务器在当前测试方式下是否响应。测试目标、协议支持和网络条件会影响结果，不能把单次耗时理解为所有网站的速度，也不能将测试失败直接等同于所有请求都不可用。若测试正常而网页失败，应继续检查目标域名、分流策略和应用内的实际请求，而不是只重复点击测试。

验证时保持条件一致：同一设备、同一基础网络、同一服务器、同一目标请求。先记录 Config 姿态的表现，需要隔离规则影响时再短暂切换 Proxy，测试后恢复原设置。若同时换网络、换服务器又改 DNS，结果即使变好，也无法确定是哪一步产生作用；下次故障还会缺少可复用的判断依据。

按失败发生的位置排查

如果连接开关很快恢复关闭，先看是否仍卡在系统授权、网络扩展启动或本地配置错误阶段。确认 VPN 配置存在、设备允许启用，再检查应用是否提示配置解析或策略引用异常。此时不必先研究某个网站的规则，因为请求可能尚未进入稳定运行的客户端。保留错误原文比只描述“打不开”更有助于区分原因。

如果开关保持打开但所有目标都无法访问，先确认基础网络，再检查服务器 Address、Port、认证信息及服务状态。连接超时通常意味着在限定时间内未完成某一步，不直接指明是密码错误；认证拒绝则更接近账户或参数问题。TLS 错误应进一步核对 SNI、证书名称和设备时间，不能只根据一个“失败”图标判断根因。

如果只有部分目标失败，先在记录中找到该目标及其关联子域名，看命中的策略是否符合预期。主页面正常而图片或登录失败，常见原因是不同请求采用不同路径。也要区分远端返回的业务错误与网络错误：页面已经返回账户权限提示，说明至少部分连接已完成，不应继续围绕本机 VPN 权限反复操作。

保留能复现问题的最小记录

记录发生问题的时间范围、Wi-Fi 或蜂窝环境、当前姿态、目标域名和错误类型。日志中若含订阅地址、认证字段、私钥或完整请求参数，应先隐藏敏感部分再用于沟通。保留协议类型和错误阶段通常已经能够支持初步判断，不需要公开整份配置。测试结束后关闭临时的详细记录，避免长期积累不必要的访问明细。

切换网络后应重新发起连接与请求，不把切换前的结果当作当前状态。某些协议对传输条件有要求，某个网络可用不能推断另一个网络也相同。问题仍无法复现时，先恢复最近一次确认可用的配置，记录差异，再逐项重做。快速主线可回看连接与验证教程；本章的目标是缩小范围，而不是一次修改所有设置。

Data 流量与请求记录

连接建立后打开 Data，先看页面标注的统计范围，再观察上传、下载及请求变化。这里的数据用于理解客户端当前可见的网络活动，不等同于运营商账单，也不一定覆盖设备上所有网络行为。不同计数项可能按会话、运行阶段或页面所示周期累计，解释数值前应先确认单位与范围，不根据一个总量推断某个应用已经传输了多少内容。

先读方向、单位与时间范围

上传表示从设备向外发送的数据，下载表示从外部返回的数据。速度是某段时间内的变化率，累计量是观察范围内的总和，两者不能直接比较。网页加载结束后速度下降通常只是本次传输已完成，并不说明连接中断；后台同步仍可能带来零星流量，因此在不执行操作时看到少量变化也不能单独判定异常。

开始一次排查前，先记下当前计数或使用页面实际提供的重置方式建立新观察区间，再只执行一个目标操作。完成后比较变化，可以把本次请求与之前的后台流量分开。若页面没有明确提供某种统计周期，就不要自行称为“本月用量”。需要计费依据时，应查服务商或运营商对应的账户记录，而不是只凭客户端局部统计。

从请求记录核对分流结果

在 Data 或对应的请求记录入口找到刚刚访问的域名，查看当前界面提供的目标、策略、匹配信息和错误。记录字段取决于实际界面与启用的记录选项，不应要求每条记录都包含全部细节。优先回答三个问题：请求是否出现、采用什么处理路径、在哪一步结束。只有确认请求进入记录后，规则分析才有明确对象。

没有看到预期请求时，先确认目标应用确实发起了新连接。浏览器缓存、已有连接复用、页面未刷新，都可能让操作看起来发生了却没有新的网络记录。可以关闭目标页面后重试，或执行一个明确需要联网的操作。也应检查记录筛选条件，避免只显示错误或特定策略时误以为其他请求没有经过客户端。

看到 DIRECT 并不必然是故障，需要结合当前 Global Routing 和命中条件判断。Config 姿态下的直连结果可能正是规则设计；Proxy 姿态下的行为则要结合适用范围与实际记录检查。规则命中只表明选择了某种路径，不保证目标服务器一定接受请求。把“规则选择正确”和“目标成功响应”作为两个检查点，能减少误判。

用重复实验解释流量差异

如果用户认为某个操作耗量异常，先在相同目标与相同操作下重复测试，再比较记录中的请求数量、重试和持续连接。视频、图片、同步任务的内容大小本来就不同，不能拿一次文本页面加载与一次媒体播放比较。若连续失败导致重复请求，累计流量仍可能增加；有流量变化并不等于业务操作已经完成。

若统计值与远端账户用量不同，先检查双方统计时间、上传下载合计口径和协议开销。客户端看到的是自身范围内的处理量，远端还可能采用不同的累计边界。不能仅凭差值判断记录错误，也不能通过修改分流规则保证两处数字一致。保留同一时间区间的观察，再向已有服务的信息来源核对其计算方式。

控制访问记录的保存与分享

请求记录可能暴露访问目标、时间以及部分 URL 参数，属于需要谨慎处理的信息。排查时只保留与问题相关的区间，分享前遮盖身份信息、订阅凭据和不相关域名。配置中的服务器备注也可能包含个人用途说明，截图或导出前同样需要检查。清除记录会移除排查线索，因此先完成必要的脱敏摘录，再执行清理。

Settings、DNS 与 On Demand

打开 Settings 前，先记录当前连接已经确认可用的条件，再决定要解决什么问题。Settings 中的选项可能与配置文件共同影响运行结果，某些项目还会受当前协议和设备条件限制。操作时以实际显示的字段为准，先查看说明再修改；不要为了让界面看起来“设置完整”而启用所有选项，未使用的能力不需要预先调整。

从解析链路理解 DNS

查找 DNS 相关选项时，先确认当前使用系统解析、自定义解析还是配置文件中的设置。DNS 把域名转换为地址，规则又可能同时依赖域名和解析结果，因此解析异常可能表现为页面无法打开，也可能影响 IP 类规则命中。修改 DNS 之前，先区分域名解析失败与服务器连接失败，后者不会仅因换一个解析地址就自动恢复。

选择系统 DNS 时，结果受当前网络提供的解析条件影响；自定义 DNS 则需要确认解析服务器在现有路径下能够访问。DNS over HTTPS 通过 HTTPS 承载查询，但其服务地址本身也需要可达，初始连接还可能涉及域名解析。不能只因为启用了某种加密传输就推断所有解析环节都已正确，仍要观察实际查询是否成功。

测试 DNS 时，一次只改变一种来源，保留修改前的值，再重新发起目标请求。必要时按应用提供的方式清理相关缓存或重连，避免旧结果影响判断。若某个域名失败而其他域名正常，应检查该域名及关联请求，不先把所有解析设置推倒重来。具体取向见DNS 设置说明。

在手动连接稳定后启用 On Demand

在 On Demand 相关入口阅读触发条件，再设置需要自动连接或保持连接的网络场景。它决定何时尝试启动连接，不决定服务器能否通过认证，也不替代 Global Routing。手动连接尚未稳定时开启自动行为，会让状态变化来源变得不清楚。应先完成一次手动连接、验证与断开，再加入按需条件并单独测试。

设置后按计划切换一次网络，观察是否触发预期动作。若出现断开后又自动连接，先检查 On Demand 条件，而不是立即判断开关失灵。临时排查需要持续断开时，应先暂停对应的自动行为，再观察系统状态。网络变化、设备休眠与应用前后台转换可能形成不同条件，因此一次成功触发并不代表所有场景都已经验证。

谨慎调整传输与高级参数

当实际问题涉及特定协议时，再进入相应服务器或配置中的高级字段。MTU 影响单次传输承载的数据规模，过大可能在某些路径产生问题，过小也会增加开销；没有证据时不应随意套用他人的数值。涉及 WireGuard 时还要区分 Allowed IPs 与应用层规则的作用范围，可查阅WireGuard 参数说明。

涉及证书和 TLS 的设置，应保持身份校验含义明确。遇到证书失败先查名称、有效性和设备时间；关闭校验会改变信任条件，不能当成常规加速措施。涉及额外证书信任、请求改写或内容处理的高级功能，不是本手册建立基础连接的必要步骤。尚未理解作用范围时，保留当前可用配置比照抄复杂设置更容易维护。

识别配置覆盖与生效时点

修改后返回 Config，确认当前生效文件没有切回其他对象，再按界面提示保存或重新连接。有的设置影响后续新请求，有的需要重建连接才能体现；不能仅凭旧页面仍然显示相同结果就认定保存失败。若文件更新后设置恢复，检查是否由远程配置重新写入，而不是继续重复修改同一个会被覆盖的位置。

订阅更新、备份与日常维护

日常使用时，先保持一份已确认可用的配置，再按实际需要更新订阅和应用。维护不是定期把所有设置重新改一遍，而是让来源、变更与结果可追溯。每次变更至少能够回答三个问题：修改了哪个对象，为什么要改，如何恢复。这样在连接出现差异时，能够从最近一次变化开始检查，而不是从首次安装重新排查。

区分三种更新对象

在订阅入口更新的是服务器资料，可能改变项目数量、地址、认证或备注；在 Config 中更新远程文件，可能改变规则和运行选项；在 App Store 更新应用，改变的是客户端本身。这三种操作不能互相替代。订阅更新成功不表示分流文件已经更新，应用完成更新也不表示过期的服务器认证信息重新有效。

更新已有订阅前，先确认地址仍来自用户自己的服务信息，并记录当前选中的项目。更新后核对分组、服务器内容和选择状态，再用同一目标测试。如果原项目消失，应检查服务信息是否发生变更，不把旧名称当成永久标识。更新失败时保留具体错误，先判断资源获取还是内容解析失败，不立即删除原本还能使用的列表。

备份时区分秘密与普通说明

使用应用实际提供的导出或备份方式时，先检查包含哪些对象。规则文件、服务器记录、订阅地址和私钥可能分开保存，导出一份文件不能自动证明全部数据都在其中。备份完成后，应核对内容范围和存放位置是否可找回；重要的恢复流程可以先用不影响现用配置的方式验证，而不是等换机后才第一次检查。

备份中可能包含 Password、UUID、Private Key 和带身份参数的订阅地址，应存放在用户自己控制、具备适当访问保护的位置。向他人解释规则时，只提供必要片段，不直接发送完整备份。示例域名可以公开，真实认证信息不能因为出现在配置文本里就当成普通说明。若怀疑凭据已泄露，应从原服务的信息管理入口处理失效与替换。

换机与重新安装的恢复顺序

在新设备先从 App Store 已购项目找回 Shadowrocket，核对设备兼容性后打开应用，再导入已有备份。购买资格恢复与配置恢复是两个阶段：前者由商店账户决定，后者依赖保留的数据。导入后重新检查权限、服务器选择、Global Routing 和生效 Config，不假定旧设备上的系统授权会完整迁移到新设备。

恢复后先进行手动连接，确认一次正常请求和规则结果，再启用 On Demand 等自动行为。若备份时间较早，应先核对服务器认证是否仍然有效；若订阅需要更新，完成更新后再次检查选中项目。不要一开始就删除旧设备上的全部记录，待新设备验证完成并确认必要数据可恢复后，再按个人数据管理需要处理旧内容。

变更前后保留短记录

可以用个人笔记保存变更日期、修改对象和观察结果，但不在笔记中重复写入密码或完整订阅地址。记录“调整某条 DOMAIN-SUFFIX 的策略后，目标接口恢复”比记录“改了设置”更有用。故障再次发生时，先对照这些差异，再查看连接排查，按权限、网络、服务器、规则、目标服务逐层缩小范围。

较长时间不使用后，重新连接前先检查基础网络与 App Store 中的应用状态，再核对已有服务信息。不要用过去一次测试的结果代表当前条件，也不因界面布局变化就立即重建所有配置。界面入口变动时按英文词查找对应功能；参数含义未变的部分可继续沿用本手册的判断方法，具体可用选项以当前应用显示为准。

完成维护后应回到最小可用状态：选中的服务器清楚、生效配置明确、测试结果可复现、临时记录已处理。需要连续完成首次操作时回到快速上手教程；需要补充协议背景时查看技术笔记。本手册用于解释各阶段的责任边界，不替代用户已有服务的账户管理与参数说明。