同时安装 VS Code 与 VS Code Insiders：远程开发和本地工作的配置拆解

开头：为什么要同时装 VS Code 和 VS Code Insiders

这篇文章主要记录一件相对具体的事情： 在多端环境（macOS + Windows）下，同时安装 VS Code 稳定版和 VS Code Insiders，各自承担不同角色，并围绕它们设计两套配置。

场景大致是：

• 有一台 远程性能很强 的机器（通过 SSH 连接），但网络 RTT 大约在 200ms 左右。
• 本地电脑（包括 Windows 和 Mac）性能也不错，更适合一些需要频繁交互的工作。
• 平时有不少 Python / Jupyter / LaTeX 相关的任务，还会使用 Remote-SSH、Copilot、GitLens 等扩展。

我最终的做法是：

• 用 VS Code 稳定版 主要做 Remote-SSH 远程开发。
• 用 VS Code Insiders 主要在 本机/局域网场景 工作，兼顾文档写作和 LaTeX。

这不是“最佳实践”，只是目前对我来说比较顺手的一种分工和配置方式。

背景：环境和使用场景

为了后文有个上下文，这里简单交代一下环境约束。

硬件与网络

• 远程服务器：

  • Linux Mint系统。
  • 计算资源相对充足（CPU / 内存都不紧张）。
  • 网络延迟：RTT ≈ 200ms，基本稳定但不算小。

• 本地设备：

  • macOS + Windows 各一台，性能都够用。
  • 本机开发、调试、文稿写作都在这里进行。

工具和工作内容

• 编辑器：VS Code 稳定版 + VS Code Insiders。

• 常用扩展与工作流：

  • Remote-SSH：连接远程 Linux 机器。
  • Python / Jupyter：日常开发、实验。
  • Git / GitLens / GitHub Copilot：协作与辅助编码。
  • LaTeX Workshop：论文与文档排版。
  • 一些本地工具（draw.io 等）。

在这个前提下，我希望做到：

1. 远程开发稳定可控：避免因自动更新、扩展行为破坏远端环境。
2. 本地开发体验顺滑：善用本机性能，适当放开一些“重”功能。
3. 配置在多端基本可共用：避免因为切换电脑导致体验差异太大。

VS Code 与 VS Code Insiders：版本与分工

在配置之前，先简单理一下这两个版本在我这里的“定位”。

VS Code 稳定版

VS Code 稳定版的特点是：

• 更新节奏相对稳定。
• 插件生态成熟，对大多数需求已经足够。
• 适合生产环境、长时间保持一个相对固定的状态。

我让稳定版主要负责：

• 远程开发（Remote-SSH）
• 连接高延迟的远程 Linux 机器
• 以“可预期、不折腾”为优先。

VS Code Insiders

VS Code Insiders 是一个更新更快的版本，会提前集成一些新特性：

• 功能更新更及时，有时会比稳定版多出一些实用小改动。
• 相对来说，偶尔可能会遇到行为变化或小问题。

我让 Insiders 主要负责：

• 本地开发、本地工具集成
• 连接本机或局域网设备
• 做 LaTeX 写作、快速试验新功能等。

这样做的好处是：

• 远程开发环境比较“稳”：不容易因为某次自动更新导致远程开发突然出问题。
• 本地走在前面试水：新特性和新扩展先在 Insiders 上体验，稳定后再考虑同步到远程那边。

下面分别展开两套配置。

远程开发配置：面向高延迟远程机器的 VS Code 设置

这一部分是给 VS Code 稳定版用的，核心目标是： 在 RTT ≈ 200ms 的情况下，把交互往返次数尽量压低，同时充分利用远程机器的算力。

Remote-SSH 相关

{
    "remote.SSH.remotePlatform": {
        "tailscale": "linux",
        "zerotier": "linux"
    },
    "remote.SSH.useLocalServer": true
}

几点说明：

