eaiadmin
89ae31c998
- 将 wechat_official_account 重命名为 weixin_public_account，符合中文命名规范 - 新增 DOCX 文档生成技能、聊天历史、请求 ID 中间件 - 增强工作流、热点服务、文章服务等模块功能 - 前端同步重命名组件和 API - 新增架构文档 AR13/AR14、专员文档更新 - 补充测试用例(seed_specialists_test, db_migration_test) Co-Authored-AI: yes
5.8 KiB
5.8 KiB
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+ 行测试）
ssh2crate 直接调用 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 项目数量多、增长快，但这：
- 反映的是增长率，不是绝对总量（JS、Python 仍远超）
- 受社区开源文化影响（Rust 社区天然开源）
- 大量是工具库、框架、基础设施项目，而非业务应用
流行度 ≠ 技术选型正确性。两个项目都选对了各自的工具。
5. 对其他项目的参考
当评估新项目技术栈时，依次判断：
- 是否需要内存安全保证？（加密、驱动、协议解析 → 倾向 Rust）
- 是否绑定特定语言框架？（Tauri → Rust，Spring → Java）
- 核心瓶颈在哪里？（CPU/内存密集 → 可能 Rust，I/O 密集 → Go/Python 均可）
- 是否需要快速迭代？（业务探索期 → Go/Python，稳定期 → 语言选择次要）
- 团队熟悉度如何？（已有经验优先，除非有强技术理由）
- 交付形态是什么？（容器化微服务 → Go/Java，单机二进制 → Go/Rust）