企业官网建设流程全解析

社区团购这几年火到什么程度，不用我多说了。小区门口一排排自提点，团长在微信群里从早到晚发链接，用户头天下单、次日提货，整个流程看起来简单，但真要做成一个系统，里面的坑一个比一个深。我前后用了大概六周时间，从零做完了一套基于Python、Django和Vue3的社区团购系统，支撑小区管理员、团长、普通用户三种角色跑通完整的“浏览-下单-支付-备货-自提-结算”闭环。这篇文章就把整个项目的技术拆解、踩坑过程、关键代码和上线运营经验一次性写透，想用Django全家桶做电商类全栈项目的人，或者正打算把社区团购当毕业设计、面试项目的同学，看完应该能少走很多弯路。

1. 做之前先想清楚：社区团购为什么不是普通电商的换皮

很多人在拿到“社区团购系统”这个需求时，第一反应就是“这不就是商城吗，商品管理、购物车、下单、支付、物流，整套电商逻辑往上套就行”。这个想法是最大的坑。社区团购和传统电商的业务模型差别非常大，如果不先把业务本质拆明白，后面数据库设计、状态机、权限体系全都会跑偏。

1.1 预售制是灵魂：先收款，后备货

传统电商是“货在仓库，随时买随时发”，库存是一个实时确定性数据。社区团购恰好相反，用户下单的时候，货往往还没到仓库。平台先汇总某个小区一天的订单量，统计出每种商品要多少斤、多少箱，再拿着这个汇总数据去供应链端采购。这意味着在设计商品信息和订单表时，不能套用传统电商“下单扣库存、支付减库存”的逻辑。

我最初把库存字段直接放在商品表里，后来发现团长在后台报数时，平台运营希望看到的是“预估可售切几分钟后自动同步”，而用户下单时只锁定“购买资格”，真正的核销动作发生在第二天用户到自提点提货那一刻。这套流程里，订单的“已支付”并不代表“货已到手”，中间隔着一个“平台采购备货”的阶段，所以订单状态里必须存在“待提货”这种过渡状态，而不是传统电商的“待发货”。

另一个容易忽略的点是，社区团购的商品里，生鲜占大头，生鲜的计费单位是份、箱、斤，而不是单纯的“件”。我见过不少项目把“规格”简单做成下拉框，结果这三个计量单位混在一起时，前端SKU联动、后端库存扣减全是灾难。

1.2 团长是系统的“腰部力量”，不是普通分销员

社区团购和普通电商分销最大的区别在于：团长不只是帮平台卖货拿提成，他还承担了货品暂存、用户通知、售后前置处理这三个实打实的线下职责。这就意味着，团长账号必须有一个独立的管理后台——他能看到自己小区的当日订单明细、能操作订单核销、能处理简单的售后登记。

技术上的连锁反应是：订单不能只挂在用户名下，必须同时关联“团长ID”和“小区ID”。我最初设计订单表时只留了user_id和address_id，结果到了做团长结算账单时，发现根本没法快速统计出某个团长名下的订单总额，只能临时写一堆低效的聚合查询，白白折腾了一整天。

所以第一性原理是：社区团购系统的核心关系不是“用户-商品”，而是“小区-团长-用户-商品”这个四元组。所有表结构设计都应该围绕这个四元组展开，而不是照搬普通电商的用户下单模型。

1.3 三种角色的权限边界要在一开始定死

在项目开始之前，我先把三种账号的能力边界想清楚了，这个动作在后端写权限校验时省了大量返工：

这里最关键的一条是“团长不能改平台价”。社区团购的毛利非常薄，很多商品团长有自己的促销空间，如果直接让团长改价，平台的价格体系马上会乱掉。正确做法是给团长留一个“活动折扣率”字段，上限由平台控制，团长只能在95%到100%这个区间内设置折扣。这个细节在后端模型和前端表单里都要体现，属于那种不做问题不大、做了马上更专业的“加分项”。

2. 数据库核心表设计与订单状态机：整个系统真正的地基

我常说，一个电商类项目，数据库设计得好不好，直接决定你后面写业务代码时是在“盖楼”还是在“填坑”。社区团购系统的表设计，关键不在多，而在关系准确、状态可追踪、账务可核对。

2.1 十一张核心表，每一张都卡住一个业务闭环

整个系统我实际落地的核心表一共十一张，我按业务域分组列在下面，没有一列字段是拍脑袋加的：

