企业官网建设流程全解析

做一个“山区儿童衣物捐赠网”，技术栈选了Python后端加Vue前端——这是很多人在课设、毕设或者练手项目里会碰到的选题。这个题目听起来不难，无非是“登记衣物、发布需求、管理员审核”，但真正动手之后你会发现，它其实牵扯到用户权限、状态流转、文件上传、前后端联调一大堆问题。我当初做这个项目的时候，在答辩现场被老师问了一句：“你这个捐赠平台和闲鱼卖二手衣服的差别在哪？”当时我一愣，后来想明白了一个道理：公益类项目真正难的不是CRUD，而是“捐赠-匹配-反馈”这一整条链路的逻辑闭环。

这篇文章就把我完整做过的一个“Python + Vue山区儿童衣物捐赠网”拆开讲清楚。不管你是准备做课设，还是想找一份能写在简历上的全栈练手项目，只要跟着这个思路走，至少能省下两周的弯路。我会从需求拆解、技术选型、数据库设计、后端API、前端Vue实现一直讲到联调排错，所有代码级别的东西都会给你一个可直接落地的方案。

1. 项目全景：山区儿童衣物捐赠平台到底要做什么

1.1 从需求到功能：这个平台不是简单的物品管理

我在设计第一版数据库表的时候只做了“用户表、衣物表、订单表”三张表，结果做到一半就发现撑不住。原因很简单：捐赠平台和电商平台的核心差异在于“多方参与”和“物品状态的多阶段流转”。

电商是一对一的买和卖，捐赠平台却是三个角色的协同——捐赠者要登记和寄出衣物，平台管理者要审核、匹配、记录物流，受助方（比如山区学校或儿童福利机构）要提交需求、接收物资、反馈结果。这三个角色缺一个，流程就残缺了。

所以完整的功能至少需要这几块：

• 捐赠端：注册登录、发布衣物捐赠信息（照片、种类、尺码、数量等）、查看捐赠状态（待审核、已匹配、已寄出、已抵达）、撤销未审核的捐赠。
• 管理端：衣物类目管理、捐赠信息审核、捐赠与需求的智能匹配推荐、物流信息登记、受助机构管理和审核、平台数据统计看板。
• 受助端：提交需求（按季节、年龄段、衣物种类提交）、浏览待匹配捐赠、确认收货、发布感谢反馈或图片。

我当时画完这个功能全景图的时候才发现，这已经不是一个“学生练手项目”了，而是一个真正意义上的多角色业务系统。好在，正因为它是公益项目，流程和规则可以简化而不失合理性——你不用做支付、退款、售后、优惠券这些电商才有的复杂逻辑，但你要把“审核与状态流转”这条主线做得清清楚楚。

1.2 核心业务链路与角色权限边界

这一节是整个项目最值得花时间的地方，因为几乎所有后期系统的复杂度都是从这里长出来的。我把它分为三条业务链路：

1. 需求侧链路：受助机构注册 → 平台管理员审核机构资质 → 机构提交衣物需求单 → 管理员审核需求单 → 需求单发布为“待匹配”状态。
2. 供给侧链路：捐赠者登记衣物 → 管理员审核衣物信息 → 衣物进入“可匹配”池 → 系统按规则匹配需求 → 匹配成功后进入物流环节。
3. 物流与反馈链路：管理员登记寄出信息和物流单号 → 机构确认签收 → 平台标记捐赠完成 → 机构上传反馈照片和感谢信 → 捐赠者看到最终去向。

这三条链路同时运行，需要靠一个关键机制串起来，就是**“每一件衣物在同一时刻只有一个状态”**。用户的每一个动作都对应一次状态变更，而状态变更必须记录它发生的时间点和操作者，这就是审计需求。

权限边界我也一并在这里定义了：

权限控制不用做得很重，但至少要用装饰器或中间件把接口的“角色身份校验”做完整。这部分如果你用Flask，我会在后面给出一个基于JWT的装饰器实现，三分钟就能全部搞定。

2. 技术选型背后的考量：为什么是Vue + Flask + MySQL

2.1 Python后端的框架选择：Flask还是Django？

在最终选定技术栈之前，我给自己列了一张非常实际的对比表。不堆理论，就按这个项目的真实需求来：

