企业官网建设流程全解析

做同人创作与分享平台，最早是圈子里几个朋友抱怨没地方安心写长篇连载：大平台限流、审核慢、找不到同好，大家就想弄个自己的小站。我后来认真评估了一圈现成方案，决定还是基于 Spring Boot 从零搭一套，前后折腾了差不多两个月，把用户、作品发布、搜索、评论互动、通知、定时任务这些模块全跑通之后，发现这类垂直内容社区和普通管理系统差别挺大，很多细节必须设计到位才能用起来顺。这篇文章就把整套系统的设计思路和实现要点分享出来，偏后端工程项目，用到的东西也都是社区里常见的组合，适合正在做创作分享类站点、或者准备用 Spring Boot 搭建内容社区的同学当参考。

1. 先想明白：同人创作与分享平台到底在解决什么

1.1 同人圈子的真实痛点

同人创作圈子有它的特殊性。内容形态以文为主，但也不缺图包、短漫、视频剪辑和音频；更新方式往往是长篇连载，一章一章地发，追更用户天天来看；读者对"圈层"极其敏感，一个作品属于哪个原作、哪对 CP、什么分级，都必须标得清清楚楚，否则就失去社区意义。

这些表面需求看起来只是普通的 CRUD，但仔细拆下来会发现很要命：长篇连载意味着作品和章节是两级结构，还可能存在修文、锁文、坑文状态；圈层标签要求搜索和推荐都具备"组合过滤"能力；创作者有极强的表达欲和更新焦虑，需要一个能承载"草稿—审核—发布—连载管理"的链路；读者互动则是多对多的关系，点赞、收藏、评论、打赏都是高频动作。

所以我在设计前先给自己定了个基调：这不是一个后台管理系统，而是一个内容生产工具加社区互动系统。Spring Boot 在这类项目上的优势很明显——模块化清晰、生态齐全、团队协作容易，尤其配合 MyBatis-Plus 这类框架做数据访问，能很快把设计落地成代码。

1.2 从同类产品里提炼功能骨架

当时我参考了国内外几个主流同人和创作社区的实际交互逻辑，把它们的功能拆成一张清单，按优先级分了三层：

第一层是内容生产核心。用户注册登录、作品创建、章节编辑、作品审核、定时发布、作品上下架、全文搜索、标签维护，这些不做完平台根本没法用。

第二层是互动关系。评论、回复、点赞、收藏、关注作者、私信通知、阅读记录，这部分决定社区能不能形成黏性，读者追更的动力全在这里。

第三层是运营和增值。热门榜单、推荐位、作品合集、创作者认证、公告通知、数据统计、内容安全审核，上线一段时间后运营一定会要这些能力。

三层功能对应的技术难度是递增的。第一层做好数据建模和基础框架就够了，第二层要处理并发和幂等，第三层往往涉及定时任务、异步消息甚至实时计算。我最终确定的整体架构是 Spring Boot 作为后端服务主干，MySQL 存业务数据，Redis 扛热数据和缓存，Elasticsearch 做内容搜索，ActiveMQ 处理异步通知，前后端分离，前端这部分我用 Vue 搭了一个简化版的控制台。

1.3 MVP 范围划定

做这类项目最忌讳一上来就铺大摊子。我第一版严格限制了范围：用户登录注册、作品和章节的发布编辑、标签系统、基础搜索、评论、点赞收藏、个人主页和排行榜，这就是能拿出来上线的最小闭环。打赏、私信、创作者认证、复杂推荐这些全部砍掉。

裁剪方案是有依据的。同人社区冷启动阶段最重要的是内容供给侧，创作者能发作品、读者能找到内容、双方能互动，这个三角关系先转起来，其他功能都有补做空间。结果证明这个范围控制得很值——后面运营反馈的很多问题都集中在这几条主线上，而前期砍掉的模块完全没有拖累系统。

2. 主干技术栈敲定：Spring Boot 不是万能的，但是合适的

2.1 技术选型对比，为什么没有选 PHP 或 Node

做内容社区， PHP 生态里的 WordPress、Typecho， Node 生态里的 Ghost，其实都有现成方案可以二次开发。我也不是没犹豫过，毕竟现成建站系统部署快、模板多，省去大量开发时间。但深入评估后发现，它们的核心设计思路是"通用博客或 CMS"，涉及自定义业务规则时改动成本极高。比如同人社区的章节独占审核流程、CP 标签体系、复杂互动计数，这些在通用系统里往往要靠大量插件硬凑，凑出来的体验还是不顺手。

