← 返回列表
⚠ 装前注意
修复 DSH 在 Windows 上「在文件资源管理器中显示」失效的问题。以用户插件形式实现，因此不受 dsh…
基本兼容但装前注意：未发布到 npm registry，仅可从源码安装 · 最近上游提交 2026/9/11 · 已提供中文文档
修复 DSH 在 Windows 上“在文件管理器中显示”静默无反应的问题。用户空间插件——在 dsh 升级后依然有效，不修改任何核心文件。
综合分
28.9
GitHub 分
28.9
用户评分
—
★ Stars
0
周下载量
—
安装插件（需先安装 dsh CLI 引擎：npm install -g @deepseek-ai/dsh）
dsh plugin --profile web add HeJian2002W/dsh-reveal-fix未发布到 npm registry，仅可从源码安装，改用 GitHub 源安装
信任档位：已验证本站已于 0 天前真实安装成功
- 是什么
- dsh 原生插件 · market
- 装得上吗
- 本站已真实安装成功（非静态推断）
- 安全吗
- 本站尚未对该插件做风险分级（暂未覆盖，不等同于无风险）
- 还在维护吗
- 活跃：最近一次提交在 14 天前
档位由下列信号合成：本站实装验证（真实安装，当前最高到 L4）· 验证所用 dsh 版本 · 静态安装检查 · 风险分级 · 仓库维护状态。下方各区块是它的证据明细。 验证判据与等级说明 →
🟢实装验证通过· 2026/9/25
由本站实装验证器在真实 dsh 环境安装成功，非静态推断。
数据截至 2026/9/22（元数据每日更新 · 实装验证按队列轮转，单条结论的验证时间见上方）
安装兼容性检查⚠ 装前注意
以下结论由程序自动检查 npm 包、engines 声明与入口文件得出，未做人工实机验证——能装不等于用着没问题。
✗npm 包dsh-reveal-fix（未发布到 npm，仅可源码安装）
✓Node 引擎未声明 engines.node
✓dsh CLI 依赖未声明 dsh 版本约束
✓入口文件main/exports/bin 已声明
未发布到 npm registry，仅可从源码安装
验证方式：npm registry 存在性 + package.json 静态校验 · 最后验证 2026/9/24 04:22:33
用户评分
还没有人投票，来当第一个
订阅周报，不错过优质插件更新
每周一封 · 高评分插件 + 新用户活动
README
由 DeepSeek 最新模型翻译生成dsh-reveal-fix
修复 DSH 在 Windows 上「在文件资源管理器中显示」失效的问题。以用户插件形式实现，因此不受 dsh 升级影响。
症状
点击交付卡片上的「在文件资源管理器中显示」时：
- 接口返回 HTTP 204，界面提示「已请求在文件资源管理器中显示」
- 但屏幕上什么都不出现 —— 没有窗口、没有任务栏闪烁、没有报错
UI 报告成功，用户感知为零，且没有任何可供诊断的痕迹。
根因（上游两个独立缺陷叠加）
| # | 缺陷 | 后果 |
|---|---|---|
| A | revealNativePath() 把 pathToFileURL().href（百分号编码的 file: URL）交给 explorer.exe /select,，而它接受的是文件系统路径 | Explorer 无法解析，静默回退打开「桌面」。空格 → %20，非 ASCII → %E5%89%8D... |
| B | 共享 runner 硬编码 windowsHide: true，Node 将其转为 STARTUPINFO 的 wShowWindow = SW_HIDE，explorer.exe 把这个显示状态应用到它新建的窗口 | 窗口被创建成隐藏：IsWindowVisible() 返回 false，永不显示 |
为什么无法诊断：Explorer 无论成败退出码恒为 1（上游将其视为"已委派"吞掉）；HTTP 路由恒返回 204；前端提示文案与成功时完全相同。三者叠加使故障完全静默。
本插件的做法
在 sessionController 上替换 revealPath：
- 传纯 Windows 路径（单个 argv 元素，紧贴逗号）
- windowsHide: false，让窗口真正显示
- 非 Windows 平台回退到原实现
- 保留上游约定：Explorer 退出码 1 不视为失败
sessionController.openWorkspacePath() 内部是 await this.revealPath(...) 动态查找，因此在实例上替换方法即可生效，无需修改任何核心文件。
安装
从 GitHub 安装（推荐）：
dsh plugin --profile web add github:HeJian2002W/dsh-reveal-fix
从本地目录安装（离线 / 自己改代码时）：
dsh plugin --profile web add link:C:\Users\Admin\.dsh\local-plugins\dsh-reveal-fix
安装后重启 dsh 生效。
卸载：
dsh plugin --profile web remove dsh-reveal-fix
为什么不受升级影响
- 插件源码位于 ~/.dsh/local-plugins/，注册信息位于 ~/.dsh/profiles/web/
- 两者都在 dsh 安装目录之外；升级（temp 暂存 → 目录交换）不会触及
- 与核心安装 node_modules 里的手工改动不同，升级后无需重新打补丁
前提：上游若改变 sessionController.revealPath 的名字或语义，本插件需要同步更新。
因此仍建议把缺陷提给上游（@deepseek-ai/dsh-native-command），长期方案是修在源头。
验证
判定标准不是「窗口计数增加」——Shell.Application.Windows() 会列出隐藏窗口，计数无法区分可见与否。必须查 IsWindowVisible：
Add-Type -MemberDefinition '[DllImport("user32.dll")] public static extern bool IsWindowVisible(IntPtr h);' -Name W -Namespace Q
(New-Object -ComObject Shell.Application).Windows() |
ForEach-Object { "{0,-6} {1}" -f [Q.W]::IsWindowVisible([IntPtr]$_.HWND), $_.LocationURL }
修复前：目标目录窗口存在但 visible=False。
修复后：visible=True。
独立 A/B（同一命令，仅改一个变量）：
| 变量 | 结果 |
|---|---|
| pathToFileURL().href → /select, | 窗口落在 Desktop ❌ |
| 纯路径 → /select, | 窗口落在目标目录 ✅ |
| windowsHide: true | IsWindowVisible = False ❌ |
| windowsHide: false | IsWindowVisible = True ✅ |
已知残留（本插件不处理）
两个缺陷都修好后，浏览器仍会在约 1.7 秒后把前台焦点抢回（即使服务端调用 Win32 SetForegroundWindow 强制置顶，同样在 1.7s 内被覆盖），窗口容易被压在浏览器后面。
若要改善，可在 reveal 后延迟约 2s 再断言一次前台。默认不启用：这会引入「用户已切去做别的事、窗口突然跳出来抢焦点」的副作用，属产品行为取舍。