帮助与生态
社区插件：选择、验证与回滚
把发现、兼容性、权限与回滚分开核验，降低安装第三方插件的风险
GitHub 话题、目录站和社群推荐只能帮你发现候选项目；它们不等于官方背书、完整安全审计或对你的 profile 一定兼容。把「找得到」和「可以装」分开判断，能显著减少供应链与升级风险。
用四层证据判断一个插件
| 证据层 | 可以确认什么 | 仍不能确认什么 |
|---|---|---|
| 发现 | 项目、包或仓库存在 | 身份、兼容性与安全性 |
| 来源与清单 | 维护者、安装来源、版本或提交，以及 dsh.bundle 声明 | 运行时行为和依赖风险 |
| 兼容性 | 某个 DSH 版本下能安装，或在隔离 profile 中完成最小验证 | 所有功能、性能与安全性 |
| 运行审阅 | 有可追溯的版本、测试记录或近期维护信号 | 第三方安全认证或长期可用性 |
状态不是安全结论
“已收录”、“clean”、“兼容”或“已验证”只描述相应索引或测试的范围，不等于代码已经过完整安全审计，也不保证所有 profile、平台和依赖组合都能正常运行。
安装前检查清单
- 锁定来源。 从插件页跳到实际的 npm 包或代码仓库，核对组织/作者、仓库地址、许可和最近发布记录；警惕同名包与突然更换维护者。
- 锁定版本。 记录计划安装的包版本或 Git 提交；不要把“最新版”当作可复现的部署策略。
- 查看权限与依赖。 特别留意文件读写、命令执行、网络请求、令牌读取、安装脚本和间接依赖。功能越接近工作区与凭据，审查就应越严格。
- 核对兼容性。 比对插件声明或发布说明中的
@deepseek-ai/dsh版本，并查看上游的近期动态。不存在明确声明时，把它视为未知，而不是默认兼容。 - 先在隔离 profile 试装。 不要用包含生产密钥、真实代码库或日常插件组合的 profile 做第一次安装。
- 留下回滚信息。 保存安装前后的 profile 配置、实际安装命令、版本/提交和最小测试结果；确认移除插件后能恢复到原先的组合。
在隔离 profile 做最小验证
先为试验建立单独的 profile，再使用固定版本或固定提交的安装来源。例如：
dsh plugin --profile plugin-sandbox add <package>@<version>
# 或使用经核验的 Git 仓库与固定提交
dsh plugin --profile plugin-sandbox add github:<owner>/<repo>#<commit>随后只执行插件声称支持的最小任务，并记录 DSH 版本、插件版本、操作系统、权限提示和日志。验证后，可用同一 profile 中的 remove <package> 撤销该包；在把它迁入常用 profile 前，再复核锁定版本和配置差异。完整命令语法见插件管理。
如何使用 cordis.run
cordis.run 可作为发现入口。若插件页提供安装来源、版本、上游链接或状态，请把这些当作带时间点的索引信号：复制之前先打开上游来源，再按上述清单确认。页面上的安装命令适合用在隔离 profile 做第一轮验证，不应跳过源码、权限与兼容性审查。
如果你发现条目信息过期、来源不一致或安全提示有误，应向对应站点或上游项目报告，而不是依据目录状态继续部署。
延伸阅读
- whyihaveyou/dsh-suite：将插件兼容状态与更新时间公开，适合作为查看可追溯状态的例子。
- AdamPlatin123/awesome-dsh-plugins：提出从发现到运行验证的证据层次；这里采用了其“证据范围要说清楚”的思路，而非替其背书。
- zp-home/dsh-recommend：把静态安全提示与安全认证区分开，值得作为阅读目录信息时的提醒。