应配置工作区级 files.exclude 隐藏 .env 等敏感文件，因 Live Share 默认共享整个工作区且不区分 git 状态；需配合 search.exclude 和 remote.extensionKind 实现多层隔离，避免协作者通过资源树、搜索或插件访问。

Live Share 会话中如何防止 .env 文件被协作者看到？

Live Share 默认共享整个工作区，包括 .env 这类文件——即使它被 .gitignore 忽略，协作者仍能在资源管理器里点开、搜索甚至编辑。关键不是“它是否提交”，而是“它是否可见”。

最直接有效的做法是启用工作区级 files.exclude 并确保该配置被同步进 Live Share 会话：

• 在项目根目录的 .vscode/settings.json 中添加：

  {
    "files.exclude": {
      "**/.env": true,
      "**/.env.local": true,
      "**/id_rsa": true,
      "**/*.pem": true
    }
  }

• 不要只配在用户全局设置里——Live Share 只读取工作区设置（.vscode/ 下的）
• 确认协作者加入后，打开资源管理器，这些文件确实不显示；如果仍可见，检查是否误用了 search.exclude（它不影响资源树展示）

为什么开了 “protected” access 还会被拖进敏感文件？

"access": "protected" 只控制“谁有资格加入会话”，不控制“加入后能看到什么”。它要求协作者登录 GitHub 或 Microsoft 账号，但一旦通过认证，权限就取决于你启动时选的模式（只读 / 协作）和工作区配置。

真正起隔离作用的是以下三项组合：

• files.exclude：隐藏文件（资源树不可见）
• search.exclude：禁用全局搜索匹配（防止 Ctrl+Shift+F 搜出密钥）
• remote.extensionKind 配置：限制插件行为，例如禁止某些扩展访问本地文件系统

  {
    "remote.extensionKind": {
      "redhat.vscode-yaml": ["workspace"],
      "esbenp.prettier-vscode": ["workspace"]
    }
  }

漏掉任意一项，都可能让协作者通过不同路径接触到敏感内容。

VSCode

避免常见的 VSCode 错误——设置冲突、调试器配置和扩展冲突。

下载

协作者能读取我本地未提交的 config.json 吗？

能。只要该文件存在于当前打开的工作区目录下，且没被 files.exclude 显式隐藏，协作者就能在资源管理器中看到、双击打开、甚至复制全文——无论它是否在 Git 索引中，也无论你有没有提交过。

这不是漏洞，是 Live Share 的设计前提：共享的是“开发环境”，不是“Git 提交快照”。所以必须主动防御：

• 把所有敏感配置文件名明确列入 files.exclude，不要依赖通配符侥幸（比如 "**/config/*.json" 不如写死 "**/config/local.json"）
• 避免在工作区根目录放 secrets.yml 或 credentials.json 这类命名直白的文件；改用间接方式（如运行时注入或 Vault 获取）
• 开启 VSCode 的工作区信任机制：首次打开陌生仓库时，VSCode 会提示“此工作区不受信任”，此时自动禁用自动任务、调试启动项和部分扩展 API——这是第一道沙箱

Live Share + dotenv-linter 能否实现保存即告警？

不能直接联动。Live Share 是实时共享协议，dotenv-linter 是本地 CLI 工具，二者无通信通道。但你可以让主机和协作者各自独立生效：

• 主机侧：按常规配置 tasks.json + editor.codeActionsOnSave，保存 .env 时自动触发检查并报错
• 协作者侧：同样需要在自己机器上安装 dotenv-linter 并配置相同 task——因为 Live Share 不同步 CLI 工具或 PATH
• 更稳妥的做法是把 dotenv-linter 集成进 pre-commit 钩子，这样无论谁提交，Git 层面就会拦截，不依赖编辑器配置

真正的难点不在工具链打通，而在于：协作者修改了 .env 后，你作为主机是否允许他保存？VSCode 没有“只读文件但允许编辑”的中间态——要么可写，要么完全禁用编辑。所以最省事的方案，是压根别让 .env 出现在共享工作区里。