• remote.SSH.remotePlatform：显式告诉 VS Code 将这些主机视为 Linux，避免平台误判。

• remote.SSH.useLocalServer: true：

  • 目的是减少频繁的 SSH 往返，使一些操作通过本地 VS Code server 中转。
  • 在 200ms 延迟下，通常会比完全“傻直连”更顺滑一点。
  • 如果后续发现不稳定，可以再关掉。

文件监视与搜索：减负但不伤筋骨

{
    "files.watcherExclude": {
        "**/.git/objects/**": true,
        "**/.git/subtree-cache/**": true,
        "**/node_modules/**": true,
        "**/build/**": true,
        "**/dist/**": true,
        "**/__pycache__/**": true,
        "**/.venv/**": true,
        "**/data/**": true,
        "**/large_generated/**": true,
        "**/.mypy_cache/**": true,
        "**/.pytest_cache/**": true,
        "**/.ruff_cache/**": true
    },
    "search.exclude": {
        "**/node_modules/**": true,
        "**/build/**": true,
        "**/dist/**": true,
        "**/__pycache__/**": true,
        "**/.venv/**": true,
        "**/data/**": true,
        "**/large_generated/**": true,
        "**/.mypy_cache/**": true,
        "**/.pytest_cache/**": true,
        "**/.ruff_cache/**": true
    }
}

思路：

• 对大多数项目来说，这些目录里的文件：

  • 要么是缓存（__pycache__、.mypy_cache 等）。
  • 要么是构建产物（build / dist）。
  • 或者是大量但不常直接编辑的数据集（data）。

• 把它们从监视和搜索里排除，可以减少：

  • 远程文件变更事件的传输。
  • Index / 搜索的负担。

Python / Jupyter：让远端 LS 多干活

在远程机器上，计算资源其实够用，所以我倾向于让语言服务“稍微勤快一点”。

{
    "editor.formatOnSave": true,
    "[python]": {
        "editor.defaultFormatter": "ms-python.black-formatter"
    },
    "python.analysis.typeCheckingMode": "basic",
    "python.analysis.indexing": true,
    "python.analysis.diagnosticMode": "workspace",
    "python.analysis.autoImportCompletions": true,
    "editor.codeActionsOnSave": {
        "source.fixAll": "explicit"
    },
    "jupyter.notebookFileRoot": "${workspaceFolder}",
    "notebook.output.textLineLimit": 5000
}

几点取舍：

• indexing: true + diagnosticMode: "workspace"：

  • 让 LS 对整个项目进行索引和诊断，补全和跳转更完整。
  • 代价是初次加载和大规模变更时，CPU 会忙一阵。

• autoImportCompletions: true：

  • 提示里带自动导入，对写代码更省心。

• Jupyter 的 notebook.output.textLineLimit：

  • 避免某个 cell 输出太多文本导致前端卡死。

如果后面证明确实太重，可以把这几个选项关回去，但在远程机器性能可接受的前提下，我现在倾向于保持开启。

终端与更新策略

部分节选：

{
    "terminal.integrated.gpuAcceleration": "on",
    "terminal.integrated.profiles.osx": {
        "zsh-login": {
            "path": "zsh",
            "args": ["-l"]
        }
    },
    "terminal.integrated.defaultProfile.osx": "zsh-login",
    "terminal.integrated.automationProfile.osx": {
        "path": "zsh",
        "args": ["-l"]
        }
}

• 终端部分更多是本机终端体验，跟远程性能没有直接关系。
• 配成 login shell 是为了在 macOS 上正确继承 PATH 和环境变量。

更新相关：

{
    "update.mode": "manual",
    "extensions.autoUpdate": false
}

这两条对应我对远程开发环境的要求： 尽量不要被“某天早上自动更新”打断，更新由我手动触发。

编辑体验与 Git / 扩展

编辑体验：

