說實話，在線更新這塊我一開始想得很複雜，以為要寫一整套版本比對、差異包、回滾機制。結果實際部署下來，這個系統的思路簡單得有點意外：整個更新入口就是一個檔案，sdk/online_update.php，拷過去、改兩個常數、瀏覽器打開，就完事了。對於那種手上管著十幾套源碼授權的站長來說，這種「單檔案即插即用」的設計省下的時間相當可觀。
部署前必須確認的環境
先把地基打好，不然後面卡在莫名的白屏上會很煩。PHP 版本要求 7.2 以上，但我個人建議直接上 7.4+，PDO 的行為和錯誤提示都友善得多；資料庫 MySQL 5.6 起跳。目錄權限方面，includes/、install/、uploads/ 這三個必須可寫——尤其 includes/，因為授權資訊檔案（例如 /includes/authcode.php）就寫在這裡，權限不對的話更新包下載回來也寫不進去。另外別忘了安裝 SG 擴展，加密核心跑不起來八成就是這個沒裝。
兩個常數，決定成敗
打開 online_update.php，頂部只有兩處要動：
QY_UPD_PASSWORD：訪問口令。這是唯一的門禁，請務必改掉預設值，並且用強度夠的字串。這個頁面能直接觸發檔案覆寫，等於半個後門，裸奔在公網上實在太危險。QY_AUTH_CORE：指向帶授權代碼的核心檔案，例如../includes/authcode.php，或任何包含AUTHCODE檢測邏輯的檔案。
設好之後，程式會自己從核心檔案裡解析出 AUTH_SERVER、AUTH_APPNAME、AUTHCODE、AUTH_BUILD 四個值。這個設計挺聰明的——你不必在更新頁裡重複填一遍授權資訊，路徑指對了，其餘自動繼承。
版本發布端的配合
客戶端能不能「檢查到更新」，取決於站長端有沒有規矩地發版本。每次發布時，版本號與 build 都要填，而 build 是實際比對的依據。我見過有人只改版本號、build 忘了遞增，結果客戶那邊死活顯示「已是最新」，排查半天才發現問題在這。
還有一個容易被忽略的細節：客戶下載更新包時，系統會自動把 AUTHCODE、上級地址、應用標識、AUTH_BUILD 寫進模板路徑。所以更新包裡千萬不要打包一份寫死授權資訊的舊檔案，否則覆蓋回去，授權就錯亂了。
最後提醒一句，更新前先備份。一鍵更新雖然爽，但檔案覆寫這種操作，沒有回滾就出事的時候真的只能乾瞪眼。
評論（14）
哇，真的只要換兩個常數就能更新，省了好多時間！
我之前用過類似的單檔案更新，感覺權限設定最容易卡關。
QY_UPD_PASSWORD 那個口令要設多長才安全呢？
如果伺服器還是 PHP 7.2，會不會遇到什麼相容性問題？
有沒有什麼工具可以自動備份整個站點，防止更新失敗？
我在 includes 目錄忘記給寫權限，結果更新時白屏慘了。
這樣的即插即用感覺不錯，但如果授權檔被改掉會怎樣？
每次發布新版本，build 必須遞增，這點真的容易忽視。
SG 擴展沒裝會怎樣？會不會直接導致更新失敗？
想問一下，更新包裡的 AUTHCODE 會不會因為環境不同而衝突？
備份真的很重要，我通常會先把整個資料庫 dump 下來。
如果要在多個站點同步更新，有沒有推薦的自動化腳本？
這套系統在本機測試沒問題，上線後卻出現權限錯誤，怎麼排查？
感謝分享，感覺比起手動比對差異包簡單太多了！