企业官网建设流程全解析

简介：一份基于微信小程序的在线免费小说应用毕业设计资料，面向希望入门小程序开发或完成课程设计、大作业、工程实训的学习者。项目完整覆盖书城、我的书单、在线阅读器三大功能模块，并配套Node.js后端接口、MongoDB数据库与Redis缓存，以及书目和排名爬虫脚本，能够串联从数据采集到前端展示的完整开发链路。压缩包共372个文件，以CSS、JS、JSON、PNG、WXML、Vue等为主，其中样式与页面文件用于小程序界面渲染，JS与JSON负责业务逻辑和接口配置，另有多个BAT脚本辅助一键启动后端、爬虫及微信开发者工具，整体约11.43MB，目录结构清晰便于按需取用。目前已有26人学习浏览，适合有一定基础、能够自行调试报错并扩展功能的读者参考借鉴。

1. 在线免费小说小程序毕设：一页书架背后的真实工作量

基于微信小程序的在线免费小说应用，乍看是把网页版小说站套个手机壳：左边一个书架，右边一个阅读页，再配个搜索框。可真正动手做毕业设计，你会发现核心难点全在数据链路——书库从哪来、正文怎么分章、章节要不要缓存、搜索怎样在 2MB 包体限制下不卡死、免费内容如何通过审核。这个题目看起来只是“列表 + 详情”，做进去才知道，它是小程序、云开发、数据库索引、富文本渲染和审核合规的缝合体。适合前端基础一般，但想完整走完一个业务闭环的读者。

2. 选型先于编码：微信小程序小说应用的三种后端方案

2.1 方案对比：云开发、自建 Node 后端与静态 JSON 模拟

做毕业设计，最容易掉进的一个坑，是一上来就对着微信开发者工具里的pages/index/index照葫芦画瓢。小说应用核心不是前端交互，而是数据：一本书可能有几百章，一章正文少则几千字，多则几万字；如果每章都写死在 JS 里，项目会瞬间超出 2MB 的主包限制。所以第一步要先确定后端方案，再回头画页面。

常见做法有三种。第一是纯静态 JSON 模拟：把十几本样书和几十章正文塞进data目录，用wx.request指向本地文件。优点是不需要服务器，缺点是一加数据就爆包，翻页刷新会卡，答辩时一联网就露馅。第二是自建 Node.js 后端，用 Express 写/books、/chapters/:id接口，配 MySQL 或 MongoDB。这是最能体现工程能力的方案，但毕业设计的时间通常不够你同时维护小程序端、服务端和数据库，光环境部署和环境变量就能耗掉一个周末。第三种，也就是我最后选的方案是微信云开发：用云函数写接口、云数据库存书库和章节，前端只做渲染和缓存，省掉了备案和服务器运维。

下表可以快速对比三者的取舍。

从表格能看出来，静态方案只是“能交差”，自建后端在毕设周期里容易透支精力。云开发属于性价比最高的中间态：你既能讲清楚 B/S 结构，又能把时间留给功能和踩坑。我当时对 Node 并不熟，但在微信开发者工具里右键创建云函数，改代码、上传、调用，整个过程是可视化操作，这直接改变了我的项目进度。

服务端选型确定后，界面就不要再纠结要不要用组件库。小说阅读页最核心的组件是rich-text，UI 库反而帮不上大忙。先把pages/book-detail、pages/reader、pages/search三个页面建好，项目结构就基本稳定了。我一般会给阅读页建一个独立分包，因为正文渲染容易触发主包体积告警。

2.2 为什么我选了微信云开发：免费额度、免鉴权与数据库权限

微信云开发最打动人的不是“免费”，而是免鉴权。传统后端每获取一个用户身份都要走wx.login换 code，再拿 code 换 openid，最后还要维护 session。云开发里云函数内置cloud.getWXContext()，直接在函数体里拿 openid，前端不用传任何登录态。这个特性正好适合小说应用：阅读记录只需要把书籍 ID 和章节索引写成一行，不需要手机号。真正需要用户身份做“我的书架”时，openid 已经够了。

