根本原因是Linux默认ptrace_scope=1限制非子进程ptrace，导致debugpy/gdbserver静默退出；验证需检查ptrace_scope值、端口监听及debugpy进程；修复推荐临时设为0、授CAP_SYS_PTRACE权限或改用attach模式。
VSCode 插件在 Linux 上调试失败，绝大多数不是插件本身写错了，而是环境链路中某一层被默认行为或权限细节卡住——尤其是 gdbserver、vscode-server 和用户 shell 权限这三者交叉时，错误信息往往不指向真实原因。
为什么 launch.json 里配了 gdbserver 却连不上
VSCode 远程调试 C/C++ 插件依赖 gdbserver 在 Linux 端监听，但常见失败不是因为没装，而是启动方式不对：
-
gdbserver默认只允许本地回环连接（--once --no-startup-with-shell不解决）；若你在launch.json中用了"miDebuggerServerAddress": "localhost:3000"，而远程 Linux 的gdbserver实际监听的是127.0.0.1:3000，VSCode 从 Windows 发起的连接会被拒绝（尤其当 SSH 隧道未显式转发该端口时） - 更隐蔽的问题：某些发行版（如 Ubuntu 22.04+）的
gdbserver默认启用ptrace_scope限制，非 root 用户无法 attach 进程 —— 表现为断点命中但变量全为 - 解决方案不是加 sudo，而是临时放宽限制：
echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope（重启失效，仅调试时用）
Remote-SSH 下插件日志里反复出现 Failed to fetch extensions
这不是网络问题，是远程 Linux 上 vscode-server 启动后默认以最小权限运行，且不读取用户 shell 的 .bashrc 或 .zshrc —— 导致 PATH 里没有 node、python 或自定义工具链路径，扩展初始化直接失败：
- 检查方法：在远程终端执行
ps aux | grep vscode-server，看其启动命令是否带--user-data-dir和--extensions-dir；若没带，说明 VSCode 没走完整流程 - 根本修复：在远程 Linux 的
~/.bashrc末尾添加export PATH="$HOME/.local/bin:$PATH"，然后在 VSCode 远程连接后，按Ctrl+Shift+P运行Developer: Reopen Folder in WSL/SSH（强制重载环境） - 注意：不要在
launch.json的env字段硬编码 PATH，那仅影响调试进程，不影响vscode-server自身
Linux 终端里能跑通的命令，在插件调试中报 command not found
这是最典型的“环境不一致”陷阱。VSCode 插件（尤其是任务/调试器调用的 shell 命令）默认使用 /bin/sh，而非你登录时的 bash 或 zsh：
- 比如你在
.zshrc里 alias 了gcc为gcc-12，但插件调用时走的是sh -c "gcc --version"，alias 不生效 - 又比如
cmake安装在/opt/cmake/bin/cmake，但只加到了.zshrc的 PATH，sh根本不知道这个路径 - 实操建议：把关键工具路径写死进
settings.json的cmake.cmakePath、cpp.gcc.default等字段；或者统一用~/.profile设置 PATH（它被所有 shell 读取）
真正容易被忽略的，是 Linux 上的 umask 和文件系统挂载选项 —— 比如远程目录挂载时用了 noexec，vscode-server 就无法执行自身解压的二进制；又或者 umask 077 导致插件下载的调试适配器文件权限为 600，gdbserver 读取失败却只报 “connection refused”。这类问题不会出现在错误面板里，得去 ~/.vscode-server/logs/ 翻 timestamp 最新的 exthost.log 才能看到真实 errno。
