WordPress 從本地搬家到線上主機：完整教學

相信不少人也在本機把 WordPress 調到完美，首頁、商品頁、聯絡表單全部跑得很順，然後盯著螢幕想：下一步到底怎麼把這個站推上線，讓全世界看得到？這一步卡住的人比你以為的多很多。本機跟線上主機是兩個完全不同的執行環境，把檔案丟上去只是表象，真正會出事的地方藏在 PHP 版本、資料庫連線、網址置換這些細節裡。本機到線上這一段，各種千奇百怪的狀況都不少見，底下也整理出一套能避開大部分地雷的實戰流程。

這篇我要把 WordPress 從本地端搬到線上主機的完整流程拆開來講。我不會只給你一份步驟清單，而是把每一條路線的風險、適合什麼樣的站、搬完之後要做哪些事一次講清楚。完成前置檢查、部署與驗收後，再開放正式流量；所需時間會隨站點大小和主機環境而不同。

快速重點：本機搬到線上需要轉換環境與網址。可選 Duplicator 打包、All-in-One WP Migration 匯出匯入，或手動傳送檔案與資料庫。先備份並確認目標環境、HTTPS 與工具限制；部署後驗收主要功能、清除安裝檔，再檢查公開頁面的搜尋引擎可見性。

先搞清楚：本機跟線上主機，到底是哪裡不一樣？

很多人以為搬家就是把資料夾複製過去。但只複製資料夾可能漏掉資料庫、網址和伺服器設定。本機環境（不管是 Local by Flywheel、MAMP、XAMPP 還是 Laragon）跟線上主機之間，至少有四個層面的落差，需要逐一核對是否影響部署。

換句話說，你搬的不是一個資料夾，而是一整套相依的執行環境。

光是把 wp-content 傳上去並不足以完成搬家。資料庫保存文章、選項與外掛資料；wp-config.php 保存資料庫連線設定，也可能定義網址常數。wp_options 中的 siteurl 和 home 是兩筆選項，另外還要核對文章、選單、自訂欄位及外掛設定中的來源網址。實際資料表前綴也可能不是 wp_。

為什麼要用本機開發，而不是直接在主機上做？

本機適合在不影響訪客的環境中修改和測試，部分工作也能離線進行；依賴第三方 API、付款回呼或遠端素材的功能仍需要網路。受保護的 staging 站同樣能用來演練，且環境可能更接近正式主機。選擇能保留備份、隔離正式交易並驗證部署的方式即可。

如果你還沒開始本機架站，可以參考我們寫的MAMP 本機架 WordPress 完整教學，Mac 跟 Windows 都適用。把本機站做好，再回來這篇把它推上線。

搬家之前，先幫你的站「減重」

很多站長忽略了搬家前的一個動作：清理。本機開發期間，你一定裝過不少試用外掛、切換過好幾個佈景、累積了大量文章修訂版本跟垃圾留言。這些東西平常不影響本機運作，但一旦打包成搬家封裝，它們會讓檔案膨脹、資料庫變肥，直接拖慢部署速度，甚至撞上外掛的檔案大小限制。

換句話說，你搬的是一個會持續長大的資料庫，越早瘦身，後面的每一步都越輕鬆。我會建議在搬家前做這幾項清理：

• 先備份，再移除確定用不到的外掛與佈景。保留作用中的父佈景、子佈景及其他相依元件；停用不等於刪除檔案。
• 評估修訂版本的保留需求。修訂可用來回復內容，不必為搬家全部清空；要清理時先保留可還原副本。
• 區分測試資料與正式資料。確認用途後再刪除垃圾留言、回收桶及測試訂單，別誤刪仍要使用的素材。
• 排除可重建的快取和重複備份。依工具掃描結果檢視大檔案；debug 記錄與備份可能含敏感資料，依維運需求安全保存，不要留在公開目錄。

清理不必要檔案與資料後，搬家封裝可能明顯縮小，但實際幅度取決於媒體庫、備份檔、快取與資料庫內容。主機到主機的流程可參考WordPress 搬家到新主機教學。若要反覆演練，也可用WP Reset 重置 WordPress 測試站資料庫，但操作前要確認重置範圍並保留可還原備份。

搬家之前，先做一次完整的「起飛前檢查」

