做个人网站这件事，我前后折腾了不少年头。从第一个实验性质的小页面，到第二个勉强能用的半成品，再到这个刚刚上线的“三分熟”版本——我的第三个网站。这个标题看起来平平无奇，但对我来说，它意味着一次彻底的重来：不再用现成的博客框架套模板，不再因为怕麻烦就让代码烂在本地，也不再天真地以为“能跑起来”就等于“能用”。如果你也做过两三个网站，或者正在做第一个、第二个，你应该能懂，当你说出“这是我的第三个网站”时，你真正想说的是：前两个踩过的坑，这一次终于绕开了。
这篇文章没有高深的理论，就是把我做第三个网站的全过程拆开：怎么从坑里爬出来，怎么重新选技术栈，怎么把一个半成品打磨成真正上线且有人用的网站，以及在部署、性能、安全和内容维护上踩过的那些常规文档不会写的坑。不管你是业余做点东西玩玩，还是正在琢磨怎么把自己的项目作品集放上网，这篇应该都能给你一些直接能抄作业的参考。
1. 前两个网站教会我的事
1.1 第一个网站：什么都想要，什么都半途而废
我的第一个网站是大三那年用某个傻瓜式建站工具搭的，目的很单纯，想给社团做个活动展示页。当时我连域名和服务器是什么都搞不清楚，只知道在工具里拖拽组件，换换图片，改改文字。结果折腾了一个月，页面倒是做了七八个，但每次新增内容都要手动改样式，图片压不压缩根本不在乎，手机上一打开字小得像蚂蚁。后来社团换届，这个网站就再也没人维护了。
那段经历给我最大的教训不是“工具不行”，而是“没有想清楚网站到底要解决什么问题”。当时的我只想着“我要做一个网站”，却从来没想过“这个网站给谁用、让他们做什么、怎么让他们愿意做”。所以这个网站表面上是做完了，实际上是个只能看的静态宣传册，连“宣传”都没做好——因为内容根本没人更新。
1.2 第二个网站：技术选型翻了车
第二个网站是我工作第一年用某博客框架搭的个人博客，初衷是写技术笔记。那时候我已经会一点前端，知道要用Markdown写文章，也知道要买个域名挂在云主机上。但问题出在技术选型上：我加了一堆插件——要评论、要统计、要SEO、要离线搜索、要PWA，还要支持暗夜模式。结果每一次升级主题都要跟插件打架，改一个样式要翻半天文档。更麻烦的是，那个框架的构建依赖非常繁琐，一个有半年没碰，回来再dev都要折腾一晚上环境。坚持写了三个月，文章没发几篇，时间全耗在“伺候”网站上。
这个阶段让我意识到，网站不是做得“多”就好，而是做得“合适”才行。那些看起来很酷的功能，维护成本如果超过内容产出成本，网站就会变成装饰品，而不是工具。
1.3 第三个网站的起点：从“我能做什么”转向“用户需要什么”
所以做到第三个网站时，我做了一个很俗但很管用的动作——先把核心需求用一句话写下来。我的情况是：我需要一个个人作品集 + 技术博客的合体站，用来展示我做过的一些模拟项目、工具型Demo，以及持续更新的技术笔记。目标用户有三个：未来可能的合作方、想找我讨论技术的同行、还有半年后可能忘掉自己写过什么的“未来的我”。
于是第三个网站的定位就很清楚了：
- 内容要快速发布，不能每次写篇文章都要重新构建全站。
- 页面要轻快，移动端打开要快，没有乱七八糟的弹窗。
- 维护成本要低，服务器不行可以随时迁移，数据要可备份、可恢复。
- 技术上最好贴近主流，这样以后别人看我代码也不会有门槛。
2. 技术栈与整体架构
2.1 为什么这次选静态优先、服务端为辅
前两个网站的教训让我把“快捷部署”和“好维护”放在第一位。当时对比了几种方案：传统动态博客、全栈自建、静态站点生成器。最后选择了以静态生成优先，动态接口为辅的混合架构。
静态生成的意思是，网站页面在构建阶段就会渲染成纯静态的HTML文件，不需要服务端实时跑模板。这样有几个直接的好处：部署简单，随便一台能托管静态文件的服务器或对象存储就能跑；访问快，页面不需要每次请求都查数据库；安全性高，没有动态解析的接口，传统注入攻击就没了入口。
但纯静态也有痛点——比如评论、搜索、表单提交。这些功能不能全靠静态文件做。我采用的办法是：评论用第三方平台嵌入，搜索用本地索引在前端跑，表单提交则用云函数和联表服务来搞定。相当于全站是一堆静态页面，但关键环节通过接口“长出”动态能力。
前两个网站我用过动态博客和框架全家桶，总是要各种登录、升级、打补丁。到第三个网站，我给自己立了一条规矩：能用静态就绝不上动态，能用一个服务就不引入两个服务。这条规矩一直用到现在，效果确实很稳。
2.2 前端框架真的选了个“闷声发大财”的
考虑到我写内容最多的是技术笔记，马克down文本是刚需，所以第三个网站的前端采用了一个组件化框架，配合了一款开源的内容驱动的生成器。选型逻辑很简单：
- 组件化框架生态成熟，将来想加交互功能，不会把自己绕死。
- 内容驱动生成器把Markdown当数据源，我只需写文章，构建自动产出页面。
- 组件化和生成器二者搭配的社区文档非常丰富，遇到问题是搜得着答案的。
有朋友问我，“你怎么不上最新的某某技术栈？”我说，网站是拿来用的，不是拿来秀的。市面上每月都有新工具，但个人站的成本得自己扛，选一个自己已经熟悉、社区足够活跃的方案，比盲目追新要靠谱得多。我宁愿把剩下的精力花在写内容和优化体验上，而不是一遍遍升级依赖。
2.3 数据库和服务器：能少花钱就不乱花钱
数据库方面，我没有单独搭数据库。内容全部用Markdown文件管理，构建后就是静态页面。需要存的动态数据，比如阅读量、访客数，用了一个轻量级的键值存储服务，附带免费额度，足够个人站用了。
服务器我只买了一台最低配的云主机，用来跑部署脚本、处理构建任务、作为静态文件的源站，前置套了内容分发网络做加速。这套架构下来，每个月的固定开销大概相当于一杯咖啡的钱。如果你也想低成本做个网站，千万不要第一步就去买高配服务器——新手期的流量根本跑不满，贵的配置只会让你心疼电费。
3. 核心功能实现与操作记录
3.1 页面架构：让首页既像作品集，又像博客索引
首页我采用了“双轨式”设计：上半部分是精选作品展示区，用来放我做过的小项目和工具截图，每个作品盖一个短描述、一个跳转链接；下半部分是最近更新的文章列表，直接读Markdown源文件生成，保证内容新鲜度。
作品区里的排序不是按时间倒序，而是按“用途”优先——凡是能立马上手用的工具排在前面，纯概念性的Demo往后放。这一点是学某些优秀个人站的启发：访客先看到“你能做什么”，再决定要不要了解你的思考过程。
首页的首屏我刻意做了简化：没有大轮播图，没有字体花哨的动画，只有一个一句话简介、一行关键词、两个按钮（查看作品 / 阅读博客）。移动端打开时，这三个板块的浏览顺序依然清晰。经验是：个人站最容易犯的错就是首页堆信息，访客根本不知道先看哪里。
3.2 博客系统：Markdown是我最后的内容防线
写文章这个环节，我彻底返璞归真，全部用Markdown。文件夹结构大致是这样：
content/ posts/ 2025-03-01-我的第三个网站.md 2025-02-14-用markdown管理项目文档.md projects/ image-processor-demo.md api-mock-server.md每篇文档的开头有一段 front matter，用来记录标题、日期、标签、摘要、封面图路径。构建的时候生成器会自动读取这些信息，渲染成文章列表和详情页。我给博客加了标签页和按年份归档，但没做复杂的分类树——原因是写文章时你很难预判未来文章会怎么归类，等文章量大了再重构也不迟。
写博客文章时，我给自己定了最小发布规范：
- 标题必须让人知道这篇文章能解决什么问题；
- 开头两段必须说完核心结论；
- 至少有一个可以复制的代码块或步骤列表；
- 图片要压缩后再上传，绝不直接外链。
这样做的效果很明显：产出速度上来了，文章质量也保持得比较稳定。
3.3 评论与互动：不自己造轮子，但也不全倚仗第三方
评论这个功能，我在第二个网站吃过亏——第三方插件加载了一堆脚本，结果页面体重增加不少。第三个网站我换了个思路，评论框懒加载，只有用户点击“加载评论”时才插入评论脚本，平时完全不影响页面速度。相应的，我接受了一个代价：评论曝光度低，留言的人比实时挂载时少一些，但对于技术博客这类场景，安静一点反而更像阅读环境。
互动不止评论。我给每篇文章加了一个“阅读状态”标记：本地通过浏览器存储记录你看过哪篇；当你再次访问时会看到“已读”标识。这个小功能成本极低，但回访体验会好不少。访客数据我坚持不在前端埋点，只在构建时统计页面访问流量，保证隐私干净。
3.4 搜索功能：本地索引才是最稳的方案
站内搜索以前我都是靠第三方搜索接口，后来发现限额动不动就爆。第三个网站我直接在构建阶段生成一个JSON索引文件，里面包含每篇文章的标题、摘要、标签和全文关键部分。搜索时前端用轻量级分词脚本在本地索引里匹配，不依赖任何服务端接口。
百来篇文章的规模下，本地搜索一秒内就能出结果。当然文章超过上千篇后，这个方案可能会吃力，但到那时再换独立的搜索服务也不迟。
3.5 表单收集：不搭后端，用云函数顶住
个人网站通常需要“给我发消息”按钮，但又不想为它专设一个后端。我的解决方式是用一个支持云函数的托管环境，前端提交后，函数负责把内容发到我的邮箱，同时写入一个只读的存储表里。这样不给自己增加被攻击的暴露面，也不怕突然来一堆垃圾广告。
云函数的冷启动也没想象中慢，实测从提交到收到邮件提示，大概两秒左右，完全能接受。安全方面，加了朋友域校验和简单的频率限制，普通垃圾消息基本进不来。
4. 部署上线与性能优化
4.1 构建流程：一次命令，全站更新
第三个网站的发布流程我用自动化脚本来做。写完文章后，本地执行一条命令，脚本会自动完成几件事：读取Markdown生成静态页面、压缩图片资源、把产物同步到服务器、在服务器上执行部署动作、再刷新内容分发网络的缓存。整个过程平均三分钟，比起第二个网站每次手动传文件要省心得多。
部署脚本最关键的是处理好增量同步，只上传变化过的文件，否则几十篇文章以后的更新会越来越慢。这里我用的是按时间戳判断变化的同步方式，上传前自动对比服务器文件时间。实测下来，单篇文章更新时，真正上传的文件只有几个，干净利落。
流水线脚本的关键步骤大致是：
# 构建静态页面 npm run build # 同步到服务器指定目录 rsync -avz --delete dist/ 你的用户@你的服务器:/网站根目录 # 刷新CDN缓存（按项目实际情况选用） curl -H "密钥信息" 刷新接口4.2 加载速度的硬指标
首页首屏的可视化资源只要两张很小的图和一段内联样式，没有一个外部字体，也没有大体积的JavaScript。我测得的结果：首屏内容加载约0.8秒，完整页面加载约1.6秒，Lighthouse性能评分在96到100之间浮动。
提升速度的心法其实只有一个：少放东西。把不需要首屏展示的脚本全部移到页面尾部或懒加载；图片全部用现代格式并做多尺寸适配；字体一律系统字体栈。听起来平淡无奇，但大多数个人网站慢，都是因为塞了太多“以防万一”的资源。
4.3 移动端适配与可访问性
第三个网站移动端的适配我采用的是“移动优先”策略：先写手机上的布局，再向外扩展到平板和桌面。实际做法是使用流式栅格和弹性排版，而不是针对每个机型写死尺寸。
可访问性做了三件事：所有图片有替代文本；所有按钮和链接有可聚焦的焦点样式；正文的对比度调到通过无障碍检测的等级。这些细节前期多花一点时间，后期就不用为“为什么手机上看不清”这种问题反复返工。
5. 上线后的问题与排查实录
5.1 图片被外部盗链，流量超了
上线第二周，我发现某一天的流量突然涨了几十倍，查了日志才反应过来，有两张项目截图被其他网站直接引用了。虽然我的流量包勉强够，但这个势头继续下去可不行。根治方法很简单：在服务器配置里加上防盗链规则，只允许自己的域名和空来源访问图片，其他外部来源一律返回占位图。
建议你在上线时就加这块规则，不要等流量炸了才想起。规则配置不长，但能省下一大笔不必要的流量费。
5.2 文章页分享到社交平台时没有摘要
有朋友把我的一篇文章分享到聊天软件里，结果预览卡片只有个光秃秃的链接。原因是我没写标准的分享卡片标签。这类标签是放在页面头部的一段元信息，告诉社交平台“用哪个标题、哪个描述、哪张图”来生成预览。
补上每个页面的“标题、描述、图片、网页地址”这四个字段后，再分享就正常了。很多个人站都忽略这个细节，但它在传播中真的很重要，毕竟大部分读者是从社交平台上第一次看到你的文章。
5.3 评论通知进垃圾箱
评论系统接入后，我发现自己收不到通知邮件，一查，通知邮件被邮件服务商过滤到垃圾箱。解决方法没什么技巧：一是把发件地址换成域名自己的邮箱，二是降低通知频率，避免短时间大量触发。个人站的评论量不大，一天十几封很正常，设成“有评论才发”就好。
这套配置花的时间不多，但如果你不问，可能一直发现不了“别人评论了，我却不知道”。
6. 一些容易被忽略的经验补充
6.1 域名和历史记录都值得认真对待
域名到期前一定要开自动续费，或至少设置好续费提醒。我有一次因为忘续费，域名被暂停解析，花了半天才找回来。更稳妥的做法是，把域名和管理后台的所有账号都记录到认账本里，并开启两步验证。个人站最容易翻车的就是“账号遗失”和“域名过期”，而不是技术疑难。
6.2 备份要做到“想到就能还原”
第三个网站的备份策略很简单：Markdown源文件同步一份到代码托管平台私有仓库，数据库之类的结构化数据每日自动导出到对象存储。这样即使服务器一夜之间消失，我也可以通过同步机制在半小时内恢复出全站内容。
如果你只有服务器本地的备份，那就等于没有备份。一定要測試一下从零恢复的流程，否则备份只是心理安慰。
6.3 内容维护：把写文章变成习惯而不是任务
网站上线只是开始，真正难的是持续更新。我的办法是提前存了十几篇半成品草稿，状态包括“只有标题的”、“写了一段的”、“配图为空但文字完整的”，这样每次打开编辑器都有可选的工作项，而不是对着空白页发呆。
更新节奏上，我不强求一周几篇，但给自己定了一条硬规矩：每当解决一个问题或踩完一个坑，就立刻补一篇文章。这样内容自然和实操挂钩，写起来也顺手。
7. 写在最后：第三个网站教会我的事
如果你现在正准备做你的第一个或第二个网站，我的建议只有一条：先写下三个问题的答案——这个网站给谁用，他们来做什么，做完后你怎么维护。想不清楚，就先去搭一个最简单的静态页验证。
我自己以前总觉得“做网站就是写代码”，现在回头看，做网站其实是持续做决定的过程：留什么功能、弃什么功能、怎么让以后维护更省力。第三个网站不是终点，而是一个能让我继续折腾的平台。我目前已经在规划把文章分类和作品筛选做得更顺手，也想给部分Demo页面增加在线交互演示。最好玩的地方在于，我现在敢于把一些不成熟的想法放上去，因为我知道，改起来不费劲。
最后再分享一个小技巧：给你的网站写一个简单的“更新日志页面”，每次发布新功能或修完严重缺陷，就在上面补一行记录。这不会花你多少时间，但三个月后回头看，你会很惊讶网站竟然已经迭代了这么多版本。做网站这件事，最难的从来不是开始，而是你能不能在一个三分钟热度过后，还在慢慢打磨它。
