Auto Counter 會將每次遞增錨定在「經過的時間」上，而不是錨定在瀏覽器剛好觸發的回呼次數上，藉此修正看起來錯誤的結果。標準的瀏覽器計時器並不是節拍器:忙碌的電腦、隱藏的分頁，或暫停中的視窗都可能延遲某一個 tick，若把每次回呼都算成恰好一次遞增，實際經過的時間就會在不知不覺中被低估。Auto Counter 改從按下「開始」的那一刻起維護一個經過時間的錨點，當回呼終於執行時，它會計算實際經過的完整選定區間數，並把這些已完成的遞增一起記錄下來。任何未滿的區間會保留為餘數，留給下一次回呼，因此暫停不會重複計算一個次數，也不會丟掉一個幾乎完成的區間。正是這樣的設計，讓 Auto Counter 在你的工作階段被中斷或被節流時，仍然能還原出看起來正確的總計;同時，在一切正常的情況下，顯示出來的計數也才能保持可預測。
為什麼 Auto Counter 的結果可能看起來不如預期
大多數令人意外的總計並不是 bug。它們是瀏覽器實際執行計時器的機制，以及 Auto Counter 刻意回應該機制後，所呈現出來的樣貌。WHATWG HTML Timers 規範將計時器描述為「已排入佇列的工作」，在頁面處於背景分頁時，可能會被合併、節流或延遲，並說明瀏覽器允許套用的最小延遲，可能遠大於你所要求的值(請參閱 WHATWG HTML Timers)。一個只會在每次回呼時遞增的天真計數器，所產生的數字與實際經過的時間之間，將不會有誠實的對應關係。
下列情況最常讓總計看起來錯誤:
- 背景或隱藏的分頁節流了你的 tick。下一次回呼觸發的時間比預期晚，因此實際上已經過了好幾個完整的區間。Auto Counter 會在這次回呼中一次記錄所有這些區間，看起來就像是突然跳一大步，而不是緩慢地累加。
- 你讓頁面整晚保持開啟。如果分頁處於非作用中的時間異常地長，Auto Counter 會停止該工作階段，而不是重播一長串過去的舊 tick。顯示出來的數字，只會反映停止之前所儲存的部分。
- 一次延遲的回呼跨越了午夜。Auto Counter 會把已完成的區間，歸到它們實際發生當天、以裝置本地時區計算的日曆日;因此橫跨 11:55 pm 到 12:10 am 的工作階段，會正確地拆成兩列日期，而不是被硬塞進同一列。
- 你希望在工作中更改區間。執行中的區間控制項是鎖定的，避免在進行中的變更重新詮釋已流逝的時間。如果你覺得顯示的數字不對，是因為區間不再符合你的流程，誠實的修正方式是先暫停，再以新的數值啟動一個全新的工作階段。
用這個角度逐一檢視每個情況，通常能把「錯誤」的結果，變成一個站得住腳的結果。數字一直都是錨定在真實經過的時間上;它只是把一個天真點按式計數器所隱藏的選擇，暴露出來而已。
如何用 Auto Counter 對帳計數
如果某個總計看起來不對，最快得到一個站得住腳的數字的方式，就是按照這個工具被設計的方式來執行工作階段，然後讓「暫停」幫你完成對帳步驟。請依序進行下列步驟。
- 開啟頁面並輸入一個簡短標籤。簡短標籤能幫助你日後辨識每日歷史紀錄的某一列，但對計數本身而言並非必要。
- 選擇一個介於 1 到 3,600 秒之間的整數區間。挑選一個能描述你自己流程的區間;這個工具並不聲稱任何特定數值比較好、比較安全或比較有效率。工作階段一旦開始，區間控制項就會被鎖定。
- 按下「開始」並保持頁面開啟。每完成一個區間，計數器就會加 1。Auto Counter 會在 counter:auto-counter 這個鍵名下儲存一個起始錨點，並只在這個頁面於瀏覽器中保持開啟時才會計數;關閉或重新載入頁面，就會結束工作階段。
- 讓任何延遲的回呼自然到位。如果分頁曾被節流，下一次回呼會對齊自錨點以來實際經過的完整區間，任何未完成的餘數則保留給下一個 tick。
- 按下「暫停」以進行對帳並停止。「暫停」會在停止工作階段之前，先對齊所有已完成的全區間，因此最後顯示的數字，會是經過時間計算後的結果，而不是回呼原始計數的殘留值。
- 檢視本機的每日歷史紀錄。每個非零的日期都會以反向順序顯示，並附上其自動遞增的總計。請將該總計與你實際讓頁面保持開啟的時間相互比對。
- 只在需要瀏覽器以外的檔案時才匯出。PNG 會產生一張 1080 乘 1350 的分享圖，內容為總計與最近的每日列，不含網址也不含自訂的計數標籤。CSV 則會產生一個單純的「日期」與「自動遞增」檔案，可在試算表中乾淨地開啟。
若想培養更深入的驗算習慣，相關指南 How to Check the Result After Using Auto Counter 會以稍有不同的角度，帶你走過同一套檢視流程。
正確閱讀每日歷史紀錄的方式
每日歷史紀錄是持久保存的紀錄，它是依據裝置本地時區的日曆日、使用 Intl.DateTimeFormat 來分群，而不是依據單一的 UTC 日期。當結果看起來不對時，這個細節很重要。如果你在 11:50 pm 開始一個工作階段、在 12:20 am 結束，你應該會在歷史紀錄中看到兩列日期，而不是被合併成一列。每一列中的已完成區間，都會被歸到它實際發生的本地日期;因此某一日期若少了某個數字，常常可以解釋成它其實落在相鄰的另一列。
| 你的操作 | 每日歷史紀錄會顯示什麼 | 為什麼總計仍然能對得上 |
|---|---|---|
| 讓頁面跨越午夜保持開啟 | 兩列日期，區間依本地日期拆分 | 每個已完成的區間都會對應到適用的本地日期 |
| 分頁被節流了好幾分鐘 | 同一列中出現一次較大的跳動 | 回呼在該次 tick 對齊了 floor(經過時間 / 區間) 的結果 |
| 分頁處於非作用中的時間異常地長 | 工作階段停止;該列不再增加 | 自動停止可避免無限制地重播舊的 tick |
| 關閉或重新載入頁面 | 執行中的工作階段結束;先前的列保留 | 計數器絕不會假裝伺服器程序在別處繼續執行 |
如果某個日期列整個不見了，代表當天並沒有儲存任何已完成的區間，而不是計數失敗。如果儲存空間被停用或已滿，頁面仍會顯示當下的互動，但會明確聲明無法保留歷史紀錄;它不會聲稱存在一個其實並沒有的備份。
何時該信任數字，何時該重新開始
當你及時按下「暫停」、在過程中沒有長時間的非作用中空窗，而且總計與你實際花費的時間相符時，就可以信任顯示出來的數字。對帳邏輯會在「暫停」時執行，因此一次乾淨的「暫停」，就是「計數已是最終值」最明確的訊號。如果總計仍然與你花費的時間對不起來，請回頭逐一檢視上述四個情況，看看是否符合其中之一。
當工作階段因為流程上的理由而明顯錯誤時，請重新開始:你忘了按暫停，導致頁面開啟的時間遠超過你的預期;你發現區間已經不再符合你實際在計時的事項;或者你清除了網站資料，導致先前的本地歷史紀錄遺失。重新啟動一個全新的工作階段，能讓新的工作階段邊界清楚可見，避免舊的錨點在不知不覺中混進新的計數。
一個簡單的算例可以說明，為什麼你看到的數字，就是你站得住腳的數字。假設你設定 60 秒的區間，並讓頁面保持開啟 1,300 秒。計算過程如下:
- Floor(1,300 / 60) = floor(21.666...) = 21 個已完成的區間
- 餘數 = 1,300 − (21 × 60) = 1,300 − 1,260 = 40 秒
Auto Counter 會在「暫停」時記錄 21 次遞增，並把 40 秒的餘數帶入下一次回呼，與之後經過的時間合併。如果分頁曾被節流、第 21 次回呼是在 1,300 秒那一刻才抵達，而不是在第 21 次個別 tick 時抵達，顯示出來的數字仍然是 21，因為錨點從未移動，只是回呼被延遲了。
讓計數誠實可信的限制
有幾道界線並非可有可無的附加功能;它們正是結果值得信賴的原因。
- 頁面必須保持開啟。Auto Counter 刻意不是一個背景服務、鬧鐘、出勤鐘或監控系統。關閉或重新載入頁面，就會結束執行中的工作階段;這個工具絕不會假裝伺服器程序在別處繼續執行。
- 執行期間區間會被鎖定。控制項會在「開始」後凍結，避免工作中的變更重新詮釋已流逝的時間，造成悄悄的重複計算或漏算。
- 長時間非作用中時自動停止。如果分頁處於非作用中的時間異常地長，工具會停止運作，而不是嘗試無限制地重播舊的 tick。你看到的數字，就是已儲存遞增的次數;不會有任何憑空捏造的部分。
- 儲存空間僅限本機。標籤、區間偏好與已儲存的每日計數，僅會依據 WHATWG HTML Web Storage 規範，儲存在這個瀏覽器的 counter:auto-counter 鍵名下。它們不會被傳送到 Lizely、不會同步到其他裝置，也不會與使用者檔案合併。清除網站資料會一併刪除紀錄;換一個瀏覽器則會從空白開始。
- 匯出檔案是在瀏覽器中產生。PNG 與 CSV 都是使用原生的 Blob 與 canvas API 來產生。在匯出流程中，沒有上傳佇列、影像處理器、帳號，也沒有任何外部 API。
實際的重點是:看起來錯誤的 Auto Counter 結果，幾乎都源自以下三種情況之一──長時間非作用中的分頁觸發了自動停止、跨越午夜把計數拆成兩列日期，或是工作階段被留在那裡繼續跑、超過你原本預定的結束時機。請先按下「暫停」，再以這個對應表去閱讀每日歷史紀錄。如果歷史紀錄仍然與你流程應有的結果對不起來，就以真正符合你節奏的區間，重新啟動一個全新的工作階段，並在結束時立即按下「暫停」。
若想進一步了解，請參閱 How to Correct a Chess Clock When the Display Looks Off。