後端說「只能這樣設計」你就沉默了？前端補上資料庫這一課的理由

2026 年 9 月 28 日，掘金上出現一篇短文「為什麼前端應該主動去學資料庫？」，作者 ErpanOmer 描繪了一個工程圈極為常見的畫面：React 寫得很熟、元件抽象能力很強的工程師，一到 API 聯調就安靜下來。後端說這個介面只能這樣設計，他沉默；說這個欄位加不了，他沉默；說分頁只能用 offset，他還是沉默。原因不是脾氣好，是他根本無法判斷對方講的到底對不對。這篇不到幾百字的文章會引起共鳴，正是因為它戳中了前後端協作裡最不對稱的一塊：資料庫知識。

你以為的 API 問題，其實是查詢問題

文中舉的場景很多前端都遇過。商品列表頁要支援按價格、銷量、上架時間排序，加上分類篩選和關鍵字搜尋。測試環境一切正常，上線後商品表長到五十萬筆，使用者回報按銷量排序要轉八秒的圈。

不懂資料庫的工程師，這時候只能把「技術限制，做不了」這句話原封不動轉達給產品經理。但作者點出，這八秒延遲的大概率原因是排序欄位上沒有索引。沒有索引的排序，資料庫必須把五十萬筆記錄全部掃過一遍，在記憶體裡排完序，再丟掉前面的，只取第二十一到第四十筆。加一條覆蓋分類與銷量欄位的複合索引，同樣的查詢可能從八秒降到五十毫秒。

用日常的比喻：這就像一本沒有目錄、也沒按筆畫排的電話簿，你要找「陳」姓用戶，只能從第一頁翻到最後一頁。索引就是那個目錄。你不需要會親自調校查詢計畫，但你要知道「排序慢通常等於索引缺」，這一個認知就足以讓你在對話裡從聽命者變成協作者。

看起來自然的互動設計，可能正在榨乾後端

文章接著把矛頭指向前端自己：很多看起來天經地義的 UI 互動，如果不懂查詢成本，等於是親手把後端推進坑裡。

第一個是無限滾動的分頁陷阱。前端的視角裡，offset 從 0 變成 980 只是參數加了大了一點；但在資料庫層面，OFFSET 980 的意思是先把前 980 筆全部掃出來、全部丟掉，再取 20 筆回傳。使用者滾得越深，資料庫做的無用功越多。替代方案是遊標分頁：每次帶著上一頁最後一筆的 ID 去取下一批，無論滾到第幾頁，查詢成本都維持恆定。作者特別強調，這個優化不是後端單方面能完成的，請求參數與前端狀態管理都要跟著改，它是一個需要前端先開口的共同決策。

第二個是 N+1 查詢。產品經理說商品卡片要顯示賣家頭像和店名，前端覺得理所當然，但後端若實作不慎，就變成先查二十個商品、再逐個查賣家資訊，請求數量隨列表長度成倍膨脹。這類問題的種子，往往是在前端畫面確定那一刻就埋下的。

工具趨勢正在拆掉那道牆

文章的最後一段論證最有時代感。作者列舉 Next.js 的 Server Actions、Cloudflare D1、Supabase、Drizzle ORM，認為這些技術正在拆掉前端與資料庫之間的最後一道牆。這與我們先前討論過的前端轉進 AI 應用開發的路徑分析指向同一個方向：界線正在移動，站在原地畫分「前端的事」與「後端的事」，風險越來越高。

值得對照的是徵才端的變化。快手秋招把前端與後端整併成「任意方向均可」的全端崗、由後端面試官主考的現象，我們在前端崗位消失機制的分析中談過。當職缺定義先鬆動、面試權力隨之移轉，資料庫這類「隔壁的知識」就從加分項變成保底項。

把這篇短文讀完，能帶走的判斷其實很具體：不必去啃完整的資料庫管理師課程，但索引怎麼運作、offset 與遊標分頁的成本差異、N+1 查詢為何發生，這三件事值得列進下一季的學習清單。下次後端再說「這個介面只能這樣設計」時，你至少能問出第二個問題。

（本文由沈安撰寫）