开通云开发的步骤很固定：微信开发者工具工具栏点“云开发”，创建环境，记下环境 ID；然后右键cloudfunctions目录选择“新建云函数”，写入下面这段代码，再右键“上传并部署：云端安装依赖”。

// cloudfunctions/getOpenid/index.js const cloud = require('wx-server-sdk') cloud.init({ env: cloud.DYNAMIC_CURRENT_ENV }) exports.main = async () => { const { OPENID, APPID, UNIONID } = cloud.getWXContext() return { openid: OPENID, appid: APPID, unionid: UNIONID || '' } }

这里env: cloud.DYNAMIC_CURRENT_ENV表示自动使用当前云环境，不需要硬编码环境 ID，这样换环境调试时不用改代码。调用时前端直接wx.cloud.callFunction({ name: 'getOpenid' })，云函数返回的 openid 在首次进入书架页时写入users集合。注意：不要把这个 openid 随页面 URL 传递，防止被其他用户伪造成他人身份。

数据库权限不要全局放开。云开发默认的集合权限是“仅创建者可读写”，这会导致前端在查询书库时拿到空数组。常见的配置是：books、chapters两个集合设为“所有用户可读，仅创建者可读写”，favorites、reading保持“仅创建者可读写”。在云开发控制台里，选中集合→权限设置→自定义安全规则，规则大致是：

{ "read": true, "write": "auth.openid == doc._openid" }

云函数不受这条规则限制，因为云函数是管理员权限。这里有个坑：如果你在云函数里读写集合很正常，但前端自定义查询返回空列表，别急着怀疑代码，先去检查集合权限。我在第一次联调时浪费了半天在这个问题上。

2.3 最小可用的数据模型：书库表、章节表与书架表

小说应用的数据库不像电商订单那样事务复杂，但字段设计直接影响后续接口复杂度。我最后沉淀了三个集合，足够覆盖“看书、找书、书架”三个核心场景。

books集合存储书籍基本信息和聚合统计：

{ "_id": "book_001", "title": "边城", "author": "沈从文", "category": "现代文学", "cover": "cloud://demo.636c-cloud-xxx/cover/边城.jpg", "description": "以20世纪30年代川湘交界的边城小镇为背景……", "chapterCount": 21, "wordCount": 41000, "isFinished": true, "updatedAt": 1700000000000 }

chapters集合存储章节索引和正文：

{ "_id": "chapter_book001_01", "bookId": "book_001", "index": 1, "title": "题记", "content": "……正文……", "wordCount": 3200, "status": "free" }

favorites集合存储用户书架与阅读进度：

{ "_id": "fav_xxx", "_openid": "oX8s_xxxx", "bookId": "book_001", "chapterIndex": 3, "scrollPos": 1260, "updatedAt": 1700000000000 }

字段说明不复杂，我提醒三处。第一，chapters的_id用“书 ID + 章节序号”拼接，能让doc()直接读取正文，省掉一次 where 查询；如果书较多，用doc('chapter_' + bookId + '_' + index)简单可靠。第二，books里的updatedAt必须存毫秒时间戳，不要存字符串，否则分页排序会把 “2025-01-01” 和 “2025-01-11” 按字典序排错。第三，wordCount提前算好，列表页展示“字数”不用每次都 count 正文。

建集合之前，先在“数据库-集合-索引管理”里给三个索引：books集合的category + updatedAt，chapters集合的bookId + index，favorites集合的_openid + updatedAt。云开发数据库在未命中索引时会返回错误或拖慢查询，别等数据多了才回头建索引。

数据从哪里来？毕设演示建议导入一到两本已进入公有领域的完整作品，像《边城》这类现代文学还是要确认版权状态；更稳妥的是用自己写的《示例小说·第一章》做样章。导入方式有两种：控制台 JSON 文件导入，或者写一个 Node 脚本读本地 txt 后按\n分割成 JSON 上传。脚本逻辑就是把每一章 content 字段填好，再更新chapterCount。别一次性导入几千章，云数据库免费版单次请求有上限，分五十条一批导入即可。

