1. 新闻发布管理系统的业务底色它不只是增删改查接触过内容类项目的人大概都有体会新闻发布系统这种需求看起来简单真正拆开之后却常常比想象中复杂得多。我接手过一个类似的模拟项目X最初需求描述只有几行字做一个后台发布新闻、前台展示新闻的网站。结果真正梳理业务时才发现背后至少要支撑三类人群普通访客要看资讯编辑要写稿、改稿管理员要审核、发布、下线、置顶。光是这三类角色就有七种以上的状态流转更不用提访问量统计、搜索、分页、封面图上传这类边角需求。用Spring Boot搭后端服务、Vue搭建后台管理界面是这个领域非常成熟的技术组合。Spring Boot负责把业务逻辑、数据持久化、权限校验这些重活揽下来Vue负责把操作界面做得像模像样。如果是个人学习或者中小团队做内部资讯系统这套方案在开发效率和后期维护之间能达到比较舒服的平衡点。本文适合刚接触前后端分离项目的开发者也适合正在设计内容管理类系统的同学参考——我会把一个基于Springbootvue的新闻发布管理系统从建模到落地的全过程讲清楚包括表结构、状态机设计、权限控制、前端页面编排和部署时容易踩的坑。这个项目的核心矛盾在于新闻内容的生产-审核-发布-下线是一条完整的生命周期任何一个环节的权限和状态约束不到位系统就会变成一锅粥。很多新手在开发时只做了管理员可以发新闻这一个功能后续被追问如何让编辑提交但管理员审核后才显示时又得推翻重来。我这次会从建模源头就把这些细节纳入考虑而不是做一个能跑但不可用的Demo。2. 数据库与状态流转设计一张新闻表的决策空间2.1 新闻主表的核心字段新闻发布系统的第一张核心表自然是新闻主表。经验上不要一开始就设计二十几个字段先抓住主干后续再根据页面展示需求做扩展。我的设计思路是标题、摘要、正文、封面图、所属栏目、作者、发布状态、审核状态、发布时间、下线时间、置顶标记、浏览量、排序权重。值得多说两句的是标题和正文的字段类型。标题不建议用varchar(50)这种过短的类型很多新闻标题长建议varchar(200)。正文用text文本类型就好如果将来需要保留富文本格式可以考虑加一个正文原始内容字段保存HTML片段。另外封面图存储路径我倾向于直接存相对路径而不是存Base64避免给数据库制造不必要的膨胀。CREATE TABLE news ( id BIGINT PRIMARY KEY AUTO_INCREMENT, title VARCHAR(200) NOT NULL, summary VARCHAR(500), content TEXT, cover_image VARCHAR(255), category_id BIGINT COMMENT 所属栏目ID, author_id BIGINT COMMENT 作者/编辑用户ID, status TINYINT COMMENT 1-草稿 2-待审核 3-已发布 4-已下线 5-被驳回, publish_time DATETIME, offline_time DATETIME, is_top TINYINT DEFAULT 0, view_count INT DEFAULT 0, sort_order INT DEFAULT 0, create_time DATETIME, update_time DATETIME, deleted TINYINT DEFAULT 0 );这里我把审核状态直接并入status字段而不是单独拆一个audit_status表。很多项目喜欢把发布状态和审核状态分开结果就是状态组合爆炸写着写着所有接口都开始if-else。我更推荐的思路是让status本身覆盖新闻从草稿到下线的全部阶段用一个状态机约束合法流转上层逻辑清爽得多。2.2 状态机约束合法流转新闻这条生命周期里合法的状态跳转应该是有限的草稿可以提交审核待审核可以被通过变成已发布也可以被驳回回到草稿已发布的新闻可以被下线下线后的新闻可以重新发布也可以修改后再次提交。非法跳转包括从草稿直接变成已发布、从已发布直接跳回待审核等。我在后端Service层里专门封装了一个方法集中处理状态流转校验。这种统一收口的好处是无论Controller层有多少个入口最终都不会违反状态约束。public void changeStatus(Long newsId, Integer targetStatus, Long operatorId) { News news newsMapper.selectById(newsId); if (news null) { throw new BusinessException(新闻不存在); } boolean legal statusTransition.isLegal(news.getStatus(), targetStatus); if (!legal) { throw new BusinessException(非法的状态流转: news.getStatus() - targetStatus); } // 补充权限校验、时间字段更新、操作日志记录 }围绕状态机做一些单元测试也很有价值。我见过不少项目状态流转逻辑散落在多个接口里每改一个功能就要把所有相关接口都排查一遍。把合法流转表集中维护配合测试用例覆盖常见路径后面新增功能时会踏实很多。2.3 用户、角色与栏目设计系统里的用户沿用RBAC模型用户表、角色表、用户角色关联表、权限表、角色权限关联表。一个用户可以有多个角色比如既写稿又做审核。角色权限树的划分如下普通编辑可以新建新闻、编辑自己的草稿和待审核状态尚未被锁定的内容审核员可以对待审核新闻执行通过或驳回管理员则拥有全部权限包括用户管理、栏目管理和下线操作。栏目表非常简单就是一下层级的分类例如国内、国际、科技、体育。设计上只需要id、名称、编码、排序这几个字段。记住不要搞无限递归的树形栏目很多新闻站只需要两层结构子栏目挂在父栏目下就够了过度设计只会增加前后端联调成本。3. 后端工程结构与登录鉴权先跑通安全的根3.1 Spring Boot工程该拆成几层我用Spring Boot搭建后端采用经典的分层结构Controller、Service、Mapper。如果是特别大的项目会引入领域驱动设计或者微服务拆分但新闻发布管理系统还远没有到那个复杂度。分层过多反而让人在一堆抽象类里迷路分层过少又会变成Service里堆几百行业务逻辑。我实际推荐的结构如下com.example.news ├── controller # 接收HTTP请求参数校验调用Service ├── service # 业务逻辑、状态流转、权限判断 ├── mapper # MyBatis-Plus的BaseMapper接口 ├── entity # 数据库实体类 ├── dto # 视图层对象避免直接把实体暴露给前端 ├── config # 拦截器、安全配置、跨域配置 └── common # 统一返回结果、异常、工具类在Controller层避免直接接收HttpServletRequest这种Servlet原始对象尽量用DTO对象接收参数。这样Swagger文档更清晰参数校验也更容易统一处理。统一返回结果的格式也选在项目一开始定好我就是用code、message、data三字段结构后续整个前端axios拦截器都依赖这个结构。3.2 登录鉴权为什么不建议用Session这个项目里我选择了JWT做登录鉴权。原因很直接前后端分离部署时前端可能跑在某个域名的静态服务上后端跑在另一台服务器的同一个域名或不同域名下Session的跨域处理要考虑的细节更多。JWT把用户身份信息放在Token里后端只做签名验证天然适合无状态接口。Spring Boot整合JWT整体链路是用户登录时校验用户名密码通过后生成JWT返回前端前端每次请求在请求头里携带Authorization字段后端用一个拦截器或者Filter解析JWT把当前用户信息放进ThreadLocal供业务层随时获取当前操作者是谁。// JWT生成的核心逻辑 String token Jwts.builder() .setSubject(username) .claim(userId, userId) .claim(role, roleCode) .setExpiration(new Date(System.currentTimeMillis() 30 * 60 * 1000)) // 30分钟过期 .signWith(SignatureAlgorithm.HS256, secretKey) .compact();这里要特别注意过期时间。许多初学者把Token有效期设置成7天做出来的系统安全防线形同虚设。我的建议是Token有效期30分钟左右搭配一个RefreshToken机制来续期这里不再展开。如果只是内部学习项目30分钟的Token配合前端401状态拦截跳转登录页也足够用了。3.3 权限校验前置与后置结合仅登录还不够系统里不同角色能做的事情差别很大。Spring Security当然可以在方法上用注解控制权限但更直接的是在Service里做二次判断。为什么两者都要因为光靠注解控制接口级别容易漏掉数据级的权限判断——比如编辑只能修改自己创建的新闻而这个约束显然不能靠一个简单的角色注解来完成。我的做法Controller层判断角色类型比如管理员接口要求ROLE_ADMINService层判断归属关系比如编辑要修改新闻时校验authorId是否等于当前登录用户ID。这样角色权限和资源归属权限都覆盖到了调用链路上也不会出现某个人能越权改别人稿件的情况。4. 核心接口落地发布、审核、置顶、下线4.1 新闻发布接口的完整流程发布新闻这个接口我最终拆成了两步保存草稿和提交审核。很多系统里保存草稿和立即发布是两个完全不同的动作这个理解要从一开始就建立起来。编辑在前端点击保存草稿后端接收的是status1的新闻数据可能内容还没填完整所以校验规则要宽松点击提交审核后端要严格校验标题、正文、栏目、封面图是否齐全然后才把状态改成待审核。我在DTO里加了一个action字段来区分这两个动作public Result saveOrSubmit(RequestBody NewsDTO newsDTO) { if (draft.equals(newsDTO.getAction())) { return articleService.saveDraft(newsDTO); } else if (submit.equals(newsDTO.getAction())) { return articleService.submit(newsDTO); } return Result.error(未知动作); }不要小看这个设计很多项目把这俩混在一起结果就是编辑随手点了保存新闻就到线上了。审核流程的存在意义就是人写的东西需要另一个人确认。4.2 审核驳回时为什么要写原因审核接口承担的是把关人角色。审核员看到待审核新闻后有两个选择通过新闻进入已发布状态设置publish_time为当前时间驳回新闻回到草稿状态同时填写驳回原因让编辑端直接可见。驳回原因存储我一般放在单独的操作日志表里这样新闻主表不用加多余的字段所有状态变化的历史也保留下来了。前端编辑看到自家稿件被驳回如果没有原因只能再猜一遍编辑重点效率很低。4.3 置顶和下线排序与可见性控制置顶操作比较简单设置is_top1再更新sort_order值。排序逻辑我定为置顶的新闻按sort_order倒序再按发布时间倒序非置顶的按发布时间倒序。这条规则统一写进SQL就不用前端做两套逻辑。SELECT * FROM news WHERE status 3 AND deleted 0 AND publish_time NOW() ORDER BY is_top DESC, sort_order DESC, publish_time DESC LIMIT #{offset}, #{pageSize}下线操作本质上是把状态改成已下线而不是从数据库删除。已下线的新闻还需要保留访问路径吗我的处理是下线后前端新闻列表不再展示但通过旧链接直接访问详情页时仍返回基础内容并追加该新闻已下线提示。这样对SEO和已分享出去的链接都更友好。真正从数据库删除的操作只提供给管理员且使用逻辑删除标志位。4.4 搜索分页的两种实现方案搜索功能最朴素的方案是用SELECT WHERE title LIKE %xxx%对于几十万条以内数据的小型新闻站足够用了。如果数据量超过百万条再考虑引入Elasticsearch这类搜索引擎。我不建议一开始就上搜索引擎它带来的运维成本和索引一致性维护成本会远超项目本身的收益。分页实现直接用MyBatis-Plus的Page对象简单直接。需要注意的一点是分页查询返回的记录要配合发布状态和时间条件过滤不能让草稿、驳回状态的数据露出去。另外给前端返回数据的时候统一用PageVO封装前端只需要消费records、total、pageNum、pageSize这几个字段。5. 前端Vue的页面编排与接口对接5.1 后台管理界面的视图结构Vue这边的后台管理界面我用的是经典布局左侧菜单栏、顶部用户信息栏、右侧内容区。菜单项根据用户登录后的角色动态生成而不是写死在前端路由里。动态路由的效果是编辑登录后看不到审核菜单审核员登录后看不到用户管理菜单。路由级权限控制主要依赖Vue Router的导航守卫。登录后后端返回当前用户的角色列表前端存到Vuex/Pinia状态管理里每次路由跳转时判断目标路由的meta字段要求哪些角色不匹配则重定向到401页面。这套逻辑实现几十行代码但价值非常高不然前端页面随便改一下路由就能看到各种本不该看的界面。router.beforeEach((to, from, next) { const token store.state.token if (!token) { next(/login) return } const roles store.state.roles if (!roles || roles.length 0) { store.dispatch(fetchUserInfo).then(() { next({ ...to, replace: true }) }) return } if (to.meta.roles !to.meta.roles.some(r roles.includes(r))) { next(/403) return } next() })5.2 axios封装与令牌处理前端所有请求都通过axios完成但绝不能每个页面单独写一个axios实例——那样的话拦截器逻辑要重复写几十遍。我会在utils/request.js里封装一个统一实例做三件事请求头自动带Authorization Token响应code不是0时统一弹出错误提示后台返回401状态码时自动清理本地Token并跳转登录页。service.interceptors.response.use( response { const res response.data if (res.code ! 0) { Message.error(res.message || 请求失败) return Promise.reject(new Error(res.message)) } return res.data }, error { if (error.response error.response.status 401) { store.dispatch(logout) router.push(/login) } return Promise.reject(error) } )有件事要提醒本地存储Token存在localStorage里会有XSS风险存在Cookie里又要注意CSRF。很多内部项目直接用localStorage图省事我建议至少加一层敏感操作二次确认校验当前用户是否本人。5.3 文件上传与富文本编辑器新闻的封面图上传是个刚需。后端用一个通用上传接口接收MultipartFile按日期分目录存储生成UUID拼文件名。注意校验文件类型和大小通常图片限制不超过5MB类型只允许jpg、png、webp。如果部署环境有Nginx前端可以直接通过Nginx访问静态文件目录不必走后端接口读图片流。富文本编辑器这是内容系统绕不开的组件我在项目里用的是一套基于a-vue的富文本编辑器方案。关键是在提交之前要处理掉编辑器里的危险脚本标签同时限制图片最大尺寸防止编辑传一张10MB的原图上来把页面拖垮。这里可以在前端编辑器的配置里做一次压缩处理也可以在后端保存前对HTML内容做一遍清洗两个节点都做更稳妥。5.4 列表页、编辑页与审核页前台新闻展示页如果是普通访客访问的通常独立做一个门户页面按栏目展示新闻卡片。后台的新闻列表页则要提供筛选条件按标题、栏目、状态筛选表格展示标题、栏目、作者、状态、发布时间、置顶标记操作列里有编辑、提交审核、审核入、置顶/取消置顶、下线这些按钮各自根据当前行的状态动态显示。比如状态是已发布的行才显示下线按钮待审核的行显示审核按钮草稿状态下则显示提交和编辑。编辑页和审核页可以复用同一套新闻操作组件。不同点在于编辑页里表单可编辑、可保存草稿、可提交审核审核页里表单只读顶部增加通过与驳回两个操作按钮驳回时需要输入原因。这套复用能减少很多重复代码维护起来也比较顺手。6. 部署实测中的三个坑与优化方向6.1 跨域配置的正确姿势前后端分离开发时跨域是第一个横在面前的问题。后端用Spring Boot的CORS配置允许的源要写前端实际运行的Origin不能简单用*。同时要确保允许Authorization请求头让浏览器可以携带Token访问。如果部署时用Nginx做了反向代理让前端和后端共用同一个域名只是在路径上做区分——比如/api前缀转发到后端服务——那么浏览器端根本不存在跨域问题。这是实际生产环境更推荐的方案开发环境用Vite代理转发生产环境用Nginx反向代理代码里不做跨域处理反而更干净。6.2 时间格式化与数据库时区问题前端显示新闻发布时间如果发现时间差了8小时多半是Jackson序列化时区配置的问题。Spring Boot后端返回JSON时默认时间可能是UTC格式而前端东八区拿到字符串后直接展示就会错位。我的处理是统一在application.yml中配置Jackson的时区为GMT8同时按yyyy-MM-dd HH:mm:ss格式输出。数据库连接的url参数里也最好显式加上serverTimezoneAsia/Shanghai避免MySQL与Java进程时区不一致导致插入的时间错乱。这类问题排查起来非常难受因为开发环境偶尔正常、测试环境偶尔异常经验上不如一开始就写死时区。6.3 数据隔离、缓存与性能走向项目跑顺之后下一步的扩展方向大致有三条。第一是接口层引入本地缓存如Caffeine给新闻列表页加十分钟粒度的缓存能显著减少数据库压力。要注意更新新闻时必须清掉对应缓存否则列表页会出现明明下线了还在展示的尴尬情况。第二是图片和静态文件迁移到对象存储。本地磁盘存放封面图在单机部署时没问题但随着数据增长和扩容需求对象存储加CDN是必然趋势。这个改造对业务代码的影响其实不大主要是上传和访问的URL指向变了。第三是操作日志和数据报表。审核操作、下线操作、置顶操作这些全都要记录操作人和操作时间后续想统计编辑提交审核到审核完成平均耗时这类指标就靠这些日志数据。有些灵动性的运营需求没有历史日志完全没法回溯。6.4 我踩过的一个状态漏洞最后分享一个当初真实踩过的坑。在做状态校验时我最初只校验了目标状态是否合法却忘了校验当前用户是否有权限操作这条新闻。结果就出现了一个问题普通编辑A可以把自己创建的新闻提交审核也能点击审核按钮只不过走到Controller层时被角色注解挡住了但权限校验只挡接口不挡Service如果绕过Controller直接调用Service方法就能把别人的新闻强制下线。那次修复之后我定了一个规矩任何修改新闻状态的方法第一步都必须拿到新闻的author_id和当前操作者的userId做比对。角色权限管能干什么归属校验管能对谁干两者的交集才是真正安全的状态修改。这个教训也算是对这套新闻发布管理系统最核心安全逻辑的总结。整个系统开发下来我最大的体感是从前端动态菜单到后端状态机再到数据库字段约束每一层都在互相兜底。新闻发布这类看似标准的业务真正下钻之后会发现有很多决策空间把这些决策点想清楚代码怎么写都在其次了。