{
    "editor.fontFamily": "Maple Mono CN, 'Fira Code', monospace",
    "editor.fontLigatures": true,
    "files.eol": "\n",
    "window.title": "${activeEditorLong}${separator}${rootName}",
    "files.insertFinalNewline": true,
    "files.trimTrailingWhitespace": true,
    "files.autoSave": "onFocusChange",
    "workbench.list.openMode": "doubleClick",
    "workbench.editor.enablePreview": false,
    "workbench.colorTheme": "GitHub Dark"
}

Git / GitLens / Copilot：

{
    "git.autorefresh": false,
    "diffEditor.ignoreTrimWhitespace": false,
    "scm.diffDecorations": "gutter",
    "git.confirmSync": false,
    "github.copilot.nextEditSuggestions.enabled": true,
    "gitlens.ai.model": "vscode",
    "gitlens.ai.vscode.model": "copilot:gpt-4.1",
    "gitlens.codeLens.enabled": false,
    "gitlens.currentLine.enabled": false,
    "gitlens.hovers.enabled": false
}

思路比较直接：

• 高延迟环境下，我倾向于 关闭 git.autorefresh，避免背景里频繁触发远程 Git 操作。
• GitLens 只保留必要功能，减少 UI 干扰。
• Copilot 开启的是“下一步建议”这类不那么激进的模式。

敏感信息：API Key 改用环境变量

一开始我把 Notebook 翻译扩展的 API key 写在 settings.json 里，后来意识到这是个明显错误。

现在的配置改成：

{
    "ipynbTranslator.openai.apiKey": "${env:IPYNB_TRANSLATOR_OPENAI_API_KEY}",
    "ipynbTranslator.openai.baseUrl": "https://api.chatanywhere.org/v1",
    "ipynbTranslator.openai.model": "gpt-5-mini",
    "ipynbTranslator.engine": "openai"
}

配合 shell 中的：

export IPYNB_TRANSLATOR_OPENAI_API_KEY="你的真实 key"

至少不会再把 key 明文写在配置文件里。

本地 / VS Code Insiders 配置：面向本机的“重度工作台”

VS Code Insiders 在我这边主要做两类事：

1. 本机 / 局域网内开发、调试。
2. LaTeX 写作与 PDF 工具集成。

因为本机性能相对宽裕，我在这套配置里会更愿意开启一些检查和工具。

文件监视与终端

{
    "files.watcherExclude": {
        "**/.git/objects/**": true,
        "**/node_modules/**": true,
        "**/__pycache__/**": true,
        "**/.venv/**": true,
        "**/build/**": true,
        "**/dist/**": true,
        "**/data/**": true,
        "**/*.aux": true,
        "**/*.log": true,
        "**/*.synctex.gz": true,
        "**/*.bbl": true,
        "**/*.blg": true,
        "**/*.fdb_latexmk": true,
        "**/*.fls": true,
        "**/*.toc": true,
        "**/.mypy_cache/**": true,
        "**/.pytest_cache/**": true,
        "**/.ruff_cache/**": true
    },
    "terminal.integrated.defaultProfile.windows": "PowerShell"
}

和远程版相比，这里多了一些 LaTeX 中间文件的排除，目的是减少大型文档项目的监视负担。

Python 格式化与 Lint

Insiders 这边我保留了一套 “Black + Flake8” 的组合：

{
    "editor.formatOnSave": true,
    "python.formatting.provider": "black",
    "python.formatting.blackArgs": [
        "--line-length",
        "120"
    ],
    "python.linting.enabled": true,
    "python.linting.flake8Enabled": true,
    "python.linting.flake8Args": [
        "--max-line-length=120",
        "--ignore=E203,W503"
    ],
    "editor.codeActionsOnSave": {
        "source.fixAll": "explicit"
    },
    "python.analysis.typeCheckingMode": "basic"
}

这里我没有专门为 Insiders 调到 strict，一方面是出于习惯，另一方面也避免在复杂项目里报出过多“噪音”式的警告。如果后续项目规模更受控，有可能会考虑在本地配置里尝试 strict，再看效果。