因为这个题目里的核心是“亲手做出来”并且“说得清楚”，我最终选择了Flask + SQLAlchemy + MySQL的组合。Flask的灵活性刚好匹配这个项目的体量，SQLAlchemy给你完整的ORM能力，同时学习和讲解成本低不少。如果你要做的版本不是很简单，你也可以选择Flask + FastAPI混合的用法，但没必要。

2.2 Vue版本选择的坑与建议

现在网上关于Vue的教程大部分已经切到Vue 3了，但课设和毕设群体里仍然有大量存量项目是Vue 2。我的建议是：你从零新写一个项目，直接选Vue 3 + Vite + Element Plus；如果你是改别人的老项目，才需要待在Vue 2生态里。

Vue 3相对Vue 2最重要的是Composition API，它把“同一业务逻辑的代码聚合在一起”，在捐赠平台这种“一个页面里涉及审核表单、状态标签、日期选择、图片上传”的模块里，逻辑聚合会明显比Options API好维护。

前端整体选型我做了一个清单：

• 脚手架：Vite（不要用Vue CLI，新的Vite模板更快更清爽）。
• UI组件库：Element Plus（表单、表格、对话框、步骤条都很成熟）。
• HTTP工具：Axios（统一封装请求实例和拦截器）。
• 路由：Vue Router 4（带角色守卫，按路由meta控制访问权限）。
• 状态管理：Pinia（比Vuex少很多样板代码，官网也推荐）。

这套组合你拿到任何一台干净电脑上，npm install之后十分钟内就能跑起来开发环境。

2.3 前后端分离的部署思路

前后端分离是这个项目绕不开的话题。一次性讲清楚：开发环境下，前端跑在Vite默认的5173端口，后端跑在Flask的5000端口，两个端口之间需要解决“跨域”和数据传递格式的问题。我在开发阶段用一个简单方案——后端装上flask-cors，允许开发来源跨域；生产环境则把前端npm run build生成的dist静态文件拷贝到Flask的static目录下，由Flask统一提供访问入口，这样只需要一个8000或者80端口就能跑整个项目。

3. 后端设计与实现：把捐赠业务拆成可落地的API

3.1 数据库设计：五张核心表的关系与字段

明确业务需求后，我才动手设计数据库。核心表一共五张，它覆盖了上面说的全部流程：

1. user表（用户表）：字段包括id、username、password_hash、role（donor/admin/agency）、phone、region、created_at。其中region字段很重要，它是后续做“就近匹配”的基础。
2. clothing表（衣物捐赠信息表）：id、donor_id、category、size、gender、season、quantity、description、photo_url、status、created_at、matched_order_id。status字段要设置枚举值——pending（待审核）、approved（已通过）、matched（已匹配）、shipped（已寄出）、received（已签收）。
3. demand表（需求单表）：id、agency_id、category、size、gender、season、quantity、urgency、status、created_at。status同样维护一套枚举。
4. match_record表（匹配记录表）：id、clothing_id、demand_id、matched_by、matched_at、status。这张表解决的是“多对多匹配的痕迹留存”问题，避免同一件衣服被匹配给两个机构。
5. logistics表（物流信息表）：id、match_record_id、express_name、tracking_no、sender_name、receiver_name、status、timeline_json。

其中有一个容易被忽略的细节：clothing表里的photo_url要用相对路径，不要存完整URL。开发环境下完整URL还能用，但一旦部署到服务器换了域名，所有图片地址都变成死链。相对路径加一个常量前缀（比如/static/uploads/）才能保证拿来即用。

3.2 核心API清单与状态机设计

整个项目我最终梳理出了约27个API，在这里列出最主要的、答辩一定会被问到的几个：

注意我这儿路由设计的原则是：资源路径尽量是名词，动作尽量通过HTTP方法或子路径表达。不要在路径里放动词英文乱飞，例如不要写/api/approve_clothing，用/api/admin/clothing/{id}/approve一眼就能看懂。

状态机是后端设计里的核心，我用一个简单字典就能实现状态迁移校验，避免用户乱序操作请求。核心状态机代码我直接贴出来：

CLOTHING_STATUS_TRANSITIONS = { "pending": ["approved", "rejected"], "approved": ["matched"], "matched": ["shipped", "cancelled"], "shipped": ["received"], "received": [], "rejected": [], "cancelled": [] } def check_transition(current_status, target_status, role): allowed_roles = { ("pending", "approved"): ["admin"], ("pending", "rejected"): ["admin"], ("approved", "matched"): ["admin"], ("matched", "shipped"): ["admin"], ("shipped", "received"): ["agency"] } if target_status not in CLOTHING_STATUS_TRANSITIONS.get(current_status, []): return False, "非法的状态变更" if (current_status, target_status) in allowed_roles and role not in allowed_roles[(current_status, target_status)]: return False, "角色无权限执行此操作" return True, "ok"

