在开发复杂的线性工程（如道路施工、长距离管道铺设与多作业区段协同）辅助设计工具时，技术人员经常需要在 Web 端进行高密度的时空冲突检测（Spatiotemporal Conflict Detection）。
当一条长达数十公里的工程干线上同时存在数百个作业方案、每个方案包含复杂的空间里程区间（K100+200 至 K105+800）、缓和曲线过渡带以及精确到分钟级的时间封锁窗口时，纯 JavaScript 在浏览器主线程进行穷举碰撞检测的性能瓶颈便暴露无遗。
为了彻底解决计算卡顿与频繁 GC 造成的掉帧问题，我近期将核心几何与拓扑计算引擎全面迁移至 Rust + WebAssembly (WASM)。今天就来分享这次内核级改造的完整代码与实战细节。
1. 性能痛点：当纯 JS 遭遇多维时空碰撞
在早期的纯 Web 原型中，所有的冲突检测逻辑均由 TypeScript 编写：
// 早期纯 JS 版本的冲突排查逻辑（伪代码）function detectConflicts(tasks: EngineeringTask[]): ConflictReport[] { const conflicts: ConflictReport[] = []; for (let i = 0; i < tasks.length; i++) { for (let j = i + 1; j < tasks.length; j++) { // 1. 时间窗口重叠判定 if (isTimeOverlap(tasks[i].timeWindow, tasks[j].timeWindow)) { // 2. 空间里程段重叠与安全净距计算 if (isStationOverlap(tasks[i].stationRange, tasks[j].stationRange)) { // 3. 复杂缓和曲线横向侵界与配合区段深层几何计算 const detail = calculateSpatialIntersection(tasks[i], tasks[j]); if (detail.hasConflict) conflicts.push(detail); } } } } return conflicts;}随着项目规模扩大，这种实现方式在实际运行中遇到了两大严重瓶颈：
- 计算与复杂几何求交：在包含曲线拟合、变坡点高程换算和临线作业安全包络线的复合计算中，双重循环导致计算耗时直接飙升到 600ms 以上，明显阻塞了 Canvas 的 60FPS 渲染主循环。
- 海量临时几何对象引发的 GC 压力：在计算空间距离与投影向量时，JS 引擎在内存中频繁分配和销毁微型点线对象，导致浏览器产生规律性的“卡顿脉冲（GC Pause）”。
2. 架构重构：Cargo Workspace 模块化设计
为了实现高内聚和跨平台复用（既能在前端由 WASM 调用，也能在本地 CLI 或服务端作为原生二进制运行），我们采用了标准的 Cargo Workspace 架构：
spatial-engine/├── Cargo.toml # Workspace 顶层配置└── crates/ ├── spatial-scene-core/ # 纯 Rust 空间几何算法、拓扑模型与区间树 ├── spatial-scene-cli/ # 命令行工具（用于自动化测试与大批量基准压测） └── spatial-scene-wasm/ # wasm-bindgen 桥接层与前端类型胶水2.1 顶层 Workspace 声明
在根目录的 Cargo.toml 中统一依赖版本管理：
[workspace]members = [ "crates/spatial-scene-core", "crates/spatial-scene-cli", "crates/spatial-scene-wasm",]resolver = "2"
[workspace.dependencies]serde = { version = "1.0", features = ["derive"] }serde_json = "1.0"wasm-bindgen = "0.2"2.2 核心算法层（spatial-scene-core）
在核心库中，我们使用 一维区间树（Interval Tree） + 二维时空包围盒（AABB） 替代了暴力遍历：
- 首先在时间维度构建区间树，将时间复杂度由 降至 ；
- 只有在时间窗口重叠的候选集内，才进一步调用高精度的空间向量投影算法，判定里程段与偏距包络线是否侵界。
pub struct ConflictDetector { tree: IntervalTree<TimeWindow, TaskId>,}
impl ConflictDetector { pub fn detect_all(&self, tasks: &[SpatialTask]) -> Vec<ConflictResult> { let mut results = Vec::new(); // 基于区间树快速过滤候选候选冲突对 for task in tasks { let overlaps = self.tree.find_overlaps(&task.time_window); for other_id in overlaps { if let Some(conflict) = self.eval_spatial_conflict(task, &tasks[other_id]) { results.push(conflict); } } } results }}3. WebAssembly 胶水与跨边界性能优化
将 Rust 代码编译成 WASM 并在前端调用的过程中，最大的开销往往不是计算本身，而是 JS 与 WASM 之间的内存序列化开销。
3.1 摒弃昂贵的 JSON 字符串序列化
早期很多 WASM 教程推荐用 serde_json::to_string 传字符串，但在频繁排查时，庞大的字符串解析反而成了新的瓶颈。
我们采用了 serde-wasm-bindgen 实现 JS 对象与 Rust 内存结构的直接转换：
use wasm_bindgen::prelude::*;use spatial_scene_core::{ConflictDetector, SpatialTask};
#[wasm_bindgen]pub struct WasmSpatialEngine { detector: ConflictDetector,}
#[wasm_bindgen]impl WasmSpatialEngine { #[wasm_bindgen(constructor)] pub fn new() -> Self { Self { detector: ConflictDetector::new() } }
#[wasm_bindgen(js_name = detectConflicts)] pub fn detect_conflicts(&self, val: JsValue) -> Result<JsValue, JsValue> { // 直接从 JsValue 快速反序列化，避免字符串编解码损耗 let tasks: Vec<SpatialTask> = serde_wasm_bindgen::from_value(val) .map_err(|e| JsValue::from_str(&e.to_string()))?;
let conflicts = self.detector.detect_all(&tasks);
serde_wasm_bindgen::to_value(&conflicts) .map_err(|e| JsValue::from_str(&e.to_string())) }}3.2 前端工程化与异步初始化
在前端 Vite 构建体系中，通过标准 ES 模块无缝加载 WASM 编译产物：
import init, { WasmSpatialEngine } from 'spatial-scene-wasm';
let engine: WasmSpatialEngine | null = null;
export async function getSpatialEngine(): Promise<WasmSpatialEngine> { if (!engine) { await init(); engine = new WasmSpatialEngine(); } return engine;}4. 优化成效与基准压测对比
我们在包含 1,000 个复杂作业段、共计 20,000 个空间特征点的测试集上进行了端到端性能基准测试：
| 方案 | 内存占用峰值 | 全量冲突检测耗时 | 60FPS 掉帧率 |
|---|---|---|---|
| 纯 TypeScript 方案 | ~142 MB | 620 ms | 严重卡顿（掉帧率 85%） |
| Rust + WASM 方案 | ~28 MB | 18 ms | 全程丝滑（掉帧率 0%） |
- 耗时降低了 97%：从超过半秒的卡顿直接缩减到单个渲染帧（16.6ms）级别，技术人员在拖拽修改施工区间时，画布可以实现完全实时的动态冲突高亮。
- 零 GC 抖动：核心运算全部在 WASM 线性内存中由 Rust 进行确定性释放，彻底消除了浏览器的 GC 停顿。
5. 结语
将重度计算下沉到 Rust + WebAssembly 并不是“为了技术而技术”，而是在面对复杂工程几何、空间拓扑与多维冲突排查等高计算密度场景时的一把利剑。
通过 Cargo Workspace 的模块化拆分与高效的内存序列化设计，我们不仅收获了数十倍的性能提升，还让同一套空间核心算法兼具了在浏览器端、桌面端与服务端运行的跨平台能力。
如果这篇文章对你有帮助，欢迎分享给更多人！
部分信息可能已经过时