Bolt.Diy 项目中终端命令执行卡顿问题的分析与解决

问题现象

在使用 Bolt.Diy 项目(v0.0.7 Docker 版本)配合本地运行的 Ollama 和 Qwen2.5-coder:7b 模型时，用户反馈在执行某些命令时会出现终端卡顿现象，命令无法正常完成执行，而是进入无限加载状态。

问题根源分析

经过技术团队深入排查，发现该问题主要由两个关键因素导致：

1. 文件监控机制的内存泄漏：在 app/lib/stores/previews.ts 文件的第156行处，webcontainer.internal.watchPaths 方法的配置中设置了 includeContent: true，这会导致每当监控的文件发生变化时，系统会将整个文件内容存储在内存中。随着文件变更次数的增加，内存占用会不断累积，最终影响系统性能。

2. 终端控制序列处理不完善：在 shell.ts 文件中，waitTillOscCode 方法与终端控制字符(\x03)的处理逻辑存在缺陷，导致在某些情况下终端状态无法正确恢复，从而出现命令卡死的情况。

解决方案

1. 文件监控优化

修改 app/lib/stores/previews.ts 文件中的配置：

// 原配置（存在问题）
webcontainer.internal.watchPaths({
  include: ['/*'],
  exclude: ['/node_modules', '.git'],
  includeContent: true
});

// 修改后的配置
webcontainer.internal.watchPaths({
  include: ['/*'],
  exclude: ['/node_modules', '.git'],
  includeContent: false
});

这一修改显著降低了内存使用量，因为系统不再需要存储文件变更的完整内容，只需记录变更事件本身。

2. 终端控制序列处理优化

调整 shell.ts 文件中的相关逻辑：

this.terminal.input('\x03');
if (state && state.executionPrms) {
  await state.executionPrms;
}
await this.waitTillOscCode('prompt');

这一修改确保了在发送中断控制字符后，系统会正确等待当前命令执行完成，并确认终端已返回提示符状态，从而避免了状态不一致导致的卡顿问题。

实施效果

经过上述修改后，Bolt.Diy 项目中的命令执行稳定性得到了显著提升：

• 终端响应更加及时
• 长时间运行不再出现内存泄漏
• 命令中断和恢复流程更加可靠

技术建议

对于使用类似技术栈的开发者，建议注意以下几点：

1. 文件监控策略：谨慎选择文件监控的粒度，避免不必要的内容存储
2. 终端控制序列：正确处理各种控制字符和状态转换
3. 资源管理：在容器化环境中要特别注意内存使用情况

该问题的解决不仅修复了当前版本的问题，也为后续版本优化性能奠定了基础。技术团队表示将在未来版本中进一步优化安装和执行时间，提升整体用户体验。