VSCode脚本共享延迟主因是文件系统同步机制或远程配置不当；须正确配置files.watcherExclude、禁用跨子系统路径、切换至Remote-WSL/SSH模式，并确保code-runner.runInTerminal为true、语言模式正确。
VSCode 脚本共享延迟，90% 以上不是网络问题，而是文件系统同步机制或远程开发配置不当导致的——改对 files.watcherExclude、禁用跨子系统路径、切到 Remote-WSL 或 Remote-SSH 模式，就能让保存即生效。
WSL2 下编辑文件后 Linux 终端看不到最新内容
这是最典型的“共享延迟”错觉：你在 VSCode（Windows 进程）里保存 /home/user/project/script.py，但 WSL2 终端里 cat script.py 还是旧内容。根本原因不是网络慢，而是你用了 \wsl$\Ubuntu\home\user\project 这种 Windows 层路径打开项目，强制所有 I/O 走 9P 协议桥接，inotify 事件丢失、stat 时间戳不同步。
- 立刻验证：看左下角状态栏是否显示
WSL: Ubuntu；如果不是，说明你没走 Remote-WSL，只是在 Windows 里开了个 WSL2 路径的文件夹 - 正确做法：卸载 Remote - WSL 扩展后重装，用
Remote-WSL: New Window命令启动，工作区路径必须是/home/xxx/...格式 - 绝对不要混用：
\wsl$路径下开的项目 + 集成终端里执行npm run dev，会触发双重桥接，I/O 延迟翻倍
Remote-SSH 连接后脚本修改不实时触发构建
现象是：保存 JS/Python 文件后，远程的 nodemon 或 uvicorn 没反应。这不是 SSH 带宽不够，而是 VSCode 的文件监视器在远程机器上扫描了不该扫的目录，或者本地监听机制没把变更推过去。
- 必须在远程工作区根目录的
.vscode/settings.json中配files.watcherExclude，用户级设置无效 - 最低要求：
"**/node_modules/**": true、"**/__pycache__/**": true、"**/dist/**": true—— 否则 inotify 句柄耗尽，退化为轮询，延迟从毫秒级变成秒级 - 如果用
nodemon，加-e js,ts,json显式限定监听后缀，避免它自己去扫整个node_modules - 禁用
remote.autoForwardPorts（除非真需要），它会在后台频繁建立隧道，干扰文件同步通道
code-runner 执行旧版本脚本，疑似“缓存延迟”
常见于 Python：改完 print("v2") 保存后运行，终端仍输出 v1。这不是 VSCode 缓存，而是 code-runner 默认在输出面板执行，路径解析走的是 Windows shell，没读到 WSL2 或远程服务器上的最新文件。
- 强制切终端执行：
code-runner.runInTerminal必须设为true - 禁用自动保存全部：
code-runner.saveFileBeforeRun设为true，但code-runner.clearPreviousOutput也建议开，避免旧日志干扰判断 - Python 用户额外加
-u参数："python": "python -u -c \"import sys; exec(open(sys.argv[1]).read())\" --"，绕过 shell 查找和缓冲，直读文件 - 检查右下角语言模式是否为
Python，不是Plain Text或JavaScript—— 错误语言模式会导致executorMap不匹配
真正卡住脚本共享的，从来不是带宽或 ping 值，而是文件系统语义不一致、监视器配置越界、以及本地/远程执行环境错位。每一步都得在对应层级（WSL 内核、SSH 远程、code-runner 运行时）确认路径、权限和监听范围，漏掉任何一层，延迟就藏在那里不动。
