Priya——你上週問我，你正在建構的降價提醒工具是不是應該「保險起見」每分鐘就輪詢一次商品頁面。在你真的把這個做進去之前，讓我完整走一遍整件事，因為輪詢間隔其實是這裡最小的決定，先把整體架構弄對，能替你在正式上架前省下一兩輪審查。
先從提示本身說起。你告訴我「一個能監看這個頁面、在降價時通知我的擴充功能」，這是個不錯的想法，但還不算是規格——建構器需要知道什麼時候要動作，而不只是要做什麼。你的監看器是三種觸發形式中的第三種，就算你用不到另外兩種，了解它們也是值得的，因為觸發形式決定了權限，而權限又決定了你的審核時程。
- 點擊執行成本最低：一個彈出視窗，在有人按下工具列圖示時，針對目前頁面執行一次——就像「把這個頁面上的所有價格抓進一份清單」這類需求。
- 常駐內容腳本會依你指定的網址模式自動執行——適合像是「在某個網域下的每個頁面上標示出競爭對手的名稱」這類需求，但你必須明確指定模式，因為「我們的內部網站」這種說法，被猜出來的範圍往往會比你原本想要的更窄。
- 你的情況屬於第三種：一個背景監看工具，不論分頁是否開啟都會維持狀態，在 MV3 底下的 Service Worker 上運作，變化發生時在圖示上顯示徽章。
這正是唯一一種建構器應該主動反問你後續問題的觸發形態，而它也確實會這麼做——因為輪詢頻率的數字是真正的取捨，不是走個過場。
這就帶回你「每分鐘一次」的直覺。前陣子我幾乎收到過跟你一模一樣的需求——監看頁面、價格變動時在圖示上顯示徽章——第一版每 60 秒輪詢一次。單人本機測試時運作良好。但一旦乘上實際安裝這個工具的人數，你就是在無故不斷轟炸別人的商品頁面，因為一般零售商品頁面的價格一天頂多變動幾次。在提示詞裡告訴建構器「每 30 分鐘檢查一次」。這不是妥協，而是更誠實的做法——沒有人需要瀏覽器擴充功能提供不到一分鐘就更新的提醒，等到不用向審查員解釋為什麼你的擴充功能一天要回傳 1,440 次時，你會感謝自己這麼做。
你不用操心的部分
你提到對 manifest 有點緊張——別擔心，這其實是你真的不需要碰的部分。兩大商店現在都要求 Manifest V3；MV2 已不再被接受用於新上架項目，Chrome 也正在積極淘汰仍在線上的 MV2 擴充功能。MV3 下最主要的變化是，你的背景邏輯以 service worker 的形式執行，而不是持續運作的背景頁面——它會因事件而啟動，瀏覽器可能在事件之間將它終止，狀態必須透過 chrome.storage 來處理，而不是單純存在變數裡。這正是建構器預設就會正確處理的那種生命週期細節。除非你特意去找，否則你根本不會看到 manifest 檔案。
你真正該花心思關注的是權限，因為這才是決定你審核速度的關鍵，而不是程式碼本身。你的監看器需要 alarms 來進行輪詢，可能還需要 storage 來記住上一次的價格——它不需要 tabs 或 <all_urls>，如果你因為「以後可能會擴充到任何網站」而要求「未來能在任何網站上運作」的能力，建構器就會照這個範圍去建構，你最後會為一個尚不存在的功能請求廣泛的主機存取權限。這是安裝對話框裡最嚇人的一行——「讀取並變更你造訪的每個網站上的資料」——也正是把自動審核升級為人工審核的元凶。先描述它現在做什麼，之後真的需要再擴大範圍。
在你宣告完工之前，還有兩件事值得花三十秒關注一下：彈出視窗介面和圖示。
- 彈出視窗介面——一個預設的選項頁面、光禿禿的核取方塊、沒有任何層次結構，這確實是造成一星負評的常見原因，而且跟擴充功能本身能不能正常運作完全無關。你的功能雖然只有幾個設定項（網址、也許還有間隔時間），但看起來仍應該像是一個完整的產品，而不是一份表單堆砌。
- 圖示——務必檢查圖示在 Chrome 的所有四種尺寸下的呈現效果（16、32、48、128 像素，Firefox 則稍有不同的規格矩陣），因為在 128 像素下清晰銳利的標誌，縮到 16 像素時很可能會糊成一團——而 16 像素恰恰是它在擁擠的工具列裡大部分時間所處的尺寸。
在你動手處理任一商店之前
要實際測試，不只是在聊天預覽裡看看。建構後你得到的是一個真正可載入的擴充功能，所以前往 chrome://extensions，開啟開發人員模式，選擇「載入未封裝項目」，然後在你真正在意的實際商品頁面上執行——而不是模擬版本。我會特別手動檢查兩件事：安裝權限提示的內容是否符合你所要求的功能，以及當內容腳本遇到它未針對設計的頁面時會發生什麼事——是靜默失敗，還是拋出可見的錯誤？這兩項檢查各花不到一分鐘，卻都是那種一看就明顯、不看就完全發現不了的錯誤。
等你真的準備好要上架時，你會透過自己在兩家商店的開發者帳戶進行——這個上架資訊由你自己擁有，這個平台不會替你管理它。而且我想先提醒你，兩家商店的流程完全不對等，我不希望你以為兩者一樣，因而排定了不切實際的上架日期。
| 商店 | 提交流程 |
|---|---|
| Chrome | 自動填寫上架資訊——標題、說明、分類，以及審查真正會讀的權限說明文字，這些都是根據程式碼實際的行為產生，而不是另外自己打的，這點很重要，因為權限說明與實際不符本身就是常見的拒絕上架原因。 |
| Firefox | 基本上不太需要人工介入；Mozilla 的審查流程較輕量，提交後大多能直接通過。 |
建構完成後產生的上架資源套件，也會產生從你的擴充功能實際運作中擷取的截圖（不是示意圖）、上架文案，以及對照真實程式碼檢查過的隱私實務問卷答案，而不是憑記憶填寫的。對於一個會與外部頁面互動的功能來說，最後這一點的重要性超乎想像：Chrome 的隱私問卷會問一些簡單的是非題，關於資料處理方式，如果你的監看工具明明在輪詢並儲存價格資料，卻在「這個功能是否收集資料」這一題回答「否」，這種小小的不誠實會在上架後被下架，而不僅僅是上架前被拒絕。讓答案對照實際程式碼檢查，能自動替你補上這個漏洞。
| 商店 | 典型審查時間 |
|---|---|
| Firefox | 數小時，有時甚至不到一小時 |
| Chrome | 大約幾天，狀況不好的週別可能接近兩天 |
像你這種背景常駐型的擴充功能，比起單純的點擊執行型，更容易落入速度較慢的人工審查隊列。這一點我們誰都無能為力。請以 Chrome 的時程來安排你的公告時間，而不是 Firefox 的，而且不要把任何宣布安排在你提交審查的同一天。
最後一件事，因為我了解你——你可能已經在想，等這個上線後要加上「跨裝置同步我的追蹤清單」和「追蹤價格歷史紀錄」。這沒問題，但要知道每一項都是新的權限，而新的權限可能意味著比你剛通過的審核更慢的審核。如果你確定要做更大的版本，真的更值得現在就一次提出、承受一次較慢的審核，而不是一個一個慢慢加權限。如果你還不確定，就先發布你現有的版本——一個範圍明確的監看器能快速通過審核，讓你獲得真實使用量，而現階段真實使用量比放在 Chrome 審核佇列裡的一長串功能清單更有價值。你隨時可以之後再要求更多權限；但一旦因為你當下還用不到的東西卡在人工審核裡，這次上線機會就回不來了。
