我一直觉得，学Web开发最怕的就是“学了一堆技术但拼不出一个完整的东西”。Django会一点，Vue也看过教程，真要独立从零搭一个能跑通前后端的网站，很多人心里还是犯嘀咕的。所以这次我想拿一个非常典型的案例——苏菜与健康分享网站，完整拆一遍从需求到落地的全过程。这个项目用的是Vue + Python，后端有Django和Flask两条路线可选，开发工具是Pycharm。不管你是拿它练手、做课程设计，还是想积累一个完整的全栈作品，这篇内容都应该能帮你在思路上省不少力气。
1. 内容整体设计与思路拆解
1.1 核心需求解析：这到底是一个什么网站
先说清楚这个项目到底在做什么。表面上看，它是一个美食分享站，核心是苏菜。但“健康”两个字才是真正决定功能架构的分水岭。如果只是做菜谱展示，那跟普通的菜谱网站没有区别，难点全在菜品数据的管理和展示上。一旦加入“健康”，就意味着每一道菜需要关联营养信息、适宜人群、饮食禁忌、食材功效这些内容。这不是拍脑袋定的，是在真实开发中反复做需求梳理之后得出的结论。
我当时拿到这个需求，第一件事不是写代码，而是把用户故事列出来。典型用户有三类：第一类是普通访客，想看看今天吃什么，想了解苏菜的文化背景，想知道某道菜的热量高不高；第二类是注册用户，会收藏菜品、提交自己的健康饮食笔记、参与评论；第三类是后台管理员，负责菜品录入、营养数据维护、用户管理。这三类角色对应出来的功能模块其实就很清晰了：菜品浏览与检索、菜品详情（含营养分析）、用户系统、收藏功能、内容管理后台。
一个常见的坑是新手上来就把所有功能堆在首页，结果代码写到最后自己都理不清楚。正确的拆法是按业务域划分。每个业务域内部再细分接口。比如菜品域拆成列表接口、详情接口、分类过滤接口；用户域拆成注册、登录、收藏、个人信息等。这样前后端对接的时候，接口清单一目了然，不会出现“前端要什么、后端不知道给什么”的尴尬。
从场景角度来说，这个网站的使用路径是：用户进入首页，通过分类或关键词找到感兴趣的菜，点进详情看做法和营养成分，喜欢就收藏，下次打开个人中心可以快速找到。管理员则定期录入新菜、修正营养数据、审核用户发布的笔记。整条链路闭环之后，这个项目才算真正“跑通”了。
1.2 技术方案选型：为什么是Vue + Python，Django与Flask怎么选
项目标题里同时出现了Django和flask，这不代表两个都要用，而是给了一个选型空间。很多人纠结到底学哪个，其实这两者在真实工程中的定位差异很大，搞清楚这个差异比记住某个框架的API重要得多。
Django走的是“全家桶”路线，ORM、Admin后台、表单处理、认证系统全套内置。它的优势是开发效率高、规范性强，适合业务逻辑复杂的项目。我们这个苏菜健康分享站，最大的复杂性不在页面，而在数据关系。食材和菜品的多对多关系、菜品和营养指标的关联、用户收藏记录、评论的层级结构，这些用Django内置的ORM来建模非常顺手。尤其是Django Admin，稍微配置一下就能得到一个可用度极高的数据后台，管理员录菜的时候不太需要额外的技术培训。
Flask的优势则在于轻量、灵活、自由度极高。如果你是一个习惯自己控制每个细节的开发者，用Flask + SQLAlchemy + 自定义扩展的组合，也能做得很舒服。代价是所有基础能力都需要自己组装，学习成本从框架层转移到了架构设计层。对于新人来说，Flask的“自由”反而容易让人迷失。
我给一个非常实操的建议：如果你的目标是把项目快速跑通、同时学到更多开箱即用的工程规范，选Django；如果你已经有了一定的项目经验，想练一练如何手写认证逻辑、自己组织项目结构、按需定制插件体系，选Flask。这两种选择最后出来的项目质量都可以很高，但开发过程中的心态体验完全不同。
前端选Vue 2还是Vue 3也要提前定。Vue 3的Composition API写起来逻辑更聚合，配合Vite构建速度也快得多；Vue 2则生态更稳定、教程更多。如果你之前只跟过Vue 2的教程，这次项目用Vue 2也不会过时，毕竟真实企业里存量项目还有很多在用。我自己做这个项目时用的Vue 3，组件用选项式API写的，主要原因是为了兼顾组合式的灵活和文档的通用性。
2. 数据库设计与核心功能模块拆解
2.1 数据模型的建立：菜品、食材、营养、收藏、评论
数据库设计是整个项目的地基。我见过太多人上来就建一张大表，把菜名、做法、食材全部塞进一个字段，结果程序跑起来之后想加一个“按食材查询”的功能，发现数据根本没法拆。合理的设计是这样的。
菜品表先定下来，最核心的字段包括：菜名、分类、简介、详细做法、封面图路径、口味标签、历史渊源。注意，历史渊源这个字段很多新手会漏掉。苏菜不只是菜，它背后有文化故事。做健康分享站，菜品背后的文化背书本身就很有价值，这个字段在后面前端页面上支撑“苏菜文化”板块非常有用。
食材表单独建一张。食材和菜品是多对多关系，一张关联表把两者的关系打通。食材本身的字段不要只存名字，还要存功效标签、适用季节、主要营养构成。这样做的好处是，以后想做“按食材找菜谱”或“根据时令推荐”功能，直接在食材表上操作就行，不需要对菜谱表做大规模改动。
营养信息不一定要单独建表，如果只是给每道菜存热量、蛋白质、脂肪、碳水化合物、膳食纤维这几项，直接挂在菜品表上就行。但如果想做更细的每日营养摄入分析，建议单独建营养表，用外键关联菜品，同时记录每100克或每份的数据基准。
用户和收藏的设计相对简单。用户表可以用Django默认的User再扩展一个Profile表，存昵称、头像、个人饮食偏好和健康目标。收藏表就是用户ID加菜品ID，再存一个收藏时间和备注即可。评论表需要稍微想清楚一点，如果只做一级评论，直接用外键关联用户和菜品就能解决；如果后续想做楼中楼，那就要设计一个parent_id字段指向父评论。
这套模型跑起来之后，整个后台的逻辑就非常清晰了。刚开始不需要追求把所有表一次建完美，但要保证核心关系不搞错，尤其是多对多关系不要塞在一张表里。
2.2 前后端交互设计：接口清单与数据流
前后端分离的项目，接口设计就是双方的“契约”。我的习惯是第一版先把接口清单写出来，发给团队（或者写给未来的自己）确认后再动代码。这样做能大幅减少联调阶段的返工。
针对这个苏菜健康分享站，我整理了一套可以拿来就用的接口方案。用户侧最基础的是注册和登录。登录这里要重点说明一下，尽量不要用Django默认的session那一套直接对接Vue前端，而是用rest_framework_simplejwt做JSON Web Token认证，前端拿到token存到localStorage里，每次请求在请求头带上Authorization字段。这套流程在前后端分离项目中非常标准，学一次之后换任何项目都能复用。
菜品相关的接口是重头戏。列表接口要支持分页、按分类筛选、按关键词搜索、按热量排序；详情接口返回菜品基本信息、关联食材、营养数据和评论列表。这里有一个特别值得说的设计点：详情页的评论不要单独请求一次，而是在详情接口里附带评论的前几页数据，前端点“加载更多”时才调专门的评论接口。这样首屏体验更流畅，接口数量也不至于过多。
收藏接口需要登录权限，这是JWT发挥作用的地方。收藏和取消收藏可以用同一个接口，通过请求类型区分动作；也可以拆成两个接口。我偏向拆成两个，代码里逻辑更清晰，前端调用时也不用频繁判断当前状态。个人中心还需要一个“我的收藏列表”接口，直接联表查询当前用户的收藏记录，返回菜品封面和简要信息。
整个数据流跑通的标志是：前端任意操作，都能在后端找到对应接口；后端任意接口，都能在前端找到调用入口。检查这一点，就能确认项目结构是正确的。
2.3 关键页面与数据展示方案
页面这块不用贪多，但每一个都要打磨到位。首页是整个项目留给用户的第一印象，我设计了三个核心区块：顶部是分类导航，按热菜、凉菜、汤羹、点心等分类展示，可以快速进入分类列表页；中间是“应季健康菜”推荐区，调用后端接口按季节标签过滤菜品；底部是“今日健康知识”卡片，放几条饮食建议，数据可以手工维护在后台。这三个区块前后端各司其职，看起来简单，但已经覆盖了一个美食站最核心的信息层级。
菜品列表页的核心是筛选器和卡片布局。筛选器放在页面左侧，支持分类、口味、热量范围三个维度；卡片展示菜品图、菜名、简介、热量的简短信息和一个“查看详情”按钮。这里有一个优化点值得提：分页不要只给上一页下一页，要支持页码跳转，同时把筛选条件反映在URL参数上，这样用户刷新后筛选状态还在，分享链接时对方也能看到同样内容。
详情页的展示层次是这样的：最上方是菜品大图、菜名、口味标签和收藏按钮；接下来是“食材与功效”区，以表格形式列出每种食材的营养贡献；再往下是“健康分析”卡片，用可视化条展示蛋白质、脂肪、碳水占比，这里前端可以直接用CSS实现简单的比例条，不需要额外引图表库，减少打包体积；最后是做法步骤和评论区域，做法步骤用带序号的段落，评论支持点赞和按时间排序。
个人中心页面在展示收藏列表的同时，加入一个简单的“饮食偏好”设置。用户在注册时可以选口味偏好，比如清淡、微辣、偏甜等，个人中心会根据偏好推荐一批放宽筛选的菜品列表。这个小功能不需要太复杂的算法，后端按标签匹配就行，但用户体验提升非常明显。
3. 实操过程与核心环节实现
3.1 从零初始化Django后端项目
Django后端的初始化过程，说难不难，但很多人会在不知不觉中把项目结构写乱。我的做法比较固定：先建虚拟环境，然后创建Django项目和一个独立的app来管核心业务。
首先在Pycharm里新建项目目录，打开终端创建虚拟环境：
python -m venv venv虚拟环境激活看着简单，但Windows和Mac命令不太一样，这个细节容易浪费新手时间。Windows环境激活命令是：
venv\Scripts\activateMac或Linux环境是：
source venv/bin/activate进入虚拟环境后，安装依赖。这里没有必要一次把所有的库都装齐，根据功能逐步添加即可。基础装Django、djangorestframework、django-cors-headers和simplejwt：
pip install django djangorestframework django-cors-headers djangorestframework-simplejwt然后创建项目和一个app：
django-admin startproject sushi_health . python manage.py startapp dishes注意项目名用“sushi_health”并不是说苏菜是日料，只是为了代码里不出现中文导致的编码问题，实际项目中的模块名和业务名的关联要清晰。app名称“dishes”稍微泛了一点，但能覆盖菜品、食材、营养三块业务，用起来反而顺手。
接下来配置settings.py。首先把rest_framework和corsheaders加入INSTALLED_APPS；然后做中文支持，把LANGUAGE_CODE改成zh-hans，TIME_ZONE改成Asia/Shanghai；最后配置CORS，允许本地开发地址访问：
CORS_ALLOWED_ORIGINS = [ "http://localhost:5173", "http://127.0.0.1:5173", ]到这里，Django的后端骨架已经搭起来了。这个环节最容易被忽略的是CORS配置，前后端分离的跨域问题不提前处理，后面前端所有请求都会报错，而且报错信息非常容易让人误解。
3.2 Django模型实现与数据库迁移
模型是后端最核心的模块。我在这个项目中把模型文件拆成三块：models.py里只放菜品和分类相关的内容，食材单独写一个ingredients.py，用户扩展和收藏相关的逻辑放到profile.py。这样文件多了，但维护起来非常舒服。
先说菜品模型。菜名、分类、做法、口味等字段按需求建好，关键点在于图片的处理。开发阶段图片可以只存URL字符串，不用实际管理上传文件。这样省了配置媒体目录的麻烦，前端也能直接通过URL访问图片，适合快速跑通流程。
再写食材模型，建立菜品和食材多对多关系时加一个中间模型，这样每一个关联关系上还可以额外记录用量，让数据逻辑更完整。代码如下：
from django.db import models class Ingredient(models.Model): name = models.CharField(max_length=100, unique=True) efficacy = models.CharField(max_length=200, blank=True) seasonal = models.CharField(max_length=20, blank=True) def __str__(self): return self.name class Dish(models.Model): name = models.CharField(max_length=100) category = models.CharField(max_length=50) cuisine = models.CharField(max_length=50, default="苏菜") description = models.TextField() steps = models.TextField() cover_image = models.URLField(blank=True) calories = models.FloatField(default=0) protein = models.FloatField(default=0) fat = models.FloatField(default=0) carbs = models.FloatField(default=0) taste = models.CharField(max_length=50, blank=True) ingredients = models.ManyToManyField(Ingredient, through="DishIngredient") class DishIngredient(models.Model): dish = models.ForeignKey(Dish, on_delete=models.CASCADE) ingredient = models.ForeignKey(Ingredient, on_delete=models.CASCADE) amount = models.CharField(max_length=50, blank=True)模型建好后执行迁移，这是让数据库落地的一步：
python manage.py makemigrations python manage.py migrate完成迁移之后，顺手用Django自带的Admin把菜品录入流程配置一下。在admin.py里注册模型并配置list_display和list_filter，这样开发过程中就能直接在后台加测试数据，不用每次都手动造数据或者写脚本。这一步看起来不起眼，但能极大提高开发效率。
3.3 Django REST Framework接口实现
接口层的实现，关键是把序列化器、视图和URL路由理顺。先用ModelSerializer把模型的输出格式定义清楚。菜品列表接口和详情接口返回的数据粒度不同，列表只需要基本信息，详情需要全量内容，所以分开写两个序列化器。
from rest_framework import serializers from .models import Dish class DishListSerializer(serializers.ModelSerializer): class Meta: model = Dish fields = ["id", "name", "category", "cover_image", "calories"] class DishDetailSerializer(serializers.ModelSerializer): class Meta: model = Dish fields = "__all__"视图这块，列表接口可以用视图集的list方法实现过滤和搜索，Django REST Framework自带的SearchFilter和OrderingFilter非常好用。配好之后前端只需要按约定传查询参数就能拿到过滤结果。详情接口直接用retrieve方法，简单直接。
注册和登录接口需要覆盖JWT的默认认证流程。注册接口要检查用户名和邮箱的重复性，密码存入数据库之前，Django的User模型已经做了哈希处理，不需要手动干预。登录接口用SimpleJWT提供的TokenObtainPairView就行，不用自己造轮子。
这里给新手提醒一个非常容易踩的坑：不要试图自己用明文密码做登录校验。不要为了“省钱”省掉安全步骤。JWT方案的成熟度已经非常高，直接用框架的机制，比手写一套安全很多。
接口写完之后，把路由挂到项目级urls.py里。整组接口用默认路由加上simplejwt提供的认证端点。用完之后，用Postman逐个验证：注册用户、登录拿token、带token调收藏接口、不带token调收藏接口确认被拒。这一步全部通过，后端接口层就基本可以交差了。
3.4 Vue前端项目结构与页面实现
前端我用的Vue 3加Vite。初始化项目命令：
npm create vue@latest然后按提示选择需要的特性。Router和Pinia（状态管理）都选上，ESLint也建议开，后期写代码过程中能及时发现低级错误。安装完后，把项目结构按views、components、api、router、stores几个目录拆好。api目录里按业务域拆成auth.js、dish.js、user.js，这样后端接口在前端每一个调用点都清晰可见。
路由设计是整个前端项目的骨架。我需要四个核心页面：首页Home、菜品列表DishList、菜品详情DishDetail、个人中心Profile。另外加登录和注册页面。路由代码如下，注意加上懒加载，避免首屏加载所有页面：
import { createRouter, createWebHistory } from "vue-router" const routes = [ { path: "/", name: "home", component: () => import("@/views/Home.vue") }, { path: "/dishes", name: "dish-list", component: () => import("@/views/DishList.vue") }, { path: "/dishes/:id", name: "dish-detail", component: () => import("@/views/DishDetail.vue") }, { path: "/profile", name: "profile", component: () => import("@/views/Profile.vue"), meta: { requiresAuth: true } }, { path: "/login", name: "login", component: () => import("@/views/Login.vue") }, { path: "/register", name: "register", component: () => import("@/views/Register.vue") }, ] const router = createRouter({ history: createWebHistory(), routes, }) router.beforeEach((to) => { const token = localStorage.getItem("access_token") if (to.meta.requiresAuth && !token) { return { name: "login" } } }) export default router这段代码里最核心的是路由守卫。没有登录令牌就访问个人中心，直接跳去登录页。这个逻辑是个人中心页面的安全底线。
页面组件的实现，我这里挑菜品列表页详细说说。页面挂载时调用dish.js里的fetchDishes函数请求列表数据；筛选器变化时把筛选条件拼成查询参数重新请求；点击分页时切换页码。这里的核心经验是：不要让每个筛选条件单独发一次请求，而是把筛选条件集中成一个响应式对象，统一拼成查询字符串。
菜品详情页需要二次请求，先拿基本信息，再拿完整详情。收藏按钮的交互逻辑是：点击后调后端接口，如果当前是未登录状态就跳登录页；如果已登录，根据当前收藏状态决定调收藏还是取消收藏接口。所有请求失败处理统一在响应拦截器里做，不要在每个页面都写一遍错误提示。
3.5 前后端联调与接口对接细节
两个端都跑起来之后，联调阶段就要处理一些列表阶段不容易发现的问题。第一个典型问题是字段名不一致。前端想要的字段叫coverImage，后端返回的字段叫cover_image。这种不一致会导致前端拿到数据却渲染不出来，而且不报错，很隐蔽。解决办法有两种：后端序列化器里用source映射，或者前端定义接口返回转换函数。我实践下来觉得后端统一转成驼峰格式更符合前端习惯，Django REST Framework序列化器里直接处理：
cover_image = serializers.CharField(source="cover_image")第二个典型问题是跨域配置在开发环境生效，但部署到生产环境忘了配置生产域名。开发时CORS配置用的是localhost，发版后前端域名变了，后端还只允许localhost，导致线上大面积接口报错。所以CORS配置不要把域名写死，可以用环境变量读取：DEBUG模式下允许所有来源，生产模式读取环境变量里的域名列表。这一步是一个容易忽视但必须做得谨慎的地方。
联调工具我比较推荐直接用浏览器的开发者工具，重点看Network面板里的请求和响应。调到一个接口，先看Request URL对不对、请求头里有没有带token，再看Response里返回的结构是否符合预期。一个抓接口问题的基本方法是三点定位：路由有没有匹配、视图有没有执行、序列化器有没有报错。
4. 常见问题与排查技巧实录
4.1 跨域、CORS与前后端协作中的高频问题
前后端分离项目里，CORS问题基本是所有人都会碰到的第一道坎。典型报错是浏览器控制台出现一段难以读懂的英文错误，大意是跨域请求被阻止。这个错误信息非常容易让人误判为后端接口挂了，但其实后端跑得好好的，是后端没有在响应头里添加允许跨域的字段。
排查思路很直接。先在浏览器Network面板看一下这个请求的Response Headers里有没有Access-Control-Allow-Origin字段。如果没有，基本可以确认是后端CORS配置的问题。检查django-cors-headers是否已安装且正确配置，特别是CORS_ALLOWED_ORIGINS里是否包含了前端实际访问的域名。注意端口也要完全一致，localhost和127.0.0.1在CORS配置里是两个完全不同的来源，经常有人在这上面卡半小时。
另一个高频问题发生在请求方式上。前端用fetch或axios发送POST请求前，会先发一个OPTIONS预检请求。这个预检请求如果后端没有正确响应，浏览器就会拦截实际请求。django-cors-headers处理这个情况已经比较成熟，但如果你的CORS_ALLOWED_ORIGINS写成了CORS_ALLOW_ORIGIN（一个不存在的配置名），预检请求照样会失败。配置名拼写这种问题，花五分钟仔细核对就能避免。
4.2 账号系统踩坑：注册成功但登录不了
账号系统的经典问题是：用户注册时数据显示成功了，但去登录却提示“用户名或密码错误”。排查后发现是注册逻辑里密码没有经过创建用户的方法处理。有些人用Django时直接在数据库中创建记录，密码存成明文，登录接口用哈希算法比对，自然永远对不上。
这个问题的根因是注册接口没有调用Django User模型自带的create_user方法。create_user内部会对密码做哈希摘要，而直接用Model.objects.create创建记录则不会。代码示例对比一下就明白了：
# 正确写法 user = User.objects.create_user(username=username, email=email, password=password) # 错误写法 user = User.objects.create(username=username, email=email, password=password)第二种写法就是典型的“看着能存数据，实际认证必失败”的坑。所以注册接口写完一定要跑一遍完整流程：注册，然后拿刚注册的账号登录，两者都通过才说明账号链路是通的。
4.3 前端渲染空白页：配置与路由的隐形错误
Vue项目跑起来但页面一片空白，这个问题看似吓人，其实多半是编译期错误或路由配置问题。编译期错误会直接在终端或浏览器控制台报错，解决难度不大。真正隐蔽的是路由配置好后，访问根路径时没有匹配到对应的组件。
一个常见场景是router中初始路径写成根路径，但对应的组件路径写错了，导致Webpack或Vite编译成功但运行时报不出有效页面。还有一种情况是组件的name和路由name不一致，使用了命名路由跳转时找不到目标组件。遇到空白页，第一步打开浏览器控制台，看到具体报错后按图索骥即可。如果控制台没有报错但仍然白屏，那大概率是入口文件里的挂载节点写错了。
4.4 性能与体验优化：图片加载和首屏提速
美食网站图片多，首屏加载容易缓慢。这直接影响用户体验。我的处理方式分两层。开发阶段，图片用外链URL，不占本地资源，先把功能跑通。上线前的优化阶段，引入图片懒加载，所有列表页的图片都用懒加载指令挂载，只有进入可见区域才加载；详情页的大图做裁剪压缩，图片尺寸控制在合理范围。
另一个容易被忽略的优化点是接口返回的数据量。列表页不需要返回完整的做法步骤和所有食材详情，序列化器里只返回渲染列表必需字段即可。后端在序列化器层面过滤字段，比前端拿到数据再筛选要省流量得多。这个小改动对用户体验的提升非常直观，尤其当菜品数据规模增长之后。
5. 部署发布与后续扩展方向
5.1 本地部署与上线过程中值得注意的细节
作业或作品集阶段，很多人在本地跑起来就认为项目完工了。但真实项目里“本地能跑”和“生产环境能跑”之间还有一段不小的距离。后端部署的核心是关闭DEBUG模式、配置好ALLOWED_HOSTS、用正式服务器软件托管Django应用。前端部署则是打包生成静态文件，然后配置Nginx把打包好的文件作为站点根目录，再把带/api路径的请求反向代理到后端服务。
部署过程中最常见的问题是把DEBUG=True直接带到生产，一旦遇到异常，Django会把完整的报错堆栈显示在页面上。这不仅是体验问题，更会泄露文件路径和数据库连接的敏感信息，是很危险的操作。对比一下DEBUG关闭前后在页面上展示的信息量，你就明白这个配置为什么要谨慎了。
静态文件的处理也很重要。Django本身不太擅长托管前端打包出来的静态文件，最佳实践是交给Nginx处理，Nginx把前端目录作为站点根目录，后端接口只是其中带/api的代理路径。这样能大幅减轻服务器压力。
5.2 从课设到作品的进阶方向
如果这个项目只是课设或者练手，做到这里其实已经合格了。但如果你想把作品放进简历里，还需要几个能拿得出手的进阶点。
第一个方向是增加搜索功能。用数据库的LIKE查询可以做模糊搜索，但不支持分词、不支持相关性排序。引入全文检索引擎后，用户可以输入“清蒸 低脂”这样的查询条件，系统能智能匹配并排序。这个功能在美食健康类项目里非常自然，游客搜索场景本身就是高频需求。
第二个方向是增加推荐逻辑。目前基础项目里的推荐还是“按标签硬匹配”的简单实现。进阶版本可以考虑用协同过滤的思路：找到和你偏好相似的用户，把对方收藏过你没收藏过的菜推荐给你。这不需要太复杂的算法，基于用户收藏行为做简单统计就能实现一个勉强可用的基础推荐模块。
第三个方向是数据可视化。健康分享的核心诉求是“吃得健康”，如果个人中心里有一张每周热量摄入柱状图、有一张营养素占比饼图，整个项目的完成度会显著提升。图表库引入ECharts就行，它的文档丰富，中文教程也多，按文档配置图表并不是什么难事。
5.3 长期维护的代价与代码规范
代码写完之后，真正保持项目长期可用的是规范，而不是当初实现功能时的那股冲劲。我建议从头就注意三个规范层面的事：命名一致性、接口版本化、数据库迁移记录清晰。
命名一致性看起来朴素，但影响巨大。后端函数名用词不统一，一会儿getDish一会儿query_detail，前端对接时完全靠记忆，时间一长就混乱。最好的做法是制定一个简单的命名口诀，比如“动词开头、表意清楚、同层一致”，然后严格执行。
接口版本化呢，则是在路由前缀加/v1，比如把接口路径统一为/api/v1/dishes。这样后续路径变更不会影响已经调用的前端页面，也是业界普遍的做法。数据库迁移记录呢，则要求每次模型改动都生成新的迁移文件，而不是删掉旧的重建。暂停一下，这件事在开发阶段好像无所谓，但一旦数据量上来了，反复重建表的代价是灾难性的。
开发这类全栈项目，我个人觉得最有价值的不是你最终做出了多少功能，而是你在调试过程中积累的那种“知道问题大概出在哪一层”的直觉。页面白屏，第一反应是路由还是编译；接口报错，先看网络请求还是直接翻后端日志；数据渲染不出来，先看返回值还是看字段匹配。这种直觉没办法从教程里直接学到，只能在一次次的联调和排错中长出来。上面这些坑，如果你能一次少踩一个，那这篇文章写得就值了。
