VSCode本身不运行Elixir代码，也不提供分布式环境，仅通过erlang-ls调试器连接已配置的命名Erlang节点（需-name、-setcookie及网络就绪），并可视化其OTP进程树与消息队列。
VSCode 本身不运行 Elixir 代码，更不“提供”分布式运行环境——它只调用你本地已安装的 Erlang/OTP 节点，而分布式能力完全由 erl 启动参数（-name、-setcookie）和系统网络配置决定。所谓“在 VSCode 中运行分布式 Elixir”，本质是让调试器能连接并观察一个带名、可通信的 Erlang 节点。
确认 erl 支持命名节点且网络就绪
Elixir 分布式依赖底层 Erlang 节点通信，VSCode 不参与启动，但若 erl 不支持或系统阻断，Node.connect/1 会静默失败、Node.list() 返回空列表。
- 终端执行
erl -name test@127.0.0.1 -setcookie abc，成功进入 shell 即表示 OTP 支持命名节点 - 检查防火墙是否放行 EPMD 端口（默认
4369）和 Erlang 分布式端口段（默认9000–9100） - 确保所有参与节点使用相同
-setcookie值，且主机名可解析（ping test@127.0.0.1应通） - Mac 用户用
asdf时，asdf current erlang输出的 OTP 版本需 ≥ 25.0；自编译 OTP 需启用+sname/+name支持
用 erlang-ls 替代 ElixirLS 启动调试会话
type: "mix_task" 配置永远以单节点、:nonode@nohost 方式运行，无法用于验证分布式逻辑。必须切换为 erlang 类型调试器，并显式传入节点参数。
- 卸载或禁用非必要扩展，只保留
erlang-ls.erlang-ls（作者 erlang-ls）和elixir-lsp.elixir-ls（二者功能互补，不可互换） - 项目根目录下创建
.vscode/launch.json，配置中必须含："type": "erlang"、"node": "test@127.0.0.1"、"setcookie": "abc" -
"startFun"推荐设为"application:start"，"startArgs"设为"[myapp]"（替换为你的应用名） - 启动后，调试侧边栏会出现
Processes、Ports、Applications标签页，点击进程可查看消息队列与状态
避免 mix_task 模式干扰分布式上下文
即使你写了 Node.start(:myapp@127.0.0.1) 或 :net_kernel.start/1，在 mix_task 下仍会因启动隔离而失效——这不是代码问题，而是 Mix 的默认行为。
- 不要在
launch.json里用type: "mix_task"调试跨节点调用、RPC 或:global.register_name/2等操作 - 若必须从 Mix 入口启动（如
mix phx.server），可在config/runtime.exs中强制注入：System.put_env("ELIXIR_ERL_OPTIONS", "-name myapp@127.0.0.1 -setcookie abc") - Umbrella 或 Phoenix 项目需确保顶层
mix.exs已加载，且mix deps.get成功——否则erlang-ls无法索引跨应用模块，Node.spawn/3可能报no such process
真正容易被忽略的是：VSCode 的 erlang-ls 调试器不自动帮你启动 EPMD 或管理 cookie 文件，所有节点通信前提都得靠你在终端手动验证过一遍。没跑通 erl -name a@127.0.0.1 -setcookie x 和 erl -name b@127.0.0.1 -setcookie x 并成功 net_adm:ping('a@127.0.0.1')，VSCode 里再怎么配 launch.json 都只是黑盒。
