如何停止 WordPress AutoSave 自動儲存功能？4 個方法幫你快速禁用！

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

停用 WordPress AutoSave 最安全的做法是修改 wp-config.php 把 AUTOSAVE_INTERVAL 調長到 300 秒，同時用 WP_POST_REVISIONS 限制修訂版本數量，而不是完全停用自動儲存。

WordPress 在編輯文章時預設每 60 秒自動儲存一次進度，這就是 AutoSave 功能。出發點是防止瀏覽器當機或斷電導致內容遺失，但長期經營的網站累積大量修訂版本後，資料庫會膨脹、查詢變慢，間接拖慢前台頁面速度。這篇教學會帶你搞懂 AutoSave 和 Revisions 的差異，再根據你的網站狀況選擇最適合的調整方式。建議先確認你用的是 WordPress.org 自架站還是 WordPress.com，以下操作只適用於自架站。

AutoSave 只留一份覆蓋用的暫存，真正讓資料庫膨脹的是 Revisions

WordPress AutoSave 是後台編輯器內建的自動儲存機制，使用 AJAX 在背景運作，不會中斷你的編輯流程。它只為每篇文章保留一份臨時副本，每次觸發就覆蓋上一份，所以對資料庫的影響極小。副本存在 wp_posts 資料表，post_type 標記為 revision。

文章修訂版本（Revisions）則是完全不同的東西。每當你按「更新」或「發佈」，WordPress 就新增一條修訂記錄，改 20 次就多 20 筆，沒有上限。真正讓資料庫膨脹的元兇是 Revisions，不是 AutoSave 那一條記錄。很多人搞混這兩者，停用了 AutoSave 卻沒解決資料庫變大的根本問題。

AutoSave 在 Classic Editor 和 Gutenberg（區塊編輯器）中的行為略有不同。Classic Editor 直接以草稿形式儲存，Gutenberg 則在右側欄位顯示「已自動儲存」提示，並跟最新版本做比對。如果你還在用傳統編輯器，可以參考 Gutenberg 換回 Classic Editor 的教學。

底層機制其實差更多。Classic Editor 走的是傳統 AJAX，把整篇文章內容 POST 到 admin-ajax.php；Gutenberg 從 5.0 起改用 WP REST API 的 /wp/v2/posts/<id>/autosaves 端點，內容是區塊陣列序列化後的字串。這個差異會直接反映在你停用的方式：Classic Editor 時代只要 wp_deregister_script('autosave') 拿掉那支 JS 就好，Gutenberg 因為儲存邏輯內建在 @wordpress/edit-post 套件裡，光 deregister 老腳本不一定擋得住，新版還會透過 wp.data.dispatch('core/editor').autosave() 主動呼叫 REST。實測下來，Gutenberg 環境用 AUTOSAVE_INTERVAL 拉長到 300 秒，比硬停用更不容易留下「儲存按鈕卡住」的怪狀態。

另一個常被忽略的事實：AutoSave 觸發的時候，WordPress 也會順手做一次 heartbeat 心跳檢查（wp-refresh-post-lock），用來維持多人鎖定狀態。如果你只停用 AutoSave 但沒處理 heartbeat，後台仍然會每 15 到 60 秒發一次請求，CPU 佔用的感受其實減不了多少。要徹底降低後台負載，得連 Heartbeat 頻率一起調，這也是為什麼很多人停用後「沒感覺變快」。

為什麼要調整 AutoSave？三個常見原因

資料庫膨脹拖慢查詢速度

一個經營三五年的網站，文章 500 篇，修訂版本可能高達上萬筆，佔掉資料庫將近一半容量。查詢速度下降直接影響 WordPress 網站速度，也讓 快取外掛的效率打折。如果你曾遇過 資料庫連線錯誤，修訂版本累積太多可能就是原因之一。

實際數字可以這樣抓：每一篇修訂版本在 wp_posts 佔一條 row，內容欄位是完整文章 HTML 的副本，再加上對應的 wp_postmeta 紀錄。一篇 3000 字的文章對應的單一修訂版本，含 postmeta 大概會吃掉 30 到 60 KB。改 50 次就是 1.5 到 3 MB，500 篇文章乘起來輕鬆破 1 GB。這還沒算 wp_icl_translations（多語系外掛 WPML）和 wp_yoast_indexable（Yoast SEO）這類會跟著修訂版本長一條記錄的外掛側資料表，實際膨脹倍率常常是純 wp_posts 估算的兩到三倍。

伺服器資源消耗

AutoSave 每 60 秒發一次 AJAX 請求。多人同時編輯、或多個編輯視窗同時開啟時，頻繁的請求會佔用 CPU 和記憶體，在共享主機環境下特別明顯，可能導致 TTFB 等待時間過長。

間接影響 SEO 排名

資料庫變慢，頁面載入速度就跟著下降，而頁面速度是 Google 排名的重要指標。所以調整 AutoSave 的真正好處在於提升前台速度，而不只是後台操作體驗。你也可以先從 啟用 GZIP 壓縮開始，這是見效很快的基本動作。

你到底該不該停用 AutoSave？決策判斷

在動手改設定之前，先判斷你的實際狀況：

