怎么把转换结果变成长期可用的订阅链接
说明 convert、/sub、/dynamic 和订阅管理之间的分工，避免把一次性结果当长期出口。
用文章解释工具怎么用、适合什么场景、常见问题怎么处理。
三种出口，解决的是三种问题
站内和订阅有关的入口不少，但它们的职责并不一样。把它们分清楚，后续维护会轻松很多。
convert
convert 更像一个“订阅生成器页面”。你可以在页面上调参数，确认目标平台、来源链接和转换选项，然后得到可继续使用的参数组合。
/sub
/sub 是真正的动态输出接口。它根据 query 生成订阅结果，更适合被客户端直接订阅。
/dynamic
/dynamic 是固定地址模式，适合长期分发。你不需要把所有参数都暴露给最终用户，而是维护一个更稳定的 path + security 入口。
推荐场景
场景一：你只是临时测试
如果只是临时试一条转换规则，直接从 convert 开始就够了。它的优点是快，适合试错。
场景二：你已经确认参数组合可用
当你确认 query 已经稳定，而且客户端以后会反复拉取，就应该切到 /sub 这个动态输出层，不要再把页面调试结果手动复制来复制去。
场景三：你要把地址长期发给别人
如果这条订阅地址要长期给自己或团队使用，优先进入 动态订阅管理，生成固定 /dynamic 地址。这样后续替换上游订阅、调整 User-Agent、增加手动节点，都不需要重新发链接。
为什么不要长期分发一次性转换结果
很多维护成本都来自“把临时结果当正式出口”。常见问题包括：
- 旧 query 参数散落在聊天记录里
- 切换上游后需要重新通知所有人
- 自定义请求头或多个来源难以集中管理
- 无法快速知道到底是谁在访问哪个固定地址
而固定 /dynamic 地址的好处是，把不稳定的上游变化收敛到站内后台维护。
一个可执行的迁移步骤
- 先在 convert 里把目标平台和参数调通
- 用客户端验证一次 /sub 输出
- 确认后进入 动态订阅管理
- 把多个来源、自定义 User-Agent 和手动节点收敛到 /dynamic
- 最后只分发固定地址
写给站长的建议
如果你要继续扩展文章区，这类内容很适合跟订阅工具一起出现，因为它解释的是“为什么要这样用”，而不是“按钮在哪里”。
用户在站内真正需要的，通常不是更多选项，而是更少的返工。
推荐工具与延伸阅读
- 先在 动态订阅转换 里把参数跑通，再进入 动态订阅管理 固定出口。
- 如果你还在整理原始节点或检查节点兼容性，可以先回到 节点转换。
- 如果你想把订阅源文件和分发边界再拆清楚，可以继续看 把配置文件放回仓库管理：什么时候该用 GitHub / GitLab / Gitee 文件工具。
发布教程、使用指南、问题排查和最佳实践，帮助用户理解工具价值。
怎么把转换结果变成长期可用的订阅链接
说明 convert、/sub、/dynamic 和订阅管理之间的分工，避免把一次性结果当长期出口。