# AR14 — 跨项目技术选型对比分析

> **日期：** 2026-09-23
> **状态：** 参考文件（记录 pj0235 与 pj0237 两项目的技术栈选型依据与结论）

---

## 1. 项目概览

### pj0235-eai_agentplatform（企业智能体平台）

| 维度 | 说明 |
|------|------|
| 项目类型 | 企业管理平台（培训、考试、知识管理、AI 助手） |
| 当前语言 | Go 1.25 |
| Web 框架 | Gin |
| ORM | GORM |
| 数据库 | SQLite（modernc 纯 Go 驱动） |
| 前端 | Vue 3 + Vite + Element Plus |
| 部署方式 | 静态二进制（38MB）+ systemd + Nginx |
| 交付形态 | 单二进制部署，无需运行时依赖 |

### pj0237-mobwx_chatextr（微信聊天记录导出工具）

| 维度 | 说明 |
|------|------|
| 项目类型 | 桌面/移动端工具（微信数据采集、传输、解密、解析） |
| 当前语言 | Rust |
| 客户端框架 | Tauri 2（桌面端 + Android） |
| 核心 crate | crates/core、crates/transfer、crates/ipc、crates/keywrap、crates/device、crates/desktop |
| 传输协议 | SFTP（ssh2 crate，调用 libssh2） |
| 前端 | JS（Tauri Webview 注入） |
| 部署形态 | 多平台二进制（Windows / Linux / macOS / Android） |
| 历史实现 | Go 实现已归档至 ahchive_goverson_ 目录 |

---

## 2. pj0235：为什么不选 Rust

### 2.1 当前 Go 方案已完全满足需求

| 需求 | Go 实现情况 |
|------|------------|
| 本地化部署 | `CGO_ENABLED=0 go build` 生成 38MB 静态二进制，无需任何运行时 |
| 不泄露源码 | 静态链接二进制无法反编译回源码 |
| 性能足够 | 企业级应用（CRUD + AI 调用），Go 性能绰绰有余 |
| 生态成熟 | Gin + GORM + JWT + bcrypt 组合经过生产验证 |

### 2.2 重构成本与收益严重失衡

- 代码规模：Go 后端约 200+ 个文件（15-25 万行），前端约 100+ 个文件
- 业务场景：培训管理、AI 对话、知识检索——不是需要 Rust 极致性能的场景
- Rust 生态：ORM（Diesel/sea-orm）成熟度不及 GORM，JWT 等库需自行整合
- 学习成本：团队需投入 Rust 异步运行时、所有权系统等学习时间

### 2.3 Go 二进制安全性已经足够

静态链接 + 无源码分发，逆向难度已经很高。Go 的运行时和反射机制使得反编译比 Rust 更困难。

---

## 3. pj0237：为什么 Rust 是正确选择

### 3.1 Tauri 框架天然绑定 Rust

Tauri 的核心（`tauri` crate）是 Rust 写的。使用 Tauri 意味着：
- 核心逻辑用 Rust 可实现桌面端与移动端共享
- 避免 JS 桥接层的开销和 bug
- Rust 与 Tauri 的 FFI 是原生而非桥接

### 3.2 加密敏感场景需要内存安全

项目涉及：
- 微信数据库密钥（`wrapped.key`，MWXK 私有格式）
- SSH 私钥认证
- 数据库解密（SQLCipher 兼容）

Rust 的编译时内存安全保证在这些场景下是真实收益。

### 3.3 跨平台二进制交付需求

输出需要覆盖四个平台：

| 平台 | 输出 |
|------|------|
| Windows | `mwx.exe` |
| Linux | `mwx` |
| macOS | `mwx` |
| Android | `mwx-agent`（Go 实现） |

Rust 跨平台编译能力成熟，`Cargo` 一次定义、多平台构建。

### 3.4 与旧 Go 实现的对标

核心 `transfer` crate 实现了 SFTP 传输、断点续传、SHA256 完整性校验：
- 完整的类型系统（`Manifest`、`FileEntry`、`UploadState`、`TransferError`）
- 详尽的单元测试（1800+ 行测试）
- `ssh2` crate 直接调用 libssh2，比 Go 的 `pkg/sftp` 更贴近底层

从归档目录看，旧 Go 实现已跑通 MVP，Rust 是在验证可行后的工程化升级。

---

## 4. 对比结论

### 4.1 决策矩阵

| 维度 | pj0235（企业平台） | pj0237（微信工具） |
|------|-------------------|-------------------|
| 项目类型 | 业务管理系统（SaaS） | 桌面/移动端工具（本地部署） |
| 核心逻辑 | 业务 CRUD + AI 调用 | 加密 + SFTP 传输 + 数据库解析 |
| 安全敏感度 | 中等（JWT + 角色权限） | 高（私钥 + 数据库密钥） |
| 多端共享 | 无需（前端独立） | 必须（桌面 + 移动端共享核心） |
| 交付平台 | Linux 服务器 | Windows + Linux + macOS + Android |
| 性能瓶颈 | 无 | 文件 I/O + 加解密 |
| 推荐语言 | Go（已选） | Rust（已选） |

### 4.2 核心原则

**项目类型决定技术栈，不是流行度决定。**

| 场景 | 推荐 | 原因 |
|------|------|------|
| 业务管理系统、微服务、SaaS | Go | 开发效率高，生态成熟，足够好用 |
| 加密敏感、系统编程、FFI 调用多 | Rust | 编译时内存安全，贴近底层 |
| Tauri 桌面应用 | Rust | 框架绑定，核心逻辑天然共享 |
| 多平台二进制分发 | Rust 或 Go | 两者都支持，Rust 更统一 |
| AI/LLM 调用密集型 | Go 或 Python | 不需要 Rust 的极致性能 |

### 4.3 GitHub Rust 项目多的误导性

GitHub 上 Rust 项目数量多、增长快，但这：
1. 反映的是**增长率**，不是绝对总量（JS、Python 仍远超）
2. 受社区开源文化影响（Rust 社区天然开源）
3. 大量是工具库、框架、基础设施项目，而非业务应用

流行度 ≠ 技术选型正确性。两个项目都选对了各自的工具。

---

## 5. 对其他项目的参考

当评估新项目技术栈时，依次判断：

1. **是否需要内存安全保证？**（加密、驱动、协议解析 → 倾向 Rust）
2. **是否绑定特定语言框架？**（Tauri → Rust，Spring → Java）
3. **核心瓶颈在哪里？**（CPU/内存密集 → 可能 Rust，I/O 密集 → Go/Python 均可）
4. **是否需要快速迭代？**（业务探索期 → Go/Python，稳定期 → 语言选择次要）
5. **团队熟悉度如何？**（已有经验优先，除非有强技术理由）
6. **交付形态是什么？**（容器化微服务 → Go/Java，单机二进制 → Go/Rust）