1. 項目概述個人健康菜譜生成系統(tǒng)到底在解決什么問題做這個個人健康菜譜生成系統(tǒng)其實一開始只是想解決我自己每天吃飯的糾結(jié)。上班族做飯最煩的不是不會做而是打開冰箱不知道今天能做什么查菜譜網(wǎng)站又一堆反人類的廣告和“適量鹽”描述。所以我干脆用 Node.js 和 Vue 寫了這個全棧項目前端負(fù)責(zé)點菜、收藏、看詳情后端負(fù)責(zé)按用戶熱量目標(biāo)、口味偏好和忌口條件去生成每日菜譜整套源碼放在一個倉庫里clone 下來就能跑。項目本身不復(fù)雜但麻雀雖小五臟俱全涉及 Vue 組件通信、動態(tài)路由、Node 接口設(shè)計、數(shù)據(jù)庫建模、推薦邏輯和常見部署問題。想練全棧的初學(xué)者、需要做課程設(shè)計的同學(xué)甚至只是想把家里食材利用起來的朋友都能從這套源碼里找到能直接用的東西。這個項目我一直放在本地方便自己改后來整理干凈之后把源碼拎了出來。標(biāo)題里寫“項目源碼”說明重心不只是講概念而是給你一套能跑通的結(jié)構(gòu)。你拿到手之后前端是標(biāo)準(zhǔn)的 Vue 3 Vite 工程后端是 Express SQLite沒有復(fù)雜的中間件和云服務(wù)依賴Windows、macOS、Ubuntu 都試過能跑。我會把從環(huán)境配置、目錄結(jié)構(gòu)、核心接口到前端交互的完整鏈路拆開講重點講那些文檔里不會寫、但實際開發(fā)一定會踩的坑。必須強(qiáng)調(diào)一點系統(tǒng)里的熱量和營養(yǎng)建議只是根據(jù)通用食物成分表估算的用來做日常參考沒問題但不要當(dāng)作醫(yī)療建議。尤其是有慢性病或者孕期飲食需求的朋友拿這套系統(tǒng)當(dāng)工具可以重要決策請咨詢專業(yè)人士。1.1 這個項目適合誰能學(xué)到什么我先說句實話這個項目沒有上微服務(wù)也不搞高并發(fā)。它就是一個典型的中小型全棧項目適合一兩個人維護(hù)。選這個規(guī)模是有意的太復(fù)雜了勸退太簡單了沒干貨。如果你正在學(xué) Vue背了路由、插槽、組件通信的面試題但沒實際項目經(jīng)驗這套源碼能讓你看到這些概念是怎么串起來的如果你剛接觸 Node 后端能學(xué)到如何用 Express 把接口拆得清晰怎么連 SQLite怎么做登錄鑒權(quán)怎么處理菜譜封面圖上傳如果你純粹想解決每天吃什么把示例食材換掉導(dǎo)入自己常買的菜這套系統(tǒng)一樣能服務(wù)你。從學(xué)習(xí)角度看這個項目最大的價值在于“完整”。市面上的教程代碼大多是片段級一個登錄頁講三小時但沒有人告訴你登錄之后怎么跳轉(zhuǎn)、數(shù)據(jù)存在哪里、刷新頁面后 token 怎么恢復(fù)、前端調(diào)接口跨域怎么處理。這些恰恰是源碼項目最值錢的部分。我在整理代碼時特意保留了合理的 TODO 注釋和單元測試目錄就是為了讓后來者能順著思路繼續(xù)擴(kuò)展。1.2 技術(shù)選型為什么是 Node.js Vue 的全棧組合選擇 Node.js 和 Vue不是因為它倆最先進(jìn)而是因為它們最適合這類項目的開發(fā)狀態(tài)。后端用 Node.js意味著前后端都是 JavaScript/TypeScript一個開發(fā)者不用頻繁切換語言心智。尤其是做菜譜推薦這種邏輯數(shù)據(jù)結(jié)構(gòu)是典型的對象數(shù)組操作JS 處理起來比 Java 短得多。前端用 Vue是因為 Vue 的響應(yīng)式系統(tǒng)和單文件組件設(shè)計對中小型項目非常友好模板寫法接近原生 HTML新手拿起來不會像看某些框架那樣一頭霧水。有人會問為什么不直接 Spring Boot Vue不是說不行如果你要交一個“基于 Spring Boot 的商品管理系統(tǒng)”那一套也完全能跑。但在我這個場景里Node.js 的啟動速度、輕量級內(nèi)存占用和 npm 生態(tài)讓我改代碼更爽。Express 路由寫起來幾乎沒有儀式感SQLite 則是零配置的文件數(shù)據(jù)庫整個后端部署起來就是node server.js一條命令。等你把這套邏輯吃透了再用 Spring Boot 重寫也只是換個殼核心推薦和建模思路完全一樣。2. 功能拆解與核心模塊設(shè)計菜譜不是瞎生成的2.1 用戶場景與功能清單這個系統(tǒng)的核心使用場景是這樣的晚上七點到家冰箱里有雞胸肉、西蘭花、豆腐、雞蛋你今天晚餐目標(biāo)熱量是 500 大卡不吃香菜但想吃點辣。系統(tǒng)會從菜譜庫里篩選出所有不包含香菜、主要食材能匹配上的菜再按熱量范圍過濾最后結(jié)合你過去一周點過什么挑出三道熱量合適、口味不重樣的菜推給你每道菜都標(biāo)注食材清單、大致做法和營養(yǎng)素估算。整個功能清單我拆成了兩大塊。用戶側(cè)包括注冊登錄、個人資料維護(hù)、每日熱量目標(biāo)設(shè)置、口味偏好與忌口管理、菜譜瀏覽、菜譜收藏、菜譜詳情查看、菜譜生成歷史。管理側(cè)則簡單一點包含食材庫管理、菜譜維護(hù)、封面圖上傳和生成日志查看。之所以把管理端也塞進(jìn)去是為了讓菜譜數(shù)據(jù)不是寫死在代碼里而是可以從界面維護(hù)這樣對做課程設(shè)計和真實使用都更方便。功能設(shè)計的取舍也值得說。我沒有做社區(qū)評論、點贊、分享這些社交功能不是不會做而是它們會顯著拉長開發(fā)周期。個人健康菜譜系統(tǒng)的重點應(yīng)該放在“生成”和“篩選”上如果生成質(zhì)量不行評論做出來也是空殼。所以我建議你拿到源碼后先把核心鏈路跑通再考慮加不加社交模塊。2.2 數(shù)據(jù)表設(shè)計與菜譜 JSON 結(jié)構(gòu)數(shù)據(jù)庫我用的是 SQLite文件就放在后端目錄的data/health.db里。表結(jié)構(gòu)設(shè)計的核心是食材和菜譜的多對多關(guān)系。一張菜譜由多個食材組成一個食材也可以出現(xiàn)在多道菜里所以不能簡單在菜譜表里塞一個ingredients字段而是要拆三張表recipes、ingredients、recipe_ingredients。下面是簡化后的建表 SQL你可以直接拿去用CREATE TABLE users ( id INTEGER PRIMARY KEY AUTOINCREMENT, username TEXT UNIQUE NOT NULL, password_hash TEXT NOT NULL, target_calories INTEGER DEFAULT 1800, taste_tags TEXT DEFAULT , excluded_ingredients TEXT DEFAULT , created_at TEXT DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE ingredients ( id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT NOT NULL, category TEXT, calory_per_100g REAL DEFAULT 0, unit TEXT DEFAULT g ); CREATE TABLE recipes ( id INTEGER PRIMARY KEY AUTOINCREMENT, title TEXT NOT NULL, description TEXT, steps TEXT, cover_url TEXT, meal_type TEXT, created_at TEXT DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE recipe_ingredients ( id INTEGER PRIMARY KEY AUTOINCREMENT, recipe_id INTEGER NOT NULL, ingredient_id INTEGER NOT NULL, amount_g REAL DEFAULT 100, FOREIGN KEY(recipe_id) REFERENCES recipes(id), FOREIGN KEY(ingredient_id) REFERENCES ingredients(id) ); CREATE TABLE favorites ( id INTEGER PRIMARY KEY AUTOINCREMENT, user_id INTEGER NOT NULL, recipe_id INTEGER NOT NULL, created_at TEXT DEFAULT CURRENT_TIMESTAMP );拆表的直接好處是篩選和統(tǒng)計方便。比如要算出某道菜的熱量只需要把這道菜關(guān)聯(lián)的食材用量乘以對應(yīng)食材的每百克熱量再累加一個JOIN就能搞定。如果不拆表把食材名和用量塞成一個 JSON 字符串那將來做“按食材查詢菜譜”和“熱量估算”會痛苦到懷疑人生。菜譜里的步驟我本來想用富文本編輯后來為了降低復(fù)雜度直接存成Text。前端詳情頁用\n分隔展示效果完全夠用。菜譜的示例數(shù)據(jù)在server/src/data/seed.js里包含了二十多道家常菜和一百個常見食材。你打開這個文件就能看到一道菜的完整 JSON 結(jié)構(gòu){ title: 香煎雞胸肉配西蘭花, description: 高蛋白低脂肪適合減脂期晚餐, mealType: dinner, steps: 1. 雞胸肉用鹽和黑胡椒腌制15分鐘\n2. 平底鍋少油中火每面煎4分鐘\n3. 西蘭花焯水后一起裝盤, ingredients: [ { name: 雞胸肉, amount: 150, unit: g }, { name: 西蘭花, amount: 200, unit: g }, { name: 橄欖油, amount: 5, unit: g } ] }2.3 推薦邏輯的關(guān)鍵標(biāo)簽匹配、排除條件與熱量估算菜譜推薦是這套系統(tǒng)的靈魂我做得很克制沒有用協(xié)同過濾或深度學(xué)習(xí)。原因很簡單個人系統(tǒng)里用戶行為數(shù)據(jù)太少協(xié)同過濾在冷啟動階段基本失效而且算出來的結(jié)果用戶看不懂“為什么推薦這道菜”。我選的是規(guī)則加隨機(jī)權(quán)重的方案推理過程透明代碼量少也容易調(diào)試。整個推薦流程分四步。第一步收集用戶當(dāng)前選擇的食材 ID 列表沒有選擇食材時就默認(rèn)全庫食材可用。第二步根據(jù)用戶資料里的excluded_ingredients排除包含忌口食材的菜譜比如用戶明確寫了“不吃香菜”那所有關(guān)聯(lián)了香菜的菜譜直接過濾掉。第三步計算每道菜的熱量估算值篩掉超出目標(biāo)熱量范圍太多的菜。第四步對候選菜譜按口味偏好標(biāo)簽做加權(quán)隨機(jī)再確保同一道菜一周內(nèi)不重復(fù)推薦。熱量估算的代碼我是單獨抽成函數(shù)的因為這個函數(shù)既會被推薦接口用到也會在菜譜詳情頁展示營養(yǎng)素時用到function estimateCalories(recipeId) { const rows db.prepare( SELECT i.calory_per_100g, ri.amount_g FROM recipe_ingredients ri JOIN ingredients i ON i.id ri.ingredient_id WHERE ri.recipe_id ? ).all(recipeId); const total rows.reduce((sum, row) { return sum (row.calory_per_100g * row.amount_g / 100); }, 0); return Math.round(total); }隨機(jī)加權(quán)的實現(xiàn)不復(fù)雜重點在于不要每次都隨機(jī)得完全一樣。我給每道菜維護(hù)了一個“最近被推薦次數(shù)”字段推薦次數(shù)越少的菜權(quán)重越高這樣用戶不會連續(xù)三天看到同樣的菜。另外口味標(biāo)簽我用的是逗號分隔的簡單字符串比如“辣”“清淡”“高蛋白”匹配時只要做數(shù)組交集判斷即可。這套規(guī)則一開始看著簡陋但實際用下來生成結(jié)果很穩(wěn)定比那些號稱智能但結(jié)果隨機(jī)的方案靠譜得多。3. 后端實現(xiàn)Node.js 接口、數(shù)據(jù)庫與菜譜推薦邏輯3.1 源碼目錄結(jié)構(gòu)先認(rèn)識一下你的項目拿到源碼之后別急著npm install先把目錄結(jié)構(gòu)看清楚。我采用的是前后端分離但放在同一個倉庫里的結(jié)構(gòu)避免了維護(hù)兩個 Git 倉庫的麻煩health-recipe-system/ ├── server/ │ ├── src/ │ │ ├── routes/ # 接口路由 │ │ │ ├── auth.js │ │ │ ├── recipes.js │ │ │ ├── ingredients.js │ │ │ └── favorites.js │ │ ├── middlewares/ │ │ │ └── authMiddleware.js │ │ ├── db/ │ │ │ ├── index.js │ │ │ └── seed.js │ │ ├── utils/ │ │ │ └── calorie.js │ │ └── app.js │ ├── data/ # SQLite 數(shù)據(jù)庫文件目錄 │ ├── uploads/ # 菜譜封面圖上傳目錄 │ ├── .env # 環(huán)境變量 │ └── package.json ├── web/ │ ├── src/ │ │ ├── views/ # 頁面組件 │ │ ├── components/ # 業(yè)務(wù)組件 │ │ ├── stores/ # Pinia 狀態(tài) │ │ ├── router/ # 路由配置 │ │ ├── api/ # axios 封裝 │ │ └── App.vue │ └── package.json └── README.mdserver/src/app.js是后端入口web/src/main.js是前端入口。把數(shù)據(jù)和代碼分離的好處是備份數(shù)據(jù)庫只需要拷一個data目錄。uploads目錄記得要在.gitignore里忽略掉不然傳幾張菜譜圖倉庫就變得很臃腫。3.2 Node.js 環(huán)境準(zhǔn)備與 npm 配置這一步看著簡單但我見過太多人卡在這里。先說 Node.js 版本項目建議用 LTS 版本目前推薦 18 以上20 也行不要用那種還在奇數(shù)版本號的嘗鮮版。Vite 在舊版 Node 上會直接報錯而且報錯信息很迷惑你排查半天發(fā)現(xiàn)是 Node 版本太老。安裝完成后務(wù)必在命令行里執(zhí)行兩個命令驗證node -v npm -v如果提示找不到命令不是沒裝好就是安裝時沒有勾選“Add to PATH”。Windows 下最穩(wěn)妥的方式是重新運行安裝包選擇修改安裝并勾選 PATH 選項。macOS 用戶我建議用 Homebrew 安裝Ubuntu 用戶可以apt install nodejs npm但裝完記得檢查版本有些發(fā)行版自帶版本偏舊。npm 裝依賴慢是國內(nèi)老生常談的問題我習(xí)慣先配鏡像源npm config set registry https://registry.npmmirror.com這行命令改的是 npm 全局配置之后所有項目的依賴下載都會走鏡像。如果你在公司網(wǎng)絡(luò)環(huán)境可能還需要額外設(shè)置代理。我另外建議不要全局安裝一堆工具用npx跑腳手架命令更干凈比如后面創(chuàng)建 Vue 項目直接npm create vuelatest就不會污染全局包。3.3 后端核心代碼服務(wù)入口和健康檢查接口后端入口文件app.js本身不長核心就是初始化 Express、掛載中間件、注冊路由const express require(express); const cors require(cors); const path require(path); const { initDB } require(./db); const authRoutes require(./routes/auth); const recipeRoutes require(./routes/recipes); const ingredientRoutes require(./routes/ingredients); const favoriteRoutes require(./routes/favorites); const app express(); app.use(cors()); app.use(express.json()); app.use(/uploads, express.static(path.join(__dirname, ../uploads))); app.use(/api/auth, authRoutes); app.use(/api/recipes, recipeRoutes); app.use(/api/ingredients, ingredientRoutes); app.use(/api/favorites, favoriteRoutes); app.get(/api/health, (req, res) { res.json({ code: 0, data: { uptime: process.uptime(), time: new Date() } }); }); const PORT process.env.PORT || 3000; initDB().then(() { app.listen(PORT, () { console.log([server] running at http://localhost:${PORT}); }); });注意express.json()這個中間件不能少否則后端收不到前端傳過來的 JSON 請求體。cors()在本地開發(fā)時必須掛否則前端在localhost:5173調(diào)localhost:3000接口會被瀏覽器攔截。接口返回格式我統(tǒng)一用{ code, data, message }前端 axios 攔截器只要統(tǒng)一解析一次就行。這個習(xí)慣看起來不起眼但能讓前端錯誤處理代碼減少一大半。項目里的數(shù)據(jù)庫操作我用了better-sqlite3這個庫它是同步 API寫起來比sqlite3的異步回調(diào)舒服很多。初始化數(shù)據(jù)庫時如果表不存在就自動建表如果食材表是空的就執(zhí)行種子數(shù)據(jù)導(dǎo)入這樣任何機(jī)器上 clone 下來運行都是即跑即用。3.4 菜譜生成接口的實現(xiàn)細(xì)節(jié)菜譜生成是核心接口路徑是POST /api/recipes/generate。請求體會接收用戶這次選擇的食材 ID 數(shù)組、餐次類型、目標(biāo)熱量等參數(shù)。我簡化后的核心邏輯如下router.post(/generate, authMiddleware, (req, res) { const { ingredientIds [], mealType, targetCalories } req.body; const user req.user; // 查詢所有菜譜并關(guān)聯(lián)出食材列表和熱量 const recipes db.prepare( SELECT r.*, GROUP_CONCAT(i.name) as ingredient_names FROM recipes r LEFT JOIN recipe_ingredients ri ON ri.recipe_id r.id LEFT JOIN ingredients i ON i.id ri.ingredient_id GROUP BY r.id ).all(); const excluded parseList(user.excluded_ingredients); // 第一步排除忌口 let candidates recipes.filter(recipe { const names recipe.ingredient_names ? recipe.ingredient_names.split(,) : []; return !excluded.some(item names.includes(item)); }); // 第二步如果指定了食材要求菜譜必須包含其中至少一個 if (ingredientIds.length 0) { candidates candidates.filter(recipe { return recipe.ingredient_names ingredientIds.some(id recipe.ingredient_names.includes(id)); }); } // 第三步熱量過濾 const range targetCalories || user.target_calories || 1800; candidates candidates.filter(recipe { const cal estimateCalories(recipe.id); return cal range * 0.6 cal range * 1.2; }); // 第四步加權(quán)隨機(jī)選三道一周內(nèi)推薦過的權(quán)重減半 const weighted candidates.map(recipe { const recentCount getRecentRecommendCount(recipe.id, user.id); return { recipe, weight: Math.max(0.2, 1 - recentCount * 0.3) }; }); // 簡單加權(quán)隨機(jī) const selected weighted .sort(() Math.random() - 0.5) .slice(0, Math.min(3, weighted.length)) .map(item item.recipe); res.json({ code: 0, data: selected }); });這段代碼我特意寫得偏教學(xué)化實際源碼里會再封裝幾個函數(shù)。你可能會問為什么先查出所有菜譜再在內(nèi)存里過濾因為示例數(shù)據(jù)量只有幾十條這樣做最簡單且容易理解。如果以后菜譜庫上萬條就改成在 SQL 里做排除和篩選按食材表JOIN后加WHERE條件。個人項目優(yōu)先保證可讀性性能問題等真遇到了再優(yōu)化這是我一直堅持的原則。還有個細(xì)節(jié)必須返回給前端熱量估算值否則前端卡片上沒數(shù)字可顯示。我在返回前給每道菜補(bǔ)充了calorie、protein、fat字段計算方式基于recipe_ingredients的用量和食材營養(yǎng)素表。這些營養(yǎng)字段即便不準(zhǔn)確也比沒有強(qiáng)因為它能給用戶一種“被認(rèn)真對待”的感覺。接口里還寫了生成記錄記錄誰在什么時間請求了哪些菜譜方便后續(xù)做“最近推薦不重復(fù)”的判斷。4. 前端實現(xiàn)Vue 頁面、路由與交互細(xì)節(jié)4.1 用 Vite 創(chuàng)建 Vue 3 項目并安裝依賴前端我選擇 Vue 3 Vite 的組合。Vite 開發(fā)服務(wù)器啟動非常快修改代碼后熱更新幾乎是秒級比老牌的 vue-cli 體驗好太多。創(chuàng)建項目的命令很簡單但要注意npm create vuelatest運行后會交互式問你要不要 TypeScript、Router、Pinia 等我建議全部選是尤其是 Router 和 Pinia后面會用到。如果不想交互可以加--default參數(shù)。創(chuàng)建完成后進(jìn)入前端目錄安裝基礎(chǔ)依賴cd web npm install npm install axios vue-router4 pinia npm run dev這里有個容易踩的坑Vue 3 對應(yīng)的是vue-router4不是老項目的vue-router3。如果安裝時沒寫版本號npm 默認(rèn)給你裝最新的4一般沒問題但如果你之前項目里殘留老版本會出現(xiàn)路由組件渲染不出來的怪問題。我遇到過一次最后是清掉node_modules和package-lock.json重新安裝才解決。裝依賴的時候如果控制臺刷出大量npm WARN先別慌只要npm run dev能跑起來就說明依賴關(guān)系沒問題。4.2 頁面路由與整體布局這個項目的頁面不多我按業(yè)務(wù)劃分了五個主要視圖首頁、菜譜生成頁、菜譜詳情頁、收藏頁、登錄注冊頁。路由配置放在src/router/index.js核心代碼如下import { createRouter, createWebHistory } from vue-router; const router createRouter({ history: createWebHistory(), routes: [ { path: /, name: home, component: () import(/views/HomePage.vue) }, { path: /generate, name: generate, component: () import(/views/GeneratePage.vue) }, { path: /recipes/:id, name: recipe-detail, component: () import(/views/RecipeDetailPage.vue) }, { path: /favorites, name: favorites, component: () import(/views/FavoritesPage.vue) }, { path: /login, name: login, component: () import(/views/LoginPage.vue) }, ] }); router.beforeEach((to, from, next) { const token localStorage.getItem(token); if (to.meta.requiresAuth !token) { next(/login); } else { next(); } }); export default router;我用了createWebHistory而不是createWebHashHistory地址欄看起來干凈。但代價是部署到 Nginx 時要做 try_files 重寫這個后面講部署會提到。路由懶加載也是從這版才加上的之前用靜態(tài) import 把整個頁面都打到一個包里首屏加載很慢。改成() import()之后每個頁面單獨分包體驗提升明顯。beforeEach路由守衛(wèi)里做了簡單的登錄攔截收藏頁和生成歷史頁需要登錄才能訪問這個對真實項目是剛需。整體布局我放在App.vue里頂部一個導(dǎo)航欄下面放router-view /。導(dǎo)航欄根據(jù)登錄狀態(tài)顯示“登錄/注冊”還是“退出登錄”用 Pinia 里的用戶狀態(tài)控制。這種全局布局方式簡單改一個文件就能控制所有頁面的公共殼子。4.3 菜譜生成頁表單校驗、請求狀態(tài)和卡片展示菜譜生成頁是這個項目里交互最復(fù)雜的一頁。左半部分是篩選表單右半部分是生成結(jié)果卡片列表。頁面模板骨架大致是這樣template div classgenerate-page form submit.preventhandleGenerate h3告訴我你的條件/h3 label餐次類型/label select v-modelform.mealType option valuebreakfast早餐/option option valuelunch午餐/option option valuedinner晚餐/option /select label目標(biāo)熱量大卡/label input typenumber v-model.numberform.targetCalories min300 max3000 / label可選食材/label IngredientSelector v-modelform.ingredientIds / button typesubmit :disabledloading {{ loading ? 生成中... : 生成菜譜 }} /button /form div classresult-area RecipeCard v-forrecipe in recipes :keyrecipe.id :reciperecipe collecthandleCollect / /div /div /template這里有兩個可以展開說的點。第一個是v-model.number修飾符它能把輸入框里的字符串轉(zhuǎn)成數(shù)字避免你在判斷targetCalories 0時踩“空字符串參與比較”的坑。第二個是IngredientSelector組件用v-model雙向綁定選中食材 ID 數(shù)組這涉及到子組件里如何觸發(fā)更新。我在這個組件里封裝了一個多選網(wǎng)格點擊食材卡片時切換選中狀態(tài)再通過emit(update:modelValue, newValue)把值傳回父組件。把這套機(jī)制搞清楚Vue 的組件通信基本就入門了。請求狀態(tài)處理也很重要。點擊生成后按鈕要置灰并顯示“生成中”防止用戶重復(fù)提交。請求失敗要區(qū)分超時和接口報錯我在 axios 攔截器里統(tǒng)一處理了錯誤提示。拿到結(jié)果后不要直接覆蓋整個列表先用 loading 遮罩擋住舊內(nèi)容等新結(jié)果回來再替換避免界面閃動。這個小細(xì)節(jié)對體驗影響非常大我最初沒做結(jié)果每次生成時頁面瘋狂跳動觀感很差。4.4 收藏功能與組件復(fù)用技巧收藏功能我用了兩個端配合后端favorites表記錄用戶和菜譜的關(guān)聯(lián)關(guān)系前端 Pinia store 管理當(dāng)前頁面的收藏狀態(tài)。點擊收藏按鈕時先判斷是否登錄沒登錄就跳轉(zhuǎn)登錄頁登錄了就調(diào)接口。收藏成功后把按鈕狀態(tài)切換成實心再次點擊則取消收藏。這套交互在整個系統(tǒng)里會出現(xiàn)在菜譜卡片、詳情頁和收藏頁三處所以我把收藏按鈕抽成了獨立組件CollectButton避免在三個頁面里復(fù)制粘貼三份一樣的邏輯。CollectButton組件只接收recipeId和initialCollected兩個 props內(nèi)部維護(hù)自己的collected狀態(tài)。但真實場景里詳情頁收藏后返回列表頁希望收藏狀態(tài)同步更新這就要用到 Pinia store 來共享狀態(tài)。我把收藏的菜譜 ID 集合放在 store 里任何組件提交收藏操作都會修改這個集合其他組件自然響應(yīng)更新。這個方法比事件總線干凈也比 localStorage 手動同步靠譜。關(guān)于插槽我在RecipeCard組件里用了一個技巧。菜譜卡片在不同頁面展示的重點不一樣生成頁要顯示熱量和收藏按鈕首頁要顯示推薦理由收藏頁要顯示收藏時間。如果這些差異全用 props 塞進(jìn)去組件會變得很臃腫。我讓RecipeCard只負(fù)責(zé)渲染標(biāo)題、封面和描述然后把可替換區(qū)域開放成插槽div classrecipe-card img :srcrecipe.coverUrl / div classcard-body h4{{ recipe.title }}/h4 p{{ recipe.description }}/p slot namefooter :reciperecipe span默認(rèn)底部內(nèi)容/span /slot /div /div父組件使用的時候向具名插槽footer里塞不同的按鈕和時間信息不用改RecipeCard本身的代碼。很多初學(xué)者會覺得插槽是面試題里的抽象概念看到這里應(yīng)該能明白它就是給組件留的“自定義區(qū)域占位符”讓同一張卡片在不同上下文里呈現(xiàn)出不同細(xì)節(jié)。這套源碼里插槽用得不多但RecipeCard這一個案例已經(jīng)足夠看懂。5. 部署運行與高頻問題排查讓源碼在你的電腦上跑起來5.1 本地啟動和打包部署流程本地跑起來只需要兩個終端窗口。第一個窗口啟動后端cd server npm install npm run dev第二個窗口啟動前端cd web npm install npm run dev前端默認(rèn)跑在5173端口后端跑在3000。我在 Vite 配置文件里加了開發(fā)代理把所有/api請求轉(zhuǎn)發(fā)到http://localhost:3000這樣前端頁面里請求地址不用寫完整的后端地址也繞開了開發(fā)環(huán)境跨域問題。配置片段如下// vite.config.js export default defineConfig({ server: { port: 5173, proxy: { /api: { target: http://localhost:3000, changeOrigin: true } } } });如果你想把項目部署到服務(wù)器我比較推薦的做法是前端先npm run build打包出dist目錄然后讓 Express 托管靜態(tài)文件。具體說在后端app.js里加幾行代碼當(dāng)路由匹配不到/api接口時直接讀取前端dist下的文件返回。這樣整個應(yīng)用只需要啟動一個 Node 進(jìn)程不太需要單獨配 Nginx。對于個人項目演示場景這是最省事的方式。如果你更喜歡標(biāo)準(zhǔn)的 Nginx 部署那就讓前端靜態(tài)文件交給 Nginx后端接口仍然由 Node 承擔(dān)。需要注意兩個點一是 Nginx 里要配置將/api轉(zhuǎn)發(fā)到后端端口二是前端使用的createWebHistory模式要求所有未知路徑都重寫到index.html否則刷新詳情頁會 404。我也見過有人把這個 Vue 項目打包后直接丟進(jìn) Spring Boot 的static目錄思路一樣只要處理好接口地址和跨域就行。5.2 高頻報錯速查表這部分內(nèi)容是我自己踩坑和幫朋友調(diào)項目時總結(jié)出來的包含幾個高頻問題按現(xiàn)象、原因和解決方式整理成了表格錯誤現(xiàn)象原因解決方式npm : 無法加載文件 ... npm.ps1因為在此系統(tǒng)上禁止運行腳本PowerShell 默認(rèn)執(zhí)行策略限制腳本運行以管理員身份打開 PowerShell執(zhí)行Set-ExecutionPolicy RemoteSigned不想改系統(tǒng)策略就直接用 CMD 運行 npmnode: not found或node 不是內(nèi)部或外部命令Node.js 未安裝成功或沒有加入 PATH重新安裝 Node.js 并勾選 Add to PATH安裝完成后重啟終端前端啟動后頁面能開但接口報 404開發(fā)代理沒生效或后端沒啟動確認(rèn)后端日志有輸出檢查vite.config.js的 proxy 配置請求路徑必須帶/api前綴請求提示 CORS 錯誤后端沒開跨域或代理配置沒覆蓋當(dāng)前請求后端掛載cors()中間件若用了代理請求地址不要寫http://localhost:3000直連SQLite 報 database is locked多個進(jìn)程同時寫數(shù)據(jù)庫文件開發(fā)時不要同時開兩個后端進(jìn)程生產(chǎn)環(huán)境可切換 PostgreSQL/MySQLCannot find module better-sqlite3原生模塊編譯失敗或沒正確安裝先刪除node_modules再執(zhí)行npm install還是不行就檢查 Node 版本是否過新退回 LTS菜譜封面圖片上傳后訪問 404圖片沒有放在uploads目錄或路徑缺少/uploads靜態(tài)服務(wù)檢查app.js里express.static配置上傳目錄必須存在并有寫入權(quán)限中文亂碼數(shù)據(jù)庫文件編碼或返回頭缺少 charsetSQLite 本身是 UTF-8亂碼一般發(fā)生在 Windows 老終端建議用 VS Code 終端運行這些報錯里最顯眼的就是 npm.ps1 禁止運行腳本。說實話我第一次遇到也懵好不容易裝好 Node運行npm -v卻報錯。后來查清楚這是 Windows PowerShell 為了保護(hù)系統(tǒng)默認(rèn)不讓執(zhí)行.ps1腳本。我自己的處理方式是只在當(dāng)前用戶范圍放寬執(zhí)行策略不去改系統(tǒng)級策略Set-ExecutionPolicy -Scope CurrentUser RemoteSigned執(zhí)行后重新打開終端就好。如果你在公司電腦上受組策略限制改不了就老老實實用 CMD 或 Git Bash一樣能跑 npm這也是完全合規(guī)的方案。5.3 關(guān)于這套源碼我的后續(xù)規(guī)劃和個人建議源碼我還會繼續(xù)迭代但方向不是加更多炫酷功能而是把推薦質(zhì)量做得更細(xì)。比如現(xiàn)在熱量估算是基于靜態(tài)食材表以后我想接入更完整的營養(yǎng)成分?jǐn)?shù)據(jù)庫把鹽、油、糖的用量也納入計算。另一個方向是記錄用戶對生成結(jié)果的反饋點了“喜歡”還是“換一道”這些反饋數(shù)據(jù)積累起來后規(guī)則系統(tǒng)能做得更智能。對于想拿這套源碼做課程設(shè)計或者畢業(yè)設(shè)計的同學(xué)我強(qiáng)烈建議你在“生成歷史”和“用戶反饋”上多下功夫這兩塊最容易做出差異化和工作量證明。最后分享一個我實際改代碼時的小技巧先把所有菜譜數(shù)據(jù)導(dǎo)出來把你自己日常會做的十道菜加進(jìn)去然后生成一次看看推薦結(jié)果。這一步能讓你迅速理解推薦規(guī)則對結(jié)果的真實影響也會發(fā)現(xiàn)一些數(shù)據(jù)問題比如某道菜熱量算出來不合理。數(shù)據(jù)是這類系統(tǒng)的地基算法再花哨食材用量錄入不準(zhǔn)也沒用。你把它當(dāng)成一個“幫自己做飯的助手”來打磨就能真正用好這套代碼。