先檢查下游是否還有可用文件
網路請求完成，不表示有新的本文可交給解析器。市場調查工作若把每一次請求結束都當成新文件，可能讓條件請求的空本文覆寫正確快照。驗收應先問：這個請求情境所對應的完整本機副本是否仍可使用？以下流程適用於獲授權的監測與網站測試。
GET以If-None-Match傳送ETag後，可能收到沒有文件本文的304。這項比較允許弱驗證器，所以不代表位元組完全相同。HTTP語意依據RFC 9110；本文提出的是應用層測試流程，並未實測所有代理路由的相容性或節省幅度。
步驟一：先建立副本識別鍵，再保存驗證器
使用自己管理的測試端點，備妥版本已知且不含敏感資料的小型樣本。列出最終URL、選定市場、請求語言、授權身分分區，以及其他會改變回傳表示的設定。納入Vary指定維度及業務規格的變體條件。首輪保持傳輸與內容編碼設定一致，方便定位差異。
將完整本文、原樣收到的驗證器、取得時間、本機完整性檢查與請求情境保存為同一筆記錄。相同URL若依地區或帳號提供不同內容，僅用URL作快取鍵就會混用。診斷證據使用內部身分分區編號，避免寫入憑證或原始Cookie。
步驟二：走完三種受控轉換
未修改樣本：先用一般GET取得版本A，再於相同情境送出A的驗證器。端點若回傳304，沿用A並記下一次驗證，不把空的網路本文送入解析器。解析結果應與原始樣本相符。
更新樣本：在自有端點將內容改成版本B，仍帶A的驗證器請求。確認回傳資料真的包含B後，才一併更新本文與驗證器。未修改內容卻收到完整200也要記錄，因為端點不一定支援條件回應。
遺失副本：在測試環境刪除A的本文，留下測試中繼資料。用戶端應在送出驗證器前發現副本不可用。若請求已送出，而304抵達前本文遭刪除，將結果標為尚未解決，移除失效條件，再做一次有次數上限的一般GET。不可把沒有本文判定為沒有業務資料。
步驟三：將市場與語言拆成各自的測試格
每個獲准的市場及語言組合都建立自己的記錄，從一般取得開始，不沿用別格的驗證器。按網站規格核對樣本市場代碼、在地化標籤或預期幣別，之後在各格內重新驗證，與各自基準比較。
出口更換未必讓內容改變；同一出口也不保證內容相同。把指定市場、實際觀察的出口及回傳內容變體分開記錄。如果兩格意外指向同一快取記錄，先核對用戶端識別鍵與來源站的變體約定，再調查住宅路由。
步驟四：區分復原失敗與傳輸效益
304若連到錯誤市場或身分副本，立即停止沿用，修正識別鍵後重建該格。沒有預期驗證器就回到一般取得。登入頁、同意頁或錯誤頁不能只因200狀態就成為有效樣本。逾時屬於失敗的重新驗證，不應推進最近成功驗證時間。
分別計算請求次數、驗證後沿用、完整文件替換、缺副本復原及實際傳輸位元組。比較相同期間和工作量，維持一致的併發與重試上限。本文傳輸量降低，不能直接宣稱帳單會下降某個比例；需核對帳戶用量與適用方案。
何時將98IP納入測試
驗收需要選定住宅市場路由時，可查看98IP動態住宅IP產品頁，依帳戶實際可用參數設定，並先核對觀察到的路由。條件回應取決於端點與用戶端；代理產品不會替來源站建立驗證器，也不會修補本機快取的識別錯誤。
若新收到的文件疑似截斷，可接著使用代理回應完整性檢查。它處理的是副本可用性；本篇則進一步決定現有副本是否適合這次請求情境。
FAQ及發布前檢查
能將本機雜湊值當作ETag嗎？雜湊值可供本機損壞檢查，送出的驗證器則應是端點為該表示提供的值。自己產生的值不代表伺服器認得這份文件。
304是否代表取得新資料？應新增驗證觀察並保留原資料版本。報表需分開列出初次取得與最近成功驗證時間，避免將驗證時間誤當內容產生時間。
上線前確認：未變、更改、缺副本三例均驗收；市場及身分分區互相隔離；本文與中繼資料一起更新；復原次數受限；業務欄位有效；證據已去識別化；節省主張有實際用量支持。
僅對自有或明確授權端點進行測試，遵守驗證、頻率、隱私及網站快取規範。不得跨使用者共用登入內容，亦不得以IP輪替規避拒絕。