换季的时候翻衣柜翻到崩溃，明明满柜子衣服却总觉得自己没衣服穿，这大概是很多人都有过的体验。我动手做了一个基于 Vue 3 和 Python Flask 的个人穿衣搭配分享网上衣橱系统，把真实衣柜搬到线上，给每件衣物打上标签，记录搭配方案，还能在社区里分享穿搭灵感。如果你正打算练手前后端分离项目，或者对衣橱管理、穿搭推荐这类工具感兴趣，这篇文章会把整个系统的设计与实现思路、关键代码、踩坑记录全部拆开讲清楚。
这个系统本质上是一个“数字衣柜”：注册登录之后，把自己常穿的衣服拍照上传，按品类、颜色、季节、场景分类管理；新建搭配时，从衣橱里挑选单品组成一套 Look，系统会根据标签和色系给出推荐；搭配方案可以公开到分享广场，其他用户能浏览、点赞。核心价值是把“穿什么”这个模糊问题，转化成结构化数据，让系统能帮你做决策。
1. 项目需求拆解：把“穿衣搭配”翻译成系统功能
动手写代码之前，先把需求想透。很多人做项目容易一上来就怼功能，结果做到一半发现逻辑矛盾重重。我习惯先用用户故事把一句话需求扩展成具体动作。
1.1 用户故事出发的需求清单
最初的需求描述是“个人穿衣搭配分享网上衣橱”，拆成一个个具体场景：
- 作为一个用户，我希望能录入衣物信息（照片、名称、品类、颜色），这样我不翻实体衣柜就能看到全部衣服。
- 作为一个用户，我希望能按季节、场景筛选衣物，这样换季的时候能快速定位可以穿的单品。
- 作为一个用户，我希望能草拟一套搭配（上装+下装+外套+鞋），系统给出建议，这样出门前不用纠结。
- 作为一个用户，我希望能查看别人公开的搭配方案，并给自己喜欢的方案点赞，这样能找到穿衣灵感。
- 作为一个用户，我希望我的衣柜和搭配方案是私有的，别人不能直接看到，这样隐私有保障。
这些故事汇总成五个核心模块：用户认证、衣物管理、搭配管理、社区广场、点赞互动。MVP 版本砍掉了一些锦上添花的功能，比如关注关系、私信、评论——不是说这些不好，而是第一版先保证核心链路跑通，后续迭代再加。
1.2 功能模块与系统边界
系统分前端和后端两条线。前端负责页面渲染和交互，后端负责数据处理和业务逻辑。整体模块划分如下：
- 用户模块：注册、登录、个人信息修改、Token 鉴权。
- 衣物管理：上传图片、填写标签、编辑、删除、列表查询、分类筛选。
- 搭配管理：创建搭配（引用多件衣物）、编辑搭配、删除搭配、查看搭配详情。
- 社区分享：搭配的公开/私有开关、广场信息流、按点赞数或时间排序。
- 点赞互动：点赞/取消点赞、点赞数量统计。
明确系统边界同样重要。这个版本不做衣物识别（拍照自动识别品类和颜色）、不做搭配评分算法（基于规则的评分可以，深度学习模型先放一边）、不做好友关系。设计系统时，边界就是这版的地基，守住 MVP 范围，项目才有机会交付。
2. 技术选型：为什么是 Vue + Flask 这套组合
技术选型决定了开发体验和后期维护成本。我当时的备选方案有 Flask + Vue、Django + Django Template、Spring Boot + Vue。最后选了 Flask + Vue 前后端分离，理由很现实。
2.1 后端：Flask 的轻量优势
Python Flask 对个人项目和中小型系统非常友好。它是一个微框架，起步成本极低，一个文件就能跑起接口，但项目变大又可以通过蓝图（Blueprint）做模块化。相比之下，Django 虽然自带 Admin 后台、ORM、认证体系，功能全但对个人项目来说有点重，很多东西用不上还得想办法关掉。
Flask 的生态也够用。数据库 ORM 用 SQLAlchemy，密码加密用 Werkzeug 自带的加密函数，JWT 鉴权用 PyJWT，文件上传处理配合 Pillow 做图片压缩。这些库我都很熟，出了问题能快速定位。个人项目最重要的是“自己掌控”，框架越轻，掌控感越强。
2.2 前端：Vue 组件化开发体验
前端选 Vue，核心原因是组件化开发方式很契合这个项目。衣柜里的衣物卡片、搭配详情卡片、筛选栏，都可以抽成独立组件，哪里需要哪里引用。Vue 的响应式数据流让衣物列表的筛选、排序逻辑非常直观——数据变了，视图自动更新，省去大量手动操作 DOM 的代码。
Vue 3 的 Composition API 这几年已经非常成熟，配合<script setup>语法，代码量比 Options API 减少不少，逻辑复用也更灵活。构建工具直接用官方脚手架 Vite，冷启动和热更新快到离谱，开发体验比 Webpack 时代舒服太多。
组件库我选了 Element Plus，它组件全、文档好、社区活跃。衣物表单、日期选择、弹窗、消息提示这些高频组件都有现成的，不用自己从头造轮子。实际开发中确实省了很多时间，尤其表格和各种表单控件，Element Plus 的封装质量很高。
2.3 前后端分离架构与目录结构
前后端分离带来的最大好处是职责清晰：后端只管数据接口，前端只管页面交互。开发期可以并行——我先把 Flask 接口写好，用 Postman 或 Apifox 自测，同时前端先用 Mock 数据开发页面，联调时再替换成真实接口。
目录结构上，前端和后端分了两个文件夹，方便分别管理依赖。后端根目录是flask-server，结构大概是：
flask-server/ ├── app.py # 应用入口，注册蓝图和扩展 ├── config.py # 配置文件（开发/生产分离） ├── requirements.txt # 依赖清单 ├── models/ # 数据库模型 │ ├── __init__.py │ ├── user.py │ ├── clothing.py │ └── outfit.py ├── api/ # 蓝图路由 │ ├── __init__.py │ ├── auth.py │ ├── closet.py │ ├── outfits.py │ └── community.py └── utils/ # 工具函数（JWT、文件上传、响应格式） ├── auth_token.py ├── upload.py └── response.py前端的结构是标准 Vue 项目，按功能划分目录：views放页面级组件，components放可复用组件，api放接口请求模块，store放 Vuex/Pinia 状态管理。
3. 数据库设计：衣橱的数据模型不是简单存图
衣柜系统的核心是数据结构。衣物、搭配、用户这三张表的关系设计直接决定接口能不能写得顺，所以我把数据库设计放在最前面思考。
3.1 核心表结构设计
用户表比较简单，核心字段是用户名、密码哈希、昵称、头像、创建时间。衣物表是这个系统的主角，字段需要覆盖管理一件衣服所需的全部信息：
clothing - id: 主键 - user_id: 外键，关联用户 - name: 衣物名称 - category: 品类（上衣/下装/外套/鞋履/配饰） - color: 主色（红/橙/黄/绿/蓝/紫/黑/白/灰/棕） - season: 适用季节（春/夏/秋/冬/四季） - scene: 适用场景（休闲/通勤/运动/约会/旅行） - image_url: 图片路径 - created_at: 创建时间搭配表的核心是描述一套完整 Look：
outfit - id: 主键 - user_id: 外键 - name: 搭配名称 - description: 搭配说明 - is_public: 是否公开 - like_count: 点赞数 - cover_image: 封面图（从组合衣物中选一张或单独传） - created_at: 创建时间 outfit_item - id: 主键 - outfit_id: 外键 - clothing_id: 外键 - position: 排序字段（上装/下装/外套/鞋的顺序）outfit_item这种中间表就是搭配和衣物的多对多关系，一套搭配里可能有多件上衣、多件配饰，直接用中间表关联加一个排序字段，灵活度最大。
3.2 表关系设计与索引优化
关系上，用户和衣物是一对多，用户和搭配是一对多，搭配和衣物是多对多。外键约束在数据库层面建好，ORM 层面也要建立对应的relationship，方便反向查询。
索引策略是：clothing表给user_id加索引，查询某用户的衣物列表时避免全表扫描；outfit表给user_id和is_public联合索引，因为社区广场要高频查询is_public=True的搭配，并且按created_at排序。like_count字段不需要单独加索引，排序可以交给内存或前端分页实现，个人项目的数据量完全扛得住。
3.3 标签体系：让衣物可以“被计算”
标签体系是整个系统的灵魂，也是“穿衣搭配”从主观判断变成可计算逻辑的关键。我在设计时给衣物打了几组维度标签：品类、颜色、季节、场景。这些标签不光是筛选条件，也是搭配推荐算法的基础。
比如一件白色衬衫，标签是category=上衣、color=白、season=四季、scene=通勤。另一件深蓝色牛仔裤是category=下装、color=蓝、season=四季、scene=通勤。系统在推荐搭配时，会优先匹配场景一致的单品，然后做色彩协调性检查（基础色与亮色、相邻色系、同色系），再补足品类完整性（上装+下装+鞋子才是一套完整搭配）。
标签值用字符串枚举存，简单直接。如果未来要做筛选，可以加一个tagsJSON 字段做扩展属性，比如“风格：日系/韩系/欧美”，这个字段对查询的影响不大，对推荐逻辑的扩展性很好。
4. 后端实现：Flask 接口从零到一
后端部分是整个系统的引擎，我按模块化思路组织代码。从环境准备到 JWT 鉴权，再到核心 CRUD 和推荐逻辑，一步步说。
4.1 项目初始化与环境准备
先建虚拟环境，这是 Python 项目的基本操作，避免依赖污染全局环境：
cd flask-server python -m venv venv source venv/bin/activate # Windows 用 venv\Scripts\activate然后安装依赖，写进requirements.txt：
flask==3.0.3 flask-sqlalchemy==3.1.1 flask-cors==4.0.1 pyjwt==2.9.0 werkzeug==3.0.3 pillow==10.4.0数据库选 SQLite 做开发环境，零配置，直接依赖 SQLAlchemy 的抽象层。如果想切 MySQL 或 PostgreSQL，改一行数据库连接字符串就行，ORM 层大部分代码不用动。
应用入口app.py负责创建应用、注册所有蓝图、初始化扩展：
from flask import Flask from flask_cors import CORS from flask_sqlalchemy import SQLAlchemy db = SQLAlchemy() def create_app(): app = Flask(__name__) app.config.from_object("config.DevelopmentConfig") db.init_app(app) CORS(app, resources={r"/api/*": {"origins": "*"}}) from api.auth import auth_bp from api.closet import closet_bp from api.outfits import outfits_bp from api.community import community_bp app.register_blueprint(auth_bp, url_prefix="/api/auth") app.register_blueprint(closet_bp, url_prefix="/api/closet") app.register_blueprint(outfits_bp, url_prefix="/api/outfits") app.register_blueprint(community_bp, url_prefix="/api/community") return app4.2 注册登录与 JWT 鉴权实现
用户系统我用 JWT（JSON Web Token）做无状态鉴权。流程是：用户注册时服务端把密码做哈希存储，登录时校验密码，校验通过后签发一个带过期时间的 Token，前端保存这个 Token，后续请求在请求头带上它。
密码哈希直接使用 Werkzeug 自带的加密函数，比明文存储安全得多：
from werkzeug.security import generate_password_hash, check_password_hash password_hash = generate_password_hash(password) # 登录时校验 is_valid = check_password_hash(user.password_hash, password)JWT 生成和验证写在工具模块里：
import jwt from datetime import datetime, timedelta from flask import current_app def generate_token(user_id): payload = { "user_id": user_id, "exp": datetime.utcnow() + timedelta(days=7) } token = jwt.encode(payload, current_app.config["SECRET_KEY"], algorithm="HS256") return token def verify_token(token): try: payload = jwt.decode(token, current_app.config["SECRET_KEY"], algorithms=["HS256"]) return payload["user_id"] except jwt.ExpiredSignatureError: return None except jwt.InvalidTokenError: return None有了这个工具，装饰器login_required就能统一保护需要登录的接口：
from functools import wraps from flask import request, jsonify def login_required(f): @wraps(f) def wrapper(*args, **kwargs): token = request.headers.get("Authorization", "") if token.startswith("Bearer "): token = token[7:] user_id = verify_token(token) if user_id is None: return jsonify({"code": 401, "message": "登录状态已过期，请重新登录"}), 401 request.user_id = user_id return f(*args, **kwargs) return wrapper实测下来，JWT 这种方案非常适合前后端分离项目。服务端不用存 Session，扩展性好，前端拿到 Token 后可以放 localStorage 或 Pinia 中统一管理。
4.3 衣物与搭配管理的 CRUD 接口
衣物接口基于蓝图closet_bp实现。核心就是增删改查，但有几个细节值得展开。
新增衣物接口里，图片上传是重点。前端传文件到后端，后端先把图片压缩保存到服务器，再把图片的 URL 存进数据库。图片处理代码：
from PIL import Image import os, uuid def save_uploaded_image(file): # 限制扩展名 allowed_ext = {"jpg", "jpeg", "png", "webp"} ext = file.filename.rsplit(".", 1)[-1].lower() if ext not in allowed_ext: raise ValueError("不支持的图片格式") # 生成唯一文件名 filename = f"{uuid.uuid4().hex}.{ext}" save_path = os.path.join(current_app.config["UPLOAD_DIR"], filename) # 用 Pillow 压缩图片，限制最长边为 1200px image = Image.open(file.stream) if image.width > 1200 or image.height > 1200: image.thumbnail((1200, 1200)) image.save(save_path, quality=85, optimize=True) return f"/static/uploads/{filename}"注意这里的几个坑：Image.open(file.stream)时 Pillow 会保留文件的原始方向信息，如果手机拍的照片是竖拍的，上传后可能显示成横的。解决方法是读取 EXIF 信息做旋转处理。另一个坑是必须限制扩展名和文件大小，防止用户上传超大的原图拖垮服务器性能。
搭配管理的接口稍微复杂一点，因为涉及中间表outfit_item。创建搭配时，前端传来的是clothing_ids数组和服务端的衣物数据。服务端要做的是校验这些衣物是否属于当前用户，然后创建outfit记录和多个outfit_item记录。锁定用户数据的归属校验是个容易漏掉的安全点——所有涉及用户数据的接口，都必须校验资源归属于当前 Token 对应的用户。
4.4 社区分享流与推荐接口
社区广场接口比较简单，核心是is_public=True的搭配列表，按时间倒序或按点赞数倒序。关键优化点是用 SQLAlchemy 的joinedload预加载关联数据，避免一次性查询大量搭配时触发 N+1 问题：
from sqlalchemy.orm import joinedload outfits = Outfit.query.options( joinedload(Outfit.user), joinedload(Outfit.items).joinedload(OutfitItem.clothing) ).filter_by(is_public=True).order_by(Outfit.created_at.desc()).all()推荐接口是“搭配推荐”的核心逻辑。我实现了一个基于标签匹配和色彩规则的推荐算法：
- 根据当前季节（服务端取当前月份映射）筛选出应季衣物。
- 根据用户选择的场景（通勤/休闲/运动等）过滤衣物。
- 品类完整性检查：优先推荐“上装+下装+鞋履”的完整组合。
- 色彩协调规则：黑白灰基础色百搭，同色系（深浅，必选慎用）的搭配安全，对比色（红绿、蓝橙）有视觉冲击但需要控制比例。
这个算法不需要机器学习模型，本质上是规则引擎。真实穿搭逻辑本身就有大量经验法则，规则型推荐在小数据量的场景下反而更可控、更好解释。我在代码里把推荐逻辑单独抽了一个函数，方便以后替换成更复杂的模型。
5. 前端实现：从页面到交互的细节
前端部分直接决定用户愿不愿意用这个系统。页面做得顺手、操作流畅，用户才会持续录入衣物。我把前端拆成几个关键环节详细说。
5.1 项目初始化与路由设计
前端用 Vite 初始化 Vue 3 项目：
npm create vite@latest frontend -- --template vue cd frontend npm install vue-router@4 pinia axios element-plus路由设计决定了页面结构。我的路由分两层，核心页面有：
/login登录页/register注册页/closet衣橱主页（衣物卡片列表）/closet/upload上传衣物页（或弹窗）/outfit/create创建搭配页/outfit/:id搭配详情页/community社区广场/profile个人中心
路由懒加载用 Vue Router 的动态 import，首屏不加载全部页面代码，提升加载速度：
const routes = [ { path: "/", redirect: "/closet" }, { path: "/login", component: () => import("@/views/LoginView.vue") }, { path: "/closet", component: () => import("@/views/ClosetView.vue"), meta: { requiresAuth: true } }, // ... ];路由守卫处理登录态——如果没有 Token 且访问了需要登录的页面，直接跳转登录页：
router.beforeEach((to) => { const token = localStorage.getItem("token"); if (to.meta.requiresAuth && !token) { return { path: "/login", query: { redirect: to.fullPath } }; } });5.2 组件拆分与状态管理
衣橱页是所有页面里组件复用最多的。我把每个衣物卡片抽成ClothingCard组件，卡片显示图片、名称、品类标签和颜色标签；筛选栏抽成FilterBar组件，内部管理品类、季节、场景的筛选状态；上传弹窗抽成UploadClothingDialog组件，内部封装上传表单和图片预览逻辑。
创建搭配页是整个前端最复杂的部分。页面左侧是“可选的衣物列表”，右侧是“搭配方案预览区”。用户点击某件衣物，它就加入搭配区，同时左侧列表自动过滤掉已选的。搭配区内部支持拖拽排序，设置每件衣服的展示顺序，整套 Look 的最终效果一目了然。
状态管理用 Pinia，它要比 Vuex 更轻量、更符合 Vue 3 的开发习惯。我用它管理 token、用户信息、衣橱衣物列表。衣橱列表在 Pinia 里维护一份，因为筛选、排序、上传后刷新、删除后移除都要改这个数据，把它变成全局状态可以减少组件之间的数据通信复杂度。
5.3 API 封装与请求拦截器
Axios 封装是每个前后端分离项目必做的基础设施。我在api/request.js里创建了一个实例，统一设置接口地址前缀、超时时间，并在请求拦截器里自动加 Token：
import axios from "axios"; import { ElMessage } from "element-plus"; import router from "@/router"; const request = axios.create({ baseURL: "/api", // 开发环境走 Vite 代理 timeout: 15000, }); request.interceptors.request.use((config) => { const token = localStorage.getItem("token"); if (token) { config.headers.Authorization = `Bearer ${token}`; } return config; }); request.interceptors.response.use( (response) => response.data, (error) => { if (error.response?.status === 401) { localStorage.removeItem("token"); router.push({ path: "/login" }); } ElMessage.error(error.response?.data?.message || "请求失败，请稍后重试"); return Promise.reject(error); } ); export default request;这个拦截器解决了两个大问题：所有请求自动带鉴权头，不用每个接口重复写；统一处理 401 过期场景，Token 失效时自动踢回登录页，用户已无需手动清缓存。
5.4 移动端适配与体验细节
网上衣橱的典型使用场景是“出门前看一眼搭配合不合适”，所以移动端适配必须做好。我的方案是整体按响应式设计做：容器宽度用百分比 + 最大宽度限制，图片用aspect-ratio固定比例避免布局抖动，字体用相对单位。Element Plus 组件本身是响应式的，栅格布局在手机上自动变成单列。
图片加载性能是另一个体验重点。在社区广场这种大量图片的页面上，用v-lazy指令做懒加载——滚动到视口附近才发起图片请求。搭配详情页的图片用fetchpriority="high"提示浏览器优先加载首屏大图。
6. 真实开发遇到的坑与排查记录
这个项目从 0 到 1 跑起来的过程中，我踩了不少坑，很多问题网上搜不到直接答案，只能一点点排查。这些经验写出来，希望能帮你少走弯路。
6.1 跨域请求问题
第一次前后端联调就遇上跨域。前端跑在localhost:5173，后端跑在localhost:5000，端口不同，浏览器默认拦截跨域请求。
解决方案是后端启用 Flask-CORS 并配置允许的来源：
from flask_cors import CORS CORS(app, resources={r"/api/*": {"origins": ["http://localhost:5173"]}})但这里有个隐蔽的坑：如果你配置了origins=*，并且请求头里带Authorization，浏览器会先发一个 OPTIONS 预检请求。Flask-CORS 必须保证 OPTIONS 请求也返回正确的 CORS 头，否则会看到“预检请求失败”的报错。好用起见，直接把resources配置成所有非简单请求也允许Authorization和Content-Type头。
实际排查时用浏览器开发者工具看 Network 里的响应头，如果发现响应里没有Access-Control-Allow-Origin，基本可以确定是 CORS 配置的问题。这时先 curl 一下后端接口（不带浏览器），确认后端本身正常，再回头查 CORS。
6.2 图片上传的内存与体积问题
项目做了一段时间后，用户上传的照片越来越大，手机上随便一拍就是 5MB 以上的原图。如果不对图片做压缩，服务器磁盘很快爆掉，前端加载也卡成幻灯片。
我用 Pillow 做压缩时最初只缩了尺寸，忘了处理 EXIF 方向信息。iPhone 竖拍的照片在浏览器里显示成横着的，排查了半天才发现是 Pillow 在缩略图模式下不自动读 EXIF。修正方法是用ImageOps.exif_transpose先旋转图像再保存：
from PIL import ImageOps image = ImageOps.exif_transpose(image) image.thumbnail((1200, 1200))还有文件体积控制。我用quality=85, optimize=True保存 JPEG，同样尺寸的图片通常能从 4MB 压到 500KB 以内，视觉几乎没区别。对 PNG 则转成 JPEG 输出，除非原图有透明通道。
6.3 Token 过期与登录态保持
JWT 设计成无状态后有一个体验问题：Token 过期前用户完全无感知，过期后第一个请求会返回 401，用户被强制弹出登录页。如果用户的 Token 是 7 天有效期，那 7 天后第一次打开页面就得重新登录，很影响体验。
我采用的方案是双 Token 机制，其实不算复杂：短期 Access Token（2 小时）和长期 Refresh Token（7 天）。前端请求拿 Access Token 带在请求头上，401 时自动用 Refresh Token 换新的 Access Token，用户全程无感。如果 Refresh Token 也过期了，再跳登录页。
这个方案实测稳定，但要注意后端换 Token 的接口必须做安全校验，防止 Refresh Token 被恶意使用。安全起见，换 Token 时判断用户账号状态是否正常。
6.4 查询变慢与 N+1 问题
社区广场的搭配列表在数据量到 100 条左右时，接口响应时间突然从 50ms 涨到 400ms。排查后发现是典型的 N+1 查询问题：先查 100 条搭配，然后每取一条搭配都单独查询它的关联衣物和用户，等于发了 201 条 SQL 语句。
修复方案是 SQLAlchemy 的joinedload预加载：
from sqlalchemy.orm import joinedload stmt = ( db.select(Outfit) .options( joinedload(Outfit.user), joinedload(Outfit.items).joinedload(OutfitItem.clothing) ) .where(Outfit.is_public == True) .order_by(Outfit.created_at.desc()) )通话加预测，响应时间恢复到 60ms 左右。这个坑在数据量小时完全不会暴露，但一旦数据多起来就会突然卡死，所以建议一开始写 ORM 查询时就习惯性地加上joinedload，别等卡了再回头补。
7. 构建与部署中的实操笔记
开发完不等于项目结束，部署上线才算真正完成。这节内容比较零散，但每一条都是我实操后的真实记录。
7.1 构建 Vue 产物与 Flask 静态托管方案
前端构建命令npm run build会生成一个dist目录，里面的静态文件（HTML、CSS、JS）需要被服务器托管。有两种做法：
方案一是独立部署：前端dist目录交给 Nginx 托管，/api路径反向代理到 Flask 服务。这是前后端分离的标准玩法，适合线上环境，我用的也是这种。
方案二是让 Flask 直接托管前端静态文件：把所有前端产物复制到 Flask 项目的static目录下。配置一个兜底路由，让所有非/api的请求返回index.html，这样 Vue Router 的 history 模式才能正常工作：
@app.route("/", defaults={"path": ""}) @app.route("/<path:path>") def catch_all(path): return send_from_directory("static", "index.html")开发环境我用 Vite 的代理配置解决跨域，生产环境则用 Nginx 的proxy_pass。具体 Nginx 配置因环境而异，但核心是一句话：/api代理到 Flask，其余文件指向前端静态目录。
7.2 环境变量与配置管理
个人项目里最容易被忽略的就是配置管理。我把开发环境和生产环境的配置分开，用一个config.py维护：
class Config: SQLALCHEMY_TRACK_MODIFICATIONS = False SECRET_KEY = os.getenv("SECRET_KEY", "dev-secret") class DevelopmentConfig(Config): DEBUG = True SQLALCHEMY_DATABASE_URI = "sqlite:///dev.db" class ProductionConfig(Config): DEBUG = False SQLALCHEMY_DATABASE_URI = os.getenv("DATABASE_URL", "mysql+pymysql://xxx:xxx@localhost/closet_db")Secret Key、数据库连接字符串这类敏感信息从环境变量读取，不要硬编码在代码里。尤其是 SECRET_KEY，如果泄露，攻击者可以伪造任意用户的 JWT Token，风险非常高。
7.3 数据备份与迁移
SQLite 开发方便，但放到线上我换成了 MySQL。切换方式很简单，改一下SQLALCHEMY_DATABASE_URI配置串，ORM 层代码完全不用动。迁移时先用 SQLAlchemy 的create_all()创建表结构，再写脚本把 SQLite 数据导出成 JSON，导入到 MySQL。
备份策略上，我会在服务器上写一个 crontab 定时任务每天把数据库 dump 到备份目录，再用对象存储同步到远程。自己用的小系统，备份频率不需要太高，但每日一备是底线。
8. 衣橱系统的扩展方向：从可用到好用
核心系统和社区功能做完之后，我发现这套架构的扩展空间非常大，很多想法可以随需加入。
第一个方向是智能穿搭推荐升级。现有的规则引擎已经很实用，但可以引入更丰富的数据源，比如天气数据（实时温度、湿度、降雨概率）、用户偏好反馈（穿上某套搭配后标记“喜欢/不喜欢”），甚至接入公开的色彩学知识库。用协同过滤算法给相似的搭配打分，个人衣橱的推荐能做得更精致。
第二个方向是数据可视化分析。衣橱数据积累到一定量时，可以统计品类分布、颜色偏好、季节利用率，生成“本季最常穿的单品”或者“购买频率最高的品类”这类报告。前端用 ECharts 画几张图，整个项目的调性立刻不一样。
第三个方向是社交属性增强。搭配分享广场目前只有点赞，后续可以加关注好友、评论交流、话题标签（#通勤穿搭、#郊游穿搭），让社区活跃起来。还可以增加一键保存他人搭配到自己的“灵感收藏夹”，方便日后参考。
第四个方向是 AI 图像识别。如果以后想省去手动打标签的功夫，可以用图像分类模型直接识别衣物品类和颜色。这个方向对服务器资源要求高，但对用户价值非常直接——上传一张照片，系统自动填好大半标签。
这几个方向都基于现有系统往前延伸，不会破坏已经跑通的框架。作为个人项目，最大的优势就是可以按自己的兴趣和精力逐步迭代。我最初做这个系统是为了解决衣柜混乱的问题，做到现在，反而变成了一个能持续学习和实验的技术沙盒。
