DISPLAY环境变量不生效是因为VSCode Remote-SSH终端默认不继承Windows系统变量，且远程shell未加载配置文件；必须在~/.bashrc中显式export DISPLAY=localhost:10.0，并确保sshd_config启用X11Forwarding yes、X11UseLocalhost no，同时VcXsrv启动时禁用Native opengl并启用Disable access control。
DISPLAY 环境变量为什么总不生效？
VSCode Remote-SSH 连接后打开的终端默认不继承 Windows 的 DISPLAY 环境变量，哪怕你在系统级设置了它。这不是 VSCode 的 bug，而是 SSH 会话启动时未加载用户 shell 配置所致。
- 不要依赖 Windows 系统环境变量——即使你设了
DISPLAY=localhost:0.0，Remote-SSH 终端里echo $DISPLAY仍为空或错误 - 必须在远程 Linux 的 shell 初始化文件中显式导出：
export DISPLAY=localhost:10.0（注意：不是:0.0） - 推荐写入
~/.bashrc或~/.zshrc，然后执行source ~/.bashrc，再新开终端验证 - 为什么是
:10.0？因为 SSH X11 转发默认从 display 10 开始分配，localhost:0.0指向本地物理 X Server，而转发通道走的是 SSH tunnel，实际监听在localhost:10.0
Linux 服务器端 sshd_config 哪几行不能错？
只改客户端配置没用，服务端必须明确允许并适配 Windows 的连接方式。最常被忽略的是 X11UseLocalhost no —— OpenSSH 默认绑定到 127.0.0.1，但 VcXsrv/Xming 监听的是通配地址 0.0.0.0，不设为 no 就会拒绝连接。
- 确认以下三行在
/etc/ssh/sshd_config中存在且未注释： X11Forwarding yes-
X11UseLocalhost no（Windows 下强制要求） AllowTcpForwarding yes- 改完必须重启服务：
sudo systemctl restart sshd，否则配置完全不生效 - 验证是否生效：
sudo sshd -T | grep -i x11，输出应含x11forwarding yes和x11uselocalhost no
VcXsrv 启动时哪些选项一勾就崩？
VcXsrv 比 Xming 更稳定，但默认勾选的 “Native opengl” 会导致 Matplotlib、RViz、OpenCV 等程序闪退或黑屏——这是 OpenGL 渲染上下文与 Windows WGL 不兼容导致的，不是驱动问题。
- 启动 XLaunch 时务必取消勾选
Native opengl - 必须勾选
Disable access control，否则远程 Linux 无法连接本地 X Server（报错Can't open display） - 选择
Multiple windows，而非Single window，避免窗口嵌套混乱 - Display number 保持默认
:0即可，对应DISPLAY=localhost:0.0是给本地非 SSH 场景用的；SSH 转发实际走的是:10.0，无需手动改这里 - 右下角出现 X 图标才代表服务真正运行，关闭它即断开所有 X11 转发
怎么快速验证 X11 转发链路通没通？
别一上来就跑 RViz 或 matplotlib，先用最轻量的 xclock 或 xeyes 排查。它们不依赖 Python 或 ROS，能直接暴露哪一环断了。
- 在 VSCode Remote-SSH 终端中运行：
xclock - 如果弹窗成功 → 链路完整；如果报
Can't open display→ 检查DISPLAY变量和sshd_config - 如果报
connect to X server failed或空白窗口 → 检查 VcXsrv 是否运行、Disable access control是否开启 - 如果窗口卡死或闪退 → 回头检查
Native opengl是否已取消勾选 - 注意：
xclock成功不代表所有 GUI 程序都行——比如 Qt5 程序可能还需额外设置export QT_QPA_PLATFORM=xcb
DISPLAY 在远程 shell 中是否被正确重载、甚至 Windows 防火墙是否放行了本地 X Server 的端口。任何一个环节静默失败，都会表现为图形程序无声无息地挂掉，而不是清晰报错。 