搬家前先確認環境、備份與回復方式，再開始打包。以下清單可用來記錄核對結果，所需時間視網站相依元件與主機設定而定。

1. 確認本機 WordPress 版本與線上主機一致。記錄來源核心、外掛與佈景版本，先在測試環境確認目標 PHP 相容性。必要的更新應先測試，不要把未測試的大版本升級和正式切換混在一起。
2. 核對 PHP 版本。WordPress 官方對伺服器環境有明確建議，截至 2026 年 9 月，建議 PHP 8.3 以上、MySQL 8.0 以上或 MariaDB 10.11 以上，並支援 HTTPS。舊版仍可能運作，不代表仍受安全維護。去你的主機後台（cPanel、SiteGround、Cloudways 都看得到）確認目標版本與外掛、佈景和所需擴充套件相容。
3. 盤點目前啟用的外掛與佈景。把清單記下來，搬完之後要逐一核對有沒有全部正常啟用。若想了解 WordPress 的使用規模，可參考 W3Techs 的統計；市場占有率不能用來判斷個別外掛相容性，仍須測試自己的組合。
4. 檢查永久連結結構。本機設定的網址結構（例如文章名稱）搬過去後可能失效，導致內頁 404。記下你本機用的結構，搬完後重新設定一次並儲存，讓 WordPress 重寫規則。
5. 確認搜尋引擎可見性設定。本機開發時多半勾選了「阻擋搜尋引擎索引此網站」，這個設定會跟著資料庫一起搬過去。上線後一定要記得取消勾選，並檢查輸出的 noindex、robots.txt 和存取權限；取消勾選只是其中一步，不代表 Google 會立即收錄。
6. 備份本機站。搬家前先做一份完整備份，包含檔案跟資料庫。萬一搬的過程出錯，你隨時可以回到本機的乾淨狀態重新來過。備份這件事我們有完整的WordPress 備份與還原指南可以參考。
7. 準備好線上主機的 SFTP 帳號、資料庫名稱、使用者與密碼。這些資訊在搬家當下會立刻用到，先確認存取權限，將憑證放在密碼管理工具，不要貼進公開文件或截圖。

這份清單走完，你對自己要搬什麼、搬到哪、會踩到哪些坑，已經心裡有底了。接下來就是選一條適合你的搬家路線。

三條搬家路線，哪一條適合你？

從本機搬到線上主機，主流的方法有三條路線，各有各的適合場景。我先幫你把三條路的差異整理成表格，再逐一展開講。挑對路線，後面的事會輕鬆很多。

如果你不知道該選哪條，我的建議是：第一次搬家就用 Duplicator。它就是為本機到線上這個場景設計的，把最容易出錯的網址置換自動化掉了。我們還有一篇更完整的WordPress 搬家外掛評比，把八款主流工具的優缺點都列出來，你可以交叉比對。

搬家路線選定了，但你的線上主機準備好了嗎？

在實際開始打包之前，還有一個前提要確認：你的線上主機到底裝好了沒有。很多人以為買完主機就能搬，其實買完主機只是拿到一塊空地，還需確認 PHP、資料庫、網站目錄及 HTTPS 是否準備完成。不同路線對主機的初始狀態要求不一樣：本文的 Duplicator 傳統安裝及完整手動部署使用獨立的空目錄與空資料庫，因為它們會把完整的 WordPress 連同核心檔案一起部署上去；All-in-One WP Migration 的匯入法則需要主機上已經有一個乾淨的 WordPress 安裝，因為它透過外掛匯入並覆寫內容。若目標原本有網站，先完整備份並確認覆寫範圍，不能直接清空。

主機類型的選擇也會影響搬家體驗。共享主機入門門檻低、價格親民，但資源有限，大站搬上去可能跑不動；VPS 與雲端方案可提供不同資源和管理方式，實際效能仍取決於配額、設定與工作負載；是否需要自行維運要看方案。如果你還在猶豫該選哪種，我們的共享主機 vs VPS vs 雲端主機比較指南把四種主機類型的差異跟適合場景都拆解清楚了。選對主機，搬家才有一個穩固的落腳處。

路線一：Duplicator 打包法，把整個站裝進一個壓縮檔

