[Bug] macOS 大型工作区反复进入 LSP 设置页触发高 CPU 和界面卡顿 #1550

Platform / 平台

macOS

Area / 模块

Settings / 设置

Lithe version / Lithe 版本

实际故障安装包：Lithe 0.6.5，build 58，LitheBuildGitRevision=a360c09a88ed7fa8d8a1d352d292a117c4109d26，构建时间 2026-10-25T05:42:39Z。信息来自运行包 Info.plist，不是用当前源码 HEAD 代替故障版本。对应的 LSP 设置页文件遍历逻辑在检查时的 preview 基线 0beb43c936f61e68b983533805d6534a01fdf8b4 中仍存在。

Priority / 优先级

P1 / 尽快处理：使用体验大幅下降，但通常仍可继续使用

OS and architecture / 操作系统与架构

macOS 27.0.1（26A434），Apple M2／arm64，8 核、16 GiB 内存，本地物理机。

Environment / 环境信息

• 故障入口：已安装的 macOS 应用，打开大型本地工作区后进入“设置 › 语言与框架 › LSP”。应用使用简体中文；安装来源、此前升级路径、最后正常版本及原故障时屏幕/主题参数未单独采集。
• 规模：原工作区包含依赖目录；当时 LocalHistory 索引有 302408 项文件记录。该数字是历史记录统计，不等同于精确的源码文件清单。未公开私人项目名称或源码。
• 精确回归夹具：另用本机临时目录内的 300007 个合成文件验证修复，其中 300000 个空 .fixture 文件，加 Main.java、index.php、main.go、Dockerfile、main.swift、app.ts 和 settings.json。不把修复后的夹具结果冒充旧安装版的复现数据。
• 原故障应用随包 Java Support：dev.lithe.plugin.java-support 1.0.0。其他插件的完整启用组合未导出；采样时应用只有监督器子进程，没有发现由该应用启动的 Java/Go 等语言服务器或编译进程，因此本报告定位的是设置页主线程识别文件的成本，未认定为 JDT LS 索引问题。
• 最近明确复现：2026-10-28 10:27～10:34（UTC+8）。没有为复现而重启/升级故障实例、删除历史或清缓存。切回普通工作区后 CPU 曾降至低位，再进入 LSP 页面又出现高负载；不是“只有启动后第一次进入”这一条件。
• 最初机器还有其他应用及 Spotlight 的后台负载；它们可能影响整机体验，但本报告依据独立进程 CPU 和 Lithe 主线程栈归因，没有将其 CPU 计入 Lithe。
• 原工作区精确源码体积、目录深度、文件系统大小写设置、swap/磁盘 I/O、最小插件组合及多显示器影响未采集，未声称完成这些隔离。网络、JDK/Maven 运行版本没有用于解释该纯文件名识别调用链；Windows、远程、虚拟机和容器未验证。
• 修复辅助验证采用 Swift 6.4／Xcode 27.1 的独立 ARM64 Release 测试包，未替换安装版。仓库固定 Swift 6.3.3／Xcode 26.6 的验证待 PR CI 完成。

Steps to reproduce / 复现步骤

1. 在上述安装版打开包含大量文件及依赖目录的工作区，等待已有项目加载完成；无需主动启动语言服务器或构建项目。
2. 打开设置，选择“语言与框架 › LSP”，观察 Lithe 主进程 CPU 和界面响应。
3. 离开 LSP 页面或关闭设置，等待 CPU 回落后，再次进入同一项目的 LSP 页面。
4. 在高负载阶段采样 Lithe 主进程。原会话的两次独立线程采样都落在同一设置页计算调用链；尚未声称每一种项目、每次点击都会发生相同持续时间或峰值。

Expected behavior / 预期行为

LSP 页应使用工作区文件快照的语言使用摘要，避免在 SwiftUI 主线程渲染、状态变化和相同快照反复进入时重复遍历大型文件列表。首次识别可以后台计算并显示加载状态；完成后应复用摘要，文件快照或规则变化时正确失效，同时保留语言开关和插件提示行为。

Actual behavior / 实际行为

• 单纯重新进入 LSP 设置页即可触发约 90%～110% 的 Lithe 主进程 CPU，观察到的单次间隔读数最高 110.4%；macOS 此处约 100% 表示占用一个逻辑核心，不表示占满整台机器。
• 界面读取发生超时，用户反馈偶发无响应；计算结束后负载和内存会回落，不能据此认定为无限循环或内存泄漏。
• 10:27:18 的 8 秒采样：主线程 4135 个样本全部处于 LSP 设置页视图计算链，其中 4046 个在 projectLanguageServers 下。另一次 5 秒采样：主线程 2285 个样本处于同一调用链，其中 2261 个在 projectLanguageServers 下。采样计数不是精确每次调用耗时。
• 源码对应 LSPControlCenterView.projectLanguageServers 对多个语言分别检查 model.projectFiles，插件提示的 projectUses 也会检查同一清单；匹配过程中反复提取 URL 文件名/扩展名。SwiftUI 重算会重复执行这些工作。
• 普通设置操作也可能有短时 CPU 波动，不能把本报告写成“任何非 LSP 页面都没有峰值”。关闭设置时偶发的约 168% 峰值尚未确认与本问题同源，明确排除在本报告和本次修复范围外。
• 初步修复已经完成并有独立 Release 回归：快照摘要后台计算与复用后，10 次热切页的扫描入口命中为 0；稳定停留 69.87 秒的主进程平均 CPU 为 1.70%。这是合成夹具的修复后数据，不是原安装版的基线。

查重：本次检索了全部状态的 LSP CPU、设置 卡顿、LSP 设置 以及开放 PR。#1245 处理工作树扫描范围、URL 持有和侧栏查找；#1526 处理 Java 服务启动竞态/启动参数/重试。它们未直接覆盖本次 LSP 设置页反复文件识别的调用链，未找到直接对应的报告或在修 PR。

Logs or diagnostic output / 日志或诊断输出

# 以下为原会话 sample/top 结果的人工脱敏摘要，不是伪造的产品日志。
# 时间：2026-10-28，UTC+8；对象为 Lithe 主进程。
10:27:18 sample_duration=8s main_samples=4135 projectLanguageServers_samples=4046
second_sample duration=5s main_samples=2285 projectLanguageServers_samples=2261
reenter_LSP interval_CPU=approximately_90_to_110_percent max_interval_CPU=110.4_percent

# 采样定位的调用关系（已省略本机路径、进程/线程标识）：
LSPControlCenterView.body
  -> projectLanguageServers
  -> provider file matching over model.projectFiles
  -> Foundation URL filename / extension extraction

# 同轮另有 pluginNotices / projectUses 遍历文件清单的采样证据。
# 采样时未发现应用启动的语言服务器或编译子进程。

Screenshots or recordings / 截图或录屏

本次未附公开截图或录屏。原始诊断包可能含本机路径和私人项目标识，未直接上传；正文提供已脱敏的采样摘要、复现条件和源码调用链。修复后的原生 GUI 回归已检查语言列表、Go/PHP 插件提示和 Java 已关闭偏好，并完成 10 次切页及 10 次设置窗口重开。

Checklist / 提交前检查

• I searched existing issues for duplicates. / 我已搜索现有 Issue，确认没有重复报告。
• I removed secrets and personal data from the report. / 我已从报告中移除敏感信息和个人数据。