承接前面三篇产品设计与素材汇总，本篇聚焦 纯管理员后台内部开发阶段遇到的真实业务 Bug，只讲后台模块自身问题。 全部问题均来自实际功能测试，按照现象 → 根因分析 → 修复方案 → 开发启示的结构整理，覆盖排班、课程管理、学员档案 & 套餐、核销管理、权限账号、列表筛选、页面 UI、日志模块，做 B 端小程序后台业务开发可以作为避坑参考。
一、排班管理模块踩坑
排班是教务最高频操作，业务校验规则多，也是后台 Bug 集中爆发区域。
坑 1：编辑排班时，没有覆盖旧数据，反而新增一条排班记录
现象：进入已有排班点击编辑，修改时间、教师等信息后保存，数据库会多出一条全新排班，原有旧排班数据依旧保留，造成同一时段重复排班，后台列表出现重复班期。
根因：调用接口没有传入目标排班的_id主键，后端逻辑直接走新增分支，没有执行更新逻辑；前端编辑弹窗没有正确回填主键参数。
修复方案：编辑弹窗打开时带入当前排班唯一 ID；后端做分支判断，存在 ID 执行更新，无 ID 才执行新增；增加业务层校验，防止无 ID 的编辑请求。
开发启示：新增 / 编辑复用同一弹窗是常见开发模式，必须保证编辑场景主键 ID 完整透传到后端，不能完全依靠前端页面限制，后端要做二次防护。
坑 2：教室同一时段排班冲突校验缺失，允许重复排课
现象：同一教室、同一个时间段，可以重复创建多条排班，出现教室资源冲突，同一个教室同时开设两节课。
根因：仅在前端做了简单校验，前端校验可以被绕过；后端保存排班接口缺少教室 + 时段的数据库层面冲突判断。
修复方案：后端新增校验逻辑，新增、修改排班时，查询当前教室该时间段是否已存在有效排班，存在则直接拦截返回业务错误，禁止保存。
开发启示：资源冲突类校验，不能只依赖前端，后端必须实现强校验，防止抓包绕过前端限制产生脏数据。
坑 3：教师休息日没有做排课拦截，休息日依然可以创建排班
现象：后台给教师配置好了每周休息日，新增排班依旧可以把课程排到教师休息日。
根因：教师休息日配置只做了页面展示，排班保存接口没有读取教师休息日配置做业务拦截。
修复方案：后端排班保存接口，读取教师固定排班配置，判断所选上课日期是否属于休息日，如果属于直接弹窗提示拦截保存。
开发启示：配置类参数，不要只做页面展示，涉及业务变更的接口，都要读取配置参与校验。
坑 4：批量生成排班，发生冲突时错误提示笼统，看不到冲突明细
现象：批量导入生成多条排班，部分排班发生教室、教师冲突，仅提示 “部分排班失败”，无法看到到底哪些日期、哪些时段冲突，教务排查困难。
根因：批量接口只统计成功、失败计数，没有收集每一条失败记录的冲突原因。
修复方案：批量循环处理每一条排班，把冲突的日期、时段、冲突原因收集返回给前端，弹窗展示明细列表。
开发启示：批量操作，除了成功失败总数，尽量返回失败项明细，降低使用者排查成本。
坑 5：手动修改课程状态，未联动更新内部关联字段
现象：管理员手动把排班标记为「已取消」，仅修改页面展示状态，底层manualStatus标记字段没有同步写入，清除手动状态时无法恢复系统自动计算。
根因：状态修改接口只修改对外展示 status，漏掉manualStatus专属人工标记字段赋值。
修复方案：手动修改状态同时写入manualStatus；清除手动状态接口将该字段置空，恢复系统自动计算逻辑。
开发启示：存在 “系统自动计算 + 人工干预” 两套状态逻辑时，要区分业务状态字段与人工标记字段，两个字段同步维护。
二、课程 & 分类管理模块踩坑
坑 6：课程移入回收站后，依然可以被绑定到新排班
现象：课程移入回收站，已经逻辑删除；管理员新建排班时下拉选择框还能看到该课程，可以继续创建排班。
根因：回收站只在课程列表做过滤；排班的课程下拉选择接口，没有过滤 isDelete 已标记删除的课程。
修复方案：所有读取课程下拉、课程选择的接口，统一增加过滤条件，过滤回收站标记课程；回收站课程禁止被新排班引用。
开发启示：逻辑删除的数据，不能仅仅在列表页隐藏，所有关联下拉选择、查询接口都要带上删除状态过滤条件。
坑 7：删除二级分类时，没有校验是否存在关联课程
现象：二级分类下面还挂载有正常课程，后台可以直接删除该二级分类，导致课程的分类 ID 变成无效 ID，课程分类展示错乱。
根因：删除二级分类接口没有做关联引用校验，直接执行删除。
修复方案：删除前查询该分类下是否存在有效课程；存在关联课程则拦截删除，提示需要先转移或者删除下属课程。
开发启示：主数据删除接口，必须做引用关系校验，防止产生外键逻辑断裂的脏数据。
坑 8：场馆规则编辑，同名场馆允许重复新增
现象：后台可以录入两条完全同名的场馆记录，排课下拉出现重复场馆选项，教务选择容易混淆。
根因：场馆新增接口没有做场馆名称唯一性校验。
修复方案：新增、编辑场馆时后端校验场馆名称重复，重复则拦截保存。
开发启示：业务主数据，对业务意义上唯一的名称字段，后端增加重复校验，避免字典脏数据。
三、学员与套餐管理模块踩坑
坑 9：套餐冻结状态下，后台核销入口依旧可以执行核销扣课时
现象：学员套餐设置为冻结，管理员后台核销页面，依旧可以对该学员做核销操作，正常扣减课时。业务预期冻结套餐不允许消耗课时。
根因：冻结状态校验只写在了学员端预约逻辑；后台手动核销接口遗漏套餐冻结状态校验。
修复方案：后台手动核销接口增加套餐状态校验，套餐冻结直接拦截，返回提示，不执行扣课时逻辑。
开发启示：同一业务规则存在多个操作入口，后台独立入口必须复用相同校验，不能只依赖 C 端校验。
坑 10：后台手动新增学员，手机号允许重复录入
现象：后台新增学员档案，两个学员可以录入完全一样手机号，造成学员数据重复，后续套餐、预约会出现数据匹配错乱。
根因：后台新增学员接口，没有对手机号做唯一性校验。
修复方案：后台新增、编辑学员接口后端校验手机号重复，重复则拦截保存。
开发启示：手机号作为学员唯一业务标识，后台录入接口增加唯一性约束，避免多条学员记录同一手机号。
坑 11：给学员新增套餐，过期时间传空未做兜底处理
现象：后台给学员添加课时套餐，如果管理员没有填写过期时间，后端没有兜底，expireTime 存入 null，后续套餐状态判断逻辑报错。
根因：接口未对过期时间入参做空值兜底。
修复方案：后台接口做参数校验，过期时间必填；或者为空自动赋予一个极大过期时间。
开发启示：后台表单的时间、数字类业务字段，后端必须做空值、非法值校验兜底，不能完全依赖前端表单校验。
四、核销管理模块踩坑
坑 12：撤销核销操作，没有校验核销记录状态，支持重复撤销
现象：一条核销记录已经执行过撤销核销；管理员再次操作撤销核销，接口仍然可以执行，多次重复返还学员课时，造成课时越返越多。
根因：撤销核销接口没有判断核销记录当前状态，没有判断是否已经撤销过。
修复方案：撤销之前先查询核销记录状态；已经撤销过直接拦截，不执行课时返还逻辑。
开发启示：逆向业务操作（撤销、回滚），一定要先校验当前业务单据状态，防止重复逆向操作造成数据错乱。
坑 13：后台生成核销二维码，排班已经取消，依旧可以生成有效二维码令牌
现象：某条排班已经被管理员手动取消；核销页面依旧可以生成 30 分钟有效签到二维码。
根因：生成二维码接口没有校验排班当前业务状态，不管排班是否取消都可以生成令牌。
修复方案：生成二维码前校验排班状态，已取消、已过期排班禁止生成核销二维码。
开发启示：生成令牌、凭证类接口，必须校验关联业务单据的当前状态，不能只单纯生成令牌字符串。
五、账号、权限与日志模块踩坑
坑 14：禁用的后台账号，后台登录接口缺少状态校验
现象：管理员账号在后台被设置为禁用；该账号依旧可以完成登录，获取后台操作权限。
根因：登录接口只校验账号密码正确，没有读取账号 status 状态做拦截。
修复方案：登录鉴权阶段校验账号状态，禁用账号直接拦截登录，写入登录失败日志。
开发启示：账号状态校验放在登录接口，不要只在页面做隐藏。
坑 15：后台多条件组合筛选逻辑失效
现象：后台预约管理页，同时勾选教师、场馆、课程状态多个筛选条件，列表过滤结果不正确，出现不该展示的数据；单条件筛选正常。
根因：筛选逻辑多个条件使用或（or）而非且（and）；空条件没有跳过过滤处理。
修复方案：重构筛选逻辑，多条件为同时满足关系；未选择筛选项不加入过滤条件，完善多条件场景测试。
开发启示：后台列表组合筛选是高频出错点，必须覆盖：单条件、多条件组合、条件清空等场景。
坑 16：后台部分业务操作不会写入操作审计日志
现象：手动修改排班状态、后台代预约、撤销核销，部分操作完成，审计日志表无记录，后期无法追溯是谁执行变更。
根因：开发只对普通 CRUD 写日志；状态变更、代预约、撤销核销这类衍生业务动作，忘记调用统一日志工具。
修复方案：封装统一日志公共工具函数；所有变更数据的业务动作统一调用日志写入，补齐全部业务动作枚举。
开发启示：凡是修改业务数据，不只是新增删除，状态变更、代操作、回滚撤销都要记录操作日志，方便对账排查问题。
六、页面 UI、交互、兼容性类后台 Bug
坑 17：后台数据看板，小分辨率屏幕布局错位溢出
现象：较小分辨率设备打开后台首页看板，统计卡片、快捷入口布局错乱、内容溢出，大屏开发机显示正常。
根因：页面大量写死固定 px 宽度，未使用弹性自适应布局。
修复方案：改用弹性栅格布局，去除硬编码固定宽度，适配多种屏幕分辨率。
开发启示：B 端后台不能只在开发大屏测试，需要覆盖多种分辨率。
坑 18：后台列表分页，pageSize 参数前端可传入超大值，一次性返回巨量数据
现象：后台各类列表分页，后端没有限制 pageSize 最大值；前端抓包修改 pageSize 传很大数字，接口一次性返回上千条记录，数据库查询压力大。
根因：只依赖前端下拉分页限制条数，后端没有对 pageSize 做上限拦截。
修复方案：所有后台列表接口，后端强制限制 pageSize 最大 50，超过则强制截断。
开发启示：分页参数后端必须做上限限制，防范恶意大查询压垮数据库。
七、后台开发通用总结启示
- 前端只负责交互体验，后端才是最终防线。资源冲突、状态、唯一性、引用关系校验，后端必须再做一层强校验，不能信任前端提交的数据。
- 同一业务规则存在多个后台操作入口，校验逻辑必须复用公共函数，避免 A 入口校验，B 入口漏掉校验。例如冻结套餐校验、单据状态校验。
- 逻辑删除不能只隐藏列表页，所有下拉、选择、关联查询接口都要带上过滤条件，防止被旧业务继续引用。
- 做删除操作，优先校验关联引用关系，避免删除主数据之后，子数据 ID 悬空，产生脏数据。
- 逆向回滚类业务（撤销核销等），操作前必须校验单据当前状态，严防重复回滚，造成数据越改越错。
- 批量操作不能只返回成功 / 失败计数，尽量返回失败明细，降低运维人员排查成本。
- 分页、表单时间、手机号等入参，后端要做边界值、非法值、最大值限制，不能完全信任前端表单校验。
- 不仅仅普通增删改，状态变更、代预约、撤销核销这类衍生业务，全部要写入操作审计日志，方便业务对账与问题回溯。
本文属于《全栈项目实战手记｜艺培场馆课时预约小程序》专栏，系列持续更新，可订阅专栏阅读完整连载。
连载目录回顾
第一篇：艺培场馆课时预约小程序 B 端管理后台完整产品设计思路
第二篇：艺培场馆课时预约小程序 C 端学员端完整产品设计思路
第三篇：艺培场馆课时预约小程序后台、教师端、学员端实拍与业务流程图汇总
第四篇：艺培场馆课时预约小程序后台开发踩坑复盘（课程、学员、权限配置类 Bug）
第五篇：艺培场馆课时预约小程序用户端 & 后台联动踩坑上篇（预约、课时、同步问题）
第六篇：艺培场馆课时预约小程序用户端 & 后台联动下篇（排课核销、定时任务、页面交互异常）
第七篇：艺培场馆课时预约小程序 V2.0 底层安全、交互、分包全量迭代复盘
第八篇：艺培场馆课时预约小程序 PC 管理端 Demo 完整开发成果展示
第九篇：艺培场馆课时预约小程序全项目开发历程完整复盘总结