• 適合調整或限制的情境：你是網站唯一作者、網站已營運多年累積大量修訂版本、有定期備份習慣、主機資源有限（低階共享主機）、習慣手動按儲存。
• 不建議停用的情境：多位作者同時編輯、經常寫超過 2000 字的長文、網路連線不穩定、對修改程式碼不熟悉。

主機品質也有差。效能好的主機像 Bluehost（WordPress 官方推薦）或 Kinsta（Google Cloud 架構加內建快取），AutoSave 基本上不會造成可感知的效能問題。如果你還在比較各家方案，看 WordPress 虛擬主機推薦比較會有完整的費用與速度分析。

無論選哪種方式，操作前請先用 UpdraftPlus 或主機內建備份功能做一次完整備份。像 SiteGround 就提供每日自動備份，有備份才有退路。

方法一：修改 wp-config.php 調整自動儲存間隔（推薦）

這是最安全也最推薦的做法，不是完全停用，而是把自動儲存的頻率降低，大幅減少資料庫寫入次數。

AUTOSAVE_INTERVAL 是 WordPress 的常數，控制自動儲存間隔時間，單位是秒，預設 60 秒。操作步驟如下：

1. 透過 FTP、SFTP 或主機控制面板連線到網站伺服器（也可用 Filester 檔案管理工具直接在後台操作）
2. 找到網站根目錄的 wp-config.php，用文字編輯器開啟
3. 在 /* That's all, stop editing! Happy publishing. */ 這行之前加入以下程式碼：

define('AUTOSAVE_INTERVAL', 300);

常見的設定值：

程式碼必須加在 require_once ABSPATH . 'wp-settings.php'; 之前才會生效。如果改完出現 500 Internal Server Error，通常是加錯位置或少了一個分號。你也可以搭配 Cloudflare CDN 和 網站速度測試工具來量化整體效能改善。

方法二：透過 functions.php 完全停用 AutoSave

如果你確定要完全停用 AutoSave，在子佈景主題的 functions.php 中修改是最乾淨的做法。為什麼要用子佈景主題？因為直接改主佈景主題的 functions.php，下次佈景主題更新時你的修改就會被覆蓋。如果你還不太熟悉佈景主題，先看 怎麼挑選適合的佈景主題。

1. 進入 WordPress 後台「外觀 → 佈景主題編輯器」
2. 右側選擇你的子佈景主題（Child Theme）
3. 點選 functions.php
4. 在檔案最下方加入以下程式碼：

add_action( 'admin_init', 'disable_autosave' );
function disable_autosave() {
    wp_deregister_script( 'autosave' );
}

wp_deregister_script('autosave') 會從 WordPress 的腳本佇列中移除自動儲存用的 JavaScript，編輯器就不會再發送 AJAX 請求。想重新啟用，移除或註解掉這段程式碼即可。

停用後如果關閉瀏覽器分頁，未儲存的內容就真的會消失。建議搭配 WordPress 安全強化一起做，也確認網站沒有 502 Bad Gateway Error 等問題。

方法三：限制修訂版本數量（WP_POST_REVISIONS）

嚴格來說這不是停用 AutoSave，但它能解決大多數人想停用 AutoSave 的根本原因：資料庫膨脹。限制修訂版本數量往往比停用 AutoSave 更有效。你也可以搭配 ShortPixel 圖片壓縮，從圖片和修訂版本兩個方向同時減少資料庫負擔。

WP_POST_REVISIONS 可接受三種值：

操作步驟：在 wp-config.php 的 /* That's all, stop editing! */ 之前加入：

define('AUTOSAVE_INTERVAL', 300);
define('WP_POST_REVISIONS', 3);

這個組合設定是我個人最推薦的做法：自動儲存間隔拉長到 5 分鐘，修訂版本最多保留 3 份，既保留安全網又能有效控制資料庫大小。搭配定期備份和 網站狀態檢查就夠用了。如果你在找高效能又平價的主機，Hostinger WordPress 主機是值得考慮的選擇；需要更完整的監測，則可以用 WP Umbrella 網站監測工具。

方法四：使用外掛停用或管理自動儲存

不想碰程式碼的話，外掛是最簡單的方式。

Disable Gutenberg Autosave

使用 Gutenberg 區塊編輯器時，這是最直接的解決方案。安裝啟用後自動停用自動儲存，不需額外設定。安裝方式就跟一般 WordPress 外掛一樣，後台搜尋名稱即可。但要注意這個外掛已有一段時間沒有更新，建議先用 InstaWP 測試站確認相容性。

WP Revisions Control

針對修訂版本管理，比直接改 wp-config.php 更靈活，可為不同文章類型分別設定保留數量。

WP-Optimize

綜合型資料庫優化工具，能清理修訂版本、垃圾評論、停用的留言記錄，還支援排程自動清理。適合已累積大量資料需要一次搞定的網站。

如果你同時使用 SiteGround SG Optimizer 或 WP Rocket 等效能外掛，建議把快取設定和修訂版本管理一起考量，避免設定衝突。整體來說，如果需求只是單純停用或管理 AutoSave，方法一到方法三的手動方式反而更乾淨。

