Strapi Plugin 覆寫陷阱:為什麼你的 Override 沒有生效?

前言:一個看似簡單的需求 需求很單純:讓 Email 驗證信中的連結顯示前端網址(www.example.com),而不是後台網址(api.example.com)。這樣用戶不會看到內部系統架構。 外包商寫了這段程式碼: // ❌ 看起來合理,但完全沒效果 plugin.services.user.sendConfirmationEmail = async function(user) { // 自訂邏輯... } 部署後,Email 中的連結依然指向後台。為什麼? 問題根源:Factory Function 陷阱 翻開 Strapi 原始碼,發現 plugin.services.user 不是一個物件,而是一個 factory function: // Strapi 內部實作(簡化版) plugin.services.user = (context) => { return { sendConfirmationEmail: async (user) => { /* 原始邏輯 */ }, // 其他方法... } } 這意味著什麼? 每次 Strapi 需要 user service 時,它會呼叫這個 factory function 來取得一個新的 service 實例。你直接覆蓋 sendConfirmationEmail 屬性,等於在一個 function 物件上加屬性——factory 被呼叫時根本不會讀取這個屬性。 不這樣理解會怎樣? 你會像外包商一樣,花兩天 debug 卻找不到原因,因為程式碼完全沒有報錯,只是靜靜地被忽略。 解決方案:Factory Wrapper 模式 正確的做法是包裝原本的 factory function: // ✅ Factory Wrapper 模式 const originalUserServiceFactory = plugin.services.user; plugin.services.user = (context) => { // 先取得原始 service 實例 const originalUserService = originalUserServiceFactory(context); return { ...originalUserService, // 保留所有原始方法 // 覆寫特定方法 async sendConfirmationEmail(user) { // 你的自訂邏輯 const confirmationUrl = `${FRONTEND_URL}/verifyEmail`; // ... }, }; }; 為什麼這樣有效? ...

January 15, 2026 · 2 分鐘 · Peter

刪了 52 萬筆資料,為什麼硬碟空間沒變小?

「奇怪,我明明刪了 52 萬筆資料,為什麼資料表還是 207MB?」 這是我今天在清理資料庫時遇到的真實情況。如果你也曾經困惑過這個問題,這篇文章會告訴你背後的原因。 事情是這樣的 專案的 user_notifications 資料表累積了幾十萬筆推播通知記錄,佔用了 207MB 空間。為了控制資料庫大小,我寫了一個 cron job 來清理超過 7 天的舊資料: // 刪除 7 天前的通知 const sevenDaysAgo = new Date(Date.now() - 7 * 24 * 60 * 60 * 1000); await strapi.db.query('api::user-notification.user-notification').deleteMany({ where: { createdAt: { $lt: sevenDaysAgo.toISOString() } }, }); 執行結果很漂亮: [Cleanup] Successfully deleted 521604 old user notifications 刪除了 521,604 筆!只剩下約 2 萬筆近期資料。 但當我打開 DBeaver 檢查時… 207MB?資料都刪了,空間怎麼沒變? 為什麼會這樣?理解 PostgreSQL 的 MVCC 這不是 bug,而是 PostgreSQL 的設計特性。 DELETE 不是真的刪除 PostgreSQL 使用 MVCC(Multi-Version Concurrency Control) 來處理並發交易。當你執行 DELETE 時,PostgreSQL 不會真的把資料從磁碟上移除,而是: 將該行標記為「已刪除」(稱為 dead tuple) 保留原始資料,直到沒有任何交易需要參照它 新的查詢看不到這些行,但它們仍佔用磁碟空間 為什麼要這樣設計? 效能考量:標記刪除比實際移除資料快非常多 並發安全:其他正在執行的 transaction 可能還需要看到舊版本 ACID 保證:確保 transaction isolation 不處理會怎樣? ...

December 31, 2025 · 3 分鐘 · Peter

