电影评论网站这种项目在Java Web毕设里属于常青树了。这几天正好在整理手上一个完整的SpringBoot2 Vue3前后端分离项目就把整个拆解过程记录下来。这个项目源码包含了完整的电影管理、评论回复、评分排行、用户体系、后台管理这几个核心模块配套了详细的设计文档和数据库脚本。我觉得最有参考价值的不只是代码本身而是从需求到落地的完整设计思路尤其是MyBatis-Plus在真实业务里的用法、Vue3组合式API的组织方式、MySQL8.0的建表规范这些东西。这篇内容适合三类人看正在做Java Web毕业设计的同学、想从前端转全栈的开发者、以及想了解前后端分离项目实际长什么样的新手。1. 项目整体定位与技术选型分析先说这个项目的定位。电影评论网站核心业务是围绕电影这个实体展开的用户行为浏览电影、查看详情、写评论、回复评论、给电影打分。这些行为背后需要一个完整的内容管理后台还要有用户注册登录体系。整体来看这是一个典型的内容展示 用户交互 后台管理三层结构复杂度刚好卡在能体现技术深度又不至于失控的位置。1.1 技术栈选型背后的思考选SpringBoot2而不是SpringBoot3第一个原因就是生态成熟度。SpringBoot2.x经过多年沉淀网上资料、踩坑记录、第三方库兼容性都非常完善。尤其对于学生项目或中小型团队项目稳定性比新特性更重要。SpringBoot2.7.x作为一个长期维护版本在性能和稳定性之间找到了很好的平衡。而且大部分毕业设计指导和评审老师对SpringBoot2的熟悉程度更高项目答辩时沟通成本更低。前端用Vue3而不是Vue2核心原因是Vue3在性能上的提升非常明显。Composition API让代码组织方式从按选项类型划分变成了按业务逻辑划分像电影列表的加载逻辑、评论区的分页逻辑可以用setup函数把相关的响应式状态和操作函数放在一起维护比Vue2的data methods computed分离写法直观得多。同时Vue3的响应式系统基于Proxy重写比Vue2的Object.defineProperty在性能上要好对于评论列表这种频繁增删的数据操作整体体验更流畅。MyBatis-Plus在这个项目里扮演的是减少重复劳动的角色。单表CRUD是最容易写又最枯燥的代码MyBatis-Plus的BaseMapper接口直接内置了insert、updateById、selectPage这些通用方法开发阶段能省掉一半的重复代码。但这不意味着放弃SQL控制权复杂的多表联查、统计排行依然用XML自定义SQL搞定项目里最典型的就是电影评分排行榜和热门电影Top10这两条SQL完全手写确保执行效率。MySQL8.0相比5.7有几个实实在在的改进。窗口函数让排行统计SQL写起来简洁很多公用表表达式CTE处理递归评论层级很方便默认的utf8mb4字符集在存储电影简介里带的表情符号时不会报错这些都是实际开发中能感受到的差异。1.2 项目功能模块与服务层次设计整个项目的模块全景图可以拆成三层来看。展示层包含首页轮播推荐、电影列表筛选、电影详情、评论区和用户个人中心。业务逻辑层包括用户的注册登录鉴权、电影信息的增删改查、评论的发表回复和删除、评分的提交和统计聚合。持久层则是对应这些业务实体的数据表和访问接口。服务架构上我采用了经典的前后端分离模式。后端服务单独启动在8080端口提供纯JSON接口前端Vue3项目运行在Vite开发服务器上通过http代理转发请求。这种架构的核心好处是职责单一后端只需要关心业务逻辑和数据处理前端只需要关心页面渲染和交互两边通过约定的接口文档对接。实际开发中两边真的可以并行开工我这边把接口定义好返回结构前端同学直接拿Mock数据开发页面最后联调时统一替换。关于服务分层我也纠结过是不是要搞更复杂的微服务架构但最后从实际需求出发否决了这个想法。项目就几万条数据规模单体应用加合理分层已经完全足够。强行拆分微服务只会增加部署复杂度、网络开销和运维成本同时引入分布式事务、服务注册发现这一堆问题对这样一个项目来说完全是负优化。2. 数据库设计与核心表结构规划数据库设计是整个项目的地基。我见过太多项目代码写得不错结果表结构稀烂关联查询要join五六张表才能拿到需要的数据后期改需求简直是灾难。这个项目的数据库设计原则很简单核心业务表做规范化设计统计查询用冗余字段和缓存表加速。2.1 实体关系梳理与建表规范电影评论网站涉及的核心实体我用五张基础表来表达。用户表t_user存储账号信息和基本资料电影表t_movie存储电影元数据评论表t_comment记录用户对电影的评论内容评分表t_rating存储用户打分记录分类表t_category维护电影的类型标签。建表规范上有几个约定我觉得值得坚持。所有表的主键都用bigint自增不用UUID字符串做主键因为InnoDB索引底层是B树UUID作为主键会产生大量随机IO造成页分裂性能下降明显。每张表都必须有create_time和update_time这两个时间字段MyBatis-Plus的TableField(fill FieldFill.INSERT)注解可以自动填充不需要手动维护。状态字段统一用tinyint0表示禁用1表示启用不要用varchar存正常异常这种字符串浪费空间且无法有效索引。关于外键这个项目里我刻意没有用数据库物理外键只保留逻辑关联。原因很简单物理外键会在每次插入、删除时触发外键检查高并发下容易成为性能瓶颈而且后期做分库分表根本没法迁移。项目里表之间的关联关系通过业务逻辑保证完整性比如删除用户前先删除他的评论记录和评分记录这样既保证数据一致性又不会拖累数据库性能。2.2 核心表结构与索引设计思路用户表结构相对简单重点在唯一索引和密码存储方式。username和email都需要唯一索引防止重复注册。密码字段用MD5加盐存储虽然业界更推荐BCrypt但毕业设计或中小型项目为了演示方便用MD5也够用。不过这种非对称加密的思想要理解数据库里存的不是明文即使数据泄露也无法直接拿到密码。盐值是一个随机的字符串拼在密码后面再做哈希这样两个用户的密码即使相同存出来的哈希值也不一样。电影表是这个系统内容的核心字段相对较多。title字段建普通索引因为电影列表页经常按名称模糊搜索。但模糊搜索的写法有讲究LIKE %关键词%这种写法索引会失效因为前导通配符导致B树无法快速定位改成LIKE 关键词%才能走索引。release_date建索引用于按年份或日期范围筛选rating_score建索引配合排序实现评分榜。评论表是交互最核心的表设计上需要仔细权衡。每条评论通过movie_id关联到电影通过user_id关联到评论人这两个字段必须联合建索引。同时评论表还要支持回复场景用parent_id字段表示父评论ID为0表示一级评论非0表示回复某条评论。查询某部电影的所有评论时排序规则是时间倒序所以movie_id和create_time可以建联合索引。这里movie_id一定要放在左边因为联合索引遵循最左前缀原则任何查询只要包含movie_id条件这个联合索引都能命中。2.3 数据初始化与测试数据准备建完表结构紧接着要准备初始化数据这个环节容易被低估。系统启动时用户还没注册但管理员账号必须先存在否则后台根本进不去。项目里预设了admin/admin123这个默认账号第一次启动后建议立刻登录后台修改密码这是一个很重要的安全习惯。测试数据方面我写了一个数据生成脚本批量插入了50部电影和几百条模拟评论。电影数据来源参考了豆瓣公开的一些元信息包括片名、导演、主演、上映时间、评分等这些数据纯属开发测试用途。模拟评论则通过Python脚本随机组合一些观影感受词汇生成目的是测试评论列表的分页效果和加载流畅度。实际开发测试时建议数据量尽量贴近真实生产规模几百条数据和几万条数据的SQL性能表现完全不是一个量级充分测试才能暴露索引问题和N1查询问题。3. 后端业务逻辑与接口实现详解后端部分用SpringBoot2 MyBatis-Plus搭建核心思路是通用能力框架化业务逻辑独立化。通用能力包括统一返回结果封装、全局异常处理、JWT鉴权拦截器这些做一次配置后续所有功能模块复用。业务逻辑则针对用户、电影、评论、评分四个核心模块独立实现每个模块的service层和controller层各司其职。3.1 统一封装返回结果与全局异常处理前后端分离架构下接口返回的数据结构必须保持一致否则前端处理起来会非常痛苦。项目里定义了一个ResultT统一返回体包含三个字段code状态码、message提示信息、data业务数据。成功时code为200失败时根据情况返回400参数错误、401未认证、404资源不存在、500服务器内部错误这些状态码都和HTTP状态语义对应前端axios拦截器拿到后可以统一处理。全局异常处理是很多人会忽略但实际很重要的设计。SpringBoot里用RestControllerAdvice加ExceptionHandler组合可以拦截所有Controller层抛出的异常。统一异常处理的意义很明显业务代码里只需要专注于正常逻辑错误处理交给全局机制兜底不会出现异常信息直接暴露到前端的情况同时记录完整的异常日志方便排错。3.2 用户认证与JWT拦截器配置用户认证是整个系统的安全基石。这个项目采用了JWTJSON Web Token方案核心逻辑分三步用户注册时密码通过MD5加盐加密存储登录时比对加密后的哈希值匹配成功后服务端生成JWT令牌返回给前端。JWT令牌本质上是一段包含用户信息和过期时间的加密字符串。签名部分用HMAC256算法配合密钥生成篡改会被识别。token附带有效期设置默认24小时过期过期后前端拿到401状态码自动跳转到登录页。这个方案的关键优势是服务端不保存会话状态天然支持水平扩展——这就是它的核心价值多台后端服务器之间不需要同步会话信息任意一台都能校验JWT。实现层面写了两个核心组件JwtUtils工具类负责生成和解析tokenJwtInterceptor拦截器负责校验。拦截器在SpringBoot里通过实现HandlerInterceptor接口注册然后在配置类里添加interceptor.addPathPatterns(/api/**)并排除登录注册接口和白名单接口。这里有一个实际开发中的坑拦截器拦截了静态资源和预检请求导致页面加载不出样式、浏览器控制台报错。解决方案是在Interceptor的preHandle中增加判断如果HTTP方法是OPTIONS直接放行静态资源路径排除在拦截路径外。3.3 评论模块的完整实现逻辑评论模块是整个项目业务逻辑最复杂的部分。实现了两个核心接口发表评论接口POST /api/comment接收movieId、content、parentId三个参数获取评论列表接口GET /api/comment/list?movieIdxxxpageNum1pageSize10。发表评论本身不算复杂核心考量的反而是数据校验。一部电影的评分需要限制在1到10分之间且只能提交一次评论内容不能为空且过滤敏感词。点赞功能用t_comment表增加likes字段记录点赞数虽然简单但需要注意高并发下的数据一致性。实际并发量不大用update t_comment set likes likes 1 where id ?这种原子更新就足够了反复读了再写会导致并发覆盖。获取评论列表这里有一种经典的方法分页查询多级回复处理。先按时间倒序查询一级评论分页得到当前页的评论列表后再批量查询每条一级评论下的所有回复。查询完所有评论后在内存中把回复评论挂载到一级评论的子列表字段中然后返回给前端渲染。这里最需要警惕的是N1查询问题——逐条评论查数据库性能瓶颈会非常明显。正确做法是先批量查出当前页所有一级评论的ID集合再用WHERE parent_id IN (?)一条SQL查出所有回复数据库只需查询两次就解决问题。这个场景特别能体现是否需要真正理解SQL性能优化而不是只会用ORM框架。3.4 电影排行榜与统计报表的SQL实现电影排行榜是整个项目比较出彩的功能点它不需要额外代码逻辑核心价值全在SQL写法上。评分最高的Top10电影那个接口单表就能解决因为t_movie表里已经冗余了rating_score字段直接ORDER BY rating_score DESC LIMIT 10搞定。这个冗余字段在每次用户提交评分时跟着更新用空间换时间避免每次排名都要临时计算平均分。按分类统计各类型电影数量那个SQL直接用GROUP BY category_id配合COUNT(*)。最热门电影Top10则根据评论数排序SQL里需要关联评论表SELECT movie_id, COUNT(*) AS comment_count FROM t_comment GROUP BY movie_id ORDER BY comment_count DESC LIMIT 10。这条SQL在评论表数据量大时可能会慢所以movie_id索引必须建好。实际项目中这类统计查询还可以进一步优化比如把统计结果缓存到Redis或专门的统计表定期刷新但作为单体项目直接查库已经能满足性能需求了。MyBatis-Plus在排行榜这个场景中主要负责的是简单查询复杂SQL在XML文件里手写。项目里在resources/mapper目录下建了MovieMapper.xml通过MapperScan扫描注册。XML里的SQL可以用if标签做动态判断多个可选的筛选条件组合时很优雅避免了拼接String字符串的繁琐和SQL注入风险。4. 前端Vue3工程化搭建与交互实现前端技术栈选择了Vue3 Vite Vue Router Pinia Axios Element Plus这套组合目前是中小型前后端分离项目的主流搭配。Vite的开发热更新效率和秒级启动体验比传统的Webpack配置舒服太多这一点在前后端联调时节省了大量等待时间。4.1 Vite工程初始化与目录结构规划初始化Vue3项目我用的是npm create vitelatest这条命令默认提供Vue3 JavaScript模板。Electron/TypeScript这些依赖在这个项目里用不上所以选择JavaScript对新手更友好前后端分开的语义也更明确。初始化完成后会生成package.json、vite.config.js、index.html等基础文件。目录结构规划上src目录下分成了api、assets、components、router、stores、views这几个子目录。api目录统一放接口请求定义按模块拆文件比如movie.js里放所有电影相关的请求comment.js放评论相关请求。这种做法让接口定义和页面组件解耦页面里只需要引入定义好的请求方法接口改了只需要动一个文件。utils目录放工具函数比如request.js封装axios实例。路由层面项目用了vue-router的createRouter模式配置了Home、MovieDetail、Login、Register、Admin这些页面路由。这里有一个实现技巧值得参考通过动态路由的beforeEach守卫做登录校验判断用户未登录时跳转到登录页并记录原始目标路由登录成功后再redirect回去体验很顺手。4.2 axios封装与请求拦截器配置axios封装这一步做得是否细致直接影响整个前端的开发效率。request.js里创建axios实例设置baseURL为/api通过Vite的代理配置转发到后端服务。请求拦截器里从localStorage获取JWT token写入请求头。响应拦截器统一处理返回结果判断code字段200则直接返回data数据401则清除本地token并跳转登录页其他错误码弹出Element Plus的message提示。一个比较关键的细节是文件上传接口需要单独设置Content-Type: multipart/form-data的请求头。项目里的电影海报上传就是这个场景如果用默认的JSON请求头后端RequestParam接收不到文件。前端和后端要同时注意这个约定。4.3 组件化拆分与El-Pagination分页实现前端页面开发遵循组件化思想每个页面拆成多个功能独立的Vue组件。首页拆成BannerCarousel轮播组件、MovieCard卡片网格、MovieFilter筛选栏三个子组件电影详情页则拆成MovieInfo、RatingWidget、CommentSection三个子组件。每个子组件用defineProps接收父组件传入的数据用defineEmits向父组件抛出事件。评论组件是整个前端交互最复杂的部分。采用reactive维护评论数据和分页信息点击分页按钮时重新请求接口加载完成后把返回的评论列表赋值给响应式数据。这里有一个值得注意的Vue3特性reactive定义的对象直接赋值一个全新数组会丢失响应性因为Proxy代理的引用被替换掉了。两种方案可以解决一种是改用ref定义数组通过xxx.value list赋值ref在修改.value时会保持响应式另一种是用Object.assign或者push逐条添加。这个坑在Vue3开发中非常常见面试也常问值得留意。4.4 角色权限控制与动态路由设计系统区分了普通用户和管理员两个角色。普通用户可以浏览电影、写评论、评分、维护个人资料管理员额外拥有进入后台管理页面的权限可以进行电影增删改、用户管理、评论审核。前端权限控制分为两个层面路由层面后台管理路由通过meta.roles标识允许访问的角色集合路由守卫里判断当前用户角色是否在集合内视图层面普通用户在管理页面只能看到基础信息管理员则显示操作按钮。Pinia是这个项目实现跨组件共享状态方案的最终选择。用户登录成功后把用户信息和token存储到Pinia的userStore中并持久化到localStorage。刷新页面时userStore从localStorage恢复数据不会出现刷新后就丢失登录状态的问题。相比VuexPinia没有繁琐的Mutation和Action区分直接调用action方法修改state心智负担小了很多非常适合中小项目。5. 环境配置、部署联调与常见问题排查这个项目的联调和部署环节我踩了不少坑特别是MySQL8.0和跨域相关的问题。接下来把环境准备、前后端联调过程和遇到的问题逐一整理出来这部分其实是最容易卡住新手的地方。5.1 基础环境搭建与MySQL8.0配置要点环境准备包括JDK8、Maven 3.6、Node.js 16、MySQL 8.0这四个基础软件。开发工具方面后端用IntelliJ IDEA前端用VS Code数据库管理用Navicat或DBeaver。MySQL8.0的配置有几个关键点必须注意。驱动类名从5.x的com.mysql.jdbc.Driver变成了com.mysql.cj.jdbc.Driver这个是最容易忽略的配置错了启动直接报错。连接URL需要串上时区参数serverTimezoneAsia/Shanghai否则JVM默认时区和数据库时区不一致插入时间数据会出现偏差。首次启动前需要手动创建数据库项目里包含了movie_database.sql脚本里面建好了所有表并初始化了数据执行脚本前先确认数据库引擎是InnoDB因为项目里用了事务和外键关联MyISAM引擎不支持这些特性。5.2 SpringBoot配置文件与跨域问题解决后端application.yml配置了数据源、MyBatis-Plus、JWT密钥三块内容。数据源配置里url参数除时区外还要加上useUnicodetruecharacterEncodingutf8强制字符编码正确。MyBatis-Plus配置了SQL日志输出和驼峰命名映射开发阶段开启日志方便调试上线前关闭避免性能损失。跨域问题是前后端分离项目最经典的问题。浏览器同源策略阻止不同端口间的请求前端8081端口请求后端8080端口的接口必须进行跨域处理。项目里通过两种方式解决后端配置了CorsFilter过滤器允许指定来源和请求头的跨域请求前端Vite配置了server.proxy代理开发环境里前端请求/api路径自动代理转发到后端8080端口有代理转发后浏览器以为是同源请求跨域问题也就不存在了。生产环境下前端打包后的静态文件由Nginx托管Nginx中配置反向代理到后端服务也同样优先走同源策略从这个角度规避了跨域风险。5.3 Docker部署与常见问题速查部署方式如果想快速体验可以直接docker-compose up -d一键启动MySQL 后端 前端三个容器。项目里准备了Dockerfile文件用于构建后端镜像和前端Nginx镜像容器编排相对简化方便部署到云服务器。根据实际部署和联调的情况我整理了这样一份常见的错误速查表现象原因分析解决方案后端启动报ClassNotFoundException: com.mysql.cj.jdbc.Driver驱动版本太低或未引入mysql-connector-java依赖pom.xml添加依赖并确认版本是8.0.x连接数据库报Public Key Retrieval is not allowedMySQL8.0默认认证插件是caching_sha2_password非SSL连接时需要FQDN校验URL末尾加allowPublicKeyRetrievaltrue前端报跨域CORS error错误后端CORS配置未加OPTIONS放行或Vite代理配置写错后端加options方法放行前端检查代理路径评论列表加载很慢查询评论未走索引或出现N1查询EXPLAIN分析SQL执行计划确认movie_id联合索引生效登录后刷新页面token消失Pinia未持久化或localStorage未同步登录成功后写入localStorage初始化时读取恢复上传海报图片404静态资源路径映射未配置SpringBoot中添加资源映射器将虚拟路径映射到实际目录5.4 前后端联调接口格式约定联调是整个开发流程中最容易出现混乱的阶段角色划分不清晰容易消耗大量时间。项目里通过一份简单的接口约定极大减少了对齐成本。所有接口返回统一Result结构分页查询返回total和records两个字段时间字段统一用yyyy-MM-dd HH:mm:ss字符串格式。约定好后端和前端按此标准各自mock开发同时按约定格式输出使得先生成前端页面并自测再对接联调效率提升明显。联调中还有一个细节是调试技巧。后端接口写好后先用curl命令或Apifox工具测试一遍确认接口正常再交给前端对接。排查问题时打开浏览器开发者工具Network标签页可以查看请求的Request URL、Request Headers、Response Body三个关键信息基本大多数问题都能通过这三个信息定位到。前端报错看Console面板后端报错看IDEA控制台两大日志判断定位是前后端分离开发最大的调错帮手。6. 安全防护、性能优化与实用性扩展项目核心功能跑通后安全加固和性能优化还有不少功课。这块容易被当成锦上添花但实际上直接关系到系统是否经得住真实环境考验。6.1 SQL注入防御与XSS过滤SQL注入是最常见也是危害最大的安全威胁。项目里三层防护联动MyBatis-Plus的内置方法全部使用预编译PreparedStatement参数绑定XML里的SQL禁止字符串拼接全部用#{}占位符。${}表达式虽然比#{}灵活但会直接拼接SQL片段一旦被利用后果不堪设想除了表名、排序字段等确实需要动态指定的场景其余地方一律不用。XSS过滤方面前端在提交评论和电影信息时做了脚本标签和事件处理器的过滤后端同样加入过滤逻辑防止恶意内容存储入库。实现方式是继承OncePerRequestFilter重写doFilterInternal方法对请求参数统一做HTML转义处理。这个过滤器对整个后台管理交互层面都很重要防止富文本内容和评论数据携带恶意的onclick、script等字符串影响到其他用户页面。6.2 数据层优化与热点接口缓存策略数据库层面的优化首选是打开慢查询日志。MySQL8.0里通过SET GLOBAL slow_query_log ON开启配合long_query_time 1参数超过1秒的SQL全部记录下来。项目优化过程中抓出过一条开发环境不明显的慢SQL用户详情页关联查询用户信息、评论数、评分三张表因为没用联合索引全表扫描了。优化方式是调整索引结构和拆分查询分三次独立查询整体响应时间从900ms降到了100ms以内。热点数据缓存是性能优化的大杀器。电影排行榜和热门电影这两个接口在用户打开首页的瞬间必然会被高频调用。项目里实现了简单缓存逻辑用一个静态HashMap加定时任务每10分钟刷新一次排行榜数据这样数据陈旧性在可接受范围内响应速度却有数量级的提升。因为不是极度高并发场景用本地内存缓存加定时刷新这种轻量方案已经足够引入Redis反而增加了运维复杂度。6.3 JWT安全策略与用户会话管理调优JWT虽然好用但也有一些特性需要权衡。token是无状态的服务端无法直接让某个用户的token失效所以项目里设计了简单的token版本号方案用户表增加token_version字段JWT中包含当前版本号修改密码或者管理员强制下线账号时版本号递增旧token带上旧版本号校验时自然失效。密码存储升级这个点上上面我也提到了粗糙的MD5加盐方案在测试开发中可用如果项目要真正商用上线建议升级为BCrypt算法。Spring Security的BCryptPasswordEncoder或者Shiro的Sha256Hash都支持这个算法每次生成的hash值随机加盐即使数据库泄露破解成本也大幅提高。后期可以保留旧的MD5校验逻辑做好兼容过渡再逐步引导存量用户重新设置密码。6.4 电影推荐简单实现与后期扩展方向最近热度比较高的推荐算法也在项目里做了一个简化版的实现。基于用户历史评分记录找出用户打分最高的电影分类然后推荐该分类下评分最高的电影。这套冷启动阶段效果还行新用户没有历史数据时系统直接返回全局热门电影榜单也能保障基础的用户留存感。推荐接口单独封装在RecommendService里核心逻辑不过几十行代码后续可以平滑替换成协同过滤算法。扩展方向上这个系统还可以继续加入缓存中间件Redis来大量缓存热点数据接入Elasticsearch做全文搜索优化电影名模糊查找的性能瓶颈引入WebSocket实现评论区的实时推送模式。每一步扩展的核心驱动都是业务数据规模和用户量的真实需求没有出现为了技术而技术的无意义架构。信息架构设计上当前的单体架构本身就是最容易维护和扩展的起点等到业务真的到了一个程度再去考虑拆微服务也不迟。做这个前后端分离的完整项目相当值得。我开发过程中的体会是这类系统真正的核心不在代码本身而在于架构它的正确思维方式。数据建模的合理性才是一切的定盘星接口设计的规范性决定了前后端协作体验SQL性能优化决定了系统能撑到多大体量。用户在真实环境里的路径、操作成本和边界情况都在提醒开发者要同时深度理解需求侧和实现侧。最后分享两个我的个人经验。第一个Postman或Apifox这类接口调试工具不仅仅是测试工具完全可以当成接口文档的载体每个接口把参数说明、返回示例、错误码都写清楚比单独维护一套文档系统实用得多。第二个写完项目记得补一个完善的自述文件把启动步骤、数据库初始化方法、默认账号密码、部署注意事项都写进去。放两个星期再回头打开项目靠的就是这份记不清视角的记录帮助你快速恢复上下文认知。