看到“Java Web 大健康养老公寓管理系统”这个项目名的时候我想起前两年帮一家养老机构做信息化摸底时碰到的真实情况几十位老人的健康档案还在用纸质表格护理员交接班靠口头传达床位和费用全靠人工登记。今天聊的这个项目正是用 SpringBoot2 Vue3 MyBatis-Plus MySQL8.0 这套 Java Web 主流技术栈把大健康养老公寓管理系统完整搭起来源码和文档都齐整。如果你正在找毕业设计题目或者想拿一个能直接落地的后台管理系统练手这套项目挺合适的。下面我从业务设计、后端工程、前端工程、数据库安装到快速跑通按一个真实项目的拆解思路一条条讲清楚。重点是不仅告诉你“这个系统里有什么”更要把“为什么这么设计、跑起来会遇到什么坑、怎么改造成自己的项目”都说明白。1. 为什么养老公寓管理系统值得用这套Java Web技术栈1.1 “大健康”三个字决定了系统不是简单增删改查普通的后台管理系统比如图书管理、员工考勤本质上是单据和台账的流转表结构相对简单。但养老公寓管理系统不一样它前面挂的是“大健康”三个字这意味着系统要同时承担两件事一是传统运营管理比如床位、房间、收费、餐饮、护理排班二是连续性的健康数据管理比如老人每天的血压血糖、服药的医嘱、慢病随访结果、异常体征预警。这两类数据是互相咬合的。举个例子一位老人入院时要先做健康评估评估结果决定他的护理等级护理等级又决定每月应收的护理费护理员每天执行的照护任务又来自护理等级对应的照护计划。如果只做几张表存数据系统跑起来会到处是窟窿。一个好的养老公寓系统像这样“业务数据驱动运营、健康数据驱动照护”的闭环关系必须从表结构设计开始理顺。这也是我拿到这类源码项目时第一个会去核对的地方老人档案、健康评估、护理任务、费用账单这几张核心表之间是不是真的有逻辑关联而不是各自独立存着玩。1.2 后端为什么选SpringBoot2而不是SpringBoot3或微服务可能有人会问现在SpringBoot3都出来了这项目怎么还用SpringBoot2答案是现实使然。企业生产环境和教学项目里使用最广、资料最全、坑最少的就是SpringBoot2.7.x系列尤其是JDK8SpringBoot2.7的搭配在2025年的今天依然是Java Web领域的基本盘。SpringBoot3强制要求JDK17起步很多老项目依赖的中间件、第三方库未必跟进到位换过去容易踩兼容性雷。至于为什么不是Spring Cloud微服务道理更简单。养老公寓管理系统的体量通常就是一个机构或一个集团内部的信息化平台几十张表、每天几百次操作单体应用完全扛得住。微服务带来的服务注册、配置中心、链路追踪、分布式事务在这个场景下不是收益而是运维负担。单体架构前后端分离部署只需要一个后端jar包和一个前端静态站点排查问题也轻松得多。这个“合适就好”的选型思路比盲目追新重要得多。1.3 数据层用MyBatis-Plus而不是Spring Data JPA的逻辑很多人纠结MyBatis-Plus和Spring Data JPA怎么选。简单讲JPA是“对象关系映射”的思路你定义好实体关系框架自动帮你生成SQLMyBatis-Plus是“增强MyBatis”的思路你写SQL框架帮你省掉通用CRUD和繁琐样板代码。对于养老公寓这种管理类系统查询条件千变万化经常要按时间段、按状态、按护理等级组合筛选还要出各种统计报表MyBatis-Plus的条件构造器用起来特别顺手。举个例子按月统计某护理等级的老人数量JPA需要写JPQL或者Specification而MyBatis-Plus可以这样QueryWrapperElderInfo wrapper new QueryWrapper(); wrapper.select(health_level, COUNT(*) as cnt) .groupBy(health_level) .eq(status, 1);这种半SQL半对象的方式既保留了SQL的灵活又不用手写一堆重复的insert、update、selectById。国内团队对MyBatis生态本身就熟接手成本低。这不是说JPA不好而是就这套系统的实际需求而言MyBatis-Plus更顺手。1.4 MySQL8.0和Vue3在这套系统里的角色MySQL8.0这个选型没有争议原因有两点。第一8.0是目前主流默认版本支持窗口函数、公用表表达式CTE、JSON操作函数做健康趋势分析这类统计时很方便比如用窗口函数算某个老人近三个月血糖值的变化趋势第二配套生态成熟SpringBoot2.7和MyBatis-Plus对8.0支持良好网上教程一搜一大把遇到问题有地方查。前端选Vue3则看重组合式API和Element Plus生态。后台管理系统的页面高度套路化表格、表单、弹窗、标签页。Vue3的setup语法让逻辑复用更利索Element Plus提供了现成的组件库开发效率比Vue2时代高不少。Vite做构建工具热更新也快。这套组合放在“Java Web大健康养老公寓管理系统”这个场景里是经过市场验证的成熟搭配。2. 业务模块设计从老人档案到收费结算的数据闭环2.1 老人档案与入住流程先把核心表设计对做这类系统的第一步一定是把老人档案这张核心表设计好。一般叫elder_info字段除了姓名、性别、身份证号、出生日期这些基础信息一定要带上两个关键域护理等级和入住状态。CREATE TABLE elder_info ( id BIGINT PRIMARY KEY AUTO_INCREMENT, elder_no VARCHAR(32) NOT NULL COMMENT 老人编号, name VARCHAR(50) NOT NULL COMMENT 姓名, gender TINYINT COMMENT 1男 2女, id_card VARCHAR(18) COMMENT 身份证号, birth_date DATE COMMENT 出生日期, health_level TINYINT COMMENT 1自理 2半自理 3全护理, admission_date DATE COMMENT 入住日期, status TINYINT DEFAULT 1 COMMENT 1在住 0退住, emergency_contact VARCHAR(50) COMMENT 紧急联系人, emergency_phone VARCHAR(20) COMMENT 紧急联系电话, create_time DATETIME, update_time DATETIME, INDEX idx_status (status), INDEX idx_health_level (health_level) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT老人档案表;这里有个设计细节容易被新手忽略紧急联系人和联系电话不要存在一个contact字段里一定要拆开。因为后续做家属通知功能时要单独用手机号字段发短信、打电话联系人。如果当初合并了后面还得拆表迁移。入住流程通常包括预约登记、到院评估、分配床位、签订协议、建立健康档案。一套完整的源码应该在这张表上能看到admission_date、room_id、bed_id这些字段的联动逻辑而不是只存一个静态的“已入住”状态。2.2 健康档案和慢病管理让体征数据变成可用的业务数据健康模块是“大健康”这个前缀最直接的体现。核心表是体征记录表一般叫health_record记录老人每天或者每次测量的血压、血糖、心率、体温等数据。设计时要注意不要每个体征项建一张表那样查询时要用大量的关联和拼接性能差还不方便。更合理的做法是一行代表一次测量记录指标字段按需扩展。CREATE TABLE health_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, elder_id BIGINT NOT NULL COMMENT 老人ID, record_date DATE NOT NULL COMMENT 测量日期, systolic_pressure INT COMMENT 收缩压, diastolic_pressure INT COMMENT 舒张压, blood_glucose DECIMAL(5,1) COMMENT 空腹血糖, heart_rate INT COMMENT 心率, temperature DECIMAL(4,1) COMMENT 体温, remark VARCHAR(255) COMMENT 备注, create_time DATETIME, INDEX idx_elder_date (elder_id, record_date) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT体征记录表;真正能拉开项目档次的是在这个模块上叠加“业务判断”。比如当最新一条血压记录超过阈值时自动打上异常标记并在护理任务中生成一条“复测血压”的待办。这个逻辑看起来不难但多数演示项目只会做记录和列表查询不会做异常触发。慢病管理可以单独建chronic_disease_follow_up表用elder_id、disease_type、next_follow_up_date三个字段支撑随访计划。每次健康评估和随访记录都跟上一次形成对比就能做出“健康趋势”的展示效果这也是答辩或者项目汇报时最容易出彩的点。2.3 床位资源和护理任务的联动资源和人力怎么调度床位管理是养老公寓最典型的资源管理场景。一张bed_info表要维护房间号、床号、床位类型普通/特护、当前状态空置/占用/维修。入住分配床位时系统要把床位状态从“空置”改成“占用”并在elder_info中回填bed_id。别小看这个状态流转很多项目就是在这里出现数据不一致老人资料显示在住床位却是空置后台一对账就露馅。护理任务表则负责把护理计划拆成可执行的任务。每个任务包含老人、护理员、任务类型翻身、喂饭、体征测量、服药提醒、计划时间、实际完成时间、完成状态。护理员可以在移动端或网页端列表看到“今天要做的事”做完一项勾一项。这比纸质交接班单清晰得多也方便管理者统计每个护理员的工作量。2.4 膳食、费用、家属端等辅助模块完整性的试金石膳食管理主要管三样东西老人的饮食禁忌和过敏原、每日食谱、订餐记录。elder_diet表记住“低盐低脂”“忌海鲜”这类信息厨房打菜的时候能查到这是加分项。费用管理则是整个系统的“算账”中枢。一般一张fee_record表记录每笔费用类型床位费、护理费、餐饮费、医疗费关联老人和账单周期。收费规则的自动计算比较麻烦比如不同护理等级对应不同单价按月生成账单允许中途入住按天折算。部分项目会直接用人工录入账单来规避这个复杂度但对于想把这个项目当做毕业设计或实际交付的人来说我建议至少做一条“按护理等级自动生成月度费用”的逻辑这个功能最能体现你对业务的理解程度。家属端如果有通常是让家属查老人的健康和账单动态。没有家属端的话也要在核心表里预留家属联系方式字段和一个简单的短信通知接口位方便后续扩展。很多完整度高的源码项目在这一点上都花了心思。3. 后端SpringBoot2工程的组织方式与MyBatis-Plus配置细节3.1 为什么坚持前后端分离不再做JSP模板渲染很容易看到有人在问“SpringBoot2怎么集成JSP目录”。这个问题在今天的这类项目里其实已经过时了。一个前后端分离的系统后端SpringBoot只负责提供REST接口前端Vue3负责页面渲染二者通过JSON通信。好处很实在后端和前端可以并行开发后端接口写好了用Swagger直接调试前端跑在Vite的5173端口再代理到后端8080没有JSP那种模板和Java代码缠在一起的麻烦。某种程度上看到项目描述里明确写了Vue3就意味着这个项目不太可能用JSP做视图如果强行把JSP集成进来反而破坏了前后端分离的架构。这套系统里后端典型的包结构是这样com.example.elderly ├── common // 统一返回结果、异常处理、工具类 ├── config // MyBatis-Plus配置、跨域配置、拦截器配置 ├── controller // 接口层 ├── service // 业务层接口和实现 ├── mapper // MyBatis-Plus Mapper接口 ├── entity // 数据库实体 ├── vo // 视图对象给前端返回的DTO如果源码项目把vo单独放一层说明作者考虑过接口返回结构的问题。一个低质量的CRUD项目往往直接把实体对象entity返给前端外键字段、创建时间一堆冗余数据全暴露出来既不安全也不优雅。3.2 MyBatis-Plus的XML与Mapper同目录配置两种方案实测这个点真的要单独拿出来讲因为被问得太多。MyBatis-Plus项目里Mapper接口和XML文件的位置有两种常见部署方式。方案一把XML统一放在src/main/resources/mapper/目录下这是默认推荐。在application.yml配置mybatis-plus: mapper-locations: classpath*:mapper/**/*.xml type-aliases-package: com.example.elderly.entity configuration: map-underscore-to-camel-case: true这种方案的好处是编译打包后XML随resources一起被拷贝到classes目录不会出现找不到XML的问题。方案二把XML放到和Mapper接口同一个包目录下即src/main/java/com/example/elderly/mapper/ElderInfoMapper.xml。这么做代码内聚性看着好但必须改Maven的打包配置否则XML根本不会被包进jarbuild resources resource directorysrc/main/java/directory includes include**/*.xml/include /includes /resource /resources /build我实测下来方案二在IDE里跑着没问题但打成jar包部署后容易翻车尤其是多人协作时有人忘了改新模块的打包范围。所以除非源码项目本身设计如此否则我建议新代码一律用方案一XML和Mapper接口之间用命名空间和com.example.elderly.mapper.ElderInfoMapper对应起来就够了。3.3 统一返回结构、全局异常和分页后端工程的基建三件套判断一个SpringBoot2源码项目的工程化水平我会先看三样东西有没有统一的返回结构、全局异常处理器、分页插件。统一返回结构一般长这样{ code: 200, msg: success, data: ... }。前端axios拦截器统一判断code不用每个接口重复处理错误分支。全局异常处理器用RestControllerAdvice捕获业务异常和参数校验异常返回同样格式的错误结构。没有这个机制数据库报错会把堆栈信息直接吐给前端既难看又不安全。MyBatis-Plus分页很容易漏配置。只引入依赖是分不了页的必须注册分页插件Configuration public class MybatisPlusConfig { Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); PaginationInnerInterceptor pagination new PaginationInnerInterceptor(DbType.MYSQL); pagination.setMaxLimit(500L); interceptor.addInnerInterceptor(pagination); return interceptor; } }漏掉这步的典型表现是selectPage方法查出来有数据但total为0或者所有记录一次性返回。这个坑几乎每个用MyBatis-Plus的人都踩过拿到含文档源码后先检查这块能省很多调试时间。4. 前端Vue3项目的代理、组件与样式问题综述4.1 用Vite创建Vue3项目并解决跨域代理前端部分如果是基于Vite构建的Vue3项目创建项目通常一条命令搞定npm create vitelatest elderly-frontend -- --template vue项目跑起来后最常遇到的第一个问题就是怎么连接后端。浏览器的同源策略会阻止前端从5173端口直接调8080端口的接口除非后端开启了跨域。更优雅的做法是在Vite里配置代理把/api前缀的请求转发到后端// vite.config.js import { defineConfig } from vite import vue from vitejs/plugin-vue export default defineConfig({ plugins: [vue()], server: { port: 5173, proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } })这样前端请求/api/loginVite代理转发到http://localhost:8080/api/login。后端接口如果有统一的前缀比如/api最好保持这个约定。实测中changeOrigin: true一定要加不加在部分服务器环境下会出会话Cookie和Host校验问题。4.2 axios请求封装与token处理逻辑管理系统的所有请求基本都要带登录凭证。把axios统一封装一次很有必要各页面不要重复写请求头逻辑。import axios from axios import { ElMessage } from element-plus const request axios.create({ baseURL: /api, timeout: 10000 }) request.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers.Authorization Bearer token } return config }) request.interceptors.response.use( response { const res response.data if (res.code ! 200) { ElMessage.error(res.msg || 请求失败) return Promise.reject(new Error(res.msg)) } return res }, error { if (error.response error.response.status 401) { localStorage.removeItem(token) window.location.href /login } ElMessage.error(error.message || 网络异常) return Promise.reject(error) } ) export default request这里有个实际经验响应拦截器里不要直接返回response要返回response.data。很多项目正式开发时所有接口都已经按res.data写好了如果拦截器忘了剥壳页面拿到的就是一个AxiosResponse对象所有字段访问都变成undefined排查时非常容易让人怀疑人生。4.3 后台管理页面的组件封装思路表格、表单、弹窗Vue3后台管理页面高度重复左侧菜单、顶部栏、中间表格、弹窗表单。一个高质量源码项目通常会把表格和弹窗封装成组件而不是每个页面都铺一段重复的el-table。我的习惯是封装一个ProTable组件外部传入columns配置数组和请求函数组件内部处理加载状态、分页、刷新、多选。每个业务页面只需要写配置和数据源代码量能减少一半。封装的时候要注意v-model的用法和expose暴露刷新方法这是Vue3组合式API里比较容易用错的地方。4.4 Element Plus的tabs标签页样式修改:deep()能解决一大半问题后台管理系统里常常用el-tabs切换不同老人的详情、不同月份的账单数据。Element Plus默认样式在视觉上偏冷很多项目需要改成自己品牌的主色调。问题是样式写在style scoped作用域里普通类选择器直接改不动组件内部元素这就是样式穿透该上场的时候style scoped :deep(.el-tabs__item) { color: #666; } :deep(.el-tabs__item.is-active) { color: #2b7a4b; font-weight: 600; } :deep(.el-tabs__active-bar) { background-color: #2b7a4b; } :deep(.el-tabs__nav-wrap::after) { background-color: #e8e8e8; } /style:deep()里写的是组件内部实际渲染出来的类名比如el-tabs__item、el-tabs__active-bar。如果发现改了不生效先按F12看目标元素真实类名再确认层级对不对。一般常见需求改激活字体颜色和底部横条上面这段就够用。如果你拿到的源码里有Vue2时代遗留的或者/deep/写法建议统一改成Vue3的:deep()因为老写法在一些构建配置里会警告甚至失效。5. MySQL8.0从安装到连接的实用避坑清单5.1 三条安装路线Windows安装包、Ubuntu的apt、Docker容器MySQL8.0的安装问题被问得极多我直接把三条常用路线给你理清楚。Windows下最简单的是下载安装包MSI一路Next记得选“Developer Default”或自定义只装Server和Command Line Client。装完在安装器里设置root密码即可。如果你下载的是zip绿色版需要用管理员终端执行mysqld --initialize-insecure mysqld --install net start mysql mysql -uroot -p--initialize-insecure会生成一个root空密码实例进库后再改密码ALTER USER rootlocalhost IDENTIFIED BY 你的新密码;Ubuntu下用apt装最省事sudo apt update sudo apt install mysql-server sudo systemctl status mysqlUbuntu新版MySQL的root默认使用auth_socket插件所以命令行里执行sudo mysql可以直接进但用Navicat、DBeaver这类远端工具连不上。需要切认证方式sudo mysql ALTER USER rootlocalhost IDENTIFIED WITH mysql_native_password BY 你的新密码; FLUSH PRIVILEGES;Docker方案适合不想污染本机环境的开发者。一条命令拉起8.0实例docker run --name elderly-mysql \ -e MYSQL_ROOT_PASSWORDroot \ -e MYSQL_DATABASEelderly_health \ -p 3306:3306 \ -d mysql:8.0 \ --character-set-serverutf8mb4 --collation-serverutf8mb4_0900_ai_ci这个命令创建了root密码和名为elderly_health的数据库同时把字符集默认成utf8mb4。实测中经常有人忘了指定字符集建出来的表默认latin1中文存进去全是乱码回头还一头雾水。5.2 新建数据库时的字符集和排序规则很多人初始化数据库时随便选个字符集这是后来中文乱码的根源。MySQL8.0里强烈建议使用utf8mb4它完整支持中文和emoji虽然系统里一般不用emoji但utf8mb4是通用选择。建库的SQL最好显式声明CREATE DATABASE elderly_health DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;排序规则里utf8mb4_unicode_ci和utf8mb4_0900_ai_ci实际使用差别不大按团队习惯选一个统一即可。重点是所有表、所有字符字段的字符集要保持一致否则多表关联查询时索引会失效速度肉眼可见地变慢。5.3 连接MySQL8.0的三大高频坑时区、SSL、驱动版本SpringBoot2连接MySQL8.0时application.yml里的数据库URL写得不对启动就会报错。最常见的三个坑第一时区问题。MySQL8.0默认使用UTC而我们的系统在东八区不指定时区的话时间差值八个小时日志里还会出现The server time zone value is unrecognized的警告。解决方式是在URL上加serverTimezoneAsia/Shanghai。第二SSL问题。本地开发环境通常没必要启用SSL不关掉的话某些驱动版本会连本地也强制校验报SSL connection error。URL上加useSSLfalse即可。第三驱动类名和依赖坐标。SpringBoot2.7之前用com.mysql.jdbc.Driver和mysql-connector-javaSpringBoot2.7开始官方把Maven坐标改成了com.mysql:mysql-connector-j驱动类名用com.mysql.cj.jdbc.Driver。如果依赖坐标和驱动类名不匹配启动时大概率报Cannot load driver class。一份标准的连接配置长这样spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/elderly_health?useUnicodetruecharacterEncodingUTF-8useSSLfalseserverTimezoneAsia/ShanghaiallowPublicKeyRetrievaltrue username: root password: rootallowPublicKeyRetrievaltrue也是MySQL8.0专属的一个坑。8.0默认认证插件是caching_sha2_password某些客户端第一次连接时需要获取服务端公钥不加这个参数会报Public Key Retrieval is not allowed。用Navicat或低版本JDBC驱动连不上时先加上这个参数试试大概率能解决。6. 拿到含文档源码如何快速跑通与进行二次开发6.1 先读文档还是先看代码我的习惯是三步走拿到一套含文档的源码项目很多新手着急双击启动类这是最容易劝退的做法。数据库还没建、配置文件还没改、前端依赖还没装启动必然报错。我的习惯是三步走第一步花十分钟看文档目录和README特别是“环境要求”和“快速启动”章节确认JDK版本、Maven版本、Node版本要求。第二步打开application.yml和前端.env文件把数据库地址、端口、账号密码记下来对照检查本机环境是否匹配。第三步找SQL脚本通常是schema.sql或data.sql先导入数据库再启动后端。这三步走完系统能跑起来的概率已经从三成提到九成。6.2 启动项目的完整流程与常见报错快速定位一个标准的前后端分离项目完整启动流程大概是这样的创建数据库并执行SQL脚本修改后端application.yml中的数据库账号密码在项目根目录执行mvn spring-boot:run或直接启动主类确认后端日志出现Started Application且端口8080可用前端目录执行npm install如果node_modules拉不下来先检查npm源执行npm run dev浏览器访问Vite输出的地址一般是localhost:5173这里最容易出的两类问题一个是端口被占用。检测后端8080或前端5173端口被谁占了用netstat -ano查PID或者直接改配置文件的端口。另一个是npm安装时依赖版本冲突。比如在Node 18或更高版本上跑老项目可能会遇到vue3相关依赖编译报错或TypeScript类型检查问题尤其若依那套vue3 ts的脚手架模板项目如果用的老版本Vite在Node 20下经常报错。优先锁定住依赖版本别盲目升级。如果前端启动正常但登录时接口报404或跨域优先检查Vite代理配置和后端上下文路径。很多项目在application.yml里设置了server.servlet.context-path: /api那么代理target就不要把/api路径拼重复。6.3 二次开发从一个“巡房记录”模块说起完整套路示例拿到源码做二次开发最忌讳上来就ctrlc大改。我更推荐从新增一个小功能模块开始比如“巡房记录”模块走一遍完整链路。新建数据库表inspection_record字段包括id、elder_id、inspector_id、inspection_time、body_condition、remark、create_time。后端新建entity、mapper、service、controller四层。Mapper接口继承BaseMapperInspectionRecordService实现类用ServiceImpl。Controller提供/inspection/list分页查询和/inspection/add新增接口按项目原有的统一返回结构包装。前端在视图目录下新建inspection/index.vue套用项目封装好的表格组件配置列字段接上axios请求。这一套走完一个上午就能完成一个小模块。关键是全程模仿项目现有代码风格——它返回结构怎么设计的你也怎么设计它前端组件怎么传参你也跟着传。项目现有代码就是最好的规范文档。如果你要对现有模块做二次开发比如给健康档案加一个“异常提醒”的自动计算逻辑建议先找到体征记录对应的service实现类在新增体征数据的方法里加上阈值判断然后调用护理任务服务生成一条待办。注意事务边界尽量保持在同一个service方法内完成避免跨服务调用后事务不一致。最后再说几句个人体会这套系统的核心价值不在技术多新而在于把“大健康”和“养老运营”两个领域的业务逻辑理顺了。技术栈本身是Java Web领域的大众组合但能把这个组合用好、把业务细节设计扎实才是真正拉开差距的地方。我自己在复现这类项目时最深的体会是不要被前端框架的酷炫效果带偏先把核心表的关联关系想清楚再逐层搭后端、连前端最后补统计分析这类锦上添花的模块。如果你接手这套源码是为了学习建议照着“老人档案 → 健康记录 → 护理任务 → 费用账单”这条主线读代码这条链路读通了整个系统的设计思路也就清楚了。最后分享一个实用技巧跑通了之后记得把本地数据库导出一份带测试数据的SQL放在项目目录里同时写一份启动说明文档记录你本机改过的配置。这样不管是自己团队协作还是以后回看这套项目都能省掉大量重复踩坑的时间。
