QinghuanTools 是我目前最主要的项目。它最初叫 "minitool"，是一个 Windows 上的小工具集合——当初只是想把自己日常用的几个小功能整合到一起。
但做着做着，它长大了。
半年多时间，它从一个简单的 Electron 窗口，变成了一套覆盖 Windows 桌面端和 Linux Web 端的完整平台。集成了 AI 聊天、智能体管理、生图、百家号运营、服务器监控等功能。
这篇文章回顾它的演变过程和背后的架构考量。
第一阶段：一个小窗口
最初的 minitool 非常朴素：一个 Electron 窗口，左侧菜单栏，右侧对应的功能页面。每个功能都是独立的 Vue 组件，数据完全本地化。
这个阶段的优点是简单——加一个新功能只需新建一个组件，注册一个路由。但随着功能增多，问题暴露了：
- 每个功能都有自己的状态管理，没有统一的数据流
- 多个功能间没法共享数据
- 本地存储限制了功能的复杂度
第二阶段：服务端介入
当"百家号运营"这个功能加入时，本地存储已经不够了——需要管理多个账号、存储文章、支持团队协作。于是有了第一个 Python 后端。
这是一个重要的转折点。客户端负责交互，服务端负责数据和业务逻辑——前后端分离的架构慢慢清晰起来。
但此时的服务端还比较混乱：每个功能几乎有一套独立的数据库表、API 路由和认证逻辑。代码复用很少。
第三阶段：重构与统一
功能越来越多，代码越来越乱。我意识到必须做一次大的重构，否则后面会很难维护。
这次重构的核心原则就一条：分层。
我把项目结构改成了：
server/—— 中心服务端，所有功能共用的后端clients/windows/—— Windows 桌面客户端（Electron）clients/linux/—— Linux Web 客户端packages/—— 跨客户端共享的核心包
这个结构的好处是：新增一个平台只需新建一个客户端目录，新增一个功能只需在 server 和 packages 中扩展，各客户端只需接入即可。
好的架构不是设计出来的，是在不断演进中长出来的。关键是在正确的时间做正确的取舍。
架构上的关键决策
回顾整个过程，有几个决策对后续影响很大：
1. 从 socket 到 WebSocket
早期客户端和服务端之间通过原始 TCP socket 通信，自定义了一套简单的协议。但随着功能增多，自定义协议越来越难维护。迁移到 WebSocket 后，基于 JSON 消息的通信清晰了很多，也更容易 debug。
2. 统一认证
最开始每个功能各自管理认证，后来统一为 token 认证 + 角色权限。这不仅简化了开发，还让未来开放 API 给第三方成为可能。
3. 前端订阅机制
早期前端渲染器订阅了太多不必要的数据，导致性能问题。后来重构为"按需订阅"模式——每个组件只订阅自己需要渲染的最小数据集。这个改动让界面流畅度提升了很多。
4. 工具发布站
每次构建后自动上传到发布站，客户端内实现版本检查、增量更新。这让持续交付成为日常，而不是一个需要特别准备的操作。
一些教训
如果让我重新开始，我会：
- 更早地做架构设计。不是过度设计，但至少要给未来留出扩展空间
- 更早引入日志和监控。等到出了问题再补，成本高很多
- 不要把所有功能塞进一个项目。有些功能适合独立成单独的服务
现在与未来
现在的 QinghuanTools 已经相对稳定，但远未完成。它还在持续迭代中——修复 bug、优化体验、增加新功能。
对我来说，它不只是一个工具集，更是一个长期的、持续打磨的作品。就像一个好的工具箱，里面的每一件工具都经过反复使用和改进。
未来我希望它能变得更"安静"——在需要的时候可靠地出现，不需要的时候安静地待着。这是好工具的终极形态。