3步搞定自动售票检票系统，面试不再卡壳的保姆级教程

面试被问原理答不上来？别慌。很多应届生在面试自动售票检票系统时，只会背八股文，一上手代码就露馅，甚至连数据库怎么存票根都讲不清。

这篇保姆级教程，就是为你准备的。我们不讲虚的，直接拆解核心逻辑，给你一套能跑通、能拿出去面试的代码框架。

核心概念与业务逻辑拆解

在写代码前，先搞清楚“自动售票检票系统”到底在自动什么。

很多人以为这就是个简单的 CRUD（增删改查），大错特错。它的核心在于状态机和并发控制。

一张票的生命周期是这样的：

生成：用户支付成功，系统生成唯一 Ticket ID。
锁定：防止同一张票被重复购买或超卖。
核销：检票闸机扫描，状态从“有效”变为“已使用”。
退改：特殊情况下，状态回滚或标记为“已退款”。

这里最大的坑在于并发。比如春运抢票，一万个用户同时点“确认购买”，数据库里只剩一张票，你怎么保证只卖出一张？

这就是面试最爱问的：如何用代码实现“原子性扣减”？

如果这时候你只会说“用锁”，面试官会觉得你经验不足。高级的答法是结合 Redis 的 decr 原子操作，或者数据库的 UPDATE ... WHERE stock > 0。

记住这个业务闭环，你的代码架构就有了灵魂。

环境准备与技术选型

既然是入门教程，我们选最通用的技术栈：Python + FastAPI + SQLite。

为什么选这套？

Python：语法简洁，适合快速验证业务逻辑。
FastAPI：自带 API 文档，性能接近 Go，开发效率极高。
SQLite：单文件数据库，不需要部署 MySQL，本地就能跑通全流程。

你需要准备的工具：

Python 3.9+ 环境。
pip install fastapi uvicorn sqlalchemy。
一个代码编辑器（VS Code 推荐）。

这里有个小细节：很多初学者喜欢在本地装 MySQL，结果配置半天连不上，心态崩了。对于业务逻辑演示，SQLite 足够用了。等逻辑跑通后，你只需要把连接字符串换成 MySQL 的 URL 即可，代码几乎不用改。

核心语法与数据模型定义

先看数据模型。这是系统的骨架。

from sqlalchemy import create_engine, Column, Integer, String, DateTime
from sqlalchemy.orm import sessionmaker, declarative_base
from datetime import datetime# 创建 SQLite 引擎，check_same_thread=False 允许跨线程访问
engine = create_engine("sqlite:///ticket.db", connect_args={"check_same_thread": False})
SessionLocal = sessionmaker(autocommit=False, autoflush=False, bind=engine)
Base = declarative_base()class Ticket(Base):__tablename__ = "tickets"id = Column(Integer, primary_key=True, index=True)ticket_no = Column(String, unique=True, nullable=False)  # 唯一票号，如 T20231024001status = Column(String, default="AVAILABLE")  # 状态: AVAILABLE, LOCKED, USEDprice = Column(Integer, default=50)created_at = Column(DateTime, default=datetime.utcnow)Base.metadata.create_all(bind=engine)

关键点解析：

ticket_no 必须设置 unique=True，这是防止重复出票的第一道防线。
status 字段是状态机的核心。不要直接用布尔值 is_used，因为状态可能会变（比如退票后重新售卖），字符串状态更灵活。

接下来是接口定义。我们要实现两个核心接口：buy_ticket（购票）和 check_ticket（检票）。

完整代码示例：实现购票与检票

下面这段代码可以直接运行。它展示了如何处理简单的并发场景（虽然 SQLite 锁机制与 MySQL 不同，但逻辑是通用的）。

