企业官网建设流程全解析

第一次看到“基于Java SpringBoot个人博客系统博客相册（源码+文档+运行视频+讲解视频）”这个标题时，我第一反应不是“又一个毕设项目”，而是先替作者算了一笔账：Spring Boot做后端、博客系统做业务骨架、相册模块做文件处理、外加文档和两套视频，这套组合几乎把一个Java Web学习者需要碰的东西全串起来了。如果你正打算做一个类似的个人项目，或者刚学完Java基础想找个“能跑、能讲、能写进简历”的练手目标，这篇文章想跟你聊聊这个标题背后具体藏着哪些技术点、哪些坑，以及拿到类似项目后应该怎么真正消化它。

这类项目最大的价值不在于“博客”本身——写文章、发评论、管理分类，这些都是再经典不过的增删改查。真正值得拆开看的是相册模块：文件上传、磁盘存储、缩略图处理、访问路径映射，再加上权限控制，这一条链路几乎覆盖了企业级Web开发里最常见的文件处理场景。我见过不少同学把项目跑起来后只会点页面，问到“图片传上去之后存到哪了”就卡住。这篇内容就是想把这类问题一次性讲透，顺便聊聊源码、文档、视频这一整套交付物到底应该怎么用，才不算浪费。

1. 一个标题里藏着的完整技术栈：这个项目到底在做什么

先别急着打开代码，把标题拆开看一遍，其实信息量非常大。“基于Java SpringBoot”锁定了技术栈，“个人博客系统”说明了业务形态，“博客相册”点明了核心亮点模块，“源码+文档+运行视频+讲解视频”则暗示了交付标准。这一连串东西加起来，本质上是一套完整的、可演示、可讲解的Web应用项目。

1.1 Spring Boot在标题里的分量有多重

Spring Boot是当前Java后端开发事实上的主流起步框架。它在Spring框架之上做了大量自动配置，让开发者不需要再手动去写一堆XML配置，也不需要自己纠结Tomcat怎么部署——一个main方法就能把整个应用跑起来。它的核心理念是“约定优于配置”，也就是框架给出一套默认行为，你只需要在偏离默认规则时显式配置。

在这个博客系统项目里，Spring Boot承担的角色比表面看起来要多得多：

• Web层：通过内嵌Tomcat提供HTTP服务，处理浏览器的页面请求和接口请求。
• 数据层：整合MyBatis或Spring Data JPA，让操作数据库变得简单直接。
• 模板渲染：配合Thymeleaf（或者前后端分离时的REST API），把后台数据变成用户能看到的页面。
• 静态资源管理：博客里的图片、CSS、JavaScript，都依赖Spring Boot的静态资源映射规则。

为什么市面上的个人博客项目几乎清一色选择Spring Boot而不是SSH（Struts+Spring+Hibernate）或者纯Servlet？因为SSH那套配置太繁琐，纯Servlet的开发效率又太低。Spring Boot用最少的配置，把“能用”和“好用”之间的差距填平了。对于学习者和交付验收场景来说，Spring Boot能让你把精力集中在业务逻辑本身，而不是跟框架配置斗争一下午。

1.2 博客系统+相册模块：为什么这个组合是“黄金搭配”

个人博客系统的常规模块无非是：用户注册登录、文章发布与编辑、文章分类、标签管理、评论互动、站点统计。这些模块覆盖了典型的CRUD（增删改查）场景，而且业务逻辑直白，非常适合作为Java Web的练兵场。

但单独的博客系统有个问题——它太“平”了，所有功能都是表单和列表的变体。加上相册模块之后，项目瞬间多了一个维度：文件上传与存储。相册模块带来的技术挑战立刻让项目层次丰富起来：

• 图片上传时的文件类型校验、大小限制、文件名处理；
• 图片存储到磁盘后，如何通过URL访问到它；
• 列表页加载大量缩略图时，怎么减少流量消耗和加载延迟；
• 相册的公开/私有属性，如何和登录用户的权限关联。

别小看这些点，它们每一个都是真实企业项目里一定会遇到的问题。一个同时包含内容管理（博客）和文件管理（相册）的项目，在验收和简历上展示出来的“业务完整度”，远高于只写一个增删改查的 demo。

1.3 从交付物反推项目规范程度