这个函数在整个项目里只写了一处，但审核、匹配、物流三个模块全部复用它。你要在答辩时被问到“状态多、容易乱怎么办”，这一段就是最有说服力的回答。

3.3 JWT认证与基于角色的接口保护

在Flask里用JWT做接口保护，关键点不在于签发token，而在于如何在每个受保护的接口里快速拿到当前用户身份和角色。我建议用一个@login_required装饰器，它做完token解析后直接往g对象里写入当前用户信息，这样后续视图函数随时可以从g.current_user取值。

下面是一个可以直接抄走的简化实现：

import jwt from functools import wraps from flask import request, g, current_app, jsonify def login_required(f): @wraps(f) def decorated(*args, **kwargs): token = request.headers.get("Authorization", "") if not token.startswith("Bearer"): return jsonify({"code": 401, "msg": "未登录"}), 401 try: payload = jwt.decode(token.replace("Bearer ", ""), current_app.config["SECRET_KEY"], algorithms=["HS256"]) g.current_user_id = payload["user_id"] g.current_user_role = payload["role"] except jwt.ExpiredSignatureError: return jsonify({"code": 401, "msg": "登录已过期"}), 401 except jwt.InvalidTokenError: return jsonify({"code": 401, "msg": "无效令牌"}), 401 return f(*args, **kwargs) return decorated def admin_required(f): @wraps(f) def decorated(*args, **kwargs): if getattr(g, "current_user_role", None) != "admin": return jsonify({"code": 403, "msg": "无权限访问"}), 403 return f(*args, **kwargs) return decorated

使用时就是标准的双装饰器叠加：

@app.route("/api/admin/clothing/<int:clothing_id>/approve", methods=["PUT"]) @login_required @admin_required def approve_clothing(clothing_id): # 审核逻辑 ...

3.4 文件上传与图片存储的工程化处理

衣物捐赠必然需要传图片，这里是整个项目里最容易出“本地跑得好好的，一部署就挂”的环节。我踩过的具体坑是：默认的Flask上传对文件大小和扩展名的校验不够，且不会自动生成唯一文件名，两个用户上传了同名为1.jpg的图片就互相覆盖了。

我的最终方案分为三步：

• 限制大小和扩展名：上传前在后端校验request.files，图片格式只允许jpg、jpeg、png、webp，单张不超过2MB。
• 重命名文件：用uuid.uuid4().hex生成唯一文件名，保留原扩展名。
• 保存目录动态创建：按日期建子目录，比如uploads/20250607/xxx.jpg，避免单个文件夹文件过多。

核心代码片段：

import uuid import os from datetime import datetime UPLOAD_FOLDER = "static/uploads" ALLOWED_EXTENSIONS = {"jpg", "jpeg", "png", "webp"} def save_upload(file_storage): ext = file_storage.filename.rsplit(".", 1)[-1].lower() if ext not in ALLOWED_EXTENSIONS: raise ValueError("不支持的图片格式") date_str = datetime.now().strftime("%Y%m%d") target_dir = os.path.join(UPLOAD_FOLDER, date_str) os.makedirs(target_dir, exist_ok=True) filename = f"{uuid.uuid4().hex}.{ext}" file_storage.save(os.path.join(target_dir, filename)) return f"/static/uploads/{date_str}/{filename}"

4. 前端Vue实现：页面组织、路由设计与状态管理

4.1 路由表与权限守卫的完整设计

Vue前端部分，我拿到需求后先不急着写页面，而是先设计路由。因为这是一个“三种角色共用同一前端”的系统，路由配置就必须从一开始就考虑到权限分层。

路由设计分成三个层级：

• 公开路由：登录页、注册页、首页捐赠信息展示。不需要token也能访问。
• 用户路由：捐赠记录、新增衣物、消息中心。需要登录。
• 管理路由：审核中心、匹配中心、需求管理、物流登记、统计看板。需要admin角色。

这里直接给出路由核心配置：

