做文学创作类社区的人多少都会遇到一个相同的困惑功能看来看去就是发文章、写评论、点赞收藏加关注好像谁都能做。可真要把一条“作者创作、平台审核、读者互动、运营管理”的完整链路跑通琐碎程度远超预期。这篇博客就围绕一个完整的SpringBootVue项目来复盘这件事。项目代号xabo技术栈是JavaMySQLMyBatis覆盖用户端、作者端和管理端三块前后端分离带完整源码。无论你是正在做类似选题的开发者还是想快速搭一套内容社区骨架这篇文章都能给你一条能直接落地的路线。1. 项目到底在做什么把需求拆成一条完整的业务闭环技术类文章一上来就贴代码是最劝退的写法。不管用什么框架第一步都应该先把业务想清楚。文学创作社交论坛和普通博客系统的差别很大普通博客的核心是“我写你看”而文学论坛的核心是“作者持续创作读者持续互动平台持续治理”所以它本质上是一条内容闭环。1.1 文学创作社区的核心业务模型我先按角色把整个系统拆开。用户端最基础的是注册、登录、浏览作品、搜索分类、阅读章节、评论、点赞、收藏、关注作者。作者端则要支持创建作品、管理章节、查看自己作品的阅读数据和评论通知。管理端承担的是审核、治理、统计和配置缺了管理端内容和用户一多就会失控。这个模型决定了数据库建模和接口设计的大方向用户、作品、章节、评论、点赞记录、收藏关系、关注关系、公告通知、敏感词、操作日志这些是一套文学社区最少也要覆盖的数据实体。文学平台还有一个特殊点连载。一部作品下挂几十上百个章节章节需要拆分独立管理。如果不把作品和章节拆成两张表编辑某个章节时就得把整部作品数据捞出来再塞回去性能差逻辑也容易乱。所以数据建模上作品表只存元信息章节表单独存正文这是第一个关键决定。1.2 xabo管理系统到底管什么xabo是项目的代号负责的是整个平台的后台管理。很多练手项目最常犯的毛病是只做了用户端觉得能注册能发帖就完事了。真实情况是一个内容平台上线后管理者必须处理的日常事务非常多新作品要不要通过审核、用户举报评论如何处理、异常用户要不要禁言、当日新增内容多少、活跃用户多少、哪些分类最热门。这些需求不做项目就只能停留在demo层面谈不上“系统”。所以xabo管理端至少有三个功能域内容审核作品发布后进入待审状态管理员查看详情后通过或驳回驳回要填原因。用户治理用户列表、角色调整、禁言、封禁以及作者认证审批。数据运营每天新增作品数、新增用户数、评论数、点赞数按时间维度统计用报表呈现。管理端独立还有一个隐含好处权限边界清晰。普通用户和作者永远接触不到管理接口避免越权操作。开发时把管理端路由独立成一套布局也方便后期做更细粒度的权限控制。1.3 功能清单与版本裁剪策略一次把所有社区功能全做完是不现实的。设计这个项目时应该有明确的主次。我按优先级把功能分成P0、P1、P2三档优先级功能模块说明P0用户注册登录、作品发布、章节管理、作品列表与详情、评论、后台审核没有这些社区闭环不成立P1点赞、收藏、关注、个人主页、我的书架、公告、数据看板完善社交属性提升粘性P2打赏、积分系统、消息通知、专题活动、排行榜增强运营能力可以后续迭代P0是必须做完的P1是项目中期补全的P2属于加分项。很多人在做这类项目时喜欢一上来就设计一个巨大无比的表结构结果开发周期拖长代码写不完。我的建议是先跑通P0闭环再逐步加P1工程上这叫MVP思维放在个人项目里非常实用。2. 技术选型为什么这套组合拳扛得住SpringBootVueMySQLMyBatis这个组合在国内的Java Web项目里已经称得上“经典款”。它不是最炫的但绝对是最稳的。我在这里把每一环的选型逻辑说清楚方便你判断自己的场景适不适合照抄。2.1 SpringBoot做后端省心的关键是“约定优于配置”SpringBoot的价值不在于它有什么黑科技而在于它把Spring生态里的配置成本压到了最低。要做SSM那套老流程你要手动配置数据源、事务管理器、MyBatis的SqlSessionFactory、扫描器任何一个环节配置错启动就报错。SpringBoot用自动配置把这些全部接管了写个application.yml就能跑起来。更实际的好处是生态成熟。做登录认证有Spring Security和JWT方案做参数校验有Validation注解做接口文档有Knife4j或者SpringDoc做定时任务有Scheduled。这些组件都能无缝嵌进SpringBoot工程。对个人开发者和中小团队而言这是一个性价比极高的起点。我在xabo项目里选择Java 8加SpringBoot 2.x很多人会问为什么不直接上Java 17和SpringBoot 3.x。原因很简单生态兼容。很多公司内部或毕业设计环境还在大量使用MyBatis、PageHelper等传统组件这些组件对SpringBoot 2.x的兼容性最好查问题也最容易找到资料。如果你的环境完全可控再考虑新版本。2.2 Vue做前端前后端分离不是炫技前端用Vue核心原因只有一个交互复杂模板渲染撑不住。文学创作论坛的页面不是简单的服务端渲染就能搞定的创作中心要实时保存草稿作品详情页要异步加载章节内容管理端有大量表单和表格联动。这些场景用原生JS写维护成本会迅速失控。Vue提供了组件化、响应式数据和路由管理。项目里我把前端分成两个部分前台门户和后台管理。前台门户面向用户页面要清爽后台管理面向管理员大量的表格、表单、弹窗适合用Element UI这类组件库快速搭建。Vue Router负责页面跳转Vuex或Pinia负责保存用户信息和登录状态。前后端分离还有一层好处是开发时可以并行。后端的接口只要约定好返回格式前端就能用Mock数据先开发页面不需要等后端写完。项目里所有接口统一返回{code, message, data}结构前端在Axios的响应拦截器里统一处理code避免每个页面都写一遍错误判断。2.3 MySQL建模表结构和索引怎么设计才不坑MySQL是这套技术栈里最不该换掉的部分。关系型数据库的ACID事务是这个项目最需要的作者发布章节、用户点赞、收藏操作每一步都涉及数据一致性不像日志类系统可以用NoSQL宽松处理。建模时有几个经验值得记下来。第一字符集必须用utf8mb4而不是utf8因为utf8在MySQL里最多存3字节用户昵称和评论里一旦出现emojiutf8就直接写入报错。第二所有表都建议带上自增主键id、create_time、update_time这三个字段能让后续开发和排查省很多事。第三不要过度使用数据库外键。逻辑外键就够了物理外键在删除和分表时会变成枷锁。索引设计上查询频率最高的场景一定要提前分析。作品列表页最常见的操作是按分类查、按状态过滤、按时间排序所以(work)表至少要建(work)的联合索引。评论表最常见的操作是按作品或章节查评论所以(comment)表至少要建(work_id create_time)的联合索引。点赞记录表要建唯一索引这是防重复点赞的关键。2.4 MyBatis把SQL掌控权握在自己手里MyBatis和JPA的选择是很多团队争论过的话题。我的个人判断是这个项目必须用MyBatis因为管理端的统计报表、作品列表的多条件筛选都依赖复杂动态SQL。JPA虽然写单表CRUD很快但一旦查询条件多、需要动态拼SQL调试成本会直线上升。MyBatis的XML里可以显式写出每条SQL出了问题直接复制出来在Navicat里跑一遍就知道对错。如果再用上MyBatis-Plus单表CRUD也能自动生成配合条件构造器QueryWrapper日常开发效率不比JPA低。在xabo项目里我采用了MyBatis加PageHelper组合分页插件用起来简单startPage之后紧跟着查询就自动分页管理端的作品列表、用户列表全依赖它。3. 核心功能设计与关键实现细节技术选型说完了接下来进入最核心的部分每个关键功能是怎么落地实现的。这一节我会重点讲数据模型和实现思路避免只讲概念。真在代码里填过坑的人会发现很多问题的根源其实都在设计阶段。3.1 用户认证JWT加拦截器的完整落地前后端分离项目里Session方案不太好用因为浏览器和后端不在同一个域跨域时Cookie管理很麻烦。我选了JWT方案本质就是用户登录成功后服务端生成一个带签名信息的Token字符串下发到前端前端在后续每次请求的Header里带Authorization后端解析Token就知道请求人是谁。登录的流程是这样用户提交用户名密码后端拿到后先用BCrypt去校验密码哈希匹配成功就提取用户ID和角色用密钥生成TokenToken里包含过期时间。接下来写一个拦截器拦截除登录注册之外的接口从Header取Token解析失败就直接返回401解析成功就把用户ID塞进ThreadLocal业务代码里随时可以取当前登录人。这套方案里最容易被忽略的两个点是密钥管理和登出。密钥不能写在代码里要放到配置文件里最好加入环境变量。JWT本身是无状态的服务端没法主动让Token失效所以登出功能要么依赖前端删掉Token要么引入简单的黑名单机制。个人项目用前端删除Token方案就够别把复杂度抬得太高。3.2 作品发布与章节管理内容主数据建模文学平台的数据核心是作品和章节。作品表记录作者ID、书名、分类、简介、封面图、状态、总字数、总点赞数章节表记录所属作品ID、章节序号、标题、正文、字数、发布时间。为什么作品和章节必须拆开一部连载作品可能有200章如果不拆表作者想改第35章的标题就要把整部作品的内容都更新一遍数据库会做大量无效的写操作。拆开后作品表的更新只涉及元信息章节表的更新只涉及单条记录还可以针对章节做分页查询和单独的阅读计数。章节正文我建议用MEDIUMTEXT类型小说一章几千字很正常如果一章长达数万字TEXT字段就会兜不住。作者发布章节时前端用Markdown编辑器或者富文本编辑器后端要统一做一遍XSS过滤不能直接把HTML内容存进数据库。这个细节在第五章会展开讲。作品的审核状态是这个项目的机构性设计。作者创建作品后状态是草稿提交审核后变成待审核管理员通过后才是连载中最终完结违规的则下架。这个状态流转贯穿整个项目作品列表、作者创作中心、管理端审核页全部以状态字段作为过滤条件。3.3 评论、点赞、收藏社交互动的数据模型互动功能看起来是小事做不好会让人怀疑整个项目的水准。先说评论表至少要有id、用户ID、作品ID、章节ID、内容、父评论ID、创建时间。父评论ID支持楼中楼回复但要注意层级最好不要无限递归最多支持两级就好回复某人的评论时前端直接展示“回复某人”即可数据查询反而简单。再重点说点赞防重的实现。很多新手写点赞逻辑是这样的// 错误示范 if (likeMapper.exists(userId, workId)) { likeMapper.delete(userId, workId); workMapper.decreaseLikeCount(workId); } else { likeMapper.insert(userId, workId); workMapper.increaseLikeCount(workId); }这段代码在并发请求下有明显的竞态问题用户快速点两下两条记录同时进数据库会出现重复点赞。正确的做法是依赖数据库唯一索引兜底不管并发来多少请求唯一索引都会把重复数据挡掉再用INSERT IGNORE这种写法后台更新计数就够了。计数更新还有一个坑不要用count(*)实时统计点赞数。每次列表查询都去count一遍点赞表数据库IO扛不住。常规做法是在作品表里冗余一个like_count字段每次点赞成功就1取消点赞就-1。虽然极端情况下会有误差但配合定时任务重新校准完全够用。3.4 管理端看板统计SQL与运营功能实现xabo管理端里最有含金量的部分是数据看板。它的SQL并不复杂但确实能体现MyBatis写自定义SQL的优势。比如要统计最近7天每日新增用户数就按日期分组SELECT DATE(create_time) AS day, COUNT(*) AS cnt FROM sys_user WHERE create_time DATE_SUB(CURDATE(), INTERVAL 7 DAY) GROUP BY DATE(create_time) ORDER BY day;同类SQL还可以扩展出每日新增作品数、每日新增评论数、作品分类分布、用户角色分布。把这些汇总结果返回给前端前端用ECharts画折线图和饼图管理端看起来就专业得多。审核和治理功能同样要落到表设计上。作品表里的status字段配合一个简单的审核备注字段管理员驳回时能看到理由。用户表里加一个status字段表示正常、禁言、封禁三种状态登录拦截器每次都要校验用户状态禁言的用户不能发评论。这些字段在设计阶段就留下比上线后靠打补丁强太多。4. 完整实操流程从建库到前后端联调跑通前面讲的偏架构和设计这一节是真正的落地流程。如果你照着做按这套步骤能把整个项目跑起来。我会按数据库、后端、前端、联调部署四个环节来还原。4.1 数据库初始化核心建表SQL与初始数据建数据库时建议单独建一个初始化脚本脚本里包含建库、建表、插入初始管理员账号三部分。下面是几个核心表的精简版结构实际项目里字段会更多但骨架就是这几张表CREATE DATABASE IF NOT EXISTS literature_forum DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE literature_forum; CREATE TABLE sys_user ( id BIGINT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL UNIQUE, password VARCHAR(100) NOT NULL, nickname VARCHAR(50) DEFAULT , avatar VARCHAR(255) DEFAULT , bio VARCHAR(255) DEFAULT , role TINYINT DEFAULT 1 COMMENT 1-用户 2-作者 3-管理员, status TINYINT DEFAULT 1 COMMENT 1-正常 2-禁言 3-封禁, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ) COMMENT 用户表; CREATE TABLE work ( id BIGINT PRIMARY KEY AUTO_INCREMENT, author_id BIGINT NOT NULL, title VARCHAR(100) NOT NULL, category VARCHAR(30) DEFAULT , summary VARCHAR(500) DEFAULT , cover VARCHAR(255) DEFAULT , status TINYINT DEFAULT 0 COMMENT 0-草稿 1-待审核 2-连载中 3-完结 4-已下架, word_count INT DEFAULT 0, like_count INT DEFAULT 0, favorite_count INT DEFAULT 0, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, INDEX idx_author (author_id), INDEX idx_status_time (status, create_time) ) COMMENT 作品表; CREATE TABLE chapter ( id BIGINT PRIMARY KEY AUTO_INCREMENT, work_id BIGINT NOT NULL, chapter_no INT NOT NULL, title VARCHAR(100) NOT NULL, content MEDIUMTEXT, word_count INT DEFAULT 0, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, INDEX idx_work (work_id) ) COMMENT 章节表; CREATE TABLE comment ( id BIGINT PRIMARY KEY AUTO_INCREMENT, work_id BIGINT NOT NULL, chapter_id BIGINT DEFAULT NULL, user_id BIGINT NOT NULL, content VARCHAR(500) NOT NULL, parent_id BIGINT DEFAULT NULL, status TINYINT DEFAULT 1 COMMENT 1-正常 2-删除, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, INDEX idx_work_time (work_id, create_time) ) COMMENT 评论表; CREATE TABLE like_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, target_type TINYINT NOT NULL COMMENT 1-作品 2-评论, target_id BIGINT NOT NULL, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_user_target (user_id, target_type, target_id) ) COMMENT 点赞记录表;初始化数据最少要包含一个管理员账号密码用BCrypt加密后的字符串插入。这样启动项目后直接用管理员账号登录管理端不用再想办法注册管理员。4.2 后端工程搭建配置与代码结构后端工程用Maven管理依赖主要包含spring-boot-starter-web、mybatis-spring-boot-starter、mysql-connector-java、pagehelper-spring-boot-starter、jjwt、hutool这些。Hutool是我比较喜欢集成的工具库里面有很多省时间的静态方法。application.yml里几个关键配置项如下server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/literature_forum?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: root driver-class-name: com.mysql.cj.jdbc.Driver mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.xabo.entity configuration: map-underscore-to-camel-case: true pagehelper: helper-dialect: mysql reasonable: truemap-underscore-to-camel-case必须开启这会让数据库的create_time自动映射到Java实体里的createTime少写很多resultMap。PageHelper的reasonable设为true后页码超大或超小时会自动修正避免前端传page9999直接把查询拖垮。后端包结构推荐这样分controller、service、mapper、entity、common、config。common放统一返回结果、全局异常处理、JWT工具类config放WebMvc配置和拦截器注册。经验之谈包结构里不要放util这种大杂烩目录每个工具类都放进对应职责的包层代码后期好找。4.3 核心接口落地从Service到Mapper的完整写法我以“作品列表分页查询”为例这条链路覆盖了Controller、Service、Mapper三层// Controller GetMapping(/work/list) public ResultPageInfoWorkVO list(RequestParam(defaultValue 1) Integer pageNum, RequestParam(defaultValue 10) Integer pageSize, RequestParam(required false) Integer status, RequestParam(required false) String category) { return Result.success(workService.pageQuery(pageNum, pageSize, status, category)); }// Service public PageInfoWorkVO pageQuery(Integer pageNum, Integer pageSize, Integer status, String category) { PageHelper.startPage(pageNum, pageSize); ListWorkVO list workMapper.selectByCondition(status, category); return new PageInfo(list); }select idselectByCondition resultTypecom.xabo.entity.WorkVO SELECT id, title, category, summary, cover, status, word_count, like_count, create_time FROM work where if teststatus ! null AND status #{status} /if if testcategory ! null and category ! AND category #{category} /if /where ORDER BY create_time DESC /select代码的核心关键是PageHelper.startPage一定要生命周期短它只对下一条执行的SQL生效。所以我习惯在Service方法的第一行调用它且这个Service方法里只有一条mapper查询。如果有人在一段代码里穿插多条查询分页数据就会跑到别的查询上去这是使用分页插件最容易踩的坑之一。Service层的其他地方事务注解Transactional的作用会被低估。发布章节这个操作既要插入章节记录又要更新作品的总字数和总章节数任何一个失败都会导致数据不一致所以发布接口必须加事务。不要觉得事务是数据库专家才关心的事这种跨表写入的场景事务就是基础要求。4.4 前端工程搭建Vue环境与请求封装前端工程用Vue CLI创建后统一安装vue-router、axios、element-ui、vuex这几个依赖。请求封装是一个必须做好的环节否则每个页面都写重复的axios调用代码肉眼可见地烂。我在项目里把axios封装成request.js核心逻辑是请求拦截器从localStorage取出Token拼到Header的Authorization字段响应拦截器统一处理HTTP状态码后端返回code401时跳转登录页code200时直接return data。这样每个页面的API调用都极其简洁// api/work.js import request from /utils/request; export function getWorkList(params) { return request({ url: /work/list, method: get, params }); }路由部分我分成两层前台路由和管理端路由。管理端路由统一挂在Layout组件下面并加前置路由守卫router.beforeEach((to, from, next) { const token localStorage.getItem(token); if (to.path.startsWith(/admin) !token) { next(/login); } else { next(); } });这个守卫只做了最基础的登录判断更细的权限校验还是得靠后端接口鉴权。前端路由守卫是体验层面的东西真正的安全边界永远在后端。4.5 联调、打包与部署本地与生产环境的差别本地联调最常见的痛点是跨域。Vue开发服务器默认在8081端口后端接口在8080端口浏览器直接请求会跨域。开发环境我推荐用Vue CLI的devServer代理而不是在后端开CORS// vue.config.js module.exports { devServer: { port: 8081, proxy: { /api: { target: http://localhost:8080, changeOrigin: true, pathRewrite: { ^/api: } } } } }这样前端请求统一写/api/work/list代理到后端就是/work/list生产环境把/api路径交给Nginx反向代理前端代码不用改动联调体验非常顺畅。生产部署时前端执行npm run build生成dist目录把dist里的静态文件放到Nginx的HTML目录再配置一个反向代理把/api的请求转发到Java后端。SpringBoot后端就一个jar包java -jar运行即可。如果服务器内存紧可以在启动命令里限制JVM堆内存java -Xms256m -Xmx512m -jar xabo.jar避免一台小机器同时跑MySQL和Java后端起不来。5. 常见问题与排查技巧实录这节是我最想写的部分。很多项目能跑起来但只有真的踩过坑才知道问题出在哪。下面这些坑全部是我在实际开发里遇到过的有些查了大半天才定位希望你看完能直接绕开。5.1 MyBatis的坑从占位符到分页插件先说#{}和${}的区别。很多人不知道这个区别会在动态SQL里把参数直接用${}拼接。比如排序字段如果写ORDER BY ${orderBy}参数被拼成SQL的一部分存在SQL注入风险。#{}是预编译占位符安全但它只适合值传递不能用于表名、字段名、排序方式这种结构性位置。像动态排序列这种场景我更推荐用白名单映射把前端传过来的字符串映射到代码里预定义好的安全列名。再说XML文件里的特殊字符。查询时间范围时经常要用到小于号比如create_time #{endTime}这种SQL直接写在XML里会报错。解决办法是转义或者用 包起来![CDATA[ AND create_time #{endTime} ]]这个报错信息很误导人初看像SQL语法错误实际是XML解析问题。报错后先检查XML里有没有裸写特殊字符是我排错的第一反应。最后是PageHelper的经典误区。在同一段逻辑里先调startPage再调用了一连串的mapper查询分页会作用在错误的SQL上。我踩过一次就是循环里分页同事写的循环里查了两次list结果分页数据一半对一半错非常难排查。用分页插件就记住一条铁律startPage之后只允许跟一条查询语句。5.2 前后端联调跨域、Token与状态持久化前后端联调经常会遇到“接口明明通了但浏览器里报跨域”。如果你用了Nginx代理或devServer代理基本上不会出现这个问题。如果确实要后端开CORS记得把allowedOrigin配成具体的域名不要用*尤其是允许携带Cookie时通配符会直接被浏览器拦掉。另一个高频问题是前端页面一刷新用户登录状态就丢了。原因在于Vuex是内存状态刷新后就清空了。解决方法是把Token存到localStorage页面加载时在路由守卫里检查localStorage同时调用一个获取当前用户信息的接口去刷新Vuex里的用户数据。顺序要对先拿Token再拉用户信息最后放行路由。Token还有一个容易被忽略的坑机器时间不一致。后端签发Token时用的过期时间是服务器时间如果前端的电脑时间比服务器快了几分钟请求走一遍代理就有可能出现“刚登录就被提示过期”的诡异现象。排查时先看两边的系统时间是否一致这个方向很多人想不到。5.3 内容安全与性能细节文学创作社区的评论、标题、正文都会面临内容安全问题。基础的做法是后端做一层XSS过滤即使前端编辑器已经处理过后端也不能信任任何输入。富文本内容尤其麻烦最简单稳妥的方案是配置一个白名单工具只允许p、br、strong、em、img、a等常见标签其余的统统剥掉。直接用正则去黑名单匹配脚本标签很容易被各种编码绕过。SQL注入防护前面说了用#{}这里再说一个容易漏的点like查询。用户搜索关键词时如果直接拼接%加keyword再加%就引入了通配符注入风险。搜索接口的参数也要走预编译用CONCAT(%, #{keyword}, %)的方式既满足模糊查询又不会把用户输入当成SQL结构。性能上最值得优化的就是作品列表页。分类筛选加时间排序这套查询如果没有合适索引数据量上到几万条就会出现明显卡顿。我在work表建的idx_status_time联合索引就是为这类查询准备的。真实项目里大列表页如果还要做深分页pageNum超过一万页时会很吃力优化手段有几种可以用lastId游标方式替代offset翻页也可以限制最大查询页数。对个人项目来说限制页数是性价比最高的办法。5.4 上线前建议检查的几件事项目的开发环境和生产环境配置必须分离。如果直接把application.yml里连本地数据库的账号密码打成jar包扔到服务器上等于公开漏洞。我用SpringBoot的profile机制来切换本地用application-dev.yml生产用application-prod.yml启动时加--spring.profiles.activeprod数据库密码还可以用环境变量引用。上线前最好把日志配置补齐。项目里默认的日志只有控制台输出一旦jar包在后台跑日志除了写进nohup.out之外最好再配置一个按天滚动生成的文件大小限制。不用额外引入日志框架logback-spring.xml配一下就能实现。还有一个容易被忽略的细节前端build之后静态资源首次加载会比较大。处理办法很简单在Vue Router里配置路由懒加载让每个页面的JS按需加载首屏性能能提升不少。加上Nginx开启gzip压缩几个大文件压缩完体积能减少一半访问体验完全是两回事。做这类全栈项目我个人最大的体会是代码写得好不好往往不在某个技巧上而在你是否能从第一行就清楚整个系统的数据流向。xabo这个项目用最经典的技术栈把用户端、作者端、管理端完整串起来很适合拿来当作理解Web全栈开发的完整样本。如果你正在做类似的系统我建议你从管理端开始做先把审核和统计打通再去打磨用户端体验顺序反了很容易陷进无穷无尽的前端样式调整里。最后再分享一个小技巧所有的请求和响应日志一定要尽早加上。不是那种print语句而是用一个拦截器统一打印请求路径、参数、耗时和响应状态。千万别小看这个东西项目联调阶段它能帮你省下至少一半的排错时间。等你真的靠着这份日志在十分钟内定位了一个看似玄学的线上问题就会回来感谢这个习惯。
