erl命令必须在VSCode内置终端中可用，否则所有扩展功能失效；需通过code .启动或配置shell环境确保PATH继承，并显式设置erlang.erlPath和erlang.rebar3Path路径。
erl 命令必须在 VSCode 内置终端中可用，否则所有扩展（包括调试、跳转、补全）都会失效——这不是插件问题，是环境没接上。
确认 erl 和 rebar3 在 VSCode 终端里真能跑
很多人装完插件发现“跳转定义”灰色、“调试按钮不可点”，第一反应是重装插件，其实根本原因是 VSCode 没继承到正确的 PATH。
打开 VSCode 内置终端（Ctrl+`），执行：
which erl which rebar3
如果返回空或报错 command not found，说明 VSCode 启动时没拿到你配置的 Erlang 路径。这时别急着改插件设置，先解决环境继承问题：
- 在终端里手动运行
code .启动 VSCode（而不是从桌面图标启动），它会继承当前终端的PATH - 或者把
erl和rebar3的路径加进系统级 shell 配置（如~/.zshrc或~/.bashrc），再完全退出并重启 VSCode - Windows 用户注意：
erl.exe路径里不能含中文或空格；若用 asdf 管理版本，确保asdf reshim erlang已执行
erlang-ls 扩展不工作？检查 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→ 比如/home/you/.local/bin/rebar3，不是rebar3.bat或软链接，要指向可执行文件本体
改完后必须重启 VSCode，语言服务器才会重新拉起。验证方式：打开任意 .erl 文件，看右下角状态栏是否显示 erlang-ls: ready。
调试 Erlang OTP 应用前，先确保 application:start/1 能在 shell 里手动跑通
VSCode 调试器本质是启动一个带调试参数的 Erlang 节点，然后 attach 上去。如果连 application:start(myapp) 都报 {error,{not_started,other_dep}}，调试配置写得再对也没用。
推荐调试前走通这三步：
- 在项目根目录运行
rebar3 shell，进入带完整应用路径的 shell - 执行
application:ensure_all_started(myapp).，确认无依赖缺失 - 再对照
launch.json中的startFun和startArgs，确保函数签名与实际模块一致（比如有些项目用myapp:start/0，而非application:start/1）
常见坑：startArgs 是字符串形式的 Erlang 项，必须严格匹配语法，比如 "[myapp, permanent]"，多一个空格或少一对括号都会导致节点崩溃。
并发调试时，node 名和 cookie 必须和 erl -name 启动参数完全一致
分布式调试的核心是节点间认证。VSCode 调试器会尝试连接一个已存在的 Erlang 节点，而这个节点必须用相同 -name 和 -setcookie 启动。
例如，你在 launch.json 里写了：
"node": "myapp@127.0.0.1", "cookie": "abc123"
那你就得在终端里这样启动节点：
erl -name myapp@127.0.0.1 -setcookie abc123 -pa _build/default/lib/*/ebin
漏掉 -pa 会导致模块找不到；-name 里 IP 写成 localhost 而配置里是 127.0.0.1 也会连不上——Erlang 认为这是两个不同节点。
更隐蔽的问题：某些 Linux 发行版默认禁用 epmd（Erlang Port Mapper Daemon），调试器连不上节点时先检查 ps aux | grep epmd 是否存活。
