市面上打着“完整源码+部署教程”旗号的项目资源很多，但真正能让人从零跑通、看懂、改得动的其实不多。这套前后端分离的夕阳红公寓管理系统，用的是SpringBoot+Vue+MyBatis+MySQL这套非常经典的组合，恰好覆盖了大多数课程设计和中小型实战项目的技术栈需求。我断断续续把这个项目从部署到二次改造过一遍，踩了不少坑，也理清了它的核心设计思路，这篇就把它掰开揉碎了说清楚，尽量做到你拿到源码之后能自己跑起来、看得懂、改得动。
先说结论：这套系统不是那种花架子Demo，它的功能模块比较完整，覆盖了住客档案管理、房间与床位分配、护理记录、费用账单、家属沟通、系统用户与权限管理这些养老公寓运营里最日常的业务。对于刚开始学前后端分离的同学或者想快速交付一个管理系统的开发者来说，它的代码结构清晰，业务边界明确，很适合用来做课程设计、毕业设计，也能作为中小型养老机构信息化管理的起步原型。如果你手头只有一份源码包和零散的部署文档，这篇文章可以帮你把“从下载到跑通”的时间压缩到一顿饭的功夫。
1. 这套养老公寓系统到底解决什么问题
1.1 养老服务行业的日常业务痛点
养老公寓的管理模式和普通酒店、医院都不同。酒店只管住几天，医院只管治病，而养老公寓要管的是一个老人的日常生活全流程——入住登记、健康档案、护理排班、饮食禁忌、家属探视、费用缴纳，每一样都是长期且循环的。用Excel表格也能管，但一旦老人数量超过几十人，记录分散在各个人手里，找一份两年前的护理记录可能翻半天，更别说统计床位利用率和月度费用了。
这套系统的核心定位就是把这些分散的纸质记录和表格管理，收敛到一个前后端分离的Web平台上。管理员在后台维护住客和床位信息，护理人员填写日常记录，家属通过分配好的账号查看老人的生活状态和账单，财务在同一个系统里处理缴费和欠费提醒。所有数据落到MySQL里，查询和统计都能即时完成，这在运营层面是一个非常实在的降本增效动作。
1.2 功能模块全景与核心使用对象
从功能清单上看，这套系统大体可以划分成七个主要模块：住客信息管理、房间床位管理、护理记录管理、费用账单管理、家属沟通管理、系统用户管理、数据统计看板。每个模块之间有明确的数据关联，比如住客必然关联一个床位，床位必然关联一个房间，护理记录必然关联一个住客，费用账单也必然关联一个住客。逻辑关系清晰，非常适合用来理解业务系统的数据建模。
不同角色看到的操作界面也不一样。系统管理员负责建账号、配置权限、查看全局数据；前台工作人员负责住客入住登记和房间分配；护理人员主要使用护理记录和健康档案相关功能；财务人员关注费用账单模块；家属账号则被限制只能查看与自己绑定的老人的信息和账单。这种基于角色的访问控制，在技术上就是通过登录后的用户角色字段在前端路由和后端接口上做双重拦截，后面我在第3章会详细展开。
1.3 为什么这套技术栈至今仍然值得学
标题里挂的SpringBoot+Vue+MyBatis+MySQL并不是什么新潮技术，但它恰恰是当前国内中小型管理系统开发里最常见的组合。SpringBoot解决了Spring配置繁琐的问题，内嵌Tomcat让部署变得简单；Vue提供了一套组件化的前端开发体验，配合Element UI这类现成组件库，做后台管理界面效率极高；MyBatis把SQL写法和Java方法做了映射，既保留了SQL的灵活性，又不会像传统JDBC那样写出一堆样板代码；MySQL则凭借稳定性和零成本成为绝大多数项目的首选数据库。
你可以说这套组合传统，但不能说它过时。学习这个项目最大的收获不是学会某一个框架，而是理解一条完整的数据流转链路：前端页面发起请求，经过Vue路由和axios封装，到达后端Controller层，再经过Service层处理业务逻辑，通过Mapper层操作MySQL，最后把结果一层层返回给前端渲染。这条链路是无数企业级系统的基本功，你掌握一次，往后换任何框架都只是在换工具，思路不会变。
2. 后端SpringBoot+MyBatis的分层设计与核心表结构
2.1 五张核心数据表的字段规划与关联关系
项目下载下来之后，我建议第一件事别急着启动，先把数据库脚本打开看一遍。这个系统的数据库脚本里一共二十多张表，其中最核心的五个表支撑了整个业务主流程：room、bed、elder、nurse_record、fee_order。
room表是最基础的物理空间单元，字段一般包括房间号、楼层、房型、可住人数、当前入住人数、房间状态。bed表挂在room下面，通过room_id关联，每张床有床位编号和状态字段（空闲/入住/维修）。为什么要单独建一个bed表而不是直接在room表里存床位数量？因为实际运营中每张床都可能被分配、更换、维修，如果把床位信息全部塞进room表，就无法精确追踪到单张床的状态。这个设计在我看过的很多学生项目里都踩了坑，他们往往把房间和床位合并成一张表，导致后面做床位分配时逻辑拧成一团。
elder表是住客主表，字段设计很有代表性：姓名、性别、出生日期、身份证号、联系方式、入住日期、紧急联系人、既往病史、饮食禁忌、所属床位ID。这里最关键的关联字段就是bed_id，它把人与人住的物理位置建立了绑定。护理记录表和费用表都通过elder_id关联，形成一个人从入住到服务到缴费的完整数据闭环。
2.2 后端分层：Controller-Service-Mapper的职责边界
SpringBoot项目打开src目录之后，包结构非常直观：controller、service、mapper、entity、config、common六个包各管各的。Controller只负责接收HTTP请求、参数校验和统一响应封装，内部不写任何业务逻辑；Service层完成实际的业务处理，比如入住登记时要同时更新床位的状态和房间的已住人数；Mapper层则通过MyBatis接口与XML中的SQL语句对接，一个接口方法对应一条SQL。
这种分层的价值在遇到稍微复杂的业务时就体现出来了。比如处理退住操作，前端只调了一个/elder/checkOut接口，但Service层里需要做五件事：把住客状态改为已退住、把床位状态改为空闲、把房间已住人数减一、生成一条退住记录、若有未结清账单则冻结结算。如果这些逻辑分散在Controller里，代码很快就会失控；放到Service里统一编排，每个方法都能独立测试，出了问题也容易定位。我改造这个项目时，第一件事就是把Controller里个别偷懒写业务逻辑的地方全部抽回到了Service层，后续加功能时清爽很多。
2.3 登录鉴权与权限控制的实现细节
登录功能是这个项目里值得仔细读的模块。系统采用的是JWT（JSON Web Token）方案，流程是：用户提交用户名和密码，后端校验通过后生成一个包含用户ID、用户名、角色的Token字符串返回给前端，前端把它存在本地，之后每次请求都在请求头里带上，后端用一个拦截器拦截需要鉴权的接口，解析Token并获取当前用户信息。
Token的有效期设置一般是一天或两天，这个在application.yml里能配置。实际运营中，家属账号和内部员工账号混在一起，权限管理尤其重要。具体做法并不复杂：LoginInterceptor里解析出用户的角色，然后在Controller接口上用自定义注解或者直接判断角色类型，决定是否放行。比如/api/family/**前缀的接口，只允许角色为FAMILY的账号访问，/api/admin/**则只允许ADMIN角色。这种基于URL前缀的拦截是最简单也最直观的粗粒度鉴权方式，对于这类公寓管理系统已经绰绰有余。唯一的提醒是，千万别把权限校验漏在静态资源或者登录接口本身上，否则会陷入重定向死循环。
2.4 MyBatis动态SQL的实战写法
这个项目里MyBatis用得比较基础，但有一处动态SQL非常值得借鉴：住客列表的分页条件查询。查询页面通常有几个筛选项——姓名、状态、入住日期区间、所属楼栋，用户不一定填全，所以SQL需要根据传入的参数决定拼接哪些WHERE条件。
<select id="selectElderPage" resultType="com.xxx.entity.Elder"> SELECT e.*, r.room_number, b.bed_number FROM elder e LEFT JOIN bed b ON e.bed_id = b.id LEFT JOIN room r ON b.room_id = r.id <where> <if test="elderName != null and elderName != ''"> AND e.elder_name LIKE CONCAT('%', #{elderName}, '%') </if> <if test="status != null and status != ''"> AND e.status = #{status} </if> <if test="startDate != null and startDate != ''"> AND DATE(e.enter_date) >= #{startDate} </if> <if test="endDate != null and endDate != ''"> AND DATE(e.enter_date) <= #{endDate} </if> </where> ORDER BY e.create_time DESC </select>这段SQL同时用到了<where>标签自动去除首个多余的AND，以及<if>标签做条件分支。很多人一开始不习惯这种在XML里写SQL的方式，但做过多条件筛选之后你就会发现，它比用代码拼SQL或者用QueryWrapper猜语义都来得直观。用LIKE CONCAT('%', #{elderName}, '%')而不是直接写'%${elderName}%'，是防止SQL注入的最基础操作，这一点务必养成习惯。另外我接手时发现原本的JOIN逻辑有个小坑：如果某条住客记录的bed_id为空，LEFT JOIN也能正确返回数据，但如果一开始误写成INNER JOIN，就会把未分配床位的住客整个丢出列表，导致管理人员误以为数据丢失。这也是为什么关联查询优先用LEFT JOIN的典型场景。
2.5 统一响应体与全局异常处理
看后端代码时，我建议重点关注common包下的Result类和GlobalExceptionHandler类。这个项目没有用随手new一个Map作为接口返回值，而是定义了统一的响应结构Result<T>，包含三个字段：code（状态码）、message（提示信息）、data（具体数据）。所有Controller的返回值都包装成这个结构，前端拿到响应后先判断code是否为200，再做后续处理。
配合统一响应体的是全局异常处理器，用@RestControllerAdvice注解捕获所有异常并转换为标准响应。比如参数校验失败时抛出IllegalArgumentException，异常处理器捕获后返回Result.error("参数错误")，而不是把异常栈直接甩给前端。前端看到的是结构一致的JSON，后端的try-catch也能少写一多半。我在实际部署后发现，线上环境最怕的是空指针异常直接返回500，前端弹一个“系统错误”，用户根本不知道是自己操作问题还是系统故障。加上全局异常处理之后，至少能区分出业务异常、参数异常和系统异常三个层级，运营人员排查问题时能省不少功夫。
3. Vue+Element UI前端：路由、状态管理与接口联调
3.1 前端工程结构与路由守卫设计
前端项目是用Vue CLI或Vite搭建的，目录结构比较标准：src/api放接口定义，src/router放路由配置，src/store放Vuex状态管理，src/views放页面组件，src/components放公共组件。主体UI组件用的是Element UI或Element Plus，具体看项目版本。管理端页面的典型布局是左侧菜单栏加右侧内容区，菜单根据用户权限动态生成。
路由守卫是这个项目前端部分的核心亮点。Vue Router提供了beforeEach钩子，每次路由跳转前都会先经过这里，代码逻辑大致是：判断本地Token是否存在，不存在则强制跳转登录页；存在则判断当前路由是否需要特定角色权限，如果用户角色不匹配就跳转到403页面或者首页。
这种设计解决了一个关键体验问题：未登录用户直接在地址栏输入某个页面的URL，理应被拦下而不是看到页面再被后端接口返的401“拒绝”。我在第一遍跑通项目时，曾直接修改浏览器地址跳到管理页面，发现页面能被打开但数据请求全部失败，后来加了这层路由守卫，未登录时直接跳转登录页，体验才算闭环。
3.2 axios请求封装与接口路径统一管理
前端请求后端接口全部走的是src/api目录下的模块化封装，而不是在组件里到处写this.$http.get。封装的核心是一个统一的axios实例，配置了基础URL、请求超时时间、请求拦截器和响应拦截器。
请求拦截器做的事很单一：从localStorage取出Token，在请求头上设置Authorization: Bearer <token>。响应拦截器做的事则稍微多一些：先判断HTTP状态码，然后取出响应体里的业务code，如果等于200就直接返回data；如果不等于200，用Element UI的消息组件弹出后端返回的message；如果HTTP状态码是401，说明Token失效或未登录，自动清除本地Token并跳转登录页。
这套封装的受益点在于，所有页面的接口调用代码极大简化，比如查询住客列表只需要三行：
const res = await getElderList(params) this.tableData = res.data.records而且后端接口路径统一以/api前缀命名，前端在src/api/elder.js里维护了一个函数映射表，比如getElderList映射到GET /api/elder/list，checkOutElder映射到POST /api/elder/checkOut。后续后端改了接口路径，只需改这个映射文件，全站的调用点都不用手动改，维护成本降低得非常明显。
3.3 床位分配交互的后端联调细节
床位分配是这个小系统里交互逻辑比较复杂的一个页面。用户操作路径是：先选楼栋，再选房间，然后看到房间内床位的网格图，每个床位根据状态显示不同颜色，空床可点，已入住床位不可点，点击空床后弹出住客信息表单。
这个页面的前端难度在于“选房间看床位”的数据加载。房间列表接口返回房间基本信息，但不同房间的状态不一样，有的房间整体被锁（比如装修中），有的房间部分床位被占用。前端做联动时最怕异步竞态：用户快速切换房间，先请求了A房间后请求了B房间，A房间的响应比B房间晚到，页面就显示了错误的数据。解决办法是在发起新请求前用axios.CancelToken取消上一个未完成的请求，或者用一个递增的请求序号来丢弃过期响应，这个细节在很多项目里都被忽视，实际演示时特别容易暴露问题。
后端联调时还需要注意一个字段：房间的当前入住人数。前端在房间列表页往往直接展示已住2/4人，这个数据建议由后端计算好返回，而不是前端遍历床位统计，因为床位状态可能因退住、维修而变化，前端拿到的可能是旧快照。我在改造时把这条逻辑放进了Service层的房间列表方法里，用一条子查询统计bed表中状态为“已入住”的床位数量，接口返回字段occupiedCount，前端直接绑定渲染，效率和数据准确性都更好。
3.4 家属端与员工端的路由拆分体验
这套系统还做了一个很人性化的设计：家属端和员工端体验分离。前端会用同一个工程打包，但通过不同路由前缀和登录后的角色判断，跳转到不同的首页布局。员工端首页是工作台，能看到入住人数、空床数、今日护理任务等统计卡片；家属端首页则是自己绑定老人的信息卡片、最近护理记录和待缴账单提醒。
这种同构拆分在代码实现上并不复杂，本质是路由配置里定义了两套布局组件，layout/StaffLayout和layout/FamilyLayout，路由守卫根据角色把不同用户导航到对应的布局下。真正要注意的是后端接口的可见性控制，家属ID只能查到自己绑定老人的数据，这个不能只依赖前端隐藏菜单，后端在SQL查询时必须强制加上elder_id = #{currentElderId}的条件。我在审查这个项目的安全性时重点检查了这个点，发现原代码在部分查询接口上确实用当前登录用户的上下文做了过滤，但有几处列表接口漏了，后来统一补上了。这块属于真实运营中的红线，内容涉及老人隐私，再怎么强调都不为过。
4. 从本地启动到服务器部署：完整步骤和踩坑记录
4.1 本地环境版本匹配是跑通的第一道坎
标题里写了“完整部署教程”，但我实际体验是文本教程写得比较简略，版本匹配问题被严重低估了。我先说结论：如果你用JDK 17去跑一个基于SpringBoot 2.x的项目，大概率会遇到UnsupportedClassVersionError或者某些包在JDK 17下行为变化导致启动失败，反之用JDK 8跑SpringBoot 3.x也不行。稳妥的做法是先看项目的pom.xml文件里spring-boot-starter-parent的版本号，再决定本地的JDK版本。
自己动手部署时，我建议用下面这套环境组合：
| 组件 | 推荐版本 | 备注 |
|---|---|---|
| JDK | 1.8 或 11 | 兼容绝大多数SpringBoot 2.x项目 |
| Maven | 3.6+ | 用于后端依赖下载和打包 |
| Node.js | 14 或 16 | Vite和Vue CLI的版本要求不同 |
| MySQL | 5.7 或 8.0 | 注意字符集设置utf8mb4 |
| Nginx | 1.20+ | 部署前端构建产物并做反向代理 |
打开application.yml，数据库连接串里的localhost:3306要改成你自己环境的实际地址，用户名密码也要改成自己的。数据库账号尽量不要用root，单独建一个库账号并只授权这一个数据库，能减少不少安全事故。导入数据库脚本时用命令行或者客户端工具执行xxx.sql文件，执行完成后检查核心表的数量和带test前缀的测试种子数据，确认至少有一两套能登录的账号。
4.2 后端打包与配置外置
本地开发完成后，把项目打包成可执行jar包的命令很简单：在pom.xml所在目录执行mvn clean package -DskipTests，然后到target目录下找到xxx.jar。直接运行用java -jar xxx.jar，但这个命令有个明显的坑：它会在当前终端窗口阻塞运行，一旦终端关闭进程就没了。需要在服务器上长期运行，建议用nohup或者systemd服务方式。
配置外置是另一个值得提前做的优化。默认情况下，application.yml里的数据库连接和端口是打进jar包里的，如果你改配置就得重新打包。更优雅的做法是在jar包同级的目录下创建一个application.yml覆盖包内的配置，SpringBoot会自动读取外部配置并且优先级更高。我实际部署时会同时把日志文件路径也外置出来，方便排查问题，配置里加上：
logging: file: name: /opt/xxx/logs/app.log这样日志不会写进jar包所在目录，既方便日志清理，也不会因为日志文件乱堆导致磁盘告警。
4.3 前端构建与Nginx反向代理配置
前端项目先执行npm install安装依赖，然后根据项目是Vue CLI还是Vite选择构建命令。构建完成后会生成一个dist目录，里面是纯静态文件，把它上传到服务器的指定目录，比如/opt/xxx/dist。
接着配置Nginx，这是前后端分离项目部署的关键环节。核心要做两件事：第一，将静态请求直接指向dist目录；第二，将/api开头的请求反向代理到后端服务的端口，同时处理好前端路由的history模式刷新问题。下面是一个经过反复验证的配置片段：
server { listen 80; server_name your-domain.com; root /opt/xxx/dist; index index.html; location / { try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }try_files $uri $uri/ /index.html这一行是无数前端项目刷新404的根源解药。Vue Router启用history模式后，访问/elder/list时服务器上并不存在这个物理文件，Nginx先按URI找文件，找不到就把请求回退到index.html，由前端路由兜底渲染。没有这行配置，用户按F5刷新页面就会看到白屏和404，这个坑我在第一次部署时踩得非常深刻，现在每次配Nginx都会条件反射地加上。
4.4 部署后高频出现的四个问题与排查链路
我把自己和其他人在部署过程中遇到的高频问题整理成一个排查表，看到故障现象直接对照排查方向能省很多时间。
| 问题现象 | 可能原因 | 排查步骤 |
|---|---|---|
| 首页能打开但接口请求显示502 | Nginx无法连接后端端口 | 先curl http://127.0.0.1:8080/api/xxx看后端是否存活，再检查后端进程是否挂掉，其次看Nginx的proxy_pass是否写错 |
| 接口返回404 | 前后端路径不一致 | 打开浏览器开发者工具看请求的完整URL，对比后端Controller的@RequestMapping前缀，重点检查/api前缀是否重复拼接 |
| 数据库中文乱码 | 数据库或JDBC连接的字符集问题 | 创建数据库时指定utf8mb4，连接串加useUnicode=true&characterEncoding=utf-8，表的Collation也统一改成utf8mb4_general_ci |
| 登录接口卡住或超时 | 数据库连接池初始化失败 | 检查MySQL端口是否开放，账号是否有远程访问权限，启动日志里是否出现Communications link failure |
这里有一个比较隐蔽的问题想单独说：如果Nginx和SpringBoot在同一台机器上，配置里proxy_pass http://127.0.0.1:8080;通常没问题，但如果部署在云服务器并且启用了防火墙或安全组策略，127.0.0.1访问是绕过了防火墙的，问题不大；可一旦数据库也迁移到另一台机器，就需要在安全组里放行MySQL的3306端口，否则后端启动就会一直报连接超时。线上排查这种问题，建议第一件事先看后端日志文件，日志里任何一点蛛丝马迹都比瞎猜强，然后按“网络通不通→进程活不活→配置对不对”的顺序逐层往下查。
4.5 用systemd把SpringBoot注册成开机自启服务
如果你希望后端进程崩溃后能自动重启、开机自动拉起，用nohup命令是不够的。我推荐把jar包注册成一个systemd服务，只需要新建一个服务文件，写入如下内容：
[Unit] Description=Sunset Apartment Backend After=network.target [Service] User=youruser ExecStart=/usr/bin/java -jar /opt/xxx/app.jar SuccessExitStatus=143 Restart=always RestartSec=10 [Install] WantedBy=multi-user.target保存后执行systemctl daemon-reload，然后systemctl start sunset启动，systemctl enable sunset设置开机自启。这种方式的优势是systemd会监听进程状态，崩溃或异常退出时按配置的间隔自动拉起，配合Nginx的负载能力，日常运营基本不用半夜爬起来处理进程挂掉的问题。刚开始用systemd服务的同学要注意ExecStart里的java路径一定要写绝对路径，用which java查一下，不然会因为找不到命令导致服务启动失败。
5. 拿到源码后的二次开发与扩展方向
5.1 从单公寓模型扩展为多机构平台
这套系统当前的数据模型是单公寓模式的，也就是说一个系统实例管理一个公寓的所有数据。如果想把它改造成一个支持连锁养老机构的管理平台，核心改动落在数据模型上：新增organization（机构）表，然后在elder、room、bed等业务表上增加org_id字段，每次查询都在SQL层强制加org_id = #{currentOrgId}过滤条件，后端通过登录用户的上下文获取当前所属机构。
这个改造听着简单，实际工程量集中在接口改造和页面调整上。挂在org_id字段上的查询如果漏掉任何一个页面，就会发生A机构的工作人员查询到B机构数据的信息越权问题。改造思路建议从外到内一步步来：先给登录接口返回orgId，再给所有列表和详情接口加过滤参数，最后对Service层里所有写操作做统一校验。改造完成后，系统就从单店版变成了多租户版，这个能力在养老运营公司扩张时是非常有价值的竞争力，放到项目经历里也是极其亮眼的亮点。
5.2 新增访客预约与门禁联动模块
养老公寓的日常运营里，访客管理是刚需。家属探访、朋友探望、快递送药，都需要登记和记录。这个系统现在只有家属账号概念，没有完整的访客预约流程，扩展空间很大。最实际的做法是新增一张visit_record表，字段包括：老人ID、访客姓名、联系电话、证件类型、来访时间、离开时间、体温登记、随行物品备注。
前端增加一个访客预约页面，家属可以提前申请，后台审批后生成一个预约二维码。车辆或人员到达门卫处，保安扫码确认就能放行。这个模块最能体现前后端分离的协作价值：家属端、管理端、门卫端三端共用同一套接口，只是页面和权限不同。后端实现上最核心的是“二维码内容如何设计”，建议把预约编码做成一串包含签名信息的字符串，扫码后调用后端接口验签，而不是只在二维码里放一个自增ID，因为自增ID太容易被篡改猜测，安全性会出问题。
5.3 数据可视化与智能预警方向
目前这套系统首页虽然有几个统计卡片，但都是最基础的计数展示。升级方向可以加两个点：一是首页图表化，用ECharts展示近半年的入住率趋势、月度费用收入结构、各楼栋空床分布，这类数据的接口后端几乎不需要新写，基于现有表做聚合查询就行；二是智能预警，比如根据elder表中的紧急联系人字段和nurse_record表里的异常指标，做一个“连续N天心率异常自动通知家属”的规则引擎。
预警功能的本质其实就是定时任务加规则判断。SpringBoot自带的@Scheduled注解定好频率，每天凌晨扫描前一天的护理数据，发现超过阈值就调用消息推送接口通知家属。扩展这个功能时技术难度不大，但业务规则一定要跟运营方确认清楚，迟到通知、漏报通知造成的不良印象比技术Bug严重得多，所以阈值宁可保守也不要激进，宁可多通知也不能漏掉关键异常。
5.4 我建议的代码阅读顺序
最后聊一下如何高效地读懂这种完整项目的源码。我拿到一份陌生项目时，从来不会按文件目录从第一个看到最后一个，那样信息太碎容易迷失。推荐的阅读顺序是从依赖配置入手，先看pom.xml和package.json，快速了解项目用了哪些框架和版本维度；然后看数据库脚本，把二十多张表之间的关系画成简图，理解业务全貌；接着看后端的启动类、全局配置和拦截器，弄清鉴权是怎么穿起来的；再挑一个核心模块跟完整链路，比如走一遍“新增住客”的前端页面、接口调用、Controller处理、Service业务、Mapper查询，这个流程走通之后就掌握了这个项目的开发范式，剩下的模块看速度会越来越快。
实际上，前两到三次阅读我的建议就是对照本文第1章的模块划分，把每个模块对应的表名、页面文件、后端接口找出来，填充到一张表格里。这张表整理完，相当于你自己画了一份项目导航地图，之后无论是改Bug还是加功能，都能快速定位到目标文件。源码学习最大的误区是总想把每行代码都看懂，正确的做法是先抓大脉络，建立起“页面-接口-逻辑-数据”之间的映射关系，细节部分用到哪里再钻到哪里，效率会高出很多。
