一、项目整体背景与版本演进脉络

本项目面向中小型艺术、体育培训机构，解决传统线下机构手工登记课时、纸质排课、预约冲突难管控、核销效率低下、课时统计对账繁琐等现实痛点。项目整体分为 V1.0 与 V2.0 两个大版本迭代，两个版本定位清晰，V1.0 优先跑通完整业务闭环，V2.0 做底层加固、交互升级与产物拓展。

V1.0 初代版本仅基于微信云开发实现三套小程序：学员小程序、教师小程序、Admin 管理员小程序。业务能力完整覆盖课程浏览、课时套餐、线上预约、线下签到核销、排课排班、学员档案、基础统计。但初代版本存在明显短板：鉴权体系简陋，没有精细化权限控制，缺少完整操作审计；Admin 后台全部页面打包在同一个分包，包体积超限；预约模块只有简单的单日列表视图，排课查看效率低；没有网页端管理入口，管理员只能在手机小程序上完成后台操作；密码仅使用简单 MD5 加密，缺少 Token 黑名单、接口限流、数据脱敏等安全防护能力。

基于 V1.0 业务底座，V2.0 版本不做业务功能删减，保留全部原有业务，直接做增量重构与新增开发。本次迭代三大核心目标：第一，全系统底层安全架构整体重构，重写云函数公共安全工具与前端权限工具，搭建签名 Token 会话、精细化权限码、数据脱敏、限流防护体系；第二，重构 Admin 小程序预约管理核心页面，新增冻结轴周视图、批量代预约、开课人数预警、多维度筛选、核销追溯等大量交互能力；第三，全新开发 PC 管理 Demo 网页管理员后台，复用全部云函数业务逻辑，同时支持 Mock 离线演示模式，作为手机小程序后台的补充操作入口；配套完成小程序分包工程改造，解决包体积超限无法上传的部署问题。

整套专栏文档正是跟随两个版本开发、测试、Bug 修复的过程沉淀而来：第一篇、第二篇完成 B 端、C 端产品设计；第三篇整理页面实拍与业务流程图；第四篇梳理纯后台内部业务 Bug；第五、第六篇完整记录学员、教师、管理员三端之间数据联动产生的各类问题；第七篇记录 V2.0 底层安全、分包工程迭代踩坑；第八篇记录 PC 网页 Demo 的开发、双模式设计以及对应的坑点。

中小型 SaaS 类项目，很容易陷入 “拿到需求就直接上手写代码” 的误区，本项目前期也出现过部分交互考虑不周，后期返工的情况。

第一，业务状态的完备性是教培预约系统最大难点。预约、排班、课时套餐存在大量边界状态：未上课、已完成、已取消、已过期；套餐正常、冻结、到期；手动标记状态、系统自动计算状态。早期 V1.0 产品设计只关注正常流程，很多异常分支（过期排班访问、冻结套餐恢复、手动标记状态清除、历史已下架课程的预约详情访问）考虑不足，大量 Bug 都是测试阶段才暴露出来。产品设计阶段不仅要梳理正向流程，更要把

异常、逆向操作、历史脏数据兼容

第二，多角色业务要做好能力复用，拒绝重复造轮子。教师端不需要完全独立开发一套全新业务逻辑，应当复用管理员后台的云函数，仅依靠权限码做数据过滤与 UI 裁剪。教师只能查看自己的排班、自己的学员预约，全部在后端鉴权层做数据隔离，而不是前端做简单隐藏。如果教师端独立实现一套接口，会出现管理员改了业务逻辑，教师端逻辑没有同步，产生两边行为不一致的问题。

第三，区分 “产品能力” 和 “演示能力”。PC 管理 Demo 有两套运行模式，真实业务模式对接云开发，Mock 模式用于售前演示、本地调试。设计阶段就明确 Demo 定位：网页端只做 UI 层，所有业务计算全部下沉云函数，Mock 只模拟数据源，不能复制一套业务逻辑在前端，否则会出现两套逻辑分裂，后期维护成本成倍上涨。

第四，PRD 文档要区分 “原有基线功能” 和 “版本增量功能”。V2.0 的 PRD 把 V1.0 作为基线，只记录新增、重构内容，不重复描述旧业务，既可以防止文档冗余，也可以明确迭代边界，避免开发过程中误改动原有稳定业务。

三、开发实现阶段核心经验教训

