簡(jiǎn)介這份資源是一套免費(fèi)開(kāi)源的CMS內(nèi)容管理系統(tǒng)源碼面向希望快速搭建網(wǎng)站或進(jìn)行二次開(kāi)發(fā)的開(kāi)發(fā)者尤其適合具備Java基礎(chǔ)、想研究前后臺(tái)實(shí)現(xiàn)邏輯的中高級(jí)學(xué)習(xí)者。系統(tǒng)基于Java技術(shù)構(gòu)建采用數(shù)據(jù)庫(kù)存儲(chǔ)內(nèi)容提供完整的前后臺(tái)代碼便于按需定制功能、優(yōu)化性能甚至重構(gòu)界面。壓縮包為zip格式大小約13.38MB包內(nèi)包含前后臺(tái)核心代碼及database數(shù)據(jù)庫(kù)相關(guān)文件可用于內(nèi)容發(fā)布、用戶管理、權(quán)限控制等模塊的二次開(kāi)發(fā)。目前已有244人學(xué)習(xí)下載說(shuō)明其在開(kāi)源CMS學(xué)習(xí)群體中具有一定參考價(jià)值。通過(guò)研讀這套源碼讀者可以理解CMS的內(nèi)容存儲(chǔ)結(jié)構(gòu)、數(shù)據(jù)庫(kù)設(shè)計(jì)與訪問(wèn)邏輯掌握開(kāi)源許可協(xié)議下的使用與修改邊界并借助社區(qū)力量擴(kuò)展系統(tǒng)功能從而更高效地管理和維護(hù)自己的網(wǎng)站項(xiàng)目。1. 一套能直接跑起來(lái)的內(nèi)容管理系統(tǒng)到底長(zhǎng)什么樣很多開(kāi)發(fā)者第一次接觸 CMS都是被“免費(fèi)開(kāi)源”四個(gè)字吸引進(jìn)來(lái)的結(jié)果下載完發(fā)現(xiàn)要么是半成品要么文檔寫(xiě)得像天書(shū)光是把前后臺(tái)跑起來(lái)就得折騰一整天。我最近拆了一套前后臺(tái)代碼都齊全的 CMS 內(nèi)容管理系統(tǒng)它的定位很明確給中小型站點(diǎn)、企業(yè)官網(wǎng)、個(gè)人博客提供一個(gè)開(kāi)箱即用的內(nèi)容發(fā)布后臺(tái)同時(shí)把前端展示層也一并給你不用自己再?gòu)念^搭頁(yè)面。這套代碼適合兩類人一類是想快速上線一個(gè)內(nèi)容站、不想從零寫(xiě)增刪改查的開(kāi)發(fā)者另一類是想拿一個(gè)結(jié)構(gòu)完整的項(xiàng)目練手、學(xué)習(xí)前后臺(tái)如何分離與協(xié)作的進(jìn)階學(xué)習(xí)者。它把文章管理、欄目分類、用戶權(quán)限、前后臺(tái)路由這些 CMS 最核心的東西都落地成了可運(yùn)行的代碼而不是停留在架構(gòu)圖里。2. 技術(shù)選型與目錄結(jié)構(gòu)先搞清楚代碼怎么組織2.1 前后臺(tái)分離的選型邏輯這套 CMS 采用的是典型的前后臺(tái)分離思路。后臺(tái)負(fù)責(zé)內(nèi)容的生產(chǎn)和管理前端負(fù)責(zé)內(nèi)容的展示和消費(fèi)兩者通過(guò)接口層通信。常見(jiàn)做法是后端提供 RESTful 風(fēng)格的 API前端用模板引擎或前端框架渲染頁(yè)面。這套代碼里后端承擔(dān)了數(shù)據(jù)持久化、權(quán)限校驗(yàn)、接口輸出三件事前端則專注于頁(yè)面渲染和交互。為什么這么選因?yàn)?CMS 的核心矛盾在于“后臺(tái)要穩(wěn)定、前端要靈活”。后臺(tái)的增刪改查邏輯相對(duì)固定適合用成熟的后端框架快速搭建前端展示層則經(jīng)常需要改版、換皮膚、適配不同終端分離之后改前端不會(huì)動(dòng)到后臺(tái)邏輯改后臺(tái)也不會(huì)影響前端頁(yè)面。這是我在多個(gè)項(xiàng)目里驗(yàn)證過(guò)的分工方式維護(hù)成本最低。技術(shù)棧上后端一般會(huì)選一門帶成熟 ORM 和路由能力的語(yǔ)言比如 Python 的 Flask/Django、Node.js 的 Express/Koa、PHP 的 Laravel 等數(shù)據(jù)庫(kù)用 MySQL 或 PostgreSQL 存內(nèi)容數(shù)據(jù)前端用 HTML 模板加少量 JavaScript或者直接用 Vue/React 做單頁(yè)應(yīng)用。這套 CMS 的代碼結(jié)構(gòu)就是按這個(gè)思路組織的下面看目錄。2.2 目錄結(jié)構(gòu)逐層拆解一套能跑的 CMS目錄結(jié)構(gòu)基本能反映它的架構(gòu)。我把這套代碼的目錄抽象成下面這樣你拿到源碼后可以對(duì)照著看cms/ ├── backend/ # 后端服務(wù) │ ├── app/ │ │ ├── models/ # 數(shù)據(jù)模型文章、欄目、用戶、評(píng)論 │ │ ├── controllers/ # 業(yè)務(wù)邏輯增刪改查、權(quán)限判斷 │ │ ├── routes/ # 路由定義前臺(tái)接口 后臺(tái)接口 │ │ ├── middlewares/ # 中間件登錄校驗(yàn)、日志、跨域 │ │ └── utils/ # 工具函數(shù)加密、分頁(yè)、響應(yīng)封裝 │ ├── config/ # 配置文件數(shù)據(jù)庫(kù)、密鑰、端口 │ ├── migrations/ # 數(shù)據(jù)庫(kù)遷移腳本 │ └── seeders/ # 初始數(shù)據(jù)填充 ├── frontend/ # 前端展示層 │ ├── pages/ # 頁(yè)面首頁(yè)、列表頁(yè)、詳情頁(yè) │ ├── components/ # 組件導(dǎo)航、分頁(yè)、評(píng)論框 │ ├── static/ # 靜態(tài)資源CSS、JS、圖片 │ └── api/ # 接口調(diào)用封裝 ├── admin/ # 后臺(tái)管理界面 │ ├── views/ # 后臺(tái)頁(yè)面文章管理、欄目管理 │ └── assets/ # 后臺(tái)專用資源 └── docs/ # 部署與使用說(shuō)明這個(gè)結(jié)構(gòu)的關(guān)鍵在于models、controllers、routes三層分離。models只管數(shù)據(jù)長(zhǎng)什么樣controllers只管業(yè)務(wù)怎么處理routes只管請(qǐng)求往哪走。新手最容易犯的錯(cuò)是把業(yè)務(wù)邏輯寫(xiě)進(jìn)路由里導(dǎo)致后面改一個(gè)功能要翻好幾個(gè)文件。這套代碼把職責(zé)切得比較干凈二次開(kāi)發(fā)時(shí)定位問(wèn)題會(huì)快很多。2.3 數(shù)據(jù)模型設(shè)計(jì)內(nèi)容系統(tǒng)的地基CMS 的數(shù)據(jù)模型決定了它能承載什么內(nèi)容。這套代碼里最核心的四張表是文章表、欄目表、用戶表、評(píng)論表。文章和欄目是一對(duì)多關(guān)系一個(gè)欄目下有多篇文章文章和評(píng)論也是一對(duì)多用戶和文章是一對(duì)多區(qū)分作者和普通訪客。-- 文章表存儲(chǔ)內(nèi)容主體 CREATE TABLE articles ( id INT PRIMARY KEY AUTO_INCREMENT, title VARCHAR(200) NOT NULL, -- 文章標(biāo)題 content TEXT, -- 正文內(nèi)容 category_id INT, -- 所屬欄目 author_id INT, -- 作者用戶ID status TINYINT DEFAULT 0, -- 0草稿 1已發(fā)布 2下架 created_at DATETIME, updated_at DATETIME, FOREIGN KEY (category_id) REFERENCES categories(id), FOREIGN KEY (author_id) REFERENCES users(id) ); -- 欄目表支持無(wú)限級(jí)分類 CREATE TABLE categories ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(100) NOT NULL, parent_id INT DEFAULT 0, -- 0表示頂級(jí)欄目 sort_order INT DEFAULT 0 -- 排序權(quán)重 );這里有兩個(gè)設(shè)計(jì)點(diǎn)值得注意。第一status字段用整數(shù)而不是布爾值因?yàn)閮?nèi)容狀態(tài)往往不止“發(fā)布/未發(fā)布”兩種草稿、待審核、已發(fā)布、已下架是常見(jiàn)需求用整數(shù)擴(kuò)展性更好。第二欄目表用parent_id實(shí)現(xiàn)無(wú)限級(jí)分類這是 CMS 的標(biāo)配做導(dǎo)航菜單和多級(jí)分類時(shí)直接遞歸查詢即可。我一般會(huì)在parent_id上加索引否則欄目一多遞歸查詢會(huì)明顯變慢。3. 核心模塊拆解從請(qǐng)求進(jìn)入到數(shù)據(jù)返回的完整鏈路3.1 路由與中間件請(qǐng)求的第一道關(guān)卡一個(gè)請(qǐng)求打到后端最先經(jīng)過(guò)的是路由和中間件。路由決定這個(gè)請(qǐng)求交給哪個(gè)控制器處理中間件則在控制器之前做統(tǒng)一處理比如登錄校驗(yàn)、參數(shù)過(guò)濾、日志記錄。這套 CMS 把前臺(tái)接口和后臺(tái)接口分開(kāi)注冊(cè)后臺(tái)接口統(tǒng)一掛登錄校驗(yàn)中間件。// routes/index.js —— 路由注冊(cè)示例 const router require(express).Router(); const authMiddleware require(../middlewares/auth); const articleController require(../controllers/article); // 前臺(tái)接口無(wú)需登錄任何人可訪問(wèn) router.get(/api/articles, articleController.list); // 文章列表 router.get(/api/articles/:id, articleController.detail); // 文章詳情 // 后臺(tái)接口必須登錄且校驗(yàn)權(quán)限 router.post(/api/admin/articles, authMiddleware, articleController.create); router.put(/api/admin/articles/:id, authMiddleware, articleController.update); router.delete(/api/admin/articles/:id, authMiddleware, articleController.remove); module.exports router;這段代碼的邏輯很直白前臺(tái)接口只讀后臺(tái)接口才允許寫(xiě)操作而且寫(xiě)操作全部經(jīng)過(guò)authMiddleware。參數(shù)說(shuō)明上:id是路徑參數(shù)表示要操作的具體文章authMiddleware會(huì)從請(qǐng)求頭里取 token校驗(yàn)通過(guò)后把用戶信息掛到req.user上供后續(xù)控制器使用。常見(jiàn)坑是忘記給刪除接口加權(quán)限校驗(yàn)導(dǎo)致任何人構(gòu)造一個(gè)請(qǐng)求就能刪文章這個(gè)在二次開(kāi)發(fā)時(shí)一定要檢查。3.2 文章管理模塊增刪改查的完整實(shí)現(xiàn)文章管理是 CMS 使用頻率最高的模塊。它的核心邏輯是創(chuàng)建時(shí)校驗(yàn)必填字段并綁定作者查詢時(shí)支持分頁(yè)和欄目篩選更新時(shí)校驗(yàn)權(quán)限刪除時(shí)做軟刪除或硬刪除。下面看創(chuàng)建和列表兩個(gè)關(guān)鍵方法。// controllers/article.js —— 文章創(chuàng)建與列表 const Article require(../models/article); // 創(chuàng)建文章 exports.create async (req, res) { const { title, content, category_id, status } req.body; // 必填校驗(yàn)標(biāo)題和欄目不能為空 if (!title || !category_id) { return res.status(400).json({ code: 400, msg: 標(biāo)題和欄目不能為空 }); } const article await Article.create({ title, content, category_id, status: status || 0, // 默認(rèn)存為草稿 author_id: req.user.id // 從登錄態(tài)取作者不信任前端傳值 }); res.json({ code: 0, data: article }); }; // 文章列表支持分頁(yè)和欄目篩選 exports.list async (req, res) { const page parseInt(req.query.page) || 1; const size parseInt(req.query.size) || 10; const categoryId req.query.category_id; const where { status: 1 }; // 前臺(tái)只展示已發(fā)布文章 if (categoryId) where.category_id categoryId; const { rows, count } await Article.findAndCountAll({ where, offset: (page - 1) * size, limit: size, order: [[created_at, DESC]] }); res.json({ code: 0, data: { list: rows, total: count, page, size } }); };創(chuàng)建方法里最關(guān)鍵的一行是author_id: req.user.id。作者信息必須從登錄態(tài)里取絕不能信任前端傳過(guò)來(lái)的author_id否則任何人都能冒充別人發(fā)文章。列表方法里where條件默認(rèn)只查status: 1的已發(fā)布文章這是前臺(tái)接口和后臺(tái)接口的區(qū)別所在——后臺(tái)列表要查所有狀態(tài)前臺(tái)只查已發(fā)布。分頁(yè)用offset和limit實(shí)現(xiàn)findAndCountAll同時(shí)返回當(dāng)前頁(yè)數(shù)據(jù)和總條數(shù)前端拿總條數(shù)算總頁(yè)數(shù)。參數(shù)上page默認(rèn) 1size默認(rèn) 10這兩個(gè)值建議在配置里設(shè)上限防止有人傳size100000把數(shù)據(jù)庫(kù)拖垮。3.3 欄目與導(dǎo)航無(wú)限級(jí)分類的遞歸處理欄目模塊的難點(diǎn)在于無(wú)限級(jí)分類。數(shù)據(jù)庫(kù)里用parent_id存父子關(guān)系但前端需要的是樹(shù)形結(jié)構(gòu)。常見(jiàn)做法是在控制器里一次性查出所有欄目然后在內(nèi)存里組裝成樹(shù)避免遞歸查數(shù)據(jù)庫(kù)。// controllers/category.js —— 欄目樹(shù)組裝 exports.tree async (req, res) { const all await Category.findAll({ order: [[sort_order, ASC]] }); const map {}; const tree []; // 先把所有節(jié)點(diǎn)放進(jìn) map方便按 id 查找 all.forEach(item { map[item.id] { ...item.toJSON(), children: [] }; }); // 再遍歷一次把每個(gè)節(jié)點(diǎn)掛到父節(jié)點(diǎn)下 all.forEach(item { if (item.parent_id 0) { tree.push(map[item.id]); // 頂級(jí)欄目 } else if (map[item.parent_id]) { map[item.parent_id].children.push(map[item.id]); } }); res.json({ code: 0, data: tree }); };這段代碼用兩次遍歷代替遞歸查詢時(shí)間復(fù)雜度是 O(n)欄目數(shù)量上千也能秒出結(jié)果。邏輯說(shuō)明第一次遍歷建立id - 節(jié)點(diǎn)的映射第二次遍歷根據(jù)parent_id把子節(jié)點(diǎn)掛到父節(jié)點(diǎn)的children數(shù)組里。參數(shù)上sort_order控制同級(jí)欄目的排序值越小越靠前。這里有個(gè)容易翻車的點(diǎn)如果數(shù)據(jù)里出現(xiàn)parent_id指向一個(gè)不存在的欄目這個(gè)節(jié)點(diǎn)會(huì)丟失。穩(wěn)妥做法是在第二次遍歷時(shí)加一個(gè)兜底把找不到父節(jié)點(diǎn)的欄目也放進(jìn)頂級(jí)避免數(shù)據(jù)異常導(dǎo)致欄目憑空消失。3.4 用戶權(quán)限登錄態(tài)與角色控制CMS 的權(quán)限通常分兩層一層是登錄校驗(yàn)判斷“你是誰(shuí)”另一層是角色控制判斷“你能干什么”。這套代碼里登錄用 token 機(jī)制角色用簡(jiǎn)單的角色字段區(qū)分管理員和普通作者。// middlewares/auth.js —— 登錄校驗(yàn)與角色判斷 const jwt require(jsonwebtoken); const SECRET process.env.JWT_SECRET || cms-secret; module.exports function auth(req, res, next) { const token req.headers[authorization]?.replace(Bearer , ); if (!token) { return res.status(401).json({ code: 401, msg: 未登錄 }); } try { const payload jwt.verify(token, SECRET); // 解析出用戶信息 req.user payload; // 掛到請(qǐng)求上供后續(xù)使用 next(); } catch (e) { return res.status(401).json({ code: 401, msg: 登錄已過(guò)期 }); } }; // 角色校驗(yàn)只有管理員能刪文章 module.exports.requireAdmin function (req, res, next) { if (req.user.role ! admin) { return res.status(403).json({ code: 403, msg: 無(wú)權(quán)限 }); } next(); };auth中間件負(fù)責(zé)解析 token 并把用戶信息掛到req.userrequireAdmin則在此基礎(chǔ)上判斷角色。參數(shù)上SECRET必須從環(huán)境變量讀取不能硬編碼在代碼里否則 token 可以被偽造。常見(jiàn)坑是把requireAdmin掛在路由上時(shí)順序?qū)懛幢热鐚?xiě)成router.delete(/api/admin/articles/:id, requireAdmin, auth, ...)這樣requireAdmin執(zhí)行時(shí)req.user還不存在直接報(bào)錯(cuò)。正確順序是先auth再requireAdmin。4. 本地運(yùn)行與部署把項(xiàng)目跑起來(lái)的完整步驟4.1 環(huán)境準(zhǔn)備與依賴安裝拿到源碼后第一步是確認(rèn)本地環(huán)境。這套 CMS 需要運(yùn)行時(shí)環(huán)境、數(shù)據(jù)庫(kù)和包管理器三樣?xùn)|西。以 Node.js 技術(shù)棧為例需要 Node.js 16 以上、MySQL 5.7 以上、npm 或 yarn。先檢查版本版本不對(duì)后面會(huì)出各種玄學(xué)問(wèn)題。# 檢查環(huán)境版本 node -v # 建議 16.x 或 18.x mysql --version # 建議 5.7 或 8.0 npm -v # 進(jìn)入后端目錄安裝依賴 cd cms/backend npm install # 進(jìn)入前端目錄安裝依賴 cd ../frontend npm install安裝依賴時(shí)如果卡住常見(jiàn)原因是網(wǎng)絡(luò)源問(wèn)題可以換成國(guó)內(nèi)鏡像源。這一步的坑在于有些依賴包對(duì) Node 版本有要求版本太低會(huì)編譯失敗報(bào)錯(cuò)信息往往是一堆看不懂的 gyp 錯(cuò)誤。遇到這種情況先升級(jí) Node 版本再刪掉node_modules重新裝。4.2 數(shù)據(jù)庫(kù)配置與初始化依賴裝完后要配置數(shù)據(jù)庫(kù)連接并導(dǎo)入初始數(shù)據(jù)。配置文件一般在backend/config/下把數(shù)據(jù)庫(kù)地址、端口、用戶名、密碼、庫(kù)名填進(jìn)去。# config/database.js 中的關(guān)鍵配置 host: 127.0.0.1 port: 3306 database: cms username: root password: 你的密碼 # 創(chuàng)建數(shù)據(jù)庫(kù)并導(dǎo)入表結(jié)構(gòu) mysql -u root -p -e CREATE DATABASE cms DEFAULT CHARSET utf8mb4; npm run migrate # 執(zhí)行遷移腳本建表 npm run seed # 填充初始數(shù)據(jù)創(chuàng)建默認(rèn)管理員這里有個(gè)血淚經(jīng)驗(yàn)數(shù)據(jù)庫(kù)字符集一定要用utf8mb4不要用utf8。utf8在 MySQL 里存不了 emoji 和部分生僻字文章內(nèi)容里一旦出現(xiàn)就會(huì)報(bào)錯(cuò)或亂碼。初始化完成后seed腳本通常會(huì)創(chuàng)建一個(gè)默認(rèn)管理員賬號(hào)賬號(hào)密碼在seeders目錄里能看到第一次登錄后記得改掉。4.3 啟動(dòng)前后臺(tái)并驗(yàn)證數(shù)據(jù)庫(kù)就緒后分別啟動(dòng)后端和前端。后端一般監(jiān)聽(tīng)一個(gè)端口提供接口前端監(jiān)聽(tīng)另一個(gè)端口提供頁(yè)面。# 啟動(dòng)后端在 backend 目錄 npm run dev # 開(kāi)發(fā)模式改代碼自動(dòng)重啟 # 啟動(dòng)前端在 frontend 目錄 npm run serve # 啟動(dòng)前端頁(yè)面 # 啟動(dòng)后臺(tái)管理在 admin 目錄 npm run dev啟動(dòng)后瀏覽器打開(kāi)前端地址應(yīng)該能看到首頁(yè)打開(kāi)后臺(tái)地址應(yīng)該能看到登錄頁(yè)。用初始管理員賬號(hào)登錄試著發(fā)一篇文章再回到前臺(tái)看是否展示出來(lái)。這個(gè)“發(fā)一篇、看一篇”的流程是驗(yàn)證整套系統(tǒng)是否跑通的最快方式。如果前臺(tái)看不到文章先檢查文章?tīng)顟B(tài)是不是草稿前臺(tái)接口默認(rèn)只查已發(fā)布。4.4 生產(chǎn)環(huán)境部署要點(diǎn)本地跑通之后部署到服務(wù)器還有幾件事要做。第一把NODE_ENV設(shè)為production很多框架在這個(gè)模式下會(huì)關(guān)掉調(diào)試信息、開(kāi)啟緩存。第二用進(jìn)程管理工具守護(hù)后端進(jìn)程避免終端一關(guān)服務(wù)就停。第三前端打包成靜態(tài)文件用 Nginx 托管同時(shí)把/api請(qǐng)求反向代理到后端端口。# 前端打包 npm run build # 生成 dist 目錄 # Nginx 配置片段 location / { root /var/www/cms/dist; try_files $uri $uri/ /index.html; # 支持前端路由 } location /api/ { proxy_pass http://127.0.0.1:3000; # 轉(zhuǎn)發(fā)到后端 }try_files這行很關(guān)鍵前端如果是單頁(yè)應(yīng)用刷新非首頁(yè)路由會(huì) 404加上它才能正確回退到index.html。反向代理則解決了跨域問(wèn)題前端請(qǐng)求同域的/api由 Nginx 轉(zhuǎn)發(fā)給后端瀏覽器不會(huì)攔截。5. 避坑與常見(jiàn)問(wèn)題排查5.1 接口返回 401 但明明登錄了現(xiàn)象是后臺(tái)操作時(shí)頻繁提示未登錄但用戶確實(shí)已經(jīng)登錄。原因通常是 token 沒(méi)有正確帶上或者 token 過(guò)期了但前端沒(méi)處理。檢查請(qǐng)求頭里有沒(méi)有Authorization: Bearer xxx再看后端JWT_SECRET是否和簽發(fā)時(shí)一致。如果部署時(shí)換了環(huán)境變量但沒(méi)重啟服務(wù)舊 token 會(huì)全部失效。解決辦法是統(tǒng)一 token 的存取邏輯在請(qǐng)求攔截器里自動(dòng)附加并在收到 401 時(shí)跳轉(zhuǎn)登錄頁(yè)。5.2 文章列表分頁(yè)數(shù)據(jù)對(duì)不上現(xiàn)象是前端顯示的總頁(yè)數(shù)和實(shí)際能翻的頁(yè)數(shù)不一致。原因多半是后端返回的total是篩選前的總數(shù)而列表是篩選后的數(shù)據(jù)。比如按欄目篩選時(shí)total應(yīng)該也是該欄目下的文章數(shù)而不是全站文章數(shù)。檢查findAndCountAll的where條件是否同時(shí)作用于計(jì)數(shù)和查詢。解決方式是把篩選條件抽成一個(gè)變量計(jì)數(shù)和查詢共用。5.3 中文內(nèi)容出現(xiàn)亂碼現(xiàn)象是文章標(biāo)題或正文里的中文變成問(wèn)號(hào)或方塊。原因有三個(gè)可能數(shù)據(jù)庫(kù)字符集不是utf8mb4、連接字符串沒(méi)指定字符集、前端頁(yè)面沒(méi)聲明charsetutf-8。按順序排查先看建庫(kù)語(yǔ)句再看數(shù)據(jù)庫(kù)連接配置里的charset最后看 HTML 的meta標(biāo)簽。三處都對(duì)了亂碼基本不會(huì)出現(xiàn)。5.4 刪除欄目后文章丟失現(xiàn)象是刪掉一個(gè)欄目欄目下的文章也跟著不見(jiàn)了。原因是數(shù)據(jù)庫(kù)外鍵設(shè)置了級(jí)聯(lián)刪除或者控制器里寫(xiě)了連帶刪除邏輯。這在 CMS 里通常是危險(xiǎn)操作。穩(wěn)妥做法是刪除欄目時(shí)先檢查下面有沒(méi)有文章有就阻止刪除并提示先轉(zhuǎn)移文章。如果確實(shí)要?jiǎng)h把文章移到默認(rèn)欄目而不是直接刪數(shù)據(jù)。5.5 前端刷新頁(yè)面 404現(xiàn)象是本地開(kāi)發(fā)正常部署后刷新非首頁(yè)路由就 404。原因是前端路由由 JavaScript 控制服務(wù)器不認(rèn)識(shí)這些路徑直接去找對(duì)應(yīng)文件找不到。解決辦法是在 Nginx 里加try_files $uri $uri/ /index.html讓所有找不到的路徑都回退到入口文件由前端路由接管。6. 二次開(kāi)發(fā)從改一個(gè)字段到加一個(gè)模塊拿到一套能跑的 CMS二次開(kāi)發(fā)的第一步不是急著加功能而是先摸清它的擴(kuò)展點(diǎn)在哪。這套代碼的擴(kuò)展點(diǎn)主要有三個(gè)數(shù)據(jù)模型、控制器、路由。加一個(gè)新功能基本就是在這三處各改一點(diǎn)。先說(shuō)最輕量的改造給文章加一個(gè)字段。比如想給文章加一個(gè)“封面圖”字段需要改三處。第一在models/article里加cover字段定義第二寫(xiě)一個(gè)遷移腳本給數(shù)據(jù)庫(kù)加列別直接手動(dòng)改表否則換環(huán)境就漏了第三在創(chuàng)建和更新的控制器里接收cover參數(shù)。改完重啟服務(wù)后臺(tái)表單里加上對(duì)應(yīng)的輸入框就能用。這種改造半小時(shí)能搞定風(fēng)險(xiǎn)也低。再說(shuō)中等難度的改造加一個(gè)“標(biāo)簽”模塊。標(biāo)簽和文章是多對(duì)多關(guān)系需要新建標(biāo)簽表、文章標(biāo)簽關(guān)聯(lián)表然后在文章控制器里處理標(biāo)簽的綁定和解綁。這里的關(guān)鍵是關(guān)聯(lián)表的操作要用事務(wù)包起來(lái)先刪舊關(guān)聯(lián)再插新關(guān)聯(lián)中間任何一步失敗都回滾否則會(huì)出現(xiàn)文章標(biāo)簽對(duì)不上的臟數(shù)據(jù)。我一般會(huì)把這個(gè)邏輯封裝成一個(gè)syncTags(articleId, tagIds)方法創(chuàng)建和更新時(shí)都調(diào)它避免重復(fù)代碼。最后說(shuō)一個(gè)驗(yàn)證改造是否成功的習(xí)慣。每次改完不要只看頁(yè)面能不能打開(kāi)要按“寫(xiě)一條數(shù)據(jù)、讀一條數(shù)據(jù)、改一條數(shù)據(jù)、刪一條數(shù)據(jù)”走一遍完整鏈路。寫(xiě)的時(shí)候看數(shù)據(jù)庫(kù)里字段對(duì)不對(duì)讀的時(shí)候看前臺(tái)展示對(duì)不對(duì)改的時(shí)候看關(guān)聯(lián)數(shù)據(jù)有沒(méi)有同步刪的時(shí)候看有沒(méi)有留下孤兒數(shù)據(jù)。這套流程走下來(lái)大部分低級(jí)問(wèn)題都能提前發(fā)現(xiàn)。還有一個(gè)容易被忽略的點(diǎn)是接口版本。二次開(kāi)發(fā)時(shí)如果直接改現(xiàn)有接口的返回結(jié)構(gòu)前端可能會(huì)崩。穩(wěn)妥做法是新增接口而不是改舊接口或者在返回里加字段而不是刪字段。前端對(duì)多出來(lái)的字段通常無(wú)感但對(duì)消失的字段一定會(huì)報(bào)錯(cuò)。這個(gè)習(xí)慣能讓你在迭代時(shí)少很多聯(lián)調(diào)扯皮。從那以后我每次拿到一套 CMS 源碼都強(qiáng)制先跑通“發(fā)一篇、看一篇、刪一篇”這條最小鏈路再動(dòng)任何一行代碼。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取