1. 项目概述与需求拆解1.1 钱币收藏圈的真实痛点钱币收藏这个小众圈子看着不大但信息分散的问题比大多数行业都严重。玩钱币的人都知道找一枚特定版别的钱币有多难——袁大头九年精发版、船洋二十三年、一版人民币的暗记区别这些信息散落在各个微信群、贴吧、论坛里没有一个集中的地方能把“藏品展示、行情交流、交换撮合”串起来。有人手里囤着重复的评级币想出手有人满世界找不到一枚品相合适的收藏币中间的桥梁却只有零散聊天记录。我做这个“基于Spring Boot的钱币收藏交流系统”初衷就是解决这个结构性痛点。它不是一个简单的展示网站而是一个把收藏圈子里的真实业务流程搬到线上的平台藏友注册后维护自己的藏品库上传钱币图片和版别信息需要出手或交换时把藏品挂上交易状态其他用户可以浏览藏品、发起咨询、走交易流程社区板块则承载鉴定求助、行情讨论这些日常交流。整套系统做完相当于把一个线下收藏圈子的核心运转逻辑完整数字化了。1.2 系统能做什么适合谁从功能边界来看这个系统落地的核心模块有四个用户认证与权限控制、藏品管理与图片上传、交易交换流程、社区互动与检索。听起来都是常见功能但缝合在一起恰好覆盖了Spring Boot开发中最典型的几类业务场景——JWT无状态认证、MyBatis-Plus分页与条件查询、事务与并发控制、全局异常处理、文件存储映射、Docker部署。所以说这个项目的受益人群非常明确如果你正打算用Spring Boot做一个完整的前后端分离项目练手或者毕设选题围绕社区、交易、垂直领域平台这套系统的拆解思路可以直接复用。技术难度控制在中等偏上既不会像纯CRUD那样学不到东西也不会碰微服务、高并发那些对新手不友好的深水区。把这套系统从头到尾写明白Spring Boot日常开发里最常用的那些技术点基本就都过了一遍。2. 技术选型与架构设计2.1 为什么选Spring Boot自动装配到底省了什么现在做Java后端选Spring Boot基本没什么悬念但很多人说不清楚它到底好在哪。拿最核心的自动装配机制来说Spring Boot启动时会读取META-INF/spring.factories里声明的自动配置类再由ConditionalOnClass、ConditionalOnMissingBean这些条件注解决定哪些配置生效。你引入spring-boot-starter-data-redis之后只要 classpath 里有Redis相关类RedisTemplate就会自动装配好直接注入就能用。这就是自动装配的价值把过去SSH时代几百行XML配置才能解决的事情变成了“引入依赖即获得能力”。不夸张地说一个Spring Boot项目的初始配置代码量只有传统Spring项目的十分之一。而且排查问题也有方向——遇到“我没配置为什么也能用”大概率是某个自动配置类生效了遇到“我配置了却不生效”首先检查是不是被ConditionalOnMissingBean挡住了。2.2 前后端分离与完整技术栈这个项目采用前后端分离架构前端Vue 3 Element Plus后端Spring Boot。版本上我选的是2.7.18而不是Spring Boot 3。原因很实在Spring Boot 3基于Jakarta EE把javax.*包换成了jakarta.*很多第三方依赖和旧教程里的代码都会踩兼容性坑。2.7.18是2.x系列的最终维护版本生态成熟、踩坑资料全做业务系统求稳它是最合适的选择。后端依赖选型这块我把核心组件和理由整理成了表格组件选型选型理由ORMMyBatis-Plus 3.5.x单表CRUD零SQL自带分页插件和防SQL注入能力数据库MySQL 8.0生态成熟事务和索引能力满足业务需求缓存Redis 5.x验证码、热门榜单、登录token黑名单认证JWT Spring拦截器无状态方案天然适配前后端分离文件存储MinIO / 本地磁盘藏品图片按部署环境选择接口文档Knife4j基于OpenAPI 3调试接口效率高选择MyBatis-Plus而不是纯MyBatis核心原因就一个字快。Java业务系统里大概七成的数据库操作是单表CRUD用BaseMapper接口一行SQL都不用写。需要复杂查询时再在Mapper接口里写Select注解自定义SQL两边兼顾。这个项目里藏品列表的“条件筛选分页”、社区帖子的“板块热度和时间排序”都是MyBatis-Plus的舒适区。3. 数据库设计与核心表结构3.1 从业务流程中抽象实体建表的逻辑应该从用户的使用流程里倒推而不是拍脑袋定几个表就开工。钱币收藏交流系统的核心流程是这样的用户注册登录后创建藏品记录每条藏品可以设置为“展示中”或“可交易”其他用户浏览藏品后发起咨询或交换请求双方达成一致后生成交易记录同时用户在社区板块发帖、评论形成交流闭环。顺着这条链路抽实体至少有六张核心表t_user用户、t_coin藏品、t_coin_image藏品图片、t_trade交易记录、t_post帖子、t_comment评论。这里有一个容易被新手忽略的设计点藏品和交易必须分离。用户先构建自己的藏品库发布交换意向只是在藏品上挂一个状态而不是生成一条交易记录。这样每枚钱币的历史交易轨迹都可以保留下来方便藏友参考行情。3.2 关键表字段与索引设计t_coin藏品表是最核心的业务表字段设计直接影响后续功能的复杂度字段类型说明idBIGINT主键user_idBIGINT所属用户titleVARCHAR(64)藏品名称dynastyVARCHAR(32)年代/版别gradeTINYINT品相分级descriptionTEXT藏品描述priceDECIMAL(10,2)心理价位trade_statusTINYINT0-仅展示 1-可交易 2-交易锁定statusTINYINT0-草稿 1-上架create_timeDATETIME创建时间品相分级这里特别说一下。钱币圈有自己的品相体系未流通、近未流通、极美、美品、上品每一档对应不同的市场溢价。这不是“好中差”几个选项能表达的所以我把它设计成独立字典表用grade字段存字典ID后面要扩展细分品相改字典数据就行不需要改表结构。索引设计上user_id必须加索引因为“我的藏品”“我的交易”全按用户维度查create_time建议和user_id组合成联合索引(user_id, create_time)这样用户查看自己的藏品列表按时间倒序时走索引扫描不需要额外排序。数据量在十万级以内这套设计完全够用。4. 核心功能模块实现4.1 用户认证与权限控制认证方案用的JWT无状态模式。用户登录校验通过后后端签发一个有效期24小时的token前端存在localStorage里每次请求在Header带上Authorization: Bearer xxx。后端用拦截器统一校验token解析出用户ID后放入ThreadLocal业务代码里直接调用CurrentUser.get()就能拿到当前登录用户省去了在接口方法里反复传user_id的麻烦。JWT有个绕不开的缺点token在过期前无法服务端主动失效。所以注销功能不能只在前端删token后端必须维护一个“已注销token黑名单”。我的做法是注销时把token的jti唯一标识写入Redis设置过期时间为token剩余有效期拦截器里先查黑名单再校验签名。这样才算真正实现了“注销立即生效”。权限控制方面普通用户和管理员的接口权限不同。我在Spring Boot拦截器中通过HandlerMethod.getMethodAnnotation(RequireRole.class)做鉴权接口上加注解声明所需角色比在代码里写一堆if (user.getRole() ! ADMIN)干净得多。4.2 藏品发布与多图上传藏品发布页面承载的信息量不小基本属性、品相、年代、描述、心理价位外加最多九张钱币图片。图片上传这块我推荐本地磁盘存储起步而不是一上来就上MinIO或OSS。原因有两个一是本地部署简单不增加额外的服务依赖二是迁移成本完全可控后面需要上MinIO只需要替换存储实现的底层接口Controller层代码不用动。但本地存储有一个必须处理的坑文件大小限制。Spring Boot默认上传大小上限是1MB钱币高清图经常超限。在application.yml里显式调大spring: servlet: multipart: max-file-size: 10MB max-request-size: 50MB超过限制后默认的错误响应信息对前端非常不友好。我习惯在全局异常处理器里单独捕获MaxUploadSizeExceededException返回统一格式的业务错误。另外图片上传不能只存原图。用户在藏品列表页需要缩略图详情页需要大图如果直接渲染原图列表页加载速度会很慢。我用Thumbnailator在上传后立即生成缩略图一行代码就能搞定效果立竿见影。4.3 交易流程与并发一致性交易是这个系统里业务状态最复杂的模块。我定义的状态流转是待确认 → 交易中 → 已完成 / 已取消。每一步状态变更都记录操作日志避免后续纠纷说不清楚。这里要有意识地避免一个新手常犯的错误在同一个Service类里一个事务方法直接调用另一个事务方法。为什么这是坑Spring事务是通过AOP代理实现的自调用不会经过代理对象注解上的Transactional直接失效。结果就是“更新藏品状态”和“生成交易记录”两个操作不在同一个事务里要么状态改了记录没生成要么记录插了状态没变。正确做法是把事务边界内的方法放在独立的Bean中或者用一个事务方法统一编排所有操作。并发场景同样要处理。两个用户同时看中一枚藏品并发起交易如果不加控制两个请求都能读到trade_status1的可交易状态双双进入交易流程。最朴素的解决办法是条件更新做乐观锁boolean locked coinService.lambdaUpdate() .eq(Coin::getId, coinId) .eq(Coin::getTradeStatus, 1) // 只有当前状态为“可交易”才能修改 .set(Coin::getTradeStatus, 2) // 修改为“交易锁定” .update(); if (!locked) { throw new BusinessException(该藏品已被其他用户锁定请刷新后查看); }这个eq条件就是最底层的并发防线。数据库层面规避了超卖式的竞争冲突业务逻辑层不用再加分布式锁简单可靠。4.4 社区互动与检索实现社区板块做了轻量化的论坛设计发帖、评论、点赞不搞好友关系链。帖子按板块划分比如“鉴定求助”“行情讨论”“晒币分享”每个板块独立列表。帖子列表的分页直接用MyBatis-Plus的分页插件配置一个拦截器即可Configuration public class MybatisPlusConfig { Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }检索方面项目初期用LIKE %keyword%就能覆盖需求数据量在百万以下性能问题不大。如果后续收藏圈子需要支持专业术语的分词检索比如“袁大头九年精发版”“船洋二十三年”这种多关键词组合搜索再考虑接Elasticsearch。现阶段刻意过度设计反而会增加复杂度和维护负担。5. 关键难点与安全防护5.1 文件存储路径与访问映射用本地磁盘存图片有个很隐蔽的坑如果开发环境把图片存到项目运行目录的相对路径下用JAR包部署时工作目录指向一个临时路径服务重启后所有历史图片全部丢失。正确做法是配置一个独立的绝对路径作为上传目录不依赖项目运行位置。在application.yml里定义变量file: upload-dir: /data/coin-platform/images然后通过WebMvcConfigurer做静态资源映射Value(${file.upload-dir}) private String uploadDir; Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/images/**) .addResourceHandler(file: uploadDir /); }这样前端访问/images/coin/xxx.jpg就能直接拿到图片后端不需要再单独写一个图片下载接口。核心思路是路径配置要外部化资源映射要显式化千万不要把上传目录和项目源码目录混在一起。5.2 XSS与上传文件安全UGC内容多的系统XSS攻击是躲不开的威胁。用户发帖、留言的内容如果直接存库再原样渲染一个恶意script标签就能偷走访问者的token。在Spring Boot里加一个全局过滤器统一对请求参数做HTML转义是最基础的防护手段。但要注意不能一刀切藏品描述里的合法标点符号、换行符都得保留。我的做法是双保险入参时对普通文本字段做StringEscapeUtils.escapeHtml4转义富文本白名单清洗交给前端配合。对于文件上传更要小心文件名里夹带的攻击payload存储时一律重命名为UUID彻底杜绝路径穿越和恶意文件覆盖的风险。5.3 限流与验证码策略登录接口和发送验证码接口必须做限流。很多项目就是在这里被脚本刷爆验证码通道被滥用用户收不到短信系统口碑直接崩掉。实现方式不复杂用Redis做计数器同一IP每分钟最多请求5次String key sms:limit: ip; long count redisTemplate.opsForValue().increment(key); if (count 1) { redisTemplate.expire(key, 1, TimeUnit.MINUTES); } if (count 5) { throw new BusinessException(请求过于频繁请稍后再试); }注意Redis的increment配合expire这个组合用法首次计数时设置过期时间后续计数自动累加。这个模式在限流场景非常实用。验证码本身也要设置过期时间校验通过后立即删除防止同一验证码被暴力重放。6. 常见问题与排查实录6.1 Spring Boot版本与依赖冲突项目初期被第三方组件的传递依赖坑过一次。某个组件内部引用了旧版spring-web和Spring Boot的依赖管理机制冲突上线后出现诡异的NoSuchMethodError。排查思路是打印依赖树定位冲突mvn dependency:tree -Dverbose -Dincludesorg.springframework:spring-web看到两个版本共存后在引入该组件时用exclusion排除旧版本问题解决。给后来者的建议是核心框架依赖版本一定要显式声明别指望传递依赖的“巧合”凑出正确组合。6.2 MyBatis-Plus分页插件失效分页失效的高频原因有两个第一分页插件拦截器没配进Spring容器第二调用分页方法时Page对象没作为第一个参数传递。还有一种容易被忽略的情况——多个InnerInterceptor共存时顺序不当。比如先配置了乐观锁插件再配置分页插件某些场景下分页会静默失效。排查这类问题的固定步骤是确认容器里注册了MybatisPlusInterceptorBean确认分页参数传对了排除多拦截器冲突。配好之后在单元测试里验证分页结果总条数和当前页数据能省去后面大量联调时间。6.3 跨域问题与联调陷阱前后端分离开发时跨域配置几乎是必踩的坑。Vue的devServer可以配proxy解决开发环境跨域但生产环境前后端分别部署在不同域名下后端必须配置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); } }一个典型症状接口在Postman里调通放到浏览器里就报跨域错误。原因通常有两个——前端请求带了Authorization头但后端的allowedHeaders没包含它或者OPTIONS预检请求被拦截。把allowedMethods显式加上OPTIONSallowedHeaders设为*能解决大部分跨域问题。6.4 打包部署与运行期故障Maven打包最容易犯的错是用scopesystem/scope引入外部JAR打包后JAR包里不包含这个依赖运行直接报ClassNotFoundException。正确做法是把外部JAR安装到本地Maven仓库或者用maven-assembly-plugin特殊处理。另外命令线上环境排查问题时没有源代码的环境看日志经常一头雾水我习惯保留原码对应的可追溯构建记录Git标签和构建参数严格对应这样日志里的代码行号就能直接映射到可读源码不需要借助反编译工具去逆向猜测业务逻辑。7. 上线部署与经验沉淀7.1 一套docker-compose编排搞定前后端前后端一起部署用Docker Compose编排是最省心的方式。项目包含前端、后端、MySQL、Redis、MinIO五个部分我写了一个compose文件统一管理version: 3.8 services: mysql: image: mysql:8.0 environment: MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD} MYSQL_DATABASE: coin_platform ports: - 3306:3306 volumes: - mysql_data:/var/lib/mysql - ./sql/init.sql:/docker-entrypoint-initdb.d/init.sql backend: build: ./backend ports: - 8080:8080 environment: SPRING_PROFILES_ACTIVE: prod DB_HOST: mysql REDIS_HOST: redis depends_on: - mysql - redis nginx: image: nginx:1.24 ports: - 80:80 volumes: - ./frontend/dist:/usr/share/nginx/html - ./nginx.conf:/etc/nginx/conf.d/default.conf - /data/coin-platform/images:/data/coin-platform/images volumes: mysql_data:这里有一个必须强调的点MySQL数据必须挂载到命名卷或宿主机目录否则一次docker-compose down就能让所有注册用户、所有藏品数据灰飞烟灭。这个配置里我把MySQL数据挂到了命名卷mysql_dataCompose删除容器不会删除卷。文件上传目录也单独挂载和容器生命周期解耦。数据库密码、Redis密码、MinIO密钥这些敏感配置一律通过环境变量传入不写死在compose文件里。部署时配一份.env文件如果文件被误提交到代码仓库立刻用docker-compose config检查一下有没有敏感信息泄露。7.2 线上性能问题与调优实践上线后的真实流量能暴露开发阶段完全看不到的问题。我这边实测发现一个慢SQL藏品列表按用户和时间排序的查询走了全表扫描数据量一上来响应就慢。优化方式是在t_coin表加联合索引(user_id, create_time)再给热门板块的帖子列表加Redis缓存接口响应时间从800ms降到了120ms效果很明显。性能优化有一条铁律先定位再优化不要凭感觉加缓存。我的排查流程是打开慢查询日志找到耗时Top N的SQL用EXPLAIN看执行计划确认是否走了索引再针对性加索引或调整查询逻辑。线上问题定位的另一个细节接口的异常日志一定要打印完整上下文包括请求参数、请求路径、用户ID、异常堆栈。日志信息不全的话排查问题就是在盲人摸象。这几轮跑下来我的体会是钱币收藏交流系统看着业务简单但把认证、上传、分页、事务、并发、部署这些基础点一个个抠透才算是真的把Spring Boot用明白了。特别是数据库字段设计和事务边界这两件事一开始设计错了后面改起来极其痛苦。如果你也正在做类似的项目建议别急着追求花哨的功能先把这些底层环节夯实后面加需求时才能从容应对。
1. 项目概述与需求拆解1.1 钱币收藏圈的真实痛点钱币收藏这个小众圈子看着不大但信息分散的问题比大多数行业都严重。玩钱币的人都知道找一枚特定版别的钱币有多难——袁大头九年精发版、船洋二十三年、一版人民币的暗记区别这些信息散落在各个微信群、贴吧、论坛里没有一个集中的地方能把“藏品展示、行情交流、交换撮合”串起来。有人手里囤着重复的评级币想出手有人满世界找不到一枚品相合适的收藏币中间的桥梁却只有零散聊天记录。我做这个“基于Spring Boot的钱币收藏交流系统”初衷就是解决这个结构性痛点。它不是一个简单的展示网站而是一个把收藏圈子里的真实业务流程搬到线上的平台藏友注册后维护自己的藏品库上传钱币图片和版别信息需要出手或交换时把藏品挂上交易状态其他用户可以浏览藏品、发起咨询、走交易流程社区板块则承载鉴定求助、行情讨论这些日常交流。整套系统做完相当于把一个线下收藏圈子的核心运转逻辑完整数字化了。1.2 系统能做什么适合谁从功能边界来看这个系统落地的核心模块有四个用户认证与权限控制、藏品管理与图片上传、交易交换流程、社区互动与检索。听起来都是常见功能但缝合在一起恰好覆盖了Spring Boot开发中最典型的几类业务场景——JWT无状态认证、MyBatis-Plus分页与条件查询、事务与并发控制、全局异常处理、文件存储映射、Docker部署。所以说这个项目的受益人群非常明确如果你正打算用Spring Boot做一个完整的前后端分离项目练手或者毕设选题围绕社区、交易、垂直领域平台这套系统的拆解思路可以直接复用。技术难度控制在中等偏上既不会像纯CRUD那样学不到东西也不会碰微服务、高并发那些对新手不友好的深水区。把这套系统从头到尾写明白Spring Boot日常开发里最常用的那些技术点基本就都过了一遍。2. 技术选型与架构设计2.1 为什么选Spring Boot自动装配到底省了什么现在做Java后端选Spring Boot基本没什么悬念但很多人说不清楚它到底好在哪。拿最核心的自动装配机制来说Spring Boot启动时会读取META-INF/spring.factories里声明的自动配置类再由ConditionalOnClass、ConditionalOnMissingBean这些条件注解决定哪些配置生效。你引入spring-boot-starter-data-redis之后只要 classpath 里有Redis相关类RedisTemplate就会自动装配好直接注入就能用。这就是自动装配的价值把过去SSH时代几百行XML配置才能解决的事情变成了“引入依赖即获得能力”。不夸张地说一个Spring Boot项目的初始配置代码量只有传统Spring项目的十分之一。而且排查问题也有方向——遇到“我没配置为什么也能用”大概率是某个自动配置类生效了遇到“我配置了却不生效”首先检查是不是被ConditionalOnMissingBean挡住了。2.2 前后端分离与完整技术栈这个项目采用前后端分离架构前端Vue 3 Element Plus后端Spring Boot。版本上我选的是2.7.18而不是Spring Boot 3。原因很实在Spring Boot 3基于Jakarta EE把javax.*包换成了jakarta.*很多第三方依赖和旧教程里的代码都会踩兼容性坑。2.7.18是2.x系列的最终维护版本生态成熟、踩坑资料全做业务系统求稳它是最合适的选择。后端依赖选型这块我把核心组件和理由整理成了表格组件选型选型理由ORMMyBatis-Plus 3.5.x单表CRUD零SQL自带分页插件和防SQL注入能力数据库MySQL 8.0生态成熟事务和索引能力满足业务需求缓存Redis 5.x验证码、热门榜单、登录token黑名单认证JWT Spring拦截器无状态方案天然适配前后端分离文件存储MinIO / 本地磁盘藏品图片按部署环境选择接口文档Knife4j基于OpenAPI 3调试接口效率高选择MyBatis-Plus而不是纯MyBatis核心原因就一个字快。Java业务系统里大概七成的数据库操作是单表CRUD用BaseMapper接口一行SQL都不用写。需要复杂查询时再在Mapper接口里写Select注解自定义SQL两边兼顾。这个项目里藏品列表的“条件筛选分页”、社区帖子的“板块热度和时间排序”都是MyBatis-Plus的舒适区。3. 数据库设计与核心表结构3.1 从业务流程中抽象实体建表的逻辑应该从用户的使用流程里倒推而不是拍脑袋定几个表就开工。钱币收藏交流系统的核心流程是这样的用户注册登录后创建藏品记录每条藏品可以设置为“展示中”或“可交易”其他用户浏览藏品后发起咨询或交换请求双方达成一致后生成交易记录同时用户在社区板块发帖、评论形成交流闭环。顺着这条链路抽实体至少有六张核心表t_user用户、t_coin藏品、t_coin_image藏品图片、t_trade交易记录、t_post帖子、t_comment评论。这里有一个容易被新手忽略的设计点藏品和交易必须分离。用户先构建自己的藏品库发布交换意向只是在藏品上挂一个状态而不是生成一条交易记录。这样每枚钱币的历史交易轨迹都可以保留下来方便藏友参考行情。3.2 关键表字段与索引设计t_coin藏品表是最核心的业务表字段设计直接影响后续功能的复杂度字段类型说明idBIGINT主键user_idBIGINT所属用户titleVARCHAR(64)藏品名称dynastyVARCHAR(32)年代/版别gradeTINYINT品相分级descriptionTEXT藏品描述priceDECIMAL(10,2)心理价位trade_statusTINYINT0-仅展示 1-可交易 2-交易锁定statusTINYINT0-草稿 1-上架create_timeDATETIME创建时间品相分级这里特别说一下。钱币圈有自己的品相体系未流通、近未流通、极美、美品、上品每一档对应不同的市场溢价。这不是“好中差”几个选项能表达的所以我把它设计成独立字典表用grade字段存字典ID后面要扩展细分品相改字典数据就行不需要改表结构。索引设计上user_id必须加索引因为“我的藏品”“我的交易”全按用户维度查create_time建议和user_id组合成联合索引(user_id, create_time)这样用户查看自己的藏品列表按时间倒序时走索引扫描不需要额外排序。数据量在十万级以内这套设计完全够用。4. 核心功能模块实现4.1 用户认证与权限控制认证方案用的JWT无状态模式。用户登录校验通过后后端签发一个有效期24小时的token前端存在localStorage里每次请求在Header带上Authorization: Bearer xxx。后端用拦截器统一校验token解析出用户ID后放入ThreadLocal业务代码里直接调用CurrentUser.get()就能拿到当前登录用户省去了在接口方法里反复传user_id的麻烦。JWT有个绕不开的缺点token在过期前无法服务端主动失效。所以注销功能不能只在前端删token后端必须维护一个“已注销token黑名单”。我的做法是注销时把token的jti唯一标识写入Redis设置过期时间为token剩余有效期拦截器里先查黑名单再校验签名。这样才算真正实现了“注销立即生效”。权限控制方面普通用户和管理员的接口权限不同。我在Spring Boot拦截器中通过HandlerMethod.getMethodAnnotation(RequireRole.class)做鉴权接口上加注解声明所需角色比在代码里写一堆if (user.getRole() ! ADMIN)干净得多。4.2 藏品发布与多图上传藏品发布页面承载的信息量不小基本属性、品相、年代、描述、心理价位外加最多九张钱币图片。图片上传这块我推荐本地磁盘存储起步而不是一上来就上MinIO或OSS。原因有两个一是本地部署简单不增加额外的服务依赖二是迁移成本完全可控后面需要上MinIO只需要替换存储实现的底层接口Controller层代码不用动。但本地存储有一个必须处理的坑文件大小限制。Spring Boot默认上传大小上限是1MB钱币高清图经常超限。在application.yml里显式调大spring: servlet: multipart: max-file-size: 10MB max-request-size: 50MB超过限制后默认的错误响应信息对前端非常不友好。我习惯在全局异常处理器里单独捕获MaxUploadSizeExceededException返回统一格式的业务错误。另外图片上传不能只存原图。用户在藏品列表页需要缩略图详情页需要大图如果直接渲染原图列表页加载速度会很慢。我用Thumbnailator在上传后立即生成缩略图一行代码就能搞定效果立竿见影。4.3 交易流程与并发一致性交易是这个系统里业务状态最复杂的模块。我定义的状态流转是待确认 → 交易中 → 已完成 / 已取消。每一步状态变更都记录操作日志避免后续纠纷说不清楚。这里要有意识地避免一个新手常犯的错误在同一个Service类里一个事务方法直接调用另一个事务方法。为什么这是坑Spring事务是通过AOP代理实现的自调用不会经过代理对象注解上的Transactional直接失效。结果就是“更新藏品状态”和“生成交易记录”两个操作不在同一个事务里要么状态改了记录没生成要么记录插了状态没变。正确做法是把事务边界内的方法放在独立的Bean中或者用一个事务方法统一编排所有操作。并发场景同样要处理。两个用户同时看中一枚藏品并发起交易如果不加控制两个请求都能读到trade_status1的可交易状态双双进入交易流程。最朴素的解决办法是条件更新做乐观锁boolean locked coinService.lambdaUpdate() .eq(Coin::getId, coinId) .eq(Coin::getTradeStatus, 1) // 只有当前状态为“可交易”才能修改 .set(Coin::getTradeStatus, 2) // 修改为“交易锁定” .update(); if (!locked) { throw new BusinessException(该藏品已被其他用户锁定请刷新后查看); }这个eq条件就是最底层的并发防线。数据库层面规避了超卖式的竞争冲突业务逻辑层不用再加分布式锁简单可靠。4.4 社区互动与检索实现社区板块做了轻量化的论坛设计发帖、评论、点赞不搞好友关系链。帖子按板块划分比如“鉴定求助”“行情讨论”“晒币分享”每个板块独立列表。帖子列表的分页直接用MyBatis-Plus的分页插件配置一个拦截器即可Configuration public class MybatisPlusConfig { Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }检索方面项目初期用LIKE %keyword%就能覆盖需求数据量在百万以下性能问题不大。如果后续收藏圈子需要支持专业术语的分词检索比如“袁大头九年精发版”“船洋二十三年”这种多关键词组合搜索再考虑接Elasticsearch。现阶段刻意过度设计反而会增加复杂度和维护负担。5. 关键难点与安全防护5.1 文件存储路径与访问映射用本地磁盘存图片有个很隐蔽的坑如果开发环境把图片存到项目运行目录的相对路径下用JAR包部署时工作目录指向一个临时路径服务重启后所有历史图片全部丢失。正确做法是配置一个独立的绝对路径作为上传目录不依赖项目运行位置。在application.yml里定义变量file: upload-dir: /data/coin-platform/images然后通过WebMvcConfigurer做静态资源映射Value(${file.upload-dir}) private String uploadDir; Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/images/**) .addResourceHandler(file: uploadDir /); }这样前端访问/images/coin/xxx.jpg就能直接拿到图片后端不需要再单独写一个图片下载接口。核心思路是路径配置要外部化资源映射要显式化千万不要把上传目录和项目源码目录混在一起。5.2 XSS与上传文件安全UGC内容多的系统XSS攻击是躲不开的威胁。用户发帖、留言的内容如果直接存库再原样渲染一个恶意script标签就能偷走访问者的token。在Spring Boot里加一个全局过滤器统一对请求参数做HTML转义是最基础的防护手段。但要注意不能一刀切藏品描述里的合法标点符号、换行符都得保留。我的做法是双保险入参时对普通文本字段做StringEscapeUtils.escapeHtml4转义富文本白名单清洗交给前端配合。对于文件上传更要小心文件名里夹带的攻击payload存储时一律重命名为UUID彻底杜绝路径穿越和恶意文件覆盖的风险。5.3 限流与验证码策略登录接口和发送验证码接口必须做限流。很多项目就是在这里被脚本刷爆验证码通道被滥用用户收不到短信系统口碑直接崩掉。实现方式不复杂用Redis做计数器同一IP每分钟最多请求5次String key sms:limit: ip; long count redisTemplate.opsForValue().increment(key); if (count 1) { redisTemplate.expire(key, 1, TimeUnit.MINUTES); } if (count 5) { throw new BusinessException(请求过于频繁请稍后再试); }注意Redis的increment配合expire这个组合用法首次计数时设置过期时间后续计数自动累加。这个模式在限流场景非常实用。验证码本身也要设置过期时间校验通过后立即删除防止同一验证码被暴力重放。6. 常见问题与排查实录6.1 Spring Boot版本与依赖冲突项目初期被第三方组件的传递依赖坑过一次。某个组件内部引用了旧版spring-web和Spring Boot的依赖管理机制冲突上线后出现诡异的NoSuchMethodError。排查思路是打印依赖树定位冲突mvn dependency:tree -Dverbose -Dincludesorg.springframework:spring-web看到两个版本共存后在引入该组件时用exclusion排除旧版本问题解决。给后来者的建议是核心框架依赖版本一定要显式声明别指望传递依赖的“巧合”凑出正确组合。6.2 MyBatis-Plus分页插件失效分页失效的高频原因有两个第一分页插件拦截器没配进Spring容器第二调用分页方法时Page对象没作为第一个参数传递。还有一种容易被忽略的情况——多个InnerInterceptor共存时顺序不当。比如先配置了乐观锁插件再配置分页插件某些场景下分页会静默失效。排查这类问题的固定步骤是确认容器里注册了MybatisPlusInterceptorBean确认分页参数传对了排除多拦截器冲突。配好之后在单元测试里验证分页结果总条数和当前页数据能省去后面大量联调时间。6.3 跨域问题与联调陷阱前后端分离开发时跨域配置几乎是必踩的坑。Vue的devServer可以配proxy解决开发环境跨域但生产环境前后端分别部署在不同域名下后端必须配置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); } }一个典型症状接口在Postman里调通放到浏览器里就报跨域错误。原因通常有两个——前端请求带了Authorization头但后端的allowedHeaders没包含它或者OPTIONS预检请求被拦截。把allowedMethods显式加上OPTIONSallowedHeaders设为*能解决大部分跨域问题。6.4 打包部署与运行期故障Maven打包最容易犯的错是用scopesystem/scope引入外部JAR打包后JAR包里不包含这个依赖运行直接报ClassNotFoundException。正确做法是把外部JAR安装到本地Maven仓库或者用maven-assembly-plugin特殊处理。另外命令线上环境排查问题时没有源代码的环境看日志经常一头雾水我习惯保留原码对应的可追溯构建记录Git标签和构建参数严格对应这样日志里的代码行号就能直接映射到可读源码不需要借助反编译工具去逆向猜测业务逻辑。7. 上线部署与经验沉淀7.1 一套docker-compose编排搞定前后端前后端一起部署用Docker Compose编排是最省心的方式。项目包含前端、后端、MySQL、Redis、MinIO五个部分我写了一个compose文件统一管理version: 3.8 services: mysql: image: mysql:8.0 environment: MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD} MYSQL_DATABASE: coin_platform ports: - 3306:3306 volumes: - mysql_data:/var/lib/mysql - ./sql/init.sql:/docker-entrypoint-initdb.d/init.sql backend: build: ./backend ports: - 8080:8080 environment: SPRING_PROFILES_ACTIVE: prod DB_HOST: mysql REDIS_HOST: redis depends_on: - mysql - redis nginx: image: nginx:1.24 ports: - 80:80 volumes: - ./frontend/dist:/usr/share/nginx/html - ./nginx.conf:/etc/nginx/conf.d/default.conf - /data/coin-platform/images:/data/coin-platform/images volumes: mysql_data:这里有一个必须强调的点MySQL数据必须挂载到命名卷或宿主机目录否则一次docker-compose down就能让所有注册用户、所有藏品数据灰飞烟灭。这个配置里我把MySQL数据挂到了命名卷mysql_dataCompose删除容器不会删除卷。文件上传目录也单独挂载和容器生命周期解耦。数据库密码、Redis密码、MinIO密钥这些敏感配置一律通过环境变量传入不写死在compose文件里。部署时配一份.env文件如果文件被误提交到代码仓库立刻用docker-compose config检查一下有没有敏感信息泄露。7.2 线上性能问题与调优实践上线后的真实流量能暴露开发阶段完全看不到的问题。我这边实测发现一个慢SQL藏品列表按用户和时间排序的查询走了全表扫描数据量一上来响应就慢。优化方式是在t_coin表加联合索引(user_id, create_time)再给热门板块的帖子列表加Redis缓存接口响应时间从800ms降到了120ms效果很明显。性能优化有一条铁律先定位再优化不要凭感觉加缓存。我的排查流程是打开慢查询日志找到耗时Top N的SQL用EXPLAIN看执行计划确认是否走了索引再针对性加索引或调整查询逻辑。线上问题定位的另一个细节接口的异常日志一定要打印完整上下文包括请求参数、请求路径、用户ID、异常堆栈。日志信息不全的话排查问题就是在盲人摸象。这几轮跑下来我的体会是钱币收藏交流系统看着业务简单但把认证、上传、分页、事务、并发、部署这些基础点一个个抠透才算是真的把Spring Boot用明白了。特别是数据库字段设计和事务边界这两件事一开始设计错了后面改起来极其痛苦。如果你也正在做类似的项目建议别急着追求花哨的功能先把这些底层环节夯实后面加需求时才能从容应对。