Duplicator 是 WordPress 官方外掛庫裡最受歡迎的搬家工具之一。它的運作原理很漂亮：本機端把整站打包成兩個檔案，一個是包含所有檔案與資料庫的壓縮封存檔（archive），另一個是安裝程式 installer.php。你把這兩個檔案上傳到線上主機，用瀏覽器打開 installer.php，它就會一步步引導你完成部署，依來源與目標設定執行網址和路徑替換，完成後仍需抽查自訂設定與內容。

實際操作分三個階段。

階段一：本機端打包。安裝並啟用 Duplicator，建立新的備份封裝，核對掃描結果與包含的內容後執行打包。下載配對的安裝程式與封存檔；檔名依備份而異，封存格式可能是 ZIP 或 DAF。若要排除快取或其他檔案，先確認其可重建且不是必要資料。

掃描提示要逐項打開查看原因，不能只憑顏色或「警告」字樣決定能否繼續。大檔案、可用空間、PHP 限制、讀取權限與封存引擎都可能影響打包；依目前版本顯示的說明處理，再確認生成的封存檔完整。掃描通過也不能取代目標環境的部署測試。

階段二：線上主機準備資料庫。到你的主機後台，用資料庫精靈建立一個全新的空資料庫，記下資料庫名稱、使用者帳號、密碼跟主機位址。以 cPanel 為例，它有內建的 MySQL 資料庫精靈，逐步引導你建立資料庫、新增使用者、對這個資料庫授予安裝和更新所需權限，而不是全伺服器的管理權限。這組連線資訊待會安裝程式會跟你要。

階段三：上傳與部署。先確認目標網域的 HTTPS 可用，再把配對的安裝程式與封存檔上傳到預定的獨立網站目錄。以實際安裝程式檔名開啟 HTTPS 網址，核對目標路徑與資料庫後測試連線，依畫面完成部署與網址替換。安裝檔只應暫時存在，使用工具可用的密碼保護或主機存取限制；登入驗收後移除安裝程式、封存檔及相關安裝目錄，確認原下載網址已無法存取。

Duplicator 的免費版對大多數中小型站來說已經夠用。如果你的站檔案量很大，打包時可能會遇到封裝大小限制，先依掃描訊息區分封存引擎、磁碟空間或主機資源限制，再評估其他工具或付費功能；更換方案前先確認它能處理實際原因。

路線二：All-in-One WP Migration，以外掛匯出匯入

如果你覺得 Duplicator 的三階段還是有點複雜，All-in-One WP Migration 把流程壓縮到最直覺的兩個動作：本機匯出、線上匯入。這款外掛在WordPress 網站搬家教學裡也是我們常推薦的選項之一，適合希望透過後台操作的人，但仍需核對主機限制和覆寫風險。

本機端安裝外掛後，到匯出功能選擇匯出到檔案，它會把整站打包成一個副檔名為 .wpress 的單一檔案，下載到你的電腦。然後到線上主機的 WordPress（要先安裝好一個空的 WordPress），同樣裝上 All-in-One WP Migration，到匯入功能上傳那個檔案。外掛會自動解開、寫入、置換網址，全部一氣呵成。

匯入前先備份目標站並閱讀覆寫確認，避免蓋掉原有資料。遇到檔案過大，要區分外掛顯示的匯入限制，以及 PHP 上傳、記憶體、執行時間和磁碟空間限制；可請主機商調整可調的設定，或評估官方 Unlimited Extension。匯入完成後使用來源站帳號登入，核對固定網址和前後台功能。

選工具時，可用備份大小、媒體數量、資料庫容量、主機資源及還原測試結果來比較。以相同網站資料在測試環境比較部署和還原流程。

路線三：手動搬家，檔案加資料庫兩段式作業

手動搬家是當外掛搞不定時的最後手段，也是你徹底搞懂 WordPress 結構的最佳教材。流程拆成檔案搬移跟資料庫搬移兩段。

檔案段：優先用 SFTP 連上線上主機（如果還不熟 FTP 操作，可以先看我們寫的WordPress FTP 完整教學），把本機的 WordPress 檔案上傳至主機指定的網站目錄。若目標已有相容的 WordPress 核心，仍須盤點 wp-content 以外的自訂檔案、wp-config.php、伺服器設定與資料庫，不能假設只傳 wp-content 就完成。上傳完之後，打開 wp-config.php，把資料庫名稱（DB_NAME）、使用者（DB_USER）、密碼（DB_PASSWORD）、主機位址（DB_HOST）全部改成線上主機配發的值。這一步沒改對，網站會直接顯示資料庫連線錯誤。