const routes = [ { path: "/login", component: () => import("@/views/Login.vue"), meta: { public: true } }, { path: "/register", component: () => import("@/views/Register.vue"), meta: { public: true } }, { path: "/", component: () => import("@/layout/MainLayout.vue"), meta: { requiresAuth: true }, children: [ { path: "home", component: () => import("@/views/Home.vue") }, { path: "clothing/new", component: () => import("@/views/ClothingNew.vue") }, { path: "my/donations", component: () => import("@/views/MyDonations.vue") }, { path: "admin/audit", component: () => import("@/views/admin/AuditClothing.vue"), meta: { role: "admin" } }, { path: "admin/statistics", component: () => import("@/views/admin/Statistics.vue"), meta: { role: "admin" } } ] } ]

守卫逻辑中，meta.role是关键，它在beforeEach里完成角色校验。不使用路由守卫直接放行的错误做法会导致非管理员能通过改地址栏直接进入管理页面，这在答辩演示时是毁灭性的缺陷。

4.2 Axios封装：这三个核心拦截器救了你一半的调试时间

在项目开发中反复遇到的坑是：后端报错不能直接弹出让人能看懂的提示，导致前后端联调效率极低。因此对Axios统一封装时做了三样事情：

• 请求拦截器统一附加JWT token。
• 响应拦截器统一处理应用层状态码，遇到401自动跳登录页。
• 错误提示统一用Message组件弹出，不依赖页面自己去catch。

关键封装代码如下：

import axios from "axios" import { ElMessage } from "element-plus" import router from "@/router" const http = axios.create({ baseURL: "/api", timeout: 15000 }) http.interceptors.request.use(config => { const token = localStorage.getItem("token") if (token) { config.headers.Authorization = `Bearer ${token}` } return config }) http.interceptors.response.use( response => { const res = response.data if (res.code !== 200) { ElMessage.error(res.msg || "请求失败") return Promise.reject(new Error(res.msg)) } return res }, error => { if (error.response && error.response.status === 401) { localStorage.removeItem("token") router.push("/login") } else { ElMessage.error(error.response?.data?.msg || "网络异常") } return Promise.reject(error) } ) export default http

4.3 审核与匹配页面的组件化拆分

审核中心是管理端最核心的页面，如果全部堆在一个.vue文件里，大概会跑到1200行。我按功能拆成了四个组件：

• ClothingCard.vue：单件衣物的卡片，显示图片、类目、尺码、捐赠人、状态标签，底部根据状态渲染操作按钮。
• AuditDialog.vue：审核弹窗，复用给“通过”和“驳回”两种操作，传入不同props控制标题和确认文案。
• FilterBar.vue：筛选栏，按类目、状态、时间范围筛选。
• MatchPanel.vue：匹配面板，左侧选待匹配衣物，右侧选未完成需求单，中间按钮发起匹配。

组件拆分的好处除了代码变清晰之外，还有一个实际价值：列表加载和弹窗提交互不干扰，子组件用emit通知父组件刷新列表，不需要也不应该让父子组件状态搅在一起。这也是Vue 3正确写组件通信的姿势。

核心里面一个值得注意的组件代码是匹配面板，它会调用后端匹配接口并接收匹配结果，如果成功就把匹配记录追加到表格中并移除当前衣物卡片：

<template> <el-card shadow="never"> <el-row :gutter="12"> <el-col :span="8"> <h4>待匹配衣物</h4> <div v-for="item in clothingList" :key="item.id" @click="selectedClothing = item"> <ClothingCard :data="item" :selected="selectedClothing?.id === item.id" /> </div> </el-col> <el-col :span="8"> <h4>未完成需求单</h4> <div v-for="item in demandList" :key="item.id" @click="selectedDemand = item"> <DemandCard :data="item" :selected="selectedDemand?.id === item.id" /> </div> </el-col> <el-col :span="8"> <h4>匹配动作</h4> <p>衣物：{{ selectedClothing?.name || "未选择" }}</p> <p>需求：{{ selectedDemand?.title || "未选择" }}</p> <el-button type="primary" :disabled="!selectedClothing || !selectedDemand" @click="doMatch"> 发起匹配 </el-button> </el-col> </el-row> </el-card> </template>

前端实际代码不止播报这一部分，但这个模式已经足够说明问题：把数据选择和数据操作分离，页面状态一目了然，AI答辩时老师点开你的组件结构也能直接看见工程化能力。

5. 全栈联调与部署：我在实际运行中踩过的坑和排查链路

5.1 跨域配置：不只是加一个CORS头那么简单

