独立开发一个AI电商图片工具：为什么我选了 React + Express + SQLite，而不是"更时髦"的技术栈

最近在做一个面向跨境电商卖家的AI图片处理工具（图小秘），从0到1独立完成了整个技术选型和架构搭建。写下这篇，聊聊作为一个从游戏服务端转型过来的开发者，是怎么想这些技术决策的。

背景：我不是Web出身

我做了8年游戏服务端，主力语言是C++/Lua，习惯的是高并发、状态同步、多进程架构这套东西。转做一个电商SaaS工具时，第一反应其实是想用更"重"的技术栈——毕竟大项目经验让人容易往复杂了想。

但独立开发者只有一个人，时间和精力是最贵的资源。所以这次选型的核心原则只有一条：用最少的技术复杂度，撑起足够的业务复杂度。

前端：React，图的是生态而不是炫技

没什么好说的，React的组件化思维和游戏开发里的ECS（实体组件系统）有几分神似，上手成本低。更重要的是生态成熟，遇到问题基本都能查到解法，这对独立开发者太重要了——你没有时间自己造轮子。

后端：Express，够用就是最好

这是最容易被"过度设计"的一环。很多人做SaaS会一上来就上NestJS、微服务、消息队列集群。我选了最朴素的Express，原因很简单：

• 我的业务逻辑核心不在"框架能力"，而在任务编排——调用视觉模型做图片理解、调用OCR识别文字、把结果拼装成可用的电商图片。这套逻辑用什么框架写都一样复杂，框架越重，反而越拖慢迭代速度。
• 单人开发，代码可读性比"架构范式"更重要。Express的路由和中间件模型足够直白，出问题时定位成本低。

这里有个从游戏服务端带过来的习惯：先跑通核心链路，再谈架构。游戏项目里，战斗同步这种核心模块往往是先用最简单的方式验证可行性，再逐步做健壮性加固。SaaS开发也一样，过早引入复杂架构是独立开发者最容易踩的坑。

数据库：SQLite，反直觉但很合理

这是最多人质疑的选择。"做SaaS怎么能用SQLite，用户多了不就崩了？"

但换个角度想：

1. 早期阶段的真实压力根本达不到SQLite的瓶颈。在验证产品是否有人用之前，先上MySQL/PostgreSQL集群纯属过度工程化，多出来的运维成本对独立开发者是纯负担。
2. SQLite的部署成本几乎为零，没有额外的数据库服务器要维护，这对一个人要同时写代码、跑业务、做客服的独立开发者来说，是实打实省下来的时间。
3. 迁移路径是留好的——数据模型设计规范的话，之后要换PostgreSQL也不是推倒重来。

判断的关键不是"哪个数据库更强"，而是"现在的规模真的需要那个强度吗"。

真正的技术难点：不在框架，在任务编排

老实说，前端用什么框架、后端用什么语言，这些选择本身没那么重要。这个项目真正的技术挑战在于：

• 怎么把视觉模型调用 + OCR识别这两个异构工具串联成一条可靠的处理链路
• 长耗时任务怎么做异步队列，避免用户请求超时
• 调用外部API失败了怎么重试和状态恢复，不能让用户卡在"处理中"出不来
• 怎么设计订阅计费和用量控制，这块看似是业务逻辑，实际上对状态一致性的要求不比游戏里的资源结算低

这套"多工具编排 + 状态管理 + 失败恢复"的思路，其实和游戏服务端里"多进程协作、状态同步"的底层逻辑是相通的。技术栈会变，但工程直觉是可以迁移的。

一点心得

独立开发跟在大厂/大项目里做开发，最大的心态差异是：没有人为你的技术选型买单，也没有人替你还技术债。选轻量级的技术栈不是能力不够，恰恰是把有限的精力用在真正有技术含量的地方——业务逻辑本身，而不是框架的"高级感"。

下次可以聊聊异步任务队列和失败重试的具体设计，如果有人感兴趣的话。