Spring Boot 的价值是给了我从业务出发的自由度。模型设计、接口定义、权限体系、任务调度全部由自己掌控，中间件生态随便挑，后面想加推荐算法、流计算统计，都有成熟的整合路径。而且 Java 后端在团队协作、代码规范、长期维护方面有天然优势，做这类垂直系统的长期迭代，稳定性比花哨重要得多。

2.2 中间件选型的取舍

存储和中间件这块我做的是最小够用加组合优化的决策：

MySQL 是绝对主力，用户、作品、章节、评论、标签关系全部落 MySQL。InnoDB 引擎，utf8mb4 字符集，业务表全部包含 created_time、updated_time、deleted 字段，这是后续所有功能的基础。

Redis 承担三块职责：用户登录态和 Token 缓存、点赞收藏的防重与计数、排行榜热数据的预计算。选 Redis 不选本地 Map 的原因显而易见——平台要面对多实例部署，状态必须集中管理。

Elasticsearch 管内容搜索。一开始有人建议我用 MySQL 的 LIKE 查询顶一顶，但同人作品标题和简介的搜索体验对社区留存影响很大，LIKE 查询在数据过万之后延迟明显上升，而且没法做分词。我最终定了 ES 加 HanLP 分词的方案，这个组合后面会专门讲。

ActiveMQ 负责异步解耦。评论之后要发通知、作品发布之后要刷新统计、注册之后要发欢迎信，这些用同步等待的方式既慢又不稳定。Spring Boot 整合 ActiveMQ 非常顺，配置好连接工厂和监听容器就能用，社区资料也多。

部署侧用的是阿里云服务器加宝塔面板，应用容器化用 Docker，这些到第六部分详细说。

2.3 Spring Boot 版本选择：网上说的"版本太高"怎么回事

搜过 springboot 相关话题的人大概率见过"springboot 版本太高"这类抱怨。这里有一个现实背景：Spring Boot 3.x 相比 2.x 是有较大跳跃的，它基于 Jakarta EE 9+，把 javax 命名空间换成 jakarta，很多老项目的代码、依赖、拦截器配置都得跟着改。Spring Boot 2.7 还是 javax 体系，3.2 就是 jakarta 体系，两者的兼容性不是平滑升级，而是断裂式迁移。

我在这个项目里选的是 Spring Boot 2.7.18，理由有两个：一是团队里现有的业务代码和第三方组件大多基于 javax 体系，迁移成本可以省掉；二是 2.7 版本身已经是 2.x 系列的最终维护版本，稳定性和安全补丁都有保障。如果你是从零起步的新项目，可以直接考虑 Spring Boot 3.2 加 JDK 17；但如果是改造老项目，建议先看依赖树里有多少组件需要换命名空间，再做决定。

除了命名空间，版本"太高"还常常指 Spring Security 6。它默认开启 CSRF 防护，前后端分离项目里如果没处理，接口调用会被 403 挡住一整片。我在项目里没有上整套 Spring Security，而是用拦截器加自定义注解的方案做认证，更轻量也更直观，这个方案在第四部分展开。

3. 领域建模：把创作和分享拆成能落地的表

3.1 用户、创作者与关注关系

用户表是系统一切关系的地基。我设计的 user 表核心字段包括 id、username、password_hash、nickname、avatar、signature、status 和注册时间。密码存的是 BCrypt 加密后的哈希，不做加密算法存储，这是基本要求。status 字段管封禁和注销状态，注销采用软删除逻辑，保留内容记录方便后续审计。

创作者的信息扩展我单独建了 creator_profile 表，存创作者简介、背景图、认证等级、作品数量统计。为什么要拆开而不是直接塞在 user 表里？因为大部分读者用户永远不需要这些字段，单表堆字段会导致后续查询性能下降和代码可读性差，拆表是更干净的建模方式。

关注关系表的字段是 id、user_id、follow_user_id、create_time，加了 user_id 和 follow_user_id 的唯一索引。这个索引唯一约束解决的是重复关注问题，不管前端怎么交替点击，数据库层面保证每个关注关系只存在一条记录。

3.2 作品、章节与连载体系

作品表是整个内容系统的核心。字段设计上我特别注意了两点：状态字段和版本号。状态字段 work_status 取值为 0 草稿、1 待审核、2 连载中、3 已完结、4 已下架、5 审核不通过，六个状态覆盖创作者从写稿到最后完结的全流程。版本号 version 是乐观锁字段，更新作品信息时需要比对，防止创作者在多个页面同时编辑导致覆盖。

