企业官网建设流程全解析

每年到毕业季，都会有不少同学拿着计算机毕业设计的题目来找我聊思路，Spring Boot个人博客就是其中出现频率最高的一类。我自己这些年也前前后后写过好几个版本的博客系统，从最早的SSH（Struts+Spring+Hibernate）一路用到Spring Boot，踩过的坑加起来能写一本小册子。这个题目看起来简单，无非就是发文章、看文章、留评论，但真要做漂亮了，里面涉及的技术点其实很密：数据库设计、权限控制、Markdown渲染、文件上传、缓存优化、部署上线，每一项都能单独拎出来写不少内容。

这篇文章就以“基于Spring Boot的个人博客平台设计与实现”为例，把整个项目从需求分析、数据库设计、核心功能编码，到部署上线的完整链路拆开讲一遍。适合正在做毕设、课设的同学，也适合想自己动手搭一个独立博客但还没想清楚从哪下手的开发者。文中会给出可以直接套用的表结构、核心代码思路和大量我从实际开发中踩坑总结出来的经验，不是为了展示代码，而是帮你把每个选择背后的为什么搞清楚。

1. 整体设计思路与技术选型拆解

1.1 需求分析：先把博客到底要做什么想清楚

很多人拿到这个题目就直接开写代码，结果写着写着发现这里缺功能、那里逻辑乱。个人博客系统虽然不算大，但边界一定要先划清楚。按照我常用的划分方式，可以分成两个端、四类角色能力。

前台面向访客，核心功能包括：文章列表浏览、文章详情阅读、按分类和标签筛选、按时间归档、全文搜索、文章评论、友情链接展示、关于页面。后台面向博主自己，核心功能包括：登录认证、文章发布与编辑、文章草稿管理、分类和标签维护、评论审核与删除、系统基础配置（比如博客标题、SEO关键词、头像、备案信息占位）。

有的同学还会加文章阅读量统计、点赞、打赏、定时发布、RSS订阅，这些都属于加分项，但我不建议一开始就铺开做。先保证主链路（发布文章到用户阅读）足够顺，再慢慢补充彩蛋功能。对于毕设来说，把基础功能做扎实，答辩时反而更能讲出东西。

我做一个版本的时候，很喜欢在需求阶段画一个粗糙的流程图：用户访问首页、点进文章详情、看到评论；管理员登录后台、发布文章、审核评论。这两条线的数据流转一旦想清楚，后面的数据库表几乎就能定下来。

1.2 技术栈选型与取舍：为什么是Spring Boot

技术选型这块，我的建议是：稳妥大于炫技。

后端用Spring Boot，这是基于Java Web的毕业设计里最不容易出错的方案。Spring Boot即使对底层原理不熟悉，也能靠自动配置快速把项目跑起来，内置Tomcat，部署只要一个jar包，省掉了一堆xml配置。版本选择上，能稳定就稳定一点，毕业设计尽量别追最新版本，很多新版本刚发布时，第三方依赖兼容性会有问题。我推荐Spring Boot 2.7.x或3.x，看你本机JDK版本。JDK 8就用2.7.x，JDK 17可以上3.x，这两个组合都是踩坑最少的。

数据层我用MyBatis-Plus，而不是纯MyBatis或Spring Data JPA。MyBatis-Plus的好处是单表CRUD基本不用写SQL，代码量能少一半，对于赶时间做毕设的同学特别友好。它内置的分页插件、条件构造器、逻辑删除，刚好覆盖博客系统的常见需求。

数据库用MySQL，不用纠结版本，5.7或8.0都行。ORM层默认也好，不需要额外引入Redis。我见过很多同学一上来就加Redis、Elasticsearch、RabbitMQ，结果把自己绕晕了。如果论文里定位是“基于Spring Boot的博客系统”，那就把Spring Boot相关的深度做好，中间件属于锦上添花，后期有余力再加不迟。

模板引擎方面，我建议直接用Thymeleaf做服务端渲染，前后台都用它。有的同学非要把后台拆成Vue + 接口分离，这个思路没错，但对毕设来说，工作量会膨胀不少。你既要写前端页面，又要处理接口鉴权、跨域、Mock数据，时间很容易失控。服务端渲染写起来直白，数据放到Model里，页面循环渲染，调试也方便，演示时不容易出幺蛾子。

1.3 数据库设计：五张核心表搭建博客骨架

博客系统的表结构几乎是大同小异，我把核心表列出来，你照着建基本不会出问题。

