remote.SSH.remoteServerCommand 不影响文件忽略逻辑，VSCode Remote-SSH 通过本地客户端 SFTP 直接操作文件，忽略行为由 files.watcherExclude 控制，而非服务端命令或 files.exclude。
remote-ssh 的 remote.SSH.remoteServerCommand 不影响忽略逻辑
VSCode 远程开发（Remote-SSH）本身不通过服务器端进程控制文件同步——它用的是本地 VSCode 客户端直接 SFTP 拉取/监听文件。所谓“忽略同步”，其实是客户端在建立连接后，对远程工作区做文件扫描和变更监听时主动跳过某些路径，不是靠服务端命令过滤。
因此，改 remote.SSH.remoteServerCommand 或在服务器上配 rsync --exclude 都无效。真正起作用的只有两个地方：VSCode 本地设置 + 远程工作区根目录下的配置文件。
.vscode/settings.json 中的 files.exclude 只对本地 UI 生效
这个配置常见但常被误解：它只影响 VSCode 左侧资源管理器是否显示文件、搜索是否包含这些路径，**不影响实际文件传输或文件监听行为**。即使你写了 "**/node_modules/**": true，VSCode 仍会为 node_modules 下每个文件发 stat 请求来确认状态——尤其在打开大项目时，大量 stat 会拖慢连接响应，带宽没省多少，延迟反而升高。
- ✅ 正确用途：隐藏干扰项、加快资源管理器渲染
- ❌ 错误期待：减少 SFTP 流量、避免监听子目录
- ⚠️ 注意：
files.exclude是 glob 模式，**匹配多级目录，但不支持正则；路径以远程工作区根为基准，不是绝对路径
必须用 files.watcherExclude 才能真正跳过文件监听
VSCode 默认用 chokidar（底层调用 inotify 或轮询）监听远程文件变化。如果不对监听范围做限制，它会对整个打开的文件夹递归注册监听器——这是带宽和 CPU 开销的主要来源。解决办法是显式配置 files.watcherExclude，它直接传给 chokidar，跳过 stat 和监听注册。
示例（放在远程工作区根目录的 .vscode/settings.json 中）：
{
"files.watcherExclude": {
"**/dist/**": true,
"**/build/**": true,
"**/coverage/**": true,
"**/node_modules/**": true,
"**/.git/**": true
}
}
- ✅ 必须写在远程工作区的
.vscode/settings.json里（不是本地用户设置），否则不生效 - ✅ 路径匹配基于远程服务器上的实际路径，且区分大小写（Linux 服务器上
Dist≠dist） - ⚠️
files.watcherExclude不影响文件打开、编辑或保存——只是不监听变化。比如你手动改了dist/index.js，VSCode 不会弹出“文件已在磁盘上更改”提示 - ⚠️ 如果项目用了自定义构建输出路径（如
out或target），记得一并加进去，漏掉一个就可能持续产生几百个无意义的inotify事件
遇到 ENOSPC 或 “Failed to watch” 错误时要检查服务器 inotify 限制
即使配了 files.watcherExclude，如果服务器 inotify 实例数超限，VSCode 仍会退回到低效的轮询模式（每秒多次遍历目录），导致卡顿和带宽浪费。错误信息通常是：Unable to watch for file changes in this large workspace 或终端里报 ENOSPC。
- ✅ 登录服务器运行
cat /proc/sys/fs/inotify/max_user_watches，低于 524288 就容易出问题 - ✅ 临时提升：运行
sudo sysctl fs.inotify.max_user_watches=524288 - ✅ 永久生效：向
/etc/sysctl.conf追加fs.inotify.max_user_watches=524288，再sudo sysctl -p - ⚠️ 注意：这个值是全局的，不是 per-user。如果服务器跑多个 VSCode 连接或其它监听工具（如 webpack watch），需按总需求预留余量
真正省带宽的关键，是让 VSCode 别去碰那些它根本不需要反应的目录——而不是等它碰了再压缩、再丢弃。watcherExclude 配得准不准，比 .gitignore 写得漂不漂亮重要得多。
