Desktop 文件树展开卡顿/无响应，/open 搜不到文件（Agent + LSP 与 UI 资源争用）

Desktop 文件树展开卡顿/无响应，`/open` 搜不到文件（Agent + LSP 与 UI 资源争用）

概述

opencode Desktop（v1.18.4，Windows）文件树点击目录时不时无反应（不发出请求），偶尔发出请求时先收到 204、随后 GET 响应很慢（"一开始没回复，过一会才出内容"）。导致子目录无法展开、/open 命令搜不到该子树下的文件。

网页端（同账号同项目）无此问题。

复现环境

opencode Desktop: v1.18.4
OS: Windows (win32)
项目规模: git 跟踪 ~2686 文件，含 226 个 JAR + 4 个 LYR 二进制；目录嵌套深（8+ 层）
LSP: jdtls（Java 21）对 1600+ 个 .java 文件提供诊断
同机其他负载: 多个 java.exe 进程（应用服务器/Tomcat）

复现步骤

打开一个大项目（如 monorepo，数千文件 + LSP 启用）
等待 jdtls 索引完成
在文件树点击一个目录（如 Server/）
观察：多数点击无反应；偶尔发出请求 → 先 204 → GET 响应延迟数秒
在 Agent 会话进行中（尤其长回复流式输出时）上述现象更明显

预期行为

点击目录应即时展开；/open 应能搜到项目内所有 git 跟踪文件。

实际行为

文件树目录点击频繁失效（click 事件被丢弃）
偶尔触发的 file.list 请求响应缓慢
受影响子树下的文件在 /open 中不可搜索

根因分析（逆向 app.asar + 系统级验证）

1. 文件树机制

文件树懒加载：点击展开目录 → 前端调 HTTP API

sdk().client.file.list({ path: dir })  //  GET http://127.0.0.1:<port>/file?path=<dir>

服务端 handler（FileHttpApi.list）调用 FileSystem.list → fs.readdir(dir, { withFileTypes: true })——非递归，仅列直接子项
客户端 createFileTreeStore 对在途请求做去重（inflight / loaded 状态）

2. 204 是 CORS 预检（非 Bug）

Electron 渲染进程用自定义 scheme oc://，API 在 http://127.0.0.1:<port>——跨源，每次 GET 前自动发 OPTIONS 预检返回 204。这是正常浏览器行为，非问题根因。

3. 目录列出本身不慢（已排除"目录过大"假设）

直接测试	结果
Node `fs.readdirSync('Server')`	1ms（4 entries）
Node `fs.readdirSync('.../dependencies')` 152 JAR	1ms
GET `/file?path=Server` 往返（Agent 空闲时）	3-5ms

Handler 逻辑极快，慢不在目录规模或二进制文件数量。

4. 真正根因：间歇性事件循环 / 渲染线程阻塞

慢是间歇性的（用户报告慢，但空闲时测仅 3-5ms）。这种模式指向 Desktop 单机架构下的资源争用：

① "时不时没有反应（不发出请求）" → Electron 渲染主线程被占用

渲染进程在同一主线程上处理：Agent 流式输出渲染（长 markdown/代码块）+ jdtls 诊断推送渲染。当主线程繁忙时，click 事件被丢弃——不是请求没回应，而是点击根本没触发请求。

② "response 慢，延迟出内容" → Node 服务端事件循环被占用

opencode 服务端跑在 Electron 的 Node utility 进程内，与 Agent 工具执行、jdtls 通信、git 操作共享同一个事件循环。当事件循环繁忙时，UI 的 file.list 请求在队列中等待，表现即"一开始没回复，过一会才出现"。

③ 网页端不受影响：Agent + LSP 在远程服务器执行，浏览器只做展示，不与 UI 争本地 CPU。

5. 本机负载佐证

同机运行 8 个 java.exe（最重者累计 2324s CPU）+ jdtls + Electron 主/渲染/Node 服务进程，CPU 争用明显。

与配置无关

opencode.json 无路径过滤配置
.gitignore 未屏蔽受影响目录（Server/ 本身未被忽略）
受影响文件已 git add 跟踪（排除"未跟踪导致不显示"）
Desktop 日志无文件树相关错误（静默失败）

影响

大项目中文件树几乎不可用（目录展不开）
/open 无法搜索到不可展开子树下的文件，严重影响开发效率
迫使开发者切回网页端或用外部编辑器浏览文件

改进建议

文件树请求优先级：file.list 等 UI 请求应在事件循环中优先于 Agent 工具调用调度，避免被长任务阻塞
渲染线程减负：Agent 输出 / LSP 诊断的渲染不应阻塞文件树等核心 UI 交互（考虑 Web Worker 或分片渲染）
file.list 缓存：对已加载目录缓存结果，减少重复请求（当前 loaded 状态已有简单去重，但刷新策略可优化）
CORS 预检优化：考虑对 oc:// → http://127.0.0.1 的本地请求免预检（如改用同 scheme 或 Permissions-Policy），减少每次展开的往返
性能诊断：在 DevTools Network 增加 file.list 耗时埋点，或在服务端日志记录 handler 耗时，便于定位阻塞源

附：关键源码位置（app.asar）

内容	偏移量
`createFileTreeStore`（树状态 + 懒加载）	@104747839
`options.list` → `sdk().client.file.list({path})`	@104753678
`FileHttpApi.list` handler（read .gitignore + `fs16.list` + ignore 检查）	@79381174
`FileSystem.list`（`fs.readdir` 非递归）	`exports_filesystem3.Service`
`readDirectoryEntries`（`fs.readdir(dir, {withFileTypes:true})`）	FSUtil layer

标签建议

bug, desktop, performance, file-tree, windows

Description