資料庫段：在本機用 phpMyAdmin 把資料庫匯出成 .sql 檔。到線上主機的 phpMyAdmin，匯入這個 .sql 檔。匯入完成後，最關鍵的一步來了：先確認完整的來源網址與目標網址，再對相關資料執行序列化安全的搜尋取代；不要無差別替換所有 localhost 字樣。這不是單純改 wp_options 裡的 siteurl 跟 home 兩筆選項就夠的，因為文章內文、選項設定、選單連結、圖片網址裡到處都寫死了 localhost。

可使用能處理序列化資料的工具，例如 WP-CLI 的 search-replace。先備份資料庫，確認資料表與欄位範圍，使用 dry-run 檢視預計替換結果再執行。直接以一般 SQL 字串替換處理序列化欄位，可能使字串長度記錄失效；網頁式資料庫工具若有上傳到主機，用完也須移除並確認不能公開存取。

為什麼序列化這件事這麼關鍵？因為 WordPress 的選項資料表裡，有大量設定值是被 PHP 的 serialize 函式包裝過的字串。舉個例子，一個 widget 的設定存成 s:9:"localhost";，開頭的 s:9 代表這是一個位元組長度為 9 的字串。當你把 localhost 換成 yoursite.com（長度變成 12），如果只改文字不改那個 9，PHP 在反序列化的時候讀到的長度跟實際不符，整個設定值就報廢了。這就是為什麼裸跑 SQL 取代會搞壞網站，而專門工具會同步修正長度標記的原因。理解了這個機制，你就明白那些「明明改了網址卻還是壞掉」的悲劇是怎麼發生的。

手動搬家後要確認固定網址與前後台功能，並核對 wp-config.php 中的連線和環境設定。Authentication Keys and Salts 用於認證相關雜湊及 cookie 驗證，不是把使用者密碼直接加密。若需要撤銷既有登入，或本機金鑰曾外洩，可換成新的隨機值，這會使既有登入 cookie 失效；更換金鑰不能取代漏洞修補與入侵清理。

這條路線的好處是你對每一步都瞭若指掌，日後網站出任何問題，你的除錯能力會比只用過外掛的人強很多。代價是步驟多、需要對 WordPress 的檔案結構跟資料庫有一定認識。如果你是第一次搬家，我不建議從這條路入門，但把它當作理解原理的教材，非常值得。

搬完不是結束：上線後的七件事

很多教學文章寫到檔案上傳完成就收尾了，但那只是技術搬家完成，你的網站離「正式上線」還有距離。接下來這七件事，決定了你的網站能不能被搜尋引擎找到、能不能安全運作、能不能留住第一批訪客。想讓第一天就留下好印象，上線前不妨對照自架站健檢表把常見的版面問題先掃一輪。

1. 重新儲存固定網址。到設定裡的固定網址頁面，選回你原本的結構（通常是文章名稱），點儲存。這可刷新 WordPress 的重寫規則；Apache 還需確認 .htaccess 可用，Nginx 則要核對伺服器設定。404 也可能有其他原因。相關的 SEO 結構設定可以看我們的WordPress 永久連結 SEO 設定教學。
2. 關閉搜尋引擎阻擋。到閱讀設定裡，確認「阻擋搜尋引擎索引這個網站」沒有被勾選。這個選項在本機開發時多半是勾起來的，會跟著資料庫一起搬過去。公開頁面還應檢查 noindex、robots.txt、HTTP 狀態與存取權限。
3. 驗證並統一 HTTPS。現在的瀏覽器對沒有 SSL 憑證的網站會直接標示「不安全」，對訪客信任度的傷害很大。更重要的是，Google 早在 2014 年的 官方公告 中就把 HTTPS 列為排名訊號之一。憑證應在部署前準備完成；部署後再核對 HTTPS 網址、轉址與混合內容，啟用方式以主機文件為準。SSL 的完整安裝流程可以參考我們的SSL 憑證安裝教學，想了解原理則看HTTP 換 HTTPS 完整攻略。
4. 提交到 Google Search Console。到 Google Search Console 加入你的網站、驗證所有權，然後提交 XML Sitemap。Sitemap 可協助 Google 發現網址，但提交不代表一定抓取、建立索引或取得排名。完整的設定流程看我們的Google Search Console 安裝教學，Sitemap 的原理與設定看XML Sitemap 完整說明。
5. 設定自動備份。網站剛上線是最興奮的時刻，也是最容易忘了防護的時刻。依可接受的資料損失與內容更新頻率安排備份，保存異地副本並演練還原。我們推薦過的UpdraftPlus 備份教學是可用來開始設定備份的參考。
6. 檢查內部連結與圖片。逐一點過主要頁面，看圖片有沒有破圖、內部連結有沒有指向 localhost。若有殘留，先確認它來自資料庫、自訂程式或快取，備份並檢視替換範圍後再處理。
7. 確認行動版顯示。Google 現在採用的是行動優先索引（mobile-first indexing），也就是主要使用行動版內容來建立索引與評估排名（見 2023 年 10 月的 搜尋中心公告）。用你的手機打開網站，確認選單、圖片、表單在小螢幕上都正常顯示。

