说实话刚接到这个需求的时候我差点把它当成一个普通的CRUD项目来做——少儿编程培训机构要选课、报名、交作业、管学员听起来不就是一个后台加一个家长端小程序吗真把原型捋完才发现这里头的水比想象中深得多家长选课要考虑同一时间段的排课冲突、名额不能超卖老师布置作业要处理代码文件和图片上传机构端还要盯着微信支付的合规门槛更不用说后面上架审核那一堆事。这篇就记录我用 vue uniapp 从零搭一套少儿编程培训机构选课报名作业系统管理小程序的完整过程从业务模型、技术选型、核心链路实现到各种绕不开的坑一次性拆开讲清楚。准备接手这类教育项目、或者打算给自家机构做小程序的开发者和教务负责人都可以拿这篇当参考。1. 先画清业务地图三类角色、六张核心表和边界取舍做任何系统第一步都不是写代码而是把业务方摆到同一张桌子上确认谁在什么端上做什么事。这个环节省掉了后面改需求的时候流的就是眼泪。少儿编程培训机构和普通K12学科机构还不太一样课程通常按阶段划分图形化启蒙、Python、C竞赛等班次固定、每周一次课作业以代码和作品截图为主。这些特点直接决定了数据模型和页面设计。1.1 用户角色拆解谁在什么端上做什么事我把系统里的用户分成了三类每一类的工作频率、操作场景、设备习惯完全不同直接混搅在一个界面里一定会出问题。角色使用端核心动作家长/学生微信小程序浏览课程、选课报名、在线支付、查看作业、提交作业、查看评语老师小程序 H5后台维护班次、确认名单、布置作业、批改作业、发送通知教务运营H5后台课程上架、名额设置、订单管理、异常退款、数据统计家长端主要在手机上追求的是下单路径短、提交作业顺畅老师端反而更适合在电脑上操作因为批改代码作业的时候要盯着大屏而且经常要复制代码片段、查看图片教务端则要处理批量导入和表格核对操作密度高不适合塞进小程序里。所以第一版我没有把三个角色全挤在一个小程序里而是做成家长小程序 老师/运营H5后台的组合。有人可能会问老师为什么不用企业微信我们一开始也想过但现实是机构老师流动性不小企业微信授权和离职交接的流程比独立账号重一个简单的H5反而更轻。这套vue和uniapp的代码其实是同一个仓库通过打包平台区分入口接口全部共用开发增量很小。1.2 核心数据模型六张表把业务串起来业务方讲需求的时候容易跳跃语速快信息像流水一样但落到表上就特别清晰。少年编程这个项目的核心表我归纳为六张课程表、班次表、选课表、订单表、作业表、提交表。course课程表id、课程名称、分类图形化/Python/C、封面图、价格、总课时、适用年龄、课程介绍。这里要注意家长买的是课程不是班次这是一个认知差异。class_schedule班次表id、course_id、周几上课、开始时间、结束时间、开课日期、结课日期、教室、最大人数、剩余名额。少儿编程的特点是同一门课会有多个班次比如Python入门周六上午一班、周日下午一班。把班次单独拆出来后面换班、插班、课消统计都会轻松很多。enrollment选课表id、student_id、schedule_id、状态正常/退课/结课、报名时间、created_at。这是一张关联表和状态表也是冲突检测的对象。order订单表id、订单号、student_id、金额、支付状态、微信prepay_id、微信交易单号、支付时间、退款状态。订单和选课表是一对一关系报名成功的前提是订单状态变成已支付。homework作业表id、teacher_id、schedule_id、作业标题、作业内容、截止时间、作业类型客观题/代码题/作品图。作业挂在班次上而不是挂在课程上因为同一个课程不同班次的进度可能不一样。submission提交表id、homework_id、student_id、提交内容、附件URL、得分、老师评语、批改状态、提交时间。这六张表的第一版我刻意保持了简洁没急着加领域模型、多态关联这些概念。教育机构业务日常变动快表结构过度设计往往到后面只会成为改造的负担。只要字段能表达一个学生在一个班次上、交了一次作业、产生了一笔订单这三条主线就够用了。1.3 边界取舍第一版不做这些反而走得更快软件项目最大的风险不是功能少而是做了一堆用不上的功能把核心路径拖慢。这个项目我明确砍掉了三个东西第一砍掉课消统计报表。机构老板肯定想看这个月消耗了多少课时、还有多少待消耗但第一版我建议用Excel过渡因为课消规则试听课算不算、请假顺延怎么算需要机构自己磨合软件做早了规则一变就是白做。第二砍掉复杂的排课算法。智能推荐最优班级听起来很酷但真正推动家长选班的往往是时间、距离和老师口碑。第一版只需要把同一个时间段已满员的班置灰把剩余名额展示清楚就完成了80%的需求。第三砍掉多校区支持。如果机构只有一个总校多校区完全是额外复杂度等有二校区再动也来得及前提是数据模型里校区字段一开始就留着但不用为它专门做界面。边界定清楚以后整个开发周期就可以压到一个月左右。后面几章讲的都是第一版必须做扎实的事尤其是选课报名和作业闭环这两条主线。2. vue3 uniapp组合式API的项目骨架目录划分、登录态与路由拦截技术选型看起来是第一步其实在梳理业务的过程中就已经确定了。这个项目我选的是 vue3 组合式API 加 uniapp后端用现成的 Node.js 或 Java 都行重点是前端这套骨架。很多教程讲 uniapp 都是从新建项目开始容易让人忽略真正决定项目舒服与否的是目录结构和工程规范。2.1 技术选型的三个理由多端复用、组合式API、生态成熟度先说多端复用。家长端跑在微信小程序上老师端如果也想在手机上临时看一眼App/H5 都要能跑。uniapp 一套代码编译到小程序、App、H5这个价值在这个项目里被放得很大因为除了家长微信小程序老师端偶尔会在手机浏览器里处理紧急批改机构公众号里也可能嵌 H5 页面。如果分别写两套维护成本直接翻倍。再说 vue3 组合式API。有一说一选项式写法在小页面里很直观但一旦涉及订单状态流转、选课表单校验、作业提交进度这种逻辑同一个功能的代码会散落在 data、methods、watch 里看代码要来回跳。组合式API最大的优势是可以按业务维度抽函数比如把订单创建和支付状态封装成 useOrder()把登录和 token 刷新封装成 useLogin()页面里五行代码就完事。这也是 vue 面试里经常被问到的选项式和组合式区别的实际意义真做一个教育业务项目你会明显感受到组合式API对复杂状态的整理能力。最后是生态。uni-ui 组件库覆盖表单、列表、弹出层这些常见场景微信小程序端有大量现成插件支付、分享、扫码的能力都是封装好的。遇到问题社区资料也比冷门框架多对项目周期短的团队来说趟坑成本是个很现实的考量。2.2 初始化项目时容易被忽略的两件事第一件用 CLI 创建项目而不是直接用 HBuilderX。不是说 HBuilderX 不好它对单兵作战很友好但团队协作时 CLI 工程可以用 git 管理、可以跑 CI、可以固定依赖版本HBuilderX 的可视化界面在两人以上协作时就容易出幺蛾子。创建命令就是常规的npx degit dcloudio/uni-preset-vue#vite my-project装完依赖就能跑。第二件manifest.json 的配置要提前填完整。微信小程序 appid 要真实填写否则运行到微信开发者工具后无法调试真机App 端要提前配置隐私政策弹窗文案iOS 审核如果在启动 App 时没有弹隐私协议直接就是审核不过。权限声明只声明真正用到的比如相册、摄像头不要偷懒全部勾上会让审核变得更麻烦。我用的目录结构长这样src/ ├── api/ # 接口请求层按模块拆分 │ ├── course.js │ ├── order.js │ └── homework.js ├── composables/ # 组合式函数 │ ├── useLogin.js │ ├── useOrder.js │ └── useHomework.js ├── components/ # 通用组件 │ ├── CourseCard.vue │ └── HomeworkItem.vue ├── pages/ │ ├── course/index.vue │ ├── course/detail.vue │ ├── order/confirm.vue │ ├── order/result.vue │ └── homework/submit.vue ├── static/ ├── store/ # pinia 状态 └── utils/ └── request.js这个结构的关键在于 composables 和 api 的边界api 只负责 HTTP 请求的封装composables 负责业务逻辑的组装。比如 useOrder() 里会调用 api/order.js 的接口但页面不需要关心到底请求了哪个接口它只关心当前订单状态是什么、要不要跳转支付。2.3 登录态与会话保持拦截器统一处理路由守卫uniapp 的路由不是 vue-router而是靠 pages.json 里的页面配置和 uni.navigateTo 这类API。所以不能按 vue-router 的习惯写全局前置守卫得用 uni.addInterceptor 来做登录拦截。小程序端登录我用的还是标准流程uni.login 取 code传给后端后端调微信接口换 openid 和 session_key再把自定义 token 返回来前端存到 storage 里。拦截器写法import { useUserStore } from /store/user const authInterceptor { invoke(args) { const userStore useUserStore() if (!userStore.token) { uni.navigateTo({ url: /pages/login/index?redirect encodeURIComponent(args.url) }) return false } return true } } // 在 main.js 中注册 uni.addInterceptor(navigateTo, authInterceptor) uni.addInterceptor(redirectTo, authInterceptor) uni.addInterceptor(switchTab, authInterceptor)这里有三个细节需要注意。一是 switchTab 也必须拦截因为 tabBar 页面无法用 navigateTo 跳转跳登录页之前要先把当前路径记录下来登录成功后再用 uni.switchTab 回跳。二是回调地址要 encodeURIComponent否则路径上如果带 query 参数还原的时候会解析错乱。三是 uniapp 中获取路由参数是通过onLoad(options)获取的options 里所有的值默认是字符串而且如果来源页面传参时没编码遇到特殊字符比如 url 里的 就会截断。所以我通常在传参时统一做一次 encodeURIComponent接收时再 decodeURIComponent这个习惯能帮你避开无数诡异bug。3. 选课报名主链路课程展示、冲突检测、名额锁定与微信支付选课报名是整个系统最重要的业务闭环没有之一。家长打开小程序看到课程列表点进详情选一个合适时间的班次提交订单微信支付支付成功后才算完成报名。这一条链路里几乎每一个环节都有坑我把核心思路和代码逻辑拆开说。3.1 课程列表与详情分页加载和试听视频课程列表页是家长的第一印象不要一屏加载所有数据。用 onReachBottom 触底加载下一页一次十条配合骨架屏显示。列表页的课程卡片上要把价格、剩余名额、适用年龄这些关键信息直接露出来减少家长点进详情才知道价格的挫败感。课程详情页的核心是视频试听。少儿编程的课程要不要买家长很看重试听课的感受。视频播放这里用 uniapp 的 video 组件播放 m3u8 地址是可以直接支持的你只需要把后端给到的 m3u8 地址丢给 video 的 src 属性。但这里要注意一个微信小程序的特殊点如果视频域名没有在小程序后台配置到 downloadFile 合法域名里真机上会播放失败开发工具里反而正常。另外在部分安卓机型上小程序的 video 组件对 hls 流兼容一般如果机构有转码条件建议同时提供一个 mp4 地址作为降级或者在域名配置里把点播服务的域名都加全。还有个小经验详情页不要上来就自动播放视频会触发小程序端的音频/视频审核限制首屏重点还是课程大纲、适龄范围和价格试听视频放在课程介绍下方让家长主动点。3.2 选课核心约束时间冲突检测与防超卖设计家长选了一个班次后服务端要做两件重要的事检查这个孩子有没有报过同一时间段的课以及这个班次还有没有名额。这两个逻辑必须在服务端做不能依赖前端判断。时间冲突检测的思路是查这个学生当前所有状态为正常的选课记录关联出对应班次的上课时间周几、开始时间、结束时间然后判断目标班次是否与其中任何一个时间段重叠。SQL片段大概是SELECT cs.id, cs.weekday, cs.start_time, cs.end_time FROM enrollment e JOIN class_schedule cs ON e.schedule_id cs.id WHERE e.student_id ? AND e.status active拿到这批时间段后在代码里逐一判断目标班次的 weekday 和起止时间这里不能只看日期因为少儿编程班是每周固定一次课跨多周持续同一周几的时间段冲突才有意义。名额防超卖是另一个高频bug点。家长同时有两个手机在选同一个班如果只靠先查剩余名额再减一的普通逻辑并发场景下必然超卖。正确做法是在数据库层面做原子扣减UPDATE class_schedule SET remaining_quota remaining_quota - 1 WHERE id ? AND remaining_quota 0如果影响行数为 0说明名额已经被抢完直接返回该班次已满员。把这个 update 和创建订单放在同一个事务里就能保证扣名额和创建订单的一致性。我见过不少项目是先创建订单再扣名额结果用户支付超时订单取消名额还扣着不释放后面还得写定时任务补偿完全没必要。3.3 订单状态机与微信支付对接细节订单状态我设计了四个待支付、已支付、已取消、已退款。状态流转只有四条合法路径当前状态触发动作下一状态待支付用户主动取消已取消待支付支付超时30分钟已取消待支付微信支付成功回调已支付已支付教务后台退款已退款拒绝了已取消再变回已支付这类非法流转。这个状态机表面简单但能挡住非常多的脏数据。前端发起支付的关键代码// 创建订单后拿到支付参数 const payment await request({ url: /api/order/pay, method: POST, data: { orderId: orderInfo.id } }) uni.requestPayment({ provider: wxpay, timeStamp: payment.timeStamp, nonceStr: payment.nonceStr, package: payment.package, signType: payment.signType, paySign: payment.paySign, success: () { // 支付成功但这里不要急着改订单状态 // 真正的状态变更以服务端回调为准 uni.redirectTo({ url: /pages/order/result?id orderInfo.id }) }, fail: (err) { // 处理用户取消支付 / 支付失败 } })很多人第一次对接微信支付时会在前端拿到 success 之后就更新 UI 为已支付但前端 success 只能说明用户输密码的流程走完了服务端回调才是确定钱到账的唯一依据。所以我的做法是前端跳转到支付结果页结果页先显示支付确认中然后靠轮询后端订单状态接口拿到已支付再刷新界面。这样既不会因为回调延迟显示错误状态也不会在前端伪造支付结果时造成安全问题。3.4 支付合规不想让支付功能被关停这几件事必须做这个章节值得单独拎出来说因为小程序支付被限制的案例实在太多了。微信小程序的支付权限本质上是一个平台风控能力不是像App那样随便申请的。项目开工之前就要确认主体资质小程序账号的主体要和机构营业执照一致教育类目需要提供对应的办学资质或备案材料类目不要乱选。支付功能上线后也要注意不能诱导用户虚假交易、刷单不能出现支付后返现这类诱导分享行为。一旦小程序被投诉或触发风控后台就会提示由于小程序违规支付功能暂时无法使用这种限制不是代码层面的问题要联系微信客服处理处理周期通常不短。所以我的建议是支付相关的代码尽量按微信官方要求写前端在 requestPayment 之前检查一下 customer 端的配置后端回调接口一定要验签该做的都会做不该做的别碰。合规经营对教育机构尤为重要因为家长都很看重机构的稳定性和信誉。项目里如果涉及退款流程也要走正规退款接口不要私下在后台改状态退款不合规也会被风控盯上。4. 作业模块三端数据流转布置、提交、批改、通知选课报名的闭环只是第一步真正把家长和机构黏在一起的其实是作业系统。少儿编程课程如果上完课就结束家长很难感知到学习效果只有老师布置了作业、孩子交了作业、老师给了评语这一连串反馈才能让家长觉得钱花得值。同时作业也是老师掌握进度的关键手段。4.1 作业的数据结构一个作业如何关联班次和学生作业挂在班次class_schedule上而不是挂在单个学生上。因为同一门课不同班次的进度可能不同周二班学到变量周六班还在学循环老师是按班布置作业的。作业表里记录是哪个老师在哪个班次布置的、内容是什么、截止时间是什么时候。作业的类型会影响前端交互我在数据结构里用 type 字段区分objective选择题/判断题学生端直接点选项老师批改时看正确率即可code代码题学生端粘贴代码老师端以文本形式查看image作品截图/成果图学生端上传图片老师端大图查看这个分类决定了不同页面渲染什么组件但不影响核心状态流转。作业之后是提交表一个学生一次作业对应一条提交记录。为什么单独拆出来因为不是所有学生都会在第一次就提交老师还要打回让学生修改重交提交表的多版本设计我放到了4.2节讲。4.2 学生端提交的真实交互图片上传、代码粘贴与草稿机制学生端提交作业最轻的入口是我拍个代码截图或者我把话画出来。少儿编程的孩子年龄普遍在6到14岁之间不能要求他们打字打太多所以提交页面要尽量降低输入成本。图片上传用 uni.chooseImage 选图或拍照一次最多9张然后逐个调 uni.uploadFile 上传到对象存储全部成功后把 URL 数组提交到服务端。代码上传部分一般思路是直接给一个大 textarea 让孩子粘贴代码。但实践经验是对于6-10岁的孩子粘贴代码往往会出现多余空格或标签家长们也不一定懂怎么格式化。所以代码题我建议做成上传 .py 文件 预览的形式或者做成粘贴 自动去除首尾空白的格式。至少让家长在电脑上把代码文件发到微信里再从文件里粘贴到 textarea方便很多。图片和代码一起提交的时候要处理并发和进度。我一般给每个文件建一个上传任务用 Promise.all 等全部完成const uploadTasks tempFilePaths.map((filePath, index) { return new Promise((resolve, reject) { uni.uploadFile({ url: https://api.example.com/upload, filePath: filePath, name: file${index}, success: (res) { try { const data JSON.parse(res.data) resolve(data.url) } catch (e) { reject(e) } }, fail: reject }) }) }) const urls await Promise.all(uploadTasks)这里有一个很实际的体验问题孩子写作业经常写到一半被打断家长关掉小程序就白填了。所以我会在提交页面定时把表单内容和已上传的图片列表存到本地 storage下次打开页面时自动填充。这个成本很低但对家长体验的改善非常明显。4.3 批改与通知闭环订阅消息的正确用法老师批改作业时在 H5 后台打开提交记录看到学生的提交内容打一个分数写两句评语点保存。批改完成以后学生的提交状态变成已批改这时候可以给家长发一条微信订阅消息告诉他孩子的作业已批改快来看看成绩吧。这里涉及到订阅消息的长期可复用问题。微信小程序的订阅消息一种是长期订阅一种是一次性订阅。教育类目很容易申请一次性订阅授权也就是家长在小程序里主动点一次允许接收作业提醒系统才能发一条消息。这个能力用起来有个前提必须在用户点击了某个按钮比如提交作业时立即调 uni.requestSubscribeMessage 申请授权而且用户点了总是保持以上选择以后后面的授权才能自动通过。如果用户在设置里关了通知那消息就没法触达了。所以我在提交成功页面放了一个开启作业完成提醒的按钮点击时申请订阅消息授权这样能保证授权来源自然也能提高后续消息的到达率。还有一点不要设计得过于激进提交一次就弹一次授权框微信会把这种行为判为骚扰轻则模板消息失效重则小程序被限制服务。5. 上线前绕不开的坑从支付合规到打包审核的排查实录这个章节是踩坑实录都是实际项目里遇到并且解决过的问题按主题列出来每个都附排查思路。要知道这类教育管理小程序用户量可能不大但出问题的容忍度极低家长点两下没反应转头就在机构微信群里吐槽。5.1 微信支付被限制该怎么排查支付功能突然用不了先不要慌按顺序排查。第一步登录微信公众平台查看站内信或违规记录确认是不是收到了限制通知如果是平台主动限制后台一般有原因和申诉入口。第二步检查小程序类目与支付场景是否匹配教育类目如果选成了普通百货类风控容易误判。第三步排查交易数据近期有没有大额、高频、来源集中在同一账号的交易有没有被用户投诉退款的记录这些都会触发风控。最后一步才是看代码确认 requestPayment 调用的参数签名是否正常。前几步没走完就怀疑代码容易被带偏。5.2 输入框被软键盘顶飞、遮挡查询内容这个问题在微信小程序里太典型了。家长在查询作业页面想搜索某个关键词手机软键盘一弹出来底部的内容被遮住严重的会把 fixed 定位的按钮顶上去。常见网上说法是设置 input 的 adjust-position 属性为 true实测下来部分安卓机型上完全无效原因是页面里有 fixed 定位元素或者 web-view 混排时编译后的原生组件层级和普通标签不一样。我的解决办法是查询页面里不要用 fixed 底栏而是用普通流式布局把按钮放在输入框下面输入框加 cursor-spacing10 留出光标距底部的安全距离如果页面有多个输入项用 scroll-into-view 在聚焦时把当前输入项滚动到可视区域。小程序端如果基础库版本够高还可以用 onKeyboardHeightChange 监听键盘高度手动调整列表的 padding-bottom这个方案最稳但工作量稍大我一般留到客户强制要求时再做。5.3 分享功能与全局 onShareAppMessage 的冲突微信小程序的分享以前需要在每个页面写 onShareAppMessage后来可以全局配置菜单。但实际开发时有个很隐蔽的坑App.vue 里如果给 onShareAppMessage 做了全局封装某些页面的自定义分享参数会失效显示出来的分享卡片标题、图片不是自己期望的。原因很简单微信小程序的 onShareAppMessage 只认页面组件里的定义App.vue 里的定义在某些基础库版本下会干扰页面级的声明。我排查过一次最后把全局分享逻辑改成 mixin 方式定义一个 sharedMixin统一处理默认的分享标题和图片页面引入这个 mixin 后再单独重写 onShareAppMessage 合并自定义参数。这样既保证了默认分享可用又不互相覆盖。如果只想让指定页面能分享就在 page 级别的 onShareAppMessage 里返回一个空对象微信默认会带上当前页面截图作为分享图效果也还行。5.4 扫码结果是一串数字先分清码制和业务场景项目里有一个扫码签到功能老师扫学生卡上的二维码快速点名。有一回测试返回的 result 一直是一串纯数字而不是预期中的学生ID逻辑怎么都对不上。后来排查发现物理学生卡上印的是 Code128 条形码不是 QR 二维码uni.scanCode 扫到的 result 就是条形码本身的内容而条形码内容恰好是一串学号。问题不在代码而在码制选择上。这个经验提示先确认机构已有的卡是什么码制再决定扫什么码。如果是 qrCode前端可以直接用如果是条形码小程序也支持但需要注意拍摄距离和对焦。还有一种是扫出来是一串数字但是二维码这时候就要怀疑码的内容是不是被其他系统编码了比如自定义加密或 ID 做了映射需要去后端查一下二维码生成逻辑。5.5 安卓应用市场上架隐私政策、软著与不同意退出的实现如果这个小程序以后要打包成安卓 App 上架应用市场事情会变多但核心是这三个软件著作权、隐私政策和备案。每个市场的软著要求不太一样但基本上都要提前准备别等到要上架了才去申请软著下证周期可以按一到两个月预估。隐私政策弹窗是所有应用市场的硬性要求用户首次打开 App 时必须弹窗用户同意之前不能初始化任何涉及个人信息的 SDK。这里对应一个热搜词场景iOS 用户不同意隐私政策及用户协议时怎么退出 App。代码逻辑是弹窗点击不同意时调用 plus.runtime.quit() 退出应用。注意这里有个审核细节iOS 审核其实不建议强制退出更推荐做法是仅退出到设置页让用户重新选择但很多机构为了简单直接仍然采用二次确认后退出应用的做法。如果你要做 iOS 包我建议按平台规范来避免审核被拒。uni.showModal({ title: 提示, content: 需要同意隐私政策后才能继续使用, showCancel: false, confirmText: 同意, success: (res) { if (res.confirm) { // 用户同意后继续初始化 } } }) // 如果用户点击不同意在按钮回调里调用退出还有一个现象很常见uniapp 项目在 HBuilderX 里运行到微信开发者工具点了运行半天没反应控制台也没报错。这时候十有八九是微信开发者工具的服务端口没开。打开微信开发者工具的设置-安全设置把服务端口打开再重新运行就能连上了。这个坑很多人能跳过去但也真的能卡住半天。5.6 前端安全底线密钥别进代码回调必须验签这类机构类系统最容易忽略安全因为用户量不大就觉得无所谓。但涉及支付和家长信息安全性一点不能妥协。第一小程序的 AppSecret 绝对不能出现在前端代码里小程序代码可以被反编译明文密钥等于裸奔。后端通过 code 换 session_key 时才需要用到 AppSecret这一步强制放在服务端。第二所有涉及角色权限的接口前端传的我是老师不可信权限判断必须在服务端根据登录态完成。第三支付回调接口必须做微信支付 v3 的验签处理用微信支付平台证书验证回调请求的签名而不是简单地校验一下回调里传来的成功字段。如果没有验签攻击者直接伪造回调通知就能把订单改成已支付而这个漏洞很容易被忽略。6. 性能与体验优化分包、列表、媒体与弱网教育业务小程序对性能的容忍度其实很低家长在小程序里打不开课程视频或者列表加载转圈超过三秒马上就流失了。这个项目规模不大但性能优化的思路还是值得按完整链路走一遍。6.1 主包瘦身与分包加载微信小程序有主包和分包的大小限制主包要控制体积。我的做法是把所有老师端页面、订单结果页这类低频页面拆到分包里主包只保留 tabBar 页面和公共组件。在 pages.json 里配置 subPackages{ subPackages: [ { root: pages/teacher, pages: [ pages/teacher/homework-list, pages/teacher/homework-detail ] } ] }这样主包体积能明显下降冷启动速度会快很多。对于少儿编程机构这种用户分布比较集中的场景首屏加载够不够快直接决定了家长愿不愿意进来逛。6.2 列表渲染性能与状态管理注意课程列表页如果一次渲染很多卡片在低端安卓机上会有明显卡顿。列表项必须加 :key并且不要在模板里写复杂的方法调用比如在 v-for 里写{{ formatPrice(item.price) }}每次渲染都会全量执行一遍数据多了就拖帧。这种计算放到 computed 或 filter 里面让数据提前处理好模板只做展示。另外不是所有数据都需要进全局 store。有些页面之间的共享状态比如当前选择的班次ID用页面参数传就完了没必要放到 pinia 里。store 里的数据一旦过多复杂度和调试成本都会上升这在教育项目的快速迭代期是负担。我当时只把用户信息和未读作业数放进了 store其他都是按需请求。6.3 图片视频资源与弱网兜底课程封面、老师头像、作业提交图片这些资源都要走 CDN并且后端在做图片上传时生成缩略图列表页加载缩略图详情页再加载原图。视频资源不要直接放原片用点播服务的转码能力输出多个清晰度家长在2G/3G环境下自动选低清晰度在WiFi下选高清。弱网兜底主要体现在提交作业这个场景。家长在停车场或者电梯里提交作业请求很容易失败要给提交按钮加一个提交中的 loading 状态并且失败时保留表单内容允许用户重试而不是把内容清空重填。这个细节其实和草稿机制是配套的做好了家长的体验会非常稳定不会因为有一次上传失败就再也不用了。其次我强烈建议在请求封装层做统一的错误提示让后端接口返回统一的错误码前端统一弹 toast。对接几十个接口以后你一定会感谢当初做了这个统一封装。到了后期如果接口跨服务了加一个请求日志中间件也能快速排查问题。全文完
说实话刚接到这个需求的时候我差点把它当成一个普通的CRUD项目来做——少儿编程培训机构要选课、报名、交作业、管学员听起来不就是一个后台加一个家长端小程序吗真把原型捋完才发现这里头的水比想象中深得多家长选课要考虑同一时间段的排课冲突、名额不能超卖老师布置作业要处理代码文件和图片上传机构端还要盯着微信支付的合规门槛更不用说后面上架审核那一堆事。这篇就记录我用 vue uniapp 从零搭一套少儿编程培训机构选课报名作业系统管理小程序的完整过程从业务模型、技术选型、核心链路实现到各种绕不开的坑一次性拆开讲清楚。准备接手这类教育项目、或者打算给自家机构做小程序的开发者和教务负责人都可以拿这篇当参考。1. 先画清业务地图三类角色、六张核心表和边界取舍做任何系统第一步都不是写代码而是把业务方摆到同一张桌子上确认谁在什么端上做什么事。这个环节省掉了后面改需求的时候流的就是眼泪。少儿编程培训机构和普通K12学科机构还不太一样课程通常按阶段划分图形化启蒙、Python、C竞赛等班次固定、每周一次课作业以代码和作品截图为主。这些特点直接决定了数据模型和页面设计。1.1 用户角色拆解谁在什么端上做什么事我把系统里的用户分成了三类每一类的工作频率、操作场景、设备习惯完全不同直接混搅在一个界面里一定会出问题。角色使用端核心动作家长/学生微信小程序浏览课程、选课报名、在线支付、查看作业、提交作业、查看评语老师小程序 H5后台维护班次、确认名单、布置作业、批改作业、发送通知教务运营H5后台课程上架、名额设置、订单管理、异常退款、数据统计家长端主要在手机上追求的是下单路径短、提交作业顺畅老师端反而更适合在电脑上操作因为批改代码作业的时候要盯着大屏而且经常要复制代码片段、查看图片教务端则要处理批量导入和表格核对操作密度高不适合塞进小程序里。所以第一版我没有把三个角色全挤在一个小程序里而是做成家长小程序 老师/运营H5后台的组合。有人可能会问老师为什么不用企业微信我们一开始也想过但现实是机构老师流动性不小企业微信授权和离职交接的流程比独立账号重一个简单的H5反而更轻。这套vue和uniapp的代码其实是同一个仓库通过打包平台区分入口接口全部共用开发增量很小。1.2 核心数据模型六张表把业务串起来业务方讲需求的时候容易跳跃语速快信息像流水一样但落到表上就特别清晰。少年编程这个项目的核心表我归纳为六张课程表、班次表、选课表、订单表、作业表、提交表。course课程表id、课程名称、分类图形化/Python/C、封面图、价格、总课时、适用年龄、课程介绍。这里要注意家长买的是课程不是班次这是一个认知差异。class_schedule班次表id、course_id、周几上课、开始时间、结束时间、开课日期、结课日期、教室、最大人数、剩余名额。少儿编程的特点是同一门课会有多个班次比如Python入门周六上午一班、周日下午一班。把班次单独拆出来后面换班、插班、课消统计都会轻松很多。enrollment选课表id、student_id、schedule_id、状态正常/退课/结课、报名时间、created_at。这是一张关联表和状态表也是冲突检测的对象。order订单表id、订单号、student_id、金额、支付状态、微信prepay_id、微信交易单号、支付时间、退款状态。订单和选课表是一对一关系报名成功的前提是订单状态变成已支付。homework作业表id、teacher_id、schedule_id、作业标题、作业内容、截止时间、作业类型客观题/代码题/作品图。作业挂在班次上而不是挂在课程上因为同一个课程不同班次的进度可能不一样。submission提交表id、homework_id、student_id、提交内容、附件URL、得分、老师评语、批改状态、提交时间。这六张表的第一版我刻意保持了简洁没急着加领域模型、多态关联这些概念。教育机构业务日常变动快表结构过度设计往往到后面只会成为改造的负担。只要字段能表达一个学生在一个班次上、交了一次作业、产生了一笔订单这三条主线就够用了。1.3 边界取舍第一版不做这些反而走得更快软件项目最大的风险不是功能少而是做了一堆用不上的功能把核心路径拖慢。这个项目我明确砍掉了三个东西第一砍掉课消统计报表。机构老板肯定想看这个月消耗了多少课时、还有多少待消耗但第一版我建议用Excel过渡因为课消规则试听课算不算、请假顺延怎么算需要机构自己磨合软件做早了规则一变就是白做。第二砍掉复杂的排课算法。智能推荐最优班级听起来很酷但真正推动家长选班的往往是时间、距离和老师口碑。第一版只需要把同一个时间段已满员的班置灰把剩余名额展示清楚就完成了80%的需求。第三砍掉多校区支持。如果机构只有一个总校多校区完全是额外复杂度等有二校区再动也来得及前提是数据模型里校区字段一开始就留着但不用为它专门做界面。边界定清楚以后整个开发周期就可以压到一个月左右。后面几章讲的都是第一版必须做扎实的事尤其是选课报名和作业闭环这两条主线。2. vue3 uniapp组合式API的项目骨架目录划分、登录态与路由拦截技术选型看起来是第一步其实在梳理业务的过程中就已经确定了。这个项目我选的是 vue3 组合式API 加 uniapp后端用现成的 Node.js 或 Java 都行重点是前端这套骨架。很多教程讲 uniapp 都是从新建项目开始容易让人忽略真正决定项目舒服与否的是目录结构和工程规范。2.1 技术选型的三个理由多端复用、组合式API、生态成熟度先说多端复用。家长端跑在微信小程序上老师端如果也想在手机上临时看一眼App/H5 都要能跑。uniapp 一套代码编译到小程序、App、H5这个价值在这个项目里被放得很大因为除了家长微信小程序老师端偶尔会在手机浏览器里处理紧急批改机构公众号里也可能嵌 H5 页面。如果分别写两套维护成本直接翻倍。再说 vue3 组合式API。有一说一选项式写法在小页面里很直观但一旦涉及订单状态流转、选课表单校验、作业提交进度这种逻辑同一个功能的代码会散落在 data、methods、watch 里看代码要来回跳。组合式API最大的优势是可以按业务维度抽函数比如把订单创建和支付状态封装成 useOrder()把登录和 token 刷新封装成 useLogin()页面里五行代码就完事。这也是 vue 面试里经常被问到的选项式和组合式区别的实际意义真做一个教育业务项目你会明显感受到组合式API对复杂状态的整理能力。最后是生态。uni-ui 组件库覆盖表单、列表、弹出层这些常见场景微信小程序端有大量现成插件支付、分享、扫码的能力都是封装好的。遇到问题社区资料也比冷门框架多对项目周期短的团队来说趟坑成本是个很现实的考量。2.2 初始化项目时容易被忽略的两件事第一件用 CLI 创建项目而不是直接用 HBuilderX。不是说 HBuilderX 不好它对单兵作战很友好但团队协作时 CLI 工程可以用 git 管理、可以跑 CI、可以固定依赖版本HBuilderX 的可视化界面在两人以上协作时就容易出幺蛾子。创建命令就是常规的npx degit dcloudio/uni-preset-vue#vite my-project装完依赖就能跑。第二件manifest.json 的配置要提前填完整。微信小程序 appid 要真实填写否则运行到微信开发者工具后无法调试真机App 端要提前配置隐私政策弹窗文案iOS 审核如果在启动 App 时没有弹隐私协议直接就是审核不过。权限声明只声明真正用到的比如相册、摄像头不要偷懒全部勾上会让审核变得更麻烦。我用的目录结构长这样src/ ├── api/ # 接口请求层按模块拆分 │ ├── course.js │ ├── order.js │ └── homework.js ├── composables/ # 组合式函数 │ ├── useLogin.js │ ├── useOrder.js │ └── useHomework.js ├── components/ # 通用组件 │ ├── CourseCard.vue │ └── HomeworkItem.vue ├── pages/ │ ├── course/index.vue │ ├── course/detail.vue │ ├── order/confirm.vue │ ├── order/result.vue │ └── homework/submit.vue ├── static/ ├── store/ # pinia 状态 └── utils/ └── request.js这个结构的关键在于 composables 和 api 的边界api 只负责 HTTP 请求的封装composables 负责业务逻辑的组装。比如 useOrder() 里会调用 api/order.js 的接口但页面不需要关心到底请求了哪个接口它只关心当前订单状态是什么、要不要跳转支付。2.3 登录态与会话保持拦截器统一处理路由守卫uniapp 的路由不是 vue-router而是靠 pages.json 里的页面配置和 uni.navigateTo 这类API。所以不能按 vue-router 的习惯写全局前置守卫得用 uni.addInterceptor 来做登录拦截。小程序端登录我用的还是标准流程uni.login 取 code传给后端后端调微信接口换 openid 和 session_key再把自定义 token 返回来前端存到 storage 里。拦截器写法import { useUserStore } from /store/user const authInterceptor { invoke(args) { const userStore useUserStore() if (!userStore.token) { uni.navigateTo({ url: /pages/login/index?redirect encodeURIComponent(args.url) }) return false } return true } } // 在 main.js 中注册 uni.addInterceptor(navigateTo, authInterceptor) uni.addInterceptor(redirectTo, authInterceptor) uni.addInterceptor(switchTab, authInterceptor)这里有三个细节需要注意。一是 switchTab 也必须拦截因为 tabBar 页面无法用 navigateTo 跳转跳登录页之前要先把当前路径记录下来登录成功后再用 uni.switchTab 回跳。二是回调地址要 encodeURIComponent否则路径上如果带 query 参数还原的时候会解析错乱。三是 uniapp 中获取路由参数是通过onLoad(options)获取的options 里所有的值默认是字符串而且如果来源页面传参时没编码遇到特殊字符比如 url 里的 就会截断。所以我通常在传参时统一做一次 encodeURIComponent接收时再 decodeURIComponent这个习惯能帮你避开无数诡异bug。3. 选课报名主链路课程展示、冲突检测、名额锁定与微信支付选课报名是整个系统最重要的业务闭环没有之一。家长打开小程序看到课程列表点进详情选一个合适时间的班次提交订单微信支付支付成功后才算完成报名。这一条链路里几乎每一个环节都有坑我把核心思路和代码逻辑拆开说。3.1 课程列表与详情分页加载和试听视频课程列表页是家长的第一印象不要一屏加载所有数据。用 onReachBottom 触底加载下一页一次十条配合骨架屏显示。列表页的课程卡片上要把价格、剩余名额、适用年龄这些关键信息直接露出来减少家长点进详情才知道价格的挫败感。课程详情页的核心是视频试听。少儿编程的课程要不要买家长很看重试听课的感受。视频播放这里用 uniapp 的 video 组件播放 m3u8 地址是可以直接支持的你只需要把后端给到的 m3u8 地址丢给 video 的 src 属性。但这里要注意一个微信小程序的特殊点如果视频域名没有在小程序后台配置到 downloadFile 合法域名里真机上会播放失败开发工具里反而正常。另外在部分安卓机型上小程序的 video 组件对 hls 流兼容一般如果机构有转码条件建议同时提供一个 mp4 地址作为降级或者在域名配置里把点播服务的域名都加全。还有个小经验详情页不要上来就自动播放视频会触发小程序端的音频/视频审核限制首屏重点还是课程大纲、适龄范围和价格试听视频放在课程介绍下方让家长主动点。3.2 选课核心约束时间冲突检测与防超卖设计家长选了一个班次后服务端要做两件重要的事检查这个孩子有没有报过同一时间段的课以及这个班次还有没有名额。这两个逻辑必须在服务端做不能依赖前端判断。时间冲突检测的思路是查这个学生当前所有状态为正常的选课记录关联出对应班次的上课时间周几、开始时间、结束时间然后判断目标班次是否与其中任何一个时间段重叠。SQL片段大概是SELECT cs.id, cs.weekday, cs.start_time, cs.end_time FROM enrollment e JOIN class_schedule cs ON e.schedule_id cs.id WHERE e.student_id ? AND e.status active拿到这批时间段后在代码里逐一判断目标班次的 weekday 和起止时间这里不能只看日期因为少儿编程班是每周固定一次课跨多周持续同一周几的时间段冲突才有意义。名额防超卖是另一个高频bug点。家长同时有两个手机在选同一个班如果只靠先查剩余名额再减一的普通逻辑并发场景下必然超卖。正确做法是在数据库层面做原子扣减UPDATE class_schedule SET remaining_quota remaining_quota - 1 WHERE id ? AND remaining_quota 0如果影响行数为 0说明名额已经被抢完直接返回该班次已满员。把这个 update 和创建订单放在同一个事务里就能保证扣名额和创建订单的一致性。我见过不少项目是先创建订单再扣名额结果用户支付超时订单取消名额还扣着不释放后面还得写定时任务补偿完全没必要。3.3 订单状态机与微信支付对接细节订单状态我设计了四个待支付、已支付、已取消、已退款。状态流转只有四条合法路径当前状态触发动作下一状态待支付用户主动取消已取消待支付支付超时30分钟已取消待支付微信支付成功回调已支付已支付教务后台退款已退款拒绝了已取消再变回已支付这类非法流转。这个状态机表面简单但能挡住非常多的脏数据。前端发起支付的关键代码// 创建订单后拿到支付参数 const payment await request({ url: /api/order/pay, method: POST, data: { orderId: orderInfo.id } }) uni.requestPayment({ provider: wxpay, timeStamp: payment.timeStamp, nonceStr: payment.nonceStr, package: payment.package, signType: payment.signType, paySign: payment.paySign, success: () { // 支付成功但这里不要急着改订单状态 // 真正的状态变更以服务端回调为准 uni.redirectTo({ url: /pages/order/result?id orderInfo.id }) }, fail: (err) { // 处理用户取消支付 / 支付失败 } })很多人第一次对接微信支付时会在前端拿到 success 之后就更新 UI 为已支付但前端 success 只能说明用户输密码的流程走完了服务端回调才是确定钱到账的唯一依据。所以我的做法是前端跳转到支付结果页结果页先显示支付确认中然后靠轮询后端订单状态接口拿到已支付再刷新界面。这样既不会因为回调延迟显示错误状态也不会在前端伪造支付结果时造成安全问题。3.4 支付合规不想让支付功能被关停这几件事必须做这个章节值得单独拎出来说因为小程序支付被限制的案例实在太多了。微信小程序的支付权限本质上是一个平台风控能力不是像App那样随便申请的。项目开工之前就要确认主体资质小程序账号的主体要和机构营业执照一致教育类目需要提供对应的办学资质或备案材料类目不要乱选。支付功能上线后也要注意不能诱导用户虚假交易、刷单不能出现支付后返现这类诱导分享行为。一旦小程序被投诉或触发风控后台就会提示由于小程序违规支付功能暂时无法使用这种限制不是代码层面的问题要联系微信客服处理处理周期通常不短。所以我的建议是支付相关的代码尽量按微信官方要求写前端在 requestPayment 之前检查一下 customer 端的配置后端回调接口一定要验签该做的都会做不该做的别碰。合规经营对教育机构尤为重要因为家长都很看重机构的稳定性和信誉。项目里如果涉及退款流程也要走正规退款接口不要私下在后台改状态退款不合规也会被风控盯上。4. 作业模块三端数据流转布置、提交、批改、通知选课报名的闭环只是第一步真正把家长和机构黏在一起的其实是作业系统。少儿编程课程如果上完课就结束家长很难感知到学习效果只有老师布置了作业、孩子交了作业、老师给了评语这一连串反馈才能让家长觉得钱花得值。同时作业也是老师掌握进度的关键手段。4.1 作业的数据结构一个作业如何关联班次和学生作业挂在班次class_schedule上而不是挂在单个学生上。因为同一门课不同班次的进度可能不同周二班学到变量周六班还在学循环老师是按班布置作业的。作业表里记录是哪个老师在哪个班次布置的、内容是什么、截止时间是什么时候。作业的类型会影响前端交互我在数据结构里用 type 字段区分objective选择题/判断题学生端直接点选项老师批改时看正确率即可code代码题学生端粘贴代码老师端以文本形式查看image作品截图/成果图学生端上传图片老师端大图查看这个分类决定了不同页面渲染什么组件但不影响核心状态流转。作业之后是提交表一个学生一次作业对应一条提交记录。为什么单独拆出来因为不是所有学生都会在第一次就提交老师还要打回让学生修改重交提交表的多版本设计我放到了4.2节讲。4.2 学生端提交的真实交互图片上传、代码粘贴与草稿机制学生端提交作业最轻的入口是我拍个代码截图或者我把话画出来。少儿编程的孩子年龄普遍在6到14岁之间不能要求他们打字打太多所以提交页面要尽量降低输入成本。图片上传用 uni.chooseImage 选图或拍照一次最多9张然后逐个调 uni.uploadFile 上传到对象存储全部成功后把 URL 数组提交到服务端。代码上传部分一般思路是直接给一个大 textarea 让孩子粘贴代码。但实践经验是对于6-10岁的孩子粘贴代码往往会出现多余空格或标签家长们也不一定懂怎么格式化。所以代码题我建议做成上传 .py 文件 预览的形式或者做成粘贴 自动去除首尾空白的格式。至少让家长在电脑上把代码文件发到微信里再从文件里粘贴到 textarea方便很多。图片和代码一起提交的时候要处理并发和进度。我一般给每个文件建一个上传任务用 Promise.all 等全部完成const uploadTasks tempFilePaths.map((filePath, index) { return new Promise((resolve, reject) { uni.uploadFile({ url: https://api.example.com/upload, filePath: filePath, name: file${index}, success: (res) { try { const data JSON.parse(res.data) resolve(data.url) } catch (e) { reject(e) } }, fail: reject }) }) }) const urls await Promise.all(uploadTasks)这里有一个很实际的体验问题孩子写作业经常写到一半被打断家长关掉小程序就白填了。所以我会在提交页面定时把表单内容和已上传的图片列表存到本地 storage下次打开页面时自动填充。这个成本很低但对家长体验的改善非常明显。4.3 批改与通知闭环订阅消息的正确用法老师批改作业时在 H5 后台打开提交记录看到学生的提交内容打一个分数写两句评语点保存。批改完成以后学生的提交状态变成已批改这时候可以给家长发一条微信订阅消息告诉他孩子的作业已批改快来看看成绩吧。这里涉及到订阅消息的长期可复用问题。微信小程序的订阅消息一种是长期订阅一种是一次性订阅。教育类目很容易申请一次性订阅授权也就是家长在小程序里主动点一次允许接收作业提醒系统才能发一条消息。这个能力用起来有个前提必须在用户点击了某个按钮比如提交作业时立即调 uni.requestSubscribeMessage 申请授权而且用户点了总是保持以上选择以后后面的授权才能自动通过。如果用户在设置里关了通知那消息就没法触达了。所以我在提交成功页面放了一个开启作业完成提醒的按钮点击时申请订阅消息授权这样能保证授权来源自然也能提高后续消息的到达率。还有一点不要设计得过于激进提交一次就弹一次授权框微信会把这种行为判为骚扰轻则模板消息失效重则小程序被限制服务。5. 上线前绕不开的坑从支付合规到打包审核的排查实录这个章节是踩坑实录都是实际项目里遇到并且解决过的问题按主题列出来每个都附排查思路。要知道这类教育管理小程序用户量可能不大但出问题的容忍度极低家长点两下没反应转头就在机构微信群里吐槽。5.1 微信支付被限制该怎么排查支付功能突然用不了先不要慌按顺序排查。第一步登录微信公众平台查看站内信或违规记录确认是不是收到了限制通知如果是平台主动限制后台一般有原因和申诉入口。第二步检查小程序类目与支付场景是否匹配教育类目如果选成了普通百货类风控容易误判。第三步排查交易数据近期有没有大额、高频、来源集中在同一账号的交易有没有被用户投诉退款的记录这些都会触发风控。最后一步才是看代码确认 requestPayment 调用的参数签名是否正常。前几步没走完就怀疑代码容易被带偏。5.2 输入框被软键盘顶飞、遮挡查询内容这个问题在微信小程序里太典型了。家长在查询作业页面想搜索某个关键词手机软键盘一弹出来底部的内容被遮住严重的会把 fixed 定位的按钮顶上去。常见网上说法是设置 input 的 adjust-position 属性为 true实测下来部分安卓机型上完全无效原因是页面里有 fixed 定位元素或者 web-view 混排时编译后的原生组件层级和普通标签不一样。我的解决办法是查询页面里不要用 fixed 底栏而是用普通流式布局把按钮放在输入框下面输入框加 cursor-spacing10 留出光标距底部的安全距离如果页面有多个输入项用 scroll-into-view 在聚焦时把当前输入项滚动到可视区域。小程序端如果基础库版本够高还可以用 onKeyboardHeightChange 监听键盘高度手动调整列表的 padding-bottom这个方案最稳但工作量稍大我一般留到客户强制要求时再做。5.3 分享功能与全局 onShareAppMessage 的冲突微信小程序的分享以前需要在每个页面写 onShareAppMessage后来可以全局配置菜单。但实际开发时有个很隐蔽的坑App.vue 里如果给 onShareAppMessage 做了全局封装某些页面的自定义分享参数会失效显示出来的分享卡片标题、图片不是自己期望的。原因很简单微信小程序的 onShareAppMessage 只认页面组件里的定义App.vue 里的定义在某些基础库版本下会干扰页面级的声明。我排查过一次最后把全局分享逻辑改成 mixin 方式定义一个 sharedMixin统一处理默认的分享标题和图片页面引入这个 mixin 后再单独重写 onShareAppMessage 合并自定义参数。这样既保证了默认分享可用又不互相覆盖。如果只想让指定页面能分享就在 page 级别的 onShareAppMessage 里返回一个空对象微信默认会带上当前页面截图作为分享图效果也还行。5.4 扫码结果是一串数字先分清码制和业务场景项目里有一个扫码签到功能老师扫学生卡上的二维码快速点名。有一回测试返回的 result 一直是一串纯数字而不是预期中的学生ID逻辑怎么都对不上。后来排查发现物理学生卡上印的是 Code128 条形码不是 QR 二维码uni.scanCode 扫到的 result 就是条形码本身的内容而条形码内容恰好是一串学号。问题不在代码而在码制选择上。这个经验提示先确认机构已有的卡是什么码制再决定扫什么码。如果是 qrCode前端可以直接用如果是条形码小程序也支持但需要注意拍摄距离和对焦。还有一种是扫出来是一串数字但是二维码这时候就要怀疑码的内容是不是被其他系统编码了比如自定义加密或 ID 做了映射需要去后端查一下二维码生成逻辑。5.5 安卓应用市场上架隐私政策、软著与不同意退出的实现如果这个小程序以后要打包成安卓 App 上架应用市场事情会变多但核心是这三个软件著作权、隐私政策和备案。每个市场的软著要求不太一样但基本上都要提前准备别等到要上架了才去申请软著下证周期可以按一到两个月预估。隐私政策弹窗是所有应用市场的硬性要求用户首次打开 App 时必须弹窗用户同意之前不能初始化任何涉及个人信息的 SDK。这里对应一个热搜词场景iOS 用户不同意隐私政策及用户协议时怎么退出 App。代码逻辑是弹窗点击不同意时调用 plus.runtime.quit() 退出应用。注意这里有个审核细节iOS 审核其实不建议强制退出更推荐做法是仅退出到设置页让用户重新选择但很多机构为了简单直接仍然采用二次确认后退出应用的做法。如果你要做 iOS 包我建议按平台规范来避免审核被拒。uni.showModal({ title: 提示, content: 需要同意隐私政策后才能继续使用, showCancel: false, confirmText: 同意, success: (res) { if (res.confirm) { // 用户同意后继续初始化 } } }) // 如果用户点击不同意在按钮回调里调用退出还有一个现象很常见uniapp 项目在 HBuilderX 里运行到微信开发者工具点了运行半天没反应控制台也没报错。这时候十有八九是微信开发者工具的服务端口没开。打开微信开发者工具的设置-安全设置把服务端口打开再重新运行就能连上了。这个坑很多人能跳过去但也真的能卡住半天。5.6 前端安全底线密钥别进代码回调必须验签这类机构类系统最容易忽略安全因为用户量不大就觉得无所谓。但涉及支付和家长信息安全性一点不能妥协。第一小程序的 AppSecret 绝对不能出现在前端代码里小程序代码可以被反编译明文密钥等于裸奔。后端通过 code 换 session_key 时才需要用到 AppSecret这一步强制放在服务端。第二所有涉及角色权限的接口前端传的我是老师不可信权限判断必须在服务端根据登录态完成。第三支付回调接口必须做微信支付 v3 的验签处理用微信支付平台证书验证回调请求的签名而不是简单地校验一下回调里传来的成功字段。如果没有验签攻击者直接伪造回调通知就能把订单改成已支付而这个漏洞很容易被忽略。6. 性能与体验优化分包、列表、媒体与弱网教育业务小程序对性能的容忍度其实很低家长在小程序里打不开课程视频或者列表加载转圈超过三秒马上就流失了。这个项目规模不大但性能优化的思路还是值得按完整链路走一遍。6.1 主包瘦身与分包加载微信小程序有主包和分包的大小限制主包要控制体积。我的做法是把所有老师端页面、订单结果页这类低频页面拆到分包里主包只保留 tabBar 页面和公共组件。在 pages.json 里配置 subPackages{ subPackages: [ { root: pages/teacher, pages: [ pages/teacher/homework-list, pages/teacher/homework-detail ] } ] }这样主包体积能明显下降冷启动速度会快很多。对于少儿编程机构这种用户分布比较集中的场景首屏加载够不够快直接决定了家长愿不愿意进来逛。6.2 列表渲染性能与状态管理注意课程列表页如果一次渲染很多卡片在低端安卓机上会有明显卡顿。列表项必须加 :key并且不要在模板里写复杂的方法调用比如在 v-for 里写{{ formatPrice(item.price) }}每次渲染都会全量执行一遍数据多了就拖帧。这种计算放到 computed 或 filter 里面让数据提前处理好模板只做展示。另外不是所有数据都需要进全局 store。有些页面之间的共享状态比如当前选择的班次ID用页面参数传就完了没必要放到 pinia 里。store 里的数据一旦过多复杂度和调试成本都会上升这在教育项目的快速迭代期是负担。我当时只把用户信息和未读作业数放进了 store其他都是按需请求。6.3 图片视频资源与弱网兜底课程封面、老师头像、作业提交图片这些资源都要走 CDN并且后端在做图片上传时生成缩略图列表页加载缩略图详情页再加载原图。视频资源不要直接放原片用点播服务的转码能力输出多个清晰度家长在2G/3G环境下自动选低清晰度在WiFi下选高清。弱网兜底主要体现在提交作业这个场景。家长在停车场或者电梯里提交作业请求很容易失败要给提交按钮加一个提交中的 loading 状态并且失败时保留表单内容允许用户重试而不是把内容清空重填。这个细节其实和草稿机制是配套的做好了家长的体验会非常稳定不会因为有一次上传失败就再也不用了。其次我强烈建议在请求封装层做统一的错误提示让后端接口返回统一的错误码前端统一弹 toast。对接几十个接口以后你一定会感谢当初做了这个统一封装。到了后期如果接口跨服务了加一个请求日志中间件也能快速排查问题。全文完
