Creativor 技术架构全解：四端 + Flask 后端是怎么搭的¶

第 6 篇。技术向，聊聊我们为什么这么搭，踩了什么坑，做了什么取舍。

一、为什么是四端¶

Creativor 的用户场景很分散：

创意团队桌面端：项目管理、Brief 编辑、资产预览，需要大屏、键盘、复杂表单——Web 最合适。
移动端轻量查看：出差路上评审、微信里打开分享页——H5 最合适。
微信生态传播：群内分享、订阅通知、轻量创作——小程序最合适。
原生体验与离线：差旅无网络时查看、推送通知、相机调用——Flutter App 最合适。

四端不是冗余，是不同场景的差异化覆盖。一套数据契约，四个壳，各取所需。

二、技术栈选型¶

端	技术	选型理由
Web	Vue 3 + Vite + Element Plus	Vue 3 组合式 API 写着舒服，Element Plus 后台组件齐全
H5	Vue 3 + Vant	Vant 移动端组件最全，和 Web 共享 Vue 生态
小程序	uni-app	一套代码多端，重点投微信小程序
App	Flutter	跨平台 + 原生体验，重点出安卓 APK
后端	Flask + SQLite + JWT	轻量、好部署、单文件可跑，原型阶段够用

为什么后端用 Flask 不用 Next.js API Route？因为 Creativor 原型是 Next.js，但 API Route 和前端耦合太紧，四端共用时拆出来更干净。Flask 单独部署，前后端彻底分离，四端都是纯客户端。

为什么 SQLite 不用 Postgres？原型阶段单机够用，零运维，后面规模化再迁移。SQLite + WAL 模式撑 50 并发没压力。

三、数据契约统一¶

四端共用一套 REST API，核心接口：

GET    /api/projects                    项目列表
POST   /api/projects                    新建项目
GET    /api/projects/<id>               项目详情
PUT    /api/projects/<id>/brief         更新 Brief
POST   /api/projects/<id>/engine        启动创意引擎
POST   /api/projects/<id>/generate/<type>  生成资产（text/image/audio/video）
GET    /api/projects/<id>/assets        资产列表
POST   /api/projects/<id>/share         生成分享链接
GET    /api/share/<token>               公开分享页数据
POST   /api/auth/register               注册
POST   /api/auth/login                  登录

数据模型：Project、CreativeBrief、CreativeDirection、GeneratedAsset、ShareLink、User。所有模型在 Flask 后端用 SQLAlchemy 定义，SQLite 持久化。

四端的 View Model 都从这套接口映射，不自己造数据。这样改后端，四端自动跟进。

四、Flask 后端的关键设计¶

JWT 鉴权¶

注册/登录返回 JWT，有效期 7 天。所有 /api/projects/* 接口要求 Bearer Token，/api/share/<token> 是公开接口不要 JWT。

创意引擎占位¶

真实的创意引擎要调 Anthropic API + Replicate，成本高且需要密钥。Flask 后端做了占位实现：返回 mock 的方向、评分、资产，保证四端联调时不依赖外部服务。上线时切真实实现即可。

SQLite 初始化¶

flask-backend/init_db.py 创建所有表 + 种子数据（一个示例项目 + Brief + 方向 + 资产）。第一次跑 python app.py 前先跑 python init_db.py，开箱即用。

错误处理统一¶

所有接口返回 {code, message, data} 结构，code=0 成功，非 0 失败。四端封装统一的请求拦截器，token 过期自动跳登录。

五、四端的差异化实现¶

Web（Element Plus）¶

路由：Vue Router，/projects、/projects/:id、/projects/:id/brief、/projects/:id/generate、/projects/:id/preview
表单：Brief 编辑用 ElForm + 校验规则
列表：ElTable + 分页
资产预览：ElTabs 按类型分页 + ElImage 大图

H5（Vant）¶

路由：Vue Router，底部 TabBar（首页/项目/我的）
列表：VanList 下拉刷新 + 上拉加载
表单：VanForm + 移动端键盘适配
资产预览：VanImagePreview + VanAudio/VanVideo

小程序（uni-app）¶

页面：pages 目录，pages.json 注册路由
分享：onShareAppMessage 转发，onShareTimeline 朋友圈
订阅：requestSubscribeMessage，创意引擎完成后推送
登录：wx.login + code2session，JWT 换 token

Flutter App¶

5 个 Screen：Home、ProjectList、ProjectDetail、Brief、Generate
状态管理：Provider
网络：dio + 拦截器
持久化：SharedPreferences 存 JWT
安卓 APK：flutter build apk --debug

六、踩过的坑¶

1. SQLite 并发¶

WAL 模式下读写不互斥，但写入还是串行。高并发写入会锁表，解法是加连接池 + 重试。原型阶段够用，规模化必须迁移。

2. uni-app 多端差异¶

uni-app 说是"一套代码多端"，但微信小程序的 API 和 H5 不完全一致。我们的策略是：重点投微信小程序，H5 顺带支持，App 端不做。 不要追求真多端，那会让你每个端都做不好。

3. Flutter 网络层¶

dio 拦截器里加 JWT 容易踩坑——401 时不要无限重试，最多重试一次。我们封装了 AuthInterceptor，401 自动跳登录页。

4. 跨域¶

Flask 后端 flask-cors 配置 * 即可，但生产环境要限定具体域名。四端分别配置白名单。

七、部署架构¶

原型阶段：单机部署。

Flask 后端跑在 5000 端口，gunicorn + 4 worker。
Web/H5 构建后扔 nginx 静态托管。
小程序走微信平台审核。
Flutter APK 直接下载安装。

规模化后：Flask 后端拆微服务（创意引擎独立、资产生成独立），数据库迁 Postgres，资产上 OSS + CDN，加 Redis 缓存 + 任务队列（Celery）做异步生成。

八、结语¶

四端 + Flask 后端听起来很重，但原型阶段其实就是 5 个目录、5 个 bun install、5 个 build。关键是数据契约统一，前端各端复用同一套 API，后端不用为每端单独写逻辑。

技术选型没有银弹，只有合适。Creativor 的选型原则是：原型阶段求快、求省、求好维护，等 PMF 跑通再优化架构。 不要过早优化，也不要欠技术债到还不起。这个度，是工程的艺术。

Creativor —— 一套数据契约，四端各取所需。