dsh-file-path-repair — 图片路径修复
本地图片(聊天里的 Markdown 图片、会话文档预览)在取文件前,把被 Markdown 转义吃掉的分隔符还原回去。不靠提示词,不挑模型,不挑会话。
问题
本地图片走 /api/file?path=…,path 是 Markdown 解析器给出的目标。在链接目标里,反斜杠后跟 ASCII 标点会被当作 CommonMark 转义:
写出来的: 
解析得到: D:\桌面_out\shot.png ← \_ 的 \ 被吃掉
请求结果: 404 → 「图片无法预览 · alt」
这个还原在解析器里发生,早于客户端任何路径钩子(pathImages / fileImages),所以页面侧插件拿不到原始路径;而「让模型改成正斜杠」只对新生成的文字有效,别的智能体、历史消息都不管用。
做法
包住 /api/file 的处理函数:
- 原样交给原处理器;不是 404 就直接返回,正常路径零影响。
- 是 404 时,按「Markdown 转义只会发生在 ASCII 标点前」生成候选路径(把
\ 插回标点前,1~3 处组合,最小改动优先)。
- 每个候选都用 HEAD 走原处理器探测,也就是说仍然由组合出来的文件系统提供方(含沙箱策略)决定能不能读。
- 只有恰好一个候选存在时才用它重新取文件;两个都像,就保持原来的 404,不猜。
- 预算:单次最多 160 次探测、400ms。
边界
- 只在已经失败的请求上工作;目录依旧拒绝,不存在的文件依旧 404。
- 依赖 Connection 服务里的
fetchRoutes 表与 registerFetchRoute;上游如果改名,本插件会静默失效(不影响任何请求),不会把路径改成错的。
- 卸载时还原:路由的包装标记与
registerFetchRoute 都会被恢复。
测试
node test/repair.test.mjs
用真实文件系统 + 一个与官方行为一致的假处理器,覆盖:正常路径、被吃掉分隔符的路径、HEAD、两个候选的歧义、无可修复、指向目录。