很多人会问，购物车表需不需要单独建？社区团购的购物车其实相当轻量，因为用户也就是晚上在群里点开团长链接，往购物车里丢几样东西而已。建独立表的好处是可以持久化“用户上次未结算的清单”，下次再进入小程序或者H5时能一键继续购买，这个体验提升非常明显。所以购物车表值得单独建。

再强调一下“商品快照”字段。订单表里必须冗余一份下单时刻的商品名称、规格描述、单价快照，绝不能通过订单明细去实时关联商品表。原因是社区团购的商品价格变动特别频繁，今天特价、明天原价，如果后台把商品价格改了，历史订单的金额如果需要追溯就全乱套了。快照这种“空间换稳定”的做法，是电商系统里的通用作风。

2.2 订单状态机的十个状态，少一个都会让你在售后阶段抓狂

社区团购订单的状态流转，比普通电商要长得多。我把状态定义成了整数枚举，避免用字符串，数据库索引更高效，代码里读起来也直观：

这个状态机的核心设计原则是：资金操作与物流操作分开。比如用户申请退款时，如果订单已经“已提货”，那就不能直接走退款，需要先经过“售后表”登记，由平台判断是否要回收商品、是否允许部分退款。我最初图省事，只设计了“待支付、已支付、已取消、已退款”四个状态，结果上线第一周就被团长骂惨了——用户提货之后发现问题申请售后，系统根本不知道商品到底有没有离开自提点。

状态机的每个节点还要配套“动作”逻辑，比如：撤销订单时，要判断是否已经支付；关闭订单时，要判断是否已经进入备货流程。这部分我在后面第3章写后端代码时会详细展开。

2.3 佣金结算的账务处理：看似简单，做起来满是细节

国库券、发票、对公账户这些词我不碰，单说小规模社区团购常见的“平台给团长结算佣金”这件事。

我设计佣金结算时踩过一个很大的坑：把“订单完成”当作佣金可结算的唯一条件。后来发现，如果用户提货后第7天订单才自动完成，团长得等整整一周才能看到这笔钱，对团长积极性打击很大。实际运营中很多平台用的是“提货次日即可结算”的模式。我最后把结算逻辑改成了：只要订单状态进入“已提货”，且用户没有发起售后申请，第二天零点跑一次定时任务，把这笔订单的佣金计入团长的“待结算余额”。

佣金比例的设置也讲究。我在团长表里留的是“基础佣金率”，比如默认5%，在订单级再做“活动商品独立佣金率”。因为平台做秒杀时，本身就不赚钱，不可能再给团长5%的佣金，这时候就要用商品级的覆盖规则。这两个字段要分开存，否则你算出来的结算账单永远是错的。

需要注意一个实务细节：佣金结算表虽然叫“结算表”，但它存的是汇总记录而不是流水。真正的流水应该在“资金流水表”里，每一笔佣金增减都对应一条流水。这样用户和团长看到余额变动时，能明确知道“这笔钱是哪个订单来的”，对账时也可以用流水反推余额，这个设计习惯救过我太多次了。

3. 后端落地：Django项目里的分层、视图、权限与支付对接

数据库设计完，最难的部分其实已经过去了一半。但很多新手觉得Django写后端难，难在“框架太自由”，不知道代码该往哪里放。我这次把项目按照“配置层、应用层、接口层、调度层”做了明确划分，经验是：Django项目一旦超过五个App，就应该提前把通用基础代码抽出来，不然改起来会想死。

3.1 App划分：宁可多拆，不要揉在一起

我这次把后端拆成了六个App，每个App只干一件事：

• accounts：用户认证、登录注册、角色区分、用户地址管理
• goods：商品分类、商品库、规格管理、库存
• trade：购物车、订单、支付回调、售后
• community：小区、团长入驻、自提点管理
• settlement：佣金计算、结算单、资金流水
• common：通用工具函数、Django Rest Framework基类、异常处理、地区编码

Trade是核心中的核心，订单状态机、支付回调都在这个App里。Community和Settlement是社区团购区别于普通电商的两个“特色模块”，值得多说几句。

App划分时要注意一个原则：底层的fields不要跨App做循环引用。比如Order模型需要关联Community的模型，我就在Order里只存community_id，不直接引入外键对象，查询时再通过ID去Community表取数据。这种“跨表通过ID关联、不引用对象”的做法，虽然多了两次查询，但避免了Django懒加载带来的莫名报错，在工程上非常稳妥。

3.2 DRF视图集与序列化器：把“接口分层”写清楚