如何清理已累積的修訂版本？

停用未來的自動儲存或修訂功能不會清理掉過去的記錄，你需要主動清理。

用 WP-Optimize 外掛清理（推薦新手）

1. 後台「外掛 → 安裝外掛」搜尋「WP-Optimize」，安裝並啟用
2. 進入「WP-Optimize → 資料庫」頁面
3. 勾選「清理文章修訂版本」選項
4. 點選「執行優化」

WP-Optimize 會顯示可清理的筆數和可釋放的空間，也支援排程自動清理。清理後搭配 WP Rocket 和 GZIP 壓縮效果更明顯。使用 A2 Hosting 等高效能主機的網站，優化效果會更顯著。

透過 phpMyAdmin 執行 SQL 指令（進階）

對資料庫操作熟悉的話，可以直接執行 SQL：

DELETE FROM wp_posts WHERE post_type = 'revision';

同時清理關聯的 postmeta：

DELETE FROM wp_postmeta WHERE post_id NOT IN (SELECT ID FROM wp_posts);

執行前確認你的資料表前綴（預設 wp_，有些主機會用不同的前綴）。這個操作不可逆，一定要先備份。清理前後用 GiftofSpeed 網站速度檢測工具各測一次，量化改善效果。

這條 SQL 只清 wp_posts，但修訂版本在 wp_postmeta 還會留下大量孤兒記錄（被刪掉的 post_id 對應的中繼資料）。實務上看過清理完 wp_posts 後資料庫只縮小一半預期，剩下的空間都被 postmeta 孤兒佔走。上面那條 DELETE FROM wp_postmeta WHERE post_id NOT IN (SELECT ID FROM wp_posts) 是常見補法，但它會清掉所有無對應文章的中繼資料，如果你的網站裝過自訂欄位外掛或 WooCommerce，這些資料可能正在用 postmeta 存正常營運資料，貿然全砍會出事。比較安全的做法是先 SELECT 出來抽樣檢查 meta_key，確認沒有重要鍵值再 DELETE。懶得自己寫 SQL 的話，回到上一段用 WP-Optimize 外掛，它會自動處理對應關係，不會誤刪。

實際能清出多少空間，跟網站體質關係很大。一個經營五年、約 500 篇文章的內容站，修訂版本加上對應 postmeta 往往佔掉資料庫一半以上的容量，清理完常見縮小幅度在三到五成；但如果你的網站本來就裝了限制修訂版本的外掛，從頭就沒累積多少，能擠出的空間就很有限。別期待這個動作能把資料庫砍到原本的一成，那是另一種過度期待。

定期維護建議

下一步：三個立即可做的動作

1. 確認你的需求再動手：如果你是唯一作者且網站營運超過兩年，直接用方法一加方法三的組合（AUTOSAVE_INTERVAL 設 300 秒 + WP_POST_REVISIONS 設 3）。多人協作的網站則只調間隔就好，不要完全停用。
2. 操作前先備份：用 UpdraftPlus 或主機內建備份功能做一次完整備份，確認備份檔案可以正常下載。這是最基本的保障。
3. 清理完測一次速度：修改設定和清理修訂版本後，用 網站速度測試工具或 GiftofSpeed 量前後差異。如果改善不明顯，問題可能不在資料庫，而是主機效能或前端資源，可以參考 WordPress 速度優化完整指南。

WordPress AutoSave 常見問題 FAQ

停用 AutoSave 會導致文章遺失嗎？

有可能。停用後如果在編輯時關閉瀏覽器分頁、瀏覽器當機或斷電，未手動儲存的內容就會消失。只要養成每寫一段就按 Ctrl+S（Windows）或 Cmd+S（Mac）的習慣，這個風險可以接受。

AutoSave 和文章修訂版本有什麼差別？

AutoSave 是系統自動儲存，每篇文章只保留一份，不斷覆蓋。Revisions 是每次手動儲存或更新時產生的歷史版本，預設無上限。真正造成資料庫膨脹的是 Revisions，不是 AutoSave。

Gutenberg 的 AutoSave 能完全停用嗎？

Gutenberg 的 AutoSave 行為跟 Classic Editor 不同，可以透過 functions.php 或外掛停用大部分功能，但 Gutenberg 本身在儲存草稿時仍會有一些自動同步行為。使用 Gutenberg 的話，建議只調整 AUTOSAVE_INTERVAL 而非完全停用。

修改 wp-config.php 會影響整個網站嗎？

只要在正確位置加入正確語法就完全安全。加入 AUTOSAVE_INTERVAL 或 WP_POST_REVISIONS 是非常普遍的操作。但加錯位置或打錯語法可能導致網站出錯，所以操作前備份是必要的。

哪一種方法最推薦？

組合使用方法一加方法三：在 wp-config.php 同時設定 AUTOSAVE_INTERVAL 為 300 秒和 WP_POST_REVISIONS 為 3-5 個版本。這樣既保留自動儲存的安全網，又有效控制資料庫大小。如果你剛入門，先從 了解 WordPress.com 和 WordPress.org 的差異開始，確認你用的是可以修改 wp-config.php 的自架站版本。