[Bug] Windows 11 下文件链接把路径反斜杠转义吃掉，点击报「文件不存在」——是否已知？计划哪个版本修复？

[Joe-aip]

版本：DSH 桌面版 0.2.1-rc.3（win-x64），Windows 11 10.0.26200

DSH 团队好：

反馈一个 Windows 桌面版的确定性 Bug，已定位到前端 Markdown 渲染层，附最小复现与实测证据。

一、环境

• DSH 桌面版 0.2.1-rc.3（win-x64，nightly 通道）
• Windows 11 64 位
• 界面语言：简体中文

二、现象
在聊天回复里点击指向本地文件的 Markdown 链接，右侧文档页签打开后提示
「文件不存在，可能已被移动或删除」，但文件在磁盘上确实存在。
页签顶部的路径面包屑本身已经是坏路径，例如：
C:/Users/<用户名><.目录名>/<子目录>/<文件名>.md
（原文 C:\Users<用户名>.<目录名>... 中，. 前的反斜杠已被吃掉）

三、最小复现

1. 准备一个路径含「以 ASCII 标点开头的目录段」的文件，例如：
   C:\Users<用户名>.<目录名><子目录><文件名>.md
   X:<父目录>[data]<含空格目录><文件名>.md
2. 在回答里写文件链接，两种常见写法都会坏：
   反斜杠裸路径：
   文件
   路径含空格时只能用尖括号：
   [文件](<X:<父目录>[data]<含空格目录><文件名>.md>)
3. 点击链接 → 右侧页签显示「文件不存在」。

四、根因（实测，非推测）
DSH 前端渲染器（dsh-web-frontend 包内 vendor 的 micromark/mdast）在生成 link.url 时
对链接目标做了反斜杠转义解码：
. → . [ → [ _ → _ - → - ( → (
而字母、数字、中文前的反斜杠保留。
Windows 路径全程以 \ 为分隔符，因此只要路径中存在「以 ASCII 标点开头的目录段」
（.dirname、[dirname、_dirname、-dirname 等），分隔符就被吃掉，路径被拼错，最终 ENOENT。

实测对照（用安装包内原版 micromark 解析，再用真实寻址链校验）：
| Markdown destination | 解析后 link.url | 结果 |
| C:\Users<用户名>.<目录名><子目录>\a.md | C:\Users<用户名>.<目录名><子目录>\a.md | 不存在 |
| <X:<父目录>[data]<含空格目录>\a.md> | X:<父目录>[data]<含空格目录>\a.md | 不存在 |
| X:/<父目录>/.<目录名>/<含%20空格目录>/a.md | 原样（%20 保留） | 正常打开 |
| <X:/<父目录>/.<目录名>/<含空格目录>/a.md> | 原样（空格保留） | 正常打开 |

补充：按 Markdown 规范，destination 含空格时裸写根本不生成链接（显示为纯文本），
因此用户/模型只能用 <> 包裹；而 <> 内的反斜杠转义同样被解码，等于 Windows 路径
没有可用的反斜杠写法（只剩正斜杠）。

五、期望行为
点击本地文件链接应在侧栏预览中打开正确文件；Windows 反斜杠绝对路径应原样传递，
不应做反斜杠转义解码。

六、建议修复方向

1. 渲染层对文件路径 destination 跳过反斜杠转义解码：可用 AST 节点的 position
   从原始 Markdown 源串切片取 destination（保留原始反斜杠）；或对「盘符开头 /
   UNC 开头」的路径豁免 escape 解码。
2. 可用性改进：侧栏 not-found 错误里直接显示宿主实际尝试读取的路径（现在只显示
   「文件不存在」，用户无法判断是拼错还是文件真缺）。

七、临时规避（已验证）
链接改用正斜杠绝对路径，空格写 %20，例如：
文件

八、补充说明
本帖未附图片；如需，我可以补充最小复现脚本（脚本内路径已全部脱敏为占位符）。

谢谢！

[PerryLink]

这是 Markdown 的转义规则吃掉的，不是路径解析丢的。写法换成正斜杠就能绕开。

[文件](C:\Users\x\.cache\a.md) 在 CommonMark 里 \. 是转义序列，链接 destination 解析出来就变成 C:\Users\x.cache\a.md。前端两个消费点拿到的已经是这个坏值——packages/client/ui-primitives/src/markdown/file-link.ts:16 和 packages/client/ui-chat/src/client/chat/AssistantMarkdown.tsx:25——它们只做 decodeURIComponent，不会把反斜杠还原回去。

今天就能用的两种写法：

[文件](C:/Users/x/.cache/a.md)
[文件](file:///C:/Users/x/.cache/a.md)

Windows API 接受正斜杠，页面和资源地址都会正常。尖括号包空格的那种写法同样受转义规则影响，换斜杠后一起解决。

上游要修的话，位置在 markdown 解析层而不是这两个消费点：要么保留原始 destination（micromark 的 token 上还留着 raw），要么在进 parser 之前把 Windows 反斜杠路径转成 file:// URL。只在消费点加还原是不够的——\. 和真正的 . 已经分不开了。