做圖書借閱類小程序的人不少但真正把借還閉環(huán)跑順、上線后不被并發(fā)和數(shù)據(jù)一致性坑到的并不多。我前后參與過(guò)幾個(gè)類似的項(xiàng)目最深的體會(huì)是基于云開(kāi)發(fā)的微信小程序圖書借閱系統(tǒng)難點(diǎn)從來(lái)不在“借書、還書、查書”這幾個(gè)頁(yè)面上而在于副本狀態(tài)怎么記、并發(fā)點(diǎn)擊怎么防、權(quán)限規(guī)則怎么配、配額怎么省。這篇文章就把這套系統(tǒng)的設(shè)計(jì)思路和我踩過(guò)的坑一次性攤開(kāi)講從技術(shù)選型的賬本到數(shù)據(jù)模型的三層拆分再到借還書的原子更新寫法、權(quán)限規(guī)則的隱藏陷阱、前端交互的細(xì)節(jié)打磨最后到上線后才暴露的超時(shí)和配額問(wèn)題。不管你是剛接需求的學(xué)生開(kāi)發(fā)者還是想快速交付一個(gè)小型借閱工具的一線同學(xué)都能從里面找到可以直接抄的部分也能提前避開(kāi)那些我花了幾個(gè)通宵才定位到的坑。1. 先把方案賬算清楚這個(gè)系統(tǒng)到底該不該用云開(kāi)發(fā)很多人一上來(lái)就開(kāi)始建集合、寫頁(yè)面寫到一半發(fā)現(xiàn)某個(gè)能力缺失推倒重來(lái)。圖書借閱這種業(yè)務(wù)規(guī)模通常不大但業(yè)務(wù)規(guī)則很密選型階段多花半天時(shí)間算賬后面能省掉一周的返工。1.1 圖書借閱的業(yè)務(wù)閉環(huán)其實(shí)很短把需求攤開(kāi)看一個(gè)最小可用的借閱系統(tǒng)要干的事就那么幾件錄入書目、給每本書生成可借副本、讀者掃碼或搜索發(fā)起借閱、管理員確認(rèn)或自動(dòng)放行、到期提醒、歸還入庫(kù)、逾期統(tǒng)計(jì)。整個(gè)閉環(huán)里真正復(fù)雜的不是功能數(shù)量而是狀態(tài)流轉(zhuǎn)——一本書可能處于“在架可借”“已借出”“預(yù)約中”“維修中”“下架”這幾種狀態(tài)每個(gè)狀態(tài)能做什么操作是固定的。這個(gè)特征決定了技術(shù)選型的核心訴求狀態(tài)更新的原子性比高并發(fā)吞吐更重要開(kāi)發(fā)迭代速度比峰值性能更重要。一個(gè)小型圖書室可能一天就幾十次借還但每一次借還都不能出現(xiàn)“同一本書借給了兩個(gè)人”這種事故。理解這一點(diǎn)你就明白為什么很多團(tuán)隊(duì)最終選了云開(kāi)發(fā)——它把賬號(hào)體系、數(shù)據(jù)庫(kù)、存儲(chǔ)、定時(shí)任務(wù)、消息推送全都打包好了省掉的是最耗時(shí)的基建部分。我在第一個(gè)項(xiàng)目里試過(guò)自建后端光是登錄態(tài)維護(hù)、文件上傳、定時(shí)任務(wù)這三塊就寫了一周多業(yè)務(wù)代碼反而只占三成。后來(lái)?yè)Q成云開(kāi)發(fā)同樣的功能兩天跑通。不是說(shuō)自建不好而是對(duì)于借閱這類“業(yè)務(wù)復(fù)雜、流量平緩”的系統(tǒng)基建投入的性價(jià)比確實(shí)低。1.2 三條技術(shù)路線的成本對(duì)照選型不要憑感覺(jué)把關(guān)鍵維度列成表答案會(huì)自己浮出來(lái)。下面這張表是我在幾個(gè)項(xiàng)目里反復(fù)驗(yàn)證過(guò)的對(duì)比成本估算按“一個(gè)人獨(dú)立完成”的口徑。維度云開(kāi)發(fā)一體化方案自建服務(wù)端 云主機(jī)純小程序本地存儲(chǔ)初始搭建耗時(shí)半天到一天三到七天兩小時(shí)登錄鑒權(quán)平臺(tái)自帶身份標(biāo)識(shí)直接可用需自行對(duì)接登錄態(tài)校驗(yàn)無(wú)無(wú)法區(qū)分用戶數(shù)據(jù)一致性單文檔更新原子支持事務(wù)完全自主可控僅本機(jī)有效換設(shè)備即丟多端共享數(shù)據(jù)天然支持需自行設(shè)計(jì)接口不支持定時(shí)任務(wù)平臺(tái)提供觸發(fā)器需自行部署調(diào)度不支持運(yùn)維負(fù)擔(dān)基本為零需要監(jiān)控、備份、擴(kuò)容零成本模型按調(diào)用量和存儲(chǔ)計(jì)費(fèi)小規(guī)?？煽毓潭ǚ?wù)器成本零適合規(guī)模單館藏幾千冊(cè)、日借還百次級(jí)多館、萬(wàn)級(jí)用戶僅個(gè)人練手從表里能看出來(lái)純本地存儲(chǔ)那條路只能用來(lái)交作業(yè)一旦涉及“讀者和管理員看到同一份數(shù)據(jù)”就必須有服務(wù)端。自建方案的自由度最高但你要為這份自由付出運(yùn)維和安全的代價(jià)。云開(kāi)發(fā)站在中間犧牲了一部分底層控制權(quán)換來(lái)的是把精力全部放在業(yè)務(wù)邏輯上。這里有個(gè)容易被忽略的判斷點(diǎn)你有沒(méi)有穩(wěn)定的運(yùn)維能力。數(shù)據(jù)庫(kù)要備份、服務(wù)要監(jiān)控、出問(wèn)題要有人半夜爬起來(lái)看這些在自建方案里是硬成本。如果你的團(tuán)隊(duì)里沒(méi)有專門負(fù)責(zé)這塊的人那云開(kāi)發(fā)省下的不只是錢是整條責(zé)任鏈。1.3 云開(kāi)發(fā)明確做不了或者做起來(lái)很難的事選型不能只看好處邊界必須提前摸清。我在實(shí)際項(xiàng)目里遇到過(guò)幾個(gè)“以為能做、結(jié)果繞了大彎”的地方提前說(shuō)出來(lái)能幫你少走彎路。第一是復(fù)雜聚合統(tǒng)計(jì)。想要“按月份、按分類、按讀者類型三維交叉統(tǒng)計(jì)借閱量”用云開(kāi)發(fā)的聚合能力可以寫但可讀性和調(diào)試體驗(yàn)都不算友好一旦維度超過(guò)三個(gè)查詢語(yǔ)句會(huì)長(zhǎng)到難以維護(hù)。我的做法是把明細(xì)數(shù)據(jù)同步一份到表格類工具報(bào)表在那邊做小程序里只展示最近七天的簡(jiǎn)單統(tǒng)計(jì)。第二是大體量數(shù)據(jù)的批量導(dǎo)入導(dǎo)出。控制臺(tái)的單次導(dǎo)入有數(shù)量限制幾千條書目要分批導(dǎo)還得處理好重復(fù)主鍵。我一般寫一個(gè)臨時(shí)的云函數(shù)做分批寫入每批兩百條寫完刪掉函數(shù)比在控制臺(tái)點(diǎn)一百次強(qiáng)。第三是精確到毫秒級(jí)的強(qiáng)一致事務(wù)。云開(kāi)發(fā)的事務(wù)能力在云函數(shù)里可用但事務(wù)內(nèi)可執(zhí)行的操作次數(shù)和可用的操作類型都有限制復(fù)雜邏輯硬塞進(jìn)事務(wù)會(huì)超時(shí)。涉及多步校驗(yàn)的借閱流程我更傾向于用“條件更新 狀態(tài)機(jī)”的方式替代大事務(wù)。提示判斷某個(gè)功能能不能做別只看文檔里有沒(méi)有這個(gè) API要看它在你的業(yè)務(wù)規(guī)模下會(huì)不會(huì)撞到限制。文檔寫“支持”和你實(shí)際能用得舒服是兩件事。2. 數(shù)據(jù)建模圖書、副本、借閱記錄這三張表決定后面所有麻煩數(shù)據(jù)模型一旦定錯(cuò)后面每一行代碼都在還債。我見(jiàn)過(guò)最常見(jiàn)的錯(cuò)誤是把“書目信息”和“實(shí)體書”混在一張表里結(jié)果一本書買了兩冊(cè)就不知道該怎么記最后只能用數(shù)量字段硬湊借出一冊(cè)就減一還回來(lái)再加一中間任何一次異常都會(huì)讓數(shù)量對(duì)不上。2.1 為什么“圖書”和“副本”必須拆開(kāi)打個(gè)生活化的比方書目信息相當(dāng)于身份證上的姓名和照片副本相當(dāng)于具體的每一個(gè)人?！度w》這本書的標(biāo)題、作者、封面只有一份但圖書室里可能有三本。你借走的是其中某一本實(shí)體書不是“《三體》這個(gè)概念”。拆成兩層之后books集合存書目元信息copies集合存每一冊(cè)實(shí)體書的唯一編號(hào)、所屬書目、當(dāng)前狀態(tài)、所在書架位置。這樣帶來(lái)三個(gè)直接好處一是可以精確知道哪一冊(cè)被誰(shuí)借走歸還時(shí)能定位到具體那本二是同一書目下不同副本可以處于不同狀態(tài)一本在架一本外借完全正常三是丟失或損壞時(shí)可以單獨(dú)標(biāo)記某一冊(cè)不影響其他副本可借。如果不拆會(huì)出現(xiàn)什么情況讀者頁(yè)面上顯示“可借 2 本”他點(diǎn)借閱系統(tǒng)隨便拿一條記錄改狀態(tài)改完發(fā)現(xiàn)那一冊(cè)其實(shí)已經(jīng)借出去了或者兩個(gè)讀者同時(shí)借同一冊(cè)。數(shù)量字段是最不可靠的狀態(tài)載體因?yàn)樗鼪](méi)有身份。2.2 借出狀態(tài)到底該存在哪拆開(kāi)之后緊接著一個(gè)問(wèn)題副本的“當(dāng)前是否借出”是記在copies表上還是只記在借閱記錄表里靠查詢推導(dǎo)兩種做法我都試過(guò)。純靠借閱記錄推導(dǎo)的做法是“只存事實(shí)狀態(tài)靠算”理論上最干凈——查某冊(cè)書是否可借就去借閱表里找有沒(méi)有“未歸還”的記錄。但實(shí)際用起來(lái)很痛苦每次列表展示都要帶一次關(guān)聯(lián)查詢列表一百條就是一百次查詢配額瞬間打光頁(yè)面還卡。最終我采用的是雙寫 主狀態(tài)字段copies表里放一個(gè)status字段作為權(quán)威狀態(tài)借閱記錄表里放完整流水。借出時(shí)用條件更新把status從“在架”改成“外借”同時(shí)插入一條借閱記錄。歸還時(shí)反過(guò)來(lái)。兩處數(shù)據(jù)理論上可能不一致所以我會(huì)加一個(gè)每天跑一次的校驗(yàn)任務(wù)比對(duì)狀態(tài)和流水發(fā)現(xiàn)不一致就告警。這個(gè)設(shè)計(jì)的核心思路是狀態(tài)字段用于快速展示和條件判斷流水記錄用于審計(jì)和對(duì)賬。兩者職責(zé)不同不要試圖只留一個(gè)。用狀態(tài)字段做展示查詢成本幾乎為零用流水做統(tǒng)計(jì)和追溯數(shù)據(jù)永遠(yuǎn)完整。2.3 字段清單與索引規(guī)劃下面是我現(xiàn)在這套項(xiàng)目實(shí)際在用的字段設(shè)計(jì)可以直接拿去改。books集合書目字段類型說(shuō)明_idstring系統(tǒng)主鍵isbnstring國(guó)際標(biāo)準(zhǔn)書號(hào)用于掃碼識(shí)別可為空titlestring書名必填authorstring作者publisherstring出版社categorystring分類用固定枚舉值coverFileIdstring封面在云存儲(chǔ)中的文件標(biāo)識(shí)totalCopiesnumber副本總數(shù)冗余字段availableCopiesnumber在架數(shù)量冗余字段createdAtdate錄入時(shí)間copies集合副本字段類型說(shuō)明_idstring副本主鍵同時(shí)作為條碼內(nèi)容bookIdstring關(guān)聯(lián)書目主鍵barcodestring可讀條碼建議簡(jiǎn)短statusstring在架/外借/預(yù)約/維修/下架shelfstring存放位置方便找書currentLoanIdstring當(dāng)前借閱記錄主鍵在架時(shí)為空updatedAtdate狀態(tài)變更時(shí)間loans集合借閱記錄字段類型說(shuō)明_idstring記錄主鍵copyIdstring副本主鍵bookIdstring書目主鍵冗余便于統(tǒng)計(jì)userIdstring借閱人身份標(biāo)識(shí)borrowAtdate借出時(shí)間dueAtdate應(yīng)還時(shí)間returnAtdate實(shí)際歸還時(shí)間未還為 nullstatusstring借閱中/已歸還/已逾期索引用得好查詢快十倍用不好等于沒(méi)建。我的經(jīng)驗(yàn)是給三類查詢建索引copies上按bookId和status建組合索引用于書目詳情頁(yè)展示可借副本loans上按userId和status建組合索引用于“我的借閱”loans上按dueAt單獨(dú)建索引用于逾期掃描任務(wù)。建索引的時(shí)候注意一點(diǎn)云開(kāi)發(fā)控制臺(tái)建索引是異步生效的剛建完立刻測(cè)可能還是慢等一兩分鐘再看。2.4 冗余字段為了查詢方便做的妥協(xié)嚴(yán)格范式的設(shè)計(jì)會(huì)把totalCopies和availableCopies去掉因?yàn)槎寄軓腸opies算出來(lái)。但真實(shí)項(xiàng)目里首頁(yè)書目列表要顯示“可借 2/3”如果每本書都去copies聚合一次一百本書就是一百次聚合查詢?cè)崎_(kāi)發(fā)的調(diào)用配額撐不住。所以我在books上冗余了這兩個(gè)數(shù)字代價(jià)是要維護(hù)一致性。維護(hù)方式很簡(jiǎn)單所有改變副本狀態(tài)的操作都走同一個(gè)云函數(shù)入口在里面順帶更新一次計(jì)數(shù)。關(guān)鍵在于只允許一個(gè)入口改狀態(tài)一旦有第二個(gè)地方也能改copies.status冗余字段遲早會(huì)漂。更新計(jì)數(shù)的寫法上有個(gè)細(xì)節(jié)。不要先查出來(lái)再寫回去那會(huì)有并發(fā)覆蓋問(wèn)題。用原子自增自減指令把“加一減一”交給數(shù)據(jù)庫(kù)引擎執(zhí)行// 借出成功后在架數(shù)量減一 await db.collection(books).doc(bookId).update({ data: { availableCopies: db.command.inc(-1) } })inc是原子操作不管多少個(gè)請(qǐng)求同時(shí)打過(guò)來(lái)結(jié)果都是準(zhǔn)確累減。這一點(diǎn)比“先 get 再 update”可靠得多后者在兩個(gè)請(qǐng)求同時(shí)到達(dá)時(shí)會(huì)讀到相同的舊值最終只減了一次。3. 借書還書那幾行代碼是并發(fā)問(wèn)題的重災(zāi)區(qū)整個(gè)系統(tǒng)里最不能出錯(cuò)的就是借閱動(dòng)作。用戶連點(diǎn)兩下、兩個(gè)人搶同一本書、網(wǎng)絡(luò)重試導(dǎo)致請(qǐng)求重復(fù)提交這幾種情況在真實(shí)使用中都會(huì)發(fā)生而且往往發(fā)生在你最不希望發(fā)生的時(shí)刻。3.1 一次借閱動(dòng)作背后要改幾個(gè)地方點(diǎn)一下“借閱”按鈕后端實(shí)際要做的事有校驗(yàn)用戶是否有未繳罰款、校驗(yàn)該書是否在架、把副本狀態(tài)改成外借、插入借閱記錄、給書目在架數(shù)量減一、記錄操作日志。六步操作只要中間斷一步數(shù)據(jù)就不一致。最危險(xiǎn)的是“副本狀態(tài)改了但借閱記錄沒(méi)插進(jìn)去”這會(huì)導(dǎo)致書顯示已借出但沒(méi)有任何人認(rèn)領(lǐng)等于憑空消失一本。反過(guò)來(lái)“記錄插了但狀態(tài)沒(méi)改”就是同一本書可以被無(wú)限借。所以這里的核心問(wèn)題不是代碼寫得多不多而是執(zhí)行順序和失敗補(bǔ)償。我的順序是先做條件更新改狀態(tài)成功后再插記錄。因?yàn)闂l件更新本身帶校驗(yàn)?zāi)芰Α率【驼f(shuō)明狀態(tài)不對(duì)直接返回錯(cuò)誤這時(shí)候還沒(méi)插記錄天然不會(huì)臟。如果插記錄失敗再補(bǔ)一個(gè)回滾把狀態(tài)改回在架加個(gè)重試。這個(gè)順序的好處是把“可能失敗”的操作放在前面后面的失敗可以回滾前面失敗直接終止。3.2 條件更新做樂(lè)觀鎖的具體寫法云開(kāi)發(fā)的數(shù)據(jù)庫(kù)更新接口支持在條件里帶上狀態(tài)判斷返回結(jié)果里的stats.updated會(huì)告訴你到底改沒(méi)改成功。這就是最輕量的樂(lè)觀鎖不需要額外加鎖字段。// 借書只有狀態(tài)仍是“在架”的副本才允許被借走 const copyResult await db.collection(copies).where({ _id: copyId, status: available }).update({ data: { status: borrowed, updatedAt: new Date() } }) if (copyResult.stats.updated 0) { // 更新了 0 條說(shuō)明條件不滿足要么副本不存在要么已經(jīng)被別人借走 return { code: 409, msg: 這本書剛被借走了換一本吧 } }這段代碼的價(jià)值在于把“判斷”和“修改”合并成了一個(gè)原子操作。傳統(tǒng)寫法是先get查狀態(tài)是不是在架再update這中間有個(gè)時(shí)間窗兩個(gè)人同時(shí)查到在架然后都執(zhí)行更新結(jié)果就是超借。而條件更新把判斷交給數(shù)據(jù)庫(kù)在執(zhí)行時(shí)完成中間沒(méi)有窗口。有個(gè)細(xì)節(jié)要提醒條件里的字段必須和數(shù)據(jù)庫(kù)里的值完全一致status如果存的是中文“在架”而條件里寫available更新永遠(yuǎn)返回 0 條你會(huì)以為是并發(fā)問(wèn)題其實(shí)是拼寫問(wèn)題。我第一次就栽在這上面排查了半小時(shí)才發(fā)現(xiàn)是枚舉值不統(tǒng)一。建議所有狀態(tài)值統(tǒng)一定義成常量前端后端共用一份。3.3 事務(wù)的適用邊界與實(shí)測(cè)限制條件更新能解決單文檔的原子性問(wèn)題但如果一次操作要改兩個(gè)集合比如“改副本狀態(tài)”加“改用戶借閱計(jì)數(shù)”就涉及跨文檔了。云開(kāi)發(fā)提供了事務(wù)能力在云函數(shù)里可以開(kāi)啟。事務(wù)的寫法大致是這樣const transaction await db.startTransaction() try { const copy await transaction.collection(copies).doc(copyId).get() if (copy.data.status ! available) { await transaction.rollback() return { code: 409, msg: 副本狀態(tài)不可借 } } await transaction.collection(copies).doc(copyId).update({ data: { status: borrowed } }) await transaction.collection(loans).add({ data: { copyId, userId, borrowAt: new Date(), status: borrowing } }) await transaction.commit() } catch (err) { await transaction.rollback() throw err }看起來(lái)很美但實(shí)際用起來(lái)要注意幾點(diǎn)。事務(wù)的存活時(shí)間有限里面操作步驟多了會(huì)超時(shí)事務(wù)內(nèi)能做的操作類型也有限制一些聚合類查詢?cè)诶锩嬗貌涣俗钜氖钦{(diào)試體驗(yàn)事務(wù)報(bào)錯(cuò)時(shí)的錯(cuò)誤信息往往很籠統(tǒng)你得靠日志一點(diǎn)點(diǎn)縮小范圍。我的實(shí)際策略是能用條件更新就不用事務(wù)。借還書這個(gè)場(chǎng)景把校驗(yàn)邏輯前置先確認(rèn)用戶資質(zhì)、確認(rèn)書目存在真正需要原子的那一步用條件更新解決最后再補(bǔ)記錄配合一次失敗重試基本能覆蓋 99% 的情況。事務(wù)留給那種“必須嚴(yán)格同時(shí)成功或同時(shí)失敗”的場(chǎng)景比如批量調(diào)撥、庫(kù)存盤點(diǎn)這類低頻高一致性要求的操作。3.4 逾期的處理定時(shí)觸發(fā)器踩坑逾期提醒看起來(lái)簡(jiǎn)單——每天掃一遍未歸還記錄看應(yīng)還日期是不是過(guò)了。做起來(lái)有幾個(gè)坑。第一個(gè)坑是時(shí)區(qū)。數(shù)據(jù)庫(kù)存的是時(shí)間對(duì)象觸發(fā)器配置的也是時(shí)間表達(dá)式兩邊時(shí)區(qū)不一致就會(huì)出現(xiàn)“凌晨該跑的任務(wù)中午才跑”或者“跑兩次”。我的做法是統(tǒng)一用時(shí)間對(duì)象存儲(chǔ)觸發(fā)器按平臺(tái)默認(rèn)時(shí)區(qū)配置業(yè)務(wù)邏輯里做比較時(shí)也用時(shí)間對(duì)象直接比大小絕不在字符串上比。第二個(gè)坑是單次掃描量。觸發(fā)器每次執(zhí)行都有超時(shí)限制一次拉全表再遍歷幾千條記錄直接超時(shí)。必須分批處理用分頁(yè)游標(biāo)每批處理一百條左右處理完記錄位置下次從斷點(diǎn)繼續(xù)。第三個(gè)坑是重復(fù)推送。任務(wù)重試機(jī)制可能導(dǎo)致同一條逾期記錄被提醒兩次用戶會(huì)覺(jué)得很吵。解決辦法是在loans上記一個(gè)lastNotifiedAt字段推送前判斷距上次推送是否超過(guò) 24 小時(shí)超了才推。// 分批掃描逾期記錄避免單次執(zhí)行超時(shí) let lastId null const pageSize 100 while (true) { const where { status: borrowing, dueAt: db.command.lt(new Date()) } if (lastId) where._id db.command.gt(lastId) const res await db.collection(loans).where(where).orderBy(_id, asc).limit(pageSize).get() if (res.data.length 0) break for (const loan of res.data) { // 逐條判斷是否需要推送提醒 } lastId res.data[res.data.length - 1]._id }4. 數(shù)據(jù)庫(kù)權(quán)限規(guī)則默認(rèn)配置基本等于把數(shù)據(jù)敞開(kāi)這一塊是我見(jiàn)過(guò)翻車最多的地方也是最容易被忽視的地方。很多人建完集合就不管權(quán)限了默認(rèn)配置下要么誰(shuí)都能讀要么連自己都讀不到兩個(gè)極端都很麻煩。4.1 四種權(quán)限模型的真實(shí)含義平臺(tái)提供四檔權(quán)限名字看起來(lái)都挺直觀實(shí)際含義差別很大。我按自己的理解重述一遍重點(diǎn)是“誰(shuí)”和“什么操作”。權(quán)限檔位誰(shuí)能讀誰(shuí)能寫適用集合僅創(chuàng)建者可讀寫只有創(chuàng)建這條記錄的人只有創(chuàng)建者本人個(gè)人筆記、私有配置所有用戶可讀僅創(chuàng)建者可寫所有登錄用戶只有創(chuàng)建者書目、副本這類公開(kāi)數(shù)據(jù)僅管理端可讀寫只有云函數(shù)等服務(wù)端身份只有服務(wù)端借閱流水、操作日志所有用戶可讀可寫所有人所有人幾乎不推薦用于生產(chǎn)看表格就明白了books和copies屬于“所有用戶可讀僅創(chuàng)建者可寫”但這里有個(gè)陷阱——如果這些數(shù)據(jù)是通過(guò)云函數(shù)寫入的創(chuàng)建者反而是云函數(shù)調(diào)用者本身也就是最終用戶。用戶 A 創(chuàng)建的書目用戶 B 就改不了這在多管理員場(chǎng)景下會(huì)出問(wèn)題。所以我的實(shí)際做法是所有寫操作全部走云函數(shù)集合權(quán)限統(tǒng)一設(shè)成“僅管理端可讀寫”。云函數(shù)里用服務(wù)端身份操作數(shù)據(jù)庫(kù)不受權(quán)限規(guī)則限制。前端只負(fù)責(zé)調(diào)函數(shù)不直連集合。這樣權(quán)限模型就只有一套心智負(fù)擔(dān)最小。代價(jià)是什么所有查詢也要走云函數(shù)前端一次列表請(qǐng)求變成一次函數(shù)調(diào)用。這時(shí)候就要注意配額和響應(yīng)速度能用一次函數(shù)返回的絕不拆成三次。4.2 openid 的傳遞鏈路和常見(jiàn)偽造誤區(qū)用戶身份標(biāo)識(shí)是權(quán)限體系的地基。在小程序端調(diào)用云函數(shù)時(shí)云函數(shù)可以從上下文里拿到調(diào)用者的身份這個(gè)是平臺(tái)保證的前端偽造不了。// 云函數(shù)內(nèi)獲取調(diào)用者身份 const wxContext cloud.getWXContext() const openid wxContext.OPENID關(guān)鍵在于永遠(yuǎn)不要在云函數(shù)入?yún)⒗锝邮涨岸藗鱽?lái)的用戶標(biāo)識(shí)。我見(jiàn)過(guò)這樣的寫法前端傳一個(gè)userId過(guò)來(lái)云函數(shù)直接拿去查記錄。這等于把身份驗(yàn)證交給了客戶端改個(gè)參數(shù)就能看別人的借閱記錄。正確的鏈路是前端只傳業(yè)務(wù)參數(shù)副本編號(hào)、操作類型云函數(shù)自己從上下文取身份用這個(gè)身份去查數(shù)據(jù)。如果確實(shí)需要處理“管理員幫別人操作”的場(chǎng)景就額外查一次角色表確認(rèn)當(dāng)前身份是管理員再做授權(quán)判斷。判斷管理員身份也要注意不要在云函數(shù)入?yún)⒗飩饕粋€(gè)isAdmin: true就信了必須查數(shù)據(jù)庫(kù)里的角色表。角色表本身也要設(shè)成只有服務(wù)端可讀否則前端能直接改自己的角色。4.3 一個(gè)越權(quán)讀用戶信息的真實(shí)案例說(shuō)個(gè)我實(shí)際遇到的情況。有個(gè)版本的“我的借閱”頁(yè)面為了讓列表顯示快一點(diǎn)前端直接查loans集合權(quán)限設(shè)成“所有用戶可讀”。功能上跑得很順直到有一次測(cè)試隨手用另一個(gè)賬號(hào)登錄頁(yè)面照樣能把別人的借閱記錄翻出來(lái)因?yàn)椴樵儣l件里只寫了按時(shí)間排序沒(méi)寫按身份過(guò)濾。問(wèn)題出在哪權(quán)限規(guī)則管的是“能不能讀這個(gè)集合”不管“讀的時(shí)候該不該過(guò)濾”。所有用戶可讀意味著任何人可以對(duì)整個(gè)集合做查詢雖然平臺(tái)會(huì)限制單次返回條數(shù)但翻幾頁(yè)就能把全量數(shù)據(jù)爬下來(lái)。修復(fù)方案很直接把loans權(quán)限改成僅管理端可讀寫前端不再直連改成調(diào)用一個(gè)getMyLoans云函數(shù)函數(shù)內(nèi)部強(qiáng)制用上下文里的身份做過(guò)濾條件。這個(gè)改動(dòng)讓列表接口多了一層調(diào)用但安全性提升是決定性的。我在這個(gè)坑之后定了個(gè)規(guī)矩凡是帶用戶身份字段的集合權(quán)限一律不開(kāi)放給客戶端直讀。書目、分類這類公共數(shù)據(jù)可以放開(kāi)讀涉及“誰(shuí)借了什么”的全部收到云函數(shù)里。這條規(guī)矩后來(lái)在好幾個(gè)項(xiàng)目里都救了場(chǎng)。5. 前端體驗(yàn)從“能跑”到“能用”之間隔著很多細(xì)節(jié)功能跑通只是及格線真正讓用戶愿意用的是那些看起來(lái)不起眼的小處理。圖書借閱小程序的用戶群體里學(xué)生和普通讀者占多數(shù)容忍度不高卡一下、錯(cuò)一次可能就不用了。5.1 掃碼借書的識(shí)別失敗率掃碼借書是最自然的使用方式但實(shí)際識(shí)別率受很多因素影響條碼磨損、貼紙反光、光線不足、鏡頭對(duì)焦慢。如果你的流程是“掃到碼直接借出”那識(shí)別錯(cuò)了就是借錯(cuò)書非常麻煩。我現(xiàn)在的流程改成兩步掃碼后先拿到條碼內(nèi)容立刻查詢副本信息并展示確認(rèn)卡片書名、作者、封面、存放位置用戶點(diǎn)確認(rèn)才真正發(fā)起借閱。多一次點(diǎn)擊少一堆糾紛。還有幾個(gè)實(shí)操細(xì)節(jié)值得說(shuō)。一是掃碼時(shí)手動(dòng)設(shè)置掃描區(qū)域和類型限定只識(shí)別條形碼避免誤識(shí)別二維碼內(nèi)容。二是加一個(gè)手輸條碼的兜底入口條碼破損時(shí)用戶還能輸入數(shù)字。三是識(shí)別失敗時(shí)不要只彈“識(shí)別失敗”要提示可能的原因和替代方案比如“條碼模糊可以手動(dòng)輸入書背面的數(shù)字編號(hào)”。5.2 分頁(yè)與20條上限這個(gè)問(wèn)題幾乎每個(gè)新手都會(huì)撞。小程序端直接查集合單次最多返回有限條數(shù)翻頁(yè)必須手動(dòng)處理。常見(jiàn)錯(cuò)誤是一次查完然后前端切片看起來(lái)能用其實(shí)第二頁(yè)開(kāi)始就是空的因?yàn)閴焊鶝](méi)請(qǐng)求到。正確的分頁(yè)邏輯有三個(gè)參數(shù)頁(yè)碼、每頁(yè)條數(shù)、是否還有更多。判斷“是否還有更多”最簡(jiǎn)單的方式是請(qǐng)求時(shí)多要一條返回?cái)?shù)量等于預(yù)期加一就說(shuō)明還有下一頁(yè)。// 分頁(yè)查詢多取一條用于判斷是否還有更多 const pageSize 10 const res await db.collection(books) .orderBy(createdAt, desc) .skip(pageIndex * pageSize) .limit(pageSize 1) .get() const hasMore res.data.length pageSize const list hasMore ? res.data.slice(0, pageSize) : res.dataskip在數(shù)據(jù)量大的時(shí)候會(huì)變慢因?yàn)閿?shù)據(jù)庫(kù)要跳過(guò)前面所有記錄。數(shù)據(jù)超過(guò)幾千條時(shí)改成用上一頁(yè)最后一條記錄的排序字段值做游標(biāo)性能會(huì)好很多。小規(guī)模數(shù)據(jù)用skip完全夠別為了優(yōu)化而優(yōu)化。5.3 封面圖與云存儲(chǔ)封面圖的處理有一個(gè)很實(shí)際的問(wèn)題圖片大了加載慢圖片多了存儲(chǔ)費(fèi)用上去了。我的處理是上傳時(shí)壓縮展示時(shí)用縮略。上傳環(huán)節(jié)用畫布能力把圖片壓到合適尺寸再上傳一般寬邊控制在 600 像素以內(nèi)封面圖用這個(gè)尺寸足夠了。存儲(chǔ)路徑按書目主鍵分目錄避免所有文件擠在一個(gè)層級(jí)里難管理。數(shù)據(jù)庫(kù)里只存文件標(biāo)識(shí)展示時(shí)通過(guò)臨時(shí)鏈接或者組件直接引用不要把外鏈地址寫死鏈接會(huì)過(guò)期。還有個(gè)小技巧默認(rèn)封面。很多老書掃不出條碼也找不到封面如果列表里全是空白圖觀感很差。準(zhǔn)備一張通用占位圖沒(méi)有封面時(shí)用它同時(shí)在前端用固定寬高比容器包住圖片避免圖片加載前后頁(yè)面跳動(dòng)。5.4 到期提醒的訂閱消息到期提醒是提升歸還率最有效的手段。平臺(tái)的消息能力需要用戶主動(dòng)授權(quán)所以時(shí)機(jī)很重要——最好在借書成功的那一刻就請(qǐng)求授權(quán)因?yàn)檫@時(shí)候用戶正在關(guān)注這本書同意率高等他退出去了再?gòu)椈径紩?huì)被拒。推送內(nèi)容要具體不要只寫“您有書即將到期”。寫清楚書名、應(yīng)還日期、續(xù)借入口用戶一眼就知道要干什么。推送時(shí)間也有講究提前三天的提醒比提前一天的有效得多因?yàn)橛脩粜枰獣r(shí)間安排。技術(shù)上有兩個(gè)注意點(diǎn)。一是模板字段要提前在后臺(tái)配置好字段順序和入?yún)㈨樞虮仨殗?yán)格對(duì)應(yīng)錯(cuò)一位就報(bào)參數(shù)錯(cuò)誤。二是推送失敗要有降級(jí)消息推不出去至少要在小程序內(nèi)留個(gè)紅點(diǎn)或者角標(biāo)讓用戶打開(kāi)時(shí)能看見(jiàn)。6. 上線之后才會(huì)暴露的問(wèn)題與排查路徑開(kāi)發(fā)環(huán)境和真實(shí)環(huán)境完全是兩回事。下面這幾個(gè)問(wèn)題我在本地測(cè)試時(shí)一次都沒(méi)復(fù)現(xiàn)過(guò)全都是上線后用戶反饋才發(fā)現(xiàn)的。6.1 云函數(shù)超時(shí)先分清是冷啟動(dòng)還是邏輯慢用戶反饋“點(diǎn)借閱轉(zhuǎn)圈半天然后失敗”第一反應(yīng)是代碼慢。但實(shí)際情況往往分兩種一種是函數(shù)很久沒(méi)被調(diào)用首次調(diào)用要初始化運(yùn)行環(huán)境這個(gè)耗時(shí)是固定的跟你的代碼沒(méi)關(guān)系另一種是你真的寫了慢查詢。區(qū)分方法很簡(jiǎn)單看日志里的執(zhí)行耗時(shí)。如果失敗請(qǐng)求集中在每天第一次訪問(wèn)而且耗時(shí)明顯高于平均值那就是冷啟動(dòng)。應(yīng)對(duì)辦法是減少函數(shù)體積把不常用的依賴做成按需引入或者給關(guān)鍵函數(shù)配置一個(gè)低頻的預(yù)熱觸發(fā)。如果是邏輯慢多半是查詢沒(méi)有走索引或者函數(shù)里串行調(diào)用了太多次數(shù)據(jù)庫(kù)。我的排查順序是先在日志里找到最慢的那次調(diào)用看它執(zhí)行了幾次查詢?cè)倏疵看尾樵兊暮臅r(shí)。串行改并行通常能帶來(lái)成倍的提升。// 串行寫法三次查詢依次執(zhí)行總耗時(shí)是三段之和 const a await getBook(bookId) const b await getCopies(bookId) const c await getMyLoans(userId) // 并行寫法三段同時(shí)發(fā)出總耗時(shí)取決于最慢的那段 const [a, b, c] await Promise.all([ getBook(bookId), getCopies(bookId), getMyLoans(userId) ])注意并行不是萬(wàn)能的如果后面的查詢依賴前面的結(jié)果就只能串行。別為了并行而并行把有依賴關(guān)系的請(qǐng)求硬拆開(kāi)只會(huì)寫出更亂的代碼。6.2 配額與調(diào)用次數(shù)云開(kāi)發(fā)的資源是按量計(jì)費(fèi)的個(gè)人開(kāi)發(fā)時(shí)的調(diào)用量看著不多上線后用戶一多賬單漲得比你想象的快。我見(jiàn)過(guò)一次事故某個(gè)頁(yè)面的下拉刷新沒(méi)做節(jié)流用戶手一滑連續(xù)觸發(fā)七八次一天下來(lái)的調(diào)用量翻了十倍。幾個(gè)降低消耗的習(xí)慣列表頁(yè)做本地緩存同樣的查詢短時(shí)間內(nèi)不重復(fù)請(qǐng)求下拉刷新加節(jié)流最短間隔設(shè)成一秒圖片用縮略圖不要每次加載原圖定時(shí)任務(wù)的掃描頻率按實(shí)際需要設(shè)別為了“實(shí)時(shí)”每分鐘跑一次一天一次完全夠用。另外要定期看資源用量面板關(guān)注趨勢(shì)比關(guān)注絕對(duì)值更重要。某天調(diào)用量突然翻倍一定是某個(gè)功能被異常觸發(fā)早發(fā)現(xiàn)早處理。6.3 開(kāi)發(fā)者工具正常、真機(jī)異常這類問(wèn)題最耗時(shí)間因?yàn)槟阍诠ぞ呃镌趺袋c(diǎn)都是對(duì)的。常見(jiàn)原因有幾種。一是網(wǎng)絡(luò)環(huán)境差異。工具走的是本機(jī)網(wǎng)絡(luò)真機(jī)走的是移動(dòng)網(wǎng)絡(luò)弱網(wǎng)下請(qǐng)求超時(shí)時(shí)間不夠表現(xiàn)就是偶爾失敗。解決辦法是把超時(shí)時(shí)間調(diào)大關(guān)鍵操作加重試并且給用戶明確的加載狀態(tài)和失敗提示別讓按鈕一直轉(zhuǎn)圈。二是基礎(chǔ)庫(kù)版本差異。用戶的客戶端版本參差不齊某些 API 在低版本上不存在。調(diào)用前先做能力判斷不支持就降級(jí)或者給提示別直接崩。三是緩存殘留。工具里改了代碼立刻生效真機(jī)上可能有舊緩存。測(cè)試新功能時(shí)記得清緩存或者用體驗(yàn)版重新進(jìn)入。排查這類問(wèn)題的順序我一般是這樣先看是不是所有機(jī)型都有還是特定機(jī)型再看是不是首次進(jìn)入有問(wèn)題還是每次都有然后對(duì)比網(wǎng)絡(luò)請(qǐng)求日志看請(qǐng)求到底發(fā)出去了沒(méi)有、返回了什么。三步下來(lái)基本能定位到是環(huán)境問(wèn)題還是代碼問(wèn)題。7. 一個(gè)可以直接抄的目錄結(jié)構(gòu)與上線前自檢清單項(xiàng)目結(jié)構(gòu)混亂是后期維護(hù)痛苦的主要來(lái)源。我現(xiàn)在的習(xí)慣是按“頁(yè)面 - 組件 - 工具 - 云函數(shù)”四層分開(kāi)云函數(shù)按業(yè)務(wù)域命名一個(gè)函數(shù)一個(gè)職責(zé)別把所有邏輯塞到一個(gè)大函數(shù)里。推薦的結(jié)構(gòu)大致是這樣頁(yè)面按功能分包書目、借閱、我的三大塊公共組件抽出來(lái)比如書籍卡片、狀態(tài)標(biāo)簽、空狀態(tài)占位工具層放請(qǐng)求封裝、格式化函數(shù)、常量定義云函數(shù)目錄下每個(gè)函數(shù)獨(dú)立文件夾各自帶依賴配置。上線前我會(huì)過(guò)一遍這份清單每一項(xiàng)都是真實(shí)踩過(guò)的所有集合權(quán)限是否已從默認(rèn)改成明確配置含用戶身份字段的集合是否已禁止客戶端直讀云函數(shù)里是否所有身份都取自運(yùn)行上下文有沒(méi)有殘留從前端接收用戶標(biāo)識(shí)的代碼關(guān)鍵操作是否都用了條件更新有沒(méi)有“先查再改”的裸寫法狀態(tài)枚舉值前后端是否統(tǒng)一有沒(méi)有中英文混用分頁(yè)邏輯是否處理了“還有更多”列表到底部能否正常加載定時(shí)任務(wù)是否做了分批和去重同一用戶會(huì)不會(huì)收到重復(fù)提醒圖片是否壓縮是否有默認(rèn)占位圖加載時(shí)頁(yè)面是否跳動(dòng)慢查詢是否都建了索引索引是否已生效是否有至少一條鏈路能在出問(wèn)題時(shí)快速定位日志里能否查到關(guān)鍵參數(shù)我個(gè)人在實(shí)際操作中的體會(huì)是這套系統(tǒng)真正的門檻不在功能實(shí)現(xiàn)而在“把狀態(tài)管住”。書目、副本、借閱記錄這三張表的關(guān)系理順了權(quán)限收口到云函數(shù)了并發(fā)用條件更新兜住了剩下的都是頁(yè)面上的打磨活。反過(guò)來(lái)如果一開(kāi)始圖省事把狀態(tài)塞成一個(gè)數(shù)量字段或者為了列表快一點(diǎn)把集合權(quán)限放開(kāi)后面補(bǔ)窟窿的時(shí)間會(huì)遠(yuǎn)遠(yuǎn)超過(guò)當(dāng)初省下的那點(diǎn)功夫。上面那些清單項(xiàng)你哪怕只落實(shí)前三條也能避開(kāi)大部分讓人半夜爬起來(lái)查日志的事故。