from fastapi import FastAPI, HTTPException, Depends
from sqlalchemy.orm import Session
from pydantic import BaseModel
import uuid
from datetime import datetimeapp = FastAPI()def get_db():db = SessionLocal()try:yield dbfinally:db.close()class TicketResponse(BaseModel):ticket_no: strstatus: strprice: int@app.post("/api/tickets/buy")
def buy_ticket(db: Session = Depends(get_db)):"""购票接口：生成唯一票号并标记为可用"""# 生成唯一票号，防止冲突ticket_no = f"T{datetime.now().strftime('%Y%m%d%H%M%S')}{uuid.uuid4().hex[:6]}"new_ticket = Ticket(ticket_no=ticket_no,status="AVAILABLE",price=50)db.add(new_ticket)db.commit()db.refresh(new_ticket)return TicketResponse(ticket_no=new_ticket.ticket_no,status=new_ticket.status,price=new_ticket.price)@app.post("/api/tickets/{ticket_no}/check")
def check_ticket(ticket_no: str, db: Session = Depends(get_db)):"""检票接口：校验状态并核销"""ticket = db.query(Ticket).filter(Ticket.ticket_no == ticket_no).first()if not ticket:raise HTTPException(status_code=404, detail="Ticket not found")# 核心逻辑：判断状态if ticket.status == "USED":raise HTTPException(status_code=400, detail="Ticket already used")elif ticket.status != "AVAILABLE":raise HTTPException(status_code=400, detail="Invalid ticket status")# 更新状态为已使用ticket.status = "USED"db.commit()return {"message": "Check successful", "ticket_no": ticket_no}

逐行讲解重点：

UUID 生成票号：在并发场景下，仅靠时间戳可能重复。加上 uuid.uuid4().hex[:6] 能大幅降低冲突概率。
状态校验前置：在修改数据库之前，先查询当前状态。这是最基础的乐观锁思路。
事务提交：db.commit() 之前，数据还在内存中。只有提交后，其他线程才能看到变化。

运行方式：

uvicorn main:app --reload

打开浏览器访问 http://127.0.0.1:8000/docs，你可以直接测试这两个接口。

常见报错与避坑指南

在实际开发中，你大概率会碰到下面这几个坑。我在 Stack Overflow 上看过大量关于 FastAPI 依赖注入的讨论，发现 90% 的新手都会卡在数据库会话管理上。

坑 1：数据库连接未关闭 现象：运行多次后，程序崩溃，提示 too many open files。原因：手动创建 SessionLocal() 后没有 close()。解决：始终使用 Depends(get_db) 这种依赖注入方式，FastAPI 会在请求结束后自动清理资源。

坑 2：并发下的超卖 现象：库存 10 张，卖了 11 张。原因：查询和更新之间有时间差（Race Condition）。解决：

方案 A（推荐）：使用数据库行级锁。在 buy_ticket 中，如果涉及库存扣减，使用 UPDATE tickets SET stock = stock - 1 WHERE id = ? AND stock > 0，检查返回的影响行数。
方案 B：引入 Redis。先 decr 库存，成功再写数据库。这是高并发场景下的标准做法。

坑 3：检票接口幂等性 现象：用户网络抖动，连续点了两次“检票”，第二次报错“已使用”，用户以为系统坏了。解决：接口设计要幂等。如果状态已经是 USED，返回 200 和提示“票已核销”，而不是 400 错误。这对前端体验至关重要。

坑 4：SQLite 并发写入死锁 现象：多人同时购票时，提示 database is locked。原因：SQLite 是文件锁，写入时独占。解决：

增加 timeout 参数：create_engine("sqlite:///ticket.db", connect_args={"timeout": 30})。
生产环境务必换 MySQL 或 PostgreSQL，SQLite 只适合单机原型开发。

小结与实战建议

这套代码虽然简单，但覆盖了唯一性约束、状态机流转、依赖注入、异常处理四个核心考点。

面试时，你可以这样描述：

“我设计了一个基于状态机的检票系统。通过 UUID 保证票号唯一，利用 FastAPI 依赖注入管理数据库生命周期。针对并发问题，我预留了 Redis 分布式锁的扩展接口，目前使用数据库行锁保证基础一致性。”

这段话，既展示了代码能力，又体现了架构思维。

最后，关于薪资和证书的问题，虽然不在代码范畴，但也是很多读者关心的。

薪资区间：初级后端开发（含此类业务系统经验）在一线城市起步约 12k-15k，二三线 8k-10k。如果你能加上 Redis 集群、K8s 部署经验，薪资可上浮 30%。
培训机构选择：警惕那些承诺“包就业”、“月入过万”的机构。真正的技术成长靠的是项目实战，而不是背题。
证书补办：如果你报考的是软考（计算机技术与软件专业技术资格），证书丢失可在中国计算机技术职业资格网在线申请补办，一般 2 个月内邮寄到家，无需跑线下窗口。

你在项目里踩过这个坑吗？评论区聊聊，看看谁经历的并发 Bug 最奇葩。