这几年接手的Java Web毕设项目里基于SpringBoot的陪诊服务平台系统算是一个业务覆盖很典型的方向。它表面上只是个服务平台但把用户端、陪诊师端、管理端三个角色的权限体系、订单全流程状态流转、评价机制都串在了一起业务深度刚好够用又不会复杂到让人望而却步。我拿到这套源码、配套说明文档lw、部署文档和讲解视频的时候第一反应是这东西很适合拿来当作从零理解一个完整Web系统怎么落地的教材。这篇博文我就以这个陪诊服务平台为例子把业务设计、技术实现、部署细节和源码学习路线一次性讲透不管你是要做类似毕设还是想搞明白一套SpringBoot项目该怎么从代码变成线上服务都能省不少力气。1. 项目全貌先搞清楚这是一个什么样的系统1.1 陪诊服务平台的业务定位陪诊服务这几年在一二线城市增长很快核心场景就是帮助老年人、异地就医人群、孕妇或者没时间陪家人看病的上班族完成挂号取号、排队缴费、取药送检这类跑腿事项。这个平台系统做的事情就是把这些服务从线下口头约定搬到线上用户发布需求陪诊师接单平台做撮合并管理履约过程。很多人第一眼看到陪诊平台会以为它只是给病人找个陪跑的人实际拆开看完全不是这样。平台要处理的核心对象是订单订单又牵扯出用户、陪诊师、医院、服务项目、支付、评价一堆关联数据。整套系统至少包含三个子业务域用户服务、交易服务、运营管理。这也是为什么很多课程设计和毕业设计都愿意选这类题目因为它麻雀虽小五脏俱全SpringBoot、MyBatis-Plus、MySQL、Redis这些主流技术都能用上而且有明确的业务逻辑可以进行答辩讲解。1.2 三类角色与核心业务流程这个系统的角色划分非常清晰一共三端对应三种完全不同的人平台用户患者或家属注册登录、完善个人信息、发布陪诊需求选择服务类型、预约时间、填写备注、浏览陪诊师信息、下单、支付、查看服务进度、服务完成后评价。陪诊师注册并提交资质认证、平台审核通过后接单、查看待接单和进行中的订单、确认开始服务、确认完成服务、查看自己的服务评价和收益记录。平台管理员用户管理、陪诊师资质审核、服务分类管理、订单监管、投诉处理、数据统计。核心流程可以抽象成一条主线用户提交需求 - 平台生成订单 - 陪诊师接单 - 到院服务 - 确认完成 - 用户评价。这条链路里最需要花心思的是订单状态的流转。订单不会只有一个待接单和已完成两个状态中间至少得有待付款已支付待接单已接单待服务服务中待完成确认已完成已取消已退款这么几个节点。订单状态机一旦设计清楚整个项目的主心骨就稳了。1.3 交付物里都有什么这套项目交付的东西比较全不只是丢给你一段能跑的代码。主要的四样东西各有用处源码完整的SpringBoot项目前后端分离或混合模式取决于原工程结构我手上这份是标准的SpringBoot Thymeleaf/前端静态资源结构重点在后端逻辑。配套文档lw也就是通常说的说明文档/论文包含需求分析、可行性分析、数据库设计、系统测试等章节。这部分在毕设场景里价值很高因为答辩时老师问的很多为什么这么设计的问题文档里都有对应阐述。部署文档环境要求、初始化脚本、启动步骤、服务器部署注意事项。这份文档的含金量在于能让你少踩很多环境坑。讲解视频/讲解笔记逐模块讲解业务逻辑和代码实现对理解项目帮助最大。我第一次拿到这套东西时是先看部署文档把项目跑起来再看讲解文档理清业务流程最后才一行行读源码这个顺序建议新手直接照抄。2. 技术选型为什么选SpringBoot全家桶2.1 选择SpringBoot而不是其他框架的底层逻辑做这类管理信息类系统可以用的技术方案其实很多传统SSH、SSM、SpringBoot、甚至Python的Django都能做。但这个项目选择了SpringBoot而且从实用性角度看这是最合理的选择原因有几点。第一SpringBoot极大降低了配置成本。传统SSM要写一堆XML配置文件数据源、事务、MyBatis映射都要手动装配光是搭建环境就能劝退一半新手。SpringBoot用自动配置把大部分样板代码吃掉了你只需要在application.yml里写几行配置加上依赖就能跑起来。对于业务逻辑为主的信息管理系统来说把精力花在配置上是一种浪费SpringBoot正好解决这个问题。第二生态太成熟。登录鉴权有Spring Security或JWT方案持久层有MyBatis-Plus这种增强工具缓存有Redis文件上传、邮件发送、定时任务这些都有现成starter。开发一个陪诊平台这种规模的项目几乎所有需求都能在Spring生态里找到对应的组件。第三部署运维简单。SpringBoot内嵌Tomcat打包成jar包直接java -jar就能跑。对于团队协作或者交付给客户部署这种方式最省心。我后面讲部署文档时会专门提到这个项目的部署流程基本就是装JDK、装MySQL、改配置、跑jar半小时能搞定。2.2 项目整体技术栈和目录结构从我这份源码来看技术栈是标准的SpringBoot 2.x MyBatis-Plus MySQL Redis JWT前端使用了Thymeleaf模板引擎加部分静态页面。目录结构上如果没有做前后端分离controller层直接返回视图名称渲染页面如果做了前后端分离则返回JSON数据。这套项目是后者为主接口都设计成了RESTful风格。典型的源码包结构是这样的com.xxx.accompany ├── controller // 接口层接收请求、参数校验、返回结果 ├── service // 业务层核心业务逻辑事务控制在这里 │ └── impl // 业务实现类 ├── mapper // 数据访问层MyBatis-Plus的Mapper接口 ├── entity // 实体类对应数据库表结构 ├── dto // 数据传输对象接口入参出参封装 ├── vo // 视图对象前端展示数据封装 ├── config // 配置类拦截器、跨域、Redis配置等 ├── common // 通用类统一返回结果、异常处理、常量等 └── utils // 工具类JWT工具、日期处理等这种分包方式是SpringBoot项目里最常见也最稳妥的。实体类entity只做数据映射DTO做接口参数校验和传递VO做前端展示数据封装三者分开是很多新手容易忽略的地方。这个项目在这点上做得规范读代码的时候能明显感受到每一层各司其职。搭配的版本信息我也建议按部署文档来SpringBoot 2.7.x配JDK 8或11最稳定千万别一上来用SpringBoot 3.x那个要求JDK 17很多老代码和新依赖会有兼容问题。2.3 关键依赖配置解析项目的pom.xml里核心依赖基本是这几类dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3.1/version /dependency dependency groupIdcom.auth0/groupId artifactIdjava-jwt/artifactId version3.19.2/version /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-redis/artifactId /dependencyMyBatis-Plus这里多说一句它提供分页插件、通用CRUD、条件构造器代码量可以少写一大半。比如分页查询订单列表不用手写SQL和PageHelper配置直接用Page对象加LambdaQueryWrapper就能实现。对于陪诊平台这种表多、查询条件灵活的系统MyBatis-Plus很合适。Redis在这个项目里的应用主要有两处一是缓存登录token二是缓存热点数据比如服务分类列表。你可能会问JWT本身已经无状态了为什么还要用Redis存这涉及到主动失效token的需求比如用户修改密码或者管理员封禁账号后需要让旧token立即失效。纯JWT做不到这一点配合Redis存储就灵活得多。这个设计在答辩时是个不错的亮点能体现对安全性的思考。3. 数据库设计与核心业务实现3.1 核心数据表结构设计思路陪诊平台的数据库表不算多但关联关系比较典型。我梳理一下最核心的几张表用户表user用户id、账号、密码bcrypt加密存、姓名、手机号、身份证号、角色标识、头像、状态。角色我这里直接放在用户表用字段区分因为三端用户数量规模不大拆三张表反而冗余。陪诊师表escort陪诊师id、关联用户id、服务区域、服务类型、从业年限、资格证书、审核状态、评分、接单数。这张表是为了扩展陪诊师专属信息而拆出来的符合第二范式。订单表order订单号、用户id、陪诊师id、服务类型、预约时间、医院名称、科室、详细地址、金额、订单状态、创建时间、完成时间。服务类型表service_type分类id、分类名称、分类描述、排序。比如陪同就诊代取报告陪伴输液等服务项目。评价表evaluation评价id、订单id、用户id、陪诊师id、评分、评价内容、回复内容。支付记录表payment支付id、订单id、支付金额、支付方式、支付状态、回调参数。订单表是整张逻辑网的枢纽建表时一定要把订单状态字段的设计考虑清楚。我建议不要用字符串直接存状态含义而是用数字编码加常量类的形式。比如0待付款、1已支付待接单、2已接单、3服务中、4待确认、5已完成、6已取消、7退款中。这样做的好处是判等时用order.getStatus() 1这种写法可读性高而且状态延伸时扩展性也强。我在读源码时看到作者的订单状态常量和状态机方法都写在OrderStatusEnum里整体设计很规范。3.2 登录认证与权限控制的落地实现登录这块用了SpringBoot拦截器加JWT。流程是这样用户提交账号密码后端校验通过后生成一个tokentoken里面封装了userId、角色类型、过期时间然后用密钥签名响应给前端。前端每次请求在请求头带上Authorization: Bearer token拦截器校验token合法性并把用户信息放入ThreadLocal供后续逻辑使用。权限控制这里有个关键点不同角色能访问的接口必须隔离。管理员能调用户管理和审核接口普通用户不能陪诊师能调接单相关接口用户不能。这个项目用的方案是拦截器里做角色判断在需要进行权限控制的Controller方法上加自定义注解比如PreAuthorize(role ADMIN)或者直接在拦截器里根据请求URL的前缀来区分。实际中小型项目用拦截器注解就够了不需要引入Spring Security因为它太重学习成本高答辩讲起来也费劲。权限控制还有一个常见坑是跨域。前端页面跑在8080端口后端接口可能在8081如果不配置CORS跨域浏览器会拦掉所有请求。在WebMvcConfig里加一个跨域配置就能解决Configuration public class WebConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }如果以后部署到线上建议把allowedOriginPatterns(*)改成具体的域名避免安全隐患。这个细节在部署文档里也有标注。3.3 订单状态机整个系统最值得研究的模块订单状态流转是这个系统里技术含量最高的部分它不涉及复杂算法但要保证在各种操作顺序下状态都不出错。整个状态机我从代码里捋出来的流转规则是用户提交需求后创建订单状态为待付款。用户支付成功后状态变为已支付待接单。陪诊师接单后状态变为已接单待服务。陪诊师点击开始服务状态变为服务中。陪诊师点击结束服务状态变为待用户确认这里就是平台履约完成。用户确认完成后订单变为已完成同时触发评价入口和陪诊师收益结算。用户支付前取消订单状态变为已取消不需要退款流程。支付后如果陪诊师接单前用户取消走退款流程状态变为退款中退款完成后变为已退款。这套状态机在设计上把每个变更都收敛到订单服务的一个方法里比如cancelOrder(orderId, userId)、acceptOrder(orderId, escortId)任何对订单状态的修改都必须走这些方法不允许在Controller里直接setStatus。这样做的好处是状态的合法转移都集中在某几个服务方法里后续加需求或者排查问题时非常清晰。给你看一段核心的接单逻辑体会一下这种写法Transactional(rollbackFor Exception.class) public boolean acceptOrder(Long orderId, Long escortId) { Order order orderMapper.selectById(orderId); // 只有待接单状态才能被接单 if (order null || !order.getStatus().equals(OrderStatusEnum.WAIT_ACCEPT.getCode())) { throw new BusinessException(当前订单状态不可接单); } // 不能接自己的订单 if (order.getUserId().equals(escortId)) { throw new BusinessException(不能接自己的订单); } order.setEscortId(escortId); order.setStatus(OrderStatusEnum.ACCEPTED.getCode()); order.setAcceptTime(new Date()); orderMapper.updateById(order); // 更新陪诊师接单数量 escortService.increaseOrderCount(escortId); return true; }这个方法上有Transactional事务注解加锁的问题需要注意。如果是单机部署这样写没有问题因为MySQL默认的update操作有行锁两个陪诊师同时接同一个订单时第二个人的selectById拿到的可能是旧数据然后update时被阻塞。如果真要完全杜绝超卖式并发问题可以加SELECT ... FOR UPDATE悲观锁或者用Redis分布式锁。这个点可以作为一个进阶优化去思考但目前这个项目的并发量级上面的写法已经够用。3.4 支付与评价模块的简化处理真实的在线支付要对接微信或支付宝涉及商户号、证书、回调验签一堆东西对毕设项目来说太重了。这个项目的做法很聪明用一个模拟支付接口代替真实支付用户点击支付后直接跳转到模拟收银台输入任意内容后端直接调用支付成功回调逻辑把订单状态从待付款改为已支付待接单。我在部署时看过这段代码支付服务里定义了统一的PaymentService接口里面有两个实现类MockPaymentServiceImpl模拟支付RealPaymentServiceImpl预留真实对接。如果你后续要接微信支付只需要实现接口里的pay()和callback()方法就行业务层不用改。这种面向接口设计的思路值得学习。答辩时你可以说考虑到演示环境无法使用真实商户号支付模块做了抽象设计预留了真实支付对接能力这比硬怼一个假的支付流程要加分。评价模块和订单是强关联的每个已完成订单只能评价一次数据库里通过订单id的唯一约束来保证。评价完成后还要同步更新陪诊师的综合评分这个用SQL的AVG聚合函数或者Redis的ZSET都可以。这个项目用的是先插入评价记录再UPDATE escort SET score (SELECT AVG(score) FROM evaluation WHERE escort_id ?)简单直接。4. 从源码到运行部署文档到底该怎么看4.1 本地启动三步走拿到项目源码第一件事不是打开IDE读代码而是先把项目跑起来。部署文档里写得比较清楚我按自己的操作经验重新捋一个更顺的步骤第一步初始化数据库。用MySQL工具执行项目sql目录下的accompany.sql脚本有些项目会存多个脚本执行顺序必须注意。先执行建库建表脚本再执行初始化数据脚本。如果执行完发现控制台报错说表不存在多半是脚本顺序反了或是在该手动建库的时候没建。第二步改配置文件。打开application.yml核对数据源配置spring: datasource: url: jdbc:mysql://localhost:3306/accompany?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver redis: host: localhost port: 6379本机如果没有Redis要么装一个要么先把Redis相关配置注释掉。有些版本连登录都依赖Redis缓存用户信息所以最好还是装一个Windows下直接下载压缩包解压运行redis-server.exe就行不用安装。第三步启动项目。用IDEA打开工程等待Maven依赖下载完毕找到主启动类AccompanyApplication直接右键运行。看到SpringBoot的Banner和Started AccompanyApplication in x.x seconds字样就说明启动成功了。之后打开浏览器访问登录页用部署文档里给的初始账号测试一下管理员、用户、陪诊师这三个账号都要试一遍。4.2 服务器部署的几个关键点本地跑通之后部署到服务器是另一个考验。这个项目的部署文档里介绍了两种方式一种是直接在服务器上装环境用java -jar运行另一种是用Docker容器化。我推荐先用第一种因为它更接近底层逻辑出了问题好排查。打包之前有个必须检查的地方application.yml里如果是application-prod.yml这类多环境配置要确认当前激活的是哪个profile。我遇到过不少人在本地是dev环境连自己电脑的MySQL打包时没切换部署到服务器后一直报数据库连接失败。经验是打包前先搜索所有配置文件里的localhost、127.0.0.1统一改成线上数据库的内网地址和密码。然后在项目根目录执行mvn clean package -DskipTests等构建成功后在target目录下会生成accompany-0.0.1-SNAPSHOT.jar。把这个jar包上传到服务器执行启动命令nohup java -jar accompany-0.0.1-SNAPSHOT.jar --spring.profiles.activeprod app.log 21 启动后查看日志确认是否有报错。如果服务一直起不来最常见的是端口被占用排查命令是netstat -tlnp | grep 8080找到占用进程后kill掉再重启。4.3 部署文档里被忽略的配置细节部署文档里有一些容易被初学者忽略的点单独拿出来说一下。一是数据库时区问题如果服务器和数据库不在同一时区时间字段会差8个小时jdbc:mysql://连接串里必须加serverTimezoneAsia/Shanghai。二是文件上传路径陪诊师的资质证书图片上传要写到服务器磁盘的某个目录比如/opt/uploads部署文档里建议把这个路径配置到应用外的目录不要放在jar包同级目录因为jar更新时容易丢失。三是日志级别生产环境建议把logging.level.root设为infocom.xxx.mapper设为warn否则每个SQL都会打到日志里日志文件会膨胀得很快。还有一点部署文档里提到的数据库密码加密问题值得一做。直接用明文密码写在配置文件里在真实项目里是禁忌可以引入jasypt-spring-boot-starter对数据库密码和Redis密码做加密处理应用启动时用密钥解密。这个项目虽然没做但作为部署加固手段你自己完全可以加上属于小而美的亮点。5. 实战中踩过的坑与排查技巧5.1 常见异常速查表我根据自己实操中遇到的问题整理了一份和这个项目强相关的异常排查速查表异常现象可能原因处理方式启动报Failed to configure a DataSource数据源配置缺失或数据库没启动检查application.yml中的url、用户名、密码确认MySQL服务已启动接口请求返回Whitelabel Error Page后端抛了未捕获的异常查看后端日志用统一异常处理器兜底返回JSON前端页面正常但接口请求404前后端路由冲突或Controller路径写错检查Controller的RequestMapping路径和前端请求路径是否完全一致JWT登录后接口返回401token过期或拦截器放行路径配置错误查看JWT工具类的过期时间检查Interceptor中excludePathPatterns放行了登录接口上传图片报磁盘空间不足服务器上传目录空间耗尽或权限不对使用df -h查看磁盘chmod设置上传目录权限页面中文乱码数据库表编码不是utf8mb4执行ALTER TABLE xxx CONVERT TO CHARACTER SET utf8mb4订单状态总是不按预期流转定时任务或手动改库导致状态不合法回归状态机逻辑禁止直接SQL修改status字段5.2 几个我实际踩过的坑第一个坑是MyBatis-Plus的字段映射问题。数据库表里有个字段叫order_status实体类属性叫orderStatus正常情况下驼峰命名会自动映射。但如果全局配置里驼峰映射没开或者字段名带了特殊前缀查询结果里这个字段就一直是null然后订单状态判断全部失效表现为用户永远无法支付。排查这类问题很简单在启动日志里打开MyBatis的SQL输出看查询结果集的列名和实体类属性对应关系是否正常。第二个坑是拦截器放行路径没配好。登录接口本身也需要用户提交token才能访问这就是典型的拦截器把登录接口也给拦截了。启动项目后访问登录接口一直401排查方式是把拦截器的excludePathPatterns(/user/login, /user/register)这些路径打印出来或者直接临时把拦截器注释掉看接口能否访问快速定位是不是拦截器的问题。第三个坑是Redis序列化问题。用RedisTemplate存储用户对象时如果不指定Jackson序列化器默认会使用JDK序列化存储进去的内容是一堆乱码而且取出来强转类型时还会报ClassCastException。部署文档里建议用GenericJackson2JsonRedisSerializer替换默认的序列化方式但很多同学的代码是copy的没有注意这个细节。做登录缓存前先set一个简单的字符串value测试Redis连接是否正常再测试对象存取这样能少走很多弯路。第四个坑是关于数据库连接池的。项目默认用的HikariCP连接池本地跑没什么感觉线上并发一高就会报Connection is not available, request timed out。排查方向是看连接池最大连接数和MySQL的max_connections是否匹配。如果是个人服务器内存紧张把HikariCP的maximum-pool-size从默认的10调到5反而更合理。5.3 答疑时容易被追问的疑难点用这个项目做毕设或者答辩的时候有几个点经常被追问我提前把思路给出来。为什么订单表不直接把陪诊师信息冗余进去而要关联陪诊师表回答思路是遵循数据库范式减少数据冗余。如果直接把陪诊师姓名、手机号冗余进订单表陪诊师改了手机号后历史订单里的信息就错了。查询时用连表查询性能完全够用因为单表数据量在这个业务规模下不大。为什么用Redis而不是只用JWT做登录态回答思路是JWT无状态但无法主动失效用户注销、改密、封禁等场景需要token立即失效Redis存储可以实现主动剔除。另外Redis还能顺带做接口防刷限流通过INCR配合过期时间实现每个用户每分钟最多请求N次这也是安全加分项。支付回调如何保证安全性虽然项目是模拟支付但这个问题的思路要提前准备。真实对接时回调接口要验签、要校验订单金额和商户订单号一致、要处理重复回调的幂等性订单状态已经是已支付就不再重复处理。用数据库的唯一约束或者分布式锁都能实现幂等。6. 这份源码怎么用才能物尽其值6.1 高效阅读源码的路线图这套项目加上说明文档和讲解视频信息量其实不小。如果一股脑从controller开始一行一行读很容易陷入细节出不来。我建议按下面这个顺序读第一步读数据库脚本。花两小时把所有表结构看一遍脑海中建立起表之间的关系。不理解表就理解不了业务这一步省不了。第二步打开项目从启动类开始然后看config包下的配置类。重点看哪些配置了拦截器、哪些配置了跨域、哪些配置了Redis序列化。配置类决定了整个应用的骨架先看骨架再看血肉。第三步找一个完整的业务链路读代码。推荐从用户下单 - 支付 - 陪诊师接单 - 完成这条主线入手。这条链路上会经过controller、service、mapper三层能把这个链路读通这个项目你就掌握了一半。第四步补充读剩余的模块。订单和支付之后优先级是用户登录鉴权、陪诊师审核、评价模块、后台统计。这几个模块彼此独立按自己的兴趣读就行。6.2 在现有源码上可以扩展的优化点如果你不想只是照着源码跑通想做出一点自己的东西来可以考虑下面这些扩展方向在答辩或者项目展示时也能明显区别于原始工程。一个是加消息通知功能。用户下单、陪诊师接单、服务完成这些节点都可以借助SpringBoot整合WebSocket或者接入第三方推送服务用站内信或短信通知相关角色。这个扩展不复杂但能显著提升系统的完整感。另一个是加数据统计报表。管理端目前只有基础的信息管理可以扩展基于ECharts的可视化大屏统计每日订单量、服务类型分布、陪诊师接单排行、区域需求热力图。技术上就是写几个聚合SQL再搭一套前端图表效果却很加分。再一个是对接真实地图服务。陪诊师接单时可以展示医院位置和距离排序用户查看陪诊师时可以按距离筛选。用高德或腾讯地图的Web服务API就可以不需要引入重型的GIS框架。这个扩展能让平台更接近商业产品的真实形态。如果你的目标是学SpringBoot而不是做毕设那这套源码的价值就更大了。它只是一个中规中矩的业务系统没有高并发、没有分布式、没有微服务但它把SpringBoot项目从开发到部署的全过程串了起来。读懂它之后再去看网上那些杀猪盘项目秒杀系统之类的进阶教程你就能理解那些复杂技术到底是在解决什么问题了。6.3 拿到开源同行项目时的通用检查清单既然提到源码学习顺便分享一个我自己拿到任何SpringBoot开源项目时都会过的检查清单这套逻辑也适用于这个陪诊平台检查pom.xml用了哪些依赖判断项目新旧程度和关键技术点检查application.yml里的配置项确认启用了哪些starter、profile是什么检查是否有单元测试测试代码覆盖了哪些核心业务检查全局异常处理器是否存在Controller里是否直接捕获Exception检查是否有定时任务、异步任务、消息队列等额外组件检查日志打印是否规范核心业务入口有没有info级日志检查数据库脚本是否包含初始化数据没有初始化数据的话很多页面打开是空白的这些项不用每一个都详细研究但过一遍之后你对这个项目的成熟度会有一个基本判断后续读代码的时候心里就有谱了。我在实际使用这套陪诊平台源码时最大的体会是一个项目能不能让你学到东西不在于它用了多少新技术而在于它的业务逻辑是否完整、代码结构是否清晰。这个项目的订单状态机、三端权限划分、支付接口抽象这几块设计都很值得细品尤其是状态机那段我建议你拿到代码后自己在纸上画一遍状态流转图再对着代码验证收获会比单纯看视频大得多。最后再分享一个小技巧部署文档里如果找不到数据库初始账号密码直接在sql脚本里搜INSERT INTO语句所有初始账号都在初始化脚本里写着不用满世界问人要。