船經過海面時，身後會留下一道航跡。但過不了多久，浪一打，痕跡就散了。

船過水無痕，本來很正常；可是假如我們真的想回頭找到剛剛經過的地方，就不能只靠海面替我們記住。

網站也是一樣。看了好幾張專輯之後，想回頭找剛剛那一張，卻怎麼也想不起名字；剛剛搜尋過的關鍵字，也得再打一次。如果網站什麼都不記，離開之後就像沒發生過。

所以今天要做最近瀏覽和最近搜尋。但「記住」這件事，也帶來另一個問題：什麼應該留下？留下多久？留下來的資料，又能相信多久？

一、哪些東西值得網站幫我記住？

Day 19 做了收藏，今天要做的則是最近瀏覽和最近搜尋。三種功能看起來都是「記住使用者的東西」，性質卻有一些不一樣：

收藏是使用者做的決定，網站有責任好好保存，所以 Day 19 把它存進資料庫，還做了跨裝置同步和 RLS。最近瀏覽和最近搜尋，是網站順手記下的足跡，方便使用者回頭找。資料的重要性，決定了要花多少成本保存它。

當然，最近瀏覽或是搜尋紀錄，也可以實作成可以跨裝置同步的。但在今天的文章中，我們會先以不跨裝置同步來實作。

二、要放在哪裡？

瀏覽器和伺服器都能存資料，常見的位置有四種：

最近瀏覽和最近搜尋，考量到未登入訪客以及比較少情況會跨裝置使用，所以這次選擇存放在 localStorage。也就是說，不需要登入、不需要新增資料表，也不用處理 Day 19 那種登入前後的合併問題。

如果發現自己開發的網站，該紀錄的資料卻消失了，可以詢問 AI 資料儲存的位置，來判斷消失的可能原因。

三、最近瀏覽要記什麼？

最直覺的做法，是把看過的專輯「整份」存起來：名稱、封面、藝人。下次打開，直接顯示。

但專輯資料是有可能會修改的。管理員修正了專輯名稱、換了封面，甚至把重複的專輯刪掉，localStorage 裡那份卻不會跟著變。使用者看到的，就會是一份過期的資料。

所以這次選擇只記 專輯的識別碼：

["armageddon", "new-jeans", "ive-switch"]

就像服務生記得你上次點了哪幾道菜（餐點名稱），而不是把上次的菜留著。這是一筆紀錄，下次要上菜時，還是照廚房現在的做法重新出餐。（餐點做法、原料可能會換，但菜名可能還是一樣）

顯示時，再用目前的專輯資料把內容還原回來。找不到的專輯，代表已經不存在，就略過並從紀錄中移除。

唯一資料來源（Single Source of Truth）

同一份資料，只讓一個地方當正式版本。專輯資料的正式版本在 Supabase 資料庫中；localStorage 只記「看過哪幾張」，不另外保存一份專輯內容。顯示時，以目前取得的專輯資料為準，而不是把 localStorage 裡的東西當成正式資料。

如果兩邊都存，就會有兩份「真相」。若資料不一致，會需要去確認哪一份才是對的，比較麻煩一點。

不過，這樣又出現一個新問題：每次顯示最近瀏覽，都要重新取得專輯資料，不會浪費嗎？

四、儲存和快取，是同一件事嗎？

講到「把資料留下來」，很多人會想到快取（cache）。但留下來的資料，不一定都是快取。

儲存，是因為之後還需要這份資料；快取，是因為不想再花同樣的成本取得一次。

儲存的資料如果不見了，就真的沒了；快取的資料不見了沒關係，再拿一次就好，因為正式版本還在別的地方。

用第一篇的餐廳來比喻：倉庫是儲存，食材丟了就真的沒了；廚房旁的備料台是快取，醬汁倒掉沒關係，再從倉庫拿食材重做一份就好。

所以，存在 localStorage 裡的東西，不一定是快取。要看裡面放的是什麼、為什麼放，例如：

localStorage 只是一個存放的位置。同一個位置，可以放紀錄，也可以放快取。

五、快取：拿過一次，下次還要重來嗎？

快取的做法其實不難：資料拿過一次，就先存一份複本在比較近的地方，下次直接用。

【圖 1｜有快取和沒有快取】