章节表 chapter 属于作品表的子表，字段包括 id、work_id、chapter_no、title、content、word_count、status、create_time、update_time。chapter_no 是章节号，我按作品维度维护自增，确保一章不多一章不少。content 存的是转换后的 HTML 或者 Markdown 源码，展示层按需渲染。word_count 在插入时根据内容实时计算并缓存，这是列表页展示字数统计的关键字段，不能等接口查询时再现算，否则大数据量下性能会很难看。

连载体系还有个隐藏细节：作品信息表里会冗余一个 latest_chapter_id 和 latest_chapter_time 字段，存最新章节的 ID 和发布时间。这是典型的反范式设计，用一定的数据冗余换列表页的高性能——个人主页和作品列表要展示最新章节信息，如果每次都去 join 章节表，查询复杂度和执行时间都会上去。

3.3 标签系统和 CP 圈层

同人社区里标签不是装饰品，它是圈层的导航系统。我设计了 tag 表和 work_tag 关系表。tag 表字段是 id、tag_name、category、status、create_time，category 区分原作、CP、角色、题材、分级这些不同类型；work_tag 表存作品和标签的多对多关系。

CP 标签的维护必须做归一化处理。用户提交"明昭x段凌"和"明昭段凌"如果当成两个标签，圈子就被割裂了。我在标签服务里做了统一的格式化规则：先对输入的标签名做全角半角转换、空格去除、分隔符统一，再查重，存在则复用，不存在才新建。这一步看着简单，实际运营中价值极大，它保证所有用户看到的是同一个标签宇宙。

3.4 评论、点赞与收藏的互动模型

互动类数据我用"目标模型"思路设计。interaction 表里放 target_type 和 target_id 两个字段，target_type 区分作品、章节、评论，这样一张表就能承接所有点赞和收藏需求，id、user_id、target_type、target_id、interaction_type 五个字段加唯一索引，interaction_type 区分赞还是收藏。

评论表单独设计：comment 表字段包括 id、work_id、chapter_id、parent_id、user_id、content、status、create_time。parent_id 支持楼中楼回复，work_id 和 chapter_id 双维度定位让评论既能挂在整部作品下，也能挂在具体某章下面。这种设计在查询"按章节拉取评论"时很干净，一个 where 条件直接命中索引。

互动模型的性能隐忧在于计数。作品表上冗余点赞数 like_count、评论数 comment_count、收藏数 favorite_count、浏览数 view_count，每次互动操作通过 Redis 做快速计数变更，再由定时任务批量回写 MySQL。这个方案扛住了社区上线初期的流量，而且后面扩展活动、榜单功能时数据源现成。

4. 核心模块实现：认证、发布、搜索三大主线

4.1 不做 Security 全家桶，用拦截器做 JWT 认证

认证方案最终选用 JWT 加 Redis 白名单，实现方式是自定义拦截器加注解，没有引入整套 Spring Security。这个选择很务实：平台的后端接口绝大多数是自研的，用 Spring Security 配置一大堆过滤链和权限规则反而增加理解成本，自研拦截器控制在两百行代码以内，行为完全透明。

具体链路是这样的：用户登录成功后，服务端生成一个 JWT Token，包含 userId 和过期时间戳，签名用 HMAC SHA-256。同时把 Token 的 jti 作为 key 写进 Redis，value 存 userId，过期时间跟 Token 保持一致，这个 Redis 记录就是"白名单"。前端请求时在 Header 里带上 Authorization: Bearer Token，拦截器先验签，再查 Redis 确认 Token 有效，最后把 userId 塞进请求上下文。

为什么验签之后还要查 Redis？如果只验签，那用户注销之后 Token 在过期前依然可用，这在社区类产品里是个安全问题——被拉黑的用户应该立刻失去访问权限。有了 Redis 白名单，注销就是删掉对应的 key，即刻生效。这个方案兼顾了 JWT 无状态的好处和有状态控制的安全性，是目前内容社区项目里性价比很高的组合。

Token 过期处理也有讲究。访问主流程接口时发现 Token 过期，我不会直接让用户重新登录，而是提供一个 refresh_token 接口：前端传一个长期有效的 refreshToken，服务端校验通过后签发新的 accessToken。同人创作者写一章可能要写半小时甚至更久，如果写到一半 Token 过期导致内容提交失败，这种体验几乎等于劝退。

4.2 发布流程状态机：从草稿到上线的完整链路

