在 Linux 系统上安装 VS Code，一条 apt install 或 dnf install 命令看似简单，但真正的考验往往在安装之后。很多人会卡在“装完打不开”、“code 命令未找到”或启动时报各种依赖缺失的错误。问题的核心从来不是“能不能装上”，而是“装完能否立刻、稳定地用起来”。尤其在后续配置 C++、远程 SSH 开发或 MPI 环境时，一个不扎实的安装基础，会让所有高级功能都举步维艰。
Ubuntu/Debian 系统：使用 APT 仓库安装最稳定
对于基于 Debian 的系统，通过官方 APT 仓库安装是最稳妥的选择。这种方式不仅包签名可信、更新有保障，还能自动解决像 libxkbfile1 这类基础依赖，省去不少麻烦。不过，有几个细节必须抠准，尤其是密钥和软件源的路径，必须严格匹配你系统的架构。
首先，导入微软的 GPG 密钥是第一步：
curl -fsSL https://packages.microsoft.com/keys/microsoft.asc | sudo gpg --dearmor -o /usr/share/keyrings/microsoft-archive-keyring.gpg接下来配置软件源。这里有个关键点：不要手动硬编码 amd64。务必使用 arch=$(dpkg --print-architecture) 动态获取你的系统架构（可能是 arm64），否则在树莓派或 ARM 服务器上肯定会失败。
执行 sudo apt update 后，如果遇到“The repository does not have a Release file”的报错，多半是源地址中的 stable 路径拼写有误，请仔细检查。
安装完成后，运行 code --version 测试。如果提示 command not found，别慌，这通常只是 /usr/bin/code 没有被包含在你的 PATH 环境变量里。一个简单的解决方法是手动创建软链接：sudo ln -s /usr/bin/code /usr/local/bin/code。
CentOS/RHEL/Fedora：用 RPM 包安装需补全依赖
在 Red Hat 系发行版上，直接下载 RPM 包安装适合内网或离线环境。但这种方式的“坑”在于，它不会自动提示缺失的依赖库，而是直接启动失败，报错信息往往令人困惑，比如经典的 libXss.so.1: cannot open shared object file。
下载时，建议直接用 wget 命令，避免从浏览器点击链接可能下载到 HTML 页面：
wget https://code.visualstudio.com/sha/download?build=stable&os=rhel-x64 -O code.rpm安装后先别急着启动。一个很好的习惯是，先用 ldd /usr/bin/code | grep "not found" 检查一下缺失哪些共享库。
常见的缺失库，可以通过以下命令一并安装：
sudo dnf install libXScrnSaver gconf2 atk at-spi2-atk gtk3对于 Fedora 36 及以上的版本，可能还需要 libappindicator-gtk3。如果遇到 GLIBCXX_3.4.29 not found 这类错误，说明系统的 GCC 运行时库版本太老。RHEL 8/CentOS 8 以上的系统通常没问题，老旧系统则建议考虑换用 Snap 或 tar.gz 方式安装。
没有 root 权限或想避免环境污染？用 tar.gz 解压即用
对于没有 root 权限的学生机、共享服务器，或者想在 Docker 容器内使用，tar.gz 压缩包是完美选择。它不写入任何系统路径，不修改 /etc 目录，完全独立。代价就是每次升级都需要手动替换整个文件夹。
下载和解压命令很简单：
wget https://code.visualstudio.com/sha/download?build=stable&os=linux-x64 -O vscode.tar.gz
tar -xzf vscode.tar.gz -C ~/vscode启动时，需要加上 --no-sandbox 参数来避免在某些受限权限环境下崩溃：~/vscode/Code --no-sandbox。
为了方便，可以在 ~/.bashrc 末尾添加一个别名：
alias code="$HOME/vscode/Code --no-sandbox"然后执行 source ~/.bashrc 即可。需要注意的是，它的插件默认存放在 ~/.vscode，和系统级安装互不冲突。但像 Remote-SSH 这类远程开发扩展，需要在这个独立的实例中重新安装一次。
启动报错 ENOSPC 或文件监听失效
有时候，VS Code 能安装能启动，但一打开大项目就报错：Error: ENOSPC: System limit for number of file watchers reached。这其实不是 VS Code 装错了，而是 Linux 系统的 inotify 文件监控数达到了上限，在 OpenCV、ROS 这类大型工作区中尤其常见。
临时缓解可以调整内核参数，但更推荐永久生效的方式：
echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p记住，别只用 sysctl -w 修改当前会话，重启就失效了，必须写入 /etc/sysctl.conf。
如果你用的是 WSL2，这个参数需要设置在 Windows 宿主机的 WSL 配置文件里，而不是在 Linux 子系统内部修改。
当然，最安全的方法还是在 VS Code 的设置里，通过 "files.watcherExclude" 排除掉不需要监控的庞大目录（比如 node_modules、build），这比盲目调高系统参数更合理。
说到底，在 Linux 上安装 VS Code，真正的麻烦往往藏在后面：code 命令能运行了，但 Remote-SSH 连不上服务器，或者 C++ 的 IntelliSense 死活找不到系统头文件。这些问题，追根溯源，常常是安装路径与环境变量没对齐，或者用了 Snap 安装却忘了加 --classic 权限。所以，动手之前，先想清楚你的主要场景：是本地写写脚本，还是远程连接服务器开发，或是做嵌入式交叉编译？选对了路径，后面就顺了。