快取可以放在很多地方。越靠近使用者，通常取得越快；但只要存了一份複本，就得決定它能用多久，以及來源更新後怎麼讓它作廢：

瀏覽器記憶體 → 瀏覽器快取 → CDN → 伺服器快取 → 資料庫
（通常最快、最近）                          （最遠，但通常是正式/正確版本）

這是簡化的示意，用來說明複本可以存在不同的地方；不代表每次請求都會一層一層經過，資料會不會過期，也不是由距離決定的。

換成餐廳：

剛剛那幾個名詞，在餐廳裡是這樣的：備料台上有，直接用，就是命中；沒有，跑一趟倉庫，就是沒命中；醬汁放太久不新鮮了，就是過期；每份備料貼上保存期限，就是有效期限；菜單改了配方，舊的醬汁要先倒掉，就是失效。

真正的配方，記在主廚的配方本上（資料庫）。備料台上的醬汁，只是照著配方先做好的一份。配方改了，要以配方本為準。

所以快取最麻煩的，通常不是怎麼存，而是什麼時候它已經不能用了。因此資料的更新週期通常會是快取實作方式的重要判斷依據之一。

5.1 CDN 和伺服器快取，差在哪裡？

兩者都在伺服器那一側，但存的東西不一樣：

CDN 像是把做好的成品，先放在離客人近的地方；伺服器快取則是廚房裡的半成品，菜還是現做，只是省掉一些準備工作。

5.2 瀏覽器裡的四種「記住」

瀏覽器這一側也有好幾種，很容易混在一起：

最容易搞混的是瀏覽器快取和 localStorage。瀏覽器快取是瀏覽器自動做的，程式通常不直接操作，而是由伺服器告訴瀏覽器能存多久；localStorage 則是程式主動寫進去的，而且沒有內建的有效期限。

5.3 公開快取和私人快取

快取還要分清楚：這份複本，可以給誰？

備料台上的醬汁，每位客人的菜都能用；但客人寄放的酒，只能拿給寄酒的那位客人，拿錯人就出事了。

私人資料也可以快取，例如瀏覽器記住自己的收藏。真正不能做的，是把私人資料放進大家共用的快取。

Day 21 後台的回應使用 no-store，代表這份回應不應被儲存下來重複使用。對包含管理資料的頁面來說，這是保守又合理的做法，也避免它被當成可以共用的內容。

六、SSR、ISR 和快取有什麼關係？

Day 20 講了渲染方式，今天講快取，兩者很容易混在一起：

渲染方式決定頁面什麼時候、在哪裡被做出來；快取決定做過的結果，能不能留下來重複使用。

有三句話值得記住：

• SSR 不代表每次都查資料庫：頁面每次都由伺服器產生，但頁面裡用到的資料，可以先快取一份
• 快取不代表頁面一定是靜態的：就算頁面每次現做，資料一樣可以從快取拿
• 從快取的角度，可以把 ISR 理解成：把已經產生的頁面重複使用一段時間，需要時再重新產生

這也回答了 Day 20 留下的一個問題。Day 20 發現，在專案中，因為根 layout 讀了每個人各自的登入狀態，完整頁面不能給所有人共用。但那說的是完整頁面。整頁不能共用快取，不代表其中所有資料都不能快取。 頁面裡的公開資料，仍然可以另外快取。專輯資料是公開的、很少變動，正適合放進公開快取。

一般來說，如果資料不太會變、讀取的次數很多，大家看到的又都一樣 ，就很適合加上快取，可以減少對資料庫的請求 。專輯資料其實就符合這些條件。

不過這次先不實作資料快取。只有 25 張專輯，每次查詢都很快；加了快取，就得開始處理「資料改了多久才看得到」。等資料量或流量真的需要時，再來決定有效期限和失效的方式。

七、實作：最近瀏覽與最近搜尋

7.1 最近瀏覽

最近瀏覽分成兩個階段：記錄和顯示。

階段一：記錄看過哪一張

【圖 2｜記錄最近瀏覽】

1. 使用者打開一張專輯，不管是完整詳情頁還是側邊欄
2. 瀏覽器從 localStorage 讀出目前的紀錄
3. 把這張專輯的識別碼放到最前面；如果原本就在清單裡，先移除舊的那筆；超過 10 筆就刪掉最舊的
4. 寫回 localStorage

這一段只動到識別碼，不需要問伺服器，也不需要登入。