一次錯誤部署引發的 PostgreSQL Sequence 災難:為什麼使用者突然無法解鎖動畫?

「老闆,用戶的解鎖記錄全不見了!」「快把舊資料拉出來灌回去!」在緊急狀況下,我沒想太多就照做了。然後,我不小心埋下了一顆定時炸彈… 🔥 第一幕:災難降臨 2025 年 11 月某日,上午 10:30 Slack 突然炸開: 💬 同事:「完蛋了…我剛剛不小心部署到舊的 commit…」 💬 QA:「欸!為什麼使用者的動畫解鎖記錄都不見了?」 💬 使用者:「我昨天才花金幣解鎖的動畫怎麼不見了?」 💬 老闆:「@所有人 立刻確認影響範圍!」 我打開資料庫一看: SELECT COUNT(*) FROM user_unlocked_animations; -- 結果: 0 😱 所有用戶的解鎖記錄全部消失! 原因:同事不小心部署了一個舊的 Strapi commit,那個版本的 database migration 把 user_unlocked_animations 相關的表全部清空了。 ⚡ 第二幕:老闆的緊急命令 💬 老闆:「快!把之前的用戶解鎖記錄拉出來,灌回現在的資料庫!」 我心裡想:「舊資料插回去,新資料又同時在進來…會不會有問題?」 但老闆在等,使用者在抱怨,沒時間多想,先恢復資料再說。 緊急恢復資料 // 從備份拉出資料,直接插入(包含原始的 ID) blablablabla } // ⚠️ 直接指定了 id,但沒想到要更新 sequence... 執行完畢: ✅ 資料恢復完成! QA 測試:「使用者的解鎖記錄都回來了!」 眾人鬆了一口氣。 💣 第三幕:24 小時後,炸彈引爆 隔天下午 💬 客服:「有使用者回報說無法解鎖動畫!!!」 💬 使用者:「我有 3 個金幣,想解鎖動畫,但一直顯示錯誤!金幣被扣了但動畫沒解鎖!」 ...

November 9, 2025 · 5 分鐘 · Peter

Strapi 自訂搜尋功能:讓 Admin 面板支援多欄位搜尋

前言 在開發 Strapi 後台管理系統時,我遇到一個實際的使用者體驗問題:在「已購買課程」列表中,管理員可以用「真實姓名」搜尋到用戶的購課記錄,但用「電話號碼」卻搜尋不到。這個不一致的行為讓管理員感到困惑。 本文將分享如何在 Strapi v5 中實作自訂搜尋邏輯,讓 Admin 面板支援跨關聯的多欄位搜尋。 問題場景 資料結構: purchased-course(已購買課程):關聯到 user user(用戶):包含 email、realName、phoneNumber、username、nickname 等欄位 問題現象: ✅ 搜尋「真實姓名」→ 可以找到對應的購課記錄 ❌ 搜尋「電話號碼」→ 找不到任何結果 為什麼會這樣? 因為 Strapi 預設的搜尋功能只會搜尋當前 Collection 的直接欄位,不會自動搜尋關聯表(relation)的欄位。當我們在 purchased-course 列表搜尋時,Strapi 只會在 purchased-course 本身的欄位中搜尋,而不會去搜尋關聯的 user 資料。 解決方案架構 Strapi 提供了三個層級可以自訂搜尋邏輯: 1. Controller 層(API 端點) 位置: src/api/purchased-course/controllers/purchased-course.ts 用途: 處理前端透過 REST API 的搜尋請求 2. Service 層(業務邏輯) 位置: src/api/purchased-course/services/purchased-course.ts 用途: 封裝可重複使用的業務邏輯 3. Content Manager Plugin Extension(Admin 面板) 位置: src/extensions/content-manager/strapi-server.ts 用途: 最重要! 這是讓 Admin 面板搜尋生效的關鍵 ...

October 27, 2024 · 5 分鐘 · Peter