Django REST Framework是社区团购系统后端最核心的依赖库。我建议所有写这类系统的人，不要为了炫技去摆弄过于复杂的ModelViewSet的魔法方法，而是老老实实用最朴素的三件套：ModelSerializer + ViewSet + queryset。

这是我实际使用的一个订单列表接口的ViewSet骨架，大家可以感受一下DRF的节奏：

class OrderViewSet(viewsets.ModelViewSet): queryset = Order.objects.filter(is_deleted=False) serializer_class = OrderSerializer def get_permissions(self): # 天然支持不同角色的权限区分 if self.action == 'create': permission_classes = [IsAuthenticated] elif self.action in ['settle', 'refund']: permission_classes = [IsAdminUser] else: permission_classes = [IsAuthenticated, IsOwnerOrReadOnly] return [permission() for permission in permission_classes] def get_queryset(self): user = self.request.user if user.role == 'admin': return Order.objects.filter(community_id=self.request.query_params.get('community_id')) if user.role == 'leader': return Order.objects.filter(leader_id=user.leader_profile.id) return Order.objects.filter(user=user)

ViewSet里最有价值的是get_queryset的这个覆写：普通用户永远只能拿到自己的订单，团长只能拿到自己小区的订单，平台管理员则可以通过查询参数切换到任意小区。这个代码必须重构到项目里形成规范，否则分分钟出现“越权查询”漏洞。

序列化器（Serializer）里，我只强调一点：写create和update方法时，一定把“价格快照”写进去，不要等到最后查数据库。比如前端提交订单时，后端查一下当前商品的售价，然后把这个数字固化到订单的amount字段里。用户看到的价格永远是下单那刻的，而不是提交后又被后台改掉的价格。

3.3 JWT认证、微信登录与权限校验的取舍

社区团购的最终用户大多数情况是从微信里打开的，所以登录首选微信OAuth授权登录。用Django实现的话，我推荐使用djangorestframework-simplejwt这个库。它的核心交换流程是：前端拿到微信登录的code，传给后端，后端用appid和secret去微信开放平台换openid和session_key，然后找到或创建用户，最后签发一个JWT给前端，前端后续请求都监听这个Token。

有一点要格外小心：JWT的过期时间。很多项目直接把ACCESS_TOKEN_LIFETIME设成7天，图用户省事。但社区团购涉及支付、售后，用户资金安全是第一位，过长的Token窗口一旦被盗，危害非常大。我最后把移动端Token的有效期设为2小时，Refresh Token有效期设为30天。前端在请求时拦截401状态码，自动刷新Token，这种体验既不打扰用户，安全性也足够。

权限校验这里其实没有银弹。我重点提一个实用技巧：Django的model_meta可以用来自动生成权限，但在社区团购这种角色逻辑不标准化的场景里，“权限控制最好写在业务视图层，而不是依赖Django的全局权限钩子”。我的做法是定义一个permission_required(role)的装饰器，配合一个简单的角色枚举类，代码可读性远好过给每个model配置四个权限。

3.4 支付与退款：回调验签、幂等处理、对账脚本

微信支付是最常见的社区团购支付方式（不是打广告，是因为用户真的都在微信里）。Django后端如果要接微信支付，必须处理好这几个问题：

第一，回调验签不能省。微信支付会把回调结果POST到你配置的notify_url上，这个请求包含transaction_id、out_trade_no、return_code、result_code等字段。你先要用微信公钥验签，确认这个通知确实来自微信，然后才去更新订单状态。我见过有项目图省事，直接信任回调内容，后来被人模拟请求“支付成功”刷单，属于必须防住的安全漏洞。

第二，回调必须做幂等。微信会为了确保成功送达，把回调通知重试多次。如果你在回调里直接执行“把订单状态改为已支付”，第二次回调过来时，订单已经变成已支付，如果逻辑是“状态等于待支付才能改为已支付”，可能触发异常。我的态度是：回调只做“加锁与记录”，支付确认单独做一个PaymentRecord表，一个订单只能有一条成功记录。只要看到transaction_id已经存在，就直接返回成功，不再重复操作订单。

第三，退款要异步处理。用户发起售后之后，订单状态变成退款中，管理员同意后，你调用微信支付的退款接口。这一步必须异步任务去执行，不能在前端请求里同步等待微信响应，否则用户体验会很差。我用的是celery加一台Redis作为broker，退款任务丢进队列，后台看板显示“退款处理中”，等微信退款回调回来确认成功后再更新退款状态。