階段二：在首頁顯示

localStorage 只記得看過哪幾張，名稱和封面不在裡面。所以首頁要分兩段：先由伺服器載入首頁本身，再由瀏覽器拿識別碼，直接向 Supabase 取得專輯資料。

【圖 3｜在首頁顯示最近瀏覽】

1. 載入首頁：伺服器照常產生首頁，最近瀏覽那一塊先放固定尺寸的佔位
2. 讀出紀錄：首頁到了瀏覽器之後，才讀 localStorage，因為伺服器讀不到它
3. 取得專輯資料：瀏覽器用公開金鑰直接呼叫 Supabase 的 Data API，只查卡片需要的摘要欄位，例如名稱、藝人、封面、發行日期和版本格式，不拿款式和內容物
4. 顯示：依照紀錄原本的順序，把佔位換成卡片；查不到的專輯略過，並從紀錄中移除

這裡沒有另外寫一支 API。專輯本來就是公開資料（Day 15），瀏覽器用公開金鑰查詢，由 RLS 決定只能讀、不能改；公開金鑰可以出現在瀏覽器裡，secret key 則絕對不行。這也是 Day 19 收藏用過的做法。

未來如果流量大了，我就會考慮替專輯資料做快取，如此一來不用每一次找一張專輯的詳情資料都要去資料庫撈一次，而是可以直接從快取取得。

這也是 Day 20 的延續：一個頁面不需要為了最近瀏覽，整頁改成在瀏覽器渲染。 伺服器讀不到 localStorage，所以只有讀取紀錄的那一塊，交給瀏覽器處理。

伺服器產生的畫面，和瀏覽器第一次顯示的畫面，都先放同樣尺寸的佔位；讀完紀錄後再換成內容。這樣伺服器和瀏覽器的第一個畫面會一致，也能減少載入時的版面跳動。

【圖４｜點擊幾張專輯後，顯示最近瀏覽（登入狀態）】

【圖５｜登出後，最近瀏覽仍然存在】

【圖６｜清除後，最近瀏覽紀錄消失】

7.2 最近搜尋

最近搜尋用的是很類似做法，只是規則不同。最需要決定的是：什麼時候才算「搜尋過」？

如果每打一個字就記錄，紀錄會變成 a、ae、aes、aesp、aespa。專案中的搜尋，在 Day 20 已經改成要案下Enter 或是點擊搜尋按鈕才會送出才查詢，所以最近搜尋也可以跟著同一個時機：按 Enter 或搜尋按鈕送出時才記錄。

搜尋紀錄存的是使用者自己打的字，共用電腦時，下一個人點開搜尋框就看得到。所以清除按鈕在這裡特別重要。

【圖７｜最近搜尋紀錄（登入狀態）】

【圖８｜最近搜尋紀錄（登出）】

驗收

「專輯改名後」這一列很重要，它證明只存識別碼的設計真的有效：使用者看到的是目前取得的專輯資料，不是 localStorage 裡的舊複本。

換個領域：網站都在記住什麼？

同樣是「最近」，影音平台的繼續觀看通常會跨裝置同步，因為它對使用者更重要。這又回到第一節：資料的重要性，決定了要花多少成本保存它。

結語與明日預告

今天做的只是最近瀏覽和最近搜尋，但真正學到的是：不是每一份資料都要永久存進資料庫，也不是每一次畫面出現，都必然要重新向資料來源取得。要不要加入快取，要看資料量、更新頻率和查詢成本；這次資料很少，所以選擇每次都用識別碼取得目前的資料，先不增加快取和失效的機制。

有些資料是使用者的紀錄，有些是暫存，有些是快取。差別不在放在哪裡，而在為什麼要存，以及可以相信它多久 。航跡終究會散。重要的不是全部留下，而是知道哪些值得記住，以及可以相信它多久，根據情況決定儲存資料的方式。

第三幕從一張資料表開始。到今天，網站已經能存資料、驗證輸入、辨認身分、分配權限，也知道哪些資料該記住、哪些該重新拿。第三幕到這邊就先告一個段落了，到目前為止，這個網站都還只在我的電腦上。開發、測試、正式的資料，也都放在同一個資料庫裡。

明天，我們將把它部署到網路上，讓他並不只能在我的電腦中開啟。

我們明天見。