這七件事做完，你的網站才算真正活著。如果你是從 WordPress.com 搬到自架的 WordPress.org，流程跟本機到線上又有些不同，可以額外參考我們的WordPress.com 搬家到 .org 完整教學。

白畫面、資料庫連線錯誤：實戰最常踩到的坑

以甜點電商這類站為例：本機用 Local 起，佈景跟 WooCommerce 都調到很順，結果一推上去前台直接白畫面。這是假設的排錯情境，需以實際記錄確認原因。白畫面（White Screen of Death）之所以讓人慌，是因為它什麼錯誤訊息都不給你，你完全不知道從何查起。其實它背後的原因是可以分類的。

白畫面可能涉及 PHP 致命錯誤、記憶體、外掛或佈景相容性等原因。先查看主機的 PHP 錯誤記錄；需要 WordPress 除錯時，可暫時啟用 WP_DEBUG 與受保護的記錄檔，同時關閉 WP_DEBUG_DISPLAY 和 PHP 的公開錯誤顯示。避免將路徑、憑證或個資印到訪客畫面，修復後恢復正式環境設定，安全保存或清理記錄。

幾個典型的錯誤情境跟對應的處理方式，我整理成下表，你遇到的時候可以直接對照。

處理這些問題的時候有一個原則：一次只改一個東西。很多人一著急就同時改外掛、改設定、改設定檔，結果問題解決了也不知道是哪個動作生效的，下次遇到同樣狀況還是束手無策。耐住性子，一次一個變數，你會學到真正的除錯能力。

以前述甜點電商情境為例，若記錄顯示佈景引用了不存在的本機絕對路徑，就要檢查該程式如何取得路徑，而不是只清快取。自訂程式可依用途使用 WordPress 的目錄與網址函式，修正後再測試。WP_DEBUG 只是輔助工具之一，主機記錄也能提供線索。挑選佈景時，可參考WordPress 佈景主題推薦，並另外測試自己的外掛與部署環境。

上傳或更新失敗也可能與檔案擁有者、群組、磁碟空間或權限有關。資料夾 755、檔案 644 是常見起點，但實際配置取決於主機執行 PHP 的方式，敏感設定檔可能需要更嚴格權限。先依錯誤記錄和主機文件確認原因，不要為了排錯直接把整站開成任意使用者可寫入。

還有一個小提醒要講：如果搬完之後發現某個頁面網址結構變了（例如本機用 localhost/?p=123，上線後改成 yoursite.com/post-name），要實際測試舊網址的回應；WordPress 的查詢式網址未必會變成 404。雖然本機站通常還沒有被搜尋引擎收錄、影響不大，但如果你是從一個已上線的舊結構換到新結構，記得用適當的永久轉址（301 或 308）把舊網址指到新網址，保留累積的排名訊號。相關做法看我們的301 與 302 轉址完整教學。

搬家與 SEO：讓公開頁面可被發現與索引

一般僅限本機存取的 localhost 網站無法供 Googlebot 抓取。上線後，公開網址還需符合抓取與索引條件；本機準備好的內容和設定有助於部署品質，但沒有可以從上線日開始計算的固定「排名計時器」。

部署完成後先確認公開頁面可存取、HTTPS 正常，以及手機版主要內容、連結與結構化資料完整，再提交 Sitemap 協助發現網址。這些檢查與持續改善內容可以並行，不需停下寫作等待收錄；Google 也不承諾新頁面何時建立索引。

