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