刚看到这个项目标题我第一反应是做这个的人多半已经被Django和Flask折磨过一遍。Django那套“全家桶”写管理后台确实香但真到对外接口、算法服务、第三方对接整个框架又沉又重Flask轻巧灵活可一旦要扯上会员订单、课程排期、权限分配这些正经业务你就会发现自己其实是在用Flask手动重建Django早就有的东西。所以我用Django Flask双框架搞了一套个性化健身房管理系统把两个框架的劣势互相抵消优势各自放大实战下来整体运行很稳。这套系统覆盖了健身房运营的几条主线业务会员档案管理、体测数据分析、课程预约排期、私教服务、个性化训练计划推荐。前台面向会员和教练后台面向运营管理员会员能在小程序或H5里查体测趋势、约课、看推荐计划教练能维护课程和会员记录管理员管理会员卡、订单、统计报表。适合两类人参考想入门Python Web实战的同学能完整跑通一个业务闭环准备做毕设或者小型商用项目的可以拿这套双框架结构当作蓝本。前半部分我重点讲选型思路、数据模型和核心模块后半部分给出实操代码和踩坑记录认真看完基本能自己复刻一套。1. 项目整体设计与技术栈选型思路1.1 为什么非要Django Flask双框架搭配先说一个最常见的疑问一个项目为什么不用单一框架非要搞混搭我的答案是健身房管理系统本质上由两类特性完全不同的模块组成。一类是强业务模块比如会员档案、会员卡订单、课程排课、权限控制。这类东西需要成熟的数据校验、事务管理、后台管理界面、数据库迁移机制Django的ORM、Admin后台、Auth体系、Migration机制几乎就是为此量身定做的。如果用Flask光是自己实现一个能用的后台管理系统就要花费大量重复劳动更不用说权限控制里那些细节比如“教练只能看自己会员的体测数据”“运营只能操作自己门店的排课”这些在Django里都是现成的工具。另一类是弱业务模块比如个性化推荐算法引擎、健康指标计算、体测数据分析。这类模块逻辑相对独立需要频繁迭代算法而且很可能被多个系统复用。把它们塞进Django的app架构里当然也能跑但每次改算法都要动整个项目测试和部署成本都很高。Flask的优势就体现出来了路由轻量、结构简单、可以作为一个独立服务快速启动和替换把推荐引擎隔离成一个微服务主系统通过HTTP接口调用两边互不影响。我实际采用的方案是Django作为主应用负责全部核心业务和后台管理Flask作为一个独立的推荐服务进程部署在同一台服务器上Django通过内部HTTP请求调用Flask的推荐接口。还有一种常见做法是用Werkzeug的DispatcherMiddleware把Flask应用挂载在Django进程里两个框架共用一个入口但我在实践后不建议在正式项目里这么干原因是Python进程内的线程模型和模块隔离会让两边互相干扰排查问题时分不清是哪个框架出的错。独立进程、内部调用逻辑边界清晰得多哪个挂了重启哪个就行。1.2 个性化推荐模块的算法设计思路健身房场景里的“个性化”不能只停留在营销噱头上它要真正回答一个问题这个会员今天应该练什么、怎么练、为什么这么安排。我选择的方案是“规则加权 协同过滤”的两层推荐策略。第一层是规则加权基于会员的体测数据生成可解释的训练方向。系统采集身高、体重、体脂率、肌肉量、基础代谢、腰围臀围等指标后先计算出BMI、体脂百分位、基础代谢率这些衍生数据然后按规则判断训练方向。比如体脂率偏高的会员优先推送减脂塑形类课程肌肉量偏低的推送增肌力量类课程久坐办公人群推送体态纠正和核心强化课程。这样推荐结果都有明确的理由支撑教练向会员解释时也站得住脚会员不会觉得系统是在乱推广告。第二层是协同过滤基于会员的兴趣标签和历史课程评价做补充。会员在首次注册时会勾选运动偏好比如瑜伽、动感单车、搏击操、重量训练系统记录每节课程的评价分数和出勤率然后计算会员之间、课程之间的相似度把“和你偏好相似的人喜欢的课”推荐给你。两层结果按权重融合规则结果占70%协同过滤占30%然后过滤掉会员已经上过且评分较低的课程最终输出个性化的周训练课表。这样设计的核心原因是“可解释性”。健身行业的教练和会员都对“为什么推荐这个”非常敏感一个纯黑盒算法推出来的计划教练不会采纳会员不信任。规则加权让推荐结果透明化协同过滤又能兜住冷启动之外的丰富度。整体计算逻辑放在Flask服务里主系统只传会员IDFlask内部通过数据库读取健康数据计算完成后返回推荐计划列表主系统再做缓存和展示。1.3 数据库设计与核心表结构数据库是整套系统的地基我在设计时没有图省事把所有东西塞进一张大宽表而是按领域分表保证可扩展性。核心表一共六张会员表、体测数据表、教练表、课程表、课程排期表、预约记录表加上推荐日志表。会员表与Django自带的User表通过OneToOneField关联User负责登录认证会员表负责业务属性手机号、性别、出生日期、会员卡等级、到期时间。之所以拆分而不是直接扩展User表是因为Django的User模型在项目中期硬改字段非常痛苦而独立关联表可以随时加字段不动认证体系。体测数据表是独立设计的关键。健身房里会员的体测数据是持续产生的一个月测一次一年就有十几条记录。我按一次一条记录的方式存储每次体测生成一条记录包含身高、体重、体脂率、肌肉量、基础代谢等原始字段同时把这次测出的BMI等派生指标也冗余存进去查历史趋势时不用实时计算直接取数即可。表结构上按会员ID和测量时间建立联合索引历史查询和趋势绘图都很快。课程排期表和预约记录表的联动是防止超卖的关键。预约记录表对“课程排期 会员 日期”做了唯一约束从数据库层面杜绝同一个人对同一节课的重复预约。排期表上存有总容量和当前已预约人数每次成功创建预约都会在同一个数据库事务里更新已预约人数并发场景下配合行锁使用后面我会详细说这个问题。推荐日志表很多人会忽略但我强烈建议项目里必须有这张表。每个推荐结果生成后记录会员ID、推荐课程ID、推荐权重、推荐理由、推送时间。后期要优化算法、排查“为什么给这个会员推了瑜伽课却从不推荐搏击操”这张表就是最直接的复盘依据。2. 核心功能模块拆解与实现要点2.1 会员管理模块从注册到会员卡到期会员模块是健身房系统里最基础的底座。我在模块里实现了完整的会员生命周期管理注册、资料维护、会员卡购买、到期预警、续费记录。注册时调用Django的User创建登录账号同时创建Member档案并让会员勾选运动偏好标签这些标签会同步进入推荐引擎的画像表。会员卡等级我用了三个值月卡、季卡、年卡每个等级对应一个到期时间。会员购买卡后系统自动在订单表里生成一条会员卡订单并把会员表里的到期时间更新为当前时间 卡时长。这里有个容易被忽略的坑如果会员已经有一张未过期的卡直接加时长容易出错正确的做法是以“当前到期时间和当前时间中较晚者”作为起始时间。也就是说月卡会员在有效期还剩10天时续了一张季卡新到期时间应该是当前到期时间再加三个月而不是从今天重新算三个月。到期预警我用的办法是写一个Django自定义Command每天凌晨跑一次查出所有7天内到期的会员向运营后台推送预警列表同时给会员发到期提醒消息。自定义Command的好处是完全复用Django的ORM和配置环境部署时只需要在crontab里加一行调用不依赖额外组件。这个Command我命名为python manage.py expiry_alert实际跑下来非常稳定。权限方面系统里有三种角色会员、教练、运营管理员。会员通过前台登录教练能看到自己名下会员的体测数据运营管理员能操作所有模块。权限控制用Django自带的Group和Permission实现视图函数上加permission_required装饰器即可。在这里提醒一下别为了省事把所有用户都塞进同一个Group后面要做教练和会员的数据隔离时你会发现权限模型已经乱成一锅粥。2.2 课程预约与排期系统并发下的数据安全课程系统是整个系统里业务逻辑最复杂的一块。健身房每天有团课、私教课、体验课每种课程都有固定容量教练有时间冲突约束会员有预约上限多个会员同时抢同一节课时还要保证不超卖。我设计的核心模型是“课程 排期”两层。课程表保存的是课程的基本信息包括课程名称、类型、时长、适用人群、封面图排期表保存的是某一天某个时间点实际开课的信息包括上课日期、开始时间、结束时间、上课教练、容量上限、当前已预约人数、状态。为什么拆两层因为同一门瑜伽课每周会上三次如果只建一张表要么重复存储课程信息要么一门课只能上一个时间完全不符合实际场景。预约的状态流转是可预约 - 预约中 - 已约满 - 已结束 - 已取消。会员在能力范围内取消预约后系统把已预约人数减一并从约满状态恢复到可预约状态。高并发超卖是我在这个模块遇到的最大挑战。最初版本我简单地在创建预约前查一次人数小于容量就插入预约记录结果压力测试时同一节课最后一个名额被3个人同时约到把排期表玩坏了。后来改成数据库事务加行锁from django.db import transaction from django.db.models import F transaction.atomic def create_booking(schedule_id, member_id, date): schedule CourseSchedule.objects.select_for_update().get( idschedule_id, datedate ) if schedule.booked_count schedule.capacity: raise BookingFull(当前课程已约满) Booking.objects.create( schedule_idschedule_id, member_idmember_id, statusbooked ) schedule.booked_count F(booked_count) 1 schedule.save()select_for_update()会对排期表的那一行数据加锁直到事务提交后才释放这样同一时刻只有第一个请求能看到真实名额其余请求会排队等待等待期间名额已经被占用再次检查时就会抛出约满异常。这样处理基本上杜绝了超卖。预约记录表还有一个细节唯一约束必须加在“排期 会员”这个组合上不能只加会员维度。因为同一个会员可以约周一的瑜伽课和周三的搏击操课如果唯一约束加在会员ID上这人整个系统就只能约一节课业务直接崩掉。正确写法是models.UniqueConstraint(fields[schedule, member], nameunique_schedule_member)。2.3 体测数据采集与健康指标分析体测数据是“个性化推荐”的基石没有数据支撑推荐就是空中楼阁。我设计的体测录入页面由教练在iPad或电脑上操作每次测量完成后把数据录入系统会员端可以实时查看自己的历史趋势。采集的原始字段包括身高、体重、体脂率、肌肉量、骨骼肌率、基础代谢、腰围、臀围。录入时最重要的是字段校验体重和体脂率这些数值如果出错后续所有计算结果都会错而且很难排查。我在表单层做了范围校验数值超出合理区间直接拒绝保存同时记录录入教练ID和录入时间方便后期追溯。派生指标我选择在保存时实时计算并冗余存放。常用的是BMI 体重(kg) / 身高(m)的平方基础代谢使用常见的Mifflin-St Jeor公式男性为10倍体重 6.25倍身高 - 5倍年龄 5女性为10倍体重 6.25倍身高 - 5倍年龄 - 161。主动计算并存起来比每次查询时现场算要高效得多特别是在月卡会员频繁查看历史趋势的场景下数据量上来之后效果差距明显。趋势图展示用了ECharts前端通过接口拉取这个会员全部体测记录按时间排序用折线图展示体脂率、肌肉量、体重的变化趋势。会员在移动端看到自己三个月体脂率从28%降到23%坚持的动力完全不一样。我给这套系统定了个原则数据展示不是做给运营看的是做给会员看的要让会员一打开就有正向反馈。3. 实操过程从0到1搭建整套系统3.1 项目初始化与目录结构设计开始动手前先把目录结构想清楚。很多人喜欢把所有代码堆在项目根目录起步很快项目一变大就开始满地找文件。我采用的布局是Django主项目放上级目录Flask推荐服务独立成子目录两者在代码层面完全隔离只在HTTP层交互。gym_project/ ├── manage.py ├── config/ │ ├── settings.py │ ├── urls.py │ └── wsgi.py ├── apps/ │ ├── members/ │ ├── courses/ │ ├── bookings/ │ ├── bodydata/ │ └── recommend/ ├── recommendation_service/ │ ├── app.py │ ├── engine.py │ └── requirements.txt ├── static/ ├── templates/ ├── scripts/ │ └── expiry_alert.py └── requirements.txtDjango部分我用了一个apps目录来承载所有业务app每个app只负责自己的领域。这样做的好处是当系统需要扩展新功能时比如增加私教预约只需要新建一个apps/private_trainer目录不影响已有app。recommend这个app在Django里主要做两件事维护推荐日志和缓存推荐结果实际的算法计算全在Flask服务里完成。初始化Django项目和各级app之后先把数据库迁移跑通再把Django Admin后台配置好。Admin后台对于开发调试的价值被很多人低估了我前面测试阶段几乎全靠Admin直接补数据、看状态不需要写任何前端页面就能验证模型设计是否合理。3.2 认证权限体系与登录流程实现认证体系我采用的是“后台Session 前台JWT”的混合方案。运营后台跑在PC浏览器里用Django自带的Session认证最合适开箱即用配合Admin后台不用额外开发登录页。前台面向会员的H5和小程序用Session管理跨平台登录状态需要处理Cookie、跨域、移动端兼容等等问题我选择了JWT方式前端把Token存在本地请求时带上服务端无状态校验省事不少。JWT方案用的是djangorestframework-simplejwt这个库在Django配置里设置一个token密钥和过期时间登录接口返回access token和refresh token小程序侧每次请求API时在请求头里加Authorization: Bearer token。会员身份从JWT的payload中解析再通过会员表关联拿到业务信息。这里有一个我踩过的坑JWT的密钥不要直接硬编码在代码里也不要和Django的SECRET_KEY共用同一个值。单独配置一个环境变量比如JWT_SIGNING_KEY部署时从环境读取。曾经一次代码仓库泄漏因为密钥写死别人可以直接伪造token访问所有会员数据那场面想想都冒冷汗。角色权限方面教练和会员的接口必须严格隔离。Django的permission_required(bodydata.view_bodydata)能控制谁能看体测数据但更细粒度的“教练只能看自己的会员”需要自己在视图里加条件判断。我在教练的接口里强制按照coach_id过滤查询集而不是让前端传一个教练ID过来避免越权风险。3.3 个性化推荐功能的完整落地路径推荐功能是系统的亮点模块我严格遵循了“主系统不写算法”的原则。Flask服务启动在5001端口对外提供三个接口获取推荐计划、提交用户反馈、刷新用户画像。Flask侧的核心代码大致是这样的engine部分承担了所有算法逻辑# recommendation_service/app.py from flask import Flask, jsonify, request from engine import generate_plan app Flask(__name__) app.route(/health, methods[GET]) def health(): return jsonify({status: ok}) app.route(/recommend/int:member_id, methods[GET]) def recommend(member_id): token request.headers.get(Authorization) if not valid_token(token): return jsonify({code: 401, msg: unauthorized}), 401 plan generate_plan(member_id) return jsonify({code: 0, data: plan})generate_plan内部并不直接读取数据库而是通过一个内部数据接口从Django的HTTP接口拉取会员画像然后把推荐结果算完后返回。为什么不让Flask直接连同一个数据库早期版本我试过Flask直连数据库确实快但两套代码同时操作同一张表迁移和事务控制非常容易出问题。改成通过接口读数据以后Flask服务甚至可以部署在另一台机器上扩展性完全打开。Django主系统调用Flask时用了请求超时机制避免推荐服务出问题导致主业务卡死# apps/recommend/views.py import requests from django.core.cache import cache def get_recommend_plan(member_id): cache_key frecommend:{member_id} plan cache.get(cache_key) if plan: return plan try: resp requests.get( fhttp://127.0.0.1:5001/recommend/{member_id}, headers{Authorization: fBearer {build_token(member_id)}}, timeout3 ) resp.raise_for_status() plan resp.json().get(data) cache.set(cache_key, plan, timeout12 * 60 * 60) return plan except requests.RequestException: return fallback_recommend(member_id)缓存我用了RedisTTL设为12小时。为什么用12小时首先会员的体测数据不是实时变化的一天之内推荐结果不需要频繁刷新其次缓存时间过长又会让会员觉得推荐内容太死板。12小时是一天两刷的节奏既能保证新鲜度又大幅减少了Flask服务的压力。fallback_recommend是一个兜底方案当推荐服务挂掉时返回最近一次成功缓存的推荐结果或默认课程列表保证体验不中断。4. 常见问题与排查技巧实录4.1 双框架混用时的Session冲突与模块隔离问题代码写到后期最让人头痛的不是某个算法不会写而是Django和Flask耦合在一起时的环境冲突。我第一版试过用Werkzeug把Flask挂到Django同一个进程运行起来开发环境什么问题都没有一上生产环境就频繁出现session串号、静态文件丢失、异步任务混乱。排查了整整一个下午才发现是两套框架的中间件在抢占同一进程的上下文。教训很直接双框架混用一定要做到进程级隔离。Django和Flask分别用不同的进程启动分别监听不同端口中间只通过HTTP协议通信。Django侧不直接依赖Flask的代码Flask侧也不引用Django的ORM这样任何一方升级版本、修改配置都不会连累另一方。同时如果两个服务部署在同一台服务器上记得给它们配置各自的系统服务统一由supervisor或systemd托管哪个挂了自动拉起哪个互不影响。另一个容易踩的问题是Cookie命名冲突。如果Django和Flask共用一个域名和端口务必给Flask配置独立的Session Cookie名称否则两者的sessionid会互相覆盖用户明明登录了Django却提示未认证。我用Flask时在配置里显式指定了SESSION_COOKIE_NAME避免和Django默认的sessionid冲突。4.2 预约高并发超卖与唯一约束冲突超卖问题前面已经给了解决方案但这块在实际上线阶段还会遇到一个衍生问题select_for_update()配合MySQL默认的Repeatable Read隔离级别死锁风险会增加。一个会员连续快速提交两个预约请求两个事务同时锁定不同的排期行可能形成死锁。我的处理策略是在事务里按固定顺序锁定排期行比如先锁排期ID较小的再锁较大的让所有事务遵循同一个顺序可以显著降低死锁概率。同时在应用层给每个会员的预约请求加一个分布式锁同一时刻同一个会员只能发起一个预约请求彻底避免交叉锁定。实际压测下500并发同时预约10个不同课程名额成功率100%没有出现一个超卖也没有出现一次死锁回滚导致用户请求失败。还有一个小问题隐藏得很深用F(booked_count) 1更新人数时如果不配合行锁只是在事务里执行这个更新语句在并发下会覆盖其他人的更新值。正确的顺序一定是先select_for_update锁行再F表达式更新。4.3 体测数据量增长后的查询性能优化上线运营两个月后体测数据表累计了几万条记录会员查询历史趋势时开始出现明显的卡顿。排查后发现问题出在查询条件上原来的查询用WHERE member_id %s ORDER BY created_at DESC但表上没有对应的索引MySQL只能全表扫描后排序数据量一大就慢。解决办法很简单建立联合索引(member_id, created_at)。建立后同样的查询从几百毫秒降到十几毫秒。这里加索引的思路是查询条件里同时存在过滤字段和排序字段时把它们放进同一个联合索引数据库可以直接按索引顺序取数避免filesort。还有一类性能坑藏在统计报表里。运营后台要做“按月统计新会员数量”“按教练统计课时数”这类聚合查询数据量上来以后每次聚合都实时扫描明细表非常浪费。我的做法是把这些统计结果做成每日汇总表用Django自定义Command每天晚上定时跑一次把前一天的数据聚合好存起来运营后台查到的永远是“昨日之前的最新数据”实时性足够性能也完全扛得住。4.4 其他容易踩的坑隐私权限与版本兼容健身房体测数据是非常敏感的个人健康数据我在项目里反复检查了权限控制。体测数据接口一开始写得太宽松只要登录用户传一个会员ID就能查任意会员的体测记录后来压测时发现这个问题冷汗都出来了。现在的规则是会员只能查自己的记录教练只能查授权给自己跟踪的会员记录运营管理员作query全部记录时必须带上门店维度而且所有操作都记录日志。权限这块宁可严格十倍也不能松一个口子。版本兼容方面Django 4.x和Flask 3.x同时存在于一个项目时要特别注意依赖包的版本冲突。比如MarkupSafe这个包早期版本兼容问题导致Flask模板渲染直接报错Django的django-cors-headers和Flask的flask-cors如果都装在同一个虚拟环境还会出现配置读取冲突。我的操作办法是给Django和Flask分别建独立的Python虚拟环境各自维护一份requirements.txt不共用依赖空间。虽然部署脚本复杂了一点但版本隔离带来的稳定性完全值得。回看这套系统最让我满意的不是某个惊艳的算法也不是复杂的并发控制而是整体架构的清晰度。双框架的边界划得很清楚Django管业务Flask管算法两者通过接口通信各司其职。如果当初一股脑全用Django硬扛推荐引擎或者全用Flask硬怼业务模块后期维护都会是灾难。最后分享一个我个人的小体会项目做完以后建议把推荐日志表和体测历史表好好利用起来。我后期优化推荐算法时全靠这两张表的数据做离线分析比如发现会员对某种新课程的上课率明显偏低就赶紧调整推荐权重。系统上线不是终点数据驱动的持续优化才是这套系统真正的价值所在。