最近我在帮一个精品民宿品牌打磨一套基于 Flask Vue 的预订管理系统从前端页面到后端接口再到最后的服务器部署前后花了大半个月时间。这套系统的定位很明确民宿不再是传统的“开个房间等客人上门”而是要在小红书、抖音上做内容运营客人刷到视频后直接在小程序或网页上下单所以对页面颜值、下单流畅度、房态实时性要求都很高。我用的技术栈是 Flask 做后端接口Vue 做前端交互PyCharm 作为开发环境期间还对比过 Django 方案最后为什么选了 Flask中间踩了什么坑这篇文章一次性讲清楚。无论你是要做毕业设计还是想给朋友的民宿搭建一套完整的预订系统又或者单纯想学 Flask Vue 这套前后端分离的实战组合这篇内容都值得认真看一遍。我会把项目从需求分析、数据库设计、接口实现、前端联调到最后的部署上线完整过一遍重点讲那些网上教程不会细说的选择和取舍。1. 项目定位与整体技术选型1.1 网红民宿预订系统到底要管什么很多人一听“民宿预订系统”第一反应就是“这不就是一个酒店订房系统换个皮吗”。真做起来完全不是这么回事。酒店是标准化房间管理民宿强调的是“房型 日期 特色体验”的组合而且网红民宿的运营模式决定了系统要扛住几个特殊的场景。首先是时段和库存的逻辑。民宿一个房源往往只有几个房型每个房型可能一共就两三间网红民宿旺季时一个日期会有大量用户同时来抢房。系统必须把“当天还剩几间”这个数字做准不能让两个用户下同一个房间的单。其次是展示内容的丰富程度。客人是被短视频吸引来的所以房型信息里一定要有轮播图、视频链接、周边介绍、入住须知这些内容板块比起普通酒店系统的“房型价格”要复杂很多。还有一个很容易被忽略的需求民宿老板自己要用它做运营。所以系统里除了给客人用的小程序端/网页端还要有一套完整的管理后台——管理民宿信息、更新房态、查看订单、处理退改、甚至统计哪个渠道带来的订单多。我之前见过不少项目把前台做得花里胡哨后台就一个简陋表格结果民宿主每天要手动在 Excel 里对账这肯定是不合格的。这套 Vue Flask 的项目最终拆成了三块vistor 端负责注册登录、浏览民宿、查看房态和提交订单admin 端负责民宿/房型维护、订单管理、价格设置后端统一由 Flask 提供 RESTful API 接口前端拿到 JSON 数据渲染页面。这种前后端分离的结构好处是以后想加小程序端可以直接复用同一套接口不用重新开发。1.2 Flask 与 Django 之争这次我为什么选 Flask技术选型是项目开始前最纠结的一步。标题里同时出现 Flask 和 Django其实背后是我真实的犹豫过程。Python 做 Web 后端主流就这两条路Django 全家桶和 Flask 微型框架。先说说 Django。Django 自带 ORM、Admin 后台、模板系统、认证系统可以说“什么都有”。如果是一个人单干、时间紧张、业务又比较传统Django 确实能省不少事。尤其它的 Admin 后台只要把 models 定义好自动就有一套可用的增删改查界面拿来给民宿老板做简单的数据管理绰绰有余。但 Flask 的优势在“轻”和“灵活”。它是一个微框架只保留了路由、请求响应处理、模板渲染这些核心功能ORM、表单、登录验证这些全都自由选择。恰恰是这种自由度让 Flask 在前后端分离的项目里反而比 Django 更顺手。因为我们的前端是 Vue负责页面渲染后端只需要纯粹返回 JSON 数据Django 自带的模板系统和 Admin 后台基本用不上反而成了冗余。而 Flask 写 API 的时候思路非常干净一个装饰器对应一个接口一个函数对应一份 JSON 响应新手看代码也一目了然。我做选型时列过一个对比表这里也分享给大家参考对比项FlaskDjango上手成本低一个文件就能跑起来中高需要理解项目结构和配置ORM默认无可用 SQLAlchemy内置 ORM功能完善自带后台无有可以快速搭建管理界面接口开发自由灵活轻量基于视图和序列化规范但重适合场景API 服务、微服务、前后端分离传统 Web 站点、全栈快速迭代最终定下来的方案是 Flask SQLAlchemy Vue再用 PyCharm 做 IDE 统一管理前后端项目。后面我会用实际代码说明这个组合写民宿预订这种中等规模的系统代码量远没有想象中多而且每行代码是什么作用自己心里清清楚楚。1.3 PyCharm 在整套开发流程里的真实角色聊完 Flask 和 Django必须专门说说开发工具。很多新手喜欢问“用 PyCharm 还是 VS Code”我的答案是如果你主要在写 PythonPyCharm 依然是综合体验最好的选择尤其在 Flask 项目这种需要频繁调试接口的场景下。PyCharm 有几个功能是这个项目里真正帮到我的。第一是 Flask 的 Run Configuration新建一个 Flask Server 配置指定 app.py 的路径和环境变量点击运行就能直接在 IDE 里启动服务配合 Debugger 可以给每一行 Python 代码打断点请求过来时变量值一览无余。第二是 Database 工具面板可以直接连上 SQLite 或 MySQL 数据库查看表结构、执行自定义 SQL特别适合调试订单数据异常。当然也有需要吐槽的地方。PyCharm 对前端文件的支持比专业前端 IDE 要弱一些Vue 单文件组件的高亮和自动补全不如 WebStorm 或 VS Code 顺手。我的习惯是 PyCharm 负责后端 FlaskVue 前端用 PyCharm 打开当作普通项目写如果遇到特别复杂的组件会临时用 VS Code 补一下。但整个项目管理、git 提交、数据库调试、后端断点全部集中在 PyCharm 里这对全栈开发来说是最高效的模式。还有一个很实用的功能是 HTTP Client。PyCharm 专业版自带 .http 文件直接在 IDE 里模拟 GET、POST 请求不用每次打开 Postman 或 ApiPost。我开发接口时写完一个接口就写一个测试请求方便后面反复验证。2. 数据库设计与后端实现2.1 核心数据模型用户、民宿、房型、订单项目要稳定跑起来数据库设计是地基。网红民宿系统里最核心的实体有四个User 用户、Homestay 民宿、RoomType 房型、Order 订单。再加上一些辅助表比如轮播图、民宿评论、价格日历。先看用户表。除了常规的 id、username、password_hash、phone、avatar我还加了 role 字段用来区分普通游客和管理员。这样前后台登录就可以共用一个用户体系管理员登录后跳转到管理页游客登录后正常浏览下单。密码存的一定是哈希值不是明文用 werkzeug 自带的 generate_password_hash 就能实现。民宿表是整个系统的“门面”字段设计要考虑前台展示的需求。我最终的字段包括 id、name、description、cover_image、images_json、videos_json、city、address、facilities_json、status、create_time。其中 images_json 和 videos_json 我直接用 JSON 字符串存图片和视频链接列表增删改查时序列化和反序列化即可。说实话存 JSON 在关系型数据库里不够“学院派”但实际开发中它非常实用尤其是民宿的图片数量、视频数量不固定拆成多张表反而给自己添麻烦。房型表是订单和库存的关键。一个民宿对应多个房型每个房型有 id、homestay_id、type_name、price、original_price、stock、bed_count、area、amenities_json。这里的 stock 是“这个房型的可售间数”也就是每天有多少间房。价格字段我只放了一个基础价格字段因为很多民宿是一天一价我单独建了一张 price_calendar 表来存特殊日期价格日期为粒度存这个房型在某天的价格。订单表是整张表里最容易出问题的。核心字段是 id、order_no、user_id、homestay_id、room_type_id、check_in_date、check_out_date、nights、total_price、status、create_time。订单号用时间戳加随机数生成不用自增 id 对外展示因为业务上经常需要按订单号查找而且自增 id 暴露给用户也不安全。下单时的核心逻辑是检查所选日期范围内该房型每天的剩余库存是否充足如果充足则扣减库存并生成订单。下面是我实际使用的 SQLAlchemy 模型片段做了一个精简版from flask_sqlalchemy import SQLAlchemy from datetime import datetime db SQLAlchemy() class RoomType(db.Model): __tablename__ room_type id db.Column(db.Integer, primary_keyTrue) homestay_id db.Column(db.Integer, db.ForeignKey(homestay.id)) type_name db.Column(db.String(64), nullableFalse) price db.Column(db.Numeric(10, 2), nullableFalse, default0) stock db.Column(db.Integer, nullableFalse, default1) # 其他字段省略 class Order(db.Model): __tablename__ order id db.Column(db.Integer, primary_keyTrue) order_no db.Column(db.String(32), uniqueTrue, nullableFalse) user_id db.Column(db.Integer, db.ForeignKey(user.id)) room_type_id db.Column(db.Integer, db.ForeignKey(room_type.id)) check_in_date db.Column(db.Date, nullableFalse) check_out_date db.Column(db.Date, nullableFalse) total_price db.Column(db.Numeric(10, 2), nullableFalse) status db.Column(db.String(16), defaultpending) # pending/paid/canceled/finished create_time db.Column(db.DateTime, defaultdatetime.now)2.2 从 Flask 应用工厂到蓝图路由拆分刚开始学 Flask 的时候大家都习惯把所有的路由写在一个 app.py 文件里。这个项目刚开始我也这样干但写到第十个接口时就发现不行了文件越来越长改一个接口要上下翻半天。后来我果断引入了蓝图和工厂模式把项目按功能模块拆开。应用工厂的好处是可以在不同环境创建不同配置的 app 实例。开发环境和生产环境的配置差别很大比如数据库地址、密钥、调试开关如果这些在代码里写死部署时就要改代码。我用一个 create_app 函数来加载配置def create_app(config_name): app Flask(__name__) app.config.from_object(config_map[config_name]) db.init_app(app) # 注册蓝图 from app.routes.user import user_bp from app.routes.homestay import homestay_bp from app.routes.order import order_bp app.register_blueprint(user_bp, url_prefix/api/user) app.register_blueprint(homestay_bp, url_prefix/api/homestay) app.register_blueprint(order_bp, url_prefix/api/order) return app上面的代码把接口按业务模块分成了 user、homestay、order 三个蓝图每个蓝图在独立的 Python 文件里维护自己的路由和视图函数。这样带来了非常直接的好处前端哪块出问题了后端直接去对应模块找接口即可不需要在整份代码里翻。路由设计方面我坚持 RESTful 风格用资源名加 HTTP 方法表达语义。比如获取民宿列表是 GET /api/homestay/list创建订单是 POST /api/order/create更新订单状态是 PUT /api/order/status。这里要提醒一点RESTful 的“规范”是给开发者看的不要为了追求完美而陷入过度设计。这个项目的核心是业务跑得通接口清晰、好维护比强行 RESTful 更重要。2.3 登录鉴权JWT 方案落地细节民宿预订系统肯定有用户体系登录鉴权躲不开。这里有很多选择Flask-Login 管理 session或者用 JWT 做无状态鉴权。这个项目我选了 JWT原因很简单前端是 Vue SPA页面跳转不经过后端模板渲染用 cookie 和 session 需要额外处理跨域和安全问题而 JWT 只要前端在每个请求头上带上 token 即可后端一验身份清清楚楚。JWT 的实现不复杂核心是加解密和中间件校验。我用的 PyJWT 库生成 token 时把用户 id、用户名放进 payload再设置一个有截止时间的过期时间。解密时把 token 从请求头的 Authorization 字段里取出来验证签名和有效期验证通过就拿到当前用户。我在项目里封装了一个 auth_required 装饰器在需要登录的接口上面直接标注非常简洁import jwt from functools import wraps from flask import request, jsonify SECRET_KEY your-secret-key-here def generate_token(user): payload { user_id: user.id, username: user.username, exp: datetime.utcnow() timedelta(hours12) } return jwt.encode(payload, SECRET_KEY, algorithmHS256) def auth_required(f): wraps(f) def wrapper(*args, **kwargs): token request.headers.get(Authorization, ) if not token: return jsonify({code: 401, msg: 未登录}), 401 try: payload jwt.decode(token, SECRET_KEY, algorithms[HS256]) request.user_id payload[user_id] except jwt.ExpiredSignatureError: return jsonify({code: 401, msg: 登录已过期}), 401 except Exception: return jsonify({code: 401, msg: token无效}), 401 return f(*args, **kwargs) return wrapper这里有几个细节值得提。第一秘钥一定要放在配置文件里不要明文写在代码中。第二token 的有效期不要设太长12 小时比较合适前端可以配合拦截器在返回 401 时自动跳转到登录页。第三如果你对安全性要求更高可以用 refresh token 机制但作为民宿预订管理系统简单有效的单 token 方案已经足够。登录接口除了返回 token我还会返回用户基本信息如头像、昵称、角色。前端拿到后可以立刻在页面上展示当前登录状态。密码的加密用 werkzeug.security 工具这里不再重复。3. Vue 前端实战与联调3.1 环境准备Vue 实例创建与依赖安装后端接口有了前端就是另一个大活。现在做 Vue 项目我默认用 Vue 3 Vite因为 Vite 的启动速度和热更新体验比之前的 webpack 时代好太多了尤其在大型页面切换时几乎是秒级响应。环境搭建的完整流程是先检查 Node.js 版本建议 16 以上然后使用 npm 或 pnpm 创建项目。我习惯用 pnpm它安装依赖速度更快也更省磁盘空间。# 创建 vue 项目 npm create vitelatest homestay-frontend -- --template vue cd homestay-frontend npm install # 核心依赖 npm install axios vue-router4 pinia项目创建后需要马上规划目录结构。我的前端不整那些花里胡哨的分层用最直观的方式src/views 放页面组件src/components 放公用组件src/api 放接口请求模块src/router 放路由配置src/store 放全局状态。民宿相关页面主要有首页民宿列表、民宿详情页、订单确认页、个人中心、登录注册、管理后台等。这里说一下 Vue Router 和状态管理的选型。Vue 3 生态下路由用 vue-router 4 是标配状态管理我用 Pinia它是 Vue 官方推荐的新一代状态管理库比 Vuex 更简洁。在民宿预订场景里Pinia 主要存用户的登录态信息和购物车式的临时订单信息比如用户从详情页选好日期人数跳转到确认页时中间参数用一个 store 传递比 URL 传参可靠得多。还要特别提醒如果你的 Node.js 是老旧版本创建 Vue 项目时大概率会报错建议先更新 Node 到最新 LTS 版本再执行上面的命令否则各种依赖版本冲突会让人崩溃。3.2 页面结构拆解首页民宿列表、详情页、下单组件前端页面是用户直接感受的“门面”尤其对网红民宿颜值就是竞争力。我的首页设计思路是顶部搜索栏 民宿卡片瀑布流。民宿卡片用漂亮的封面图做主视觉房型名、价格、标签如“落地窗”“浴缸”“近地铁”用简洁的小卡片展示。Vue 的列表渲染配合后端返回的数据几乎不用写复杂的 DOM 操作代码。先说民宿列表页面。页面挂载后调用 api 模块里的方法去拉取数据拿到数组数据后用 v-for 渲染。整个过程如果不用任何框架原生 JS 写起来会非常繁琐而 Vue 的响应式机制让数据变化自动驱动视图更新。我用的是组合式 API 写法逻辑更集中script setup import { ref, onMounted } from vue import { getHomestayList } from ../api/homestay const homestays ref([]) const loading ref(true) const fetchList async () { try { const res await getHomestayList() homestays.value res.data } finally { loading.value false } } onMounted(fetchList) /script详情页是整个预订流程中最关键的页面。要展示民宿介绍、房型列表、图片轮播、日历选房。日历选房如果自己从零写非常费时间我直接用了一个轻量日期组件设置最小可选日期为今天最大预订日期为 90 天后。用户选择入住日期和离店日期后前端要实时计算入住晚数和总价。计算逻辑是先拿到该房型的基础价格再检查是否有该日期段的特殊价格覆盖前端只用一个估计价格显示给用户最终价格由后端在下单接口中根据价格日历计算保证准确性。下单流程的用户体验也做了几个细节优化。比如在列表页用户点“立即预订”时如果还没登录会先跳登录页并带上 redirect 参数登录成功后自动跳回原页面提交订单时按钮置灰防止重复点击下单成功后弹出订单详情展示订单号、入住日期和总金额用户点击“去支付”跳转到模拟支付页面。这些细节在真实运营中直接影响转化率开发时值得多花时间打磨。3.3 axios 封装与跨域问题处理前后端分离开发必然遇到两个问题接口请求的重复代码如何封装以及跨域问题如何解决。axios 封装是我在前言阶段就完成的工作。我在 src/api 目录下建了一个 request.js配置 axios 实例的 baseURL并在请求拦截器里自动从本地存储取出 token加到请求头中。响应拦截器里统一处理后端返回的 code如果遇到 code 是 401未登录或 token 过期自动清除本地登录状态并跳转到登录页。这样业务代码里只需要专注处理正常逻辑不需要每个接口都写一遍错误判断。import axios from axios import router from ../router const request axios.create({ baseURL: /api, timeout: 10000 }) request.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers.Authorization token } return config }) request.interceptors.response.use( response response.data, error { if (error.response error.response.status 401) { localStorage.removeItem(token) router.push({ name: login }) } return Promise.reject(error) } ) export default request跨域问题在开发阶段几乎必现。前端跑在 Vite 默认的 5173 端口后端 Flask 跑在 5000 端口浏览器会拦截跨域请求。解决办法很简单开发环境在 Vite 配置代理让请求转发到后端生产环境把前端打包后的静态文件交给 Nginx 托管再由 Nginx 反向代理到后端接口。Vite 的配置如下// vite.config.js export default defineConfig({ server: { proxy: { /api: { target: http://127.0.0.1:5000, changeOrigin: true } } } })有些朋友喜欢在后端启用 CORS 来解决跨域比如装 Flask-CORS 库。我的经验是开发阶段 CORS 可以用但生产环境最好以 Nginx 反向代理为主。原因很简单反向代理的方式可以隐藏后端真实地址同时规避 CORS 预检请求带来的额外开销整体更稳。4. 开发调试与问题排查4.1 PyCharm 下的调试技巧这个项目开发周期里我用 PyCharm 的断点调试定位了至少十几个 bug必须分享一下调试方法。后端 Flask 启动后如果在接口逻辑里想观察某个变量的值直接在 PyCharm 代码行号处点击添加断点然后通过前端页面触发请求程序执行到断点处会自动暂停底部的 Debugger 窗口会展示当前所有变量的值。这时候可以单步执行或者跳到下一个断点配合 Evaluate 表达式功能可以在调试窗口直接执行代码查看结果。有一次订单价格计算总是不对我就是在计算 total_price 的那行加了断点发现当天日期格式从前端传过来是字符串 “2025-05-16”而后端直接用字符串做了日期比较导致价格覆盖逻辑失效。修复方法很简单在接口里先做一次 datetime.strptime 转换再参与运算。如果这个时候还在靠写 print 日志定位问题估计得来回改好几遍代码才能找到效率差距非常明显。前端 Vue 的调试主要靠浏览器开发者工具和 Vue Devtools 插件。在 Vue 组件里给关键点打 console.log 只是最笨的办法更好的办法是在 Network 面板看接口状态和返回内容在 Vue Devtools 的 Components 标签里直接查看组件的 data 和 props。前后端联调时如果页面数据不对先看 Network 的返回数据是否符合预期如果返回正常再去看前端的渲染逻辑这一套流程能帮你快速锁定问题发生在哪一层。4.2 前后端联调高频报错一览表我把这个项目中常见的问题整理成一个表格基本覆盖了大多数前后端分离项目会遇到的坑大家可以直接对照排查现象可能原因解决办法前端请求 404后端路由前缀和 axios baseURL 不一致检查蓝图的 url_prefix 和请求地址是否完全匹配前端请求 500后端代码抛异常通常是数据处理问题看 Flask 控制台堆栈日志定位报错代码行跨域请求被拦截后端没有配置 CORS 或没有走代理开发环境配置 Vite proxy生产环境用 Nginx 代理页面能打开但无数据后端返回格式和前端预期不一致统一后端返回 JSON 为 {code, msg, data} 格式图片无法显示图片路径是相对路径前端域名和后端域名不同图片地址用完整 URL 返回或将静态资源托管到对象存储提交订单重复用户多次点击提交按钮前端按钮加 loading 状态后端做幂等校验中文乱码数据库字符集不是 utf8建库时指定 utf8mb4接口响应指定 JSON_AS_ASCIIFalse这里特别想提一下“图片无法显示”这个坑。开发阶段前后端都在本机很多人直接存了 “/uploads/xxx.jpg” 这样的相对路径前端页面打开时浏览器会把这个路径拼到前端域名上自然找不到文件。我后来统一让后端返回完整的图片 URL或者在 Nginx 里把 /uploads 路径单独代理到后端的静态目录这才彻底解决。4.3 部署上线从开发机到服务器开发阶段一切正常不代表部署就顺风顺水。我第一次部署的时候用的是最简单粗暴的方式把 Flask 服务用 nohup 命令跑起来前端打包成 dist 目录扔到 Nginx 的 html 目录里。结果刚跑一天就出问题了进程经常无故挂掉运维体验很差。后来我引入了 waitress 来跑 Flask。它在 Windows 和 Linux 上都能用是一个纯 Python 实现的 WSGI 服务器部署方式非常轻量pip install waitress waitress-serve --host0.0.0.0 --port5000 app:app前面这方案只能说是跑起来了但进程守护还是要再稳定一点。我最终是在服务器上用 Nginx 托管前端静态文件并把 /api 下的请求反向代理到 waitress 端口再用 systemd 守护 Flask 服务确保进程异常退出后能自动重启。这里我建议所有做 Web 项目的人都要掌握 Nginx 的动静分离思路静态文件交给 Nginx响应速度快动态接口交给后端进程逻辑清晰方便后期扩容。部署时的环境变量也要注意。本地开发用的数据库是 SQLite生产环境我换成了 MySQL这时配置文件的数据库连接地址、用户名密码都要通过环境变量注入不要把生产环境的密码硬编码在代码里。Flask 的 SECRET_KEY 在生产环境也一定要重新生成一个高强度的随机值避免照搬开发配置。5. 项目复盘与真实运营建议5.1 时间管理和任务优先级如果大家想复刻一个类似的项目我给一个建议先画好数据库表结构再定接口文档最后同时推进后端和前端开发。这个项目最耗时间的并不是写代码本身而是前后的接口联调和不可预知的 bug。给一个小时间分配参考阶段时间占比核心任务需求梳理与数据库设计15%明确角色、核心流程、字段定义后端接口开发25%民宿、房型、订单、用户相关接口前端页面开发30%首页、详情、下单、管理后台页面联调与测试20%修接口问题、优化交互、数据核对部署与验收10%服务器配置、自动化启动、上线检查有朋友会觉得前端页面开发 30% 有点多那是因为民宿系统的“颜值”本身就影响运营效果。一套后台管理系统你随便写都能用但前台如果按钮对不齐、加载白屏客人大概率会直接放弃预订。所以我的建议是前台花 60% 的精力后台讲究功能完整和操作顺畅就好。5.2 系统上线后真正影响运营的几个功能项目上线之后我才发现很多功能在开发时没太重视但实际运营中影响很大。第一个是价格日历。网红民宿在节假日、周末和平日的价格差距很大甚至同一天不同房型价格也不同如果只靠一个基础价格字段根本玩不转。我是在运营两周后补做了价格日历功能后台可以按日期设置特殊价格前台下单时自动读取对应价格计算。第二个是订单状态流转。用户的订单可能经历待支付、已支付、已入住、已取消、已完成多种状态每一种状态变化都需要通知到对应的人。虽然这个系统没有接入短信但我做了站内消息和邮件通知的功能运营人员每天打开后台就能看到待办事项不用自己盯着订单表这个体验对小团队来说非常关键。第三个是数据统计。民宿老板一定会问“这个月订了多少单”“哪个房型最受欢迎”所以我在后台增加了一个简单的看板统计订单总量、营收总额、热门房型排行虽然只是一个 SELECT SUM GROUP BY 的 SQL但对运营决策至关重要。5.3 双框架选择后的个人体会最后分享一点个人的判断。这个项目采用 Flask 而非常见的 Django核心原因在于我们认定前后端分离是方向而后端只需要专注输出结构化数据。Flask 的轻量让接口开发更快也让整个项目更容易被新人读懂和维护。如果项目后期规模变大、业务模型复杂到一定程度Flask 的好处会慢慢减弱Django 的自带功能就开始体现价值了。我们在 PyCharm 里同时管理了 Flask 后端和 Vue 前端还用 PyCharm 内置的 HTTP Client 做接口测试整体流程下来非常顺滑。如果你刚好也在做民宿预订系统或者做一个类似的中小型业务管理系统这个技术组合是一个值得考虑的模板。想快点验证想法的可以把数据库换成 SQLite前端先只做列表和详情页想直接商用的再按我上面说的把 MySQL、Nginx、waitress 全套方案搭上。技术从来不是目的能帮民宿主真正把房间订出去、把账算清楚系统才算真正有用。