作品发布绝对不能做成"点击保存就公开"。平台的内容在正式对外展示前必须经历状态流流转，我设计的链路是：草稿、提交审核、待审核、通过上线、连载中、完结、下架、审核驳回。

核心实现是 work 表上的 status 字段加 update_status 接口。创作者的编辑动作全部在草稿或编辑状态进行，只有点下"提交审核"才会把状态从草稿推送到待审核。这里有一个容易被忽略的业务细节：作品提交审核之后仍然可以修改内容，但每次修改都会把校验状态回退到待审核，保证上线内容都是经过审核的最新版本。

定时发布是创作者呼声很高的功能。我在 work 表上加了 publish_time 字段，配合 Spring Boot 的 @Scheduled 定时任务，每分钟扫描一次状态为待定时发布且 publish_time 已到的作品，批量改成连载中。用定时任务而不是写一个常驻的延时队列，虽然不够实时，但对内容发布场景完全够用，而且实现和运维成本基本为零。

状态机的关键约束是要保证状态流转合法。比如审核通过只能从待审核状态进入，完结只能从连载中状态进入。我写了一个状态流转校验工具类，每次更新状态时先查旧状态再校验目标状态是否在合法集合里，状态越界直接抛业务异常。这一步看似简单，但在后台会审人员那里很容易出现把已完结作品又误操作成连载中的事故，做了之后这类问题彻底绝迹。

4.3 搜索模块：HanLP 分词加 Elasticsearch 索引

同人内容搜索有个特点：检索词往往是角色名、CP 名称、题材词汇，而且用户经常输入带空格或特殊符号的复合短语，比如"明昭段凌"或"现代都市 ooc"。直接用 ES 默认的标准分词器，效果很差，会把人名切得支离破碎，检索召回率惨不忍睹。

我的方案是引入 HanLP 分词器做搜索词预处理。用户在搜索框输入关键词后，后端先调用 HanLP 做分词和词性标注，把其中人名、名词性词汇提取出来作为检索词，再拼接成 ES 的查询语句。比如输入"明昭段凌 现代"，HanLP 会把"明昭""段凌""现代"识别成独立词项，然后组合成 bool 查询，命中效果比字符串原样匹配好得多。

ES 索引方面，我在 work 索引里建立的字段包括 title、summary、author_nickname、tag_names，以及一个 status 过滤字段。写索引时把作品标签和作者昵称冗余进去，读接口就能少做很多 join。搜索接口返回的命中文档带高亮片段，用 ES 的 highlight 功能，展示的时候把命中词包上高亮标签，前端渲染出效果，读者能立刻看到自己搜的东西出现在哪里。

HanLP 在 Spring Boot 里的整合并不复杂，引入 hanlp 的 jar 或通过 Maven 依赖即可，主要坑是依赖传递里可能碰到一些版本冲突，需要检查本地依赖树。首次启动时 HanLP 会把词典数据加载到内存，会有几秒的初始化延迟，建议在容器启动阶段预热一次，别等第一个搜索请求进来再卡顿。

5. 社区互动里的工程细节：幂等、异步与定时任务

5.1 点赞和收藏的幂等设计

点赞收藏这类操作的业务特点是高频率、可重复触发、用户手速快。前端按钮如果没做防抖，用户连续点击三次，后端收到的就是三个请求。这三个请求如果都执行"insert 一条点赞记录"，数据就脏了。我在 interaction 表上建了联合唯一索引 user_id、target_type、target_id、interaction_type，重复插入时数据库会抛 DuplicateKeyException，业务层捕获之后直接当成"已经点赞"处理，不做任何额外写入。

高并发下更麻烦的是计数。每次点赞直接 update work 表的 like_count 字段，在峰值流量下会出现行锁竞争，甚至把普通查询拖慢。实测下来我改成了 Redis 计数方案：点赞操作先写 Redis 的 Set 结构记录用户已赞，再对 like_count 的 key 执行 INCR；反赞则从 Set 里移除并 DECR。MySQL 里的 like_count 字段作为持久化基准，由定时任务每隔一段时间把 Redis 的累计变更同步回去。

计数一致性问题在这套方案下要格外小心。我的处理策略是定时任务先做 Redis 与 MySQL 的差值计算，按差值一次性更新数据库，更新之后再把 Redis 计数归零重建。这样即便中途漏了几个写操作，下一次对账也能追回来，不会出现计数差得离谱的运营事故。

5.2 评论通知的 ActiveMQ 异步化改造

