简介：这是一套教育培训学校小程序v2.0.13前端源码包，定位服务于教育培训机构和在线课程运营者。项目描述强调线上视频与线下教学相结合，因此资源很适合需要快速搭建视频课程展示、播放和购买入口的教培业务方。压缩包共1474个文件，整体13.06MB，核心是小程序前端工程，包括WXML页面结构、WXSS样式、JS交互逻辑、JSON配置等；同时包含PHP服务端接口、HTML后台页面以及较多PNG/JPG图片、图标素材，并带有少量WXS、SVG、字体文件等附属资源。目录按模块组织，页面覆盖课程列表、课程详情、个人中心等常见模块，便于按需检索和定位。目前已有227人学习下载。解压后可以对照完整前端页面理解典型业务实现思路，也能复用页面组件、样式表和接口调用代码，作为从零开发教育培训类小程序或二次改造本地版本的基础底稿。
1. 教育培训学校小程序的前端改造，最先要解决的是续班率问题
教育类小程序和电商小程序有个本质差异：用户打开它的目的不是“逛”，而是“查课表、看剩余课时、约试听、续费”。这意味着前端的信息架构必须把“高频查询”放在触手可及的位置，而不是把首页做成机构介绍海报。v2.0.13 这个版本号背后，通常是一次中型迭代——可能重构了课程列表的加载方式，也可能替换了报名流程。无论具体改动是什么，前端要守住一条底线：弱网环境下，家长能在一分钟内完成“找课、看剩余课时、提交报名”三个动作。
这一类小程序适合的团队画像也很明确：机构自己有运营人员，但没有专职小程序团队；前端要么外包，要么由 App 或后台开发兼任。所以选型、目录结构和发布流程都要按“最少维护成本”来设计。下面的内容围绕 uniapp 这条常见技术路线展开，覆盖从初始化到提审的完整前端方案，并针对 v2.0.13 这类迭代版本给出可落地的增量发布技巧。
2. 基于 uniapp 的教育培训小程序选型与目录拆分
2.1 为什么教育类小程序前端普遍走 uniapp 而不是原生
原生微信小程序的好处是性能天花板高，但代价是 Android 和 iOS 两端各写一套逻辑，而且将来如果机构想同步出一个支付宝小程序或抖音小程序，原生代码基本作废。教育培训学校的业务形态以表单、列表、地图、支付为主，没有重交互的动画和复杂手势，uniapp 的编译性能足够支撑。
我一般会这样判断是否值得上 uniapp：如果机构已有 App 端（无论是否用 uni-app 开发），小程序前端直接用 uniapp 天然多端复用；如果机构只在微信生态内运营，且产品有 3 个以上复杂页面（课程详情、校区地图、报名表单），uniapp 依然值得——因为 HBuilderX 的调试体验和热重载效率比原生开发者工具更接近现代前端工作流。
v2.0.13 的前端改造建议锁定 Vue 3 语法组合式 API 风格。Vue 2 的生命周期函数在 uniapp 里能用，但新项目再入 Vue 2 等于给自己埋技术债，后续招聘前端接手时，Vue 3 的经验匹配度也更高。
2.2 按业务域拆分 pages 和 components，而不是按页面拆分
很多外包团队喜欢把 pages 下的每个文件夹都塞一个 components 目录，结果一个页面 5 个子组件，数据全靠 props 和 $emit 传，页面跳转参数一多就乱。教育培训小程序更适合按业务域拆：
src/ ├── pages/ │ ├── index/ # 首页（推荐位+今日课表） │ ├── course/ # 课程列表、课程详情、课程评价 │ ├── booking/ # 约课日历、报名表单、支付结果 │ ├── member/ # 学员卡、课时记录、订单列表 │ └── mine/ # 个人中心、设置、消息 ├── components/ │ ├── business/ # 业务级组件：CourseCard、CalendarPicker │ └── common/ # 通用组件：EmptyState、NavBar、PriceText ├── api/ # 按模块拆请求文件 ├── store/ # Pinia 状态管理 └── utils/ # 格式化、鉴权、埋点工具api 目录是这次重构的重点。很多培训机构的小程序是外包交付的，接口路径经常带 v1、v2 混用，而且有的接口返回{code:200}，有的返回{status:0}。前端必须在 request 封装层统一掉，而不是在每个页面里各自处理。v2.0.13 的代码评审里，我会专门看有没有页面直接调uni.request——凡是漏掉的，都说明封装层没贯彻。
2.3 状态管理只放跨页数据，课时和课程详情不要进 store
教育类小程序最容易犯的错是把课程列表整个塞进全局 store，理由是“切 tab 时不想重新加载”。这个思路在低频场景下成立，但课程列表会随时因为排课调整而变动，全局缓存反而造成“用户看到的课表和实际不一致”的客诉。
store 里只放四样东西：登录态信息、当前选中校区、报名草稿、订单支付状态。其他一切数据用页面级请求 + 本地 Storage 缓存，缓存时间不超过 10 分钟。
// store/member.js import { defineStore } from 'pinia' export const useMemberStore = defineStore('member', { state: () => ({ token: '', childList: [], // 当前账号绑定的学员 currentChildId: '', selectedCampusId: '' }), actions: { setToken(token) { this.token = token uni.setStorageSync('token', token) }, logout() { this.token = '' this.childList = [] this.selectedCampusId = '' uni.removeStorageSync('token') } } })这段代码里的childList是教育场景特有的一对多关系——一个家长账号可能绑定两个孩子。如果把 childList 放到页面级请求，切孩子之后所有页面都要重新请求；放 store 后，全局只需要一个currentChildId做参数传递。logout()动作专门清空 childList，避免账号切换后查看到上一个孩子的课时记录。
3. 核心业务模块：课程列表、报名提交与课时记录展示
3.1 课程列表页的分页加载和校区筛选联动
课程列表是教育小程序的流量入口，它的加载策略直接影响用户留存。常见的错误是下拉刷新时整页 loading，用户每动一次就闪一下白屏。v2.0.13 的前端推荐用“滚动容器内局部刷新 + 分页追加”。
页面结构上，把课程列表放进 scroll-view，而不是用 page 级 onReachBottom。这样做的原因是课程列表页通常顶部有校区筛选栏和分类 tab，如果用页面级滚动，校区切换会触发整个页面重建，体验比较割裂。
<template> <view class="course-page"> <!-- 校区横向滚动选择器 --> <scroll-view scroll-x class="campus-tabs"> <view v-for="campus in campusList" :key="campus.id" class="campus-tab" :class="{ active: selectedCampusId === campus.id }" @click="switchCampus(campus.id)" > {{ campus.name }} </view> </scroll-view> <!-- 课程列表滚动容器 --> <scroll-view scroll-y class="course-list" @scrolltolower="loadMore" > <CourseCard v-for="course in courseList" :key="course.id" :course="course" @click="gotoDetail(course.id)" /> <view v-if="loading" class="list-loading">加载中...</view> <view v-if="!hasMore && courseList.length" class="list-end">没有更多课程了</view> </scroll-view> </view> </template>对应的逻辑层要注意“校区切换时重置列表”与“分页加载时追加列表”是两个不同的分支，很多前端新手会把它们混在一起，导致切完校区后旧数据残留到新列表尾部。
const PAGE_SIZE = 10 async function switchCampus(campusId) { selectedCampusId.value = campusId pageNum.value = 1 courseList.value = [] hasMore.value = true await loadCourseList(true) } async function loadMore() { if (loading.value || !hasMore.value) return pageNum.value++ await loadCourseList(false) } async function loadCourseList(isReset) { loading.value = true try { const res = await courseApi.getList({ campusId: selectedCampusId.value, page: pageNum.value, pageSize: PAGE_SIZE }) if (isReset) { courseList.value = res.list } else { courseList.value.push(...res.list) } hasMore.value = res.list.length === PAGE_SIZE } finally { loading.value = false } }isReset参数是这段代码的关键设计：它区分了“替换列表”和“追加列表”两种形态。向后端传page和pageSize是最标准的做法，避免用 offset 风格带来的深分页性能问题。单元测试时重点验证一个边界：当res.list长度恰好等于 PAGE_SIZE 时，hasMore为 true；如果后端返回空数组，应立即把hasMore置为 false，否则会出现无限请求空页面。
提示：scroll-view 的
scrolltolower事件在内容不足一屏时不会触发。需要在页面 onReady 后主动调用一次loadMore()检查是否需要补位。
3.2 报名表单的校验策略与防重复提交
教育类小程序的报名表单字段比电商复杂：要选校区、选课程、选上课时间段、填学员姓名、年龄、家长联系方式，部分科目还要求选老师。字段一多，前端校验就容易变成巨长的 if-else。更好的做法是把校验规则表驱动化。
const rules = { childName: { required: true, message: '请填写学员姓名' }, childAge: { required: true, validator: (val) => { const age = Number(val) return age >= 3 && age <= 18 }, message: '学员年龄需在3至18岁之间' }, campusId: { required: true, message: '请选择校区' }, courseTimeId: { required: true, message: '请选择上课时间段' } }validator自定义函数给了扩展空间，比如暑期班的年龄上限可能放宽到 22 岁，业务侧只需改 rules 不必动表单组件代码。提交按钮要有两个锁：一个是 500ms 内的节流锁，另一个是请求进行中的isSubmitting状态锁。这两个锁不能互相替代——节流锁管的是用户手速，isSubmitting管的是服务端响应延迟期间的重复点击。
3.3 剩余课时和到期日的展示细节
课时数据是家长最敏感的信息，前端不能直接显示后端返回的秒级时间戳。统一做格式化是基本操作，但有三个容易忽略的点：到期日在 30 天内的需要显眼标记；剩余课时为 0 的卡片要引导去续费；课时单位可能是“节”也可能是“小时”，前端展示要支持单位切换。
export function formatRemaining(lesson) { if (lesson.remaining <= 0) { return { text: '课时已用完', type: 'danger' } } if (lesson.remaining <= 5) { return { text: `仅剩${lesson.remaining}${lesson.unit}`, type: 'warning' } } return { text: `剩余${lesson.remaining}${lesson.unit}`, type: 'normal' } }这段函数返回的是带语义的“三元组”，让模板层只做渲染不写判断逻辑。type 字段可以映射到 CSS 颜色类，warning 状态在卡片右上角加红点提示。v2.0.13 的版本里我建议在member页面新增一个“课时预警”区域，把 5 节以下的课程直接聚合展示，而不是让家长自己去翻每一门课的详情。
4. 微信小程序的差异化适配：动态标题、顶部导航与备案提示
4.1 动态设置页面标题的两种方式及其边界
微信小程序里uni.setNavigationBarTitle可以动态改页面标题，但教育类小程序有个特殊场景：课程详情页的标题如果写死成“课程详情”，分享出去后对方看到的就是一个毫无信息量的卡片。更合理的做法是进入页面后用课程名做标题。
onLoad(options) { if (options.id) { courseApi.getDetail(options.id).then(res => { uni.setNavigationBarTitle({ title: res.courseName }) }) } }需要注意：页面配置里的navigationBarTitleText是默认值，动态设置的优先级更高。此外onLoad里 setNavigationBarTitle 有延迟覆盖竞态问题——如果页面配置里也写了标题，动态设置偶尔会因为时序问题被配置值覆盖。规避办法是在页面的onReady里再调用一次。
v2.0.13 前端改善建议里，有一条值得加：首页的下拉刷新文案和导航栏标题可以随运营活动动态下发，比如机构做寒春联报时，标题从“XX教育”临时切换成“寒春联报9折”。通过接口下发标题，前端支持 fallback 默认值即可。
4.2 顶部导航栏的高度计算与安全区避让
教育类小程序的用户画像偏中年，手机型号分布很杂，从 iPhone SE 到各类 Android 千元机都有。自定义导航栏时不能写死height: 44px，要基于胶囊按钮位置动态计算。
// utils/navbar.js export function getNavBarInfo() { const systemInfo = uni.getSystemInfoSync() const menuButton = uni.getMenuButtonBoundingClientRect() const navBarHeight = (menuButton.top - systemInfo.statusBarHeight) * 2 + menuButton.height return { statusBarHeight: systemInfo.statusBarHeight, navBarHeight, menuButtonRight: menuButton.right } }这段计算的原理是：菜单按钮（胶囊）到状态栏顶部的距离，决定了导航栏上下留白，通常两侧留白相等，所以导航栏整体高度是「上留白 + 胶囊高度 + 下留白」，而上留白约等于下留白，因此用(menuButton.top - statusBarHeight) * 2 + menuButton.height。这比网上很多直接加 20px 的写法规避了 Android 全面屏和 iOS 灵动岛的差异。
自定义导航栏的组件里，padding-top用状态栏高度，height用 navBarHeight。注意uni.getMenuButtonBoundingClientRect()只能在微信小程序端调用，H5 端要加条件编译做降级处理。
4.3 小程序备案备注信息的前端关联
热词里提到“小程序备案备注信息怎么填”，这个虽然偏运营操作，但前端在提审时需要配合：如果机构类型是民办非企业单位，前端页面底部必须展示备案号，而且要能点击跳转到备案详情页。这个展示不是静态写死的，建议在app.vue的onLaunch里拉取一次配置，存到全局 store，由页面通用组件IcFooter统一渲染。
// api/config.js export function fetchSiteConfig() { return request({ url: '/api/site-config', method: 'GET' }) }IcFooter组件接收icpRecord和policeRecord两个字段。只有备案通过后，接口返回的内容才非空；提交审核前若备案还在流程中，前端可隐藏该区域。这保证提审截图里不会出现“备案号位置空白”的尴尬状态。
5. 提审前的体验调优：启动速度、骨架屏与加载页改造
5.1 修改刚进入的加载页面，把同步阻塞改为异步初始化
“修改刚进入的加载页面”是微信小程序优化的长期话题。很多教育类小程序的第一个页面是splash或loading，里面setTimeout3 秒再跳转，这种写法在 v2.0.13 里必须改掉。
正确的思路是：取消独立 loading 页，首页直接变成内容页；数据没回来时渲染骨架屏，数据回来后渐进填充。从用户视角看，小程序秒开且内容逐步出现；从技术视角看，减少了一次无意义的页面跳转。
// pages/index/index.vue onLoad() { this.loadInitData() } async loadInitData() { const [bannerRes, courseRes] = await Promise.allSettled([ bannerApi.getList(), courseApi.getTodayList() ]) if (bannerRes.status === 'fulfilled') { this.bannerList = bannerRes.value } if (courseRes.status === 'fulfilled') { this.todayCourseList = courseRes.value } this.isReady = true }Promise.allSettled比Promise.all更适合这里：banner 接口失败不应阻塞课表渲染。如果某个接口挂了，局部显示空态即可。骨架屏的实现不需要引第三方库，用 CSS 动画配合v-if就能做到。
5.2 首屏资源的压缩策略和分包加载
教育培训小程序通常有大量课程封面图和机构环境照片，图片体积是首屏性能的主要瓶颈。v2.0.13 前端可以选三条线同时做：接口返回的图片 URL 裁剪尺寸、本地静态图片转 WebP、必要的大图走 CDN 懒加载。
分包方案上，把报名流程和支付结果页放进subPackage，首页和课程列表留在主包。微信小程序的规则是主包最大 2MB，v2.0.13 如果出现“包体积超限”报错，优先拆掉member下的历史订单列表、电子发票页面这些低访问频率页面。
5.3 性能面板查看哪些指标
提审前，打开微信开发者工具的“性能”面板，切换网络为 Slow 3G，重点看三项指标：
- 首次渲染完成时间：指首页骨架屏或首个有效像素出现的时间，建议 2 秒以内
- 首次可交互时间：用户能点击跳转的时间，建议 3 秒以内
- 请求数瀑布图：页面启动后 2 秒内发起的请求数越少越好，超过 10 个要警惕
如果首次渲染时间过大，优先检查app.vue的onLaunch里有没有同步请求。常见误区是把配置拉取放在onLaunch里且不用 Promise 包裹，导致所有页面的onLoad都在等这个响应。
6. v2.0.13 增量发布的版本管理、灰度监控与回滚快照
6.1 用版本号驱动前端缓存更新
小程序发版后，用户端的缓存更新一直是个麻烦问题——微信不会强制所有用户立刻切到新版，而是渐进覆盖。v2.0.13 的前端代码里，可以主动引入“版本检测”逻辑：在启动时拉取最新版本号接口，和本地 Storage 里的版本号比对，不一致就提示用户手动重启小程序。
// app.vue onLaunch() { const localVersion = uni.getStorageSync('app_version') configApi.getVersion().then(res => { if (res.version !== localVersion) { uni.showModal({ title: '版本更新', content: '检测到新版本，请重启小程序获取最新功能', showCancel: false, success: () => { uni.setStorageSync('app_version', res.version) } }) } }) }这里有个细节：不要自动调用uni.reLaunch强行刷新，因为用户在填写报名表途中被强制刷新，草稿会丢。提示让用户自己决定重启时机，体验更平滑。版本号接口的返回建议带isHotfix字段——如果只是代码层面热修复，没有新增字段，可以只提示不比对版本。
6.2 灰度策略：按白名单和按校区灰度
v2.0.13 这类版本的灰度通常有两层。第一层按机构内部白名单：把教务老师的微信号加入后端白名单，前端判断is_tester字段后访问测试环境接口；第二层按校区批次放量：只在某个体验店逐步放量，观察接口错误率和用户反馈，24 小时平稳后再全量。
灰度期间前端需要配合做一件事：在页面埋点里带上version字段，否则后端看到报错无法判断是哪个版本。埋点字段推荐统一为：
app_version: 2.0.13 platform: wechat-miniprogram os_version: iOS 17.2 / Android 146.3 回滚的快照机制和前端应急开关
小程序的发布不同于 App，代码回滚只需要在微信公众平台选择“退回上一版本”，但这个动作需要几个小时的生效周期。更可靠的做法是给前端加远程开关：后端配置中心下发course_list_show、booking_enabled等 boolean 字段，前端每次启动拉取。
const featureFlags = reactive({ bookingEnabled: true, showReferralEntry: false }) async function loadFeatureFlags() { const res = await configApi.getFeatureFlags() Object.assign(featureFlags, res) }当线上出问题时，运营可以在不发布代码的情况下直接关掉报名入口，在页面上显示“系统维护中”。这样操作响应速度以秒计算，远比等微信审核回归快。注意 fallback 逻辑：如果getFeatureFlags请求失败，默认值必须是“全开启”，否则一个网络抖动就会导致业务全挂。
版本发布后 48 小时内，前端开发要盯三个指标：页面 JS 报错率（高于 0.5% 立刻查）、报名提交成功率（低于 99% 立即回滚）、接口 4xx/5xx 比例。这三个指标都正常，v2.0.13 才算真正完成线上收口。
本文还有配套的精品资源，点击获取