“源码+文档+运行视频+讲解视频”这种交付组合，说明项目不是随手写完就扔的，而是按照“能被别人接手”的标准整理的。源码对应代码实现，文档对应设计思路和部署说明，运行视频证明它能真实跑起来，讲解视频则是帮你理解它为什么这么写。

我个人一直认为，对一个项目最好的检验方式，不是“我能不能运行起来”，而是“我能不能讲清楚”。如果你的代码里有一个功能模块，你能用十分钟把它拆开讲明白，那这个模块你是真的掌握了；如果只能照着视频复述，那大概率还没吃透。这套交付物组合，恰恰就是为了服务“讲清楚”这个目标。

2. 相册模块开发的核心链路：从表设计到上传处理的完整思路

相册模块是整篇内容里最值得展开的部分。我见过很多项目的相册功能只是“上传图片+展示图片”两个页面，内部细节经不起追问。这里把一条相对完整的链路拆开，从数据库设计讲起，到上传处理，再到访问映射，尽量把每一步的决策逻辑也说出来。

2.1 数据库设计：相册和图片怎么放，决定了业务的上限

相册模块至少要两张表：相册表和图片表。这两张表的关系是一对多——一个相册可以包含多张图片，一张图片只属于一个相册。设计上通常有四个核心字段组：

• 归属字段：相册属于哪个用户，图片属于哪个相册；
• 展示字段：相册名称、描述、封面图；图片的原始文件名、存储文件名、访问路径；
• 状态字段：相册是公开可见还是仅自己可见，图片是否被逻辑删除；
• 时间字段：创建时间、更新时间，方便按时间排序。

一个典型的图片表结构大概长这样：

为什么存储文件名要单独用一个UUID，而不是直接用原始文件名？因为用户上传的文件名可能包含中文、空格、特殊字符，而且不同用户可能上传同名文件，直接用原始名存磁盘，覆盖和乱码问题会接踵而至。用一个UUID重命名文件，后缀保留原始后缀，既保证了唯一性，也避免了对文件名做各种转义处理的麻烦。

相册表相对简单一些：id、user_id、name、description、cover_url、visibility（0公开/1私有）、created_at、updated_at。这里需要特别考虑的是封面图的来源——最省事的方案是用相册里第一张图的缩略图地址作为封面，但这要求每次上传图片后判断“这个相册还没有封面吗？有就补上，没有就跳过”。也可以允许用户手动设置封面，逻辑会复杂一些，但体验更好。

2.2 上传接口的设计：Controller层之外，还要处理哪些事

很多人一想到上传，就以为写一个接收MultipartFile的Controller方法就完事了。真实业务里远不止这些，最少还要做四件事：

说得直白一点，文件上传的入口必须做校验，但不能只依赖前端校验。前端可以限制只能选jpg、png，但接口是可以被直接调用的，后端如果不校验，任何类型文件都能进服务器，这就是隐患。

校验规则里，扩展名白名单是最基础的一层，比如只允许jpg、jpeg、png、gif、webp。更严格一点还要校验MIME类型（通过文件头而不是Content-Type字段），因为恶意文件可以把exe改名成jpg。不过对于个人博客和学习项目，做到扩展名+文件大小双重校验已经比大多数项目扎实了。

存储路径的规划同理。我见过有人把图片直接平铺在一个目录下，文件一多管理起来非常痛苦。建议按/uploads/相册ID/年/月/这层结构来组织，或者按用户ID分目录。这样既能避免单目录文件过多，也方便后期迁移和排查问题。文件名用UUID.后缀生成，可以彻底避开同名冲突。

下面是核心上传逻辑的一段参考实现，我用Java伪代码拆解了主要步骤，但需要注意，不同版本、不同ORM框架下写法会有差异，这类项目一般会引入MyBatis-Plus简化数据操作：