评论是社区互动里最能刺激创作者活跃度的功能，但"用户评论之后系统要通知作者"这个动作牵扯很多后续逻辑：生成站内信、推送邮件、更新未读消息数。当初第一版把这些调用全写在评论接口的事务里，结果是评论响应慢了一截，而且通知服务一旦超时，评论接口也跟着报错。

后来我把通知逻辑改成 ActiveMQ 异步消息。评论接口只做评论本身的事务：写评论表、更新作品评论数、返回成功。同时在生产端发一条消息到 comment_notify 队列，消息内容包含评论 ID 和被评论者的用户 ID。消费端监听这个队列，从评论表里查出评论详情，然后生成站内信、更新未读数量、如果有配置再发邮件。

这套改造之后评论接口的 P99 延迟下降很明显。而且 ActiveMQ 自带消息重试机制，消费端如果处理失败会进入重试队列，不会因为一次通知失败丢消息。刚开始踩坑的地方是消息消费要保证幂等性——消息系统可能重复投递，我在消费端做了按消息 ID 去重的逻辑，处理过的消息直接跳过，确保即使 ActiveMQ 重启重发也不产生重复通知。

5.3 定时任务的三大场景：热榜、定时发布、阅读统计

Spring Boot 的 @Scheduled 定时任务在这个项目里承担了三类工作。

热榜计算是最核心的场景。排行榜每周计算一次，计算公式是 score 等于浏览数乘 0.3、点赞数乘 0.5、评论数乘 0.2，再乘上时间衰减系数。定时任务扫描最近 7 天有更新的作品，按热度公式算出分数排序，结果写进 Redis 的 ZSet，前端榜单接口直接读 Redis 返回。为什么不做实时计算？实时计算意味着每次互动都要更新排序结构，不仅开发复杂度高，性价比也低，按小时级别刷一次榜单对社区用户来说已经完全够用。

定时发布在第四部分讲过，每分钟扫描待发布作品。阅读统计则比较特殊：作品浏览数在 Redis 里通过 INCR 累加，每个小时定时任务把增量同步到 MySQL。这个窗口期的数据丢失风险我们通过日志补偿，同步任务启动前会先记录各 key 的值，同步完成后再做一次对账，偏差超过阈值就触发警报。

很多人问 springboot 整合 flink 这类流计算框架是不是必要，我的观点是这个体量的社区项目根本不用上 Flink，定时任务加 Redis 的组合已经覆盖了需求。Flink 适合超大规模实时流计算的场景，比如百万级日活的埋点分析。中小平台硬上 Flink，运维成本和学习成本会远超收益。

5.4 内容安全：作品分级与敏感词过滤

同人创作平台在内容安全上必须有点提前量。平台允许创作者标注作品分级，按全部年龄可见、青少年需谨慎、成人内容仅限特定用户可见三档做权限控制。这个设计不复杂，作品表里一个 rating 字段，查询接口根据登录用户的情况做过滤。

敏感词过滤走的是 DFA 算法加自定义词库。敏感词库集中在词表里，发布接口和评论接口提交时统一走一遍过滤服务，命中词进行替换或打回。这个服务用 Redis 缓存敏感词集合，更新词库后不需要发版，运营直接在后台修改配置即可生效。审核环节我做了两层：机器过滤即时拦截明显的违规内容，人工审核处理细分领域的争议内容，作品提交后进入待审核队列由运营人员决定放行还是驳回。

6. 项目工程化与部署：从单模块到 Docker 上线

6.1 项目结构选型：单模块还是多 modules

Spring Boot 项目结构是被讨论很多的话题，热词里也有 springboot modules、springboot 项目结构。我的经验是：团队小、业务边界模糊的阶段，单模块反而更高效；业务明显划分为多个域、参与人数超过三个，再模块化。

这个项目最终采用了多 modules 结构，划分方式是 domain-based 而不是技术分层：

• boot-admin：启动入口，放全局配置和公共装配
• common-core：通用工具类、统一返回体、异常处理、常量定义
• system-module：用户、权限、认证相关
• content-module：作品、章节、标签、内容审核
• interaction-module：评论、点赞、收藏、通知
• search-module：ES 索引和搜索服务封装

各模块之间的依赖关系有硬性约束：上层的 content 和 interaction 都依赖 common-core，但模块之间禁止互相依赖，需要通过接口调用。比如搜索模块需要读取作品数据，我在 content-module 里暴露一个 Feign 风格的本地接口，搜索模块只依赖这个接口定义，不直接操作作品表。这样做的好处是后续如果要把搜索模块拆成独立服务，改造工作量很小。

