vscode 不运行 lisp 代码，需正确配置解释器（sbcl/clisp）、扩展、路径及文件类型识别；路径须为无空格绝对路径，语言模式需手动设为 common lisp，光标须在有效 s-表达式内，slime 不适用于 vscode。
直接说结论：VSCode 本身不运行 Lisp 代码，它只调度本地解释器；Common Lisp 要跑起来，必须装好 SBCL 或 CLISP，并配对正确扩展 + 正确路径 + 正确文件类型识别，三者缺一不可。填错路径、用错扩展、没设语言模式，90% 的“点不动”“报 ENOENT”“Ctrl+Enter 没反应”都卡在这儿。
CLISP 在 Windows 上总报 spawn clisp ENOENT
这是路径配置最典型的失败现象——VSCode 找不到 clisp.exe。CLISP 扩展不会自动探测安装位置，尤其 Windows 下极易踩坑。
-
lisp.clispPath必须填绝对路径，例如C:\clisp\clisp.exe，不能只写clisp或clisp.exe - 路径含空格（如
C:\Program Files\clisp\clisp.exe）会触发解析失败，建议重装到无空格路径（如C:\clisp） - 确认命令行能直接运行：
clisp -q进入 REPL，否则 VSCode 一定失败 - 首次打开
.lisp文件后，右键 → Change Language Mode → 选 Common Lisp，否则快捷键无效
SBCL + Calva 启动 REPL 却没反应
Calva 不是“点一下就启动 REPL”，它依赖 Roswell 启动 SBCL，且默认不读取用户级配置（比如 ~/.clisprc），容易卡在“连接中”或静默退出。
- 先验证底层是否通：终端运行
ros run -- -q，能进 SBCL *提示符*才算 OK - Calva 设置里别填
sbcl.exe路径——它走ros命令链，填了反而冲突 - Quicklisp 加载必须显式写进项目级
load.lisp或 Calva 的calva.replConnectSequences，(ql:quickload "...")不会自动执行 - 如果状态栏显示 “No REPL process found”，先关掉所有终端面板再重试，Calva 有时残留旧进程占端口
Ctrl+Enter 发送空行或卡住 REPL
这不是扩展 bug，而是光标位置导致的语义误判：Common Lisp 扩展和 Calva 都按当前光标所在“S-表达式”发送，但注释行、空白行、括号外位置会发空内容，REPL 就卡住。
- 光标必须落在有效 S-表达式内部（比如
(defun foo () ...)的任意非注释字符上），不能停在;后或行首空白处 - 整文件发送用
Ctrl+Shift+Enter（Common Lisp 扩展）或Ctrl+Alt+Enter（Calva），不是保存后自动运行 - 若已卡住，手动在 REPL 输入
:q退出当前输入态，再重新触发
为什么 SLIME 在 VSCode 里永远装不上
SLIME 不是插件，它是 Emacs 原生生态的一部分，深度耦合 elisp 运行时、swank 协议和 Emacs UI 控件。VSCode 没有这些组件，任何叫 “SLIME for VSCode” 的扩展都是名字误导或早已失效。
- 搜索结果里出现的 “VSCode SLIME 插件”，实际只是语法高亮，或连不上 swank 就报
Connection refused - 想用 SLIME，必须换 Emacs；想留 VSCode，就接受 Calva 或 Alive 的替代交互模型
- Calva 支持
calva.expandMacro和calva.evaluateTopLevelForm，覆盖日常调试，但没有slime-inspect那类对象树探查能力 - Alive 更接近 SLIME 体验（支持内联 macroexpand、inspect 点开），但它只认 SBCL + ASDF + Quicklisp，且需手动配
alive-lsp启动命令
真正麻烦的从来不是装插件，而是解释器、路径、文件类型、光标位置这四层叠加校验——每层漏一个，就停在黑屏或报错里。别跳步骤，一行一行敲命令验证，比反复重启 VSCode 有用得多。
