从 React 到 Rust，没有 try/catch

我独立构建了三个库。当将它们放入同一个项目时，它们之间的边界消失了。这就是最终留下的成果。

这条路径：在 React 表单中的一次点击，经过模式验证，进入在 WebAssembly 中运行的 Rust 求解器，再通过一个类型化的 Result 返回，最终输出为渲染好的猪排图热力图——整个过程中没有任何地方使用 try/catch 进行控制流管理。

这些库包括：

lambert-izzo —— 用于解决兰伯特问题的 Rust 求解器，通过 wasm-pack 暴露给 JavaScript。它返回一个类型化的 LambertOutcome；领域内的失败以值的形式返回，而不是作为异常抛出。
@railway-ts/pipelines —— 提供 Result<T, E>、Option<T>、模式验证以及组合功能。Brotli 压缩后约 4.8 kB，完全支持树摇优化。
@railway-ts/use-form —— 模式优先的 React 表单。该模式是类型、验证、字段路径和错误位置的唯一真实来源。

出于设计目的，它们共享一种编程习惯：区分联合类型的结果，不使用异常进行控制流管理。有趣的问题是，当将它们放入同一个项目时会发生什么。简短的回答是：接缝消失了。

演示程序位于 stackblitz.com/edit/vitejs-vite-9hmwtvdt。在阅读其余内容之前，请先去运行它——它很小，源代码本身就是最好的论证。

关于受众的说明：如果你以前使用过 Result/Option 编程习惯——例如在 Rust、fp-ts 或 neverthrow 中——那么代码示例读起来会很自然。如果你没有用过，前几个示例可能会感觉像行话。猪排图部分会让这种语法显得物有所值；请坚持看下去。

90 秒了解兰伯特问题

两个位置矢量 r₁ 和 r₂。一个飞行时间 tof。一个引力参数 μ。找出在牛顿引力作用下连接这两点的速度 v₁ 和 v₂。这就是兰伯特两点边界值问题，达里奥·伊佐于 2014 年发表了一种快速且稳健的算法来解决它。

每当你需要设计转移轨道时，都会用到它：例如地球到火星的发射窗口、卫星交会任务或碎片清除任务。它是猪排图背后的主力工具——猪排图是一种覆盖（出发日期 × 到达日期）的热力图，显示窗口内每次转移所需的总速度增量（Δv）。成本最低的单元格即为发射窗口。

该问题也有明确定义的失败模式：

CollinearGeometry（共线几何）—— r₁ 和 r₂ 指向同一方向；转移平面未定义。
DegeneratePositionVector（退化位置矢量）—— 其中一个半径为零。
NonPositiveTimeOfFlight（非正飞行时间）、NonPositiveMu（非正引力参数）、NonFiniteInput（非有限输入）—— 数值错误。
RevsOutOfRange（圈数超出范围）—— 多革命圈数超出 1..=32 的范围。

这些不是异常。它们是情况分类。

一个小巧的契约，被一致地应用：

带有原因的失败 是一个 Result<T, E>。两个分支都有类型。预期的失败不会作为用户代码中抛出的异常进行传递。
单纯的不存在 是一个 Option<T>。没有 null，没有 undefined，在询问“我是否有值？”的边界处，也没有 ?.foo ?? bar 这样的链式调用。

免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。