Electron 主进程和渲染进程，边界一乱 TCP 功能就会变脆

Electron 最开始让人兴奋的地方，是你能用前端技术写桌面应用。可一旦真正接入 TCP 套接字、文件系统或者系统级能力，就会很快遇到另一个问题：主进程和渲染进程到底怎么分工？

我在 2018 年做这类功能时，最明显的感受就是，边界一乱，功能不一定立刻坏，但会变得特别脆。

为什么 TCP 场景最容易把问题放大

因为 TCP 连接天生带状态，而且状态会变化。
连接建立、断开、重连、超时、半连接异常，这些都不是一次性的按钮点击，而是持续中的系统行为。

如果这些状态和页面 UI 状态绑得太紧，一旦窗口刷新、页面切换或者渲染层逻辑重载，连接语义就会跟着变得不稳定。

我更偏向的分工方式

我的做法是把“连接生命周期”尽量收在主进程里，让渲染进程主要负责：

• 展示当前连接状态
• 触发用户动作
• 接收结构化事件结果

而真正的 TCP 建连、重连、心跳、异常恢复，尽量由主进程维护。

为什么不要让渲染层直接扛连接

渲染层更容易被刷新、被销毁、被用户交互打断。
如果把连接对象直接绑在页面生命周期上，表面看起来写得快，后面会遇到很多微妙问题：

• 刷新页面后连接丢失
• 多个窗口重复抢同一条连接
• UI 临时卡顿影响网络状态处理

这些问题排查起来很折磨，因为你很难判断它到底是网络问题，还是界面层把连接语义搅乱了。

事件传递最好比“直接调用”更明确

我后来更喜欢让主进程对外暴露有限的事件和命令，而不是让渲染进程直接伸手拿底层对象。
这样虽然多了一层通信，但边界会清楚很多：谁负责网络，谁负责界面，不容易模糊。

结尾

Electron 写桌面应用时，真正难的往往不是把功能接上，而是把进程职责收干净。尤其 TCP 这种持续连接型能力，只要边界稍微松一点，稳定性就会明显下降。那几年我最大的教训之一，就是别让页面层去承担它并不擅长的生命周期。