1. 这个题目为什么值得做以及我对技术栈的真实看法火车购票系统这个选题几乎是毕业设计和课程项目里的常青树。每年都能看到类似题目比如PythonVue的火车购票系统的设计与实现 django Pycharm flask关键词里同时出现了 django 和 flask说明不少人在选题初期其实没完全想清楚后端框架到底用哪个。我自己做这个项目时也经历过这个纠结阶段所以这篇就把整个设计与实现过程摊开聊一聊包括选型逻辑、数据库建模、接口设计、前后端联调、部署踩坑以及我实测下来值得注意的细节。先说结论主后端我用的是 djangoflask 在这个项目里我用来做了一个非常轻量的辅助服务——模拟票务系统对外部渠道的开放查询接口。很多人听到 django 就觉得很重其实对于一个包含用户注册登录、车次查询、下单购票、订单管理、后台管理的系统来说django 自带的 ORM、Admin 后台、认证体系和表单校验能省掉大量重复劳动。flask 则适合做独立的小模块比如第三方接口模拟因为它的路由和请求处理更薄起一个服务只需要几十行代码。两者不是非此即彼的关系用对场景才是关键。这个项目也顺带体现了 Pycharm 在开发流程里的角色。Pycharm 本身不参与业务逻辑但它对 django 项目的支持非常成熟比如 manage.py 命令的直接运行、模板文件的自动补全、数据库工具面板、虚拟环境管理这些在日常开发中能省下不少事。社区版就够用了不需要额外折腾。适合看这篇文章的人有两类一类是正在做类似毕设或课程项目的学生另一类是想系统了解前后端分离项目从零到落地全过程的开发者。我不会只丢一堆代码片段重点放在为什么这么设计上。因为面试官或答辩老师问得最多的不是你写了什么功能而是你为什么要这样做。2. 需求拆解与选型逻辑先想清楚系统边界再动手写代码2.1 火车购票系统的核心业务闭环很多人拿到这个题目第一反应就是把页面先画出来然后直接写接口。这个顺序其实是错的。做业务系统尤其是这种有状态流转的系统第一步必须把业务闭环理清楚。火车购票系统最核心的链路是用户注册登录 - 查询车次 - 选择车次下单 - 生成订单 - 模拟支付 - 出票 - 用户可查看订单、退票。这七个环节缺一不可否则这个系统就不是一个购票系统而只是一个车次展示系统。我见过不少同学把大量精力花在车次查询的炫酷效果上结果订单模块只有一个简单的增删改查这其实是本末倒置。车次查询再快订单状态管理一塌糊涂答辩时一被追问就露馅。我把这个系统拆成四个功能模块来设计用户模块、车次与余票模块、订单模块、后台管理模块。其中订单模块是最复杂的因为它涉及状态变化。订单不是一条记录那么简单它至少有待支付、已支付、已出票、已退票、已取消这几种状态每一种状态对应不同的用户操作和后台处理逻辑。2.2 django 与 flask 的定位划分回到技术选型。标题里出现了 django 和 flask我必须给还在纠结的人一个明确建议主框架选 djangoflask 负责边缘模块。为什么这么说因为我实际对比过。django 自带的东西太多了。用户认证体系不用自己写User 表、session、密码哈希全都有ORM 查询非常强大车次联表查询、订单过滤统计基本不需要手写 SQLAdmin 后台天然可用后台管理模块等于只做数据模型就能拿到一个可用的管理界面migration 机制让数据库表结构的变更可追溯。flask 的优势在于轻量和灵活一个文件就能起服务。但正是这种灵活性导致用户注册登录、数据库迁移、表单校验这些通用能力都需要自己找第三方库组装而且第三方库的选型组合本身就是一个坑。对于一个业务链路完整的购票系统来说用 flask 做主体会让工作量成倍增加你还得自己保证这些库之间能配合。那 flask 在这个项目里到底用在哪儿我把它做成了一个独立的第三方票务渠道模拟服务。它提供两个接口一个查询外部渠道余票一个提交外部渠道出票请求。前端并不直接对接这两个接口而是由 django 后端在必要的时候去调用。这个设计模拟了真实系统集成第三方服务的过程在答辩时是很加分的点。比如当用户查询车次时django 先查本地库再并行调 flask 服务的接口聚合两边的结果返回给前端——这样就把多数据源聚合这个真实场景引入了项目。2.3 Pycharm 在技术栈中的实际价值Pycharm 在这个项目里承担的是集成开发环境的角色。它解决的最核心痛点是django 项目的运行和调试流程非常统一但手动操作容易出错。我用 Pycharm 的虚拟环境管理器创建了项目的 venv然后指定 Python 解释器版本。这个步骤很关键因为 django 和 flask 的依赖都装在这个虚拟环境里不会污染全局环境。Pycharm 的 Django 支持插件会自动识别 manage.py在 Run Configuration 里可以直接配置启动参数比如 runserver 0.0.0.0:8000这样局域网内的设备也能访问。另外Pycharm 的 Database 面板让我在开发时可以直接查看 SQLite 或 MySQL 里的数据表。调试订单状态流转时这个功能帮了大忙——我在浏览器里操作下单然后在 Database 面板里实时看 orders 表的数据变化能直观地确认状态修改是否正确。这里有一个很重要的心态建议IDE 只是工具但选对工具能让你把精力集中在业务逻辑上。Pycharm 社区版完全够用不用在这个项目上为专业版付费。如果你的电脑性能一般用完记得定时清理缓存项目运行时确实会比 VSCode 占用更多内存。3. 数据模型设计车次、余票和订单不能想当然地建表3.1 车辆基础数据与站点关系的建模车次信息是整个系统的地基。我第一次设计时建了一张 train 表字段包括车次号、起始站、终点站、出发时间、到达时间、票价、余票数。看起来没什么问题但实际用起来会发现一个尴尬情况所有车次都变成直达车了因为一张表里只存一个出发站和一个到达站。真实的火车购票场景里一个车次会经过多个站点。比如 G101 次从北京南出发经停济南西、南京南最后到上海虹桥。如果你只存始发站和终点站那用户想买济南西到南京南这段票就没法处理了。所以正确的做法是把车次和站点拆成两张表车次表存基本信息车次停靠表存每个车次经过的站点顺序、到达时间、离开时间、以及该站到下一站的票价。这其实是真实票务系统里的区间定价逻辑。车次表的具体字段我建议这样设计车次号如 G101、车型高铁/动车/普快、始发站ID、终点站ID、发车时间、到达时间、运行时长、总座位数、状态运营中/停运。停靠表的字段是车次ID、站点ID、到达序号、到站时间、离站时间、从始发站到该站的累计票价、剩余座位数。注意查询从A站到B站的车票时需要先查出同时停靠A和B的所有车次然后按停靠序号判断 A 在 B 之前接着把 B 站的剩余座位数当作这趟车在这个区间的余票。这个逻辑用 django ORM 写起来很别扭因为需要先查车次集合再在 Python 层做过滤。实测下来用原生 SQL 或者 django 的 annotate Q 表达式能搞得定但数据量大了之后还是建议加缓存。3.2 余票字段的坑直接在票表上减一是个危险设计很多初学项目会在下单时这样操作查询到有余票 - 创建订单 - UPDATE trains SET remaining remaining - 1。这个逻辑在小流量演示下不会出错但存在严重的并发问题。两个用户同时下单都查到余票为 1都执行了减一结果剩余票数变成 -1也就是传说中的超卖。真实的购票系统不会把余票当成一个单纯的数字字段。我的做法是引入一个 ticket_stock 表每个车次区间一条记录包含区间标识始发站ID 到达站ID和库存数量。下单时不是直接 UPDATE 减一而是用事务加乐观锁或悲观锁。django 里可以这么处理在事务中用 select_for_update() 锁定库存记录然后判断库存是否大于 0确认后再减一。这样即使并发过来数据库的行级锁也能保证不会超卖。这个细节我在答辩时被老师专门追问过所以建议做这个项目的同学一定要把并发控制这块想明白。代码逻辑很简单但为什么需要才是得分点。3.3 订单表的扩展字段设计订单表是另一个容易被低估的地方。基础字段包括订单号、用户ID、车次ID、出发站ID、到达站ID、乘车日期、座位类型、票价、状态、创建时间、支付时间。我额外加了两个字段乘车人姓名和身份证号。因为真实购票必须实名制而且一个用户可以帮别人买票。这两个字段让订单模块不只是一个用户买一张票而是支持多乘车人的业务扩展。虽然增删改查的代码量稍有增加但系统完整性上一个台阶。订单号我建议自己生成而不是用自增ID。自增ID会暴露系统每天的订单量真实系统也不会这么做。我的生成规则是日期时间戳 用户ID后四位 随机数。虽然不能保证绝对唯一但配合数据库唯一约束已经足够。4. 后端实现django 接口与购票业务流程的状态机设计4.1 项目结构与核心接口规划django 项目的目录结构我建议这样组织train_ticket/settings.py 存放全局配置apps/users 用户模块apps/trains 车次模块apps/orders 订单模块apps/management 后台管理基于 django Admin 扩展每个 app 内部再按 views、models、serializers、urls 组织。如果你跟我一样把整个项目都写在主应用的 views.py 里那等到业务逻辑复杂起来后一个文件几千行代码基本没法维护。接口规划方面我的 API 采用 RESTful 风格主要通过 django-rest-frameworkDRF实现。DRF 的好处是序列化、视图集、权限控制、自动生成 API 文档这些能力都具备比手写 JsonResponse 规范得多。我定义了这些核心接口POST /api/users/register 用户注册POST /api/users/login 用户登录GET /api/trains/search?departurearrivaldate 车次查询GET /api/trains/{id}/stops 车次停靠详情POST /api/orders 下单创建订单POST /api/orders/{id}/pay 模拟支付POST /api/orders/{id}/refund 退票GET /api/orders/my 我的订单列表4.2 车次查询接口的查询优化与参数校验车次查询是整个系统的高频接口也是性能优化的重点。我在实现时把查询步骤拆成三步第一步根据出发站和到达站找出所有同时停靠这两个站的车次ID第二步根据出发日期和车次ID去查当天的余票记录第三步关联车次表和停靠表补齐发车时间、到达时间、运行时长和票价信息。django ORM 的写法大致是这样先用停靠表过滤出包含出发站的车次集合再过滤出包含到达站的车次集合然后取交集最后在 Python 层按停靠顺序判断出发站序号是否小于到达站序号。这一步用 ORM 的跨表查询也能做但多条件关联时性能下降明显。我实测下来在本地 SQLite 里几百条测试数据没感觉但换成 MySQL 并发查询多了之后还是建议直接把核心查询写成原生 SQL 或预计算缓存。参数校验这块也容易忽略。用户传入的出发站和到达站必须是数据库里真实存在的站点日期格式必须是 YYYY-MM-DD而且出发日期不能是过去的日期。这些校验我统一写在序列化器里DRF 的 serializer.is_valid() 会自动做字段格式检查业务校验放在 validate_* 方法里。4.3 下单接口最需要严谨对待的业务状态流转下单接口是订单模块的核心。它不能简单地在订单表里 insert 一条记录。我设计的完整流程是第一步开启数据库事务。第二步锁定库存记录用 select_for_update。第三步检查余票数是否足够。第四步创建订单记录状态设为待支付。第五步库存减一。第六步提交事务。这里有个容易忽略的业务规则订单创建之后库存就扣掉了但用户可能一直不支付。如果不做处理库存会被无效订单长期占用。解决办法是给订单增加一个支付过期时间字段比如下单后 15 分钟未支付自动取消。取消时要把库存加回来。这个逻辑可以用 django 的定时任务或者 Celery 实现也可以用最简单的办法在查询接口里判断订单的创建时间是否超过 15 分钟如果超过则自动更新状态并恢复库存。订单状态的完整流转我用了一张状态表来管理在实际代码里就是一个字段加一组权限判断。这里我把状态定义成状态码状态名含义允许的前置状态0待支付已下单未付款无1已支付已付款未出票02已出票票已生成13已退票用户申请退票成功1或24已取消超时未支付或手动取消0我发现直接把这个状态表写在接口注释里比自己记一堆业务逻辑清晰得多。后端每个接口在修改订单状态前都先检查当前状态是否在允许的前置状态列表中不合法就返回错误提示。这是最朴素的状态机实现但足够可靠。4.4 利用 django 的 signal 或轮询实现前端有数据就推送热搜词里有django websocket实现后台有数据前端推送这个需求在购票系统里其实很真实。比如用户下单后后台处理出票结果希望前端能实时收到通知而不是等用户手动刷新页面。websocket 的方案是django 用 channels 库把 websocket 协议接到 asgi 里前端用 vue 的 websocket 客户端监听。出票成功后后端往该用户对应的 channel group 推送一条消息前端收到后刷新订单状态。不过说实话channels 的配置复杂度不低要额外安装 channels-redis、配置 channel layer 的 backend。如果你的项目只是课程设计级别我建议用更轻量的方案前端每隔几秒轮询一次订单状态接口。也就是伪实时推送。这个方案在后端就是多写一个查询接口前端在 created 生命周期里 setInterval 定时请求。虽然在学术上不够高级但它稳定、简单、不依赖额外组件而且你在答辩时把为什么不用 websocket说清楚——比如项目规模小、低成本实现——反而体现了你的工程判断。如果确实想用 websocket 展示能力我建议只将它用在一个独立的小模块上比如售票大厅的实时余票看板而不是整个系统的核心链路上。这样既展示了技术广度又不至于把所有核心业务都押在一个不熟悉的实时方案上。4.5 flask 辅助服务的实现方式flask 在这个项目中作为独立的渠道模拟服务代码量非常少。我单独创建了 third_party_api 目录里面是一个 flask 应用。它提供了两个接口GET /api/external/inventory 和 POST /api/external/booking。django 通过 requests 库在需要时调用这两个接口。由于两个服务运行在不同的端口上django 跑 8000flask 跑 5000所以 flask 侧需要配置 CORS否则前端直接调用会有跨域问题。当然我这里 flask 接口由 django 后端调不涉及浏览器跨域但你要是想让前端直接调就得加上 flask-cors。这一点我记得很清楚因为第一次联调时就被这个卡了半小时。flask 服务的实现非常简单但价值在于它让整个系统的服务划分更接近真实架构。我在代码注释里写了它是模拟外部渠道所以答辩时老师问为什么有两个后端服务我可以清晰回答一个是主业务系统一个是第三方渠道的仿真系统两者通过 HTTP 接口通信。5. 前端实现Vue 项目搭建与购票流程交互设计5.1 Vue 项目创建与目录结构规划前端我用的是 Vue 2 加 Vue Router 加 Element UI。这套组合在课程项目里非常常见生态成熟组件现成不需要自己造轮子。如果你熟悉 Vue 3那用 Vue 3 加 Element Plus 也可以但要注意 Element UI 和 Element Plus 的 API 有差异选型后不要混用。我用 Vue CLI 创建项目命令是 vue create train-ticket-frontend。手动选择 Router 和 CSS 预处理器我选了 SCSS。目录结构如下src/api 封装 axios 请求src/router 路由配置src/views 页面组件src/store 全局状态没用 vuex因为订单状态都从后端获取前端不需要维护复杂共享状态src/components 通用组件这里有个建议不要在页面里直接写 axios.get()应该统一封装。我在 src/api 里建了一个 request.js配置了 axios 的 baseURL、请求拦截器附加 token、响应拦截器统一处理 401 和业务错误码。这样业务代码里只需要调用 api.getTrains(params) 这种函数。5.2 页面设计与路由配置购票系统的前端页面我规划了五个核心视图首页车次查询、车次列表、下单确认页、订单中心、登录/注册页、后台管理页。路由配置需要注意的点是部分页面需要登录才能访问。我用的方案是 Vue Router 的 beforeEach 导航守卫。判断 localStorage 里有没有 token没有就跳转到登录页。这个方案简单易用虽然不如 vue-router 4 的路由元信息加守卫那么优雅但对课程项目完全够用。首页的设计是顶部一个搜索栏用户选择出发城市、到达城市和出发日期点击查询后跳转到车次列表页。车次列表页展示车次号、出发到达时间、历时、座位类型和票价。每个车次后面有一个预订按钮点击后进入下单确认页。5.3 与 django 后端的对接细节与 axios 配置前后端分离项目最烦的其实就是接口联调时的跨域和鉴权问题。跨域问题我是在 django 侧解决的。安装 django-cors-headers 后在 settings.py 里把 CORS_ALLOWED_ORIGINS 配置为前端的开发地址 http://localhost:8080。如果你希望网购票系统上线后前后端同源可以在部署时把 Vue 打包的静态文件交给 django 托管这样就不存在跨域了。两种方案我都试过开发阶段用 CORS生产阶段用同源托管这个流程比较顺。鉴权方面我用了基于 Token 的认证方式。用户登录成功后django 返回一个 token前端把它存在 localStorage。每次请求在 axios 拦截器里带上 Authorization: Token xxx。django 侧用 rest_framework.authentication.TokenAuthentication 认证。这个方案比 session 认证更适合前后端分离因为前端是纯静态资源不依赖 cookie 会话。有一个小坑django 的 Token 认证默认只在数据库中存一份 token 字符串用户改密码后 token 不会自动失效。安全要求高的话可以给每个用户分配一个过期时间或者重新生成 token。否则你测试退登再登录时django 返回的还是同一个 token前端清掉本地 storage 照样能带旧 token 访问接口。5.4 订单流转在前端页面的呈现逻辑订单中心页需要根据状态给用户不同的操作入口。待支付订单显示去支付和取消订单按钮已支付订单显示申请退票按钮已退票和已取消的订单只展示状态。这个逻辑本质上就是把后端的状态机映射到前端按钮显隐判断上。前端加这些交互逻辑的时候我发现一个容易出错的地方状态字段的数字容易记混。我后来在前端建了一个 orderStatusMap 映射对象把数字状态映射成中文文本和对应的按钮显隐规则。这个映射对象在多个组件里复用总算让状态判断的代码整洁了不少。下单确认页还有一点值得注意车票的乘车人姓名和身份证号需要在前端表单里填写下单时传给后端创建订单。如果允许一个订单多乘车人前端需要支持动态添加乘车人列表。6. 联调、部署与排错这套系统最常踩的五类坑6.1 时区与时间格式不一致django 的 settings.py 里默认的 TIME_ZONE 是 UTCUSE_TZ 是 True。你在数据库里存的是 UTC 时间但前端展示需要北京时间。我在查询接口里直接用 timezone.localtime() 转换后返回或者把 USE_TZ 设为 False 直接用本地时间存储。后者虽然简单但不推荐在真实项目里用。我的建议是保持 USE_TZ True在序列化器里明确输出东八区时间。这个坑很隐晦因为开发前期只有你自己测试感觉不了差异。等到你打印订单创建时间发现慢了 8 个小时才会意识到问题所在。前后端就时间格式我在联调时统一约定为 YYYY-MM-DD HH:mm:ss前端拿到字符串直接展示避免 Date 对象在 JS 里带来额外的时区转换。6.2 静态文件与前端构建资源的托管问题开发阶段前端跑在 8080 端口后端跑在 8000 端口各管各的没问题。但部署时如果直接把 Vue 的静态文件和 django 的应用分开部署就得配置 Nginx 反向代理两个来源。这个方案对课程项目来说负担偏重。更省事的办法是前端执行 npm run build 生成 dist 目录然后把这个目录下的静态文件放入 django 的静态目录通过 django 直接托管和路由。API 请求路径改为相对路径不再加 CORS。配合 django 的 TemplateView 将未知路由指向 index.html就能支持 Vue Router 的 history 模式。这个方法能让整个系统以单个服务的形式部署在服务器上只需要跑一个 django 进程。我在部署时用的组合是 Nginx uwsgiNginx 负责托管静态文件和转发动态请求到 uwsgi 进程。实测下来稳定性不错只要 CORS 配置正确和静态文件路径配置正确基本不会出问题。6.3 数据库并发导致的超卖与事务处理我在前文提到过 select_for_update 解决超卖。实际联调时用 django test client 写并发脚本测试后确实发现没有加锁的情况下会出现余票为负数的记录。加了事务锁后虽然性能略有下降但数据一致性得到保证。还有一点是用 MySQL 还是 SQLite 的选择。开发阶段我用 SQLite好处是零配置文件即数据库。但 SQLite 对并发的支持比较弱多个写操作同时到达时会报 database is locked。如果你的系统要演示真实的并发场景最好从一开始就切换成 MySQLdjango 的 ORM 能平滑迁移。只需要修改 DATABASES 配置并执行 migrate。6.4 Vue Router history 模式与后端路由冲突Vue Router 默认是 hash 模式URL 里带 #比如 /#/orders刷新页面没问题。我为了 URL 好看开启了 history 模式。结果刷新 /orders 页面时django 直接返回 404因为 django 后端没有这个路由。解决办法是在 django 的 urls.py 最后加一个 catch-all 路由把不匹配 API 的请求都转发给 index.html。这个操作在后面部署时非常重要否则别人访问你的站点一点刷新就白屏。我也在 Pycharm 里遇到过类似问题配置了项目根目录后django 模板和静态文件路径引用错误。这个靠检查 BASE_DIR 相关的路径拼接就能定位。Pycharm 的 File Settings Languages Frameworks Django 面板里设置好 Django template 根目录和 manage script 路径自动补全才能正常工作。6.5 pycharm 常见误区和环境配置经验围绕 Pycharm 的热搜里有个词是pycharm激活。这里我想认真分享一下Pycharm 社区版是免费开源授权的功能对 django 和 Vue 开发来说完全够用不需要特意去寻找任何非官方激活方式。我见过很多同学在这上面绕了远路反而浪费了不少时间。正确的路径是直接从官网下载社区版安装包然后在 Settings Project Python Interpreter 里配置虚拟环境中的 Python 解释器Pycharm 会自动安装的 django 支持插件就能让 IDE 识别 manage.py 脚本。另外Pycharm 里配置 django 的 Run Configuration 时注意 Environment variables 里需要设置 DJANGO_SETTINGS_MODULE 为 train_ticket.settings否则有时候命令行正常但 IDE 里启动会报配置错误。这个报错很常见但排查方法也很简单基本是配置路径没对应上。7. 从这个小项目里我认为值得长期保留的设计习惯做完这个项目之后我复盘了一下哪些设计是以后做任何业务系统都可以复用的。第一是业务状态流转一定要前置梳理清楚订单的状态机画明白再写代码比写完了再反复修补高效得多第二是并发安全问题不要留到联调阶段才想写第一版查询和下单接口时就要用事务锁因为事后加锁的改动成本远高于一开始就写好第三是前后端接口的字段命名和时间格式要在一开始就统一约定否则联调期每天都在扯皮。这个系统做下来我自己最大的收获是对完整业务闭环有了更具体的认知。一个能演示的购票系统不是在页面上能点几个按钮而是从用户进入到订单终态每一步都有清晰的规则、可追踪的状态和可靠的数据一致性。这种思维方式放在任何业务系统开发里都一样。如果你现在也在做这个题目我的建议是先把业务闭环走通再考虑加什么炫酷的动画效果或者技术特性。基础链路稳定了再去加 websocket 实时推送、多数据源聚合、Elasticsearch 全文搜索之类的进阶点都不迟。但反过来如果核心订单流程漏洞百出这些进阶功能反而会成为答辩时的扣分项。