从零构建文学网全栈项目：需求拆解、技术选型与部署上线实战

1. 为什么“文学网”这个选题比看起来更值得做很多人看到“文学网”三个字第一反应是“这不就是个发文章的后台吗CRUD 而已”。我一开始也这么想直到真正动手把一个文学网从需求梳理做到线上部署才发现这里面藏着不少容易被忽略的坑富文本内容的存储与渲染、章节的层级组织、阅读进度的记录、搜索的模糊匹配、以及部署时静态资源与动态接口的分离。它麻雀虽小但前端、后端、数据库、部署链路一个都不少是练手全栈能力非常合适的载体。这篇内容我打算按真实项目推进的顺序来讲从需求拆解、技术选型、数据库设计到核心功能实现、跨浏览器适配再到最后的部署上线。适合正在找毕业设计选题的同学也适合想完整跑通一个 Web 项目全流程的开发者。我不会只丢一堆代码而是把每个决策背后的“为什么”讲清楚——为什么用这个技术栈、为什么表要这么设计、为什么部署要这么拆。你照着做能跑起来理解了能自己改。需要先说明一点下面涉及的具体代码和配置是基于这类项目最常见的实践补全的原始需求只给了标题和方向所以细节部分我按“一个合格从业者在这个场景下最可能采用的方案”来展开你可以根据自己的实际情况调整。2. 需求拆解文学网到底要解决谁的什么问题2.1 三类角色与他们的核心诉求做任何系统之前先把角色想清楚否则功能会越做越乱。文学网的角色其实很清晰就三类游客/读者不登录也能浏览作品列表、看章节内容、搜索作品。核心诉求是“快速找到想看的读起来顺畅”。作者注册登录后可以创建作品、发布章节、编辑已发布内容、查看自己作品的阅读数据。核心诉求是“写作和发布流程别太繁琐”。管理员管理用户、审核或下架违规作品、维护分类和标签。核心诉求是“能快速定位和处理问题内容”。这三类角色的权限边界必须在设计初期就定死不然后面加权限会非常痛苦。我的做法是用一张角色表加一张用户角色关联表权限判断统一走一个拦截器而不是在每个接口里写 if-else。2.2 功能清单的优先级排序需求最怕一锅端。我习惯用 MoSCoW 方法把功能分成四档先保证 Must have 能跑通优先级功能说明Must用户注册登录基础中的基础没有它一切免谈Must作品与章节的增删改查系统的核心数据流Must作品列表与详情浏览读者侧的主路径Must分类与标签内容组织的骨架Should全文搜索提升找书效率但可后置Should阅读进度记录体验加分项Could评论与点赞社区属性非核心Wont付费阅读、打赏本期不做避免复杂度爆炸把 Wont 明确写出来特别重要。很多项目烂尾就是因为一开始什么都想做结果核心功能都没打磨好。2.3 一个容易被忽略的非功能需求阅读体验文学网和普通管理系统最大的区别在于它的核心场景是“长时间阅读”。这意味着几件事必须提前考虑正文字号要可调、行高要舒适、夜间模式最好有、翻页或滚动要流畅。这些不是锦上添花而是决定用户愿不愿意在你这里读下去的关键。我在第一版就加了字号调节和夜间模式实现成本很低但体验提升非常明显。3. 技术选型为什么是这套组合而不是别的3.1 后端选 Spring Boot 的实在理由后端框架的选择上Spring Boot 几乎是这类项目的默认答案但我想说说它到底好在哪而不是人云亦云。第一它的自动配置让一个 Web 项目几分钟就能跑起来省去了大量 XML 配置第二生态成熟MyBatis、Spring Security、Redis 这些常用组件都有现成的 starter集成成本低第三社区资料多遇到问题基本都能搜到答案。如果你更熟悉 Python用 Flask 或 Django 也完全可行Django 甚至自带 Admin 后台能省掉一部分管理端开发。但考虑到这类项目在课程和毕设场景下的通用性以及后续找工作时 Java 生态的普及度我还是推荐 Spring Boot。3.2 前端为什么不用重型框架也能做很多人一上来就 Vue 或 React但对于一个以内容展示为主的文学网服务端渲染加少量原生 JS 其实更合适。原因有三一是 SEO 友好搜索引擎能直接抓到内容二是首屏加载快读者不用等一大坨 JS 下载完三是开发简单不用处理复杂的状态管理。我的方案是 Thymeleaf 做模板渲染配合原生 JS 处理交互比如字号调节、夜间模式切换、异步加载章节。如果后期要做成单页应用再迁移到 Vue 也不迟。技术选型要服务于当前需求而不是为了用新技术而用。3.3 数据库与缓存的搭配数据库用 MySQL 就够了文学网的数据量和并发量通常不会太大。表设计上要注意字符集用 utf8mb4否则遇到生僻字或 emoji 会出问题。缓存方面如果只是小规模部署可以先用 Spring 自带的缓存抽象等访问量上来了再引入 Redis 缓存热门作品和分类列表。提示字符集一定要在建库时就设成 utf8mb4后期改字符集涉及数据迁移非常麻烦。这个坑我踩过血的教训。4. 数据库设计表结构决定了系统能走多远4.1 核心表清单与字段设计文学网的核心表其实不多但每张表的字段设计都要经得起推敲。下面是我实际用的表结构重点讲几个关键字段的设计意图。用户表user除了常规的 id、username、password、email我额外加了 nickname、avatar、role 三个字段。password 必须存加密后的值用 BCrypt 而不是 MD5因为 MD5 已经被证明不安全。role 字段用来区分读者、作者、管理员虽然也可以用关联表但对于角色种类少的场景单字段更简单。作品表novel核心字段包括 title、author_id、category_id、cover_url、summary、status、create_time、update_time。status 用来标记作品是连载中还是已完结这个字段在列表页做筛选时很有用。summary 是简介建议限制长度避免有人塞一大段文字进来。章节表chapter字段有 id、novel_id、title、content、chapter_order、word_count、create_time。这里有两个设计要点一是 chapter_order 用来控制章节顺序不能依赖 id 自增因为作者可能插入章节二是 word_count 冗余存储避免每次统计字数都要遍历全文。分类表category和标签表tag分类是一对多关系一个作品属于一个分类标签是多对多关系一个作品可以有多个标签。这两者的区别在于分类是强归属标签是弱描述。4.2 章节顺序与内容存储的取舍章节顺序这个问题值得单独说。如果用 id 自增来排序作者想在中间插入一章就会很尴尬。我的做法是 chapter_order 用浮点数或者留间隔的整数比如 10、20、30插入时取中间值。这样既保证了顺序又避免了大规模更新。内容存储上章节正文可能很长用 TEXT 类型存储。但要注意如果正文包含富文本格式存的是 HTML 字符串渲染时一定要做 XSS 过滤否则会有安全风险。我用的方案是后端存储前用 Jsoup 做一次清洗只保留安全的标签。4.3 索引与查询优化文学网最常见的查询是“按分类查作品列表”和“按作品查章节列表”。对应的索引必须建好novel 表的 category_id 加索引加速分类筛选chapter 表的 novel_id 加索引加速章节列表查询novel 表的 title 加全文索引支持搜索注意全文索引在数据量小的时候效果不明显但数据量上万后差距就出来了。如果不想用全文索引也可以用 LIKE 加前缀匹配但性能会差一些。5. 核心功能实现从注册登录到章节阅读5.1 注册登录与密码安全注册登录看似简单但安全细节很多。密码存储用 BCrypt它自带盐值每次加密结果都不同能有效防止彩虹表攻击。登录成功后用 Session 或 JWT 维持状态我选 Session因为服务端渲染场景下 Session 更自然。登录接口要做防暴力破解简单做法是记录同一 IP 或同一账号的失败次数超过阈值就锁定一段时间。这个功能实现成本不高但能挡掉大部分脚本攻击。// 密码加密示例 String rawPassword user_input; String encoded passwordEncoder.encode(rawPassword); // 验证时 boolean matches passwordEncoder.matches(rawPassword, encoded);5.2 作品发布与章节管理作者发布作品的流程是填写作品信息 - 创建作品 - 进入章节管理 - 发布章节。这里有个体验细节作品创建后应该直接跳到章节编辑页而不是让作者再去找入口。减少一次点击作者就少一分流失。章节编辑用富文本编辑器我推荐用轻量级的比如 wangEditor 或 Quill它们体积小、功能够用。编辑完的内容存 HTML渲染时用 Thymeleaf 的th:utext输出但前提是已经做过 XSS 清洗。章节的增删改要特别注意权限校验只有作品作者本人和管理员才能操作。这个校验不能只在前端做后端每个接口都要验。5.3 阅读页的体验打磨阅读页是文学网的灵魂。我的实现里做了这几件事字号调节用 CSS 变量控制点击按钮切换几档字号存在 localStorage 里下次访问自动应用。夜间模式同样是 CSS 变量切换时改背景色和文字色避免刺眼。阅读进度记录用户滚动位置下次打开同一章节自动跳转。实现上用 scroll 事件节流后存 localStorage。上一章/下一章根据 chapter_order 查询相邻章节按钮固定在页面底部。// 字号调节的简单实现 function setFontSize(size) { document.documentElement.style.setProperty(--reading-font-size, size px); localStorage.setItem(fontSize, size); }这些功能单个看都不复杂但组合起来就是“读起来舒服”的完整体验。很多文学网做得不好问题往往就出在这些细节上。5.4 搜索功能的实现路径搜索是读者找书的主要入口。初期可以用 MySQL 的 LIKE 查询简单直接SELECT * FROM novel WHERE title LIKE CONCAT(%, #{keyword}, %) OR summary LIKE CONCAT(%, #{keyword}, %);但 LIKE 以通配符开头时无法走索引数据量大后会很慢。进阶方案是引入 Elasticsearch它支持分词、高亮、相关度排序体验好很多。如果不想引入额外组件也可以用 MySQL 的全文索引配合 ngram 分词器对中文支持还不错。我的建议是项目初期用 LIKE等数据量到几万条再考虑升级。过早优化是万恶之源。6. 跨浏览器适配那些只在特定浏览器上出现的坑6.1 CSS 兼容性的常见问题跨浏览器适配是文学网这类面向大众的项目必须面对的。我遇到最多的问题集中在 CSS 上flex 布局现代浏览器都没问题但如果要兼容很老的版本需要加前缀。不过现在基本可以不用管了。CSS 变量IE 不支持但 IE 已经退出历史舞台可以忽略。字体渲染不同系统默认字体不同建议显式指定字体栈比如font-family: PingFang SC, Microsoft YaHei, sans-serif;。6.2 JavaScript 的兼容性处理JS 方面主要注意这几点避免使用太新的语法如可选链在某些旧版本不支持或者用 Babel 转译事件监听用 addEventListener 而不是 onclick 属性处理滚动事件时注意节流否则在低端设备上会卡顿。6.3 移动端适配的实用方案文学网有很大比例的用户在手机上看移动端适配不能马虎。我的方案是响应式布局加 viewport meta 标签meta nameviewport contentwidthdevice-width, initial-scale1.0配合媒体查询在小屏幕上把侧边栏隐藏、字号调大、按钮加大。阅读页在移动端要特别注意行高和边距太挤了看着累。提示移动端测试一定要用真机模拟器上看着没问题真机上可能字体、间距全变了。这个坑我踩过不止一次。7. 部署上线从本地跑通到公网可访问7.1 打包与服务器环境准备Spring Boot 项目打包用 Maven 的 package 命令生成可执行 jar。服务器上需要装 JDK 和 MySQL如果前端有静态资源还要考虑用 Nginx 做反向代理。# 打包 mvn clean package -DskipTests # 运行 java -jar novel-web.jar --spring.profiles.activeprod生产环境的配置文件要单独一份数据库密码、端口这些不能和开发环境混用。7.2 Nginx 反向代理与静态资源分离Nginx 在这个架构里承担两个角色反向代理和静态资源服务器。动态请求转发给 Spring Boot静态文件CSS、JS、图片由 Nginx 直接返回效率高很多。server { listen 80; server_name your-domain.com; location /static/ { root /var/www/novel; expires 7d; } location / { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }静态资源设置缓存过期时间能显著减少重复请求。图片建议再配一层 CDN不过小项目直接用 Nginx 也够。7.3 数据库备份与日志监控上线不是终点运维才是长期工作。数据库要设置定时备份用 mysqldump 加 crontab 就能搞定。应用日志要配置滚动策略避免日志文件把磁盘撑爆。# 每天凌晨备份数据库 0 2 * * * mysqldump -u root -p novel_db /backup/novel_$(date \%Y\%m\%d).sql监控方面初期可以用简单的健康检查接口配合 uptime 监控工具。等规模大了再上 Prometheus 加 Grafana 那套。7.4 部署后必做的几项验证部署完成后别急着宣布完工这几项一定要验证注册登录流程是否正常、作品和章节的增删改查是否正常、静态资源是否加载成功、移动端访问是否正常、数据库连接是否稳定。我习惯写一个简单的检查清单每次部署后过一遍能避免很多低级问题。8. 我在这个项目里踩过的几个真实坑第一个坑是字符集。建库时没注意用了默认的 latin1结果用户提交的中文全变问号。后来改成 utf8mb4 重新导数据折腾了大半天。所以建库第一件事就是确认字符集。第二个坑是章节顺序。一开始用 id 排序作者想插入一章时只能删了重建体验极差。后来改成 chapter_order 留间隔问题才解决。第三个坑是 XSS。富文本内容直接渲染结果有人提交了带脚本的内容页面弹窗。后来加了 Jsoup 清洗才堵住。安全这块真的不能偷懒。第四个坑是部署时的路径问题。本地开发时静态资源路径写的是相对路径部署到 Nginx 后全 404。后来统一改成绝对路径加 context-path 配置才正常。这几个坑的共同点是本地跑得好好的一到真实环境就出问题。所以我的经验是开发阶段就要尽量模拟生产环境别等到部署才发现问题。9. 后续可以怎么扩展这个项目如果核心功能已经跑通想继续深挖有几个方向值得尝试。一是引入 Redis 缓存热门作品和分类列表提升响应速度二是接入 Elasticsearch 做全文搜索支持分词和高亮三是加评论和点赞功能增加社区属性四是做阅读数据的统计分析给作者提供阅读量、收藏量等反馈。每个方向都可以独立展开建议一次只做一个做完验证稳定了再上下一个。贪多嚼不烂这个道理在项目开发里同样适用。最后分享一个我个人的习惯每完成一个功能模块就写一段简短的笔记记录这个模块解决了什么问题、用了什么方案、踩了什么坑。等项目做完回头看这些笔记就是最好的复盘材料也是下次做类似项目时最实用的参考。