3. 把小说读起来：章节列表、阅读页与本地缓存

3.1 阅读页 UI 拆解：字号、主题与翻页方式

进入阅读页，用户首先关注的是排版，而不是用什么动画。很多毕设把精力花在精美的封面轮播上，阅读页一打开却是把整章正文塞进<text>，段首没有缩进，段落之间不分行。阅读体验在线，答辩才有说服力。微信小程序的rich-text组件支持 HTML 字符串和 nodes 数组两种用法，小说正文建议用 nodes 数组，因为字符串方式容易被注入的标签带偏。

我在pages/reader页面里用了一个buildRichText(content)函数，先把正文按换行符拆成段落，再映射成rich-text能识别的节点结构：

// pages/reader/reader.js function buildRichText(content) { const paragraphs = content.split('\n') .map(line => line.trim()) .filter(line => line.length > 0) return paragraphs.map(paragraph => ({ type: 'p', attrs: { style: 'text-indent: 2em; line-height: 1.8; font-size: 17px; margin: 0.4em 0;' }, children: [{ type: 'text', text: paragraph }] })) }

逻辑说明：split('\n')处理从云数据库读出的正文字段，过滤掉空行；每个段落是一个p节点，style必须写成内联样式，因为rich-text不会读取页面上定义的 class。这里的字号用了px而不是rpx，后面避坑章会展开讲。

还需要一个包含小说章节列表的目录页。章节列表不用二次请求，可以在进入本书详情时把chapters集合的title、index字段拉下来，用户点某一章再请求正文。阅读页顶部放一个自定义导航栏，这样不用受微信自带导航颜色限制。自定义导航栏要注意微信小程序顶部导航栏高度由状态栏高度和胶囊按钮位置决定，不能写死 44px。我在app.js里用wx.getWindowInfo()拿到statusBarHeight，在需要时用 CSS 变量或直接给padding-top赋值。

3.2 按章节加载正文：一次性请求还是分页拉取

第一次做的时候，我图省事，在onLoad里把整本书所有章节全部拉下来。小书只有二十章，看起来没压力；一旦换一本三百章的样书，加载时间立刻破三秒，控制台开始报云函数超时。后来我把策略改成“目录全量 + 正文按需”：目录数据量小，一次性返回；正文只在用户进入某一章时调用一次。

为了让首次打开阅读页不要太久，我通常写一个云函数getChapterContent，接收bookId和index，返回对应章节的正文：

// cloudfunctions/getChapterContent/index.js const cloud = require('wx-server-sdk') cloud.init({ env: cloud.DYNAMIC_CURRENT_ENV }) const db = cloud.database() exports.main = async (event) => { const { bookId, index } = event if (!bookId || !index) { return { code: -1, message: '参数缺失' } } const res = await db.collection('chapters').doc( `chapter_${bookId}_${index}` ).get() return { code: 0, data: { title: res.data.title, content: res.data.content, wordCount: res.data.wordCount, prevIndex: index > 1 ? index - 1 : null, nextIndex: res.data.hasMore ? index + 1 : null } } }

参数说明：doc()直接通过_id读取是主键查询，比 where 快很多；index参数必须使用数字类型，前端传入的如果是从字符串'01'解出来的，要先parseInt。prevIndex和nextIndex用来在底部渲染“上一章/下一章”按钮，不要用“当前索引 + 1”硬算，因为章节可能被隐藏或倒序。

前端拿到正文后，在onLoad时把章节列表渲染出来，点目录跳到某章时调用上面的云函数。目录跳转后要做两个操作：wx.pageScrollTo回到顶部，再把当前章节 index 写入 storage。否则下一章加载后，滚动位置还停在上一章的段落，用户会以为页面没更新。

3.3 阅读进度与书架状态：用 Storage 做离线兜底