前后端分离开发时，前端跑在localhost:5173，后端跑在localhost:5000，你如果直接向后端发请求，浏览器会拦截。最粗暴的做法是后端开启flask-cors，允许所有来源——开发环境这么干没错，但生产环境也这么写就非常不安全。

我建议的完整做法是：开发环境用Vite代理解决跨域，不直接走CORS。在项目根目录vite.config.js里配置：

export default defineConfig({ server: { proxy: { "/api": { target: "http://localhost:5000", changeOrigin: true } } } })

这样前端的/api请求会被Vite开发服务器转发到Flask，前端代码本身永远不感知后端地址。生产环境直接把前端dist目录放进Flask的static，也不存在跨域问题。这个方案简单地说就是：能走代理就别开跨域白名单，能同源就别搞两套域名。

5.2 “图片上传成功但页面不显示”的排查链路

这个问题几乎每个做上传功能的同学都会遇到。我第一次遇到时，图片上传接口返回的URL是http://localhost:5000/static/uploads/20250607/xxx.jpg，浏览器打开也能看到图片，但前端页面就是显示不出来。

后来我按这个链路排查：

1. 先在浏览器Network面板看图片请求的Status，发现是404。
2. 再检查返回的图片URL，发现前缀是http://localhost:5000，而Vite代理只代理了/api，/static路径没有经过代理。
3. 找到根本原因：后端的图片响应路径没走代理通道。解决方法是把图片URL也用相对路径存，也就是/static/uploads/20250607/xxx.jpg，再把Vite代理中给/static也加上转发规则，或者干脆把图片作为/api/static响应。

最终我用的是通过代理转发，同时在Flask中把/static路径的响应头加上缓存，避免同一个图片被反复读取拖慢页面。

5.3 Vue打包后布局异常与路由刷新404问题

这个坑特别经典：npm run build打包出来的dist文件在Flask里跑，页面加载了但样式全部错乱，或者内页刷新直接404。

样式错乱的原因通常是打包后的静态资源路径写死成了根路径/assets/xxx.css，但你项目是部署在子路径下的。解法是在vite.config.js里加一行base: "./"，让所有资源变成相对路径。

刷新404则是因为前端用了history模式路由，Flask后端没有做“兜底重定向”。在Flask中增加这样一段路由：

@app.route("/", defaults={"path": ""}) @app.route("/<path:path>") def catch_all(path): return app.send_static_file("index.html")

这个路由必须放在所有/api/路由之后，否则它会拦截API请求，把JSON也吐成HTML。我在排错时曾亲眼见过一个同学把兜底路由写在最上面，结果整个API全挂了。

5.4 来源不明的“捐赠数量对不上”问题

最后说一个业务逻辑层面的坑。我在测试数据仪表盘的过程中发现，后台统计数量和列表里实际能看到的记录数总是对不上。排查后发现是用户重复提交表单制造了冗余数据。

这类问题在前端新增衣物表单里极其常见，最简单的解决方法是使用一个submitting的loading状态锁住按钮，防止连续点击。但更坚固的防线在后端：同一用户对同一张表单添加一个防重令牌（幂等键）。收到请求时先检查有没有处理过相同token的请求，处理过就直接返回上一次的结果。

如果你时间紧张，至少要做到前端防抖加按钮禁用：

<el-button type="primary" :loading="submitting" @click="submit"> {{ submitting ? "提交中..." : "提交捐赠" }} </el-button>

async function submit() { if (submitting.value) return submitting.value = true try { await http.post("/clothing", form.value) ElMessage.success("提交成功，等待管理员审核") } finally { submitting.value = false } }

5.5 数据库时区与日期格式化：看起来小但很致命

MySQL默认时区是服务器系统时区，Flask写入created_at用的是本地时间，但前端JavaScript拿到后端返回的时间字符串后，用new Date()解析时容易因为时区偏移少掉8小时。虽然捐赠平台对时间精度要求没那么苛刻，但“记录显示下午4点提交，实际是上午8点提交”这种错误在演示时非常丢分。

我的处理方式是统一约定：后端所有时间字段返回ISO 8601字符串加+08:00时区标志，前端不做本地时区猜测，直接原样展示。

在Flask里设置SQLAlchemy列时可以这样：

from datetime import datetime, timezone def utc_now_plus_8(): return datetime.now(timezone.utc).astimezone(timezone(timedelta(hours=8))) class Clothing(db.Model): id = db.Column(db.Integer, primary_key=True) created_at = db.Column(db.DateTime, default=utc_now_plus_8)

