sublime Text 仅是轻量编辑器，erlang/OTP 的高并发与容错核心在于原生 Actor 模型（轻量进程、消息通信、无共享）和监督树机制（强制层级管理、崩溃重启策略、幂等初始化）。
sublime text 本身不是 Erlang/OTP 的开发环境，它只是一个轻量级代码编辑器；真正支撑高并发、容错与热升级的是 Erlang 运行时和 OTP 框架。要高效开发 Erlang/OTP 系统，关键不是换编辑器，而是理解 Actor 模型如何落地、监督树怎样组织进程生命周期——这些才是高并发稳定性的核心。
Actor 模型：每个进程都是独立的“小宇宙”
Erlang 的 Actor 不是概念抽象，而是语言原生支持的轻量进程（spawn 出来，内存隔离，仅通过消息通信）。它不共享状态，不锁资源，天然规避竞态和死锁。
- 一个 gen_server 就是一个 Actor：有自己私有状态、接收消息的 handle_call/handle_cast/handle_info 回调、可自主决定是否响应或崩溃
- 消息传递是异步且不可靠的（没有“发送成功确认”），所以设计上必须容忍丢包或延迟——比如用 confirm 消息 + 超时重发，而不是依赖 TCP 可靠性
- 别在 Actor 里做耗时操作（如文件读写、http 同步请求），否则会阻塞整个调度器；该用 spawn 或 Task.async 的地方就拆出去
监督树：让崩溃变得“可预期、可管理”
OTP 的监督树不是设计模式，是强制约定：每个子系统必须由 supervisor 管理，而 supervisor 本身又被上层 supervisor 管理，形成树状结构。崩溃不是 bug，而是正常控制流的一部分。
- supervisor 启动子进程时指定启动策略（one_for_one / one_for_all / rest_for_one）和重启强度（比如 5 秒内最多重启 10 次），这决定了故障传播边界
- 子进程崩溃后，supervisor 默认会按 child_spec 重新拉起——这意味着你写的 init/1 必须幂等、可重入，不能假设“只运行一次”
- 不要在 supervisor 的 init/1 里做业务初始化（如连接数据库），应放到子进程的 init/1 中；否则 supervisor 崩溃会导致整棵树重启，扩大故障面
Sublime 配合 Erlang 开发：务实提效的几件事
用 Sublime 写 Erlang 没问题，但得补足生态短板，重点不是语法高亮，而是快速跳转、编译反馈和调试感知。
- 装 Erlang Build 系统插件，绑定 rebar3 compile 命令，保存即编译，错误直接定位到行
- 配合 SublimeREPL 或 Terminal（macOS/linux）+ tmux，开个 shell 运行 erl -pa _build/default/lib/*/ebin，实时 reload 模块测试行为
- 用 Erlang Sublime Text 插件支持 .app.src 和 .rel 文件识别，避免手写错 application Resource 规范导致 start_phase 失败
基本上就这些。Erlang/OTP 的力量不在语法多炫，而在把并发、失败、升级变成可声明、可组合、可推演的结构——Actor 是单元，监督树是骨架，其余都是填充。Sublime 只是笔，画对图才重要。