自习室预约

项目概览

自习室的座位预约系统，顾客端与管理员端一体。

顾客端：微信登录后用「一楼 / 二楼」切换楼层，按日期在座位图上点选空座，确认预约时从次卡扣减次数；「我的」页有卡券、预约与消费记录，管理员还会多一个入口。

管理员端：营收与座位占度概览、营业时间配置、用户列表与发卡、会员卡充值、座位手动占用/释放、按日预约查询与取消、卡种增删改、操作日志。

并发下的座位安全

预约是整个项目里唯一有真正并发风险的地方——两个人可能同时选中同一个座位。实现方式是把这些操作全部收进一个 SQLite 事务：

先在事务内查这个「座位 + 日期」是否已有预约，再查是否被月卡长期占用，两者命中就抛 SEAT_TAKEN；然后复查次卡是否处于有效状态且余次足够，不足抛 NO_CARD；两步都过了才插入预约记录并扣减次数。数据库层再加一道 bookings(seat_id, book_date) 唯一索引兜底，冲突统一返回 409。

better-sqlite3 的同步事务保证了这个过程的原子性，不需要额外的锁。

部署

后端用 PM2 托管，nginx 把 /study/ 路径反代到本地服务，与同域的作品集站、另一个小程序后端共用一台服务器。

线上接口是活的：营业时间返回 08:30 - 23:30，座位布局返回真实座位，卡种返回次数卡·10 次 ¥10 / 30 次 ¥25 / 月卡三档。

真实的边界

这个后端虽然在线运行，但还没有面向真实用户开放，原因有三个：

• 登录是模拟的：.env 里的 WX_APPID 与 WX_APPSECRET 是空的，登录逻辑走 mock 分支，所有用户会共用一个账号。
• 支付是模拟的：购买页顶部明确写着「当前为模拟支付，正式上线将接入微信支付」，订单支付方式记为 simulate，没有调用微信支付。
• 前端还没切生产：config.js 里的 apiBase 仍指向 127.0.0.1:3001，生产地址只写在注释里。

另外文档有个不一致处：README 说服务跑在 3002 端口，nginx 配置里写的是 3001。