统一编辑器体验

{
    "editor.fontFamily": "Maple Mono Normal NF CN, 'Fira Code', monospace",
    "editor.fontLigatures": true,
    "files.eol": "\n",
    "editor.detectIndentation": true,
    "window.title": "${activeEditorLong}${separator}${rootName}",
    "editor.minimap.enabled": true,
    "files.insertFinalNewline": true,
    "files.trimTrailingWhitespace": true,
    "files.autoSave": "onFocusChange"
}

这里的目标主要是做到：

• 两套 VS Code 在“表现层面”尽量一致，不因为切换版本而产生明显割裂感。
• 少量差别（如 minimap 开启与否）更多是针对“本机更强，可以多开一点东西”。

Git / GitLens 与 Remote-SSH

{
    "[git-commit]": {
        "editor.rulers": [72]
    },
    "git.confirmSync": false,
    "remote.SSH.remotePlatform": {
        "100.100.1.1": "linux"
    },
    "terminal.integrated.tabs.enabled": false,
    "gitlens.ai.model": "vscode",
    "gitlens.ai.vscode.model": "copilot:gpt-4.1"
}

这一块和远程版的思路类似，只是这里的 Remote-SSH 更多是在局域网或本机互连场景下使用，延迟不再是最大问题。

LaTeX Workshop：同时兼顾 macOS 与 Windows

因为 Insiders 在我这里还承担了 LaTeX 写作的角色，所以这部分配置相对完整。

核心编译链：

{
    "latex-workshop.latex.autoBuild.run": "onSave",
    "latex-workshop.latex.recipes": [
        {
            "name": "xelatex ×2（日常最干净）",
            "tools": ["xelatex", "xelatex"]
        },
        {
            "name": "xelatex → bibtex → xelatex×2（加文献时切换）",
            "tools": ["xelatex", "bibtex", "xelatex", "xelatex"]
        }
    ],
    "latex-workshop.latex.recipe.default": "xelatex ×2（日常最干净）",
    "latex-workshop.latex.tools": [
        {
            "name": "xelatex",
            "command": "xelatex",
            "args": [
                "-synctex=1",
                "-interaction=nonstopmode",
                "-file-line-error",
                "%DOC%"
            ]
        },
        {
            "name": "bibtex",
            "command": "bibtex",
            "args": ["%DOCFILE%"]
        }
    ]
}

macOS 上使用 Skim：

{
    "latex-workshop.view.pdf.viewer": "external",
    "latex-workshop.view.pdf.external.viewer.command": "/Applications/Skim.app/Contents/SharedSupport/displayline",
    "latex-workshop.view.pdf.external.viewer.args": [
        "0",
        "%PDF%"
    ],
    "latex-workshop.view.pdf.external.synctex.command": "/Applications/Skim.app/Contents/SharedSupport/displayline",
    "latex-workshop.view.pdf.external.synctex.args": [
        "-r",
        "-b",
        "%LINE%",
        "%PDF%",
        "%TEX%"
    ],
    "latex-workshop.synctex.afterBuild.enabled": true
}

Windows 上使用 SumatraPDF 的配置被放在多行注释里，需要时再启用：

/*
"latex-workshop.view.pdf.viewer": "external",
"latex-workshop.view.pdf.external.viewer.command": "C:/Program Files/SumatraPDF/SumatraPDF.exe",
"latex-workshop.view.pdf.external.viewer.args": [
    "-reuse-instance",
    "%PDF%"
],
"latex-workshop.view.pdf.external.synctex.command": "C:/Program Files/SumatraPDF/SumatraPDF.exe",
"latex-workshop.view.pdf.external.synctex.args": [
    "-forward-search",
    "%TEX%",
    "%LINE%",
    "-reuse-instance",
    "%PDF%"
],
"latex-workshop.synctex.afterBuild.enabled": true,
*/

