1個后端新手3天踩了7個坑：分頁和鑒權到底怎么搞

1471行代碼，3個功能，0次崩潰——這是后端新人Day 3的真實戰績。但數字背后藏著更細的東西：分頁怎么切才不會漏數據？JWT放Header還是Cookie？這些"小決策"在真實業務里全是雷。

原作者的日更記錄像一份帶血的踩坑筆記。每天1%的改進口號聽著輕松，落地時全是選擇題。

分頁：從"一把梭"到"切香腸"

最開始的API直接返回全表數據。本地測試時百來條記錄跑得飛快，作者沒覺得有問題。

直到他意識到生產環境可能存著幾萬條任務記錄。前端一次性渲染會卡死，后端內存也可能爆掉。

分頁的本質不是技術炫技，是給前后端都設一道流量閘門。

他改成了按頁獲取。但這里有個隱形坑：如果排序字段不唯一，翻頁時可能出現重復或遺漏。原文沒提他用什么排序，估計是默認ID——這在小項目里夠用，業務復雜后得加聯合索引。

另一個細節是頁碼從0還是從1開始。Spring Data JPA默認0起算，但前端同事可能習慣1起算。這種"約定沖突"在聯調時才會爆炸。

校驗：讓API學會說"不"

之前的接口來者不拒。缺少標題？可以。描述為空？也行。數據庫里攢了一堆臟數據，后期清洗成本比前期校驗高十倍。

作者加了請求校驗。必填字段缺失時直接打回，錯誤信息返回給前端。

這里有個產品思維：校驗規則該多嚴格？太松數據爛掉，太嚴用戶體驗差。他選擇了"硬阻斷"模式——必填項缺一不可。這對內部工具型API是合理選擇，To C場景可能得給默認值或草稿態。

原文沒寫用的什么校驗框架。Spring Boot生態里Hibernate Validator最常用，注解式開發省不少樣板代碼。

JWT：把" session 存服務器"扔進歷史垃圾桶

Day 3最重的改動是接入Spring Security + JWT。

傳統session模式里，用戶登錄后服務器存一份會話狀態，每次請求帶著cookie來查庫。用戶量上千時內存吃緊，多實例部署還得搞共享session，架構瞬間復雜。

JWT的思路很粗暴：服務器不存狀態，把用戶信息加密成token扔給客戶端，每次請求帶回來驗簽就行。

作者實現了這套流程：登錄接口發token，后續請求帶Authorization頭部，服務端驗通過放行，驗不過踢掉。

但他沒提幾個關鍵細節：token有效期設多長？刷新機制怎么做？被盜用了怎么吊銷？這些在真實生產環境全是必答題。日更記錄停在"能跑通"，但距離"能上線"還有段距離。

另一個觀察：他把認證路由和任務路由做了區分。登錄注冊公開，增刪改查要鑒權。這是最基礎的RBAC（基于角色的訪問控制）雛形，但原文沒提角色劃分——估計目前只有"登錄/未登錄"兩種狀態。

3天積累 vs 真實業務的距離

作者的進度條很清晰：Day 1搭架子，Day 2寫CRUD，Day 3加安全和性能。每個功能都是"從能用到夠用"的跨越。

但后端開發的殘酷在于，功能實現只是20%，剩下80%是邊界情況。分頁時數據庫并發寫入怎么辦？JWT密鑰怎么輪換？高并發下驗簽性能瓶頸在哪？

這些他沒遇到，所以沒寫。但讀者里若有正在接生產系統的，應該能自動補全這份清單。

有個細節值得玩味：他在文末提到"Templates let you quickly answer FAQs"，這句話突兀地混在技術總結里。查了下是某協作工具的模板功能說明，疑似復制粘貼時的殘留。日更的壓力下，這種"小穿幫"反而讓記錄更真實。

作者說每天改進1%。按這個節奏，第10天該上緩存，第30天該壓測，第100天該考慮分庫分表。但大多數自學者的曲線是：前兩周陡峭上升，第三周碰到分布式事務或性能調優，然后卡在平臺期。

他會走哪條路？取決于Day 4到Day 7能不能保持這個更新頻率，以及——更重要的是——有沒有一個真實項目把他逼到必須解決某個具體問題的墻角。

你現在回頭看自己第一個"能跑通"的后端項目，最慶幸當時做了哪個小決策，最后悔漏了哪塊？