0.39-0.40.1 web 陷入死循环等待响应

What version of Kimi Code is running?

0.40.1

Which open platform/subscription were you using?

订阅会员

Which model were you using?

k3

What platform is your computer?

windows10

What issue are you seeing?

0.39-0.40.1 web 陷入死循环等待响应

What steps can reproduce the bug?

问题定位

1. 崩溃点确认在 markstream 渲染器的 validateLink 补丁层

kimi.exe 内嵌了 web 前端，Markdown 渲染用 markdown-it + markstream 流式渲染器。二进制里能看到一套对 validateLink 的 monkey-patch：

给实例打 __markstreamOriginalValidateLink 标记，保存原始引用；

每次渲染 link/image 规则前临时 swap md.validateLink，finally 里恢复；

还有一个四级回退的委托选择：n.validateLink ?? g ?? m.options?.validateLink ?? m.validateLink。

这种"保存原引用→临时替换→恢复"的多层补丁，一旦委托链成环（某层的 fallback 指回 wrapper 自身），就会出现你抓到的 validateLink → String.replace 交替帧无限递归 → Maximum call stack size exceeded。而且 kimi 自己还注册了一层自定义校验（l => !Wh(l, {tagName:"a", attrName:"href"})，DOMPurify 风格的 URI 检查），叠加后共有 2~3 层 wrapper，成环条件更容易满足。

2. 版本回归的证据

~/.kimi-code/bin/kimi.exe = 0.40.1（9-03 08:35 升级），kimi.exe.bak = 0.40.0（9-02 15:58 升级时的旧件）

两版二进制中上述补丁代码逐字节一致，validateLink 出现次数也相同（25 处）——说明递归隐患是潜伏的，0.40.1 的回归更可能在 web 端哪些地方走这条渲染管线（比如会话列表标题、思考过程块也接了 markstream），让 bug 从"特定内容才触发"变成"必然触发"。0.40.1 公开 changelog 只列了一条修复，但二进制 diff 约 27KB，web 端改动并未全部披露。

3. 触发源实锤

本会话（b8ce5990）正文含裸 URL http://192.168.1.43:9019/xxxApp/...、26 处 Windows 路径、大段 MyBatis XML/SQL 报错（单条事件最大 ~20KB）

全局扫描：17 个会话的标题里带裸 URL/IP（大量 curl 'http://192.168.1.43:8081/...'，甚至有一条 https://www.kimi.com/...）

linkify 开了 fuzzyLink（二进制里 new Ej({fuzzyLink:!0})），裸 IP:端口 必然被自动识别为链接 → 每次渲染都进 validateLink

4. 为什么"每个会话都出错"+"卡住"同时出现

渲染崩溃没有 per-message 错误隔离：一条消息（或一个列表项标题）递归溢出 → Vue 整棵会话视图/列表树进 error boundary → 全部显示「出错了」。而"卡住"是两件事叠加：大段 XML 高亮 + typographer 流式重解析本身就慢（秒级），崩溃后的重渲染又会再次溢出，崩溃-恢复循环把主线程占满，表现为页面无响应。性能问题让你"卡"，validateLink 递归让你"崩"，叠加后就是"加载卡住然后出错了"。

我之前的"归档导致"判断因此修正：归档只是巧合（9-02 归档，9-03 升级 0.40.1 后才发现打不开），数据完全完好。

方案
A. 立即可用（不改数据）

绕开 web 渲染器：TUI 不走这套 Vue/markdown 管线，kimi --session session_b8ce5990-a579-4cb6-bd5e-aa5780121c02 可正常查看；或 /export-md / kimi export 导出阅读

回退验证版本假设：把 kimi.exe.bak（0.40.0）临时换回 kimi.exe（先备份现行版）。若 0.40.0 下 web 正常，即坐实 0.40.1 回归；这也是给官方报 bug 时最有力的对照实验

最小复现，二分触发集：新建会话分别只发 ① 裸 URL http://192.168.1.43:9019/x、② Windows 路径 C:\app...、③ 一段 20KB XML，看哪类必崩——能把"链接渲染崩溃"和"大 XML 卡顿"两个问题的触发集分开

B. 临时缓解（接受轻度改数据）

清洗带毒标题：TUI 进会话后用 /title 改成纯文本标题（官方支持的操作，不算手改文件）。如果崩溃发生在列表标题层，清掉 17 个含裸 URL 的标题即可恢复列表；若消息正文也崩，此招只治列表不治详情

不建议直接编辑 wire.jsonl（官方明确警告手改 sessions 目录可能导致会话无法恢复）；真要改（如把裸 URL 包进反引号 code span 避开 linkify），先整目录备份

C. 上报官方（根治路径）

kimi export session_b8ce5990-a579-4cb6-bd5e-aa5780121c02 -o repro.zip 生成诊断包，附：控制台完整堆栈、最小复现文本、0.40.0↔0.40.1 对照结果，提 issue。建议在 issue 里点名四个修复方向：

错误隔离：每条消息/列表项独立 error boundary，单条渲染失败降级为纯文本，不拖垮整棵树

补丁防环：swap 前检查 u !== 当前 wrapper；__markstreamOriginalValidateLink 已存在时跳过重复 patch；validate 改为不读写实例状态的纯函数

收敛链接识别：标题等非正文文本不走完整 markdown 管线，或对会话内容关闭 fuzzyLink 的裸 IP/域名 autolink

渲染性能：长会话虚拟滚动、大代码块高亮进 Web Worker 或 requestIdleCallback 分片、超长消息默认折叠

What is the expected behavior?

No response

Additional information

No response

Contribution

• I am willing to submit a PR for this bug fix myself (please wait for maintainer approval in this issue first)

No source file or test is named. Start by reproducing the failure with a bare URL, Windows path, and large XML, then compare web behavior between 0.40.0 and 0.40.1 while inspecting the markstream validateLink path; done means the web session view no longer loops or becomes unresponsive for the reported content.