第一张是用户表。字段包含主键id、用户名、密码（必须是BCrypt加密后的密文）、昵称、头像、邮箱、角色（admin/user）、创建时间、更新时间。博客一般只有一个管理员，但保留用户字段方便以后扩展注册功能。

第二张是文章表。主键id，标题title（VARCHAR(200)）、摘要summary、正文内容content（用LONGTEXT，因为Markdown文本或者HTML源码可能很长）、封面图cover、分类id category_id、状态status（0草稿、1已发布）、是否置顶、是否允许评论、浏览量、创建时间、更新时间。这里一定要设置逻辑删除字段deleted，用MyBatis-Plus的@TableLogic，避免用户误删数据后没法恢复。

第三张是分类表。字段就三个：主键id、分类名称name、分类别名slug。slug用于生成类似/category/java这种语义化URL，比用数字id美观也利于SEO。

第四张是标签表。字段和分类表几乎一样，也是id、name、slug。

第五张是文章标签关联表。因为一篇文章可以有多个标签，一个标签下也有多篇文章，多对多关系需要一张中间表。中间表两个字段：article_id、tag_id，如果你需要按标签统计文章数，给tag_id建个普通索引就行。

辅助表可以根据情况再加：评论表（id、文章id、昵称、邮箱、内容、父评论id、审核状态、创建时间）、友情链接表（id、站名、URL、logo、排序）、站点配置表（key-value形式存储博客名称、标题后缀、描述等）。

数据库细节上，有两点必须提前注意。第一，所有表默认用utf8mb4字符集，不然用户评论里发个emoji表情，直接乱码或者报错。第二，时间字段建议用datetime而不是timestamp，并且统一设置默认值CURRENT_TIMESTAMP，能少掉很多插入数据时不带时间的bug。

2. 核心功能模块的实现与细节

2.1 文章发布与Markdown渲染链路

博客系统的核心是文章，而文章这部分的实现细节，十个人里有八个人会踩坑。

我推荐的流程是：前台编辑器用开源的Markdown编辑器，比如Editor.md，它自带预览和上传图片功能，界面也还算好看。后端保存时，存两样东西：原始Markdown文本，以及由Markdown渲染后的HTML。为什么存两份？因为如果你只存Markdown，那么每次用户访问文章详情，都要实时做一次文本转换，虽然性能不见得成为瓶颈，但白白浪费CPU，而且不同渲染器可能渲染出不同结果。如果你只存HTML，后续想重新编辑文章，没有原始Markdown，前端编辑器里拿什么回显？所以最佳实践是“双写”：编辑时用Markdown，展示时用HTML。

后端渲染Markdown，我用的是CommonMark（Java版）这个库，它性能好、标准支持完整。引入依赖后，核心代码很短：

import org.commonmark.parser.Parser; import org.commonmark.renderer.html.HtmlRenderer; public String markdownToHtml(String markdown) { Parser parser = Parser.builder().build(); HtmlRenderer renderer = HtmlRenderer.builder().build(); return renderer.render(parser.parse(markdown)); }

但这地方有一个非常重要的安全坑：Markdown渲染后的HTML里，可能包含恶意脚本。比如一篇文章里写<script>alert('xss')</script>，某些Markdown解析器会直接原样保留，用户访问页面时脚本就会被执行。解决手段有两个：要么在渲染时配置HTML过滤，要么在后端保存时统一做XSS清洗。我用的方法是引入一个开源的HTML sanitizer，比如OWASP Java HTML Sanitizer，在渲染HTML之后，把所有危险标签和属性过滤掉。这是个人博客最容易忽略的点，建议写进你的“项目亮点”。

文章发布的核心业务逻辑，在Service层其实很简单：接收表单提交的标题、摘要、Markdown内容、分类id、标签id数组；把Markdown转换为HTML；保存文章；建立文章和标签的关联关系；更新分类或标签的文章统计。唯一要注意的是事务注解，因为这里涉及多张表写入：

