企业官网建设流程全解析

前面第一篇到第八篇，依次完成产品需求设计、多端产品梳理、业务流程图整理、后台业务 Bug 复盘、学员‑教师‑管理员三端联动踩坑上下篇、V2.0 底层安全重构复盘、PC 网页管理 Demo 开发复盘。本复盘站在独立全栈开发者视角，完整回顾从 V1.0 初代版本到 V2.0 重构版本的完整过程，梳理需求落地、架构选型、踩坑教训、工程得失、遗留局限以及后续可拓展方向，对中小型线下教培预约类小程序项目提供可复用经验参考。

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

本项目面向中小型艺术、体育培训机构，解决传统线下机构手工登记课时、纸质排课、预约冲突难管控、核销效率低下、课时统计对账繁琐等现实痛点。项目整体分为 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 作为基线，只记录新增、重构内容，不重复描述旧业务，既可以防止文档冗余，也可以明确迭代边界，避免开发过程中误改动原有稳定业务。

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

1. 云开发架构的利与弊

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

核心启示：定时任务不要直接裸写数据库更新，尽量复用已经封装好的公共业务函数；定时任务增加异常捕获、日志记录、管理员告警；资产变更类业务，必须使用事务保证原子性。

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

学员小程序、教师小程序、Admin 小程序、PC 网页 Demo，四个终端，所有业务计算、校验、权限、脱敏、日志全部收敛在云函数层。前端（不管小程序还是 PC 网页）只负责收集参数、渲染页面。 项目中大量 Bug 根源就是前端做业务判断：前端缓存课时状态、权限状态，后端没有二次校验；前端写业务计算逻辑；不同客户端各自实现课时扣减、取消预约逻辑。 同一个业务动作存在多个操作入口：学员自己取消预约、管理员后台取消预约、PC 网页取消预约、定时任务自动过期取消预约，全部调用同一个公共函数，实现一套逻辑，多处复用。绝对不允许不同入口各自实现业务代码，否则就会出现 A 端操作课时返还，B 端操作课时不返还的不一致 Bug。

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

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

开发启示：新项目如果条件允许，鉴权、权限、脱敏、日志从初期就要纳入设计；如果为了快速上线先跑业务，也要做好规划，后续安排完整安全迭代，不要把简陋安全逻辑直接交付生产使用。权限判断，永远后端优先，前端只是 UI 层面隐藏按钮，不能作为安全屏障。

4. 工程分包与代码维护

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

四、测试阶段的关键认知

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

1. 重点测跨端联动场景：后台修改数据之后，学员端、教师端页面是否同步；后台代预约、撤销核销这类逆向操作，课时、流水、预约状态是否同步变更。大量问题不是操作本身报错，而是其他终端页面没有感知数据变更。页面 onShow 生命周期重新拉取服务端数据，不要过度依赖前端内存与 storage 缓存。课时、余额这类核心资产，禁止信任前端缓存数据，全部以数据库为准。
2. 一定要测逆向流程：取消预约、撤销核销、套餐冻结解冻、过期自动处理，很多开发者只测正向新增预约、核销流程，逆向流程漏洞非常多。
3. Mock 环境单独测试：Mock 模拟数据结构需要跟随真实数据库同步更新，业务表字段改动，Mock 仓库必须同步改动，否则离线演示模式会出现渲染异常。
4. 角色覆盖完整测试：超级管理员、普通子管理员、教师、学员，不同权限账号完整走一遍业务，校验权限码、数据脱敏、数据隔离是否生效。

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

现存局限

1. 当前版本主要面向单场馆机构，没有做多门店连锁完整隔离架构，如果是多校区连锁教培机构，还需要增加门店维度隔离；
2. 财务模块比较薄弱，只有简单课时消耗流水，没有完整的营收对账、收款、退费财务闭环；
3. 消息通知依赖微信订阅消息，缺少站内消息中心；
4. PC Demo 目前为网页管理后台，只实现管理员能力，教师、学员依旧依靠小程序访问，网页端没有做这两类角色页面。

后续可拓展方向

1. 连锁多门店改造，增加门店隔离，数据按门店隔离；
2. 完善财务模块：缴费、退费、账单导出、财务对账报表；
3. 增加站内消息中心，消息记录持久保存，不依赖微信订阅消息；
4. 学员端增加更多营销相关能力：优惠券、拼团、体验课；
5. 导出报表能力增强，支持 Excel 批量导出排班、预约、课时流水。

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

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

1. 开发顺序建议：V1 版本优先保证业务闭环，把核心流程跑通，不必一开始就堆砌复杂安全、复杂性能；业务跑通稳定之后，再启动 V2 版本做底层加固、交互升级、新增产物。不要追求一步到位，否则需求庞大，项目很难落地。
2. 业务逻辑尽量收敛后端，前端只做展示与参数收集，减少多端逻辑不一致的坑。
3. 文档沉淀伴随开发同步进行，产品 PRD、踩坑复盘文档，不只是写出来给自己看，后续迭代、二次维护，文档可以极大降低回忆成本，本专栏一到九篇就是完整项目沉淀。
4. 重视逆向流程、边界状态、脏数据兼容，B 端系统 Bug 大量出现在异常场景，而不是正常业务流程。
5. 区分正式业务产物和演示产物，像 PC‑Demo 这种同时支持真实云函数和 Mock 两套模式，要严格隔离两套逻辑，不能把演示逻辑混入正式业务代码。

至此，《全栈项目实战手记｜艺培场馆课时预约小程序》整套专栏全部完结。从产品设计、流程图梳理、后台 Bug、三端联动问题、底层安全重构、分包工程、PC 管理 Demo 开发，完整记录一个独立全栈开发者，基于微信云开发从零落地一套面向教培机构课时预约管理系统的完整过程。

连载目录回顾

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

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

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

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

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

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

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

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

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