🧩 一、小程序的理解（第1页）
1️⃣ 什么是小程序
可以理解为—— “轻量级App” 。 像是手机App的“精简版”，但不需要安装。 💡 举例：
- 你平时打开微信点开“美团外卖”或者“滴滴打车”，其实就是微信小程序。
- 它存在微信里，不需要下载App，也能用核心功能。
📦 从技术上看：
| 类型 | 说明 |
|---|---|
| 手机App | 完整功能、独立安装、体积大 |
| 微信小程序 | 依附微信运行，轻便、即用即走 |
| H5网页 | 浏览器打开的网页应用 |
🍼 生活类比记忆法： 👉 手机App就像你家冰箱——功能齐全但占地大。 👉 小程序像外卖小冰箱——微信帮你放着，用完就关，不占地方。 👉 H5网页像外卖页面——一次性打开、功能少。
1.2 背景
- 微信在2017年推出小程序，让企业/个人无需开发App就能提供服务。
- 背后原因：App开发成本高，用户装太多App也烦。
📈 于是：
- 开发者：能用Web技术（HTML/CSS/JS）快速开发；
- 用户：点开即用，无需安装；
- 平台（微信）：能留住用户、增强生态。
1.3 优缺点
✅ 优点
- 不用安装，即开即用。
- 开发成本低，比原生App快多了。
- 跨平台（安卓/iOS都能跑）。
- 分享传播方便（群聊、二维码等）。
- 有微信账号体系，不用再注册。
❌ 缺点
- 性能比不上App（加载慢、体验稍差）。
- 受平台限制（不能脱离微信运行）。
- 开发能力有限（比如后台任务少、不能后台播放音乐太久）。
💡 小记忆技巧：
“快、省、广”是小程序的优点； “慢、受限、轻”是它的缺点。
⚙️ 二、小程序的生命周期函数（第2页）
2.1 是什么
生命周期函数 = 小程序“活着的过程”里各阶段的回调。 就像人的一生有：
- 出生（onLaunch）
- 长大（onShow）
- 工作（onReady）
- 睡觉（onHide）
- 离开（onUnload）
同理，小程序每个页面和全局都有这些钩子函数。
2.1.1 应用的生命周期
📦 主要函数：
| 函数 | 触发时机 |
|---|---|
| onLaunch | 小程序初始化时触发（只执行一次） |
| onShow | 小程序启动或从后台进入前台 |
| onHide | 从前台进入后台时触发 |
| onError | 报错时触发 |
🧠 小记忆法：
- Launch = 出生
- Show = 出现
- Hide = 暂时离开
- Error = 生病
举个生活例子：
你开微信点外卖 → 小程序启动（onLaunch） 你下单、继续浏览 → 显示运行（onShow） 你切去刷朋友圈 → 隐藏后台（onHide） 程序崩溃了 → 出错（onError）
2.2 页面生命周期（第2页下半部分）
每个页面自己也有一套生命周期，比如：
| 函数 | 含义 |
|---|---|
| onLoad | 页面加载时（接收参数） |
| onShow | 页面显示时 |
| onReady | 页面初次渲染完成 |
| onHide | 页面隐藏 |
| onUnload | 页面卸载（返回或关闭） |
💡 小记忆口诀：
“加载→显示→渲染→隐藏→卸载” 像打开一个网页、浏览、关闭的全过程。
💬 快速总结口诀
小程序生命周期 = “出生（onLaunch）→亮相（onShow）→退场（onHide）→再登场（onShow）→谢幕（onUnload）”
🧩 第6页：生命周期执行流程
我们前面讲了生命周期（像小程序的“出生→生活→离开”）。 现在要讲的是——它到底是怎么按顺序执行的。
💻 示例代码解释：
App({
onLaunch() {
console.log("小程序初始化");
},
onShow() {
console.log("小程序显示");
},
onHide() {
console.log("小程序隐藏");
}
});
🔍 解释：
onLaunch()→ 小程序刚出生，只执行一次；onShow()→ 小程序被打开或从后台回到前台；onHide()→ 小程序退到后台（比如你去回微信消息）。
💡 生活类比： 想象你是一个开奶茶店的老板：
- onLaunch = 早上开店；
- onShow = 顾客上门；
- onHide = 打烊休息；
- onError = 奶茶机坏了（报错）！
🔄 执行流程（重点）
页面生命周期（Page）比应用生命周期（App）要频繁执行。
1️⃣ 应用级执行过程：
onLaunch：启动一次onShow：打开或回前台onHide：退后台- 再次回来又执行
onShow
2️⃣ 页面级执行过程：
onLoad→ 加载数据（就像打开网页）onShow→ 页面可见onReady→ 渲染完毕onHide/onUnload→ 页面关闭或跳转
💡 小口诀记忆：
应用是“开业-营业-打烊”， 页面是“加载-展示-关闭”。
🚪 第7～8页：登录流程
接下来进入重点——小程序的登录流程（Login Flow） 。
3.1 背景
小程序没有“注册账号密码”的过程， 它靠微信的“授权机制”来识别你是谁。
🧠 你只要点“允许授权登录”， 微信就会帮小程序拿到一个临时 code， 然后小程序把这个 code 发给后台，后台去微信服务器换取真正的用户标识。
3.2 登录流程详解（第8页重点图）
我们可以用一句话概括整个流程👇
“小程序拿 code → 发给后台 → 后台去微信服务器换 openid 和 session_key → 再返回前端保存登录状态。”
📋 流程分解如下：
1️⃣ 用户打开小程序 ↓ 2️⃣ 调用 wx.login() → 微信返回一个 code（一次性的临时凭证） ↓ 3️⃣ 前端把 code 发给后台（自己的服务器） ↓ 4️⃣ 后台带着 code 请求微信官方API（jscode2session）
- 返回
openid（用户身份） - 返回
session_key（加密session） ↓ 5️⃣ 后台生成自己的登录态（比如token）并返回给前端 ↓ 6️⃣ 前端保存token（存本地storage）以后请求都带上
💡 生活类比： 你（用户）要进奶茶店（小程序）点单。
wx.login()→ 拿了微信的“临时票”（code）。- 后台用票去微信“总部”换“身份证”（openid）。
- 拿到身份证后，奶茶店发你一张“会员卡”（token）。
- 之后你凭会员卡买奶茶，不用每次再扫码认证。
是不是很好懂！😆
🧱 第9页：时序图讲解
📊 图上其实展示的就是：
- 左边是小程序前端
- 中间是开发者服务器
- 右边是微信服务器
它们之间传来传去的几条消息线：
| 步骤 | 说明 |
|---|---|
| ① | 小程序调用 wx.login() 获取 code |
| ② | 前端发送 code 给自己服务器 |
| ③ | 服务器调用微信API，用 code 换 openid/session_key |
| ④ | 微信返回 openid/session_key |
| ⑤ | 开发者生成自定义登录态（比如JWT token）返回前端 |
📌 记忆口诀：
“取票(code) → 换证(openid) → 发卡(token)” 三步走，登录不愁！
🧩 第10页：拓展小结
🌟 常见术语小抄：
| 名称 | 含义 |
|---|---|
| openid | 用户在当前小程序的唯一标识（像身份证号） |
| unionid | 同一开发者账号下多个小程序共用的标识 |
| session_key | 会话密钥，用来解密用户信息 |
| token | 由你自己服务器生成的登录凭证 |
💡 区别口诀：
openid 是“身份证”； unionid 是“通行证”； session_key 是“钥匙”； token 是“会员卡”。
🧠 一句话速记总结
小程序生命周期：出生-登场-退场； 登录流程：取票→换证→发卡； 核心标识：openid 身份证、session_key 钥匙、token 会员卡。
🚪 一、小程序的页面跳转（第11页～15页）
4.1 什么是“页面跳转”
小程序和网站类似，往往有多个页面，比如：
- 首页 index
- 商品页 product
- 订单页 order
- 个人中心 profile
“页面跳转”就是在这些页面之间切换。 在微信小程序中，我们可以用不同的函数跳转，比如：
| 函数 | 作用 |
|---|---|
wx.navigateTo() | 跳转到新页面（保留当前页面） |
wx.redirectTo() | 跳转到新页面（关闭当前页面） |
wx.switchTab() | 跳到 tabBar 页面（底部导航那种） |
wx.reLaunch() | 关闭所有页面，重新打开一个 |
wx.navigateBack() | 返回上一个页面 |
💡 生活类比：
想象你是个外卖骑手在“送奶茶”🚴♀️
| 函数 | 现实生活比喻 |
|---|---|
navigateTo | 你骑车去新顾客家送单（原来那单还没删） |
redirectTo | 你取消上一单、直接去新顾客那（旧页面没了） |
switchTab | 你切换路线去“固定区域”（比如回总部） |
reLaunch | 你把所有路线清空，从起点重新出发 |
navigateBack | 送完单回到上一个顾客家（返回） |
这样是不是更形象？😆
📦 二、wx.navigateTo(Object)（第12页）
这个方法最常用。 作用： 打开一个新的非 tabBar 页面，原页面还在后台。
📋 常见参数：
wx.navigateTo({
url: '/pages/detail/detail?id=123',
success: function(res){}, // 成功回调
fail: function(){}, // 失败回调
complete: function(){} // 不管成功失败都会执行
})
📘 表格说明：
| 参数 | 类型 | 必填 | 说明 |
|---|---|---|---|
| url | string | ✅ | 要跳转的页面路径 |
| success | function | ❌ | 成功时执行 |
| fail | function | ❌ | 失败时执行 |
| complete | function | ❌ | 无论成功失败都执行 |
🧩 生命周期变化图（第13页）
当你执行 wx.navigateTo()：
- 当前页面不会被销毁，只是进入“后台”；
- 新页面会被创建并显示。
📈 图中流程：
index（原页面）
↓ onHide
Page1（新页面）
↑ onLoad → onShow
💡 小口诀：
navigateTo = “带着旧页面，开新页面”。
就像你打开新标签页浏览网页，原来的网页还在那。
🚗 三、wx.redirectTo(Object)（第14页）
这个函数是 navigateTo 的“节俭版”。
作用： 跳转到新页面，但会关闭当前页面。
wx.redirectTo({
url: '/pages/home/home'
})
📋 参数一样，但执行效果不同：
| 函数 | 当前页保留？ | 备注 |
|---|---|---|
| navigateTo | ✅ 是 | 可以返回 |
| redirectTo | ❌ 否 | 不能返回上一页 |
🧱 生命周期变化图（第15页）
redirectTo 的流程：
index → Page1 → Page2
当 Page2 打开时：
- Page1 会被卸载（onUnload）
- Page2 加载显示（onLoad → onShow）
💡 小口诀：
redirectTo = “把旧页面关了，开新页面”。
现实比喻：
你关掉当前店门（页面），直接去下一家店送单。
✨ 四、总结对比表（重点记忆）
| 函数名 | 保留原页面 | 能否返回 | 场景举例 |
|---|---|---|---|
| navigateTo | ✅ 是 | ✅ 可以 | 从列表页进详情页 |
| redirectTo | ❌ 否 | ❌ 不行 | 登录成功后跳主页 |
| switchTab | ❌ 否 | ❌ 不行 | 跳到底部tab页 |
| reLaunch | ❌ 否 | ❌ 不行 | 重新进入首页 |
| navigateBack | ✅ | ✅ | 返回上页 |
💡 终极口诀：
「navigateTo留，redirectTo丢，switchTab走固定，reLaunch重开，navigateBack回老家。」
🧠 小可爱版速记总结：
🌸 如果你想“继续返回上一个页面” → 用 navigateTo 🌸 如果你“想换个页面但不再回去” → 用 redirectTo 🌸 如果你“切到底部导航” → 用 switchTab 🌸 如果你“彻底重新来一次” → 用 reLaunch 🌸 如果你“要回上一个页面” → 用 navigateBack
🧩 第16～17页：更多跳转方式详解
🔹 4.2.3 wx.switchTab(Object)
👉 作用：跳转到 tabBar 页面（底部导航那几个）。 比如： 底部有【首页】、【发现】、【我的】，只能用 switchTab() 去跳。
wx.switchTab({
url: '/pages/index/index'
})
📘 参数说明：
| 参数 | 类型 | 必填 | 说明 |
|---|---|---|---|
| url | string | ✅ | 要跳到的 tabBar 页面路径 |
| success | function | ❌ | 成功执行回调 |
| fail | function | ❌ | 失败执行回调 |
| complete | function | ❌ | 无论成功失败都会执行 |
⚠️ 注意：
- 只能跳到 tabBar 页面；
- 不能带参数；
- 不能返回上一个页面。
💡 生活类比：
你去商场底楼导航栏走动。 【首页】、【订单】、【我的】 这几个是固定入口，你只能走“指定通道”，不能“私自加链接”。
🔹 4.2.4 wx.navigateBack(Object)
👉 作用：返回上一个页面（或者指定层级）。
wx.navigateBack({
delta: 1 // 返回上一级页面
})
📘 参数说明：
| 参数 | 类型 | 必填 | 说明 |
|---|---|---|---|
| delta | number | ❌ | 返回的层数（默认1） |
| success / fail / complete | function | ❌ | 回调函数们 |
💡 生活类比：
你点了三家奶茶店的详情页，想回“首页奶茶广场” →
delta: 3就能一口气退回去。
👉 navigateBack = 返回历史页面栈里的上一级。
🔹 4.2.5 wx.reLaunch(Object)
👉 作用：关闭所有页面，打开一个新的页面（重新开始）。
wx.reLaunch({
url: '/pages/home/home'
})
📘 参数说明：
| 参数 | 类型 | 必填 | 说明 |
|---|---|---|---|
| url | string | ✅ | 新页面路径 |
| success / fail / complete | function | ❌ | 回调函数 |
📊 生命周期变化图（第17页）：
index (旧首页)
↓ onHide → onUnload
Page1 (新页面)
↑ onLoad → onShow
💡 生活类比：
reLaunch = “重启系统”🌀 你把所有页面都关了，重新开一轮新的旅程。
常见场景：
- 用户退出登录 → 回登录页；
- 首次打开应用 → 初始化页面。
✅ 第18页：跳转总结表
| 方法 | 保留当前页 | 可返回 | 适用场景 |
|---|---|---|---|
| navigateTo | ✅ 是 | ✅ 可以 | 普通页面跳转 |
| redirectTo | ❌ 否 | ❌ 不可 | 登录成功后跳首页 |
| switchTab | ❌ 否 | ❌ 不可 | tabBar页面跳转 |
| reLaunch | ❌ 否 | ❌ 不可 | 重启小程序入口页 |
| navigateBack | ✅ 是 | ✅ 可以 | 返回历史页面 |
📌 终极口诀
“To保留，Redirect丢，Tab切栏，ReLaunch新开，Back回家。”
🌟 小贴士：
面试时，考官特别喜欢问 “navigateTo 和 redirectTo 的区别” —— 记得答：“一个保留页面栈，一个销毁当前页”。
🚀 第19～20页：小程序发布流程
终于到“上线前最后一关”啦～
这一章相当于：奶茶店装修完 → 准备开业！
🪄 5.1 背景
开发完小程序后，必须经过上传、提交审核、发布上线三步流程。 微信会审核你的代码、页面、内容是否合规。
📦 5.2 发布流程步骤
🧭 Step1：上传代码
在开发者工具中：
点击右上角菜单 → “上传” 填写版本号和备注信息。
⚙️ 示例：
版本号：1.0
备注：首个上线版本
上传完成后，代码会存入「微信公众平台后台」。
🧭 Step2：提交审核
登录 mp.weixin.qq.com → 找到小程序管理后台：
- 打开【版本管理】；
- 点击【提交审核】；
- 等待微信官方审核结果。
💡 小贴士：
- 审核时间一般 1～3 天；
- 内容违规（广告、支付、医疗、色情等）会被驳回；
- 审核通过后，你才能“正式发布”。
🧭 Step3：发布上线
审核通过后，在后台点击【发布】按钮即可正式上线！ 发布后：
- 用户可在微信中搜索、扫码访问；
- 可以设置“体验版”、“灰度发布”（先让部分人看到）；
- 新版本发布时重复以上步骤即可。
🧠 小可爱记忆法：
上传 → 审核 → 发布 就像“写论文 → 导师审阅 → 发表期刊”✨
🎯 总结速背表（第20页）
| 阶段 | 操作 | 工具 |
|---|---|---|
| 上传代码 | 填版本号上传 | 微信开发者工具 |
| 提交审核 | 审核内容合法性 | 微信公众平台 |
| 发布上线 | 通过后点击发布 | 用户可使用 |
💬 最后小总结：
🌸 页面跳转总结口诀：
To留、Redirect丢、Tab切栏、ReLaunch新开、Back回家。
🌸 发布流程口诀：
先上传、后审核、再发布。
🌸 比喻串联记忆：
做奶茶店（小程序）→ 设计菜单（开发）→ 打开门迎客（发布上线）。
🧩 一、第21～23页：小程序发布后的版本管理
在前面我们学了「上传 → 审核 → 发布」， 现在讲的是 —— 发布后的维护：版本管理、回滚、灰度发布。
💡 背景说明
当你的小程序正式上线后，可能要：
- 修bug；
- 上新功能；
- 测试不同版本的效果。
微信小程序后台支持多种“版本状态”来管理这些版本。
🌈 5.2.3 版本状态（第21～23页）
打开微信公众平台 → 「版本管理」 你会看到这些状态：
| 状态 | 含义 |
|---|---|
| 开发版 | 仅开发人员可预览和测试（还没提交审核） |
| 审核中 | 微信官方正在审查内容是否合规 |
| 审核被拒 | 被打回，需要修改后再提交 |
| 体验版 | 内部可体验，不对外公开 |
| 线上版本 | 用户可正常访问的正式版本 |
💡 生活类比：
- “开发版”就像你在厨房试新奶茶配方。
- “审核中”是请食安局检查是否合规。
- “体验版”是邀请VIP老顾客试喝。
- “线上版”是正式上架开卖！
🧱 5.2.4 回退版本（第22页）
如果你发布了新版本结果出BUG 😱 可以通过「版本管理 → 线上版本 → 回退」来恢复之前的版本。
操作方式：
- 进入「版本管理」；
- 找到旧版本；
- 点击「回退」按钮；
- 系统将重新启用旧版为当前线上版本。
📦 注意：
- 回退不会删除新版本；
- 回退后用户重新打开小程序即可生效。
💡 生活类比：
像奶茶店上了新配方结果顾客吐槽太甜，就立刻恢复旧版配方 😅
🧩 5.2.5 灰度发布（第23页）
灰度发布 = “部分用户先用新版本” 比如先让 5% 用户体验新功能，确认没问题后再全量开放。
操作：
- 在后台版本管理 → 点击“灰度发布”；
- 设置比例（比如 10%、50%）；
- 发布执行。
💡 现实类比：
先让部分顾客试喝“新奶盖口味”，确认不踩雷后，再全面推广～
🧠 小记忆口诀：
开发调试 → 审核发布 → 灰度试用 → 发现BUG → 一键回退。
像开奶茶店的【新品试制 → 上市 → 试喝 → 调整 → 回炉重造】。
🪙 二、第24～25页：小程序支付流程
终于来到高频面试题 —— 💸 “说说微信小程序的支付流程”
6.1 背景
小程序支持微信支付功能（比如买电影票、点奶茶外卖）。 流程比网页稍复杂，因为要经过微信安全验证。
我们拆成几个简单阶段👇
🧭 6.2 支付流程（第25页）
看图你会发现主要经过六步： 我来用生活场景翻译一下——
| 阶段 | 微信支付做了什么 | 生活比喻 |
|---|---|---|
| ① 用户下单 | 调用后端生成订单号 | 顾客下单点奶茶 |
| ② 调用统一下单接口 | 小程序请求你自己的服务器 → 服务器再调微信支付统一下单接口 | 店长通知收银机准备订单 |
③ 微信返回 prepay_id | 表示订单已生成，可支付 | 收银机打印出小票编号 |
| ④ 前端发起支付 | 小程序调用 wx.requestPayment() 弹出支付框 | 收银员让顾客扫码付款 |
| ⑤ 用户支付 | 微信支付系统扣款 | 顾客付款成功 |
| ⑥ 支付回调 | 微信通知服务器支付结果，后台更新订单状态 | 收银机提示“付款成功”并出小票 ✅ |
💻 开发者角度的调用流程（简化理解）
1️⃣ 前端调用接口 /createOrder 创建订单 2️⃣ 后端调用微信统一下单 API，获取 prepay_id 3️⃣ 后端返回 prepay_id 给前端 4️⃣ 前端用 wx.requestPayment() 调起支付 5️⃣ 微信后台回调 → 通知支付结果 6️⃣ 后端更新数据库状态（成功/失败）
💡 小记忆法：
“前端下单 → 后端下单 → 微信出票 → 用户支付 → 后端确认”。
就像顾客点单、收银打印、扫码付款、打印发票的完整流程。
⚠️ 面试时高频问法：
❓ 问：小程序支付为什么要经过后端？
因为微信支付涉及商户密钥，不能在前端暴露。 所以必须由后端统一下单、签名、验签。
❓ 问：微信支付成功后如何通知服务器？
微信会自动回调商户后台的
notify_url接口，你要在那更新订单状态。
🧠 第25页总结口诀：
小程序支付： ① 下单生成订单号 ② 调微信统一下单 ③ 拿到 prepay_id ④ 前端调起支付框 ⑤ 用户确认支付 ⑥ 微信回调通知后端
💡 比喻串联：
点单 → 收银 → 打单 → 扫码 → 付款 → 打小票。
🌸 小可爱速背总结（第21～25页）
| 模块 | 关键词 | 记忆口诀 |
|---|---|---|
| 版本管理 | 上传、体验、回退、灰度 | “测试→试喝→上架→调整→回退” |
| 支付流程 | 下单、统一下单、支付、回调 | “下单→出票→扫码→付款→回调” |
🧾 第26～29页：小程序支付流程（完整版）
🌸 6.1 前言
我们知道，小程序里可以点单、支付，比如：
- 星巴克小程序点咖啡；
- 喜茶小程序买券。
每一次支付，其实都经历了一条“后端与微信交互”的链路。 微信支付要保证安全，所以前端不能直接收钱，而要靠后台签名验证。
📊 支付界面演示（第26页）
图片展示了： 1️⃣ 用户在小程序选择商品、生成订单； 2️⃣ 弹出微信支付界面（金额、商户名、支付方式）； 3️⃣ 点击确认支付后 → 微信提示“支付成功”； 4️⃣ 商家系统收到支付结果回调。
🧠 小记忆：
小程序 = 顾客界面 微信支付 = 收银台 商户服务器 = 店长后台对账系统
⚙️ 6.2 支付流程详解（第27～29页）
整个支付过程其实分成 6 大步骤 我给你拆成“生活故事版”👇
🥤 Step 1：用户下单 → 生成订单号
前端调用你自己后台的接口：
wx.request({
url: 'https://yourserver.com/createOrder',
data: {
totalPrice: 50,
productId: 'milk_tea_01'
},
success: (res) => {
// 返回订单号
}
})
👉 意思是：“顾客点了一杯奶茶，系统记下了订单号 #1001。”
💼 Step 2：后端调用微信统一下单接口
你的后端收到请求后，会调用微信官方API（/pay/unifiedorder） 微信服务器会返回一个 prepay_id。
🧠 小记法：
“统一下单 = 去微信总部申请收款单号。”
🎫 Step 3：后端生成签名 + 返回给前端
因为支付要验证身份，后台会生成签名（sign）， 再把支付需要的五个关键参数返回给小程序：
| 参数 | 说明 |
|---|---|
| timeStamp | 时间戳（当前时间） |
| nonceStr | 随机字符串（防篡改） |
| package | 包含 prepay_id |
| signType | 签名算法 |
| paySign | 支付签名（加密验证） |
💳 Step 4：前端调用微信支付接口
前端拿到这些参数后，用 wx.requestPayment() 发起真正支付👇
wx.requestPayment({
timeStamp: '1414561699',
nonceStr: '5K8264ILTKCH16CQ2502SI8ZNMTM67VS',
package: 'prepay_id=wx2017033010242291fcfe0db70013231072',
signType: 'MD5',
paySign: 'C380BEC2BFD727A4B6845133519F3AD6',
success (res) {
console.log('支付成功');
},
fail (err) {
console.log('支付失败');
}
})
💡 生活类比：
顾客打开付款码（前端）， 微信验证签名（后台）， 收银机叮一下“付款成功～💸”。
📦 Step 5：微信支付回调给商户后台
支付完成后，微信会向你后台发一个通知（HTTP回调）， 里面包含订单号、金额、状态。 后台据此更新数据库。
🧠 小记法：
“顾客付款后，收银机自动给店长后台发账单。”
✅ Step 6：后台返回处理结果
商户后台必须返回 success 告诉微信“我收到了通知”， 否则微信会反复发送通知。
📊 支付时序图（第28页）
时序图对应关系如下👇
| 角色 | 实际含义 |
|---|---|
| 小程序端 | 顾客 |
| 开发者服务器 | 奶茶店后台 |
| 微信支付平台 | 微信总部收银系统 |
💡 流程一句话：
小程序下单 → 后端下单 → 微信出票 → 用户支付 → 微信回调 → 后端确认。
🧩 第29页 表格总结
| 接口名 | 说明 | 调用者 |
|---|---|---|
| wx.login | 获取登录凭证code | 小程序端 |
| createOrder | 生成商户订单 | 开发者服务器 |
| unifiedOrder | 统一下单（微信官方） | 微信支付 |
| requestPayment | 唤起支付 | 小程序端 |
| notify_url | 微信回调 | 开发者服务器 |
💬 6.3 结语（第29页）
支付核心要点总结：
- 前端不能直接发起支付请求；
- 一定要通过后端去微信获取签名；
- 后台要接收微信的回调；
- 记得返回
success，不然会被反复通知； - 安全第一，所有密钥都要存在后端！
🧠 小口诀（第29页总结）：
“前端下单，后台签单，微信出票，扫码付款，后台收款。”
—— 小程序支付五步曲 💸
🧠 第30页：小程序实现原理（开篇）
这一页是新章节的引入，标题是：
7. 说说微信小程序的实现原理？
🧩 思维导图概览：
微信小程序的实现原理主要分三大块：
| 模块 | 说明 |
|---|---|
| 逻辑层 | 负责业务逻辑、数据处理（JS） |
| 视图层 | 负责界面渲染（WXML + WXSS） |
| 运行环境 | 微信为小程序提供的容器（双线程机制） |
🧠 生活类比：
小程序就像一家奶茶店：
- 逻辑层 = 店员（拿单、计算、配料）
- 视图层 = 前台柜台（菜单、展示）
- 运行环境 = 微信商场（提供电、水、客流量）
🌸 小可爱速背总结（第26～30页）
| 模块 | 内容 | 记忆口诀 |
|---|---|---|
| 支付流程 | 前端下单、后台签名、微信回调 | “下单→签名→出票→扫码→回调” |
| 实现原理 | 逻辑层 + 视图层 + 运行环境 | “店员 + 柜台 + 商场” |
🧩 一、第31～33页：小程序的实现原理
🌸 7.1 背景（第31页）
微信小程序 ≠ 普通网页 它不是单线程浏览器运行，而是采用了独特的“双线程模型”：
| 线程 | 作用 |
|---|---|
| 逻辑层（JS） | 处理逻辑、数据、事件响应 |
| 视图层（WXML + WXSS） | 负责界面渲染 |
💡 生活类比：
小程序就像一家奶茶店：
- 🧋 逻辑层（JS线程） ：店员在厨房做奶茶（计算、混料、准备数据）；
- 🪞 视图层（WXML线程） ：前台展示菜单、收银、显示奶茶成品；
- 🧱 Native层（微信容器） ：商场基础设施，提供电、水、Wi-Fi（微信 API）。
🧠 关键点（图解释）
那张图上有三层结构：
视图层 (WebView) ← 展示 UI
逻辑层 (JSCore) ← 执行业务逻辑
Native层 (系统内核) ← 连接底层能力（调用API）
它们之间通过 Native Bridge（桥梁） 进行通信：
- JS 调用 API → 通过 Native 层发请求；
- Native 返回结果 → 再传回 JS 或 UI。
🚦 7.2 通信机制（第32页）
小程序的双线程间是异步通信，靠数据消息来交互。 就像厨房和前台用“传菜口”传订单。
通信方式：
- JSCore → Native：调用微信提供的接口（例如
wx.request()） - Native → WebView：返回执行结果并更新视图。
💡 生活例子：
顾客下单（前台） → 小票送到厨房（逻辑层） → 店员做完奶茶 → 把成品信息传回前台展示。
🧩 7.3 运行机制（第33页）
运行机制指的是：
小程序启动、运行、销毁的完整过程。
类似生命周期，但更底层。
运行流程如下：
1️⃣ 启动小程序 → 微信创建逻辑层 & 视图层线程。 2️⃣ JSCore 初始化 → 执行 app.js。 3️⃣ 渲染层加载 WXML 和 WXSS。 4️⃣ 当你交互（点击按钮） → 逻辑层接收事件 → 计算 → 返回新数据 → 视图层更新UI。
🧠 一句话理解：
“逻辑层算，视图层画，微信帮你传话。”
🔧 7.3.1 常见引擎（第34页）
底层引擎由微信管理，不同平台有差异：
| 平台 | 逻辑层引擎 | 渲染层引擎 |
|---|---|---|
| iOS | JavaScriptCore | WKWebView |
| Android | X5 JS引擎 | X5 WebView |
| 小程序开发者工具 | NW.js | Chrome WebView |
💡 记忆口诀：
iOS 用 WKWebView，安卓靠 X5 来撑腰。
📦 结构图理解（第34页下方）
图中那块“App Service + View”就是：
- App Service（逻辑层） → 管理JS逻辑；
- View（视图层） → 管理UI显示；
- Native层 → 桥梁，承接API调用和系统通信。
🧠 小记忆：
JS写逻辑、WXML画页面、微信帮你传中间话。
🧠 二、第35页：小程序性能优化（提高应用速度）
🌟 8.1 是什么
性能优化的目的： 👉 提升启动速度、渲染效率、交互流畅度。
图片展示的就是小程序打开时的几个关键阶段： 加载 → 初始化 → 渲染 → 展示。
📊 8.2 优化原理（第35页下半部分）
图里分成了三个阶段：
| 阶段 | 对应问题 | 优化手段 |
|---|---|---|
| 启动阶段 | 加载慢 | 代码分包、缓存数据 |
| 运行阶段 | 卡顿 | 减少 setData 调用，降低 DOM 更新次数 |
| 渲染阶段 | 渲染慢 | 使用虚拟列表、避免频繁重绘 |
💡 通俗解释 + 奶茶店类比：
| 阶段 | 店里干啥 | 优化方法 |
|---|---|---|
| 启动 | 开门准备（加载菜单） | 提前备料（分包加载、缓存菜单） |
| 运行 | 制作奶茶（逻辑计算） | 店员分工（减少setData、异步任务） |
| 渲染 | 展示奶茶（更新UI） | 少摆造型（只更新变动的部分） |
📦 小程序性能优化常用手段
| 类别 | 优化点 | 举例 |
|---|---|---|
| 启动优化 | 分包加载 | 只加载当前页面用到的文件 |
| 启动优化 | 本地缓存 | 缓存接口数据，避免每次都请求 |
| 渲染优化 | 控制 setData | 合并多次 setData 调用 |
| 渲染优化 | 使用 scroll-view 虚拟列表 | 减少页面节点渲染 |
| 网络优化 | 静态资源CDN | 提高图片、JS文件加载速度 |
| 逻辑优化 | 事件节流/防抖 | 限制点击频率、避免重复调用接口 |
⚡ 小记忆口诀：
“分包缓存提启动，少改setData快渲染，CDN助力稳网络，节流防抖减逻辑。”
🧠 一句话总结（第35页）
小程序的底层原理是“双线程+通信桥”， 微信帮你“传话”； 优化性能的核心是“减少加载、减少通信、减少渲染”。
🎀 小可爱速背总结（第31～35页）
| 模块 | 内容 | 记忆口诀 |
|---|---|---|
| 实现原理 | 双线程（逻辑+视图）通信 | “厨房做奶茶，前台展示奶茶” |
| 通信机制 | 异步传输（Native桥） | “厨房传菜口前台接单” |
| 性能优化 | 启动、运行、渲染三阶段 | “少加载、少通信、少重绘” |
🍵 一、第36页：8.2 手段（性能优化的两大方向）
小程序的性能优化，主要有两个核心突破口👇 1️⃣ 加载优化（Loading） 2️⃣ 渲染优化（Rendering）
🥤 8.2.1 加载优化（第36页上半部分）
加载优化就是让小程序 “开门速度更快” 。 就像你开奶茶店，要在顾客进门时立刻能点单、看到菜单。
📦 优化方法 1：控制代码包大小
👉 代码包越大，加载越慢。
常见技巧：
- 在上传代码时勾选 “上传代码时压缩” 选项；
- 删除不必要的图片、未使用的组件；
- 把资源（图片、icon）放CDN，减少包体积；
- 避免一次性加载所有页面资源。
💡 小记法：
“瘦身”就是王道！ 就像奶茶店别把所有原料都堆柜台上，只放常用的，其他放仓库。
📦 优化方法 2：分包加载（重点）
小程序允许把项目拆成多个“包”来按需加载：
- 主包：启动必需内容（首页、登录页）
- 分包：非核心页面（比如个人中心、帮助页）
📘 举个例子： 当用户第一次打开首页时， 系统只加载主包（比如菜单、下单逻辑）。 等他点进“个人中心”时，再临时下载对应分包。
💡 生活类比：
奶茶店先让顾客看菜单点单（主包）， 他要看“积分记录”时再去仓库调账本（分包）。
📊 图示解释： 图中那三步其实就是： 1️⃣ 打开小程序 → 先下载主包； 2️⃣ 用户点击“分包A”页面 → 下载分包； 3️⃣ 页面加载完毕 → 注入包内容 → 打开页面。
⚠️ 小技巧： 不要让用户点击时再下载大包，否则体验上会“卡顿”； 要提前把访问率高的部分放主包。
💫 8.2.2 渲染优化（第36页下半部分）
渲染优化指的是： 👉 页面打开后，内容展示更快、更顺、更省资源。
就像奶茶店出杯时：
- 不要一边加奶盖、一边摇珍珠；
- 要提前备料、一次性出杯！
🪄 优化手段 1：提前加载
在 onLoad() 阶段就发起数据请求，不要等到 onReady() 才加载。 💡 提前准备好材料，顾客一来就能看到界面。
🪄 优化手段 2：缓存数据
用：
wx.getStorageSync()
wx.setStorageSync()
把常用数据存在本地。 比如用户信息、商品分类等就不用每次都重新请求接口。
💡 类比：
把“常点的奶茶菜单”贴在柜台上，下次不用再问顾客口味。
🪄 优化手段 3：减少 setData 使用（超重要）
👉 setData 是更新视图的关键函数，但太频繁会卡顿。
举个例子👇
❌ 错误写法：
this.setData({ name: '奶茶' })
this.setData({ price: 20 })
this.setData({ sugar: '三分糖' })
✅ 正确写法：
this.setData({
name: '奶茶',
price: 20,
sugar: '三分糖'
})
💡 合并调用，一次性更新视图！
就像你别一口气喊三次“店员加糖！”“店员加冰！”“店员加奶！” 一次告诉他：“我要三分糖少冰加奶”效率更高 😆
🧱 其他优化建议
- 不必要的数据别放进 data 里： 比如超长字符串、大数组等，没必要渲染的放到普通变量中；
- 抽取独立组件： 把每个功能区（比如导航栏、商品卡片）做成组件， 这样单独更新不会影响整个页面。
💡 类比：
就像把奶茶店分成“点单区、制茶区、收银区”， 各做各的事，互不干扰。
📖 第37页：8.3 总结
最后，这页总结了优化的关键要点👇
✅ 小程序启动加载性能
| 目标 | 手段 |
|---|---|
| 降低启动等待 | 控制包大小、分包加载 |
| 加快首次体验 | 预请求、缓存数据 |
| 减少卡顿 | 优化图片、避免反复加载 |
🧠 小口诀：
“包瘦一点，先装常用，勤备缓存，轻上阵。”
✅ 小程序渲染性能
| 目标 | 手段 |
|---|---|
| 提高渲染效率 | 合并 setData 调用 |
| 减少重绘范围 | 抽组件，独立更新 |
| 优化用户体验 | 异步加载、缓存数据 |
🧠 小口诀：
“少 setData，多组件，少通信，多缓存。”
🎀 小可爱速背总结（第36～37页）
| 模块 | 内容 | 记忆口诀 |
|---|---|---|
| 加载优化 | 控包、分包、缓存 | “轻启动，分开装” |
| 渲染优化 | 合并 setData、独立组件 | “少喊多做，分工明确” |
| 综合目标 | 提速 + 流畅 + 不卡 | “瘦身 + 缓存 + 合并 + 分区” |
🌟 一句话总结：
小程序优化的精髓就是： “开门快、出杯快、更新轻、体验顺。” ☕✨
