← 返回首页

profile 是叠加出来的，不是配出来的

2026-10-02 · 9 分钟阅读

第一次改 DSH 配置改不动的时候，我以为是插件没加载。后来才想明白：问题不在插件，在我没搞清楚配置是怎么叠起来的。

配置树从一个空根开始

DSH 的配置不是「一份文件」，而是从空根开始依次叠加的若干层。顺序是这样的：

  1. dsh.profile.bundles 里各组合包带的 patch
  2. profile 自己的 cordis.patch.yml
  3. home 级的 $DSH_HOME/cordis.patch.yml
  4. --patch 指定的覆盖层

越靠后优先级越高。这解释了一个常见现象：你在 profile 里改了一个字段，重启后没变化——因为 home 级那层把它盖掉了。

profile 目录结构本身很简单：一个 package.json（记录树外插件依赖 + dsh.profile manifest），加一个 cordis.patch.yml（用户自己的 patch）。

调配置之前先 dump，别猜

与其逐层推演，不如直接看组合后的结果。三个命令各有用处：

dsh --profile web --dump-config          # 组合后的最终配置树
dsh --profile web --dump-default-config  # 没叠加用户 patch 的默认值
dsh --profile web --dump-config-schema   # 插件声明的 JSON Schema

--dump-config 和 --dump-default-config 一比，就知道差异是「我改的」还是「插件默认的」。--dump-config-schema 输出的是描述 entry 与 patch 的 JSON Schema，不是配置值——它会在不启动应用的情况下导入组合树里插件声明的 schema。

如果你要 dump 不受信任的第三方插件，先读一下 schema dump 的安全性与范围说明，这个命令会实际导入插件代码。

两个容易踩的地方

desktop 这个名字不能碰

desktop 保留给 Electron 持有的 profile。CLI 会直接拒绝对它的启动和配置 dump 请求——不是权限问题，是设计如此。想建自定义 profile 换个名字。

HMR 开着和关着，行为不一样

启用 dsh-hmr 时，它会监视 profile manifest、profile 与 home 级 patch 文件，通过统一串行重载重新组合所有层。没启用的话，改动要重启才生效。

这里有个细节值得知道：监听器注册期间发生的编辑会被当作后续编辑处理，走同样的非致命重载错误报告路径。所以「改配置的那一刻正好在启动」不会导致状态错乱。

插件装到哪

dsh.profile.bundles 里列出的组合包，先从 dsh 安装目录解析（dsh-base、dsh-web-app 这些），再从 profile 自己的 node_modules 解析。pnpm 会把树外插件装进后者。

用 dsh plugin --profile <name> <pnpm 参数> 管理依赖，它会转发给 pnpm 并持有 profile 写锁——所以它和插件管理器不会打架。更新依赖时会保留已停用的组合包选择，不会把你之前关掉的插件又打开。

小结

理解分层顺序的价值不在于背下来，而在于知道「改配置没生效」时该去 dump 哪一层。顺序记不住没关系，命令记住就行。

profile配置层Cordis