免费小说应用的“书架”本质是收藏列表 + 阅读进度。云数据库适合存放一个稳定的“最近阅读”状态，但用户清后台、断网重进时，进度最好能在本地恢复。我的做法是“先本地，后云端”：每次翻章时把进度写入本地 Storage，同时异步调用云函数写入favorites集合。这样真机飞行模式下，用户依然能打开上次阅读的章节。

// 翻页时的进度保存 function saveProgress(bookId, chapterIndex, scrollTop) { wx.setStorageSync(`progress_${bookId}`, { chapterIndex, scrollTop, updatedAt: Date.now() }) wx.cloud.callFunction({ name: 'saveProgress', data: { bookId, chapterIndex, scrollTop } }).catch(() => { // 网络异常时静默失败，不打断阅读 }) }

Storage 容量虽然有限，但只存进度数据，占用的空间可以忽略。不要为了“离线阅读”把整本小说存到本地，免费版小程序本地缓存上限是 10MB，一本长篇小说动辄几 MB，多放几本就爆了。离线兜底只兜底状态，不兜底内容。

在退出阅读页时，scrollTop从scroll-view的事件里拿到。要注意scroll-view的scroll-top属性和实际滚动像素值在小程序里都对，但scrollTop在顶部回弹时可能出现负值，保存前做一次Math.max(0, scrollTop)。至于进度恢复，进入阅读页时先读本地 storage，把它传给scroll-view，再调用云函数拿最新的云端进度；两侧数据不一致时以“更大的 chapterIndex”为准，避免回跳。

这一章三个小节，写到这里基本能跑。我实际开发中还会给目录列表加loading状态，因为章节目录即使很小，第一次云函数冷启动也可能让用户以为点击没反应。在所有请求之前先setData({ loading: true })，请求完成后无论成功失败都置回 false，这个状态习惯能帮你省下很多排查时间。下一章把搜索和分页串起来。

4. 在线搜索与书库分页：在微信小程序里实现“找书”的完整链路

4.1 搜索接口与防抖：用云函数处理关键词查询

书库页的搜索框往往被做成“只过滤前端已加载的几十条数据”，这在小数据量下能用，一旦书库超过一百本，你就需要真正的搜索接口。微信云开发数据库支持正则匹配，前端可以直连数据库查询，但把搜索逻辑放进云函数有两个好处：不使用前端暴露集合名，且可以在一个函数里同时查书名、作者和简介。

云函数写法如下：

// cloudfunctions/searchBooks/index.js const cloud = require('wx-server-sdk') cloud.init({ env: cloud.DYNAMIC_CURRENT_ENV }) const db = cloud.database() const _ = db.command exports.main = async (event) => { const keyword = String(event.keyword || '').trim() if (!keyword) return { books: [] } const reg = db.RegExp({ regexp: keyword.replace(/[.*+?^${}()|[\]\\]/g, '\\$&'), options: 'i' }) const res = await db.collection('books').where( _.or([ { title: reg }, { author: reg }, { description: reg } ]) ).field({ title: true, author: true, cover: true, chapterCount: true }).limit(20).get() return { books: res.data } }

