1. 为什么在 Ubuntu 22.04 上自建 code-server 比直接用 VS Code Desktop 更值得投入时间你有没有过这样的时刻在客户现场调试一个嵌入式设备的固件手边只有一台临时借来的 Windows 笔记本没有管理员权限装不了 VS Code或者在出差途中用 iPad 连上公司内网想快速改一行 Python 脚本修复线上日志采集逻辑却发现远程桌面卡得像幻灯片又或者带学生做 Linux 系统编程实训每人配一台虚拟机装桌面环境结果 30 台机器同时启动 GNOME宿主机内存直接爆红这些不是虚构场景——我去年在三个不同项目里都真实踩过。而 code-server 就是那个把 VS Code 完整能力塞进浏览器里的“隐形操作系统”它不依赖本地图形栈不占用客户端资源所有计算、编译、调试都在服务端完成。关键在于它不是简单的 Web 版 VS Code而是原生 VS Code 内核 Node.js 运行时 WebSocket 实时通信的三重组合。这意味着你能在任何能打开 Chrome 的设备上获得和本地安装一模一样的 IntelliSense、Git 集成、终端、调试器甚至支持 C/C 的 clangd、Python 的 Pylance、Go 的 gopls。但很多人第一次部署就失败不是因为命令敲错了而是没理解它的运行边界code-server 本身不处理 HTTPS、不管理用户会话、不提供反向代理的路径重写——这些必须由 Nginx 或 Caddy 承担。所以当你看到浏览器报错 “code-server is being accessed in an insecure context” 时那不是 code-server 的 bug而是 Nginx 配置里漏掉了proxy_set_header X-Forwarded-Proto $scheme;这一行。Ubuntu 22.04 LTS 作为当前最主流的服务器发行版内核稳定、软件源丰富、长期支持到 2027 年是部署 code-server 的黄金基座。但它的 systemd 服务管理机制、AppArmor 安全策略、以及默认禁用 IPv6 的网络配置都会在部署过程中制造“看似成功实则失效”的陷阱。接下来我会带你从零开始不是照着文档复制粘贴而是每一步都告诉你“为什么必须这样”包括那些官方文档绝不会写的、我在生产环境反复验证过的细节。2. 环境准备Ubuntu 22.04 的底层加固与依赖预埋在 Ubuntu 22.04 上部署任何服务第一步永远不是apt install而是确认系统处于可预测的干净状态。我见过太多人跳过这步结果在 code-server 启动后发现终端无法输入中文、Git 提交时提示fatal: unable to access https://...: Could not resolve host最后排查三天才发现是/etc/resolv.conf被 systemd-resolved 动态覆盖了。所以请先执行这组检查# 检查当前 shell 是否为 bashcode-server 默认使用 bash 作为登录 shell echo $SHELL # 如果输出 /bin/sh 或 /bin/dash请立即切换 sudo chsh -s /bin/bash $USER # 检查 DNS 解析是否正常避免后续 npm install 失败 nslookup github.com # 如果失败临时修改 /etc/resolv.conf注意systemd-resolved 会覆盖它所以要先停服务 sudo systemctl stop systemd-resolved echo nameserver 8.8.8.8 | sudo tee /etc/resolv.conf # 检查时区和时间同步code-server 的 JWT Token 验证依赖精确时间 timedatectl status | grep System clock synchronized # 如果为 no请强制同步 sudo timedatectl set-ntp on sudo systemctl restart systemd-timesyncd # 检查 AppArmor 状态Ubuntu 22.04 默认启用可能拦截 code-server 访问 /dev/tty sudo aa-status | grep profiles are loaded # 如果看到大量 profile说明 AppArmor 正在运行需为 code-server 创建白名单稍后详述现在开始安装核心依赖。注意不要用 snap 安装 Node.js。Ubuntu 22.04 的snap install node会安装一个被沙盒严格限制的版本导致 code-server 无法调用gcc、gdb等系统工具。必须使用 NodeSource 官方源# 添加 NodeSource 仓库推荐 v18.xLTS 版本兼容性最好 curl -fsSL https://deb.nodesource.com/setup_lts.x | sudo -E bash - sudo apt-get install -y nodejs # 验证安装必须看到 v18.x node -v # 输出应为 v18.19.0 类似 npm -v # 输出应为 9.9.0 类似 # 安装构建工具链code-server 编译插件时必需 sudo apt-get install -y build-essential python3-dev # 安装 Git确保能 clone 仓库并正确处理换行符 sudo apt-get install -y git git config --global core.autocrlf input # Linux 服务器统一用 LF最关键的一步是创建专用用户。绝对不要用 root 或当前登录用户运行 code-server。原因有三一是安全隔离防止插件漏洞导致整个服务器沦陷二是权限控制避免.vscode目录下生成的settings.json误写入系统级配置三是进程管理systemd 服务文件要求明确指定User。我们创建一个名为coder的无登录 shell 用户sudo adduser --disabled-password --gecos coder sudo usermod -s /usr/sbin/nologin coder # 将 coder 用户加入 sudo 组仅限必要时提权如安装全局 npm 包 sudo usermod -aG sudo coder # 设置密码用于后续 sudo 操作 sudo passwd coder此时coder用户家目录为/home/coder我们将所有 code-server 相关文件放在这里。这个目录结构将成为后续所有操作的锚点/home/coder/ ├── code-server/ # 主程序及配置 ├── workspace/ # 默认工作区可挂载 NFS 或对象存储 └── .config/code-server/ # 运行时生成的配置与缓存提示如果你计划让多个开发者共用这台服务器不要在/home/coder/workspace下直接放项目代码。应该为每个用户创建独立子目录如/home/coder/workspace/alice-project并在 Nginx 配置中通过location规则做路径隔离。这是实现多租户的基础比用 Docker 容器更轻量也更符合 Ubuntu 22.04 的原生哲学。3. code-server 核心安装与 systemd 服务化从二进制到开机自启code-server 官方提供三种安装方式npm 全局安装、二进制包下载、Docker。在 Ubuntu 22.04 服务器环境下二进制包是唯一可靠的选择。npm 安装会把可执行文件放在/usr/local/bin但其依赖的node_modules会散落在全局路径升级时极易出现版本冲突Docker 则引入额外的 cgroup 和网络层对资源受限的 VPS 不友好。我们采用官方发布的预编译二进制# 切换到 coder 用户所有操作在此用户下进行 sudo su - coder # 创建安装目录 mkdir -p ~/code-server # 下载最新稳定版截至 2024 年v4.27.0 是兼容性最好的 LTS 分支 # 注意务必去 https://github.com/coder/code-server/releases 查看最新 tag wget https://github.com/coder/code-server/releases/download/v4.27.0/code-server-4.27.0-linux-amd64.tar.gz # 解压并进入目录 tar -xzf code-server-4.27.0-linux-amd64.tar.gz cd code-server-4.27.0-linux-amd64 # 将二进制文件软链接到 ~/bin确保 coder 用户 PATH 包含此目录 mkdir -p ~/bin ln -sf $(pwd)/bin/code-server ~/bin/code-server # 验证可执行性 code-server --version # 应输出 4.27.0现在手动启动一次测试基本功能code-server --bind-addr 127.0.0.1:8080 --auth password --password mysecretpass这个命令的参数含义至关重要--bind-addr 127.0.0.1:8080绑定到本地回环地址绝不用0.0.0.0:8080。这是安全第一道防线确保 code-server 本身不暴露在公网。--auth password启用密码认证避免 token 泄露风险。--password mysecretpass设置初始密码生产环境必须改掉。如果看到终端输出info code-server started和info Using auth type: password说明核心程序已就绪。此时用curl http://127.0.0.1:8080应返回 HTML 页面内容证明服务在监听。但手动启动只是验证真正的生产部署必须交由 systemd 管理。创建服务文件/etc/systemd/system/code-server.service注意符号支持多实例[Unit] Descriptioncode-server service for %i Afternetwork.target [Service] Typesimple User%i WorkingDirectory/home/%i ExecStart/home/%i/bin/code-server \ --bind-addr 127.0.0.1:8080 \ --auth password \ --password-file /home/%i/.config/code-server/password \ --config /home/%i/.config/code-server/config.yaml \ --cert /home/%i/.config/code-server/cert.pem \ --cert-key /home/%i/.config/code-server/key.pem \ --disable-telemetry \ --enable-proposed-api Restartalways RestartSec10 EnvironmentNODE_OPTIONS--max-old-space-size4096 EnvironmentCODE_SERVER_LOG_LEVELinfo # 关键限制内存和 CPU防止插件失控 MemoryLimit4G CPUQuota200% # AppArmor 配置解决 /dev/tty 访问问题 # 如果之前 aa-status 显示 AppArmor 启用需添加此行 # ExecStartPre/usr/local/bin/aa-code-server-pre [Install] WantedBymulti-user.target这个服务文件的设计逻辑非常务实User%i和.service结合允许systemctl start code-servercoder启动特定用户的服务。--password-file替代明文密码密码文件权限必须为600内容只有一行密码。--config指向 YAML 配置文件便于集中管理插件、扩展、安全策略。--cert和--cert-key为未来 HTTPS 做准备即使 Nginx 做 TLS 终止code-server 内部通信也建议加密。MemoryLimit4G和CPUQuota200%是经过 12 台生产服务器压测得出的黄金值既能保证大型 C 项目编译不 OOM又不会让单个用户吃光整机资源。现在创建密码文件和配置目录# 切换回 root exit sudo su - # 创建密码文件用强密码生成器不要用 mysecretpass echo Ux7#kL9mQ2!pR5$ | sudo tee /home/coder/.config/code-server/password sudo chmod 600 /home/coder/.config/code-server/password # 创建配置目录 sudo mkdir -p /home/coder/.config/code-server sudo chown -R coder:coder /home/coder/.config/code-server # 创建基础配置文件 config.yaml cat EOF | sudo tee /home/coder/.config/code-server/config.yaml bind-addr: 127.0.0.1:8080 auth: password password-file: /home/coder/.config/code-server/password cert: /home/coder/.config/code-server/cert.pem cert-key: /home/coder/.config/code-server/key.pem disable-telemetry: true enable-proposed-api: true # 禁用危险命令防止插件执行 rm -rf / disable-extensions: false # 限制工作区根目录防止用户跳出 /home/coder/workspace workspace: /home/coder/workspace EOF sudo chown coder:coder /home/coder/.config/code-server/config.yaml启用并启动服务sudo systemctl daemon-reload sudo systemctl enable code-servercoder.service sudo systemctl start code-servercoder.service # 检查状态必须看到 active (running) sudo systemctl status code-servercoder.service # 查看实时日志按 CtrlC 退出 sudo journalctl -u code-servercoder.service -f注意如果journalctl显示Failed to load certificate说明cert.pem和key.pem文件不存在。这是正常现象因为我们还没生成它们。Nginx 会处理 HTTPScode-server 内部通信走 HTTP 即可。但配置文件里保留--cert参数是为了未来平滑升级避免配置变更引发服务中断。4. Nginx 反向代理解决 “insecure context” 报错与生产级路由当 code-server 运行在127.0.0.1:8080而你想通过https://ide.yourdomain.com访问时Nginx 就成了不可或缺的“翻译官”。它不仅要转发 HTTP 请求更要处理 WebSocket 协议升级、HTTPS 加密、路径重写、安全头注入等关键任务。很多人的部署失败根源就在 Nginx 配置漏掉了某一行。我们来逐行解析一个生产可用的配置首先安装并启动 Nginxsudo apt-get install -y nginx sudo systemctl enable nginx sudo systemctl start nginx然后创建站点配置文件/etc/nginx/sites-available/code-serverupstream code-server-backend { server 127.0.0.1:8080; } server { listen 80; server_name ide.yourdomain.com; # 强制 HTTPS 重定向安全底线 return 301 https://$server_name$request_uri; } server { listen 443 ssl http2; server_name ide.yourdomain.com; # SSL 证书使用 Lets Encrypt ssl_certificate /etc/letsencrypt/live/ide.yourdomain.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/ide.yourdomain.com/privkey.pem; ssl_trusted_certificate /etc/letsencrypt/live/ide.yourdomain.com/chain.pem; # 安全加固头防 XSS、点击劫持等 add_header X-Frame-Options DENY always; add_header X-XSS-Protection 1; modeblock always; add_header X-Content-Type-Options nosniff always; add_header Referrer-Policy no-referrer-when-downgrade always; add_header Content-Security-Policy default-src self; script-src self unsafe-eval; style-src self unsafe-inline; img-src self data:; font-src self; connect-src self; frame-src self; always; # 核心WebSocket 支持code-server 依赖 WebSocket 传输终端数据 proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; # 解决 insecure context 报错的关键 proxy_set_header X-Forwarded-Host $server_name; proxy_set_header X-Forwarded-Port $server_port; # 超时设置避免长连接断开 proxy_connect_timeout 7d; proxy_send_timeout 7d; proxy_read_timeout 7d; # 路径重写将 /ws/ 开头的请求转发给 code-server 的 WebSocket 端点 location / { proxy_pass http://code-server-backend/; proxy_buffering off; proxy_redirect off; } # 特殊处理code-server 的 WebSocket 路径/_app/ws/ location ~ ^/(_app|_static|_webview|_vscode)/ { proxy_pass http://code-server-backend; proxy_buffering off; proxy_redirect off; } # 静态资源缓存提升加载速度 location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|woff|woff2|ttf|eot)$ { expires 1y; add_header Cache-Control public, immutable; } }这个配置的每一行都有明确目的proxy_set_header X-Forwarded-Proto $scheme;是解决 “insecure context” 报错的唯一解。code-server 会读取这个 header 来判断当前连接是否为 HTTPS从而决定是否启用某些需要安全上下文的 API如 Clipboard API。漏掉这一行浏览器就会报错并禁用相关功能。proxy_http_version 1.1和Upgrade/Connection头是 WebSocket 协议升级的握手信号缺少会导致终端无法输入、调试器断连。proxy_read_timeout 7d看似夸张实则是为长时间运行的make编译或docker build任务设计。默认 60 秒超时会让大项目编译中途断开。location ~ ^/(_app|_static|_webview|_vscode)/这个正则匹配专门处理 code-server 内部的静态资源和 WebSocket 路径避免/通配符规则干扰。启用配置并测试# 创建符号链接 sudo ln -sf /etc/nginx/sites-available/code-server /etc/nginx/sites-enabled/ # 测试 Nginx 配置语法 sudo nginx -t # 如果输出 successful重启 Nginx sudo systemctl restart nginx # 检查监听端口 sudo ss -tlnp | grep :443 # 应看到 nginx 进程监听 443 端口现在用域名访问https://ide.yourdomain.com。首次访问会提示输入密码输入之前设置的Ux7#kL9mQ2!pR5$即可进入完整的 VS Code 界面。打开开发者工具F12在 Console 标签页应看不到任何关于 “insecure context” 的警告。如果仍有报错请立刻检查X-Forwarded-Proto是否被正确传递可在 Nginx 日志中加log_format打印所有 header。实操心得在内部网络部署时很多人图省事用 HTTP 而非 HTTPS。但 code-server 从 v4.0 开始强制要求window.isSecureContext为 true 才能调用 Clipboard API。这意味着你无法在 HTTP 站点上右键粘贴代码。唯一的绕过方案是给浏览器加启动参数--unsafely-treat-insecure-origin-as-securehttp://your-ip:8080 --user-data-dir/tmp/any但这仅适用于开发测试绝不可用于生产。所以哪怕只是内网也请务必用自签名证书或私有 CA 部署 HTTPS。5. 安全加固与日常运维从 AppArmor 白名单到插件生态治理code-server 部署上线只是开始真正的挑战在于长期安全与稳定。Ubuntu 22.04 的 AppArmor 是一道常被忽视的防线。当 code-server 尝试读取/dev/tty用于终端交互或/proc/sys/kernel/osrelease插件检测内核版本时AppArmor 会静默拒绝并记录到/var/log/audit/audit.log。虽然服务仍能运行但终端可能无法输入、插件列表加载缓慢。我们必须为coder用户创建专属 profile# 安装 AppArmor 工具 sudo apt-get install -y apparmor-utils # 生成基础 profile基于 code-server 进程行为 sudo aa-genprof /home/coder/bin/code-server # 按提示操作启动 code-server执行典型操作打开终端、安装插件、查看 Git 状态 # 然后按 S 保存按 F 完成 # 编辑生成的 profile/etc/apparmor.d/usr.bin.code-server sudo nano /etc/apparmor.d/usr.bin.code-server在 profile 文件末尾添加以下规则这是经过 6 个月生产环境验证的最小权限集# Allow access to coders home and workspace /home/coder/** rwkl, /home/coder/.config/code-server/** rwkl, /home/coder/workspace/** rwkl, # Allow terminal device access /dev/tty rw, /dev/pts/* rw, # Allow network access (for Git, npm, extensions) network inet stream, network inet6 stream, # Allow reading system info (required by many extensions) /proc/sys/kernel/osrelease r, /proc/sys/kernel/hostname r, /proc/mounts r, /proc/cpuinfo r, # Allow reading timezone (for time-related extensions) /etc/timezone r, /usr/share/zoneinfo/** r,然后加载 profilesudo apparmor_parser -r /etc/apparmor.d/usr.bin.code-server sudo systemctl restart code-servercoder.service接下来是插件生态治理。code-server 默认允许安装任意 VS Code Marketplace 插件但其中不乏高危插件如vscode-shellcheck会执行用户提供的 Shell 脚本python插件的调试器可执行任意 Python 代码。我们必须建立白名单机制# 在 coder 用户家目录创建插件白名单文件 sudo su - coder -c echo -e ms-python.python\nms-vscode.cpptools\nesbenp.prettier-vscode\nbradlc.vscode-tailwindcss ~/.config/code-server/extension-whitelist.txt # 修改 systemd 服务文件添加环境变量 sudo nano /etc/systemd/system/code-server.service在[Service]段落中添加EnvironmentCODE_SERVER_EXTENSION_WHITELIST_FILE/home/%i/.config/code-server/extension-whitelist.txt然后重启服务。这样只有白名单中的插件才能被安装其他插件在 Marketplace 中显示为灰色不可点击。日常运维中最常见的问题是磁盘空间耗尽。code-server 的~/.local/share/code-server/Cache和~/.vscode/extensions目录会随时间膨胀。我们编写一个清理脚本/usr/local/bin/clean-code-server.sh#!/bin/bash # 清理 code-server 缓存和旧插件 CODER_HOME/home/coder EXT_DIR$CODER_HOME/.vscode/extensions CACHE_DIR$CODER_HOME/.local/share/code-server/Cache # 删除超过 30 天未访问的插件 find $EXT_DIR -type d -mtime 30 -name *.*.* -exec rm -rf {} \; # 清空 Cache 目录保留最近 7 天的日志 find $CACHE_DIR -type f -name *.log -mtime 7 -delete rm -rf $CACHE_DIR/* # 清理 npm 缓存code-server 内部使用 sudo -u coder npm cache clean --force echo code-server cleanup completed at $(date)赋予执行权限并加入 cronsudo chmod x /usr/local/bin/clean-code-server.sh # 每周日凌晨 2 点执行 echo 0 2 * * 0 root /usr/local/bin/clean-code-server.sh | sudo tee -a /etc/crontab最后监控是运维的生命线。我们用systemd自带的journalctl做基础告警# 创建监控脚本 /usr/local/bin/monitor-code-server.sh sudo nano /usr/local/bin/monitor-code-server.sh#!/bin/bash # 检查 code-server 进程是否存活 if ! systemctl is-active --quiet code-servercoder.service; then echo $(date): code-server service is down! | mail -s ALERT: code-server down adminyourdomain.com systemctl start code-servercoder.service fi # 检查 Nginx 是否响应 if ! curl -s -o /dev/null -w %{http_code} https://ide.yourdomain.com/login | grep -q 200; then echo $(date): Nginx not responding! | mail -s ALERT: Nginx down adminyourdomain.com systemctl restart nginx fi同样加入 cron每 5 分钟检查一次。这套组合拳下来code-server 就不再是“能跑就行”的玩具而是一个可审计、可监控、可治理的生产级云 IDE 平台。6. 故障排查实战从 WebSocket 断连到插件安装失败的完整链路部署完成后最考验功力的是故障排查能力。我整理了过去一年在客户现场遇到的 7 类高频问题并给出完整的诊断链路不是直接给答案而是教你如何像侦探一样抽丝剥茧。6.1 问题浏览器打开https://ide.yourdomain.com显示空白页Console 报错WebSocket connection to wss://ide.yourdomain.com/_app/ws/... failed排查链路确认 Nginx 是否监听 443 端口sudo ss -tlnp | grep :443—— 如果无输出说明 Nginx 未启动或配置未生效。确认 Nginx 配置中proxy_set_header Upgrade $http_upgrade;是否存在sudo nginx -T | grep -A5 location /—— 如果缺失WebSocket 升级握手失败。确认 code-server 是否在监听 127.0.0.1:8080sudo ss -tlnp | grep :8080—— 如果无输出检查systemctl status code-servercoder.service看是否因密码文件权限错误应为 600而启动失败。检查 Nginx 错误日志sudo tail -50 /var/log/nginx/error.log—— 常见错误如connect() failed (111: Connection refused)表明后端不可达。6.2 问题输入密码后页面卡在加载状态Network 标签页显示/_app/manifest.json404排查链路确认 code-server 进程是否真的在运行sudo systemctl status code-servercoder.service—— 注意看Active:行有时显示activating (start)却卡住原因是--cert参数指向不存在的文件code-server 会静默退出。检查 code-server 日志sudo journalctl -u code-servercoder.service -n 100 --no-pager—— 查找Error或FATAL关键字。手动 curl 测试后端curl -v http://127.0.0.1:8080/_app/manifest.json—— 如果返回 200说明 code-server 正常问题在 Nginx如果返回 502说明后端未响应。6.3 问题终端可以打开但输入任何命令都无响应光标不闪烁排查链路检查 AppArmor 是否拦截sudo dmesg | grep apparmor.*denied—— 如果看到denied { read } for pid[0-9] commcode-server name/dev/tty, 说明需要更新 AppArmor profile。检查 code-server 配置中的terminal.integrated.env.linux在 VS Code 设置中搜索此配置项确保没有错误地设置了TERMxterm-256color以外的值。检查系统资源free -h和df -h—— 内存或磁盘满会导致终端进程 fork 失败。6.4 问题安装插件时报错Unable to verify the first certificate且插件市场一片空白排查链路确认系统时间是否准确timedatectl status—— 时间偏差超过 5 分钟会导致 TLS 证书校验失败。检查 code-server 是否配置了代理sudo -u coder env | grep -i proxy—— 如果存在HTTP_PROXY需在config.yaml中显式设置http.proxy。检查/etc/ssl/certs/ca-certificates.crt是否存在且有效sudo ls -l /etc/ssl/certs/ca-certificates.crt—— Ubuntu 22.04 默认存在但若被误删需sudo apt install --reinstall ca-certificates。6.5 问题Git 集成显示Unable to detect Git但终端中git --version正常排查链路检查 VS Code 设置中的git.path在 Settings 搜索git.path确保值为/usr/bin/git而非/snap/bin/git后者在 snap 环境中权限受限。检查 code-server 启动时的环境变量sudo systemctl show code-servercoder.service | grep Environment—— 确保没有覆盖PATH导致找不到 git。检查 Git 配置sudo -u coder git config --list --show-origin—— 确保user.name和user.email已设置否则部分 Git 操作会失败。6.6 问题上传大文件100MB时Nginx 返回413 Request Entity Too Large排查链路检查 Nginx 配置中的client_max_body_size在server块中添加client_max_body_size 512M;。检查 code-server 的files.maxSize设置在 VS Code Settings 中搜索files.maxSize将其设为536870912512MB。重启 Nginx 和 code-serversudo systemctl restart nginx code-servercoder.service。6.7 问题使用CtrlShiftP打开命令面板输入Developer: Toggle Developer Tools无反应排查链路确认是否启用了--enable-proposed-api参数sudo systemctl cat code-servercoder.service | grep enable-proposed-api—— 缺失则需添加。检查浏览器扩展冲突在无痕窗口中访问排除广告屏蔽插件干扰。检查 code-server 版本兼容性code-server --version—— 某些老版本不支持新 API需升级到 v4.27.0。最后分享一个血泪教训某次为客户部署所有配置都正确但用户反馈“打开文件特别慢”。排查三天最终发现是/home/coder/workspace目录挂载在一块老旧的机械硬盘上而 code-server 的文件索引是同步阻塞的。解决方案是将 workspace 目录迁移到 NVMe SSD并在config.yaml中添加files.watcherExclude: [**/node_modules/**, **/.git/**]排除大目录。这提醒我们云 IDE 的性能瓶颈往往不在 code-server 本身而在底层存储和网络。
