Erlang/Elixir中使用传入的pid前是否需检查存活状态？

一、使用PID前是否需要检查？ #

首先要澄清：Erlang/Elixir中，进程死亡后，持有PID的变量并不会自动变为undefined——PID是不可变的标识符，进程终止后它只是不再对应活跃进程，但变量仍会保留该PID值，仅在主动赋值或特殊场景下才会出现undefined。

回到问题本身：

• 如果变量存在变为undefined的可能（比如从可选配置、动态进程生成结果中获取），使用前必须检查，否则调用send(undefined, Msg)会抛出BadArg异常。
• 如果是正常持有合法PID的场景，直接调用send/2无需额外检查——向已终止进程的PID发消息，虚拟机只会静默丢弃消息，不会触发崩溃。

二、Nx项目stream.ex中未检查PID的考量 #

这种写法核心是遵循Erlang/Elixir的**「让其崩溃」(Let It Crash)**设计哲学，具体考量包括：

• 职责边界清晰：框架默认调用方会传入合法有效的PID，参数合法性校验应由调用方负责，框架仅处理合法输入的逻辑，代码更简洁。
• 性能优化：高频调用的stream模块，额外的PID检查会增加分支判断开销，省略检查能提升执行效率。
• 问题暴露更直接：若出现无效PID，说明调用方逻辑已出错，让异常崩溃能快速定位根源，而非在框架内部隐藏问题。

三、「让其崩溃」或模块外检查的可行性 #

1. 让其崩溃 #

这是Erlang/Elixir生态的常规解决方案：

• 若传入无效PID属于异常场景（非预期业务逻辑），让进程崩溃是合理的——通过监控树(Supervisor)自动重启，或在上层捕获异常统一处理，既能快速定位问题，又不会导致整个系统崩溃。
• 比如向undefined发消息抛出的异常，可通过try/rescue或监控进程的EXIT信号做兜底处理。

2. 模块外检查 #

更适合业务代码场景：

• 在调用stream模块函数前，自行通过is_pid/1判断PID合法性，或确保变量不会为undefined。
• 把参数校验职责放在业务层，既保证框架代码简洁，又能在业务逻辑层面提前拦截无效输入。

内容的提问来源于stack exchange，提问作者Chen Yu