每个MVP都有蜜月期。用户少、数据库空、服务器快，点击按钮、发送请求、后端响应、界面更新——一切顺滑得像在本地运行。你甚至会天真地以为这套架构能一路撑到上市。

然后产品长大了。列表变长、筛选变复杂、分析功能上线、表关系乱成蜘蛛网、用户数持续爬升。我们在做Finsight时撞上了这堵墙。这类产品的特点是读操作极多：交易记录、分类筛选、统计总计、月度视图、快捷编辑。如果每个页面都要等服务器，整个产品就像背了沙袋跑步。

打开网易新闻 查看精彩图片

用户盯着加载动画的时间，比真正操作产品还长。打开列表，等。改个字段，再等。网络明明正常，服务器也没挂，但体验就是卡。最难受的是——技术上明明没做错任何事。

打开网易新闻 查看精彩图片

常规疗法我们都试了一遍。检查PostgreSQL索引、加分页、缓存接口、把重计算移出热点路径、跑EXPLAIN ANALYZE、砍掉多余JOIN、拆分大查询、优化序列化器、前端加防抖。有用，但不够。

问题根源不是后端慢，是"请求-等待"这套架构本身。经典流程：点击→请求→等待→响应→更新界面。网络和 backend 快的时候没问题，但移动网络一抖、服务器稍慢、数据库卡一下，界面就被等待锁死。用户每次操作都要和网络谈判。

打开网易新闻 查看精彩图片

我们决定换条路：本地优先。界面主数据源变成用户设备上的SQLite数据库。后端没消失——它 still 管认证、权限、业务规则、校验，PostgreSQL仍是中央存储。但React不再每次显示列表或更新字段都调API。

新流程：React界面→本地SQLite→PowerSync→后端→PostgreSQL。用户点击保存，记录先进本地库，界面几乎立刻更新，PowerSync后台同步到后端。点击→本地写入→更新界面→后台同步。卡顿消失了。