6.2 自定义自动配置在项目里到底用在哪

热词里还有 springboot 自定义自动配置，这也是被问得很多的内容。我在这个项目里做了一套统一 Redis 配置组件：自定义 RedisTemplate 的序列化器、连接池参数、key 前缀规则，然后封装成一个 autoconfigure 组件，在 spring.factories 中注册。各业务模块只需要引入这个依赖就自动获得配置好的 RedisTemplate，不需要在每个模块重复写 bean 配置。

自定义自动配置的核心机制是 Spring Boot 的 SPI 机制。早期版本用 spring.factories 里的 EnableAutoConfiguration 注册，Spring Boot 2.7 之后也可以用 AutoConfiguration.imports 文件。实现一个自动配置类的步骤就是：定义一个标注 @Configuration 的类，类里用 @Bean 生成默认组件，通过 @ConditionalOnMissingBean 控制组件不存在时才生效，最后把类注册到工厂文件里。

这类技术点看文档很容易，难的是判断使用时机。我的建议是：同一个中间件客户端在系统里超过三个模块都在使用时，才值得封装自动配置；只有一两个地方用，直接在各模块写配置 bean 反而更直观。过度封装是自找麻烦。

6.3 宝塔 + Docker 的部署落地

部署方案最终用了宝塔面板加 Docker Compose。我在项目根目录维护了一份 docker-compose.yml，编排了 MySQL、Redis、Elasticsearch、ActiveMQ 和业务应用五个容器。业务应用启动前依赖中间件健康检查通过，Compose 里配置了 depends_on 加 condition: service_healthy，避免应用启动时数据库还没就绪导致反复报错。

应用本身的 Dockerfile 是多阶段构建：第一阶段用 Maven 镜像编译打包，第二阶段用精简 JRE 镜像运行。多阶段构建的好处是最终镜像不携带编译工具链，体积能缩小一半以上，启动速度也快。部署时把打包产物传到宝塔的 Docker 管理器里，一键构建启动，日志通过 docker logs 直接看。

踩坑比较多的是阿里云构建路径的问题。国内服务器直接拉公共镜像源和 Maven 中心仓库经常超时，我在 Maven 的 settings.xml 里把镜像源换成阿里云 maven 镜像，Docker 拉镜像时配置了国内镜像加速器。这两个配置没配好之前，构建一次至少重试五六次，配完之后半小时能完成整套部署。这个经历应该也是热词里"springboot 阿里云构建地址"频繁被搜索的原因。

6.4 常遇工程坑：Gradle 插件下载与依赖冲突

热词里还有 springboot gradle 项目搭建、springboot 下载插件、springboot 整合 activemq 这类问题。我也踩过，提几个具体解法。

如果用 Gradle 构建 Spring Boot 项目，首要问题是插件下载慢。Gradle 默认仓库可能连不上外网，我在 settings.gradle 里把 pluginManagement 的 repositories 换成了阿里云提供的 gradle-plugin 仓库，依赖仓库同样加上阿里云 maven 镜像，下载速度立竿见影。

ActiveMQ 整合的坑主要在版本兼容。Spring Boot 2.7 里引入 spring-boot-starter-activemq 之后，默认连接的 broker 是内置的 VM 模式，外部 ActiveMQ 需要配置 broker-url。我在 application.yml 里显式指定了 tcp 地址、用户名密码、和 trustAllPackages 设置，否则从 ActiveMQ 读取 Java 对象消息时会因为序列化白名单问题直接报错。消息体我尽量用 JSON 字符串而不是 Java 对象，规避了反序列化兼容的安全问题，也让消息对运维人员更可读。

另外还要注意跨域配置。前后端分离项目，控制台的接口请求来自另一个端口，Spring Boot 后端必须配置 CORS 过滤器，允许指定域名和 Authorization 请求头。这个不配，前端调用的报错信息会让人误以为接口路径有问题，实际是跨域被拦截了。

做这个项目给我最大的体会是，同人创作与分享平台的技术难点不在某个单独的功能里，而在内容生产、互动关系和数据检索之间的协同设计。Spring Boot 提供了一个足够稳的主干，但作品状态机、搜索分词、互动幂等、异步通知、定时统计这些细节才是真正决定系统好用与否的部分。我最后再给一个实际的建议：第一版上线时务必把日志体系搭好，接口耗时、消息队列积压、定时任务执行情况都打点记录，后面排查线上问题时你会感谢自己当初多写了这几行日志配置。