另外，为了减少不必要的打扰，我关掉了 LaTeX Workshop 的弹窗消息：

{
    "latex-workshop.formatting.latex": null,
    "latex-workshop.message.error.show": false,
    "latex-workshop.message.warning.show": false,
    "latex-workshop.message.badbox.show": false
}

错误和警告仍然会出现在 Problems 面板里，自己看即可。

排错与坑：多端、多版本配置里遇到的问题

这一节简单列一下在这个过程中踩到的几个点，以及后续的处理方式。

1. 多端共享 settings 时的路径问题

• 问题现象：

  • 在 Windows 上同步到含有 macOS 路径的配置（比如 /Applications/Skim.app/...）时，容易造成混乱。

• 实际结果：

  • VS Code 对于不适用当前 OS 的路径常常会“无感忽略”，但从维护角度看不清爽。

• 当前做法：

  • 通过多行注释区分 macOS / Windows 段。
  • 实际启用时，根据当前平台手动切换。

2. Remote-SSH remotePlatform 写错主机名

• 如果主机名写错或不匹配，VS Code 可能会错误推断远程平台类型。

• 结果是某些功能表现异常或者安装扩展时不准确。

• 目前的应对方式是：

  • 尽量用明确的、稳定的主机标识（如 IP 或固定别名）。
  • Remote-SSH 的配置只写真正常用的主机。

3. 自动更新对远程环境的影响

• 在早先的一些配置里，我允许扩展自动更新。

• 这导致过几次：远程环境“昨天还好好的”，第二天某个扩展更新后出现兼容性问题。

• 后来的调整：

  • 远程开发用的 VS Code：update.mode = manual + extensions.autoUpdate = false。
  • 本地 Insiders：可以适当放开，但还是倾向于手动确认。

4. 在 settings.json 中硬编码 API key

• 这是一个明显的安全问题，之前确实犯过。
• 现在统一改为通过 ${env:XXX} 读取环境变量。
• 这并不能解决所有安全问题，但至少不会再把 key 明文提交到仓库。

5. 高延迟环境下 Git 自动刷新导致卡顿

• 当 git.autorefresh 打开时，VS Code 会在后台定期触发 Git 状态检查。

• 在 RTT ≈ 200ms 时，这些操作叠加起来会让 UI 有明显的“顿挫感”。

• 目前做法：

  • 远程开发配置中关闭 git.autorefresh。
  • 有需要时手动刷新。

总结与反思：从“两套 VS Code”到“两套工作流”

这次整理的过程，其实更像是在给自己的开发环境做一次“角色分工”：

• VS Code 稳定版：偏向“生产工具”，负责远程开发，强调可控、可预期。
• VS Code Insiders：偏向“实验与本机工作台”，负责本地开发和文档写作，可以更积极地尝试新功能。

在这个过程中，有几个点对我自己的习惯影响比较大：

1. 把“远程”视为一个需要单独治理的环境 不再默认“本机怎么配置就怎么同步过去”，而是刻意考虑远程机器的网络、资源和风险。

2. 减少隐性行为（自动更新、自动刷新） 很多后台自动行为看起来方便，但在高延迟或远程场景下，带来的不确定性和性能成本被放大了。 调整后，反而更容易从日志和现象中定位问题。

3. 避免把密钥、路径等强绑定在通用配置文件里 把敏感信息移动到环境变量，把平台相关路径用注释区分开，对多端维护来说负担更小。

接下来，如果要进一步改进，大概有几个方向：

• 把当前这两套配置抽象成更清晰的“基础配置 + 环境差异”，用 Profile 或其他方式分层管理。
• 更系统地评估 Python 分析模式（basic / strict）对大型项目的影响，而不是只凭直觉。
• 把“远程开发”和“配置演进”本身也当做一个可回溯的项目，减少随手改动带来的不透明性。

这篇文章算是把当前状态记录下来，后面如果环境或者工作方式有变化，再基于此版本迭代。