1. 從零搭一套圖書借閱小程序先想清楚云開發(fā)能扛住什么做校園或社區(qū)圖書借閱這類小程序最大的誤區(qū)就是一上來就搞 Spring Boot MySQL 服務(wù)器那一套。我?guī)н^幾個類似的項目真正卡住進度的從來不是業(yè)務(wù)邏輯有多復雜——借書還書本身簡單得很——而是沒人愿意長期維護一臺服務(wù)器、沒人愿意去折騰域名和證書、更沒人愿意在半夜被告警電話叫醒說數(shù)據(jù)庫連不上了。云開發(fā)這條路子最適合的就是這種場景三五個人、預算接近于零、需求清晰、用戶量可控。圖書借閱小程序本質(zhì)上就是一批書、一群人、一堆借還記錄數(shù)據(jù)量上萬條就到頭了讀多寫少幾乎沒有高并發(fā)壓力這正是 Serverless 最舒服的區(qū)間。先把這套系統(tǒng)要干的事說清楚管理員把書錄進去書名、作者、ISBN、封面、館藏位置、總冊數(shù)讀者掃碼或搜索找到書點借閱系統(tǒng)扣減可借庫存并生成一條借閱記錄到期前提醒還書時核銷記錄、回滾庫存超期了標紅提示。聽著像玩具項目但真做起來庫存并發(fā)、權(quán)限邊界、時間時區(qū)、列表性能這四個坑一個都不會少。這篇文章就是把我踩過的這些坑按順序攤開講數(shù)據(jù)集合怎么設(shè)計才不會后期改表改到崩潰、借書那一下為什么必須上事務(wù)、云函數(shù)超時到底是哪行代碼拖的、還有一大堆權(quán)限報錯和冷啟動的排查思路。適合剛接觸云開發(fā)、想拿一個完整項目練手的朋友也適合已經(jīng)寫了一版但總在邊界情況上翻車的人。我不打算把這篇寫成 API 手冊文檔上有的東西抄一遍沒意義。下面全是為什么這么設(shè)計和當時出了什么問題的記錄代碼片段你可以直接拿去改。2. 方案選型云開發(fā)和自建后端到底差在哪2.1 把成本、運維和擴展性攤在一張表上看選型這事兒最怕拍腦袋。我一般會把幾個關(guān)鍵維度列出來橫向?qū)Ρ缺苊庾龅揭话氚l(fā)現(xiàn)路走錯了。圖書借閱系統(tǒng)的特點是用戶規(guī)模有限一個學校幾千人、一個社區(qū)幾百人、業(yè)務(wù)邏輯集中在寫操作、沒有復雜的實時通信需求、也沒有大數(shù)據(jù)分析要求。基于這幾個前提我把兩條路線擺在一起維度自建后端服務(wù)器 數(shù)據(jù)庫云開發(fā)云函數(shù) 云數(shù)據(jù)庫 云存儲初期投入需要服務(wù)器、數(shù)據(jù)庫、域名、證書配置周期 3 到 7 天開通環(huán)境即用半小時能跑通第一個接口運維成本系統(tǒng)補丁、備份、監(jiān)控、擴容全靠自己平臺托管基本不用管成本模型固定月費即使沒人用也在燒錢按調(diào)用量計費低峰期費用趨近于零冷啟動無有明顯冷啟動延遲幾百毫秒到兩秒復雜查詢自由度高SQL 想怎么寫怎么寫聚合能力夠用但有邊界跨集合聯(lián)查需要手工拼單次執(zhí)行時長自己控制云函數(shù)有明確超時上限默認較短可調(diào)但有天花板遷移成本低數(shù)據(jù)在自己手里需要提前設(shè)計導出通道避免被綁死結(jié)論很清楚這類項目不需要為了顯得專業(yè)去自建后端。真正需要警惕的是第二條路線的隱性約束——超時時間、單次返回條數(shù)、事務(wù)支持范圍這三樣如果一開始沒摸清楚后面改起來會很痛。2.2 三個必須先量清楚的硬約束第一個是單次查詢返回條數(shù)。小程序端直接查數(shù)據(jù)庫默認一次只給 20 條云函數(shù)里查默認 100 條。很多人寫完列表頁發(fā)現(xiàn)怎么只有 20 本書以為是數(shù)據(jù)沒插進去其實是被截斷了。做書籍列表必須老老實實分頁別想著一次拉全量回來在前端過濾。第二個是云函數(shù)執(zhí)行超時。默認值比較短后臺可以調(diào)高但不是無限的。圖書借閱里最容易超時的場景是批量導入書籍和批量到期掃描。前者一次性插幾百條逐條add必超時后者遍歷所有借閱記錄逐條判斷數(shù)據(jù)一多就掛。解決辦法后面會講批量導入走分批提交到期掃描走定時觸發(fā)器加最小化掃描范圍。第三個是事務(wù)的適用范圍。借書這個動作要同時做兩件事扣庫存、寫記錄。這兩步必須原子完成否則會出現(xiàn)庫存扣了但記錄沒寫、或者兩條借閱記錄搶到同一本書的情況。云開發(fā)的數(shù)據(jù)庫事務(wù)支持在云函數(shù)里使用但有前提所有操作必須在同一個事務(wù)對象上執(zhí)行且事務(wù)內(nèi)有操作數(shù)量和執(zhí)行時間的限制。所以借書邏輯不能拆成幾個獨立云函數(shù)串行調(diào)用必須一口氣做完。注意事務(wù)不是萬能的。它解決的是同一時刻兩個人搶最后一本書的問題解決不了用戶網(wǎng)絡(luò)不好重復點擊提交的問題。后者要在前端做防抖加冪等鍵兩碼事。2.3 需求邊界先畫死別讓功能膨脹拖垮進度我見過太多這類項目死在順便加個功能上。第一版只做四件事書的增刪改查、借、還、逾期提醒。就這四個別貪。會員積分、書評、預約排隊、掃碼入庫、推薦算法全部放到二期。為什么因為圖書借閱的核心難點在數(shù)據(jù)一致性和權(quán)限控制功能一多權(quán)限規(guī)則就復雜規(guī)則一復雜就容易出現(xiàn)某個角色的用戶能改別人記錄這類安全事故而這種問題往往上線之后才被發(fā)現(xiàn)。還有個現(xiàn)實問題如果這個小程序涉及押金、收費借閱類目和資質(zhì)這塊要提前確認清楚別代碼寫完卡在審核上。我一般建議第一版做成純公益的館內(nèi)借閱完全不碰資金流把業(yè)務(wù)跑通再說。3. 數(shù)據(jù)模型設(shè)計把借閱規(guī)則釘進集合結(jié)構(gòu)里3.1 五個核心集合的字段規(guī)劃數(shù)據(jù)模型這一步做扎實后面能省掉一半的麻煩。我最終的集合設(shè)計是這樣字段名統(tǒng)一用下劃線風格避免前后端拼寫不一致集合名用途關(guān)鍵字段books書籍主數(shù)據(jù)_id、title、author、isbn、cover_file_id、category、total_copies、available_copies、location、status、create_timeborrow_records借閱流水_id、openid、book_id、book_snapshot、borrow_time、due_time、return_time、status、overdue_daysusers讀者信息_id、openid、nickname、student_no、max_borrow、current_borrow、statuscategories分類字典_id、name、sort、parent_idnotices公告與提醒_id、title、content、type、publish_time幾個設(shè)計決定值得單獨說一下。庫存用兩個字段而不是一個。total_copies表示館藏總量available_copies表示當前可借數(shù)量。為什么不只存可借數(shù)因為管理員改館藏的時候你需要知道原始總量才能算出正確的可借數(shù)。比如總量從 5 改成 8可借數(shù)應(yīng)該 3而不是直接變成 8。只存一個字段這個計算就沒法做了。用戶身上冗余一個 current_borrow 計數(shù)。嚴格來說這個數(shù)可以從借閱記錄里統(tǒng)計出來但每次借書都去count一遍記錄表既慢又容易在并發(fā)下算錯。冗余一個計數(shù)字段配合事務(wù)一起更新讀取時直接拿速度快得多。代價是要保證這個字段永遠和實際記錄數(shù)一致——這就是后面要講的還書時一定要回滾。status 一律用數(shù)字枚舉不用布爾值。借閱記錄的狀態(tài)至少有借出中、已歸還、已逾期、已丟失。用is_returned: true/false這種布爾設(shè)計將來加丟失狀態(tài)就得改全表。用status: 1/2/3/4加一份常量映射擴展起來毫無壓力。3.2 借閱記錄為什么要存一本書的快照這是我在第二個項目里才想明白的事。最開始 borrow_records 只存book_id展示的時候再去 books 集合里聯(lián)查書名和封面。結(jié)果出了個問題管理員把一本書下架刪除了歷史借閱記錄全部變成未知書籍讀者查自己的借閱歷史一臉懵。解決辦法是在借閱記錄里冗余一份快照book_snapshot: { title, author, cover_file_id, isbn }。借出那一刻把書名作者封面拷一份進去之后書籍怎么改、怎么刪歷史記錄都完整可讀。多占一點存儲空間換來的是數(shù)據(jù)的不可變性——這個交換在借閱系統(tǒng)里絕對劃算。同樣的思路也適用于用戶信息。借閱記錄里存openid就夠了展示昵稱時再查因為昵稱會變。但如果是罰款單、借書憑證這類憑證性數(shù)據(jù)用戶信息也得存快照。區(qū)分標準很簡單這條數(shù)據(jù)是當前狀態(tài)的引用還是當時事實的記錄。前者存 ID后者存快照。3.3 數(shù)據(jù)庫權(quán)限規(guī)則最容易翻車的地方云開發(fā)的數(shù)據(jù)庫權(quán)限有四檔僅創(chuàng)建者可讀寫、所有用戶可讀僅創(chuàng)建者可寫、僅管理端可讀寫、所有用戶可讀寫。選錯一檔要么數(shù)據(jù)泄露要么功能直接不工作。圖書借閱系統(tǒng)的正確配置是books所有用戶可讀僅管理端可寫。普通讀者能瀏覽書目但不能改庫存。borrow_records僅創(chuàng)建者可讀寫。讀者只能看自己的借閱記錄看不到別人的。管理員的操作走云函數(shù)云函數(shù)有管理員權(quán)限不受這條規(guī)則限制。users僅創(chuàng)建者可讀寫。自己的資料自己改。categories、notices所有用戶可讀僅管理端可寫。提示小程序端直接寫數(shù)據(jù)庫用的是創(chuàng)建者身份也就是 openid。一旦某條記錄的_openid字段和你當前用戶對不上寫操作就會失敗報的錯還不一定直觀。所以凡是涉及修改別人的數(shù)據(jù)——比如管理員幫讀者辦理還書——一律走云函數(shù)別在小程序端硬寫。這里有個特別隱蔽的坑云函數(shù)里創(chuàng)建的記錄_openid字段是空的。因為云函數(shù)用的是管理員身份不是用戶身份。如果你在云函數(shù)里插入借閱記錄然后指望小程序端按僅創(chuàng)建者可讀的規(guī)則讀出來會發(fā)現(xiàn)讀不到。解決辦法是在云函數(shù)里手動把 openid 寫進一個自定義字段比如openid查詢時用自己的字段過濾而不是依賴_openid的自動權(quán)限。或者干脆把借閱記錄的讀取也放到云函數(shù)里做。我傾向后者邏輯集中權(quán)限清晰。4. 核心業(yè)務(wù)實現(xiàn)借書那一下到底發(fā)生了什么4.1 庫存并發(fā)是這類系統(tǒng)的頭號殺手把所有邏輯攤開看借書這個動作包含四個判斷和兩個寫入這本書存在且狀態(tài)正常available_copies 0該用戶當前借閱數(shù)未超過上限該用戶沒有已經(jīng)借了同一本書未還寫入一條借閱記錄available_copies減 1用戶current_borrow加 1如果不用事務(wù)最典型的故障是兩個人同時點借最后一本書兩個請求都查到了available_copies 1都判斷通過然后都執(zhí)行扣減最后庫存變成 -1兩條記錄都成功。這在測試階段幾乎發(fā)現(xiàn)不了上線第一天就爆。正確的寫法是把整個流程放進云函數(shù)用事務(wù)包住。下面是我實際用的結(jié)構(gòu)省略了部分校驗// cloudfunctions/borrowBook/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 { bookId } event const { OPENID } cloud.getWXContext() try { return await db.runTransaction(async transaction { // 1. 讀用戶加鎖式讀取 const userRes await transaction.collection(users) .where({ openid: OPENID }).get() if (!userRes.data.length) { throw new Error(USER_NOT_FOUND) } const user userRes.data[0] if (user.status ! 1) throw new Error(USER_DISABLED) if (user.current_borrow user.max_borrow) throw new Error(BORROW_LIMIT) // 2. 讀書籍 const bookRes await transaction.collection(books).doc(bookId).get() const book bookRes.data if (!book || book.status ! 1) throw new Error(BOOK_NOT_AVAILABLE) if (book.available_copies 0) throw new Error(NO_COPY_LEFT) // 3. 查重同一本書不能借兩次 const dupRes await transaction.collection(borrow_records) .where({ openid: OPENID, book_id: bookId, status: 1 }).get() if (dupRes.data.length) throw new Error(ALREADY_BORROWED) // 4. 寫記錄快照在這里生成 const now new Date() const due new Date(now.getTime() 30 * 24 * 3600 * 1000) await transaction.collection(borrow_records).add({ data: { openid: OPENID, book_id: bookId, book_snapshot: { title: book.title, author: book.author, cover_file_id: book.cover_file_id || }, borrow_time: now, due_time: due, return_time: null, status: 1, overdue_days: 0 } }) // 5. 扣庫存 加計數(shù) await transaction.collection(books).doc(bookId).update({ data: { available_copies: _.inc(-1) } }) await transaction.collection(users).doc(user._id).update({ data: { current_borrow: _.inc(1) } }) return { code: 0, dueTime: due } }) } catch (err) { return { code: -1, msg: err.message } } }幾個細節(jié)必須說清楚。_.inc(-1)這個原子操作符是關(guān)鍵。它讓減一在數(shù)據(jù)庫層面完成而不是先讀出來再寫回去。即使事務(wù)沒鎖住inc本身也不會丟更新。判斷重復借閱時我查的是status 1 的記錄也就是未歸還的。如果用戶借了還了再借是允許的所以不能簡單按 book_id 查。所有校驗必須在事務(wù)內(nèi)完成。把available_copies 0的判斷放到事務(wù)外面事務(wù)就白用了因為讀的時候是舊值。錯誤碼用字符串而不是中文提示。前端拿到NO_COPY_LEFT再映射成這本書已經(jīng)全部借出了方便做多語言和統(tǒng)一文案也避免云函數(shù)返回中文在不同環(huán)境下編碼出問題。4.2 還書流程里的兩個易錯點還書看起來比借書簡單實際上有兩個坑。第一個坑是重復還書。用戶連點兩次、或者管理員手誤點了兩下庫存會被加兩次。所以還書的第一步必須是檢查記錄當前狀態(tài)只有status 1才允許歸還歸還后立刻置為 2。這個檢查和更新必須在事務(wù)里否則兩次并發(fā)請求都能通過狀態(tài)檢查。第二個坑是逾期天數(shù)怎么算。這里我踩過最蠢的一次坑云函數(shù)運行環(huán)境的默認時間是 UTCnew Date()拿到的比北京時間晚 8 小時。如果你直接用new Date()和due_time相減算天數(shù)晚上八點以后的數(shù)據(jù)會全部錯一天。正確做法是用時間戳算差值然后按天向下取整const MS_PER_DAY 24 * 3600 * 1000 const diff Date.now() - new Date(record.due_time).getTime() const overdueDays diff 0 ? Math.floor(diff / MS_PER_DAY) : 0注意是Math.floor而不是Math.ceil。超期 1 小時算 0 天人性化超期 25 小時算 1 天。如果用ceil超期一分鐘就顯示已逾期 1 天用戶會覺得系統(tǒng)在訛他。還有一個細節(jié)due_time存進去的時候是 Date 對象取出來在云函數(shù)里拿到的是 Date在小程序端拿到的是字符串。兩邊的比較方式不一樣別在小程序端直接拿字符串做減法會得到 NaN。前端只負責展示計算全部放云函數(shù)。4.3 定時觸發(fā)器做逾期掃描的正確姿勢逾期狀態(tài)有兩種維護方式一種是查的時候?qū)崟r算一種是用定時任務(wù)提前標好。我建議兩個都做定時任務(wù)每天凌晨跑一次把已經(jīng)逾期的記錄 status 改成 3 并寫入 overdue_days用戶查詢時再根據(jù) due_time 實時兜底算一遍。原因是定時任務(wù)可能因為各種原因沒跑成功實時計算保證展示永遠正確。定時觸發(fā)器的配置文件長這樣{ triggers: [ { name: dailyOverdueScan, type: timer, config: 0 0 2 * * * * } ] }這個 cron 表達式是七位的秒 分 時 日 月 周 年0 0 2 * * * *表示每天凌晨兩點。很多人寫六位表達式少一位秒配置不生效還不報錯查半天。掃描邏輯上有個優(yōu)化點不要where({ status: 1 })全表拉出來逐條判斷數(shù)據(jù)量上千條就可能超時。正確做法是讓數(shù)據(jù)庫幫你過濾const _ db.command const now new Date() let hasMore true let lastId null const BATCH 100 while (hasMore) { const query { status: 1, due_time: _.lt(now) } if (lastId) query._id _.gt(lastId) const res await db.collection(borrow_records) .where(query).orderBy(_id, asc).limit(BATCH).get() if (!res.data.length) break // 逐條更新狀態(tài)這里用 Promise.all 但控制并發(fā) await Promise.all(res.data.map(rec { const days Math.floor((now.getTime() - new Date(rec.due_time).getTime()) / MS_PER_DAY) return db.collection(borrow_records).doc(rec._id).update({ data: { status: 3, overdue_days: days } }) })) lastId res.data[res.data.length - 1]._id hasMore res.data.length BATCH }用_id做游標分頁而不是skip這是數(shù)據(jù)量上來之后必須要改的一點。skip(10000)意味著數(shù)據(jù)庫要掃描并丟棄前一萬條越往后越慢最后直接超時。游標分頁每次都從上次結(jié)束的位置開始性能是平的。注意Promise.all一次并發(fā) 100 個數(shù)據(jù)庫寫操作在云函數(shù)里可能會被打限流。實測下來建議把 BATCH 降到 20 到 50 之間或者用分批串行的方式慢一點但穩(wěn)。5. 前端體驗與性能那些讓人抓狂的小細節(jié)5.1 列表分頁和搜索的取舍書籍列表是整個小程序里訪問最頻繁的頁面它的性能直接決定用戶第一印象。分頁這塊小程序端用skip limit就行因為列表頁用戶最多翻個十幾頁skip的累積開銷可以接受。但一定要做觸底加載而不是頁碼跳轉(zhuǎn)符合小程序的操作習慣。加載狀態(tài)要有骨架屏或者 loading 占位否則用戶會以為卡死了。搜索是最容易做錯的。很多人上來就寫db.collection(books).where({ title: db.RegExp({ regexp: keyword, options: i }) }).get()這個寫法在數(shù)據(jù)量小的時候沒問題但正則查詢用不上索引全表掃描幾百條還行幾千條就明顯卡。更要命的是用戶輸入的關(guān)鍵詞如果帶特殊字符正則可能直接報錯。我的處理策略是分兩層第一層書名、作者前綴匹配用db.RegExp({ regexp: ^ escapeRegExp(keyword) })前綴正則是可以用上索引的。用戶輸三體能搜到《三體》《三體 II》。第二層如果第一層結(jié)果為空再降級做全文模糊匹配同時限制返回 20 條。另外一定要對用戶輸入做轉(zhuǎn)義處理把.*()[]這些正則元字符替換掉否則用戶輸個(就白屏了。function escapeRegExp(str) { return str.replace(/[.*?^${}()|[\]\\]/g, \\$) }如果書籍量真的很大比如幾萬條正則在任何位置匹配都不合適這時候要么上云開發(fā)的聚合搜索要么在錄入書籍時預生成一個拼音首字母字段讓用戶能按拼音首字母快速定位。這個優(yōu)化我在一個兩千多本書的項目里做過搜索響應(yīng)從兩秒多降到兩百毫秒以內(nèi)。5.2 封面圖片云存儲的存儲和加載封面圖是這類小程序里最占體積的東西。常見的錯誤做法是把圖片轉(zhuǎn)成 base64 存進數(shù)據(jù)庫幾百本書下來數(shù)據(jù)庫直接告急查詢還慢得要命。正確做法是圖片上傳到云存儲數(shù)據(jù)庫里只存fileID。展示的時候用cloud://開頭的 fileID小程序端的image組件可以直接識別不需要先換成臨時鏈接。如果你需要在 web 端或者分享卡片里用才需要調(diào)用getTempFileURL換鏈接而且臨時鏈接有有效期別緩存太久。上傳前必須壓縮。我用wx.compressImage質(zhì)量設(shè)到 60 到 70 之間寬度壓到 750px 以內(nèi)一本書的封面從兩三兆能壓到一百多 KB。這個操作在管理端做讀者端永遠拿到的都是壓好的圖。還有個容易忽略的點刪除書籍時記得刪云存儲里的文件。云開發(fā)的數(shù)據(jù)庫和云存儲是兩個獨立系統(tǒng)刪記錄不會自動刪文件。時間一長云存儲里堆一堆孤兒文件既占空間又占額度。我的做法是在刪除云函數(shù)的最后加一步cloud.deleteFile失敗也不影響主流程但日志要記下來。5.3 交互細節(jié)上的幾個加分項借書按鈕的防重復點擊最簡單有效的辦法是點擊后立刻setData({ submitting: true })把按鈕置灰請求返回再恢復。不要指望用戶手不抖。掃碼借書這個功能值得做。給每本書貼一個碼內(nèi)容是書籍的_id或者 ISBN用戶掃碼直接跳詳情頁。用wx.scanCode一行代碼的事體驗提升非常明顯尤其對老年讀者友好。借閱列表的排序默認按借閱時間倒序但要把已逾期的置頂。實現(xiàn)上有兩種方式一種是數(shù)據(jù)庫排序字段設(shè)計一種是前端分組。我傾向前端分組把數(shù)據(jù)分成逾期中和其他兩個數(shù)組分別渲染邏輯清晰也不影響分頁。6. 排錯實錄那些報錯信息背后的真實原因6.1 高頻報錯速查表下面這些都是我在實際項目里真實遇到并解決過的問題按出現(xiàn)頻率排序報錯或現(xiàn)象真實原因處理方式errCode: -502005 database collection not exists集合沒創(chuàng)建或者云函數(shù)連的環(huán)境不對在控制臺手動建集合檢查cloud.init的環(huán)境 IDpermission denied權(quán)限規(guī)則和操作身份不匹配寫操作走云函數(shù)或用自定義 openid 字段過濾云函數(shù)返回Timeout循環(huán)里逐條 await或全表掃描改批量操作加_id游標分頁縮小 where 范圍首次調(diào)用特別慢后面正常冷啟動提高內(nèi)存配置關(guān)鍵路徑減少依賴包體積庫存出現(xiàn)負數(shù)沒用事務(wù)或事務(wù)內(nèi)校驗不全全部校驗搬進事務(wù)用_.inc原子操作列表只顯示 20 條小程序端查詢默認限制顯式分頁或用云函數(shù)查默認 100 條借閱記錄查不到_openid云函數(shù)插入的記錄不帶 openid手動寫入openid字段查詢時用它過濾逾期天數(shù)差一天云函數(shù) UTC 時區(qū)用時間戳算差值不用字符串比較cloud.callFunction:fail云函數(shù)沒上傳部署或函數(shù)名拼錯右鍵上傳并部署檢查名字大小寫圖片不顯示存的是 http 鏈接或未壓縮的超大圖統(tǒng)一存 fileID上傳前壓縮6.2 冷啟動不是 bug但必須緩解冷啟動這個事很多人第一次遇到會以為是代碼有問題?，F(xiàn)象很典型早上第一個用戶打開小程序加載首頁轉(zhuǎn)圈兩秒多之后就飛快。原因是云函數(shù)實例被回收了重新拉起需要初始化時間。緩解手段有幾個按性價比排序減小依賴體積。云函數(shù)目錄里的node_modules越大冷啟動越慢。我見過有人在云函數(shù)里裝了整個lodash和moment其實只用了一個函數(shù)。日期處理用原生Date就夠工具函數(shù)自己寫幾行包體積能從幾十兆降到幾兆。提高內(nèi)存配置。云開發(fā)后臺可以調(diào)云函數(shù)的內(nèi)存配置越高分配的 CPU 越強初始化也越快。這個幾乎不用改代碼調(diào)一下配置就有改善。拆分函數(shù)。一個巨型云函數(shù)處理所有邏輯初始化時要把所有依賴都加載一遍。拆成借書還書查書幾個小函數(shù)每個只加載自己需要的依賴單次冷啟動時間會短很多。前端做體驗兜底。首頁加載時先渲染本地緩存的書目列表wx.setStorageSync存一份同時發(fā)起請求拿到新數(shù)據(jù)再替換。用戶感知不到等待。6.3 上線前的自查清單我在每次交付前會過一遍這張單子能擋掉大部分線上事故所有涉及多表寫入的操作是否都在事務(wù)內(nèi)借書、還書、刪書這三個必須檢查。所有查詢是否都加了分頁有沒有哪個頁面在偷偷全表拉取數(shù)據(jù)庫權(quán)限規(guī)則是否逐條核對過特別是books的寫權(quán)限有沒有誤開給所有用戶。云存儲里有沒有孤兒文件建議寫個一次性腳本清理。定時觸發(fā)器是否真的跑起來了可以在函數(shù)里加一行日志觀察兩天的執(zhí)行記錄。所有new Date()的地方是否都用時間戳計算避免時區(qū)問題錯誤碼是否都有對應(yīng)的用戶友好文案有沒有哪個分支會直接彈出undefined用戶連續(xù)點擊提交按鈕會不會產(chǎn)生重復數(shù)據(jù)冪等性檢查做了沒有7. 我在幾個項目里攢下的經(jīng)驗最后說點零碎的、文檔里不會寫的東西。別在云函數(shù)里做遞歸。有次我寫了個分類樹遞歸查詢本地測試沒問題線上數(shù)據(jù)一深就超時報錯信息還特別模糊。分類這種層級不深的數(shù)據(jù)一次性全查出來在前端組樹就行幾十條數(shù)據(jù)的內(nèi)存開銷可以忽略。數(shù)據(jù)庫索引早點建。云開發(fā)控制臺可以給字段建索引。borrow_records的openid、status、due_timebooks的title、category這幾個字段建上索引查詢速度差別是數(shù)量級的。索引這事不占多少工作量但一定要在上線前做完等數(shù)據(jù)多了再建建索引本身就要花很久。測試數(shù)據(jù)一定要造臟數(shù)據(jù)。我在測試階段永遠會插幾條這樣的記錄庫存為 0 的書、已經(jīng)被刪除的書但記錄還在、due_time 是去年的記錄、openid 為空的用戶。這些邊界數(shù)據(jù)能提前暴露 80% 的空指針和狀態(tài)判斷漏洞比寫一百個單元測試管用。給管理員留一個數(shù)據(jù)導出入口。哪怕第一版只是個簡單的導出借閱記錄為 CSV的功能。理由很現(xiàn)實一旦你想換方案、或者需要給上級交一份統(tǒng)計報表沒有導出通道會非常被動。這個功能實現(xiàn)起來不復雜云函數(shù)里拼好 CSV 字符串傳到云存儲返回一個下載鏈接就完事。日志要打但別亂打。云函數(shù)里console.log的內(nèi)容在控制臺能看但默認保留時間有限。關(guān)鍵路徑——借書成功、還書成功、事務(wù)失敗——打一行結(jié)構(gòu)化日志包含 openid、book_id、錯誤碼。出問題時這幾行日志能省掉你半天排查時間。非關(guān)鍵路徑別打日志太多反而看不清。這套系統(tǒng)我從第一版到現(xiàn)在改了三輪最大的感受是云開發(fā)的天花板不在技術(shù)能力而在你有沒有把邊界情況想全。庫存并發(fā)、時區(qū)、權(quán)限、分頁、重復提交這五個點每一個都值得單獨寫一段代碼去防而它們恰恰是最容易被先跑通再說跳過的部分。等用戶量上來、數(shù)據(jù)變多這些跳過的坑會一個一個找回來。