大概半年前一位做策展的朋友找到我说他们线下的艺术空间积累了一批青年创作者的作品一直想做一个在线展示渠道。需求听起来很朴素“能浏览图片、能按分类筛选、后台能上传和管理作品就行。”但等项目进入设计阶段后才发现这个看似简单的内容展示平台背后牵扯到用户体系、文件存储、权限控制、前后端交互、部署上线等一系列问题。这篇文章就把我从零搭建这个SpringBootVue艺术作品展示平台的过程完整复盘一遍包括技术选型的理由、数据模型怎么设计、后端与前端各自的实现链路以及我在部署阶段踩到的一个真实故障。计划做同类作品站、个人画廊、内容型网站的朋友可以参考这套方案进行功能取舍和扩展。1. 项目起手这个“展示平台”到底要解决什么问题1.1 从线下展厅到线上平台核心需求拆解线下展厅的逻辑是一次性把几十件作品挂到墙上观众按动线浏览。线上平台不能简单复制这个逻辑因为访客的来源、停留时间、访问设备都不一样。我一开始和策展朋友梳理需求时把“线上展厅”拆成了四个角色视角游客不登录就能浏览作品、按分类筛选、搜索这是平台最大的流量来源。注册用户在游客基础上增加评论、点赞、收藏的能力目的是积累互动数据激励创作者。创作者艺术家可以上传自己的作品、编辑作品信息、查看自己作品的浏览和互动情况。管理员负责审核创作者上传的作品管理用户、分类和平台基础配置。为什么要把角色拆得这么细核心原因是版权与内容安全。艺术作品和普通博客文章不一样图片一旦被随意上传、盗用对创作者的伤害很大。所以平台不能开放自由上传必须走“创作者上传——管理员审核——公开可见”的链路。审核动作意味着后台管理系统必须存在权限边界必须清晰这也是这个项目相比普通CRUD系统多出来的复杂度。另外一个容易被忽略的点是作品的“展示形态”本身也是个需求。单张图片是最基础的但创作者还会上传系列作品、作品细节图、创作说明。所以我后来在数据模型里考虑到了“作品主图 详情图列表”的结构而不是简单的一张图一条记录。这个设计在前期多花了一点时间后期做详情页大图预览时非常省事。1.2 技术选型SpringBootVue在这个场景下赢在哪先交代一下我当时的选型背景。后端团队长期使用Java前端则两三个人维护过Vue项目。在这个前提下SpringBoot Vue几乎是顺理成章的选择但我还是把其他方案过了一遍方案优势在这个场景下的问题纯Spring Boot Thymeleaf部署简单页面交互弱瀑布流、图片预览、后台表格体验太差前后端分离 SpringBoot Vue职责清晰生态成熟部署多一个Nginx环节联调成本略高Node.js全栈上手快团队不熟文件上传和权限控制的成熟方案少Python Flask 模板开发快后续做移动端API时还得补框架不如一步到位我最终选择SpringBoot 2.7 Vue 2 Element UI理由很实在SpringBoot的自动配置和生态能快速撑起REST API、文件上传、JWT鉴权这些基础能力Vue的双向数据绑定和组件化特别适合信息流展示一类页面Element UI的后台表格和表单能直接覆盖管理端大部分需求。数据存储用MySQL因为表结构明确、事务和关联查询都方便MyBatis-Plus作为ORM减少单表CRUD的重复代码。这里插一个经验版本选择不要盲目追新。SpringBoot 2.7和Vue 2在当时都是最稳的组合网上踩坑记录多遇到问题搜得到解决方案。这个项目并不是高并发高流量的场景稳定性比新技术特性重要得多。2. 数据库设计作品平台的骨架怎么搭2.1 核心表结构先理顺用户与作品的关系数据库设计是这个项目里最值得投入时间的环节。我第一版直接按页面想需求作品表、用户表、评论表三张表就开干。结果做到后台管理时发现问题作品和用户的关联关系、创作者与普通用户的角色区分、审核状态的流转都没地方放只好回头重构。第二次设计时我按照“用户—作品—互动”三条线梳理最终定下来这几张核心表用户表sys_userid、username、password、nickname、avatarrole0普通用户 / 1创作者 / 2管理员status启用/禁用create_time作品表artworkid、title、description、cover_url、user_id创作者、category_idstatus0草稿 / 1待审核 / 2已发布 / 3已驳回 / 4已下架view_count、like_count、favorite_countcreate_time、update_time作品图片表artwork_imageid、artwork_id、image_url、sort_order分类表categoryid、name、parent_id、sort_order评论表commentid、artwork_id、user_id、content、parent_id、create_time收藏表favoriteid、artwork_id、user_id、create_time加唯一索引artwork_id, user_id喜欢表artwork_likeid、artwork_id、user_id、create_time加唯一索引artwork_id, user_id这套表结构的核心思路是把“作品图片”单独拆出来因为一个作品往往有多张图拆开存储比用逗号拼接URL字段规范得多。虽然查询时多一次关联但配合MyBatis-Plus的关联查询或分步查询性能完全不是问题。评论表里加parent_id是为了支持二级回复用户回复评论时不必再新建一张表。2.2 分类、标签与状态三个容易想糊掉的设计点分类表是展示平台的检索骨架。我一开始想按“油画、国画、版画、雕塑、水彩、插画、设计”这种一级分类做后来发现很多作品跨类别比如“插画风格的水彩作品”如果只能挂一个分类创作者很难受。参考电商系统的做法我在分类之外加了作品“标签”字段允许一个作品挂多个标签。分类负责组织浏览路径标签负责描述作品属性两者配合使用前端可以做“分类筛选 标签过滤”的组合查询。状态字段是作品内容管理的关键。最初我只设计了“已发布/草稿”两个状态但管理员审核这个环节插进来之后状态就不够了。我最终采用五个状态0 草稿创作者本人都还没准备公开。1 待审核创作者提交进入管理员待办列表。2 已发布审核通过前台可见。3 已驳回内容或版权有问题创作者需要修改后重新提交。4 已下架曾经发布但被管理员或创作者主动下线。这个设计直接决定后台管理列表的查询条件。审核页只需要查到“status1”的数据创作者端则要看到自己所有状态的数据。如果当初把审核状态糊在一个布尔字段里这步一定会返工。2.3 收藏与点赞互动功能的数据模型差异刚开始做互动功能时我犯过一个“经验主义”的错直接把点赞数存进作品表的like_count字段每次点赞就update 1取消点赞就update -1。单独看没问题但并发刷新时数字会飘而且我没法判断当前用户到底有没有点过赞。后来老老实实加了artwork_like表用唯一索引artwork_id, user_id保证同一用户对同一作品只能有一条点赞记录。这样点赞时先查记录是否存在不存在则插入并给作品表的like_count加1。取消点赞时删除记录并给like_count减1。查询当前用户是否已点赞“select count(*) from artwork_like where artwork_id? and user_id?”。收藏表设计思路一致唯一区别是收藏带“列表展示”需求用户收藏夹页面需要分页查出收藏的作品所以favorite表关联artwork后做连表分页即可。点赞数用冗余字段是为了避免每次展示都要count一次查询大列表时性能更好。两个数字和实际记录可能短暂不一致但对展示类应用来说无伤大雅。如果对一致性要求高的项目可以引入消息队列最终一致性不过当前规模用不上。3. 后端实现上传、展示与互动的关键链路3.1 文件上传从接收文件到安全落盘的完整流程文件的接收和存储是后端最核心的模块。这里我不建议直接把前端传过来的文件名存进数据库因为存在路径穿越、重名覆盖、非法字符一堆问题。我的做法是前端通过FormData上传MultipartFile到/api/upload接口。后端先做类型校验不只检查扩展名还要检查文件的MIME类型和魔数文件头。限制文件大小这里设置单张图片不超过8MB。用UUID作为新文件名保留原始扩展名。按日期分目录存储例如/upload/2025/03/避免单目录文件过多。返回给前端的路径是/upload/2025/03/uuid.jpg数据库存相对路径不存完整域名URL。类型校验的代码片段Override public String upload(MultipartFile file) { if (file.isEmpty()) { throw new BusinessException(文件不能为空); } if (file.getSize() 8 * 1024 * 1024) { throw new BusinessException(图片大小不能超过8MB); } String originalFilename file.getOriginalFilename(); String ext StringUtils.getFilenameExtension(originalFilename); if (!ALLOWED_EXT.contains(ext.toLowerCase())) { throw new BusinessException(不支持的文件类型); } // 校验文件头魔数防止伪装扩展名 String magic checkMagicNumber(file); if (!ALLOWED_MAGIC.contains(magic)) { throw new BusinessException(文件内容不是有效图片); } String dateDir LocalDate.now().format(DateTimeFormatter.ofPattern(yyyy/MM)); String newFileName UUID.randomUUID().toString().replace(-, ) . ext; String relativePath /upload/ dateDir / newFileName; File dest new File(uploadDir / dateDir, newFileName); // 目录不存在则创建 if (!dest.getParentFile().exists()) { dest.getParentFile().mkdirs(); } file.transferTo(dest); return relativePath; }这里面最值得说的一点是魔数校验。扩展名可以伪造一个html文件改成.jpg后缀也能通过扩展名校验但图片文件的文件头是固定的比如JPEG以FF D8开头PNG以89 50 4E 47开头。读取文件头四到八个字节就能识别真实类型虽然不绝对可靠但能挡住绝大多数恶意文件。这也是内容型平台的基本安全底线。3.2 静态资源映射为什么直接访问不到上传的图片上传后的文件保存在服务器磁盘目录但SpringBoot默认只处理/static、/public等classpath下目录的静态资源磁盘上的目录它是不管的。我一开始直接返回/upload/xxx.jpg给前端浏览器访问时404原因就在这里。解决方法是注册一个资源处理器把/upload/**映射到磁盘目录Configuration public class WebMvcConfig implements WebMvcConfigurer { Value(${upload.dir}) private String uploadDir; Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/upload/**) .addResourceLocations(file: uploadDir /); } }注意这里有个跨平台的坑file:协议要求的路径是file:/绝对路径/最后一定要带末尾斜杠否则会映射失败。Windows下路径分隔符是反斜杠Linux下是正斜杠所以不要把路径写死在配置里而在application.yml中用upload.dir配置不同环境指定不同值。我当初在本地Windows环境一切正常部署到Linux服务器后图片全部404排查了半天最后才发现是配置里路径末尾的斜杠问题。这个后面部署章节会细讲。3.3 作品列表接口分页、筛选与返回结构的统一约定作品列表是前端信息流的核心数据来源。为了同时服务首页瀑布流、分类页、搜索页和管理后台我就设计了一个统一的接口GET /api/artworks。参数设计page、pageSize分页参数。categoryId按分类筛选。tag按标签筛选。keyword标题或描述模糊搜索。status状态筛选前台默认只查已发布status2后台按需传。userId查某个创作者的作品用于个人主页。sort排序方式可选latest最新、mostViewed浏览量、mostLiked点赞量。返回结构封装为统一格式{ code: 200, message: success, data: { total: 128, records: [ { id: 1, title: 某系列作品, coverUrl: /upload/2025/03/uuid.jpg, author: 某创作者昵称, likeCount: 32 } ] } }统一返回结构这件事看起来简单但很多项目做着做着就乱套。我定下规则所有接口要么返回正常数据要么抛出业务异常由全局异常处理器转换成统一错误结构。前端axios拦截器只认code200其他统一弹提示。这样前端不用每个接口单独处理错误分支联调效率提高一大截。实现上使用MyBatis-Plus的LambdaQueryWrapper拼接查询条件分页用自带的分页插件。排序字段注意做白名单校验不要直接把SQL拼接进去避免注入风险。比如sort参数映射到固定字段名而不是把前端传的字符串直接拼进OrderBy。4. 前端Vue部分把作品“讲清楚”的交互细节4.1 首页设计轮播、分类导航与瀑布流首页是访客对平台的第一印象。我参考了一些作品展示类网站的做法把首页分为三个区块第一个区块是推荐的轮播图后台配置推荐位前端用轮播组件展示精选作品的封面大图。这个区块的作用是展示平台的水准第一眼要有冲击力所以图片尺寸统一裁剪为宽幅避免变形。第二个区块是分类导航从/api/categories接口拉取分类列表渲染成一排可点击的标签。点击某个分类当前列表立即切换为该分类下的作品URL同步变化这样刷新页面后还能停留在当前分类而不是跳回首页。第三个区块是瀑布流作品列表。为什么用瀑布流而不是网格因为艺术作品封面比例不统一有的是横幅有的是竖幅瀑布流能最大化利用空间。Vue侧我用了一个开源的瀑布流组件核心是分列布局根据容器宽度分成若干列每张图片进入最短的那一列。但这里有个前端的坑图片异步加载会导致列高度跳动必须等当前批量图片全部加载完毕后再插入下一行。我实现时先获取图片尺寸用new Image()预加载后把height占位算好再渲染进瀑布流体验会稳定很多。4.2 作品详情页大图预览与评论区作品详情页的结构是左侧大图右侧作品信息。大图预览我用了一个图片查看器组件支持点击放大、缩略图切换和全屏查看。对艺术作品展示来说图片的清晰度和缩放体验是硬指标。上传时压缩过的小图不适合作为详情大图所以我在上传环节额外生成了一个大图版本单个文件不超过8MB压缩为最长边1920px存为_large.jpg后缀的文件。详情页展示大图列表页展示中等尺寸缩略图则用于推荐位这样既保证加载速度又不牺牲清晰度。评论区我做了两级结构一级评论显示在列表顶层二级回复嵌套在对应评论下面。发布评论走POST /api/artworks/{id}/comments接口登录后才能评论游客点击评论按钮时弹登录框。这里值得注意的细节是评论内容的过滤与字数限制。我做了前后端双重校验前端限制200字后端再做一次避免绕过前端直接调接口。敏感词过滤我用了一个简单的映射表方案虽然不完美但能满足这个场景的基本要求。点赞和收藏按钮的交互逻辑类似未登录点击时跳转登录页已登录点击时调用接口成功后按钮状态切换数字在本地先加1再等后端返回最终值避免点击后卡顿的感知问题。4.3 前后端联调跨域、Token与axios封装前后端分离联调时最先碰到的是跨域问题。开发环境下前端跑在8080端口后端跑在8081端口浏览器默认拦截跨域请求。我在后端统一处理了CORSConfiguration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }这样配置后开发环境不再有跨域问题但生产环境不依赖它——生产用Nginx反代前端请求/api由Nginx转发到后端服务不存在跨域。所以开发环境的CORS配置仅限于开发生产建议关闭或收紧origin白名单。Token管理这里我踩过一个小坑。JWT拦截器在验证用户身份后把userId放到ThreadLocal里但异步请求或线程池复用时ThreadLocal可能会串数据。我的处理方式是在拦截器结束时remove掉ThreadLocal同时请求级别的上下文使用HandlerInterceptor的afterCompletion方法清理。前端axios的请求拦截器统一从localStorage取出token放到Header的Authorization字段响应拦截器检测到401状态码时清除本地用户信息并跳转登录页。这个流程跑顺之后前后端联调效率提升了一个档次。5. 部署上线一次真实的图片加载故障排查5.1 前后端分离部署的正确姿势开发环境一切正常后部署到测试服务器时才是真正考验项目结构的时候。我采用的部署拓扑是Nginx监听80端口负责域名转发、Gzip压缩、HTTPS终止。前端静态文件dist目录放在/usr/share/nginx/html/art-show/下由Nginx直接托管。所有/api开头和/upload开头的请求反向代理到SpringBoot服务的8080端口。SpringBoot以java -jar art-show.jar方式运行附带application-prod.yml生产配置。前后端分离部署最大的好处是静态资源由Nginx处理性能好后端只处理API职责清晰。不要图省事把前端dist塞进SpringBoot的static目录里后者虽然打包成一个jar部署简单但静态资源夹杂在SpringBoot的逻辑里后续前端单独更新一次就要重新打包整个jar非常不灵活。5.2 图片404排查路径分隔符与大小写敏感部署后遇到的第一个问题就是图片全部加载失败。我访问https://域名/upload/2025/03/xxx.jpg返回404但打开服务器上的文件路径发现文件确实存在。排查链路是这样的先检查Nginx配置确认/upload/确实转发到了后端而不是被当作静态文件处理location /upload/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; }检查SpringBoot日志发现静态资源映射报了个警告Resource handler 没匹配到文件。打开服务器上的application.yml里面写的upload.dir是/data/artshow/upload/看起来没毛病。后来用curl测试时发现服务器上实际创建的目录是/data/artshow/upload/2025/03但Nginx转发后请求的路径是/upload/2025/03/xxx.jpg在Windows上开发的代码里文件存储时用的分隔符是File.separatorWindows下是\Linux下是/按说没问题。真正的问题出在我配置的资源映射路径末尾少了斜杠。我写的是upload: dir: /data/artshow/upload而资源映射拼接后变成file:/data/artshow/upload/按说也能用但SpringBoot在解析路径时对末尾斜杠的处理有要求某些版本在路径拼接上会出问题。改成upload: dir: /data/artshow/upload/后图片恢复。这个问题的深层原因其实是我在Windows开发环境下绝对路径写的是D:/upload/而Linux部署时路径结构发生变化配置没有同步调整最终在资源映射拼接时踩中路径组合的坑。教训就是文件路径配置务必独立成外部配置部署前先验证磁盘目录与配置一致不要想当然。另外一个相关的坑是文件系统的大小写敏感。我在Windows下生成的文件名是UUID.jpgWindows不区分大小写但Linux区分。如果代码里用UUID.JPG作为文件名而实际生成的是UUID.jpg浏览器请求404。排查时要把日志里的文件名和磁盘上的文件名逐一对比。5.3 Nginx的history路由配置前端项目用的是Vue Router的history模式页面路径形如/detail/12而不是带#的hash模式。history模式的好处是URL干净但缺点很明显用户直接访问/detail/12时Nginx不认识这个路径会返回404。解决办法是Nginx配置try_files让所有非API和静态文件的请求都回退到index.htmllocation / { root /usr/share/nginx/html/art-show/; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080; } location /upload/ { proxy_pass http://127.0.0.1:8080; }这里有一个必须注意的顺序问题location /要放在后面/api和/upload的精确匹配要放前面。如果反过来try_files会把/api/artworks当成静态文件去找找不到又回退到index.html导致API请求永远得不到正确响应。我一开始就把通用location /放前面了结果API请求返回的是index.html的HTML内容而不是JSON前端直接解析失败。调整location顺序后一切恢复正常。6. 收尾一些个人体会与后续优化方向这个项目整体用了我两周多的业余时间其中数据库设计和权限体系花掉三分之一前端信息流部分花掉三分之一剩下时间全部耗在联调和部署上。做下来最大的体会有三点第一内容型平台的数据模型决定产品天花板。如果一开始没把“作品”和“作品图片”分离没设计审核状态流后面无论前端怎么写都会受制于后端数据结构。好的数据模型不是一次到位的但要在第一版就预留出明确的状态和关联边界避免推倒重来。第二前后端分离项目的真正成本在“约定”。接口返回结构、错误码规范、Token传递方式、上传路径规则这些约定越早统一联调越顺畅。我最初阶段没有把错误处理约定清楚导致前端每个接口都要单独处理复杂的错误情况浪费了不少时间。第三部署环境的细节会咬人。一次路径末尾斜杠、一次大小写问题、一个Nginx的location顺序任何一个都足以让线上环境陷入“我本地明明没问题”的抓狂状态。建议项目一开始就把部署文档写清楚把外部配置和代码解耦。后续这个平台我打算做三件事一是把图片存储迁移到对象存储服务配合CDN分发解决单机磁盘容量和带宽瓶颈问题二是增加作品集收藏夹的导出和分享功能方便艺术家离线展示三是引入更精细的统计埋点分析每个分类的浏览转化率帮助策展方判断哪些类型的作品最受关注。如果你也在做一个作品展示类项目我的建议是先花两天认真设计数据模型和权限边界再把每一个接口的返回结构定死最后再动手写第一行业务代码。地基打稳了上面盖什么楼都不会晃。
