本地VS Code Dev Container终端性能极差的原因是什么

该终端卡顿问题和硬件配置无关，核心触发原因是WSL2跨文件系统挂载的IO性能瓶颈，具体逻辑：

• 本地测试时，你将代码仓库克隆到了Windows系统的NTFS分区，启动本地Dev Container时，基于WSL2运行的Docker Desktop会将该Windows路径通过bind mount方式映射进容器内部。
• WSL2访问Windows挂载分区（即容器内看到的挂载代码目录）的IO性能远低于WSL2原生ext4虚拟磁盘的性能，小文件随机读写的性能差距可达上百倍。
• bash/zsh加载提示符、每次执行完命令返回提示符的过程中，会自动运行一系列前置检查：当前目录Git工作区状态、文件权限信息、虚拟环境识别、路径缩写计算等。这些操作需要频繁读取挂载目录下的文件元数据，跨文件系统的高延迟直接将原本毫秒级的操作拉长到数分钟。
• 浏览器访问远程Codespaces、VS Code远程连接Codespaces无卡顿，是因为云端Codespace的代码存储在Linux原生文件系统上，没有跨系统挂载开销；VS Code编辑等功能无卡顿，是因为Dev Containers扩展对文件读写做了专属缓存优化，但容器内终端运行的shell进程没有这层缓存加速，所有文件操作直接走低性能的跨系统挂载通道。

可以通过两个操作快速确认根因：

• 在卡顿的容器终端执行cd /切换到容器原生Linux目录（非挂载的Windows代码目录），执行任意简单命令，如果提示符瞬间返回，即可确认是挂载IO问题。
• 临时关闭shell提示符的Git状态检查（比如使用oh-my-zsh可执行git config --global oh-my-zsh.hide-status 1，原生bash可临时注释.bashrc中Git提示符相关配置），切回代码目录后卡顿会直接消失。

按效果优先级排序：

• 最优方案：不要将Dev Container相关的代码仓库存储在Windows NTFS分区，直接将仓库克隆到WSL2发行版的原生ext4文件系统中（可在资源管理器地址栏输入\\wsl$\打开WSL存储路径，将代码放入对应发行版的home目录下），再从该路径启动Dev Container，终端性能可达到和远程Codespaces一致的水平。
• 次优方案：如果必须将代码存在Windows分区，可调整shell配置，关闭提示符中的Git状态、文件权限类自动检查，比如使用极简提示符、关闭oh-my-zsh/starship等工具的Git相关模块，可大幅降低卡顿，但无法彻底消除跨系统IO的固有开销。
• 临时缓解方案：在Docker Desktop设置中开启WSL2后端的文件系统缓存选项，可一定程度降低延迟，但无法从根本解决问题。

内容的提问来源于stack exchange，提问作者gbro3n