1. 项目背景与核心需求拆解我在雪场蹲了三天才动手滑雪场雪具租赁服务系统这个项目最早其实是被一线员工“逼”出来的。我在北方一个中型滑雪度假区做技术顾问时发现租赁部的工作方式还停留在手工台账阶段上午九点到十一点是取板高峰前台同时挤着十几个游客员工一手抄身份证号、一手写租赁单还要翻箱子核对雪鞋尺码。队伍排到门口投诉单也堆了一摞。到了晚上对账单据被风吹乱了几张账目就死活对不平运营经理只能认倒霉自己掏钱补差额。那一刻我就知道这个场景需要一套系统来解决。这里的核心矛盾不是“没有库存记录”而是租赁业务本身具备高频、短周期、强状态流转的特点。滑雪装备不是普通商品卖出去就结束了它要在同一旺季里被不同顾客反复租用每一件雪具都要经历“在库—出租—归还—质检—再出租”的循环。手工方式根本没法跟踪每个环节的单据状态出错只是时间问题。1.1 真正让人头疼的四个业务痛点我蹲点三天整理出租赁业务最核心的四个痛点后续所有设计都围绕它们展开痛点具体表现业务后果库存盲区库管不知道雪具在哪前台不知道是否可租重复出租、设备凭空消失计费争议超时费靠员工口头计算标准不统一顾客纠纷、员工被投诉押金混乱押金收缴和退还无记录单据易丢坏账、赔偿无法追溯状态脱节设备磨损、损坏、送修无跟踪高峰时期故障设备被租出安全隐患前三个是管理问题最后一个是安全问题。滑雪头盔、固定器如果有损伤轻则影响体验重则造成事故。设备状态必须被系统强制管理而不是靠老员工“凭经验看”。1.2 功能需求分层先做能用再做好看我建议所有做这类企业级Python项目的朋友都先做需求分层别拿到需求就建model。我把功能分成三层每层有明确的取舍标准基础层没有就运营不下去雪具信息管理设备编号、类型、尺码、品牌、购入日期、当前状态、磨损度库存实时查询支持按类型、尺码、状态、位置筛选租赁办理选客户、选雪具、算租金、收押金、设归还时间归还办理验收设备、判损、算超时费、退押金、更新设备状态客户管理姓名、电话、身份证号、历史订单、黑名单标记进阶层提升效率、规避风险基于角色的权限管理前台、库管、店长分级订单与流水统计报表大屏看板实时数据展示远期层雪场规模做大后逐步上线小程序在线预约、自助取板RFID或二维码设备追踪对接电子发票与在线支付判断标准很简单没有这个功能现场能不能正常营业不能的就是基础层能缓一缓的就是进阶层。1.3 系统边界明确“不做什么”比“做什么”更重要项目最忌讳的就是云需求。我第一次迭代时明确砍掉了三块内容不做在线支付雪场微信收款码已经够用系统只记录支付方式、不做完整进销存采购和财务归另一个系统管、不做会员积分。把这三块砍掉之后核心开发周期从计划的三周压缩到两周后台开发成本大幅降低。项目边界定清楚以后技术方案也就好选了核心业务交给Django因为它有完整的管理后台、ORM和权限体系另起一个Flask服务只做数据可视化看板轻量、独立、互不干扰。下面详细说说为什么这么定。2. 技术选型Django和Flask不是二选一而是各司其职很多朋友看到标题里又有django又有flask会问这两个框架不都是Python的Web框架吗选一个不就行了我在实际项目里确实两个都用了这不算重复造轮子而是典型的“重业务系统轻量辅助服务”组合模式。2.1 Django扛起核心业务因为这四件事第一ORM和Migrations让表结构演进变得非常顺滑。租赁业务的数据模型一定会在开发期频繁调整比如我在上线前给订单表加过两次字段Django的python manage.py makemigrations直接跟踪字段变化不用手写SQL和改表脚本。第二自带Admin后台等于白送一个管理界面。你可能想不到最后真正高频使用系统的不是程序员的私有界面而是Django自带的admin。运营人员只需要登录后台点一点就能完成大部分雪具管理操作省掉了独立开发管理前端的工作量。第三认证和权限体系是RBAC的地基。雪具租赁涉及押金、退款、价格调整不同岗位能看的和能改的必须严格区分。Django的User、Group、Permission模型天生就支持这种场景我不用从头设计权限表。第四安全能力让人省心。CSRF防护、ORM参数化查询天然防注入表单校验也有成熟的Form组件。这类系统要上线面对真实用户安全层面的东西不能临时补。2.2 Flask为什么还占一个位置雪场管理层需要一个实时看板展示今日出租量、收入、热门雪具型号、超时率这些指标。当时有两种方案一是在Django里加几个视图和API二是独立写一个Flask服务。我选了后者。原因是这个看板本质上是读多写少的展示型服务不需要Admin、不需要权限体系、不需要复杂表单只需要十几个轻量接口和页面。用Flask写代码总量只有二百来行独立进程部署到5000端口不会影响Django主服务的稳定性。即便看板服务挂了前台租赁操作也不受任何影响。这里有个通用判断标准如果你的辅助功能需要读写同一批业务数据、需要和主系统做复杂联动那就老老实实放在Django里如果只是读统计结果、做展示拆出来用Flask非常合适。2.3 项目目录结构长这样snow_rental/ ├── manage.py ├── config/ # Django主配置 │ ├── settings.py │ ├── urls.py │ └── wsgi.py ├── rental/ # 租赁业务主应用 │ ├── models.py # 雪具、客户、订单、明细、日志 │ ├── services.py # 业务服务层处理租赁/归还事务 │ ├── views.py # 视图层 │ ├── admin.py # Admin后台配置 │ └── urls.py ├── stats/ # 统计报表相关 ├── static/ # 静态资源 ├── media/ # 客户头像、雪具图片 └── dashboard/ # 独立Flask服务 ├── app.py # Flask入口 ├── templates/ └── static/开发时我用了vscode调试Django和Flask都很顺手。如果你是从零开始先把Python环境配好建议用venv或conda创建独立解释器不要装系统全局不然项目一多包版本冲突会让人崩溃。3. 数据模型设计把雪具当成“有状态的资源”而不是普通商品这是整个项目最核心的建模思路。雪具和普通商品有个本质区别普通商品库存只需要一个数量字段但雪具每一件都是独立的、需要被追踪状态的资源。一套滑雪板从“在库”到“已租”再到“磨损待修”状态一直在变数据建模必须能表达这种变化。3.1 五张核心表一次说清楚我用Django的ORM设计了五张表基本覆盖了租赁业务的所有环节Equipment 雪具表每件设备一条记录哪怕同型号同尺码也各自有独立编号。字段包括equip_no设备编号唯一例如SB-A-2023-0001代表2023年采购的成人单板equip_type类型用choices例如单板、双板、雪鞋、头盔、护目镜、雪杖、滑雪服size尺码brand_model品牌型号purchase_date购入日期status状态包括available、rented、repair、damagedwear_level磨损程度1到5的整数5表示严重磨损Customer 客户表存储游客基本信息手机号加索引作为查询主键。重点维护一个blacklist字段用来标记有恶意损坏历史或经常超时失联的顾客。RentalOrder 租赁订单表一笔订单对应一个客户可以包含多件雪具。字段包括订单号、客户外键、订单总金额、押金总额、订单状态、预计归还时间、实际归还时间、操作员。订单状态设计为四种draft草稿、active租赁中、settled已结算、cancelled已取消。RentalOrderItem 订单明细表订单和雪具多对多的关联表。为什么不能直接在订单表上存一个雪具ID因为一家人来滑雪往往同时租板子、雪鞋、头盔、滑雪服如果每个雪具生成一单押金和超时费就会拆散前台操作复杂、顾客体验也差。所以用明细表接收订单下的多件雪具。这个设计参考了很多电商下单系统的做法。EquipmentLog 设备操作日志表记录每件设备每一次“出租”和“归还”的流转包含设备外键、订单外键、操作类型、操作员、时间戳、备注。这张表是审计和故障追责的关键我在后文还会提到。这五张表互相之间的关系可以用一个简单的逻辑串起来客户创建订单订单包含多条明细每条明细对应一件具体雪具每次状态变更都留下日志。3.2 状态机设备生命周期管理的核心雪具的状态字段我用了一个状态机来约束而不是随便改。核心状态转换只有四条合法路径available在库 → rented已租出rented已租出 → available正常归还rented已租出 → repair归还后送修rented已租出 → damaged归还时判定损坏为什么要这么严格因为我在实际运营中发现如果没有状态机约束库管员很容易把一件已经预留给下一个客户的设备直接填成可用造成重复出租。状态机可以通过Django的clean()方法或服务层校验强制限制非法跳转直接拦截并报警。3.3 计时与计价逻辑的字段设计计价逻辑是租赁系统的敏感地带。我的方案是在订单表上存储rate_type计价方式和base_amount基础金额归还时再根据实际时长计算超时费。具体逻辑是按小时租用的设备起步价包含前2小时超出部分按30分钟或1小时计费按天租用的设备一般在当天营业时间内归还超过营业时间自动计入夜间套餐押金按设备类型差异化设置头盔押金比例低高级雪板和雪服押金比例高这些规则不写死在代码里而是做成配置项存数据库或配置文件方便雪场在淡旺季调整价格。这一点很重要我在第四节实现部分会给出具体代码。4. 核心流程实现租赁和归还的完整代码链这一节是干货重点。我把租赁和归还两条主流程的代码链路完整展示出来。实际开发时把业务逻辑放在服务层services.py而不是视图层这样Django的admin、后续增补的API接口都能复用同一套事务逻辑。4.1 租赁下单流程十五分钟内完成从选设备到出单下单接口接收两类参数一个客户手机号一个设备编号列表。整个流程用事务包裹要么全部成功要么全部回滚from django.db import transaction from decimal import Decimal from .models import Equipment, RentalOrder, RentalOrderItem, EquipmentLog transaction.atomic def create_rental_order(customer_obj, equip_no_list, operatorNone): # 1. 逐个校验设备状态 equips Equipment.objects.select_for_update().filter(equip_no__inequip_no_list) for equip in equips: if equip.status ! available: raise BusinessError(f设备 {equip.equip_no} 当前状态为{equip.get_status_display()}不可出租) # 2. 创建订单 order RentalOrder.objects.create( customercustomer_obj, order_nogenerate_order_no(), statusactive, operatoroperator, ) # 3. 创建订单明细同时计算价格 for equip in equips: price calc_rental_price(equip) # 按设备类型当前季节定价 deposit calc_deposit(equip) # 按类型差异化押金 RentalOrderItem.objects.create( orderorder, equipequip, unit_priceprice, depositdeposit, ) # 4. 锁定设备状态防止被下一单重复选择 equips.update(statusrented) # 5. 写操作日志 for equip in equips: EquipmentLog.objects.create( equipequip, orderorder, actionout, operatoroperator, ) return order这里我用了select_for_update()这个处理非常关键。它的作用是在事务内对符合条件的行加数据库锁。什么意思呢假设两个前台员工同时点了同一副雪板的出库按钮没有锁就会导致两个订单都显示成功雪板被重复租给两个顾客。加上行级锁后第二个事务会等待第一个事务提交然后再核对状态发现设备已变为rented就会抛出业务异常提示“设备已被租出”。4.2 归还结算流程超时费计算与状态变更归还流程比租赁更复杂因为它涉及超时计费、损耗判定、押金退还三个动作。核心代码如下transaction.atomic def settle_rental_order(order_no, damage_mapNone): order RentalOrder.objects.select_for_update().get(order_noorder_no) if order.status ! active: raise BusinessError(该订单不是租赁中的状态) total_surcharge Decimal(0) for item in order.items.select_related(equip): equip item.equip # 1. 计算超时费用 overdue_hours calc_overdue_hours(order.due_at, timezone.now()) total_surcharge overdue_hours * item.unit_price # 2. 处理设备状态有损坏则进入damaged否则回可用 if damage_map and damage_map.get(equip.equip_no): equip.status damaged equip.wear_level min(equip.wear_level 1, 5) else: equip.status available equip.save() # 3. 写归还日志 EquipmentLog.objects.create( equipequip, orderorder, actionreturn, operatororder.operator, remarkdamage_map.get(equip.equip_no, ), ) order.total_amount total_surcharge order.status settled order.actual_return_time timezone.now() order.save() return order归还时最常被忽略的是“损耗登记”。我们规定当wear_level达到4或5设备自动进入repair状态不可直接出库。这个规则纯靠员工自觉不可靠于是我在save()方法里加了一行判断在模型层强制兜底class Equipment(models.Model): def save(self, *args, **kwargs): if self.wear_level 5: self.status repair super().save(*args, **kwargs)4.3 Django查询与删除对象时的两个坑Django的CRUD操作大家都会但业务系统里藏了两个易错点。第一个坑是删除订单明细时的级联行为。如果你直接item.delete()外键关联的日志表和订单汇总不会自动清理金额就会对不上。我的经验是业务数据尽量不物理删除而是通过状态字段标记为cancelled。要删除设备时也同理宁可改为retired状态也不能直接删记录否则历史订单的统计报表会缺口。第二个坑是查询性能。Django的查询如果被ORM偷懒很容易产生N1查询问题例如在循环里访问item.equip每取一次就多发一条SQL。解决方式是配合select_related或prefetch_related一次性加载关联数据上面归还结算的代码就用了.select_related(equip)门店高峰期一单几十条明细的查询速度能快一个数量级。5. 权限管理用Django自带的RBAC改造出四类角色租赁服务系统的权限管理不是花架子。前台能操作租赁订单但不能改设备采购价和押金比例库管只能管理雪具和设备状态不应该看营业收入店长要能看到所有数据还要能手动调整异常订单。这里我用Django自带的Group和Permission实现了一套轻量RBAC没有引入第三方权限库够用且稳定。5.1 权限矩阵先期画清楚功能模块前台库管店长创建租赁订单是否是办理归还是是是录入/编辑雪具否是是调整租金押金否否是查看收入报表否否是黑名单管理否否是画完这个矩阵之后权限设计就一目了然了。Django的Group天然适合做这种固定角色的权限体系我建了三个组然后把每个功能模块的增删改查权限分别挂到对应组上。5.2 自定义权限的添加方式Django的AbstractUser自带的权限模型默认覆盖add/change/delete/view四类模型级权限。但实际业务里像“调整价格”这种操作不是针对某个模型的增删改而是一种业务动作。我会在模型Meta里自定义权限class Equipment(models.Model): ... class Meta: permissions [ (adjust_price, Can adjust equipment rental price), (manage_inventory, Can manage equipment inventory), ]然后在设置里执行python manage.py makemigrations和migrate权限就会出现在Django的权限表里。给组赋权之后在视图上直接加装饰器from django.contrib.auth.decorators import permission_required permission_required(rental.adjust_price, raise_exceptionTrue) def adjust_price_view(request): ...raise_exceptionTrue的作用是无权限时直接返回403而不是静默跳转到登录页方便前台提示用户联系店长。5.3 一个容易忽略的权限设计细节Django内置权限是模型级的颗粒度比较粗。比如“库管可以编辑雪具”但是编辑和删除实际上是两个权限需要分别授权。这带来一个问题如果权限矩阵漏配某些页面的按钮会对不该看到的人展示。我的处理方案是结合模板权限控制在页面上动态显隐操作按钮例如{% if perms.rental.adjust_price %} a href/rental/price/{{ item.id }}/调整价格/a {% endif %}这种“后端权限强制校验前端按钮显隐”的双重配合是我在真实项目里强烈推荐的做法。只做前端隐藏不做后端校验等于把权限当装饰品只做后端不做前端操作员会一直点错按钮体验非常差。6. Django Admin后台的实用定制方案我见过很多团队一上来就订制独立前端后台结果迭代了两周连基础功能都没做完。个人经验是在小团队和垂直业务场景里Django自带的admin是非常好的默认可选方案只有到了角色复杂、交互要求很高的阶段才需要重写前端。6.1 我如何配置admin让运营人员顺手运营人员不是程序员admin要尽量做到“少输入、多点选、能搜索、能看状态”。下面这段配置基本够用admin.register(Equipment) class EquipmentAdmin(admin.ModelAdmin): list_display (equip_no, equip_type, size, status, wear_level, get_rented_order_no) list_filter (equip_type, status, wear_level) search_fields (equip_no, brand_model) ordering (-purchase_date,) list_editable (status,) def get_rented_order_no(self, obj): item obj.rentalorderitem_set.filter(order__statusactive).first() return item.order.order_no if item else get_rented_order_no.short_description 当前租赁单号关键技巧有三个list_editable (status,)可以直接在列表页下拉修改设备状态不用点进详情页库管盘点时效率极高search_fields带上品牌和编号前台接到顾客电话说“上次租的那副绿板子”也能快速检索list_filter按状态和类型筛选配合雪具数量大时的大列表分页后台体验稳定6.2 订单明细使用Inline方式订单在admin里展示时我会用TabularInline把明细嵌在订单详情里这样店长查看一笔订单时能看到这个订单包含了哪几件雪具、各自的租金和押金非常直观class RentalOrderItemInline(admin.TabularInline): model RentalOrderItem extra 0 readonly_fields (equip, unit_price, deposit) admin.register(RentalOrder) class RentalOrderAdmin(admin.ModelAdmin): inlines [RentalOrderItemInline] list_display (order_no, customer, total_amount, status, created_at, due_at) list_filter (status,)把关键业务字段设为readonly能有效防止前台误改价格。价格只能通过权限分配给店长的账号进行调整这也是RBAC在管理后台的具体落地。7. 部署实战与踩坑记录从开发机到Linux服务器这个项目最终要部署到雪场机房的一台Linux服务器上而不是只在本地跑通。部署过程里我踩了不止一个坑其中最典型的是静态文件404问题。很多朋友问“vscode里写了img标签放到django的static目录里为什么就是显示不出来”下面逐一拆解。7.1 静态文件配置的完整解药Django静态文件显示不出来的根因90%是STATIC_URL、STATICFILES_DIRS、STATIC_ROOT这三个变量没配清楚。我的配置如下# settings.py STATIC_URL /static/ STATICFILES_DIRS [BASE_DIR / static] # 开发时查找的目录 STATIC_ROOT BASE_DIR / collect_static # collectstatic后汇总的目标目录开发模式下Django的开发服务器会按STATICFILES_DIRS去找静态文件生产模式下需要先执行一次python manage.py collectstatic把所有app里的静态文件收集到STATIC_ROOT再交给Nginx处理。如果你只配置了STATICFILES_DIRS但没执行collectstatic或者Nginx的root指向了错误的目录线上页面就会大量404。7.2 Linux服务器部署的完整步骤服务器是Ubuntu 22.04Python版本我用了3.10。这里直接给出我当时的部署命令序列# 1. 安装Python及相关编译依赖 sudo apt update sudo apt install python3.10 python3.10-venv python3-pip nginx supervisor # 2. 创建虚拟环境并安装依赖 python3.10 -m venv /opt/snow_rental/venv source /opt/snow_rental/venv/bin/activate pip install -r requirements.txt # 3. 迁移数据库与收集静态文件 python manage.py makemigrations python manage.py migrate python manage.py collectstatic --noinput # 4. 用gunicorn启动Django服务 gunicorn config.wsgi:application \ --workers 3 \ --bind 127.0.0.1:8000Nginx反向代理配置如下server { listen 80; server_name your_domain.com; location /static/ { alias /opt/snow_rental/collect_static/; } location /media/ { alias /opt/snow_rental/media/; } location / { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }然后我用supervisor守护gunicorn进程配置大概三分钟搞定开业到现在重启过两次服务都比较稳。7.3 Flask服务部署时的两个常见坑Flask看板服务部署相对简单但有一个坑值得特殊说明附件和资源文件的路径问题。我在Windows开发机上跑得好好的部署到Linux之后发现图片上传全部失败。排查半天才发现问题出在代码里用了硬编码的绝对路径比如D:\\snow_rental\\media\\...到了Linux环境自然找不到目录。解决办法是在统一定义一个基于项目根目录的动态路径不要用绝对路径。我改成BASE_DIR / media这种带pathlib的写法两个框架统一维护一个资源路径工具模块问题彻底解决。另一个坑是Flask服务在生产环境关掉debug后页面没有按预期渲染。排查发现是因为我把首页逻辑和app.route定义放得太散Flask在非debug模式下对静态文件的处理机制不一样。建议Flask生产环境部署时严格使用gunicorn或uwsgi绑定WSGI协议而不是直接用app.run()裸跑。8. 轻量可视化看板Flask ECharts展示雪场租赁数据管理层在办公室隔三差五就要问“今天租了多少板子”“这个月流水多少”。数据可视化是刚需。我用Flask写了一个独立看板服务再配合前端ECharts画图二三百行代码就把“租赁数据的实时概况”变成了清晰的大屏展示。8.1 Flask读取汇总数据而不是直接查业务表看板服务部署在Django主服务旁边独立运行在5000端口。为了避免两个服务同时写操作数据库导致冲突我让Flask只读取一张专门的统计汇总表这张表由Django的定时任务每小时更新一次。核心代码如下from flask import Flask, render_template, jsonify import sqlite3 app Flask(__name__) app.route(/api/daily_stats) def daily_stats(): conn sqlite3.connect(/opt/snow_rental/data/stats.db) cur conn.cursor() cur.execute(SELECT date, rent_count, income FROM daily_stat ORDER BY date DESC LIMIT 30) rows cur.fetchall() return jsonify([{date: r[0], rent_count: r[1], income: r[2]} for r in rows])8.2 前端展示前端页面读取这个接口用ECharts画折线图。看板还做了一张“出租率TOP10雪具型号”柱状图店长一眼就能看出哪款单板最抢手提前和采购沟通补货。div idchart styleheight: 400px;/div script src/static/echarts.min.js/script script fetch(/api/daily_stats) .then(res res.json()) .then(data { const chart echarts.init(document.getElementById(chart)); chart.setOption({ xAxis: { type: category, data: data.map(d d.date) }, yAxis: { type: value }, series: [{ type: line, data: data.map(d d.rent_count) }] }); }); /script8.3 跨域与端口协调Django主系统跑在8000端口Flask看板跑在5000端口。如果前端直接访问另一个端口会遇到跨域问题。最省心的两个方案一是在Nginx层把两个服务统一挂在同一个域名的不同路径下例如/rental/api转到Flask/转到Django二是给Flask渲染的服务端模板直接读数据浏览器只访问Flask自身域名不存在跨域。我采用了第二种Flask用服务端模板把每日统计数据渲染成HTML前端图表只需要引用Flask自身的API整体网络请求干净利落部署也少一个路由配置。9. 上线三个月后的复盘与扩展规划系统上线后的第一个雪季每天平均处理两百多笔租赁订单盘点准确率从手工时代的85%提升到99.5%高峰期前台办理效率从三分钟一单压缩到一分钟以内。不过复盘过程中我也发现了一些最初没考虑到的实际问题写出来供大家参考。9.1 实际运营中暴露的三个问题第一个问题是高峰期还排队的核心瓶颈不在系统而在取板位置设计。系统把前端办理速度提高了但游客还是得挤在一个狭窄柜台前等待拿设备。后来我建议把“线上预选线下确认”的流程加进去顾客在前一天晚上通过管理后台或客服电话完成预选第二天直接到专门窗口取板高峰期拥堵问题基本解决。第二个问题是设备损耗的分析维度不够。系统记录了work_level但没有和雪具的累计使用次数、归还超时频次做交叉分析。没有数据分析采购和维修决策就只能拍脑袋。下一步我准备在EquipmentLog基础上增加更细的汇聚表让老板能看到“单板SB-A-2023-11已经累计租出127次磨损度4建议退役”。第三个问题是异常单的处理流程偏手工。比如顾客把雪板忘在餐厅或者到时间没归还联系不上目前还是靠店长手动改状态。后续准备加一套“逾期未还自动报警”的逻辑如果订单超过预计归还时间两小时且没有结算系统自动给运维发短信提醒这块正好可以用Django自带的定时任务实现。9.2 可以继续扩展的方向扩展方向有三个小程序在线预约顾客微信扫码选雪具、付押金到店直接扫码取板流程全程线上化接入RFID给每件雪具贴RFID标签进出库自动被感应器捕获设备流转实时入场更精细的价格策略淡旺季、节假日动态调价甚至对接天气数据雪量大时自动提高预订热度9.3 一点个人体会做这类Python管理系统技术难点往往不在框架本身而在于把业务约束准确地落到代码里。租赁流程里大量的“如果超时怎么办”“如果设备损坏怎么办”都需要在设计阶段用状态机、事务、权限去约束好。先把需求边界划清楚再把数据模型和状态流想透最后写代码反而是最顺手的一步。如果你手头也在做滑雪场、健身房、乐器行这类租赁型业务系统我的建议是先按这个思路搭出第一版Django管业务Flask做辅助看板Admin先挡住80%的管理需求。跑通一两个雪季你自然就知道下一步该往哪个方向优化。这套架构足够为中型雪场平稳运营也可以直接迁移到其他类似的租赁场景里去复用。
