这套养老院管理系统我从零完整跑通了一遍，从Node.js后端接口到Vue前端页面，再到数据库设计和部署联调，中间踩了不少坑，也积累了不少实打实的经验。如果你正准备做类似的Web项目，或者是拿这个题目当毕业设计，那么这篇文章应该能帮你少走很多弯路。
先说清楚这个系统是干什么的：它本质上一个典型的前后端分离管理平台，核心目标是让养老院的工作人员（管理员、护工）通过网页完成老人信息管理、健康档案维护、护工排班、费用统计这些日常事务，同时给家属提供一个查看老人状态、在线缴费的窗口。技术骨架就两个关键词：Node.js和Vue——后端用Express搭接口服务，前端用Vue配合Element UI做管理界面，数据库用MySQL存业务数据。整个项目非常贴合“中小型信息管理系统”的经典套路，学到的技能点也足够覆盖从零搭建到部署上线的全流程。
如果只是会写几个接口、能渲染一个列表，那这个项目没什么稀罕的。真正的价值在于它把一套完整业务流程串了起来，你在过程中会接触权限控制、文件上传、数据可视化、前后端联调、生产环境部署等一堆实际工作中绕不开的问题。下面的内容我会按自己的实现顺序来讲，把我做的技术决策、踩过的坑、排查问题的思路全部摊开。
1. 项目概述与整体设计思路
1.1 系统定位与业务逻辑梳理
开始写代码之前，先花了差不多两天时间把业务角色和流程理顺。养老院服务系统按使用者划分其实就四类人：系统管理员、护工、老人（被动信息）和家属（远程关注）。很多做毕设的人容易犯一个错误，上来就建表写CRUD，表建了十几个，页面做了七八个，最后发现角色权限是乱的，业务流程根本对不上。
我在设计阶段先把核心业务链路画了一遍：老人入住登记 -> 建立健康档案 -> 分配楼层房间和护工 -> 护工按排班记录日常护理 -> 系统根据服务项目自动生成费用账单 -> 财务确认收款 -> 家属在小程序或Web端查看状态、在线缴费。这个链路决定了系统的核心模块，也决定了数据库的外键关系。比如费用表必须关联老人、关联护理项目，不能孤立存在；护工排班表需要同时关联老人和护工，否则“分配护理任务”这个动作就没法落地。
所以一个看似普通的养老院系统，拆开来看其实是典型的“主数据 + 业务单据 + 权限角色”三层结构。先把这些想明白，后面编码基本就是体力活。我用一张简单的Excel表格列出了所有功能点，每个功能点标注了所属角色、涉及的前端路由、后端接口、数据表，这个表后来直接变成了开发任务清单，个人非常推荐这个做法，磨刀不误砍柴工。
1.2 为什么选Node.js + Vue的组合
选型这块很多同学会纠结：到底是Spring Boot + Vue还是Node.js + Vue？我的观点很直接：如果你不是Java技术栈的拥趸，毕业设计或者中小型管理系统用Node.js做后端反而更顺手。
首要理由是语言统一。前后端都用JavaScript，数据类型、对象结构的思维不用切换，前端拿到的一手JSON数据结构是什么样，后端模型就长什么样，省掉了大量字段映射的工作。我写Spring Boot项目时最烦的就是Java Bean和前端传参之间的转换，一不小心就是类型不匹配的报错，Node.js基本没有这个问题。
第二个理由是开发效率高。Express框架极轻，中间件机制非常朴素，一个路由文件几行代码就是一个接口，配合一个MySQL的工具类，一个星期把全后端接口撸完完全可行。相比之下，Spring Boot虽然工程化强，但启动慢、依赖重、配置繁琐，做个小系统属实有点大炮打蚊子了。
第三个理由是你用Node.js能学到的东西一点不少。JWT身份认证、中间件设计、文件上传处理、数据库连接池、接口鉴权这些后端核心能力，Express全都覆盖。而且Node.js处理高并发I/O的能力并不弱，做养老院这种并发量级（几十人同时在线都算多的）绰绰有余。唯一要留神的是Node.js对代码规范要求更高，它不像Java编译器帮你查错，错误处理和异步流程得靠自己约束好。
1.3 功能模块拆解与优先级排布
模块拆解直接照着业务链路画就行，我自己的划分是七个功能域：
- 系统登录与权限控制：账号密码登录、JWT签发与验证、基于角色的路由权限控制
- 老人档案管理：入住登记、信息编辑、退住注销、按条件搜索展示
- 健康档案管理：体检记录、慢性病史、用药提醒、健康趋势图表
- 护工排班与任务管理：排班表、护理任务分配、任务完成状态跟踪
- 费用管理：护理项目价格维护、账单自动生成、支付状态管理、月度统计
- 家属端服务：家属登录查看老人概况、缴费、在线预约探视
- 系统管理：用户管理、角色管理、操作日志
排优先级时把“老人档案”和“健康档案”放到了P0，因为它们是整个系统的主线数据。护工排班和费用是P1，属于核心业务操作。家属端和系统管理是P2，可以放到赶工期时后面做。这样就算最后时间不够，交付的版本核心链路依然是完整的，不会有“登录进去不知道干什么”的问题。
2. 技术栈选型与核心实现思路
2.1 前端技术栈：Vue + Element UI + ECharts
前端我用了Vue 2.6 + Element UI，这个组合放在今天看虽然有点“旧”，但在管理系统领域依然是稳定性最高的方案。Vue 3 + Element Plus我也试过，组件生态和API变化不大，但网上能直接抄的作业明显没有Vue 2多，对毕业设计这种对进度有要求的项目，稳比新更重要。
组件库选Element UI是因为管理后台的表格、表单、弹窗、分页这些高频组件它全都覆盖得很好，主题风格统一，改起来也不费劲。数据可视化部分用ECharts，老人健康指标的趋势图、费用月度统计柱状图、护工任务完成率饼图，这些图表组件直接npm install echarts然后按需引入就行，不需要额外封装。
路由用的vue-router，状态管理用了Vuex。按功能模块拆了store模块，老人档案、费用、用户三个独立模块，各自维护自己的状态。实际开发下来，Vuex在这种中后台系统里主要发挥两个作用：一个是全局的登录用户信息和权限菜单状态，另一个是解决不同页面之间共享数据的问题。比如费用页面修改了一笔账单，老人详情页里那个“欠费金额”要跟着变，不通过store就会很别扭。
前端工程化选了Vue CLI 5。虽然大家都说Vite快，但Vue CLI的生态兼容性更好，webpack配置网上资料多，遇到问题容易排查，对新手也更友好。npm run serve一键启动开发服务，npm run build打包后扔到nginx就能跑，没有什么特别复杂的配置。
2.2 后端技术栈：Express + MySQL + JWT
后端我用Express 4.x配合node的mysql2驱动。为什么不用Sequelize这类ORM？因为说实话，手写SQL更直观，也更能锻炼排查问题的能力。ORM虽然省事，但如果关联查询复杂、字段多，生成的SQL一旦有问题，反而不如自己写的SQL好调整。养老院系统的关联查询其实很集中，主要是老人-档案-费用-排班的联表，手写SQL完全hold住。
连接数据库用的连接池配置，maximum设为10，MySQL默认最大连接数是151，开发环境10个连接完全够用。连接池的好处是避免每次请求都重新建立TCP连接，压测下来的性能差异非常明显。
鉴权方案选了JWT（jsonwebtoken库），登录成功签发一个有效期24小时的token，前端存储到localStorage，每次请求放到Authorization请求头里。后端用express-jwt中间件统一校验，除了登录接口和静态资源，其他接口全部要求带token。这里有个细节：密码不能明文存，用bcryptjs做哈希，同一个密码每次生成的hash都不同，这样即使数据库泄露，原始密码也不容易被逆出来。
后端项目结构用了经典的分层：
server/ ├── app.js // 入口文件 ├── config/ │ ├── db.js // 数据库配置和连接池 │ └── jwt.config.js // 密钥和过期时间 ├── routes/ // 路由文件，按模块拆分 ├── controllers/ // 控制器，处理业务逻辑 ├── models/ // 数据模型/SQL语句 ├── middlewares/ // 中间件：鉴权、错误处理、日志 └── utils/ // 工具类：响应封装、文件上传2.3 前后端分离与跨域处理
前后端分离之后，前端跑在8080端口，后端跑在3000端口，两个端口不同必然产生跨域问题。我的处理方式是：开发环境在Vue CLI的devServer里配置proxy代理，把/api前缀的请求都转发到http://localhost:3000；生产环境直接用nginx做反向代理，把/api也代理到后端端口。
这里我强烈建议用代理而不是后端开cors。如果后端开cors允许跨域，相当于对任何来源的请求都放开了接口访问，虽然能解决问题，但接口等于裸奔。用代理的方式，浏览器看到的是同一个源（前端的域名），不存在跨域概念，安全性高得多。更重要的是，这和线上部署时的行为是一致的，代码不需要为了环境差异做任何修改。
3. 数据库设计与接口规范
3.1 核心数据表设计
数据库设计是这个系统的灵魂，表建得不好，后面写接口和页面全是坑。我把核心表分了三组：
主数据表：用户表（sys_user）、老人信息表（elder_info）、护工信息表（worker_info）、房间床位表（room_info）。
业务流水表：健康档案表（health_record）、护理任务表（care_task）、排班表（work_schedule）、缴费账单表（fee_bill）、探视预约表（visit_order）。
支撑表：角色权限表（sys_role）、操作日志表（sys_log）。
每张表的公共字段我统一都建了create_time、update_time、deleted三个字段，deleted做逻辑删除，查数据时统一过滤deleted = 0。逻辑删除是系统开发的保命项，物理删数据容易把自己搞死，软删至少还有后悔药。
老人信息表的核心字段是姓名、身份证号、性别、年龄（可以由身份证自动算）、入住时间、房间ID、护理等级（自理/半自理/全护理）、家属联系方式、紧急联系人、备注。身份证号必须唯一索引，因为它是老人身份的唯一标识。房间ID外键关联房位表，房位表要维护当前状态（空闲/占用/维修），这样才能在“老人入住登记”时只展示空闲房间。
健康档案表单独列出来是因为它和老人的关系是一对多——一个老人可能有多条体检记录。每条记录包含血压、血糖、心率、身高体重、既往病史、过敏药物说明等。这个表用老人ID做外键索引，查询时按时间倒序取最近的一条作为“当前健康状态”。
3.2 接口设计约定
接口设计遵循RESTful风格，统一前缀/api，例如：
- GET /api/elder/list —— 分页查询老人列表
- POST /api/elder/add —— 新增老人档案
- PUT /api/elder/update —— 修改老人档案
- DELETE /api/elder/delete —— 删除老人档案（逻辑删除）
- GET /api/health/list —— 查询健康档案列表
- POST /api/fee/generate —— 生成费用账单
统一响应格式是项目里很容易忽略但非常重要的一点。我的所有接口返回结构固定为：
{ "code": 200, "message": "操作成功", "data": {} }code为200表示成功，401表示未认证，403表示没权限，500表示服务器内部错误。前端axios封装里根据code做全局拦截，code不是200时统一弹错误提示，这样业务代码里就不需要每个请求都手写error回调。
接口里最核心的几个我多说一句。老人分页查询用的是LIMIT和OFFSET分页，参数是page（页码）和pageSize（每页条数），返回结果除了data数组还要带上total总数，前端表格页码才能算出来。费用生成是个典型的事务操作，同步生成多条账单明细（床位费、护理费、餐费），必须放在数据库事务里执行，任何一个插入失败都要回滚，否则账就对不上。
3.3 接口鉴权与操作日志
权限控制这块我用了比较简单的“一个用户一个角色”模型。用户表存role字段，1=管理员，2=护工，3=家属。后端在进入某个接口时校验角色的中间件，比如费用删除接口只有管理员能调，护工只能查看和更新护理记录，家属登录后前端只显示家属端那几个页面。
实现时我给每个需要权限的接口打上注解路径：
router.delete('/api/fee/delete', authMiddleware(['admin']), feeController.delete);authMiddleware接收一个角色数组，登录用户的角色不在数组里直接返回403。
操作日志用中间件实现，每次有写操作（POST/PUT/DELETE）时往日志表插入一条记录，内容包括用户ID、操作模块、请求路径、操作时间和IP。这个功能看似不起眼，但实际很有用，真出了问题，翻日志就能定位是谁在什么时间做了什么操作，是系统审计的保底机制。
4. 实操过程：从环境搭建到前后端联调
4.1 Node.js安装与环境配置
这一块是很多新手卡壳的第一道坎。我自己的经验是，Node.js版本不要追新，装LTS版就好，当前我们用的是16.x和18.x这两个长期维护版本。装完之后一定要确认环境变量，因为Windows下安装包虽然会自动配置PATH，但偶尔会有意外。
安装完成后在命令行输入node -v能输出版本号，npm -v能输出版本号，说明Node和npm都就绪了。如果输出不了，绝大多数原因就是环境变量配置没生效，手动去系统设置里检查Path是否有nodejs安装目录。
用得顺手之后，非常建议把npm镜像源切到国内镜像，否则下载依赖的时候你会体验到什么叫“等到花儿都谢了”：
npm config set registry https://registry.npmmirror.com切完之后手动安装依赖的速度提升是肉眼可见的，一个Vue项目从挂起到装完依赖，原来可能要十几分钟，现在一两分钟就下来了。这是我在实操中强烈推荐的第一个优化步骤，谁用谁知道。
4.2 创建Vue前端项目
前端项目的创建用Vue CLI最省事：
npm install -g @vue/cli vue create elder-admin创建过程中会让你选择配置，我选了Manually select features，然后勾选了Babel、Router、Vuex、CSS Pre-processors（选Less）、Linter。项目创建完成后进目录装核心依赖：
npm install element-ui axios echartsElement UI按需引入可以减小打包体积，但配置麻烦，图省事可以直接完整引入，一个入口文件全部注册完，开发体验比较顺畅。main.js里的大致写法：
import Vue from 'vue' import ElementUI from 'element-ui' import 'element-ui/lib/theme-chalk/index.css' import App from './App.vue' import router from './router' import store from './store' Vue.use(ElementUI) new Vue({ router, store, render: h => h(App) }).$mount('#app')页面结构上用了Element UI现成的布局容器，左边是侧边栏菜单，右边是顶栏和内容区。菜单项根据登录用户的角色动态生成，这里是前端路由守卫配合路由meta配置来实现的，管理员显示全部菜单，护工只显示档案和任务，家属只显示家属端页面。
4.3 Express后端搭建与数据库连接
后端的创建就简单多了，先手动建目录，然后初始化package.json，依次安装依赖：
npm init -y npm install express mysql2 jsonwebtoken bcryptjs multer入口文件app.js里要做几件事：解析JSON请求体、挂载日志、注册路由、启动监听。数据库连接池的配置单独放一个文件，参考示例：
const mysql = require('mysql2/promise'); const pool = mysql.createPool({ host: '127.0.0.1', user: 'root', password: '123456', database: 'elder_care', waitForConnections: true, connectionLimit: 10, charset: 'utf8mb4' }); module.exports = pool;注意字符集一定要用utf8mb4而不是utf8，否则存储中文没问题，但一旦内容里有特殊表情符号或者生僻字，数据库就会报错甚至数据丢失。这是我实际踩过的坑，因为没有设置charset，前端传入一个客户评价里带emoji的字段，接口直接500了。
4.4 前后端联调的关键环节
联调阶段是项目真正“活着”的时刻。前端启动开发服务器后，通过代理请求后端接口，首先要验证的是登录流程。我登录成功后拿到token不是简单存起来就完了，而是在axios请求拦截器里统一加上请求头：
service.interceptors.request.use(config => { const token = localStorage.getItem('admin_token') if (token) { config.headers['Authorization'] = 'Bearer ' + token } return config })响应拦截器里做统一错误处理，code为401时跳转到登录页，code为500时统一弹出后端返回的错误信息。这样写完之后，开发时接口报错信息基本一眼就能看到根因，是参数错了、权限不够还是后端代码崩了，三个状态码对应三种排查方向，联调整体顺畅不少。
跨域的坑我在联调阶段遇到过一次。当时前端代理配置了/api前缀，但后端接口也带了/api前缀，代理转发时忘了保留前缀，前端请求/api/elder/list被转发成/elder/list，后端路由匹配不上，返回404。排查这个问题的技巧是用DevTools的Network面板看请求URL，看到实际发出的请求路径和预期不一样，就立刻知道是代理路径配置的问题了。
4.5 关键技术点：文件上传与视频播放
养老院系统里有个“生活记录”功能，护工偶尔上传活动照片和视频。文件上传我用multer处理，上传目录放在后端服务器本地，数据库只存文件路径。上传接口做了一层文件类型和大小校验，只允许jpg/png/mp4，限制大小10MB以内。
视频播放遇到的实际问题是网上常见的m3u8格式视频，尤其是活动监控或录像回放，很多都是HLS流。前端播放m3u8可以用video.js配合hls.js库，代码如下：
import videojs from 'video.js' import 'video.js/dist/video-js.css' import 'videojs-contrib-hls'后端不需要特殊处理，只要把流文件静态资源暴露出来就行。但这里有个容易踩的坑：如果m3u8文件和分片ts文件的访问路径是相对路径，播放器解析时会基于当前URL去拼接，结果常常出现404。解决方案是给播放器传入完整的绝对地址列表，或者在后端把m3u8里的ts路径改写为完整URL。我自己处理时是把ts路径和m3u8文件放在同一目录并直接用完整URL拼接，问题立刻消失。
5. 常见问题与排查技巧实录
5.1 npm相关高频报错与解决
开发过程中我和npm的报错交手次数最多，这里整理几个高频问题。
npm.ps1无法加载报错。这个报错的原话是“npm : 无法加载文件 ...npm.ps1，因为在此系统上禁止运行脚本”。这是因为Windows PowerShell默认的执行策略是Restricted，不允许执行.ps1脚本文件。解决办法是右键以管理员身份打开PowerShell，执行：
Set-ExecutionPolicy RemoteSigned再输入Y确认就能用了。这个命令的意思是对本地脚本放行，远程脚本需要有可信签名才运行，既解决了问题又不会把系统安全级别降到最低。
npm install卡住或者下载失败。最常见的诱因就是默认源在国外，速度慢。我前面已经建议切换npmmirror源了，但还有更极端的场景：公司网络对某些域名限制访问，此时可以用代理方式覆盖部分依赖的下载路径，比如给node-sass单独指定镜像。另外一种情况是依赖装到一半断了，先删掉node_modules目录再重装，不要心存侥幸地直接再跑一次npm install。
Node版本太高导致node-sass安装失败。这个坑非常经典，node-sass需要和Node版本精确匹配，升级Node之后原来的node-sass直接编译失败。推荐方案是弃用node-sass改用sass（dart-sass），API基本兼容。如果项目里必须用node-sass，那就查版本对应表，找到匹配当前Node的node-sass版本号再装。
5.2 数据库与后端接口排查
连接数据库报错“ER_NOT_SUPPORTED_AUTH_MODE”。这通常是因为MySQL 8默认的账号认证插件是caching_sha2_password，而旧版mysql2驱动不识别。解决办法有两个：要么升级mysql2到2.x版本，要么在MySQL里把认证方式改成mysql_native_password：
ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY '你的密码';我两个都试过，升级驱动是更干净的做法。
接口返回500但看不到错误日志。这个问题很隐蔽，原因是Express的默认错误处理没有把异步抛出的异常捕获住。Express 4中对async请求处理函数里的报错不会自动进入错误中间件，需要手动包裹一层。我当时是在所有路由外面加了一个asyncHandler工具函数，把异步函数包进去，错误就能统一抛到错误处理中间件，日志里才能看清楚崩在哪一行。
查询数据时中文乱码。数据库库表、连接、前端页面三个地方只要有一个字符集不变，就可能导致乱码。优先检查数据库连接字符串有没有charset=utf8mb4，其次检查建表语句的默认字符集。这两条都对了，基本不会乱码。
5.3 前端常见问题
前端页面白屏，控制台报错“Cannot read properties of undefined”。这种问题大量发生在数据还没返回时就尝试渲染深层嵌套的对象属性。比如后端返回的老人列表，每个老人下面有roomInfo对象，模板里写了elder.roomInfo.roomName，如果roomInfo是null就崩了。解决方法是模板渲染前用v-if判断，或者后端返回数据时就把嵌套结构处理好，没有房间信息的直接返回空对象而不是null。
Element UI表格分页和“翻页后数据不刷新”。这是因为表格绑定的数据没有同步到当前页码下。排查思路很简单：翻页时是否调用了获取列表的接口，数据是否被新返回值覆盖，分页组件绑定的total是否更新。我遇到过最奇葩的一次是页码从1跳到2，接口请求是发了，但Vuex里返回的数据被一个旧函数覆盖了，导致表格看起来没变化。这个问题让我明白了一个原则：获取列表的接口逻辑只写一个函数，全项目复用，别到处复制粘贴。
Vue devtools插件不生效。大概率是插件版本和Vue版本不匹配。Vue 2项目要用Vue 2对应的devtools版本，Vue 3项目要用Vue 3版本的devtools beta。下载路径直接在浏览器扩展商店搜“Vue.js devtools”，看清楚支持哪个版本再安装。安装完记得刷新页面，开发者工具里会出现Vue的Tab，里面可以看到组件树和各组件的data数据，排查数据传递问题相当好用。
5.4 排查问题的思路总结
我自己的排查套路很朴素，遇到问题先从后端日志入手，看接口有没有收到请求、有没有报错堆栈；再看浏览器Network面板，确认请求是不是发出去了、返回状态码是多少；最后才是看业务代码逻辑。哪个环节断了就专攻哪个环节，基本能把问题范围缩小到很小的区域。
如果你是在Windows下开发，还要习惯“端口被占用”这个经典场景。前端跑着8080，后端跑着3000，时不时就会遇到端口占用导致启动失败，解决方法是找到占用进程然后结束掉：
netstat -ano | findstr :3000 taskkill /PID 你的PID /F6. 部署上线与项目管理心得
6.1 生产环境部署流程
开发联调完成之后，部署上线是检验项目能不能真正跑起来的最后一道关卡。我的部署方案很简单：一台Linux服务器，前端打包后用nginx托管，后端用pm2守护进程管理。
前端打包执行npm run build，生成dist目录，里面的静态文件放到nginx的html目录下。nginx的关键配置是把所有/api请求代理到后端的3000端口：
server { listen 80; server_name your_domain; root /usr/share/nginx/html; index index.html; location /api/ { proxy_pass http://127.0.0.1:3000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } location / { try_files $uri $uri/ /index.html; } }这里有个很关键的配置是try_files $uri $uri/ /index.html。因为Vue是单页应用，前端路由由history模式接管，用户直接访问/elder/detail时nginx找不到这个物理文件，必须把请求回退到index.html，由Vue自己根据路由渲染页面。漏掉这一行，刷新页面就是404。
后端用pm2启动，一个进程守护命令就搞定：
pm2 start app.js --name elder-serverpm2的好处是进程崩溃自动重启，开机自启也方便，服务器重启后不用手动再起服务。实际线上跑了两周，稳得很。
6.2 项目质量与代码规范
软件项目写到最后，拼的是代码规范和工程质量。我自己在开发中坚持了几个原则，现在回头看特别值。
接口返回格式必须统一，前端才能写出干净的拦截逻辑。我封装了一个sendSuccess和sendError工具函数，所有controller返回都走这两个函数，绝不在某个接口里直接res.send("ok")。
错误处理不能只try-catch不处理。我见过太多项目，catch到异常就res.send({code:500})，日志里什么都没有，事后排查全靠猜。我的做法是catch里必须打日志，打上请求路径、请求参数和错误堆栈，线上出问题才能快速定位。
上传的文件必须有命名规范，时间戳加随机字符串拼接原始名字，避免中文名和重名文件。存储路径按日期分目录，比如/upload/2025/06/15/，这样后期清理文件时直接按月删目录就行。
6.3 踩坑后的项目管理心得
最后聊点管理层面的体会。我一个人做这个项目，从设计到编码花了大概三周，每天稳定投入五六个小时。能撑下来没烂尾，一个是靠前面说的Excel任务清单，另一个是坚持“可运行版本优先”的原则。我给自己定的规矩是，每天下班前必须保证系统能在本地完整跑起来，哪怕这个功能还没做完，至少不能把项目搞到启动不了的状态。
每完成一个模块就做一个简短的markdown记录，包括核心代码片段、踩坑点和心得体会。第三周联调时翻这些笔记找问题根因，比重新翻源码效率高得多。这个习惯我一直保留着，做任何项目都会顺手维护一份开发日志。
做完这个项目再回头看，Node.js和Vue这套组合是真的适合快速搭建业务管理系统。它不需要复杂的工程设计，但有足够的深度让你理解Web前后端交互的全链路。如果你也在做类似的系统，我最大的建议是别急着写代码，先花时间把业务数据流想清楚，把表的关联设计好，后面自然水到渠成。开发过程中遇到的问题，九成都能在网上找到答案，但要真正理解为什么这么解决，还是得靠自己在项目里动手踩一遍。