前端需要显示“几分钟前发布”此类相对时间时，再用dayjs插件统一处理，不要在页面里到处写new Date(xxx).toLocaleString()。

6. 项目展示与上线：能写在简历上，也能回应答辩质询

项目做到这里，整体功能已经完整，接下来有两件事务必认真对待：一是数据初始化与演示环境准备，二是项目文档和答辩话术。

6.1 演示数据如何造得“像真的”

写项目时如果数据库里全是“测试1、测试2”这样的脏数据，即使是答辩现场演示，老师极大可能没耐心看。所以建议在项目启动时自动执行一个init_data.py脚本，插一批真实的模拟数据：

• 8个受助机构，分布在不同的山区县。
• 50件等待匹配的衣物，类别覆盖棉衣、T恤、裤子、童鞋等。
• 20条需求单，按不同季节和年龄段规划。
• 30条匹配记录，其中一部分已经到达“已签收”状态。

更进一步的“仿真实”是在评估和机构反馈里写明捐赠来源、捐赠者昵称和实际年龄段对应的衣物需求。

def seed_data(): agencies = [ {"name": "爱心村小学", "region": "云南红河", "need": "6-10岁冬季棉衣"}, {"name": "板桥镇希望小学", "region": "贵州铜仁", "need": "4-6岁幼童春秋外套"}, ... ] for a in agencies: insert_agency(a)

演示时直接从仪表盘打开“统计看板”，能看到月度捐赠趋势、衣物类目占比、需求完成率这些真实效果——强烈建议在统计页面上放一个“按区域筛选”的功能，这是整个项目里最容易被问到的亮点。

6.2 答辩前需要弄明白的五个问题

这个项目做完，你在答辩时大概率会被追问这五个问题。我建议在答辩前把答案明确写下来，确保自己能流畅回答：

1. 为什么不用现成的公益平台？答：现有平台的信息透明度不够，捐赠者看不到衣物的最终去向；本项目用状态机记录了每一件衣物的全生命周期，能直接展示“从捐赠到签收”的完整轨迹。
2. 用户表单校验为什么后端还要做一遍？答：前端校验只优化用户体验，不能防恶意请求；后端的字段、权限、状态三重校验才是安全底线。
3. 技术栈选型的依据是什么？答：按项目规模选了Flask轻量框架；Vue 3加Element Plus快速构建多角色界面；MySQL存储结构化数据，稳定成熟。
4. 这个项目还有什么不足？诚实回答：目前匹配逻辑依赖管理员人工确认，后续可以利用物品类目标签和机构地区做相似度排序，把人工干预降到更低。
5. 如果并发人数变多会怎样？答：Flask开发服务器只是本地演示用途；生产上可以挂Gunicorn或uWSGI提供多进程服务，再前置一层Nginx；数据库层面还能加索引和连接池配置。

6.3 后续扩展：从一个课设变成一个真正可持续的公益系统

如果说这篇文章还有什么值得让你多花时间想想的，那就是项目做完了别立刻扔掉，它有很多值得扩展的方向。我当时做完基础版本后，继续加了三个改进迭代，简历和项目描述瞬间就不一样了：

• 智能匹配推荐：给衣物和需求单都打上规范化标签（类目、年龄、季节），计算标签相似度分数，管理员在匹配页面看到的优先选项自动被最匹配的排到前面。
• 捐赠证书自动生成：物流到达签收后，系统自动生成一张带编号的电子捐赠证书，捐赠者可以在个人中心下载。这个功能非常“公益项目”，很能打动面试官。
• 物流状态定时同步：调用快递查询API，把物流信息从手动登记升级为自动跟踪，让受助机构在签收前每一步都有通知。

做这个项目的整个过程，我最大的体会是：公益项目的技术难度不一定比电商高，但业务逻辑的严谨程度要求一点都不低。每一件衣物从登记到送出，每一步状态变更都必须有出处、有权限、有记录。这种“流程感”一旦建立起来，你写任何后端系统都会有一个清晰的骨架意识。

如果你正准备复现这个项目，建议从数据库设计开始，先把那五张表的字段和状态枚举定清楚，再动手写代码——这比你先搭界面再做表要节省数倍时间。选型上遇到拿不准的，记住一条原则：能用最熟悉的工具就绝不为了炫技换框架，公益类项目的价值从来不是技术复杂度，而是你对业务的理解深度和流程的完整度。