eaiadmin
89ae31c998
- 将 wechat_official_account 重命名为 weixin_public_account，符合中文命名规范 - 新增 DOCX 文档生成技能、聊天历史、请求 ID 中间件 - 增强工作流、热点服务、文章服务等模块功能 - 前端同步重命名组件和 API - 新增架构文档 AR13/AR14、专员文档更新 - 补充测试用例(seed_specialists_test, db_migration_test) Co-Authored-AI: yes
151 lines
5.8 KiB
Markdown
151 lines
5.8 KiB
Markdown
# 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）
|