退款还有个容易忽略的点：退款金额不能从“订单总金额”里直接减，要按实际支付金额退。因为社区团购经常有满减活动、优惠券抵扣，订单总金额和实付金额往往不一致。退款时一定用实付金额来计算，否则用户会投诉你多扣钱。

4. 前端实战：Vue3管理端的搭建、组件设计与登录态管理

后端跑通只是第一步，社区团购真正难缠的地方在前端交互。团长端的H5页面、用户端的微信内页面、平台管理后台这三个前端，不可能做成同一个工程，我这次先做了最核心的管理后台。管理后台用Vue3 + Element Plus + Pinia + Vue Router 4搭建，这是目前最主流也最省心的组合。

4.1 脚手架与目录结构：创建项目两分钟，组织代码一下午

用Vite创建Vue3项目很快，难的是目录结构怎么定。我这次的项目结构如下：

frontend/ ├── src/ │ ├── api/ # 所有后端接口的封装 │ ├── assets/ # 静态资源 │ ├── components/ # 通用组件（表格、表单、弹窗） │ ├── stores/ # Pinia状态管理 │ ├── router/ # 路由配置 │ ├── views/ # 页面级组件 │ ├── utils/ # 工具函数（请求库、时间格式化） │ ├── App.vue │ └── main.js

目录不乱，写起来就顺手。这里有一个我踩了无数次的坑：api/目录里的接口封装，不要一个个手写，可以用一个工厂函数批量生成。我定义了一个createApi(url, method)函数，然后通过配置数组一次性注册几十个接口，代码量直接砍掉一半，维护也方便。前端调用时，只需要api.orderList(params)，可读性极高。

4.2 商品分类级联与SKU规格编辑：两个“难缠组件”的落地思路

管理后台里最“夹生”的组件有两个：商品分类级联选择和规格价格编辑。它们看起来简单，实际上全是细节。

分类级联，我实现的方法是后端直接返回一棵完整的分类树，前端用一个el-cascader搞定。不搞懒加载，因为社区团购的分类数量最多几十个，一次性全量下发根本不会有性能问题。从接口设计角度说，这种“小数据全量、大数据分页”的策略，才是真正的工程智慧。

规格编辑更考验细节。一个商品可以有多个规格（比如“苹果5斤装19.9元”和“苹果10斤装39.9元”），规格和价格要联动，而且每个规格还要有自己的库存。前端做法是用动态表单，点击“添加规格”自动生成一组输入框，通过v-model绑定一个有meta信息的数组。后端序列化器则用ListSerializer的create和update方法，一次性接收整个规格列表，替换掉原有的规格数据。

这里必须提个醒：规格更新时，不要直接delete旧规格再insert新规格。因为可能已有用户把该规格加进了购物车，强删会导致外键错误。正确做法是逻辑删除旧规格，新规格执行insert，旧的保留历史，用状态字段标记为不可售。这也是我在第2章为什么强调核心表都要有is_deleted字段的原因。

4.3 登录态管理与权限控制：为什么你的页面总在刷新后跳登录

Vue管理后台的登录态管理，核心是比较稳定的。登录后把JWT存储到localStorage和Pinia里，然后在Axios拦截器里统一注入Authorization头部。这样做的问题在于：页面一刷新，Pinia里的状态丢失，如果你只依赖Pinia存储，就会导致这个Session丢失，所以必须有一个从localStorage恢复Session的初始化逻辑。

我处理的方案是：在Pinia的store定义里，state初始化时直接从localStorage读取。每次请求401时，请求拦截器尝试用Refresh Token刷新，刷新成功后重新放行原请求。如果Refresh Token过期，就跳转到登录页。这个逻辑写在Axios拦截器里最合适，不会污染业务代码。

权限控制的另一块是路由级控制。Vue Router的meta字段可以配置每个路由的“允许角色”，然后在全局前置守卫里检查用户角色是否匹配。比如团长后台的路由，meta.roles = ['leader']，如果普通用户访问，直接重定向到504页面。这个设计比在每个页面内用v-if过滤要干净得多，也让后端接口成为第二道防线。

5. 多团长并发与超卖问题：Python后端务必警惕的线上事故源头

社区团购有一个特别容易爆雷的业务点：特价商品和秒杀活动。团长把秒杀链接往群里一甩，几百人同时下单，如果库存扣减逻辑写得不对，超卖几乎是必然。下面的经验是我用一次线上事故换来的，写在这里希望你能绕过去。

