ipcMain.handle(...)
这是伪类型安全，没有运行时保证接收到的IPC消息具有该结构，当传入消息的结构不仅对稳定性有影响，还对安全性有影响时。
我知道这可能听起来像“又一个实现”，但我建议使用joi和joiful的组合来获得静态类型和运行时类型安全。
我查看了你提到的所有潜在候选方案，我之前见过大多数，这导致我多次编写自己的解决方案😆 我将这个问题保持开放，因为我在这个领域有一些想法，但肯定没有近期计划。

这是一个虚假的类型安全
我的理解是，@Juice10 提到的是 TypeScript/开发时类型安全，至少根据它的多次提及。
我查看了你链接的所有潜在候选者，我之前见过大多数，这导致我为自己编写了自己的解决方案。
同样，我在2017年研究过这个问题，无法找到带有类型方法签名的现成库(有些有类型方法名，但没有参数/返回值)。所以我自己为我构建了一个，它仍然帮助我管理多个IPC交互的复杂性，但我承认它是不完整的，因为没有得到发展(它甚至没有使用提到的 handle/invoke 方法，因为那些在2017年并不存在)。所以有一个官方的IPC交互库会很好。
或者 Electron 可以从所有潜在候选者中“选择一个赢家”，并在文档中宣传它。
我认为在文档中宣传还不够，因为这不是一个非常前瞻性的或可持续的场景，但接受在 @electron 组织中维护该库的责任。

这是一个虚假的类型安全
我的理解是，@Juice10 提到的是 TypeScript/开发时类型安全，至少根据它的多次提及。
是的，这是正确的，我更关心的是将错误降到最低，而不是最小化攻击向量(在这种情况下)。
或者 Electron 可以从所有潜在的候选项中“选择一个赢家”，并在文档中宣传它。
我认为在文档中宣传是不够的，因为这不会是一个非常前瞻性的或可持续的场景，但接受在 @electron 组织中维护库的责任。
如果一个外部工具或库最终成为解决方案，那么将其完全纳入 Electron 项目/组织确实是理想的！