public UploadResult uploadImage(MultipartFile file, Long albumId) { // 1. 校验是否为空 if (file.isEmpty()) { throw new BusinessException("文件不能为空"); } // 2. 校验扩展名白名单 String ext = getExtension(file.getOriginalFilename()); if (!allowExtSet.contains(ext.toLowerCase())) { throw new BusinessException("不支持的图片格式"); } // 3. 校验大小，这里限制为5MB if (file.getSize() > 5 * 1024 * 1024) { throw new BusinessException("图片大小不能超过5MB"); } // 4. 生成存储文件名，并决定目录 String storageName = UUID.randomUUID().toString().replace("-", "") + "." + ext; String relativeDir = "/uploads/" + albumId + "/" + LocalDate.now().format(DateTimeFormatter.ofPattern("yyyy/MM")); // 5. 保存原图 + 生成缩略图 File targetFile = new File(rootPath + relativeDir, storageName); FileUtil.mkParentDirs(targetFile); file.transferTo(targetFile); String thumbName = createThumbnail(targetFile, ext); // 6. 写数据库记录 Photo photo = new Photo(); photo.setAlbumId(albumId); photo.setOriginalName(file.getOriginalFilename()); photo.setStorageName(storageName); photo.setUrl(relativeDir + "/" + storageName); photo.setThumbnailUrl(relativeDir + "/" + thumbName); photo.setSize(file.getSize()); photo.setContentType(file.getContentType()); photoMapper.insert(photo); return new UploadResult(photo); }

这段逻辑里有两个容易忽略的点：一是getExtension不能用String.split(".")直接截取，因为文件名可能没有后缀，也可能有多个点，更稳妥的做法是取最后一个点之后的部分，并判断是否存在；二是transferTo的目标目录如果不存在，第一次上传会直接报错，所以要先创建父目录。这些问题不踩一遍坑很难意识到。

2.3 缩略图方案：列表页能不能快，全看这一步

相册列表页一般会一次性展示几十张图片。如果直接加载原图，一张3MB的照片，十张就是30MB，页面会慢到怀疑人生。业界通用做法是生成缩略图，列表页显示小图，点击后才加载原图。

缩略图工具在Java生态里比较轻量的选择是Thumbnailator，几行代码就能把图片压缩到指定尺寸。比如统一生成宽度为400像素、等比缩放的缩略图，同时把质量压缩到0.8，这样通常能把一张几MB的图压到100KB以内，页面加载速度会快非常多。

还有个业务细节：相册封面直接复用缩略图，不要单独把原图再复制一份当封面。封面在列表页显示，用缩略图就够了，避免一个相册多占用一份原图大小的磁盘空间。

缩略图命名习惯上加个_thumb后缀，存储到同一目录。这样数据库只需要保存url和thumbnail_url两个相对路径，不需要额外维护文件名映射关系。

2.4 访问权限：相册不是单纯的“图片堆”

相册的公开/私有属性决定了访问控制策略。公开相册，任何人都能看；私有相册，只有创建者自己登录后能看。实现上有两种常见思路：

• 简单方案：在Controller层手动判断。查询相册前先查它的visibility字段，如果是私有相册，再校验当前登录用户是不是创建者。适合项目里用户体系比较简单的场景。
• 进阶方案：走Spring Security或拦截器，在请求到达Controller之前统一做权限校验。适合想体现安全设计能力的项目。

我倾向于在个人博客项目里用拦截器+手动判断的折中方案。拦截器统一处理“哪些路径需要登录”，相册访问时再比对用户ID。这套逻辑够用了，而且好理解，答辩时一两句话能讲清。硬上Spring Security不是不行，但如果对Security本身不熟，为了加权限引入一堆不懂的配置，遇到问题反而更难排查。

3. Spring Boot在这个项目里承担的整体角色：为什么它让开发变快

相册的部分讲完，把视角拉回整个项目。理解Spring Boot在这个博客系统里扮演的角色，不能停留在“它能少写配置”这个表面印象上，得知道它到底替我们做了哪些决策。

3.1 自动配置与Starter机制：少写配置背后的原理

以前用Spring开发Web项目，要配置web.xml、配置Spring容器、配置MyBatis、配置事务管理器、配置视图解析器……每一个环节都可能因为版本不匹配而踩坑。Spring Boot把这一堆东西浓缩成了几个“启动器”（Starter），你引入一个spring-boot-starter-web，它就把Spring MVC、内嵌Tomcat、Jackson（JSON处理）等依赖全部带进来，并触发对应的自动配置逻辑。

自动配置的核心逻辑是：框架在classpath里发现某个依赖存在，就自动装配相关Bean；如果没有，则跳过。它利用@Conditional的一系列注解来实现“有则配置，无则跳过”。这个设计让项目的启动成本变得非常低，也让“约定优于配置”从一句口号变成了真实机制。

在这个博客项目中，自动配置带来的直接好处是：你不需要关心Tomcat是怎么启动的，不需要给Spring MVC配视图解析器，不需要手动创建DataSource——只要在application.yml里写上数据库连接信息，一切就位。这个“少写配置”不是黑魔法，它只是把常见场景的默认值提前帮你填好了。

3.2 三层架构与依赖注入：博客系统的骨架是怎么搭的

典型的Spring Boot项目分三层：

• Controller层：接收请求、绑定参数、调用Service、返回结果或页面。
• Service层：写业务逻辑，比如发布文章前检查标题重复、上传图片前生成缩略图。
• Mapper/Repository层：操作数据库，封装SQL或继承BaseMapper。

三层架构的价值在于解耦。Controller不写具体业务，只做调度；Service不碰数据库细节，只调Mapper接口；数据层只顾数据读写。这样任何一个层发生变化，其他层不需要跟着改动。比如把MyBatis换成JPA，理论上只影响Mapper层，Service层根本不用动。

依赖注入则解决了对象创建和组装的问题。Service需要用到Mapper，只需用@Autowired或构造器注入声明，Spring容器会自动把实现塞进来。新手最容易犯的错误是到处new对象，结果对象之间耦合严重，想拆都拆不开。我在这个项目里建议坚持构造器注入或者@RequiredArgsConstructor，因为显式声明依赖后，测试时替换实现类会非常方便。

3.3 为什么持久层选MyBatis-Plus比JPA更合适

博客系统里有很多按条件查询的场景：按分类查文章、按用户查相册、按状态查评论。持久层的选型直接影响写代码的体验。

Spring Data JPA上手快，但复杂查询要用@Query写JPQL，动态条件拼接也比较别扭。MyBatis-Plus则在我印象里更符合国内开发者的习惯——实体类注解少，BaseMapper自带常用的增删改查，复杂查询可以写XML或Wrapper，动态条件用LambdaQueryWrapper非常顺手。

举个例子，查询某个用户公开相册的列表，MyBatis-Plus的写法大概是：

LambdaQueryWrapper<Album> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(Album::getUserId, userId); wrapper.eq(Album::getVisibility, 0); wrapper.orderByDesc(Album::getCreatedAt); return albumMapper.selectList(wrapper);

这种写法没有字符串拼接、没有注解SQL，完全面向对象，而且一旦字段被重命名，编译器直接报错，不会出现“SQL运行时报字段不存在”的问题。对于个人博客这个体量的项目，MyBatis-Plus是效率和可控性的最佳平衡点，这也是我踩过几个项目的坑之后的个人经验。

4. 源码之外的交付物：文档、运行视频和讲解视频的真实价值

聊完技术，再回过头说说标题里的“文档+运行视频+讲解视频”。这几样东西，很多人把它们当成“附赠品”，实际它们的学习价值不亚于源码本身。

4.1 运行视频解决的是“环境不一致”问题

你在自己电脑上能跑起来的项目，换一台电脑可能就起不来。原因大概率在环境差异上：JDK版本不对、MySQL版本不同、字符集没设、Redis没启动、端口被占用……运行视频最大的价值，就是提供了一条“从零开始验证环境”的路径。

拿到类似项目后，别直接双击运行，先对照视频把环境按步骤搭一遍。视频里如果演示了安装JDK、配置环境变量、导入数据库脚本、修改数据库密码、启动项目，你就照着一步一步复现。任何一个步骤报错，先暂停，看视频里的页面和你的屏幕差在哪。这个过程虽然烦，但正是排查能力积累的关键时期。不要跳过环境搭建直接运行，那会错过很多藏在细节里的知识。

4.2 讲解视频的本质是“别人帮你画重点”

源码就在那，为什么还需要讲解视频？因为代码文件是一堆静态文本，阅读顺序、模块之间的调用关系、哪段代码是核心、哪段代码只是辅助，没人提醒的话很容易迷失。

好的讲解视频应该是这样的结构：先讲项目整体架构和数据流，再按模块逐层深入，最后挑几个关键点细讲。比如讲解相册上传功能，视频里应该会演示：从前端页面提交request → Controller接收文件 → Service处理业务 → Mapper写库 → 返回结果，并指出每一层分别做了什么、为什么这么做。

我看过不少人学项目的方式是“一遍视频都不看，遇到问题直接百度”。这个方式不能说错，但对系统性理解帮助不大。更好的做法是：先看一遍讲解视频建立全局认知，再自己读源码读一遍，最后再带着疑问去看第二遍视频。第二遍你会突然发现“哦，原来这里当时没注意这么深”。

4.3 文档怎么用：别只把它当“交差材料”

项目文档一般包含需求说明、数据库设计、部署手册和接口说明。它们的价值各不相同：

• 需求说明：帮你理解项目目标，知道每个模块为什么要存在。
• 数据库设计：包含表结构、字段含义、ER图，这是理解整个项目数据流最快的方式。
• 部署手册：相当于运行视频的文字版，环境变量、启动参数、常见问题都在这。
• 接口说明：前后端联调的依据，也是面试中“你做过哪些接口设计”的直接素材。

建议拿到文档后，先读数据库设计文档，再读部署手册，最后看需求说明。这个顺序能让你从“存储了什么”入手，再理解“怎么运行”，最后回到“为什么要做”，跟从代码反推业务的路径完全一致。

4.4 消化这个项目的三个动作

如果你打算拿类似项目来学习或交付，我建议按这三个动作去消化它：

1. 跑起来：用运行视频把环境配好、数据库导入、项目启动。
2. 讲出来：跟着讲解视频，把项目架构和核心流程画成图，用自己的话讲一遍。
3. 改出来：改掉一个小需求，比如给图片加上“是否置顶”字段，自己动手扩展一个功能。

第三步是最关键的检验标准。只靠阅读，你对项目的理解永远停留在“懂了个大概”；动手改过之后，才能真正遇到类型怎么加、SQL怎么改、页面怎么调这些具体问题。绝大多数学习者在第三步卡住，也正是在这一步实现突破的。

5. 部署与运行时最容易踩的坑：基于常见实践整理

最后这部分是纯实战向的，我把自己在部署类似项目时遇到过的、以及身边人高频踩中的问题整理成表，每个问题附上解决思路。这些问题你在学习或验收阶段几乎一定会碰上。

下面挑两个最常见的坑多说几句。

5.1 版本匹配问题：一切异常的源头

Spring Boot本身版本迭代很快，2.x和3.x在底层上有重大变化。比如Spring Boot 2.7用的是javax命名空间，Spring Boot 3.0开始改成jakarta；再比如Spring Boot 3.x强制要求JDK17及以上。如果你拿到一个用Spring Boot 2.6写的项目，却用JDK17去跑，很多时候不会立刻报错，而是会在某些操作时抛出莫名其妙的反射异常，排查起来非常费劲。

所以第一步永远是看项目的pom.xml里父项目的版本号，再看java -version，两者对齐之后再往下走。这个动作花不了三十秒，能省下后面好几个小时的排查时间。

5.2 图片上传大小限制：配置项藏在三个地方

很多项目默认只允许上传1MB或10MB以内的小文件，超过就抛MaxUploadSizeExceededException。这类报错初学者特别容易懵，因为明明代码没报错，请求却失败了。

处理时至少要检查三处配置：第一是spring.servlet.multipart.max-file-size，控制单个文件大小；第二是spring.servlet.multipart.max-request-size，控制整个请求大小；第三是Tomcat自身的maxSwallowSize，它会吞掉多余的请求体。个人博客项目里把前两个设为5MB或10MB比较合适。如果项目用的是外置Tomcat而不是内嵌的，还要额外检查Tomcat的web.xml或server.xml配置。

5.3 图片404问题：路径映射的经典困惑

上传成功但访问404，这类问题99%是存储路径与URL映射没对齐。Spring Boot默认只能访问classpath下的static目录里的静态文件，你上传到你本机磁盘D:/uploads/下的图片，默认情况下Spring MVC根本不知道它存在。

解决方案有三个层次：

• 简单方案：把上传目录直接放在项目的src/main/resources/static/uploads/下。开发调试时方便，但打包后新上传的图片会随进程重启丢失，不推荐用于演示。
• 推荐方案：在配置类里实现WebMvcConfigurer，把本机目录映射成一个虚拟路径，例如将D:/uploads/映射到/uploads/**。
• 生产方案：把图片上传到云存储对象存储服务，走CDN访问，本地磁盘不留文件。这也是大厂项目的通行做法。

虚拟路径映射的参考配置大概是这样：

@Configuration public class WebConfig implements WebMvcConfigurer { @Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/uploads/**") .addResourceLocations("file:D:/uploads/"); } }

注意file:前缀不能漏，漏了Spring会把它当成classpath路径去解析。这一步是项目里“看着简单但总有人出错”的典型环节。

5.4 数据库连接细节：时区问题导致的隐性Bug

MySQL 8对时区处理比MySQL 5要严格，如果不加参数，经常会出现“时间显示差8小时”或者连接报错。解决办法是JDBC连接串统一加上serverTimezone=Asia/Shanghai和useSSL=false，同时注意字符集characterEncoding=utf8要打开。这些配置看着不起眼，但在接口返回时间数据时，差别非常明显。

数据库还有一个小细节：如果导入.sql脚本后，发现中文出现乱码，要确认脚本本身的编码格式，最好用UTF8无BOM格式，并且通过命令行或客户端设置连接字符集后再导入。项目里有一个乱码问题，通常不是代码问题，而是数据库表的默认字符集不是utf8mb4。

6. 如果让我继续往下做：这个项目的进阶方向

项目跑通、文档看明白、功能能讲清楚之后，很多人会问：然后呢？如果是我拿到这个项目，我会从低风险到高风险依次做这几件事，既不会破坏现有功能，又能明显提升项目质量和简历含金量。

6.1 权限体系升级：从“能用”到“规范”

现在的博客系统如果用的是Session+登录判断，属于“能用但不规范”。进阶改造可以引入Spring Security或Sa-Token，把认证和授权抽出来统一管理。特别是相册的私有访问，用Spring Security的@PreAuthorize注解或Sa-Token的登录校验，语义比手动判断清晰很多。

但我要说一句实在话：如果只是为了完成项目交付，不要试图在答辩前三天硬上Spring Security。它的过滤链、配置方式、方法拦截对新手来说有两三天学习曲线，学不透反而会弄巧成拙。如果是学习时间充裕，那这一项非常值得做。

6.2 缓存层：给博客系统加Redis

博客系统的典型瓶颈在文章和相册的列表查询。每次访问首页都去数据库查一遍所有文章，虽然数据量小的时候无所谓，但一旦有了缓存设计，面试官会立刻高看你一眼。

引入Redis之后，可以缓存热门的文章列表、相册列表，设置5分钟过期；图片的缩略图URL也可以缓存，减少数据库查询。这个改造不改变原有的接口，只加一层查询缓存，是性价比很高的优化。注意缓存更新策略要设计好——文章编辑后要主动删缓存或更新缓存，否则会出现“改了内容页面没变”的诡异问题。

6.3 静态资源上云端存储

本地磁盘存储的局限很明显：磁盘扩容麻烦、备份困难、多台服务器之间文件不共享。进阶项目可以把相册图片迁移到云对象存储服务，配上CDN加速。改造点集中在存储层——写一个StorageService接口，本地存储和云存储分别实现，上传业务只调用接口不关心实现。这样既保持了扩展性，又能在文档里写一句“采用策略模式支持多存储源”，面试时可聊的东西又多了一个。

6.4 代码规范与工程质量细节

很多人忽略了代码规范本身就是一个加分项。例如统一返回结果体Result<T>，把成功和失败包装成固定结构；全局异常处理器@RestControllerAdvice，保证任何异常都能返回友好提示；日志切面记录接口耗时和参数。这些改造都不复杂，但能极大提升项目“质感”。

我个人判断代码质量的方式很简单：找一个从没看过项目的人，让他打开源码，如果他在一分钟内能说出Controller在哪、Service在哪、Mapper在哪，那这个项目的结构就是合格的。很多项目的问题是代码全部堆在Controller里，Service形同虚设，这种写法虽然运行没问题，但从学习角度来说，等于放弃了三层架构本身的意义。

6.5 学习路线的自然延伸

做完以上这些，你实际上已经接触到了Spring Boot生态里的好几个核心方向：Web层、持久层、安全、缓存、文件存储。下一阶段想继续深入，可以尝试把这些经验打包到一个更大的项目里，比如做一个前后端分离的博客系统，前端用Vue或React，后端只提供REST API。这个方向会把你从“服务端渲染页面”带向“纯接口开发”，也是目前企业开发更主流的方式。

一步一步来，不要贪多。先把当前这个项目消化透了，再往上叠新东西，效果远比同时开好几个项目最后全部烂尾要好。

如果只留一句话给看完这篇内容的人，我想说：别把“拿到一套能跑的项目”当成终点，把“能拆开、能改懂、能讲明白”当成目标；源码、文档、视频都在帮你靠近这个目标，真正动手改代码的那一刻，才算开始学习。