建站時(shí)埋下、后期很難修復(fù)的隱患
核心特點(diǎn)：不是改改文字樣式就能搞定，往往要動底層架構(gòu)、數(shù)據(jù)庫、權(quán)限邏輯，甚至部分需要重做站點(diǎn)；很多問題平時(shí)看不出，上線久了、流量上來才爆發(fā)。
一、底層架構(gòu)與程序選型類（難改）
隨便選用小眾 / 停止維護(hù)的源碼、CMS建站圖省事用不知名源碼、多年不再更新的舊版 CMS。后期：漏洞沒人修補(bǔ)、沒有插件、找不到開發(fā)者，一旦被黑客入侵，沒法打補(bǔ)丁。想遷移內(nèi)容，數(shù)據(jù)庫結(jié)構(gòu)不通用，導(dǎo)出導(dǎo)入非常麻煩，很多字段錯亂。
對比：主流 CMS（WordPress、Dede、Typecho、帝國等）至少社區(qū)有資料，但舊版本依然坑。
- 前后端代碼耦合嚴(yán)重、沒有分層頁面代碼、業(yè)務(wù)邏輯、SQL 查詢混寫在同一個文件里。改一個功能，很容易連帶崩其他頁面；想做改版、加新模塊，牽一發(fā)而動全身。很多外包小站容易踩這個坑。
- 數(shù)據(jù)庫設(shè)計(jì)缺陷
- 缺少索引：數(shù)據(jù)量變大后查詢極慢，后臺卡、頁面加載超時(shí)；后期加索引要鎖表，量大時(shí)會直接停機(jī)。
- 字段設(shè)計(jì)不合理、冗余字段、缺少關(guān)聯(lián)約束：數(shù)據(jù)越來越多出現(xiàn)臟數(shù)據(jù)（重復(fù)、空值、無效記錄）。
- 沒有分庫分表規(guī)劃：適合小站，一旦數(shù)據(jù)幾十萬 +，重構(gòu)數(shù)據(jù)庫成本極高，還要做數(shù)據(jù)遷移校驗(yàn)。
- 沒有備份機(jī)制、沒有定時(shí)備份腳本：一旦刪庫中毒，數(shù)據(jù)直接丟失。
- 服務(wù)器 / 環(huán)境選型錯誤一開始貪圖便宜用低配虛擬主機(jī)，或者 Windows 環(huán)境跑 PHP 站點(diǎn)。后期流量上漲，遷移到云服務(wù)器要改路徑、權(quán)限、偽靜態(tài)；有些程序環(huán)境依賴特殊擴(kuò)展，遷移后大量頁面 404。還有：域名和站點(diǎn)綁定混亂、一開始用 IP 建站，后期換域名大量鏈接失效。
二、安全類隱患（出事代價(jià)大，修復(fù)繁瑣）
- 權(quán)限配置過大web 目錄給了 777 全開權(quán)限、數(shù)據(jù)庫賬號直接 root 權(quán)限。黑客拿到一句話木馬就能拿下整臺服務(wù)器。后期要逐目錄、逐個文件重設(shè)權(quán)限，文件數(shù)量多的時(shí)候工作量巨大，一不小心弄成 500 錯誤。
- 沒有做輸入過濾，SQL 注入、XSS 漏洞原生存在代碼直接接收用戶參數(shù)拼 SQL，前端不轉(zhuǎn)義輸出。這種屬于底層代碼漏洞，不是裝個安全插件就能根治。簡單防護(hù)只能臨時(shí)擋攻擊，徹底修復(fù)需要逐頁改寫代碼。
- 后臺地址、弱密碼、文件上傳漏洞上傳接口沒有校驗(yàn)文件類型，允許上傳 php/asp 腳本文件。很多站點(diǎn)被掛黑鏈、挖礦木馬就是這個原因。修復(fù)要重寫上傳邏輯，還要全網(wǎng)掃描清理已經(jīng)上傳的惡意文件。
- 沒有 HTTPS 規(guī)劃、證書配置錯誤建站全程 http，后期想切 https 會出現(xiàn)大量混合內(nèi)容報(bào)錯（圖片、js、css 還是 http）。如果大量硬編碼寫死 http 地址，需要批量改代碼 + 數(shù)據(jù)庫，還會影響 SEO。
補(bǔ)充：SSL 證書只是一部分，全站資源硬編碼 http 是大坑。
三、SEO 與 URL 結(jié)構(gòu)類（改了傷流量，幾乎不敢動）
URL 結(jié)構(gòu)設(shè)計(jì)不合理，后期無法修改比如 URL 帶 ID、中文、特殊符號，或者層級太深；或者靜態(tài) / 偽靜態(tài)規(guī)則寫得很差。
難點(diǎn)：上線收錄后，一旦修改 URL，舊鏈接全部失效。雖然可以做 301，但大量 301 會損失權(quán)重，工作量巨大。很多網(wǎng)站寧愿一直用爛 URL 也不敢重構(gòu)。
- 硬編碼寫死域名、站內(nèi)鏈接代碼、模板、數(shù)據(jù)庫里大量寫死
shturl.cc/YAHg，不是相對路徑。后期換域名、遷移服務(wù)器，需要批量替換，極易漏改，出現(xiàn)大量死鏈。 - 缺少標(biāo)準(zhǔn)化元信息、重復(fù)頁面、無規(guī)范 canonical分頁、篩選頁面生成大量重復(fù)內(nèi)容，沒有 canonical 標(biāo)簽。等到被搜索引擎判定重復(fù)內(nèi)容降權(quán)，再批量處理頁面規(guī)則，工作量巨大。
- 圖片資源無規(guī)范，圖片地址硬寫、沒有圖片壓縮 / CDN 規(guī)劃圖片全部存在站點(diǎn)服務(wù)器，不做縮略圖；圖片鏈接寫死域名。后期圖片越來越多，服務(wù)器帶寬扛不??；遷移圖片需要遷移海量文件，還要改數(shù)據(jù)庫里圖片地址。
四、業(yè)務(wù)功能與擴(kuò)展性隱患（越用越難加功能）
- 沒有統(tǒng)一的接口，業(yè)務(wù)邏輯硬寫死比如支付、短信、會員邏輯直接寫在頁面里。后期要更換支付服務(wù)商，幾乎要重寫整套業(yè)務(wù)代碼，不能簡單配置切換。
- 會員體系設(shè)計(jì)缺陷用戶密碼明文存儲（高危！）；用戶信息表缺少字段；權(quán)限模型簡單，后期要加角色、分級權(quán)限，需要重構(gòu)用戶模塊，還要遷移已有用戶數(shù)據(jù)，風(fēng)險(xiǎn)高。明文密碼一旦泄露，責(zé)任很大。
- 沒有日志系統(tǒng)不記錄訪問日志、操作日志。遇到被攻擊、用戶反饋異常時(shí)，無法排查問題；后期補(bǔ)日志系統(tǒng)，需要改造底層代碼。
五、多端、兼容、資源類
- 響應(yīng)式?jīng)]做，移動端單獨(dú)頁面但數(shù)據(jù)不同步PC 和手機(jī)兩套獨(dú)立程序，內(nèi)容分開維護(hù)。后期要統(tǒng)一管理，需要做數(shù)據(jù)同步，非常麻煩。
- 靜態(tài)資源（JS/CSS）雜亂無打包、無版本管理大量零散 js，沒有合并，沒有 cdn。頁面加載慢，后期優(yōu)化要重構(gòu)前端，容易出現(xiàn)樣式?jīng)_突。
六、容易被忽略：備份、遷移、文檔缺失
- 建站不留文檔沒有部署文檔、數(shù)據(jù)庫字典、接口說明。當(dāng)初開發(fā)的人離職之后，沒人看懂代碼，后面接手的人只能猜，簡單改功能都容易出問題。
- 只做全量備份，不做增量備份，不驗(yàn)證備份可用性很多站點(diǎn)有備份，但從來沒試過恢復(fù)。等到出事，備份文件損壞無法恢復(fù)。
? 優(yōu)先級總結(jié)：哪些坑難修復(fù)
- 數(shù)據(jù)庫底層設(shè)計(jì)、明文密碼、耦合代碼（重構(gòu)成本高）
- URL 結(jié)構(gòu)、全站硬編碼域名（改動會嚴(yán)重影響 SEO，不敢輕易動）
- 底層代碼漏洞（安全風(fēng)險(xiǎn)，修復(fù)需要逐頁審計(jì)）
- 老舊停止維護(hù)程序（后期沒有支持，只能整站遷移）
? 建站階段可以提前規(guī)避的簡單清單
- 優(yōu)先成熟維護(hù)中的程序，盡量減少自研底層代碼
- 數(shù)據(jù)庫提前規(guī)劃，密碼必須哈希加密存儲
- URL 規(guī)劃好，上線收錄前定稿；資源盡量使用相對路徑
- 服務(wù)器最小權(quán)限原則，上傳接口嚴(yán)格校驗(yàn)
- 上線前就部署 HTTPS，資源不要硬寫 http
- 搭建定時(shí)備份，并且定期測試恢復(fù)
- 留存部署文檔
