做个人网站这件事我前后折腾了不少年头。从第一个实验性质的小页面到第二个勉强能用的半成品再到这个刚刚上线的“三分熟”版本——我的第三个网站。这个标题看起来平平无奇但对我来说它意味着一次彻底的重来不再用现成的博客框架套模板不再因为怕麻烦就让代码烂在本地也不再天真地以为“能跑起来”就等于“能用”。如果你也做过两三个网站或者正在做第一个、第二个你应该能懂当你说出“这是我的第三个网站”时你真正想说的是前两个踩过的坑这一次终于绕开了。这篇文章没有高深的理论就是把我做第三个网站的全过程拆开怎么从坑里爬出来怎么重新选技术栈怎么把一个半成品打磨成真正上线且有人用的网站以及在部署、性能、安全和内容维护上踩过的那些常规文档不会写的坑。不管你是业余做点东西玩玩还是正在琢磨怎么把自己的项目作品集放上网这篇应该都能给你一些直接能抄作业的参考。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页面增加在线交互演示。最好玩的地方在于我现在敢于把一些不成熟的想法放上去因为我知道改起来不费劲。最后再分享一个小技巧给你的网站写一个简单的“更新日志页面”每次发布新功能或修完严重缺陷就在上面补一行记录。这不会花你多少时间但三个月后回头看你会很惊讶网站竟然已经迭代了这么多版本。做网站这件事最难的从来不是开始而是你能不能在一个三分钟热度过后还在慢慢打磨它。 
长河君 · 2026/10/21 6:44:36 · 阅读 1.2k 从踩坑到上线：我的第三个个人网站全流程复盘
做个人网站这件事我前后折腾了不少年头。从第一个实验性质的小页面到第二个勉强能用的半成品再到这个刚刚上线的“三分熟”版本——我的第三个网站。这个标题看起来平平无奇但对我来说它意味着一次彻底的重来不再用现成的博客框架套模板不再因为怕麻烦就让代码烂在本地也不再天真地以为“能跑起来”就等于“能用”。如果你也做过两三个网站或者正在做第一个、第二个你应该能懂当你说出“这是我的第三个网站”时你真正想说的是前两个踩过的坑这一次终于绕开了。这篇文章没有高深的理论就是把我做第三个网站的全过程拆开怎么从坑里爬出来怎么重新选技术栈怎么把一个半成品打磨成真正上线且有人用的网站以及在部署、性能、安全和内容维护上踩过的那些常规文档不会写的坑。不管你是业余做点东西玩玩还是正在琢磨怎么把自己的项目作品集放上网这篇应该都能给你一些直接能抄作业的参考。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页面增加在线交互演示。最好玩的地方在于我现在敢于把一些不成熟的想法放上去因为我知道改起来不费劲。最后再分享一个小技巧给你的网站写一个简单的“更新日志页面”每次发布新功能或修完严重缺陷就在上面补一行记录。这不会花你多少时间但三个月后回头看你会很惊讶网站竟然已经迭代了这么多版本。做网站这件事最难的从来不是开始而是你能不能在一个三分钟热度过后还在慢慢打磨它。