个人博客项目开始于 2022 年 10 月 8 日。它最初只是一个用来串联所学知识的练习项目，后来逐渐变成自己的笔记库、作品和长期维护的个人空间。相比最终页面，这段从零设计、开发、重构和部署的过程，对我的成长更重要。
博客真正记录的不只是文章，也记录了我如何从“想到哪做到哪”，逐渐学会需求分析、工程规范、性能优化、部署和复盘。
一、为什么要做一个个人博客
当时学校仍处于疫情防控阶段，我希望找一个足够完整的项目，把前端、后端、数据库和部署串联起来，同时拥有一个由自己控制的个人笔记库。
为了真正经历从 0 到 1 的过程，项目很少直接依赖完整 UI 组件库。从页面样式、数据结构、接口到服务器部署，都尽量自己完成。这样做效率不一定最高，却让我看见了一个完整系统背后的每个环节。
二、版本时间线
2022 年 10 月 8 日：项目启动
开始收集参考网站、确定视觉方向、梳理技术栈，并着手设计数据库与接口。
2022 年 11 月 10 日：1.0 版本完成
完成博客前台、服务端和后台管理的基本闭环，能够满足文章发布与日常书写需求。
2022 年 12 月 3 日：2.0 版本完成
由于对服务端渲染和 SEO 的需求增加，使用 Nuxt 3 重构博客前台。最终时间比最初预计晚了约半个月。
延期本身不是最大的问题。更值得复盘的是：早期需求没有整理清楚，后期不断调整数据库和页面，很多时间消耗在返工上。
三、当时的技术架构
- 博客前台：Vue 3、TypeScript；后期使用 Nuxt 3 重构。
- 服务端：Node.js、Express。
- 数据库：MySQL。
- 后台管理：独立的内容管理端。
- 服务端组织：采用 MVC 分层思路。
这套架构描述的是 2022 年项目阶段。博客后续可能继续重构或更换技术栈，不能把这篇历史复盘当作当前生产架构说明。
访客
↓
博客前台（Vue 3 + TypeScript / Nuxt 3）
↓ REST API
服务端（Node.js + Express）
↓
MySQL
管理员 → 后台管理端 → REST API项目截图：从左到右依次为博客前台、服务端和后台管理。
四、从想法到上线的开发过程
1. UI 方向
初期浏览了大量个人博客和内容网站，最终确定简洁、轻量的视觉方向。页面不追求复杂装饰，希望内容本身成为阅读中心。
2. 技术选型
当时有意选择较新的技术，目的之一是训练自己快速学习和解决陌生问题的能力。新技术带来了学习动力，也增加了踩坑和返工成本。
3. 需求与数据设计
围绕文章、分类、标签、用户和管理功能进行需求分析，设计数据库与 ER 关系，并按 REST 风格组织 API。后来出现的大幅数据库调整，也说明这一阶段做得还不够充分。
4. 工程结构与规范
分别搭建前端、后端和管理端项目，制定目录结构、ESLint 规范和 Git 提交规范。服务端按 MVC 拆分职责，避免所有逻辑堆在路由中。
5. 业务开发
逐步完成文章管理、内容展示、分类检索和后台维护等日常功能，让系统具备从编辑到发布再到阅读的完整链路。
6. 部署与修复
完成服务器部署，并在实际使用中继续修复 Bug、调整页面和优化加载速度。上线以后，问题才从“代码能运行”变成“用户是否能稳定访问”。
五、性能与体验优化
首屏加载
项目早期首页在当时测试环境中平均加载约 11 秒，后来降到约 6 秒。这个数字不是严格实验室基准，但它让我第一次直观看到图片、请求数量、渲染方式和资源加载策略对体验的影响。
- 对非首屏图片使用懒加载。
- 压缩图片，避免直接分发尺寸和体积过大的源文件。
- 文章列表采用分页，减少一次请求和渲染的数据量。
- 插件按需引入，控制前端资源体积。
响应式布局
使用 Flex 布局与媒体查询适配手机、平板、笔记本和大屏显示器。响应式不只是把页面缩小，还需要重新考虑导航、文字宽度、图片尺寸和交互区域。
CDN
将图片和部分静态资源放到云 CDN，降低源站压力并改善资源访问速度。后续还需要同时考虑缓存版本、失效策略和资源域名的长期可用性。
SEO 与服务端渲染
使用 Nuxt 3 重构前台后，为文章详情设置标题、描述等页面元信息，让搜索引擎更容易理解内容。SEO 不只是一组关键字，还包括可抓取内容、语义结构、链接、性能和持续输出。
性能优化不能只记住“懒加载、CDN、SSR”几个名词。应该先测量瓶颈，再验证每项改动是否真的改善用户访问体验。
六、为什么选择 Nuxt 3 重构
1.0 版本已经能够运行，但纯客户端渲染对首屏内容和搜索引擎抓取并不理想。重构的主要目标是改善内容页面的服务端渲染能力和 SEO，而不是单纯为了更换框架。
- 让文章内容能够在初始 HTML 中输出。
- 按页面生成合适的标题与描述。
- 统一路由、数据请求和页面渲染逻辑。
- 为后续性能优化和内容分发留出空间。
重构也带来了新的学习成本：服务端与客户端执行环境不同，数据获取、运行时配置和 Hydration 问题都需要重新理解。
七、项目中暴露出来的问题
1. 需求没有提前收敛
项目开始前没有把功能范围和数据关系梳理完整，经常想到一个功能就立即开始做。数据库在后期发生较大变动，接口和页面随之返工，直接影响开发效率。
2. 开发记录太零散
遇到问题时做过一些笔记，但内容分散、结构混乱，后来连自己都不愿意看。没有记录决策背景，也很难解释当时为什么选择某种方案。
3. 没有及时复盘
项目结束后没有立即总结，直到两个月后才重新回顾。很多具体问题和解决过程已经模糊，只能花更多时间重新寻找线索。
4. 优化缺少统一指标
当时记录了首页加载时间的变化，却没有完整保存网络环境、设备、缓存状态和各阶段指标。它能说明体验有所改善，但不适合作为严格的性能结论。
八、这个项目带来的成长
从单点知识到完整链路
以前学习 Vue、Node.js 或 MySQL 时，关注的是某个知识点能否运行。博客项目让我第一次把 UI、接口、数据库、部署、域名、CDN 和 SEO 放进同一条链路。
从写功能到理解工程
目录规范、提交规范、分层架构和部署流程看起来不会直接产生页面功能，却决定了项目能否继续维护。真实项目让我理解了这些工程约束的意义。
从追求完成到重视复盘
项目让我意识到，完成一个版本只是阶段终点。及时记录问题、解释决策、整理指标和回顾返工原因，才能把一次项目经历真正转化为长期能力。
从技术展示到长期写作
博客最初是练习项目，后来变成持续使用的写作空间。技术会重构，页面会变化，但文章和思考会不断积累，这也是它区别于普通课程 Demo 的地方。
九、后续优化方向
内容与管理
- 完善后台年度计划或内容规划模块。
- 改善文章编辑、草稿、发布和版本管理体验。
- 建立更清晰的分类、标签和站内搜索。
评论与通知
- 设计评论审核流程，处理垃圾内容与风险文本。
- 在回复发生时准确通知对应用户。
- 增加频率限制、身份校验和隐私保护。
性能与可靠性
- 建立可重复的性能测试，而不是只记录一次加载时间。
- 继续优化图片格式、响应式尺寸、缓存和 CDN 策略。
- 完善日志、错误监控、备份和部署回滚。
开发过程
- 开始编码前写清楚需求范围和数据关系。
- 开发过程中记录关键问题、决策和验证结果。
- 每个版本结束后立即复盘，而不是等记忆逐渐消失。
十、如果重新开始一次
- 先定义博客真正需要解决的问题，列出本期不做的功能。
- 画出页面流程、数据模型和系统边界，再决定技术栈。
- 用最小闭环尽早上线：登录、写作、发布、阅读。
- 从第一天建立代码规范、环境配置和数据库迁移。
- 为性能、SEO 和错误率建立可重复的测量方式。
- 每次重构都写清楚目标和验收条件，避免为了框架而重构。
- 在版本完成当天记录问题、选择、数据和下一步。
十一、结语
个人博客并不是我做过最复杂的项目，却是最能反映成长轨迹的项目之一。它从一个练习 Vue、Node.js 和 MySQL 的想法开始，经历了需求反复、性能优化、Nuxt 3 重构和服务器部署，最后成为持续写作的地方。现在再看，真正有价值的不是某一版用了什么框架，而是我开始学会把技术选择放进需求、体验、维护和长期积累中思考。