5.1 不要用“先查后改”的方式扣库存

我最早期版本扣库存的写法是：

goods = Goods.objects.get(id=gid) if goods.stock >= num: goods.stock -= num goods.save()

这个代码在并发量稍高一点时必出问题。两个请求同时读到了同样的库存数比如3，都判断3>=2，都减2，最终库存变成-1，但两个订单都下单成功了。超卖的根因就是“读取与更新”不是原子操作。

解决办法不难，用Django的F()表达式做一个原子更新：

from django.db.models import F updated = Goods.objects.filter(id=gid, stock__gte=num).update(stock=F('stock') - num) if updated == 0: raise StockShortage()

这里的本质是让数据库帮我们做库存判断和扣减的原子操作，而不是在Python代码层比较。数据库的WHERE stock__gte=num条件能挡住超卖，实测下来高并发下这个写法是很稳的。

需要特别提醒：这个原子写法只是一个单行更新，如果还掺杂了其他业务逻辑（比如写订单表、删除购物车），就要考虑事务问题。扣减成功后，再在事务里创建订单，如果后续操作失败，需要手动把库存加回去。这个补偿逻辑我通常用一个contextmanager封装，避免一次操作遗漏。

5.2 Redis预扣库存：把秒杀流量挡在第一道闸门前

单纯数据库原子扣减，在极端高并发下（比如上千人同时抢一个特价）还是会打垮数据库。更稳的方案是先让Redis做一道“预扣”闸门。

秒杀开始时，先把商品库存写入Redis：

redis_client.set(f'stock:{sku_id}', sku.stock)

用户下单时，先执行Redis的decr操作，如果返回值大于等于0，说明有库存，继续走正常的数据库下单逻辑；如果返回值小于0，说明已经抢光，直接提示“已售罄”。同时注意，Redis预扣减后，数据库也还是要走stock__gte的原子更新，因为数据库才是最终的数据源，Redis更像是流量闸门，不是真正的账本。

这个双写方案里，最麻烦的是Redis和数据库的数据一致性：如果用户下单后没有支付，订单超时取消了，Redis里的库存要加回去吗？我的答案是：不要加回到Redis，只要保证数据库里的真实库存不被多扣就行。原因是超时订单还没走到数据库扣减，它只是占用了Redis的一把“预扣名额”，名额失效后，自动释放，对真实库存没有任何影响。这个小细节很多教程不会讲，但对理解秒杀方案的工程本质很关键。

5.3 订单超时未支付自动关闭：Celery任务不要直接跑循环

订单支付超时关闭，常规思路是起一个定时任务，每分钟扫一遍所有“待支付”订单。这样做的缺点是：表越大越慢、数据库压力越来越大，而且精确度很差。社区团购的时效性没有那么强，晚几秒钟关订单影响有限，但也不能无限制地堆积。

我用的是更细的延迟任务方案：用户下单成功后，往Celery里发一条delay任务，任务内容就是“如果这个订单订单时间超过30分钟且状态还是待支付，就把状态改为已取消”。Celery会精确地在30分钟之后执行这个任务，不用扫全表，压力小很多。

为了避免任务丢失，Celery worker挂了等情况，我同时保留了一个“兜底定时任务”，每10分钟扫一次超时订单。这就叫“双保险”，主方案效率高，兜底方案不丢数据，适合所有定时类业务。

6. 部署上线：从本地到服务器的完整过程

后端写差不多了，前端也联调完了，真正把系统部署到服务器能正常对外提供服务，是另一门课。尤其Django项目，本地开发服务器runserver是一回事，线上用uwsgi又是另一回事。

6.1 Nginx + uWSGI + 多进程配置：参数都是调出来的

我的部署架构是经典的三层：Nginx接收外部HTTP请求，静态资源由Nginx直接返回，动态请求转发给uWSGI，uWSGI跑Django应用。

uWSGI配置，我是写在配置文件里的，不会每次启动都敲一长串命令：

[uwsgi] socket = 127.0.0.1:8001 chdir = /srv/community module = community.wsgi:application master = true processes = 4 threads = 2 harakiri = 60 max-requests = 5000 vacuum = true buffer-size = 32768

进程数不是越多越好。一个Django worker默认大概占用几十MB内存，如果服务器只有2G内存，开8个进程直接内存耗尽。我这里设4个进程、每个进程2个线程，实测能扛住日常流量。max-requests = 5000的意思是积累5000个请求后自动重启worker，可以防止内存泄漏累积，这是很重要的运维细节。