逻辑说明：正则对象用db.RegExp构造，而不是 JavaScript 的new RegExp，因为这是传给云端数据库的查询条件。options: 'i'表示不区分大小写，可以搜TXT或txt。我在构造正则前先做了一次转义，把.*这类正则符号变成普通字符，避免用户输入(导致查询报错。.field()指定只返回列表页需要的字段，能明显减小回包体积。

前端搜索框要做防抖。云函数调用有冷启动，如果用户每输入一个字就发一次请求，非常容易触发并发限制。下面这段逻辑写在页面里：

// pages/search/search.js let searchTimer = null Page({ data: { keyword: '', books: [], loading: false, searched: false }, onInput(e) { const keyword = e.detail.value clearTimeout(searchTimer) this.setData({ keyword }) if (!keyword.trim()) { this.setData({ books: [], searched: false }) return } searchTimer = setTimeout(() => { this.search(keyword.trim()) }, 300) }, async search(keyword) { if (this.data.loading) return this.setData({ loading: true }) try { const res = await wx.cloud.callFunction({ name: 'searchBooks', data: { keyword } }) this.setData({ books: res.result.books, searched: true }) } finally { this.setData({ loading: false }) } } })

防抖参数 300ms 是通用值，如果云函数冷启动明显，可以放宽到 500ms，但不要低于 200ms，否则低端安卓机上输入法连续输入时抖动无效。另一个细节是搜索结果的“空状态”：搜索完没有结果时，不能只显示空白页，应给出“没有找到相关书籍”的文本提示，很多评审老师会专门搜一个不存在的词来看你有没有处理空数据。

4.2 分页列表加载：onReachBottom 与 loading 状态机

书库首页不能一次把书全部渲染出来。微信小程序的wx.cloud.database()单次get()默认最多返回 20 条，所以分页是必须的。经典做法是用页面自带的生命周期onReachBottom：当页面滚动到底部时触发加载下一页。要控制重复触发，必须维护一个状态机。

我在书库页里的分页代码：

// pages/home/home.js Page({ data: { books: [], page: 0, pageSize: 20, hasMore: true, isLoading: false }, async onLoad() { this.loadBooks(true) }, async onReachBottom() { if (this.data.hasMore) { await this.loadBooks(false) } }, async loadBooks(reset) { if (this.data.isLoading) return this.setData({ isLoading: true }) const db = wx.cloud.database() const page = reset ? 0 : this.data.page + 1 try { const res = await db.collection('books') .orderBy('updatedAt', 'desc') .skip(page * this.data.pageSize) .limit(this.data.pageSize) .get() this.setData({ books: reset ? res.data : this.data.books.concat(res.data), page: page, hasMore: res.data.length === this.data.pageSize, isLoading: false }) } catch (err) { this.setData({ isLoading: false }) wx.showToast({ title: '加载失败，请稍后重试', icon: 'none' }) } } })

这段代码有两个关键判断：第一，if (this.data.isLoading) return防止上拉一次还没返回时再次发起请求；第二，hasMore用“返回条数等于 pageSize”来判断，而不是“页数 < 总页数”，因为云数据库没有直接返回总记录数，用 limit 的溢出判断更简单。skip分页只在数据量小于几千条时好用，毕设演示足够；如果书库要上几万条，建议换成按_id游标分页，常见做法是记录最后一条的_id，下一页用where({ _id: _.gt(lastId) })继续取值。

加载中的视觉反馈也要做。底部分页加载时，给列表尾部加一个“加载中”的 view 或提示；没有更多数据时显示“已经到底了”。这些文案能让演示过程更自然，也能避免用户反复上拉。我见过不少项目加载状态是对的，但没有“没有更多了”的提示，看起来像是应用卡住。

4.3 免费书源接入与合规：优先用开放版权内容做演示

“免费”是这个题目里的高危词。如果直接把网上抓来的小说正文导入数据库，从技术上完全可行，但到毕业设计答辩这一层会面临版权追问，在小程序提审时更可能被拒。我当时的处理原则很简单：演示数据全部来自公有领域作品，或者自己写的样章。这样无论怎么演示、怎么被追问，都能回答“内容来源合法”。

接入外部书源的一般做法：用一个 Node 脚本把公开的 TXT 文件按章节拆开，清洗乱码和广告，再逐批写入云数据库。如果你只是做毕设演示，不需要做定时爬虫，手动跑一次导入脚本就够了。脚本要去处理的问题有几类：编码不统一，老 txt 常见 GBK，读取时要转 UTF-8；章节标题正则要兼容“第X章”“第X节”“楔子”“第一章 相遇”等格式；正文里夹带的 URL 和联系邮箱要过滤；分章后要统计字数，回填到books集合的chapterCount。

如果你连 TXT 都懒得找，还有一个更省事的方案：在云开发控制台手动录入三五个章节作为样书，把封面用公开图库或自己生成的图替代，样章内容多写一点。演示时重点永远是“应用能跑通”，而不是“书库有多全”。我见过有同学导入 500 章盗版小说到项目中，结果小程序包直接超限，最后一天一边删数据一边改代码，非常被动。

书源合规的另一个含义是“免费”二字的展示。小程序页面上不要出现“全网免费小说”“VIP 全免费”这类夸大文案，列表页和详情页标注“本书为公有领域内容”或“演示内容”，审核和答辩都更稳妥。微信小程序平台对“小说、阅读”类目有资质要求，毕设为了避免资质问题，通常选择工具类目，名称里不带“小说”两个字，比如“云端阅读 Demo”。这个取舍后面避坑章还会细说。

5. 微信小程序小说应用避坑指南：5 个容易让毕设翻车的细节

5.1 章节列表渲染不出来，云函数却返回正常

现象：首页书单正常，点进书籍详情页，章节列表一直转圈，控制台没有任何报错；在云开发控制台里手写查询又能查出来。

原因：章节列表由前端直接请求云数据库时，走的是用户权限。云数据库集合默认权限“仅创建者可以读写”，而集合里这些文档是通过控制台导入的，_openid字段要么不存在，要么属于管理员，普通用户对它们没有读权限。云函数查询不受影响，所以云函数调试时一切正常，换到前端调用就静默失败。

解决：在云开发控制台把books、chapters集合的权限调整为“所有用户可读，仅创建者可读写”。如果项目里的阅读进度按照_openid区分用户，favorites集合保持“仅创建者可读写”。改完后在真机上冷启动重新测试，不要只在开发者工具里点预览。

5.2 安卓端正文段落挤在一起，字号忽大忽小

现象：开发工具和 iPhone 上阅读页段落间距正常，安卓真机上同一个页面有时字体突然变大，段落边界消失，排版肉眼可见地乱。

原因：我在rich-text的内联样式里混用了rpx和px。小程序官方对rich-text内的节点样式解析是依赖 WebView 的，部分安卓 WebView 对rpx的支持存在兼容问题，会把rpx当成px处理，导致 34rpx 变成 34px，字号瞬间放大。rich-text本身并不支持把页面级单位带进节点。

解决：buildRichText生成节点时，只写px、em、百分比这类 CSS 标准单位，不写rpx。阅读页的容器还是用rpx做响应式，正文节点用固定font-size: 17px，让用户设置字号时直接改动这个值。改完之后用安卓低版本机型复验一次，别只看旗舰机。

5.3 云函数超时：正文一长就报“调用失败”

现象：前二十章阅读正常，翻到一章字数特别多的章节时，loading 转了几秒后弹出“云函数调用失败”，再次点击有时又好了。

原因：云函数默认超时时间在微信开发者工具里是 3 秒或 5 秒，而一章小说正文可能有 8000 字，加上段落清洗、JSON 序列化和网络传输，容易撞上超时时间。我一开始还在云函数里对正文做了关键词替换，把书中的手机号、日期批量替换成全角字符，耗时更长。

解决：在cloudfunctions目录右键该云函数，进入“云函数配置”，把超时时间从 3 秒调大到 20 秒。同时优化数据链路：正文存纯文本，返回前不做过重的正则处理；如果确实要清洗，放在导入脚本里完成，不要在每次读取时处理。更彻底的方案是章节正文按“预览段落 + 剩余正文”分段返回，首次加载只返回前两段，点击“加载更多”再取剩余部分，但毕设一般不必做到这步。

5.4 onReachBottom 不触发，列表永远只有 20 条

现象：书库页第一次加载出 20 本书，之后怎么往下滑都没有触发下一页，底部也没有“加载中”的状态。

原因：我为了实现“顶部固定搜索框”，把整个列表放进了一个外层view，给它设了height: calc(100vh - 100rpx)，列表在这个 view 内部滚动。onReachBottom是页面的滚动回调，只有页面根节点滚动到底部才会触发；当滚动发生在一个固定高度的子容器里时，页面本身没有滚动事件，所以回调永远不执行。这不是玄学，是页面滚动和容器滚动的区别。

解决：把onReachBottom无法触发的责任归到布局。要么不用内部滚动容器，让搜索框position: sticky悬浮，列表继续由页面滚动承载；要么给内部滚动容器绑定bindscrolltolower事件，在事件里写下一页加载逻辑。我最终选了 sticky 方案，因为改动最小，也符合内容流页面的一般交互。如果你用 scroll-view 做横向轮播，同样不会触发 onReachBottom，需要单独处理。

5.5 免费阅读被审核拦下：别照搬微信小程序登录获取手机号

现象：给小程序加了一个微信手机号快捷登录，提交审核后被打回，理由是“涉及收集用户手机号与实际功能不符”；答辩现场也被老师质疑，为什么一个免费阅读应用要从“微信小程序登录获取手机号”。

原因：微信小程序的手机号授权是平台较敏感的能力，审核会判断手机号是否必要。小说阅读场景不需要手机号，读者只需要一个匿名身份追书；我当时照搬了电商模板，一键登录诱导感太强，反而给自己制造了风险。

解决：改成微信云开发的 openid 匿名登录，也就是前面 2.2 节那个getOpenid云函数。书架、阅读记录全部以 openid 为关联键，不采集任何个人信息。这样功能完整，审核和答辩逻辑也更顺。如果你确实需要用户头像昵称，可以用微信的“昵称填写”能力，但要让用户自愿填写，不能作为强制登录的前置条件。这个改动我只花了一个晚上，省掉了后面至少三轮提审。

这些坑大多集中在从开发者工具转向真机调试那几天，别指望开发工具里跑通就等于项目完成。每遇到一个问题，把“复现步骤 → 原因 → 解法律方案”记进笔记，答辩时被问“你遇到过什么难题”，就是现成的加分素材。

6. 从“能打开”到“能答辩”：验收清单与最后一步优化

6.1 用真机跑通五条验收路径

有些功能在开发者工具里很完美，在真机上就是另一套行为。我的经验是，在答辩前至少花两个下午做真机回归，重点走五条路径：首页书单加载、搜索到打开章节、章节翻页和目录跳转、退出重进恢复进度、飞行模式下的错误提示。下面这张表是我验收时用的检查项，你也可以直接抄走。

每一条都对应一个隐藏的坑：首屏速度慢通常是云函数冷启动，可以把首页书单改成前端直连数据库查询省掉一次冷启动；目录加载慢要检查集合权限和orderBy索引；搜索空态是前端没判断books.length === 0；进度恢复是忘了把scrollTop存成本地；断网处理则必须给所有callFunction包裹catch。

6.2 答辩现场的最后一步：把“免费”讲成“合规”

演示顺序建议按“业务闭环”走，而不是按代码目录走。先打开首页，快速翻到书架，加一本到书架，然后退出小程序再进，展示进度恢复；接着搜索一个关键词，点进正文，把字号调大，再切到目录跳到第 N 章。这一套动作能在五分钟内把数据模型、云函数、缓存、交互全部展示一遍，评审老师不会觉得你在背稿。

收尾时说一句“所有正文来自公有领域或自制样章，因此这个应用可以做到真正的免费”，往往比讲任何技术细节更让人印象深。我当时最后悔的是开题时写计划把“实时排行榜”列进了功能清单，最后实现的却只是按updatedAt排序的替身。如果时间不够，宁可把“最近阅读”做成真功能，也不要让“排行榜”停留在按钮上。

给后来者的一个习惯：每次把项目跑通一个小闭环，就立即在手机上录一段 30 秒的短视频，存到云相册里。毕业后你可能会删掉不必要的代码，但这些视频是你写论文、做 PPT 时的第一手素材，也是你向老师解释“我确实做过”的证据。这个习惯让我在论文瓶颈期省了不少时间，也希望帮到你。

本文还有配套的精品资源，点击获取