erl命令在vscode终端不可用导致所有erlang插件功能失效，根本原因是环境变量path未正确继承；需通过code .启动或配置shell文件确保path生效，并显式设置erlang.erlpath和erlang.rebar3path为绝对路径，重启vscode后验证erlang-ls: ready状态。
erl命令在VSCode终端里跑不通，所有功能都失效
VSCode的Erlang插件（如erlang-ls）不读系统PATH，它依赖终端能直接执行erl和rebar3。如果内置终端里which erl返回空，跳转、补全、调试按钮全灰——这不是插件坏了，是环境没接上。
验证方式：按 Ctrl+` 打开VSCode内置终端，运行：
which erl which rebar3
若任一命令报command not found，立刻停手，别改插件设置。解决路径继承问题才是关键：
- 在已配置好
PATH的终端中执行code .启动VSCode（而非桌面图标） - Linux/macOS：把
export PATH="/path/to/erlang/bin:$PATH"加进~/.zshrc或~/.bashrc，然后完全退出VSCode再重开 - Windows：确保
erl.exe路径不含中文或空格；若用asdf，先运行asdf reshim erlang
erlang.erlPath和erlang.rebar3Path必须填绝对路径
即使which erl有输出，erlang-ls语言服务器仍可能启动失败——它默认忽略PATH，只认你手动填的绝对路径。
打开VSCode设置（Cmd+, ），搜索并填写：
-
erlang.erlPath→ 填/usr/local/lib/erlang/bin/erl（macOS/Linux）或C:\Program Files\erl-25.3\bin\erl.exe（Windows） -
erlang.rebar3Path→ 填rebar3可执行文件本体，不是rebar3.bat，也不是软链接（比如/home/you/.local/bin/rebar3）
改完必须彻底重启VSCode，否则语言服务器不会重载。验证：打开任意.erl文件，右下角状态栏应显示erlang-ls: ready。
调试前application:start/1必须能在shell里手动跑通
VSCode调试器本质是启动一个带调试参数的Erlang节点，然后attach上去。如果连application:start(myapp)都返回{error,{not_started,other_dep}}，说明依赖没拉起，调试配置写得再对也白搭。
实操建议：
- 先在VSCode终端里运行
rebar3 shell，进入带项目路径的Erlang shell - 手动执行
application:ensure_all_started(myapp).，确认无报错 - 若失败，检查
rebar.config是否声明了deps，以及myapp.app.src里的applications列表是否完整 - 只有这一步通过，再配
launch.json才有效
launch.json里request: launch和attach的区别很关键
选错request类型会导致调试器卡住或连接拒绝。两种模式用途完全不同：
-
"request": "launch"：VSCode自己启动一个新Erlang节点，适合单模块快速验证，但无法观察OTP进程树全貌 -
"request": "attach"：连接一个已运行的节点（比如iex --name debug@localhost --cookie my_cookie -S mix），适合调试真实OTP应用和分布式行为
常见错误：
- 用
launch方式却没配startFun和startArgs，节点启动后立即退出 - 用
attach方式但cookie或hostName与目标节点不一致，报Node is not responding - 调试Elixir项目时，
erlang.rebar3Path被误设为mix路径——这是错的，mix不参与erlang-ls的语言服务
真正容易被忽略的是：erlang-ls只管Erlang代码，而Elixir项目需靠ElixirLS驱动；两者路径不能混用，elixirLS.erlangPath和elixirLS.elixirPath必须单独配置且指向正确二进制。