@Transactional public void saveArticle(Article article, List<Long> tagIds) { article.setStatus(1); // 1表示发布 article.setContentHtml(markdownToHtml(article.getContent())); articleMapper.insert(article); // 先删除旧关联再插入新关联，保证编辑时不会残留 articleTagMapper.deleteByArticleId(article.getId()); if (CollectionUtils.isNotEmpty(tagIds)) { for (Long tagId : tagIds) { articleTagMapper.insert(article.getId(), tagId); } } }

2.2 分类与标签的联动查询

分类和标签在页面上的表现，一个是树状结构，一个是扁平标签云。实现上不需要复杂设计，两张表加一张中间表就足够。

首页文章列表页，通常会提供“按分类筛选”、“按标签筛选”的入口。我的做法是，列表接口接收一个可选的分类id或标签id参数，然后走动态SQL拼接。MyBatis-Plus的QueryWrapper天然支持这种动态条件：

public Page<ArticleVO> pageArticles(long page, long size, Long categoryId, Long tagId) { Page<Article> p = new Page<>(page, size); QueryWrapper<Article> wrapper = new QueryWrapper<>(); wrapper.eq("status", 1).orderByDesc("create_time"); if (categoryId != null) { wrapper.eq("category_id", categoryId); } // 标签筛选需要使用子查询或者连表，单独处理 if (tagId != null) { wrapper.inSql("id", "SELECT article_id FROM article_tag WHERE tag_id = " + tagId); } return articleMapper.selectPage(p, wrapper); }

需要注意的是，分页插件得先在配置类里注册。大多数同学没配，结果分页查询不生效，返回的全部数据都塞在一页里，页面一下加载几十条文章，列表会卡。注册方式很固定：

@Configuration public class MybatisPlusConfig { @Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }

分类和标签的统计数量，我有两种方案：一是每次保存文章时更新article_count字段，二是直接用COUNT查询。对于个人博客这种数据量，COUNT足够，顶多加个缓存，没有必要引入额外的统计表。如果非要显示侧边栏每个分类的文章数，建议页面里做个统一查询，避免在循环里逐条COUNT，产生N+1问题。

2.3 评论功能设计与防刷处理

评论这块，算是博客系统里最容易被人忽略，又最容易出问题的地方。

基础表结构前面已经说过。设计时需要考虑三个点：是否需要登录后才能评论、是否允许匿名评论、是否需要留言审核。我的建议是：默认允许游客填昵称和邮箱评论，毕竟个人博客更看重交流感，强制登录会把很多想留言的路人拒之门外；但后台必须加一个“评论审核开关”，开启后新评论默认不展示，管理员审核通过后才显示。

评论内容输入框，前端用textarea加一个简单的字数限制就可以。后端要做的事更多：过滤掉评论里的HTML标签、避免提交空评论、控制单条评论长度（比如500字内）、给同一个IP加一个提交频率限制。后者我常常被忽略，但不想被刷屏垃圾广告的话，必须做。最简单的方案是写一个拦截器，用Redis或者本地Map记录IP在5分钟内的提交次数，超过3次就拒绝。

评论列表在文章详情页的展示，有两种做法：一种是只展示第一层评论，按时间倒序，子评论通过“回复”按钮逐条展示；另一种是把所有评论一次性查出来，在Java里组装成树形结构。我建议用第二种，因为博客评论的层级通常很浅，一次性组装成树，前端递归渲染，体验最好。

组装树的伪代码大概是：

List<CommentVO> allComments = commentMapper.selectList(wrapper); Map<Long, CommentVO> map = new LinkedHashMap<>(); List<CommentVO> roots = new ArrayList<>(); for (CommentVO c : allComments) { map.put(c.getId(), c); if (c.getParentId() == null || c.getParentId() == 0) { roots.add(c); } } for (CommentVO c : allComments) { if (c.getParentId() != null && c.getParentId() > 0) { CommentVO parent = map.get(c.getParentId()); if (parent != null) { parent.getChildren().add(c); } } }

2.4 搜索功能的实现方案

很多同学会在搜索功能上纠结，要不要上Elasticsearch？对于个人博客来说，绝大多数情况都不需要。如果文章数量在几千篇以内，数据库LIKE查询完全够用，查询速度可能几十毫秒，用户根本感知不到。

最简单的实现是用MyBatis-Plus的条件构造器：

public Page<Article> searchArticles(String keyword, long page, long size) { QueryWrapper<Article> wrapper = new QueryWrapper<>(); wrapper.eq("status", 1) .and(w -> w.like("title", keyword).or().like("summary", keyword).or().like("content", keyword)) .orderByDesc("create_time"); return articleMapper.selectPage(new Page<>(page, size), wrapper); }

如果你的博客文章偏技术类，内容比较长，LIKE查询匹配的精度其实够用了。真要提升体验，可以加一个MySQL的全文索引，但中文全文索引要用ngram解析器，配置起来相对麻烦，而且连表查询时全文索引会失效，要考虑清楚。我的个人实践是：除非文章超过一万篇，否则不要给自己找额外工作量。

3. 后台管理、文件上传与安全设计

3.1 后台登录认证：Session方案就够了

个人博客的后台只有一个博主在用，安全要求不像企业系统那么高，Spring Security + JWT那套组合确实很稳，但对毕设而言配置成本偏高，而且概念太多，答辩时如果原理讲不透反而露怯。

我更推荐用Spring Boot原生的Session认证，配合一个拦截器。具体做法：管理员登录成功后，在Session里写入一个标识（比如userId）；写一个HandlerInterceptor，拦截/admin/**路径；如果Session里没有用户信息，就重定向到登录页。代码量很小，逻辑也直白。

登录密码的存储是另一个容易犯的错误。千万别把密码用MD5直接存数据库，MD5撞库太容易了。用BCrypt：

// 注册或修改密码时 String encoded = BCryptPasswordEncoder().encode(rawPassword); // 登录校验时 boolean matches = encoder.matches(rawPassword, encodedPassword);

Spring Security虽然不整体引入，但可以只引它的加密模块spring-security-crypto，这样一个独立的依赖就够用了，不引入复杂的认证流程。

3.2 文章发布流程与草稿机制

后台的文章管理页面，需要考虑四种状态：新建、编辑、放入草稿、发布。数据库里用status字段区分：0草稿，1已发布。编辑已发布的文章时，为了安全，不建议直接改线上出正式版本。不过个人博客没有那么多讲究，直接覆盖是比较常见的选择。

发布页面的表单布局，我的习惯是左边是标题和内容编辑器，右边是分类、标签、封面图、状态等设置项。提交时，如果点了“保存草稿”，status设为0，不进入前台列表；如果点了“发布”，status设为1。

遇到一个常见的坑：用Thymeleaf回显时，textarea里的Markdown内容不能直接当HTML输出，必须转义。Thymeleaf的th:text会自动转义，而th:utext不会。如果你在编辑页面用th:utext回显Markdown原文，输入框里会显示渲染后的HTML标签，这是好多同学找半天的bug。

封面图上传也放在文章发布页面里。上传后，后端把文件保存到服务器指定目录，然后把可访问的URL存进数据库。这里涉及一个静态资源映射问题，等会儿在下一节单独说。

3.3 文件上传与静态资源映射的坑

博客系统离不开图片上传。关于文件存储，我的建议是：尽量用本地磁盘存储，不引入OSS对象存储。原因很简单，毕设主要演示本地开发环境，OSS还要配置AccessKey、桶、域名，麻烦且没必要。等以后真的搭建线上博客，再换对象存储也不迟。

但本地存储有一个非常隐蔽的坑：Spring Boot默认只把classpath:/static/当作静态资源根目录。如果你把上传的文件保存到服务器磁盘的/home/blog/upload/目录下，前端访问http://localhost:8080/upload/xxx.jpg是访问不到的，会报404。

解决办法是自定义一个静态资源映射，把/upload/**这个URL路径映射到本地的实际目录。在配置类里加：

@Configuration public class WebMvcConfig implements WebMvcConfigurer { @Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/upload/**") .addResourceLocations("file:" + Constants.UPLOAD_DIR); } }

需要注意，addResourceLocations里必须写成file:开头的绝对路径，Windows上最后要带斜杠，否则映射不生效。还有一个安全细节：保存文件时，文件名不要用用户上传的原始文件名，因为可能包含中文、空格甚至特殊字符，建议用UUID配合原始文件扩展名重新生成，比如20250213_8f3a2c1e.jpg，这样可以避免路径注入攻击。

3.4 权限校验与接口安全

后台所有管理接口，都应该经过登录拦截器校验。除了Session校验，我还会在接口上加一个简单的自定义注解@AdminOnly，配合拦截器一起使用，这样接口级的安全控制更清晰。对于游客可访问的前台接口，不需要拦截，但要注意SQL注入、XSS和越权问题。

XSS在评论和文章内容里必须处理。文章内容用CommonMark渲染后加Sanitizer过滤，评论内容直接去掉所有HTML标签，只保留纯文本，这是最简单有效的策略。

另外，后台接口的返回值不要直接返回实体类，最好封装一个统一的结果对象Result<T>，包含code、message、data三个字段。这样前端Ajax调用时统一处理，状态码清晰，答辩时讲起来也是一个亮点。前端页面则用Thymeleaf + jQuery的方式，Ajax提交表单，返回JSON后刷新局部区域，既简单又稳定。

4. 缓存优化与部署上线

4.1 给热点数据加Redis缓存

如果你有余力，想在项目里体现一点性能优化，我建议从缓存入手。个人博客的热点数据主要是首页文章列表、分类统计、标签统计、友情链接、站点配置。这些数据变化频率低、读取频率高，非常适合缓存。

引入Redis后，最简单的做法是手动缓存。比如查询首页文章列表时，先查Redis，Key类似article:list:page:1，存在就直接返回，不存在则查数据库并写入Redis，设置过期时间10分钟，并处理“缓存穿透”问题（空结果也缓存，比如数据量为0时，缓存一个短时间的空值）。

文章详情页的浏览量和文章内容也可以缓存。需要留意的是，浏览量每次请求都要加1，如果跟着缓存一起更新，Redis写操作会非常频繁。我的做法是浏览量不缓存，每次请求直接更新数据库，或者用一个定时任务批量刷新。个人博客的访问量不大，直接更新数据库完全扛得住。

4.2 数据库索引与SQL优化

博客系统表结构不大，但也要注意基本索引。文章表的status和create_time建议建联合索引，因为列表查询常常是WHERE status=1 ORDER BY create_time DESC。分类表的slug字段建唯一索引，用于URL匹配。标签表和关联表的查询就靠主键和中间表索引。

深分页是另一个易踩的坑。比如后台文章列表分页，翻到第100页，MySQL要扫描前100页的数据扔掉，性能直线下降。如果文章量过千，后台列表分页建议改成“上一页/下一页”模型，或者直接限制最多翻到第200页。对个人博客来说，深度分页问题不会太严重，但知道这个优化点，面试或答辩时能多说一层。

SQL层面的优化我不建议做太多，只要在开发时打开MyBatis的SQL日志，把慢查询SQL捞出来，看看有没有没走索引的，针对性加索引就够了。

4.3 打包、部署与服务器配置

开发完成后，如何部署上线，是检验项目是否真正完整的一关。

第一步，修改配置。生产环境数据库连接、Redis连接不能和本地共用，我习惯用Spring Boot的多环境配置文件：application-dev.yml和application-prod.yml，启动时通过--spring.profiles.active=prod指定环境。

第二步，打包。在项目根目录执行：

mvn clean package -DskipTests

构建完成后，target/目录下会生成一个blog-0.0.1.jar，这就是最终产物。

第三步，部署。服务器上需要安装JDK和MySQL。把jar包上传到服务器，比如/home/blog/目录，然后启动：

java -jar blog-0.0.1.jar --spring.profiles.active=prod

不过我更推荐用systemd写一个服务文件，让博客开机自启、崩溃自动重启。服务文件大概是：

[Unit] Description=Blog Service After=network.target [Service] User=blog ExecStart=/usr/bin/java -jar /home/blog/blog-0.0.1.jar --spring.profiles.active=prod Restart=always RestartSec=5 [Install] WantedBy=multi-user.target

写完保存到/etc/systemd/system/blog.service，然后：

systemctl daemon-reload systemctl enable blog systemctl start blog

第四步，反向代理。前端通过Nginx把80或443端口转发到8080，Nginx配置里需要注意，client_max_body_size要调大一点，否则上传大图直接413错误。另外图片、CSS、JS这些静态文件交给Nginx直接处理，不要转发到Java应用，可以降低应用压力。

location /upload/ { alias /home/blog/upload/; }

4.4 线上环境常见问题清单

部署到线上后，有俩问题特别常见，我几乎每次都会遇到。

第一个是端口占用。启动时报Port 8080 already in use，直接换端口或者查看进程杀掉：netstat -tlnp | grep 8080。

第二个是数据库时区问题。MySQL 8默认时区是UTC，应用连上后查询任务可能比本地快8小时，所有发布时间对比实际时间差了大半天。解决方法是连接URL里加参数：

jdbc:mysql://localhost:3306/blog?serverTimezone=Asia/Shanghai&useUnicode=true&characterEncoding=utf8

还有字符集问题，生产环境MySQL建库时万一没有指定utf8mb4，中文和emoji会乱码。所以建库语句直接写全：

CREATE DATABASE blog DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

5. 踩坑记录与实用排查技巧

5.1 时区、编码、emoji三连坑

时区问题上面已经提过，这里再单独强调一遍。不仅是数据库连接URL，Linux服务器的系统时区也建议改成Asia/Shanghai，否则日志打印的时间和数据库时间对不上，排查问题时会非常痛苦。

emoji存储问题也是老生常谈。评论里如果包含emoji，数据库表是utf8mb4就没事，但有的同学建表时默认用了utf8，存emoji直接报错Incorrect string value。记住，MySQL的utf8不是真正的utf8，只是utf8mb3，必须用utf8mb4。建表时统一：

CREATE TABLE comment ( id BIGINT PRIMARY KEY AUTO_INCREMENT, article_id BIGINT NOT NULL, nickname VARCHAR(50), content TEXT, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

5.2 懒加载与JSON序列化冲突

如果你在项目里用了JPA或MyBatis-Plus的关联查询，且实体类之间有一对多关系，到了Controller返回JSON时，有可能报出LazyInitializationException，因为session已经关闭，懒加载的属性取不到了。解决方式很简单：不要直接序列化实体，封装VO或DTO，在Service层把需要的数据查好并复制进去。

这个坑在评论区树形查询和文章详情页特别容易出现。与其花时间调懒加载配置，不如一开始就用VO模式。实话说，对博客系统这种小项目，Controller直接返回实体类虽然省事，但容易把密码、内部字段暴露出去，不是好习惯。用VO类还能顺便添加自定义字段，比如文章VO里带一个tagList字段，而不是让前端循环关联表查询。

5.3 分页插件不生效，怎么排查

分页查询返回的数据量不对，最常见的原因是忘了注册MybatisPlusInterceptor。另一个容易被忽视的问题是，用了selectPage但SQL里没有自动加limit，此时很可能是分页插件没加载到MyBatis-Plus 3.5版本以上，需要检查依赖版本和配置类是否被扫描到。

排查思路很简单：启动时看控制台有没有输出分页插件的初始化日志，或者把SQL日志打开，直接在日志里看有没有Limit关键字。如果是Spring Boot 3 + MyBatis-Plus 3.5.4以下的版本组合，还有兼容问题，建议直接升级到3.5.4以上。

5.4 图片上传后页面访问不到

这个坑十个人里九个遇到。上传成功返回了URL，但浏览器打开404。排查步骤按顺序来：

1. 确认URL路径是不是以/upload/开头。
2. 确认本地目录真的存在，且文件已经写进去了。
3. 确认静态资源映射类被Spring容器扫描到。
4. 确认映射路径和请求路径一致，特别是末尾斜杠。

如果你用的是Windows，路径写file:D:/blog/upload/时，注意D后面冒号和目录斜杠别漏。部署到Linux后，路径变成file:/home/blog/upload/，同样注意斜杠。

5.5 开发环境热部署配置

Spring Boot开发时，强烈建议引入spring-boot-devtools，它带来的最大好处是修改类后自动重启，不用手动ctrl+F5。依赖配置里加上，IDE设置里开启自动构建，改代码保存后应用会在几秒内自动重启，开发效率提升非常明显。

需要注意的是，生产环境一定不要带这个依赖，否则僵尸进程多、内存占用高。可以用Maven的profile用环境来控制依赖，或者在启动时加-Dspring.devtools.restart.enabled=false。

6. 从毕设到独立博客：再多说几句

这次用Spring Boot写个人博客，我最大的感悟是：一个看似简单的小项目，想做到“演示流畅、答辩有亮点、上线能用”，其实需要照顾到的边缘环节非常多。数据库字符集、时区、静态资源映射、XSS过滤、分页插件、部署脚本，这些不是教科书里画图能讲出来的东西，而是每次真实动手才能记住的经验。

最后再分享一个我做博客系统时比较喜欢的小技巧：把日志做好。项目里统一用Lombok的@Slf4j打印日志，在关键业务节点（登录、发布文章、删除评论、上传文件）输出日志。线上出问题时，查日志能省掉80%的排查时间。写日志时不要只打印一行字符串，尽量把关键ID也打出来，比如保存文章成功，articleId={}, article.getId()。这个习惯，比多写几个功能点更能帮你应对突发状况。

如果你正打算用Spring Boot做个人博客，按照这个思路从需求、表结构、核心代码一步步落地，把后端功能做扎实，前端用Thymeleaf或简单模板实现，绝对够撑起一份技术含量不错的毕业设计，也能真正搭建起一个属于你自己的独立博客。