1. 项目缘起与整体设计思路做文学类网站这件事我从接需求到最终上线前后完整走过两遍。第一遍是帮朋友的小型文学社团搭站第二遍是给一个原创写手平台做重构。两次踩的坑不一样但核心逻辑是相通的文学网看起来只是“文章列表详情页”真做起来内容模型、检索、权限、部署这几块一个都绕不开。这篇就把我从需求梳理到服务器部署的全过程拆开讲尽量把每个决策背后的理由说清楚让你能直接抄作业。先说清楚这个项目是什么。基于WEB的文学网本质是一个以长文本内容为核心的发布与阅读平台核心功能包括作品发布、章节管理、分类检索、评论互动、用户书架以及后台的内容审核与运营。它解决的问题是让写作者有一个稳定的地方连载作品让读者能高效地找到并持续追更。适合谁来参考我认为有三类人最有用一是正在做课程设计或毕业设计的同学需要一个结构完整、能讲清楚设计模式的WEB项目二是想练手全栈开发、但不知道做什么题材的开发者三是小型文学社团或工作室想低成本搭一个自己的内容站。为什么选文学网这个题材因为它对内容模型的要求比普通博客高一个档次。普通博客一篇文章就是一个独立单元而文学作品是“作品—卷—章节”的树形结构还涉及连载状态、字数统计、更新提醒。这个结构一旦设计好你对关系型数据库的理解会上一个台阶。另外文学网天然需要全文检索和分页优化这两块是很多教程里一笔带过、但实际项目里最容易出问题的地方。整体技术选型上我走的是前后端分离路线。后端用 Spring Boot 提供 REST 接口前端用 Vue 做单页应用数据库 MySQL检索用 Elasticsearch缓存用 Redis最后用 Nginx 做静态资源托管和反向代理。这套组合不是唯一解但对文学网这种“读多写少、检索频繁”的场景非常合适。读多写少意味着缓存收益极高检索频繁意味着需要专门的搜索引擎而不是数据库 LIKE 查询。下面我会逐层拆开讲。提示如果你只是做课程设计Elasticsearch 和 Redis 可以先不上用 MySQL 全文索引和本地缓存顶替把核心链路跑通再逐步加。不要一上来就堆中间件否则调试成本会压垮你。2. 需求拆解与核心功能设计2.1 从用户角色反推功能清单做需求最忌讳拍脑袋列功能。我的做法是先定角色再从角色反推功能。文学网的角色其实就三类读者、作者、管理员。读者要的是“找书、看书、追书”作者要的是“写书、管章节、看数据”管理员要的是“审内容、管用户、看运营”。按这个思路拆下来功能清单就清晰了角色核心功能优先级读者作品检索、章节阅读、加入书架、评论、阅读历史高作者创建作品、发布/编辑章节、草稿箱、数据统计高管理员内容审核、用户管理、分类维护、敏感词管理中这里有个经验阅读历史和书架要分开设计。书架是用户主动收藏阅读历史是系统自动记录。很多人图省事合成一张表结果用户取消收藏后历史也没了体验很差。我第一版就犯过这个错后来拆成bookshelf和read_history两张表才理顺。2.2 内容模型的树形结构设计文学网的数据模型核心是“作品—卷—章节”三级结构。但实际设计时我建议把“卷”做成可选层级因为很多短篇作品根本不需要分卷。所以表结构上章节表用一个parent_id自关联或者干脆用volume_id可空字段来兼容两种情况。作品表的关键字段我列一下id、title、author_id、category_id、cover_url、intro、status连载/完结、word_count、chapter_count、created_at、updated_at。其中word_count和chapter_count是冗余字段每次发布章节时更新而不是实时统计。为什么因为列表页要显示字数如果每次都去 count 章节表列表页会慢得离谱。这是典型的空间换时间。章节表的关键字段id、work_id、volume_id、title、content、word_count、sort_order、status草稿/已发布、created_at。这里sort_order用整数递增方便拖拽排序。注意content字段用LONGTEXT因为单章可能上万字。2.3 检索需求与方案取舍文学网的检索需求比想象中复杂。读者可能按标题搜、按作者搜、按分类筛、按状态筛还要支持“最近更新”“字数最多”“收藏最多”等排序。如果只用 MySQL 的LIKE %关键词%数据量一上来就全表扫描几万条数据就能让查询超过一秒。我的方案是分两层列表页的筛选走 MySQL 索引全文检索走 Elasticsearch。具体来说分类、状态、排序这些结构化条件在 MySQL 上建联合索引就能扛住而标题、简介、正文的关键词搜索同步到 ES 里做分词检索。同步方式用双写定时补偿发布章节时同时写 MySQL 和 ES每天凌晨跑一次全量校对防止数据不一致。注意ES 的分词器对中文要特别配置。默认的 standard 分词器会把中文按单字切搜“文学”会匹配到所有含“文”或“学”的内容噪音极大。一定要装 IK 分词器并在 mapping 里指定analyzer: ik_smart。3. 技术栈选型与关键实现细节3.1 后端框架与分层结构后端我选 Spring Boot理由很实在生态成熟、文档多、招人好招。分层上严格走 Controller—Service—Mapper 三层别把业务逻辑写在 Controller 里。我见过太多课程设计把 SQL 直接拼在 Controller后期改一个字段要翻遍所有文件。包结构我习惯这样分controller、service、service.impl、mapper、entity、dto、vo、config、common。其中dto是接收前端参数vo是返回给前端的数据entity对应数据库表。为什么要分这么细因为直接返回 entity 会把密码、内部状态这些字段暴露出去而且一旦表结构变了前端也跟着崩。用 vo 做一层转换接口就稳定了。这里体现一个设计模式的实践转换层用建造者模式或工厂模式来组装 vo。比如WorkVO需要作品基本信息加作者昵称加分类名这些来自三张表。我在 Service 里用一个WorkVOConverter统一组装而不是在每个接口里重复写。这样以后加字段只改一处。3.2 数据库索引与分页优化分页是文学网最容易翻车的地方。用LIMIT offset, size做深分页当 offset 到几万时MySQL 要扫描并丢弃前面所有行慢到无法接受。我的做法是游标分页用上一页最后一条的id或updated_at作为游标查询WHERE id last_id ORDER BY id DESC LIMIT size。这样每次都是索引定位速度恒定。索引设计上作品列表页的常用查询是“按分类按状态按更新时间排序”所以我建了联合索引idx_category_status_updated (category_id, status, updated_at)。注意联合索引的字段顺序很关键要把等值查询的字段放前面范围排序的放后面。如果写成(updated_at, category_id)那分类筛选就用不上索引了。章节表的索引是idx_work_sort (work_id, sort_order)保证按作品查章节列表时有序返回不用额外排序。另外content字段不要建索引大文本建索引又慢又占空间。3.3 缓存策略与一致性处理Redis 在文学网里的作用主要是缓存热点作品和章节。我缓存三类数据作品详情、章节内容、分类列表。缓存 key 设计成work:detail:{id}、chapter:content:{id}、category:all过期时间分别设 30 分钟、2 小时、24 小时。为什么章节内容缓存时间最长因为章节一旦发布基本不改改动频率极低。而作品详情因为字数、收藏数会变缓存短一点。分类列表几乎不变可以缓存一整天。一致性上我用先更新数据库再删除缓存的策略。为什么不更新缓存因为并发更新时容易产生脏数据删除缓存让下次读取时重建更稳妥。极端情况下仍有短暂不一致但对文学网这种场景完全可以接受——读者晚几秒看到最新字数没有任何影响。提示缓存穿透要防。如果有人恶意请求不存在的作品 id每次都会打到数据库。我的做法是缓存空值key 为work:detail:{id}value 存一个特殊标记过期时间设短一点比如 5 分钟。4. 前端实现与跨浏览器适配4.1 页面结构与组件拆分前端用 Vue 3 加 Vite 构建。文学网的页面不算多首页、分类页、作品详情页、阅读页、书架页、作者后台、管理后台。但阅读页是重点它要处理长文本渲染、章节切换、字体调节、阅读进度记忆。组件拆分上我把阅读页拆成ChapterContent、ChapterNav、FontSetting、ProgressBar四个子组件。ChapterContent只负责渲染正文用v-html但要先做 XSS 过滤。这里有个坑作者可能粘贴带样式的富文本直接渲染会破坏页面布局。我的做法是后端存储时用白名单过滤标签只保留p、br、strong、em这些基础标签。阅读进度记忆用localStorage存{workId, chapterId, scrollTop}下次进入自动定位。这个功能看着小但读者体验提升巨大尤其是追更长篇的读者。4.2 跨浏览器兼容的实战处理跨浏览器支持是文学网必须考虑的因为读者用什么设备的都有。我实测下来主要问题集中在这几块一是scrollTop在 Safari 和 Chrome 上的取值差异二是localStorage在隐私模式下的异常三是字体渲染在不同系统上的行高差异。scrollTop的问题Safari 用document.body.scrollTopChrome 用document.documentElement.scrollTop。我的处理是封装一个getScrollTop()函数两个都取取到非零的那个。localStorage在 Safari 隐私模式下写入会抛异常所以所有读写都要包try-catch失败时降级到内存变量。字体行高差异更隐蔽。Windows 和 macOS 对中文字体的默认行高计算不同同一段 CSS 在两边显示的行距能差 20%。我的做法是显式设置line-height: 1.8并指定字体栈PingFang SC, Microsoft YaHei, sans-serif把渲染差异压到最小。4.3 阅读体验的细节打磨阅读页的字体大小调节我用 CSS 变量实现根元素设--font-size: 18px正文用font-size: var(--font-size)调节时只改这个变量。这样不用重新渲染组件性能好。背景色也做成可切换提供护眼黄、夜间黑、纯白三种同样用 CSS 变量控制。翻页交互上我支持键盘左右方向键和点击左右区域两种方式。移动端加左右滑动手势。这些交互看着简单但要处理好边界第一章不能再往前最后一章要提示“已是最新章节”。我见过不少站翻到最后一章直接白屏体验很差。5. 部署上线与运维实战5.1 服务器环境准备部署我走的是单机 Docker Compose 方案适合中小规模。服务器选 2 核 4G 起步文学网这种读多写少的场景这个配置能扛住日均几万 PV。系统用 Ubuntu 22.04先装 Docker 和 Docker Compose然后所有服务都用容器跑。容器编排上我定义了五个服务mysql、redis、elasticsearch、backend、nginx。MySQL 数据目录挂载到宿主机防止容器重建丢数据。ES 比较吃内存我给它设了ES_JAVA_OPTS-Xms512m -Xmx512m2 核 4G 的机器上够用。注意ES 默认会占用大量内存如果不限制 JVM 堆大小很容易把服务器内存吃满导致其他服务被 OOM 杀掉。这个坑我踩过半夜服务器直接失联。5.2 Nginx 配置与反向代理Nginx 在这里干三件事托管前端静态文件、反向代理后端接口、做 gzip 压缩。前端打包后的dist目录直接挂到 Nginx 的root接口请求用location /api/转发到后端容器。gzip 压缩对文学网特别重要因为章节内容是大段文本压缩后体积能减少 70% 以上。我开启gzip_types text/plain text/css application/json application/javascript并设置gzip_min_length 1k小文件不压缩避免浪费 CPU。缓存策略上前端静态资源带 hash 文件名设Cache-Control: max-age31536000一年不过期。HTML 文件设no-cache保证每次拿到最新版本。这样用户首次加载后后续访问几乎秒开。5.3 数据备份与监控备份是上线后最容易忽视的。我的方案是每天凌晨 3 点用mysqldump全量备份压缩后保留最近 30 天。备份文件同时传一份到对象存储防止服务器本身故障。ES 的数据可以从 MySQL 重建所以不用单独备份但 mapping 配置要存到代码仓库里。监控上我用一个轻量的方案后端暴露/actuator/health接口写一个定时脚本每 5 分钟请求一次失败就发邮件告警。日志用logback按天切割保留 15 天。这些配置不复杂但能让你在出问题时第一时间知道而不是等用户投诉。6. 常见问题与排查技巧实录6.1 接口响应慢的排查路径接口慢是最常见的问题。我的排查顺序是先看日志里的 SQL 耗时再看缓存命中率最后看 ES 查询。有一次作品列表页要 3 秒才返回日志显示 SQL 只花了 50ms问题出在序列化上——返回的 vo 里嵌套了作者的全部信息包括头像 base64数据量巨大。后来把头像改成 URL 就解决了。所以排查慢接口别只盯着数据库。序列化、网络传输、前端渲染都可能是瓶颈。我习惯用浏览器开发者工具的 Network 面板看各阶段耗时能快速定位是服务端慢还是客户端慢。6.2 缓存与数据库不一致的处理前面说了用“先更新库再删缓存”但仍有边界情况。比如删缓存失败或者并发下旧值被重新写入。我的兜底方案是给缓存设一个较短的过期时间即使不一致也会自动恢复。另外对于特别重要的数据比如章节内容我干脆不缓存写操作只在读时缓存从源头减少不一致。如果发现用户看到旧数据先查缓存 key 是否存在再对比数据库值。我写了一个简单的对账脚本遍历热点 key 和数据库比对发现不一致就删缓存。这个脚本每周跑一次基本能兜住所有问题。6.3 部署后 502 错误的速查502 一般是 Nginx 连不上后端。排查顺序先docker ps看后端容器是否在运行再看后端日志有没有启动报错最后检查 Nginx 配置里的proxy_pass地址对不对。我遇到过一次是后端启动时连不上 MySQL 直接退出容器反复重启Nginx 就一直 502。后来给后端加了启动重试和健康检查才稳定。下面这张表是我整理的常见问题速查可以直接收藏现象可能原因排查动作接口 502后端未启动或崩溃查容器状态和后端日志列表页慢深分页或索引缺失看 SQL 执行计划搜索无结果ES 未同步或分词问题查 ES 索引和分词效果缓存不生效key 拼错或未删缓存查 Redis key 是否存在阅读页错位富文本标签未过滤检查内容过滤白名单6.4 我踩过的几个真实坑第一个坑是章节排序。我一开始用created_at排序结果作者修改旧章节后时间变了章节顺序全乱。后来改用独立的sort_order字段作者可手动调整才彻底解决。第二个坑是字数统计。中文和英文的字数计算方式不同我一开始用content.length()把标点和空格都算进去了。后来改成统计中文字符数加英文单词数才符合作者预期。第三个坑是并发发布。两个请求同时发布同一作品的章节chapter_count会少加一次。后来用数据库行锁SELECT ... FOR UPDATE锁住作品行再更新问题消失。这类并发问题在课程设计里常被忽略但实际项目必须处理。7. 后续可扩展的方向这套系统跑通后扩展空间其实很大。我目前在做的一个方向是阅读偏好推荐根据用户的阅读历史和书架用简单的协同过滤推荐相似作品。不需要上复杂的机器学习用物品相似度矩阵就能做出不错的效果。另一个方向是作者数据看板把章节的阅读量、收藏转化率、读者留存做成图表。这块对吸引作者很关键作者能看到数据才有动力持续更新。技术上用 ECharts 加定时聚合任务就能实现。还有一个实用的扩展是离线阅读用 Service Worker 缓存已读章节读者在地铁没信号时也能看。这个功能实现不难但对移动端读者体验提升明显。我试过在阅读页注册 Service Worker缓存最近 20 章实测下来很稳。最后分享一个小技巧文学网的 SEO 很重要因为很多读者是通过搜索引擎找书。作品详情页和章节页要做服务端渲染或预渲染把标题、简介、正文首段输出到 HTML 里搜索引擎才能收录。纯前端渲染的 SPA 在这块天然吃亏可以用预渲染插件在构建时生成静态 HTML兼顾开发效率和 SEO 效果。