另一個容易輕忽的點是網域的 DNS 設定。你的正式網域必須正確指向線上主機的 IP，訪客跟爬蟲才進得來。如果你剛買網域還沒設定好，可以看我們的DNS 網域名稱指向設定教學。DNS 快取更新會受 TTL 與解析器影響。先透過主機預覽或 hosts 設定測試目標站，再於目標可服務時切換 DNS，並確認郵件等其他記錄沒有被誤改。

長期來看，上線後你要建立的是一個穩定、可被信任的內容資產。WordPress 搬家只是起點，後續可持續改善內容品質、網站速度與使用者體驗，同時以搜尋資料觀察成效；搜尋排名涉及多項系統與訊號。如果你想把基礎打得更穩，延伸閱讀可以看WordPress 架站與 SEO 優化全攻略，把搬家之後的優化方向一次看清楚。

上線後可在 Google Search Console 查看「網頁索引」報表了解已索引與未索引網址的分類，再以「網址審查」檢查重要頁面的索引資訊或即時可存取性。零索引不一定是 robots.txt 或 noindex，應同時核對網址發現、內容與技術條件；刻意移除的頁面也不必為了清空報表而一律轉址。具體操作可看Google 網頁收錄查詢教學。

速度是另一個上線後立刻要顧的面向。Google 把網頁體驗訊號列為排名考量之一，應先量測實際瓶頸，再判斷是否需要快取、圖片或伺服器調整。趁內容還不多的時候先把效能基礎打好，比你累積了上百篇文章之後再回頭優化輕鬆太多。如果你想知道從哪裡著手，可以看我們的速度優化的完整做法，把載入時間壓下來。

本機上線前後的行動清單

依序完成以下步驟，並記錄測試結果與可回復的備份位置，確認功能正常後再開放正式流量。

1. 記錄來源環境並備份。核對核心、外掛、佈景、PHP 與資料庫相容性，以及網址結構和存取權限。
2. 準備目標站。確認 HTTPS、獨立目錄、資料庫和安全連線；已有內容的目標站先備份，不能直接清空。
3. 依選定工具部署。核對打包內容、目標路徑、覆寫範圍和網址替換。
4. 驗收並清理安裝檔。測試登入、頁面、表單、圖片與手機版，確認安裝程式和封存檔不再公開存取。
5. 切換與核對 DNS。目標可服務後才切換，檢查解析與其他必要 DNS 記錄。
6. 確認索引與備份設定。核對公開頁面的可見性，提交 Sitemap，設定適合資料更新頻率的備份與還原演練。
7. 追蹤錯誤。查看受保護的記錄，逐項排除；修復後恢復正式環境的除錯設定。

有一個小建議：第一次搬家，挑一個你比較沒有壓力的時段來做，例如週末的下午。預留查資料、測試或回復備份的時間，在時間充裕的狀態下處理，你的判斷力會好很多，也不會因為趕時間而亂改一通。如果你是幫客戶搬家，更要在正式切換前先用一個臨時網址或預覽模式測試過一遍，確認前後台都正常，再把正式網域指過去。這個前置測試的習慣，有助於提早發現環境差異。

WordPress 從本機搬到線上主機，說難不難，說簡單也確實有很多細節會絆倒人。但只要你把環境落差搞懂、選對路線、上線後把該做的事做齊，這個過程其實很踏實。每一個你親手解決的錯誤，都會變成你日後經營這個網站的底氣。

搬家過程中難免會遇到卡關的時刻，那種「明明照著做卻還是出錯」的挫折感幾乎每個站長都遇過。但回頭看，那些卡關的經驗恰恰是你跟只會用一鍵安裝的站長拉開差距的地方。你搞懂了資料庫結構、搞懂了網址置換的原理、搞懂了伺服器環境的落差，這些知識會在未來每一次網站調整、每一次主機升級、每一次效能除錯的時候持續發揮價值。把它當成一堂投資報酬率極高的實戰課就對了。

網站上線只是開始，接下來才是真正累積的階段。如果你在主機選擇、網域設定、或 SEO 接軌上還有任何環節想再深入，我們的網站架設完整自學指南把從主機到建站的流程串了起來，可以接著往下看。現在，去把你調到完美的本機站，推到全世界看得到的地方吧。