项目选用微信云开发作为后端，不需要自建服务器，能够快速落地小程序类业务，适合独立开发者做中小型项目。但云开发也存在限制：数据库单批查询条数限制、云函数执行超时、资源额度上限。 项目开发中踩过不少云开发特有的坑：定时任务批量处理数据，不做分页分批遍历会漏掉部分数据；定时任务异常终止没有告警，业务状态不会自动流转；并发场景下缺少行级事务保护会出现课时重复扣减；接口没有限流防护，异常请求快速消耗云开发资源。

2. 多端共用后端，业务逻辑必须收敛在云端

学员小程序、教师小程序、Admin 小程序、PC 网页 Demo，四个终端，

所有业务计算、校验、权限、脱敏、日志全部收敛在云函数层

。前端（不管小程序还是 PC 网页）只负责收集参数、渲染页面。 项目中大量 Bug 根源就是前端做业务判断：前端缓存课时状态、权限状态，后端没有二次校验；前端写业务计算逻辑；不同客户端各自实现课时扣减、取消预约逻辑。 同一个业务动作存在多个操作入口：学员自己取消预约、管理员后台取消预约、PC 网页取消预约、定时任务自动过期取消预约，

全部调用同一个公共函数，实现一套逻辑，多处复用

。绝对不允许不同入口各自实现业务代码，否则就会出现 A 端操作课时返还，B 端操作课时不返还的不一致 Bug。

3. 安全不能后置，V2.0 重构的重要教训

V1.0 把业务跑通作为第一优先级，安全相关能力后置，后期 V2.0 整体重构付出不小成本。 重点问题：没有统一鉴权入口；登录凭证没有黑名单机制，退出登录 Token 依旧可以使用；密码简单 MD5，没有加盐；没有精细化权限码，靠角色名硬编码判断权限；敏感的学员手机号、姓名前端直接返回，缺少脱敏；接口没有限流；教师账号没有强制数据隔离。

Admin 小程序页面过多，V1.0 全部放在同一个分包，包体积达到 2.59MB，无法上传发布。V2.0 通过 app.json 配置进行分包拆分，把不同业务模块拆分为独立分包，把公共组件、工具脚本放在主包。 分包开发需要注意公共资源路径问题，跨分包引用组件、样式很容易出现页面空白、样式错乱；分包追求按需加载，错误的预加载配置会失去分包优化效果。 同时项目沉淀大量公共工具：日志工具、密码工具、脱敏工具、请求封装，统一抽离，各个终端复用，一处修改，全部终端生效。

很多边界 Bug，单纯单元测试很难覆盖，必须走完整业务链路真机实测。

五、项目现存局限与未来可拓展方向

六、独立全栈开发者项目落地总结

对于独立开发者开发中小 B 端工具类小程序，这套项目的落地路径有一定参考价值：

第一篇：艺培场馆课时预约小程序 B 端管理后台完整产品设计思路

第二篇：艺培场馆课时预约小程序 C 端学员端完整产品设计思路

第三篇：艺培场馆课时预约小程序后台、教师端、学员端实拍与业务流程图汇总

第四篇：艺培场馆课时预约小程序后台开发踩坑复盘（课程、学员、权限配置类 Bug）

第五篇：艺培场馆课时预约小程序用户端 & 后台联动踩坑上篇（预约、课时、同步问题）

第六篇：艺培场馆课时预约小程序用户端 & 后台联动踩坑下篇（排课核销、定时任务、页面交互异常）

第七篇：艺培场馆课时预约小程序 V2.0 底层安全、交互、分包全量迭代复盘

第八篇：PC‑Demo 网页版管理员后台（可复用云函数，对标 V2.0 PRD）

第九篇：艺培场馆课时预约小程序全项目开发历程完整复盘总结

全栈项目实战手记｜艺培场馆课时预约小程序全项目开发历程完整复盘总结

人工智能

本专栏完整复盘独立开发者基于微信云开发打造的艺培场馆课时预约小程序，从V1.0到V2.0全版本迭代，覆盖产品设计、多端联动、安全重构及PC管理Demo开发。文章汇总B端/C端PRD、业务流程图、三端联动踩坑及底层安全加固经验，详解云端业务收敛、权限控制与逆向流程测试，为中小型教培预约项目提供高复用全栈开发参考。

数据脱敏

单元测试

数据结构

云函数

服务器

数据库

SaaS

JSON

让每一个 Agent，都跑在云上

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

全栈项目实战手记｜艺培场馆课时预约小程序全项目开发历程完整复盘总结

全栈项目实战手记｜艺培场馆课时预约小程序全项目开发历程完整复盘总结

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