Nginx配置里，我特别关注两个位置：一个是client_max_body_size，因为商品图片的上传大小往往超过默认1M限制，我设置成了20M；另一个是location /static/和location /media/要指向正确路径，否则页面样式和商品图会全挂。

6.2 HTTPS与域名配置：微信登录的必要前提

微信登录要求回调域名一定是HTTPS，这个没得商量。要让社区团购跑起来，没有HTTPS根本走不通微信授权那一关。

申请SSL证书，现在有免费渠道，不需要花钱。把证书上传到服务器后，Nginx的配置大概长这样：

server { listen 443 ssl; server_name your-domain.com; ssl_certificate /etc/nginx/ssl/your-cert.pem; ssl_certificate_key /etc/nginx/ssl/your-cert.key; location / { include uwsgi_params; uwsgi_pass 127.0.0.1:8001; } # 静态资源单独处理 location /static/ { alias /srv/community/static/; } location /media/ { alias /srv/community/media/; } }

这里还有个细节：HTTP的80端口要做一个301跳转到HTTPS，避免用户直接访问HTTP时功能异常。配置写好后一定要用nginx -t检查语法再重载，不然一个语法错误会导致整个网站打不开。

6.3 上线第一周我遇到的那些“看不见的坑”

上线并不意味着结束，下边这些坑人人几乎都会遇到：

第一，时区问题。Django的USE_TZ=True会让数据库里存的是UTC时间。如果你在业务逻辑里直接用datetime.now()去算“今天提货的订单”，运营会看到所有订单的“今天”都比用户慢了8小时。解决办法是用django.utils.timezone.now()，或者干脆把USE_TZ = False（如果服务器和用户都在同一个时区的话）。

第二，静态文件的collectstatic。Django生产环境不会自动从app目录收集静态文件，要执行python manage.py collectstatic。很多新手忘了这一步，页面样式全丢。同时STATIC_ROOT、STATIC_URL要配置正确，Nginx的alias路径不要带错层。

第三，Celery进程守护。我用了supervisor来管celery和uwsgi进程，不然SSH断开后进程会跟着退出。supervisor配置很简单，把启动命令写进去，设置autostart=true就行，但这一步是很多人踩坑后才知道的。

7. 从这套系统里我提炼出的几个“通用经验”

项目做完复盘，有一些经验不局限于社区团购，写任何Django全栈项目都用得上。

7.1 全栈项目最容易翻车的三个地方

翻车第一名是“接口文档缺失”。我最初前后端联调时，因为没约定好字段名，前端要phone，后端返回mobile，改了半天。后来我在项目一开始就约定用ApiFox或swagger生成接口文档，每次后端写完接口，前端照着文档调，效率翻倍。

第二名是“异常处理不统一”。Django的异常要么给出了HTML错误页，要么直接抛500，前端拿到一坨堆栈信息。我统一封装了一个全局异常类，所有API返回都走同一个JSON格式：

{ "code": 40000, "message": "参数错误", "data": null }

前端只需要判断code === 20000就行，错误弹窗文案直接取message字段，非常统一。

第三名是“日志系统没有提前搭”。上线后遇到问题，最怕的就是没有任何日志可查。我在Django里配置了logging，把请求日志、错误日志、支付回调日志分别写到不同文件，还加了按日期切割，省去了线上排查问题时的无数抓狂时刻。

7.2 给新手的练级路线

如果你是刚学完Python基础，想拿社区团购系统来做全栈练手，我建议的路线是：

• 先花一周把Django基础过一遍：ORM的filter、annotate、select_related要搞明白，重点是查询性能。
• 再花一周学Django REST Framework：重点理解Serializer、ViewSet、权限认证，不要一上来就钻进源码里。
• 然后才是Vue3：先会用脚手架搭项目、用Axios对接接口、用Pinia管理状态，不要浪费大量时间研究Vite插件。
• 最后再把微信支付、Celery、Redis、Nginx部署这些工程化能力补上。

这几步走完，你不仅能看懂这篇文章里说的所有东西，还能有自己的见解。社区团购这个项目域，我做了两版，第一版停留在“能跑起来”的层面，第二版才真正考虑到了并发、幂等、权限、对账这些工程问题。如果你想把这个类型的项目写进简历，强烈建议至少完成第二版：把订单状态机画全、把支付回调幂等处理掉、把库存超卖挡住，这三个点只要在简历里写出来，面试官一定会多问两句，你的准备也算真的没有白费。