碰到这种情况真的挺闹心的，我之前也踩过类似的坑，给你整理几个亲测有效的解决思路，你可以挨个试试：

• 手动指定Python解释器路径
  既然自动探测卡壳了，咱们直接跳过这个步骤手动指定。按下Ctrl+Shift+P（Windows/Linux）或Cmd+Shift+P（Mac）打开命令面板，输入Python: Select Interpreter，选择Enter interpreter path...，直接输入远程Ubuntu上Python解释器的绝对路径就行——比如系统默认的/usr/bin/python3，或者你自己虚拟环境里的~/venv/bin/python，指定后应该就能正常使用扩展功能了。

• 关闭Python扩展的自动探测功能
  打开VS Code设置（快捷键Ctrl+,），搜索Python: Discovery Mode，把它改成off，这样扩展就不会再自动扫描解释器了。另外也可以检查Python: Discovery Paths，如果里面包含了太多冗余路径，也可能导致探测卡住，把没用的路径删掉就行。

• 清理远程端的vscode-server缓存
  远程机器的vscode-server缓存损坏也可能引发这类问题。登录到Ubuntu终端，找到~/.vscode-server目录，直接删掉它，然后重启VS Code重新连接SSH——这个操作会重新部署vscode-server，很多奇怪的CPU占用问题都能这么解决。

• 更新Python扩展和VS Code到最新版本
  有时候是扩展或编辑器本身的bug导致的，打开VS Code扩展面板，找到Microsoft的Python扩展检查更新，同时把VS Code本体也更到最新版，重启后再试试连接。

• 排查远程机器的Python环境
  看看远程Ubuntu上的Python环境有没有异常，比如多版本冲突、路径权限问题之类的。可以在终端里运行which python3、python3 --version确认环境正常，也可以新建一个干净的虚拟环境，指定这个环境的解释器，看看还会不会出现探测卡住的情况。

如果以上方法都不管用，你可以试试在远程终端里调试vscode-server进程：先用ps aux | grep vscode-server找到进程ID，再用strace -p <进程ID>查看它的运行日志，能帮你定位到底是哪个环节卡住了（不过这个需要点Linux调试基础）。

备注：内容来源于stack exchange，提问作者Rani Pinchuk