navop
融合数据库管理、SSH/SFTP、Redis/MongoDB 与 AI 对话的 Rust 原生桌面工
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
微信扫码咨询客服
POMOAI — 让开源 AI 即刻运行
融合数据库管理、SSH/SFTP、Redis/MongoDB 与 AI 对话的 Rust 原生桌面工
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
有没有想过，为什么管理数据库要用一个工具，连服务器要用另一个工具，调 AI 还要再开一个网页标签？一个真正高效的开发环境，不应该被这些割裂的工具链拖累。
Navop 正是为解决这个痛点而生。它将数据库管理、SSH 终端、SFTP 文件传输、Redis/MongoDB、可视化监控乃至 AI 对话全部整合到一个 Rust 原生桌面应用中，并借助 Zed 团队开源的 GPUI 框架实现 GPU 加速渲染——这意味着界面流畅度足以与原生 App 比肩。
Navop 的作者是 GitHub 用户 feigeCode，这个项目从 2021 年就开始维护，至今已迭代超过三年。项目没有大厂背书，也没有拿到融资，纯粹靠个人热情和对效率工具的极致追求驱动——这一点从仓库的 50+ 个 crates 子模块和详尽的中英双语文档就能感受到。
值得注意的是，Navop 的 License 并非纯粹的 Apache 2.0，而是 Apache 2.0 + Navop Supplementary License（补充条款）。这个补充条款禁止再分发、转售以及在竞争产品中使用，对商业化场景有一定限制，但个人和开源使用完全不受影响。
Navop 的技术选型非常硬核：Rust + GPUI。
GPUI 是 Zed 编辑器团队开源的 UI 框架，提供了声明式的 UI 描述方式和 GPU 加速的渲染管线。与 Tauri/Electron 不同，GPUI 直接用 Rust 构建原生界面，不需要 WebView 桥接层，理论上能实现更好的性能和更小的内存占用。
项目采用 workspace monorepo 结构，核心拆分成 50+ 个独立 crate：
| 模块组 | 代表 crate | 职责 |
|---|---|---|
| 数据库层 | db, db_view | SQL 执行引擎、结果渲染 |
| 连接管理 | connection_form, connection_tunnel, port_forwarding | 连接配置、SSH 隧道、端口转发 |
| 远程操作 | ssh, sftp, sftp_view | SSH 终端、SFTP 文件传输 |
| 缓存/NoSQL | redis-runtime, redis_view, mongodb-runtime, mongodb_view | Redis/MongoDB 专用界面 |
| AI 能力 | ai_chat_view, agent_runtime, public_mcp, tool_runtime | AI 对话、MCP 协议、Agent 工具调用 |
| 扩展系统 | extension-host, extension-runtime, extension-wasm | WASM 扩展运行时 |
| Markdown | markdown-editor, markdown-source | Markdown 编辑与渲染 |
| 远程桌面 | remote_desktop, remote_desktop_view | RDP/VNC 远程桌面 |
依赖层面，项目大量使用 Rust 生态的成熟库：reqwest（HTTP）、tokio（异步运行时，通过 gpui_tokio）、markdown（Markdown 解析）、lsp-types（语言服务器协议）、notify（文件系统监控）等。
Navop 的数据库支持覆盖面极广：
除了基本的 SQL 执行和数据浏览，Navop 还提供：
ferrum-flow 渲染数据库表关系图内置终端支持 SSH 和本地 Shell，提供了：
相比单纯的 SFTP 客户端，Navop 的 SFTP 模块提供了：
Navop 的 AI 能力不是简单调用 ChatGPT API，而是深度集成到各个功能模块：
内置 Markdown 编辑器，支持：
优势：开箱即用 预编译包覆盖 macOS（Apple Silicon + Intel）、Linux（x86_64 + ARM64）、Windows（x86_64），下载对应安装包即可，无需自己编译 Rust 环境。
进阶：源码编译 如果想从源码构建，需要：
./script/bootstrap 安装系统依赖（X11/Wayland 字体等）.\script\install-window.ps1cargo run -p main 启动macOS 用户注意：首次安装 DMG 后，macOS Gatekeeper 可能拦截，需执行：
sudo xattr -rd com.apple.quarantine /Applications/Navop.app
1. License 争议 Navop 的双 License 模式（Apache 2.0 + 补充条款）在开源社区引发过一些讨论。补充条款明确禁止竞争产品使用，意味着如果某公司基于 Navop 改进了自己的数据库管理工具并商业化，可能面临法律风险。这对于想要贡献代码或基于 Navop 做二次开发的团队是一个需要评估的因素。
2. Oracle 依赖问题 内置 Oracle 驱动依赖 Oracle Instant Client（需要手动下载），虽然扩展市场提供了纯 Go 实现的 Oracle 驱动作为替代，但这增加了初始配置的复杂度。
3. Rust 生态的维护成本 50+ 个 crates 的 monorepo 对维护者来说是个巨大挑战。每次 Zed 更新 GPUI rev，都需要同步更新依赖。一旦 Zed 停止维护或 API 不兼容，Navop 将面临迁移成本。
4. 非容器化部署 项目没有提供 Dockerfile 或 docker-compose.yml，意味着不支持 Kubernetes 集群部署，也无法在无图形界面的服务器上通过 Web 访问。
Navop 代表了一个趋势：用 Rust 构建高性能原生应用，以替代 Electron/WebView 方案。GPUI 框架让 Rust UI 开发门槛大幅降低，而 Navop 则是这一技术路线在"开发者工作站"场景的最佳实践之一。
从数据看，169 stars 虽然不算爆火，但在同类工具（数据库管理 + SSH + AI 集成）中已经是一个值得关注的项目。作者坚持三年持续迭代、中英双语文档、国产数据库全覆盖，都说明这是一个认真做产品的项目。
如果你厌倦了在多个工具之间切换，Navop 值得一试。