插件、App 与主程序版本怎么对应
先记住三条原则
- 版本号不互相绑定：插件 0.6.2 起 App 与插件独立编号，插件版本 ≠ App 版本 ≠ 主程序版本，各查各的。
- 「不在表里」≠「不兼容」：兼容矩阵记录的是已验证的组合；未列出的版本不代表不能用，只是没被测过。0.3.6 起插件也不会仅凭版本号拒绝启动。
- 升级 dsh 后异常，先更新插件：主程序预览版接口变动快，插件跟进也快，多数「升级后不好使」靠更新插件解决。
已验证组合的查询方式
项目仓库的兼容性章节维护着完整矩阵：每个插件版本对应一列已验证的主程序版本，并标注验证范围（打包安装、隔离配对、移动页面启动、WebSocket 工作区读取等维度）。举几个参考点：
- 较新的插件版本（0.6.x）验证过主程序 0.2.0-rc.2、0.2.1-alpha.2 等预发布版本。
- 历史版本一路回溯到最早的 0.1.x 组合，每档都记录了验证内容。
- 完整清单以项目仓库的兼容性章节为准，本页不逐行复刻。
App 版本的功能分界
拿到旧版 App（比如网盘里的 0.2.0）时，这些功能边界要心里有数：
| App 版本 | 分界功能 |
|---|---|
| 0.1.3 及更早 | 需卸载重装并重新配对 |
| 0.3.3 起 | 无需重新配对的连续性保障（cpolar 用户建议 0.3.15+） |
| 0.4.0 起 | 多设备列表、启动行为设置、任务系统通知、电脑端撤销状态同步 |
| 0.4.6 起 | 自签 FRP 入口的远程 CA 固定 |
| 0.6.0 起 | 设备列表排序（上移/置顶）与长按抽屉返回列表 |
远程通道的 App 版本要求：自建 FRP 需 0.3.3+，自有反向代理需 0.4.0+。
升级后异常的排查顺序
- 核对实际运行的 dsh 命令与 profile 版本、插件安装路径。
- 对照矩阵看这个组合是否验证过。
- 更新插件到最新再试。
- 仍失败时，带版本号、模块路径与脱敏后的完整错误去项目仓库提 issue。