技术博客从零搭建：静态站点、自动部署与SEO收录实战

先说一个我观察到的现象：大部分人的技术博客死在第 7 天，而不是死在第 700 天。搭建本身只花了两个晚上，第三次更新之后就再也没有打开过那个仓库。原因通常不是懒，而是搭建阶段做了一堆当时觉得"很专业"、事后全变成阻力的决定——主题改了三遍、评论系统接了两套、部署流程要手动传文件、想改个标题得翻五个配置文件。这篇文章聊的是从零搭建技术博客的完整链路，但重点不在于给你一套抄完就完的配置，而是把每个环节的选择逻辑摊开：域名和托管怎么配、静态站点生成器怎么选、内容目录怎么组织、性能与收录要做哪几件真正有用的事、上线之后怎么不被依赖升级拖死。适合已经写过几篇笔记、准备把东西正式放出去的人，也适合已经搭好但一直没更新的朋友对照着检查一下自己卡在哪一步。

1. 动手前先想清楚：技术博客到底写给谁看

我见过太多人把顺序搞反了：先花两周调主题配色，写到第一篇正文时忽然发现自己不知道该用什么语气说话。定位这件事听起来虚，但它实实在在决定了后面所有技术选型——要不要评论、要不要多语言、要不要统计、目录结构按年份还是按主题，全都从这里推导。

1.1 三种定位对技术栈的真实影响

技术博客大致分三类，各自的诉求差别很大。

个人知识库型：主要读者是三个月后的自己。这类站点对样式几乎没要求，但对检索要求极高——全站搜索、标签聚合、按时间倒序归档必须有。你可能还会有大量半成品笔记，所以草稿机制和"不发布但也不删除"的状态要设计好。这类站点我建议直接上最轻的方案，构建越快越好，因为你会频繁本地预览。

作品展示型：读者是面试官、合作方、潜在客户。这类站点对首屏观感和页面质量要求高，文章数量反而不重要，五篇写得扎实的深度文章顶过五十篇周记。它需要的是精心设计的首页、清晰的项目说明页、稳定的访问速度，以及一个不会突然挂掉的域名。评论系统在这类站点上基本是负资产，噪音大于价值。

话题输出型：面向社区持续输出，靠订阅和搜索流量获得反馈。这类才真正需要 RSS、站点地图、结构化数据、社交卡片、访问统计这一整套东西，也最需要关注收录情况。如果你属于这一类，第 5 章的内容要认真看。

先把这三类分清楚，再去看工具对比表，你会发现很多"功能"其实跟你无关。我见过有人给一个纯知识库站点接了三种评论插件，最后因为垃圾评论太多全删了，白折腾。

1.2 用"三个月后还在更吗"做一次冷静自检

判断自己属于哪一类，有个很土但很准的方法：问自己"三个月后这个站还在更新吗"。如果答案是"应该会"，那你可以放心投入时间做完整的基建；如果答案是"看情况"，那就把搭建时间压到 4 小时以内，剩下的精力全留给写第一篇。

这里有个经验值：从想法到发布一篇新文章的操作步骤超过 5 步，断更概率会显著上升。理想状态是在编辑器里写完 Markdown，保存，执行一条提交命令，剩下的交给自动化。任何需要你打开浏览器登录后台、复制粘贴、手动上传文件的环节，都是未来的断更理由。

顺带说一句，别急着买域名。先用托管平台给的免费二级域名把站点跑起来，写满五篇再决定要不要绑定自己的域名。域名一年几十块不贵，但绑定域名之后你会开始在意"这站得拿得出手"，然后陷入无限期的主题打磨，第一篇文章永远发不出去。

2. 静态站点生成器怎么选：把需求翻译成选型清单

技术博客九成以上是静态站点，原因是它没有数据库、没有运行时、每次访问都是读文件，速度快、成本低、几乎不会挂。剩下的问题就是：用哪个工具把 Markdown 变成 HTML。

2.1 从写作习惯倒推工具链

选型别从"哪个最火"开始，从你的写作习惯倒推。我列几个真正影响长期体验的问题，你可以逐条对照：

• 你主要在本地编辑器写，还是希望有个网页后台？如果坚持本地写，纯静态生成器完全够用；如果希望随时在手机或别的电脑上写，那要考虑内容仓库和构建流程能不能在浏览器里完成。
• 文章里会不会有数学公式、流程图、交互式组件？数学公式需要渲染器支持；交互组件意味着你要么用支持组件化的框架，要么接受用内嵌页面绕过去。
• 预计文章规模是多少？五十篇和一千篇是两个世界。纯静态生成器生成一千篇通常在几十秒量级，但如果每篇文章都带图片处理（压缩、生成多尺寸缩略图），构建时间会成倍增长，这时候增量构建能力就很关键。
• 有没有人跟你一起写？多人协作时，模板语法的学习成本和代码评审的友好度就变得重要。

把这四个问题答完，备选方案通常就只剩一两个了。剩下的差异都是个人偏好，选哪个都不会错。

2.2 四类常见方案的横向对照

按实现语言和设计思路，市面上主流方案可以归成四类。我用功能描述代替具体名称，你对照特性就能认出它们分别是谁。

几个补充说明，这些是表格里塞不下的：

构建速度的实际影响比想象中大。我做过一个对比，同一批约 400 篇带代码块的文章，编译型生成器全量构建 1.2 秒左右，脚本型大约 12 秒，组件框架型冷启动接近 40 秒。单看数字都还能忍，但本地写作时你每改一个标点就要等一次热更新，40 秒的反馈延迟会实打实地磨掉写作欲望。如果你有前端背景并且确实需要组件化能力，那值得；如果只是想写文章，别为了"技术栈先进"支付这个成本。

插件生态是一把双刃剑。插件多的方案上手快，但插件质量参差不齐，很多插件长期不维护，升级主版本时集体报错。我的做法是：核心功能用官方能力，非核心功能（比如阅读时长估算）自己写十几行脚本，反而更稳。

增量构建不是万能药。它解决的是"改了文章 A 却要重新生成全站"的问题，但如果你的瓶颈在图片处理或语法高亮，增量构建帮不上忙，得从流程上分开处理。

2.3 我为什么最终落在"Markdown + Git"这条路上

说一个我自己的选择过程。早期我用过带数据库的方案，好处是有后台、能在线编辑、评论和统计一体化；坏处是三年后我想换主题，发现所有文章都躺在数据库里，导出成 Markdown 之后格式乱得一塌糊涂，代码块的缩进全丢了，图片链接指向的还是旧域名的绝对路径。那次迁移花了我两个周末。

后来我把所有内容统一成纯 Markdown 文件放进 Git 仓库，这件事带来的收益远超预期：

• 版本可回滚。改错一个参数把站点搞崩了，回退一个提交就行，不用回忆"我到底改了哪"。
• diff 可读。文章修订历史是逐行的，能清楚看到某段话是什么时候改的、为什么改。
• 不绑定平台。内容就是一堆文本文件，今天用这个生成器，明天换另一个，正文一个字都不用动，只需要处理 front matter 字段名和模板。
• 离线写作无障碍。飞机上、断网时照常写，写完提交等有网再推。
• 备份天然存在。每推一次就是一份异地副本。

代价也要说清楚：你需要熟悉命令行，需要理解 Git 的基本操作，多人协作时要处理冲突（不过博客这种场景冲突极少）。图片放在仓库里会让仓库体积膨胀，超过几百 MB 之后克隆会变慢，这时候要么用 Git 的大文件扩展，要么把图片挪到对象存储。这个取舍后面第 4 章会细说。

3. 域名解析、HTTPS 与托管链路：把站点真正推到公网

本地能跑和公网能访问之间，隔着一段最容易出错的链路。这一段的坑普遍很低级，但排查起来很费时间，因为出错时的表现往往只是"打不开"或"404"，没有任何提示。

3.1 域名和 DNS 记录怎么配才不会踩空

先把记录类型搞清楚，这决定了你后面能不能正确绑定。

这里有个必须知道的基础限制：CNAME 记录不能直接用在根域名上。根域名（也就是不带 www 的那一截）按 DNS 规范必须能同时承载其他记录类型，而 CNAME 要求该名字下不能存在其他记录，两者冲突。所以你会看到两种常见做法：

一是根域名用 A 记录指向托管方的固定 IP，www子域用 CNAME 指向托管方域名，然后在托管侧配置把www重定向到根域名（或反过来）。二是使用支持别名记录的解析服务，它能在根域名上模拟 CNAME 的行为，这样托管方换 IP 时你不用手动跟。

我的建议是统一到一个主域名上，另一个做 301 永久重定向，不要两个域名都能直接访问。原因很实际：两个地址都能打开会造成重复内容，收录时会分散权重，也是第 5 章要讲的收录问题的常见来源。

还有一个小技巧值得提前做：改解析之前把 TTL 调低。TTL 是记录的缓存时间，常见默认值是 3600 秒甚至更长。如果你要更换托管方，提前一天把 TTL 调到 300 秒，切换时全球生效只需要几分钟；如果不调，改完之后可能有一小时的时间，一部分用户看到新站、一部分看到旧站，你会以为是自己配错了，反复折腾。

3.2 自动部署流水线的搭建与常见报错

手动上传文件这件事，第一次做觉得没什么，做到第十次就会开始偷懒，偷懒就会出错。自动部署的流程很简单：往仓库推代码，托管平台拉取代码、执行构建命令、把产物目录发布出去。配置文件通常是仓库根目录下的一个 YAML 文件，写清楚环境版本和构建命令就够了。

# 通用构建配置示意，字段名按所用平台的实际规范调整 build: image: node:20 # 显式锁版本，不要用 latest steps: - run: npm ci # 用 ci 而不是 install，保证依赖与锁文件一致 cache: true - run: npm run build publish: dir: dist # 产物目录，写错就是全站 404

配置本身没什么难度，坑都在环境差异上。下面这几类我全踩过：

大小写敏感问题。本地开发机常见的不区分大小写，而构建环境通常是区分的。你在本地引用./Images/cover.png，文件实际叫images/cover.png，本地一切正常，上线后图片全裂。这类问题排查起来特别费劲，因为报错信息只会告诉你资源 404。解决办法只有一条：文件名统一小写，并且用连字符代替空格，从源头掐死。

环境版本不一致。本地用的是一个较新版本的运行时，构建环境默认是老版本，于是本地好好的构建在线上直接报语法错误。配置文件里把版本号写死，别用latest，这一条能省掉大量莫名其妙的报错。

缓存导致的陈旧产物。依赖缓存能大幅缩短构建时间，但偶尔会出现"明明改了代码，线上还是旧的"。遇到这种情况先清缓存重跑一次，如果仍然不对，检查是不是产物目录被整体缓存了。

子目录部署的路径问题。如果站点部署在example.com/blog/这样的子路径下，而站点配置里的基础路径还是根路径/，那所有 CSS、JS、图片链接都会指向错误位置，表现为"页面是白板，只有裸文字"。这个配置项名字各不相同（有的叫 base，有的叫 publicPath，有的叫 pathPrefix），但逻辑一样。

构建时的时区问题。文章日期如果是"未来时间"，有些生成器会默认跳过不生成。构建环境的时区和你本地不一致时，可能出现某篇文章本地有、线上没有的诡异情况。统一用带时区的完整时间格式写日期，这个坑就没了。

3.3 HTTPS 证书与重定向的细节

HTTPS 现在基本是托管平台自动处理的，你不需要手动申请证书。但有三个细节要确认：

混合内容警告。站点是 HTTPS 了，但文章里引用的图片还是http://开头，浏览器会把整页标记为不安全，某些环境下图片直接不显示。老文章迁移时最常出现这个问题，建议在构建阶段加一条检查，把正文里所有http://的资源链接揪出来。

强制跳转要配。确认访问http://会自动跳到https://，而不是两个都能打开。这同样是重复内容问题。

HSTS 谨慎开启。HSTS 是告诉浏览器"以后访问我这个域名一律走 HTTPS"，好处是安全，坏处是它会记住这个设置且很难撤销——如果你开了 HSTS 之后证书出问题，用户连"手动点继续访问"的机会都没有，只能等证书修好。开启之前先确认证书续期是稳定的自动流程，并且对子域名是否生效想清楚。

4. 内容组织：目录结构、写作流程与代码块规范

前面都是基建，这一章才是你未来几年每天都要打交道的东西。内容组织做得不好，两年后你会面对一堆找不到、改不动、不敢删的文章。

4.1 从"文件夹即分类"到标签体系的取舍

分类和标签的区别，用一句话说清楚：分类是一对多的目录，标签是多对多的关键词。一篇文章只能属于一个分类，但可以打任意多个标签。很多人一开始只用文件夹分目录，写到一百篇之后发现有些文章既属于"A"又属于"B"，文件夹没法表达，于是开始乱放。

我的做法是：分类只保留少数几个粗粒度的、稳定的维度（比如后端、前端、工具、杂记），数量控制在十个以内，并且尽量不新增，因为分类一旦变化就意味着 URL 变化。标签放开用，反正标签页面是聚合视图，改动不影响文章本身的地址。

URL 结构上，我强烈建议在文章地址里带上日期或固定 slug，并且发布之后永不修改。文章标题可以改，但 slug 一旦变动就必须配 301 重定向，否则所有外部链接和搜索结果都会指向 404。这个规则我写进了自己的发布清单里，改标题时先问一句"slug 要不要动"。

front matter 字段也要一开始就定好，后面加字段的成本比想象中高（历史文章要批量补）。我用的字段大致是这些：

4.2 一套能坚持下来的写作流水线

写作流水线的设计目标只有一个：让"想写"到"已发布"之间的阻力尽可能小。我现在的流程是这样的，从新建到上线全程不超过几分钟的额外开销。

第一步，用一个模板文件生成新文章的骨架。模板里预填了日期、分类、草稿标记，我只需要改标题和 slug。这里建议把模板里的日期自动填成当前时间，手动敲日期最容易写错格式。

第二步，文章放草稿状态写。草稿状态下本地预览能看到，但构建产物里没有，所以你可以放心地推送到仓库，不用担心半成品被访问到。这解决了"想在公司电脑上接着写"的问题。

第三步，本地预览。热更新是必需品，改完保存浏览器自动刷新，比自己按 F5 强很多。预览时重点看三件事：代码块有没有横向溢出、图片宽度是否撑破容器、长标题在列表页会不会换行错位。

第四步，发布前过一遍清单。我的清单一共六条，每条都对应一次真实的翻车：文章里所有外链能不能打开、代码块有没有标语言、图片 alt 有没有写、摘要填了没有、slug 有没有和已有文章冲突、日期是不是在未来的时区里。这六条检查下来不到两分钟，但能挡掉大部分低级问题。

第五步，提交推送，等自动化跑完。构建日志要养成看一眼的习惯，很多警告（比如内部链接指向不存在的页面）不会让构建失败，但会一直烂在那里。

4.3 技术文章里的代码块、图片与图表规范

代码块是技术博客的门面，几个细节值得较真：

一定标语言。不标语言的代码块没有语法高亮，读者阅读成本陡增。而且某些生成器会把它当纯文本处理，长行直接溢出容器。

控制单行长度。超过 90 个字符的行在中等宽度的屏幕上会触发横向滚动，读者要左右拖动才能看完整，体验很差。写代码示例时主动断行，比事后怪主题宽度设置不合理有用。

代码要能跑。我给自己定的规矩是：示例代码必须是从实际能运行的版本里截出来的，不能凭记忆手写。凭记忆写出来的代码经常少个引号、少个await，读者复制过去报错，然后就不再信任你的文章了。

图片这块，我现在的处理原则是：

• 截图宽度统一压到 1200 像素以内，格式优先用 WebP，质量 80 左右，单张控制在 200KB 以下
• 终端输出、配置片段这类内容用代码块而不是截图，搜索得到、复制得了、体积还小
• 图片放在仓库里还是对象存储，取决于数量。两百张以内放仓库最省事，再多就该往外挪了
• 每张图都写 alt，一方面是无障碍，另一方面图片挂了的时候至少能看出这里原本是什么

至于要不要在文章里放流程图和时序图，我的看法是：能用一段话讲清楚的，就别画图。图维护成本高，改一个分支就要重画，而且很多图表工具的语法和渲染效果在不同主题下差异很大，迁移时经常整块失效。真需要图，优先选纯文本描述加表格。

5. 打开速度与搜索可见度：性能与 SEO 的实战处理项

站点上线之后，你会开始关心两个指标：打开快不快、搜不搜得到。这两件事有大量"看起来很专业但没什么用"的操作，我按投入产出比排一下。

5.1 首屏性能：图片、字体与第三方脚本

性能优化最容易犯的错是没有测量就开始优化。先用浏览器自带的性能面板跑一次，看最大内容元素的加载时间落在哪里，再决定动哪里。经验上，静态博客的性能瓶颈九成集中在三个地方：

图片。首屏大图是最常见的拖累项。处理方式是压缩、限制尺寸、首屏图不要懒加载、非首屏图全部加懒加载。一个常被忽略的点是给图片写死宽高属性，否则图片加载过程中页面会跳动，读者刚想点某篇文章，页面一跳点到了别的，这种体验损伤比慢一秒更严重。

字体。中文字体文件动辄几 MB，直接引入会让首屏白屏很久。解决办法是子集化——只保留你实际用到的字符，通常能压到几百 KB 甚至更小；再配合font-display: swap，让文字先用系统字体显示，字体加载完再替换。如果你的站点主要读者在国内，还要考虑不要依赖境外字体服务，加载失败时会长时间卡住。

第三方脚本。访问统计、评论系统、分享按钮，每一个都是外部请求。这些脚本全部改成延迟加载，等页面主要内容渲染完再执行。评论系统尤其要注意，它经常是页面上最重的部分，而它恰恰是最不重要的部分——没人会因为评论区加载慢而离开，但会因为你首屏白屏两秒而离开。

顺便说一个反直觉的观察：主题自带的"性能优化开关"经常是负优化。比如某些主题默认开启代码块行号、默认开启阅读进度条、默认内联所有 CSS，这些在文章少的站点上没什么感觉，文章一多就会显著增加单页体积。上线前把主题配置项过一遍，把不认识的全关掉，比装优化插件管用。

5.2 站点地图、robots 与结构化数据

基础三件套，缺一不可：

站点地图（sitemap.xml），把所有文章地址列出来，告诉搜索引擎有哪些页面。大部分生成器有现成插件，一行配置就出来了。要注意的是它必须包含最终可访问的绝对地址，如果域名配错了，站点地图里全是错的链接，提交上去反而有害。

robots.txt，放在根目录，声明哪些可以抓、站点地图在哪。最简版本大概长这样：

User-agent: * Allow: / Sitemap: https://你的域名/sitemap.xml

canonical 标签，每篇文章声明自己的规范地址。这一条对防止重复收录特别重要，尤其是你同时存在www和非www、或者带不带结尾斜杠两种地址都能访问的时候。所有内链统一用一种形式，别一半带斜杠一半不带。

结构化数据这块，技术博客最值得加的是文章类型的数据（标题、作者、发布时间、修改时间、封面图）。加对了之后搜索结果里可能展示发布时间和缩略图，点击率会有肉眼可见的提升。但别乱加——把不是文章的页面标成文章、把发布时间写成未来时间，都会带来负面影响。社交分享卡片（分享到聊天工具时显示的那张预览图）也值得配一下，一张 1200×630 的封面图就够，成本很低。

5.3 收录异常时的逐层排查链路

文章发出去搜不到，这是最高频的问题。我的排查顺序是这样，基本能定位到九成情况：

第一层，确认页面能不能被抓。打开 robots.txt 看有没有不小心写了Disallow: /。这个错误极其常见，很多主题的默认配置里就带着一行屏蔽规则，本地看不出任何异常。同时看一眼页面源码里有没有noindex的 meta 标签，有些主题会把标签页、归档页默认设成不索引，如果你误把文章页也归类进去了，就永远搜不到。

第二层，确认页面在不在站点地图里。打开站点地图搜索你的文章标题，不在的话说明构建时被跳过了，最常见的原因是日期写成了未来时间，或者草稿标记忘了去掉。这条我在第 3 章提过，是真的高频。

第三层，确认规范地址指向哪里。打开页面源码，找 canonical 那一行，看看它指向的地址和你想收录的地址是不是同一个。如果指向了一个不存在的地址（比如域名写错、路径多了个斜杠），搜索引擎会认为这篇内容属于另一个页面，你这篇就永远进不了索引。

第四层，确认内容能被解析。如果你用了大量客户端渲染，抓取工具拿到的可能是个空壳。静态生成的站点一般没这个问题，但如果是组件框架型方案且没做预渲染，就要注意了。用抓取工具模拟看一下渲染后的 HTML 里有没有正文，是最直接的验证。

第五层，才是等。前面四层都确认没问题，那就只是时间问题。新站点从提交到被收录，几天到几周都正常。这时候该做的是去几个相关社区把文章发一下，让外链自然产生，比反复刷新搜索结果的效率高得多。

6. 上线之后：备份、迁移与长期维护

搭好只是开始。一个技术博客真正的成本在维护，而维护的痛点在两三年后集中爆发：依赖全部过时、主题作者弃坑、想换工具发现迁移成本高得离谱。

6.1 备份不等于"我推了 Git"

很多人的备份策略是"代码在仓库里，仓库在平台上，平台有备份"。这个链条有个明显缺口：你的内容不全在代码里。评论数据、访问统计、图片如果放在对象存储、订阅用户列表，这些都不在 Git 里。

我的做法是每月做一次导出，把三样东西打包存到本地和另一处：Markdown 源文件全集、图片目录、各个外部服务的配置导出。整个操作五分钟，但能救命。尤其是评论系统，很多第三方服务的免费额度用完会把数据锁住，等你发现的时候已经导不出来了。

还有一个容易忽略的点：备份要验证一次能恢复。我见过有人备份了三年，真出问题时发现压缩包是空的。每年挑一次，从备份里恢复一个测试站，跑一次构建，确认文章都在、图片都在、链接都对。

6.2 依赖腐化与主题魔改的代价

静态站点的依赖树通常不深，但有两类东西会随着时间腐烂：

主题。开源主题的作者维护热情往往只有一两年。你基于某个主题做了大量定制，两年后它不再更新，新的运行时版本不兼容，你就卡住了。我的应对方式是：能通过配置项改的绝不改源码，必须改的部分单独抽成一个覆盖层或自定义样式文件，这样将来换主题时，改动集中在一个文件里，重写成本可控。

插件和依赖。锁文件一定要提交，保证每次构建结果一致。同时给自己定一个节奏，比如每季度跑一次依赖升级，小版本直接升，大版本一次升一个，升完立刻构建+预览。我最惨的一次是把所有依赖一次性升到最新，构建报错十七处，排查了两天才逐个修完，从那以后再也不批量升级了。

运行时版本也要固定。配置文件里写死运行时的大版本号，别用latest。不然某一天平台默认版本更新，你的构建会突然挂掉，而你可能一个月都没推过代码，完全不知道发生了什么。

6.3 换生成器的迁移成本与最小化路径

说实话，绝大多数人不会换生成器，但如果哪天你想换，迁移成本主要来自三件事，提前预防能省掉大量时间：

URL 结构。这是最贵的。如果新旧方案的 URL 规则不一致，你需要为每篇老文章配一条 301 重定向。几百篇文章手写重定向表不现实，写个脚本从旧站点地图生成映射表，一次性搞定。所以从一开始就让 URL 结构尽量简单且与工具无关，比如"年份/slug"这种形式，大多数方案都能配出来。

front matter 字段名。不同方案对同一个概念叫法不同，摘要有的叫 summary，有的叫 description。写个脚本批量重写字段名就行，十分钟的事。

图片路径。如果你的图片引用写的是站点内的绝对路径，换域名或换目录结构会全裂。建议正文里统一用相对路径引用同目录下的图片，把所有资源放在和文章同级的位置，迁移时整个目录搬走就行，一个链接都不用改。

最后再说个小技巧，关于域名到期：把域名到期提醒设在到期前 90 天，而不是提前 7 天。域名过期之后有一个赎回期，费用通常是正常续费的十倍以上，而且期间站点会直接消失。我给自己所有重要域名都设了日历提醒，这不是强迫症，是真的有人因此丢掉过用了五年的域名。

7. 我的建议顺序：别把顺序搞反了

如果让我重新走一遍，顺序会是这样：先用最轻的方案把站点跑通，不为任何"以后可能会用到"的功能提前搭基建；写满五篇文章之后，再回头决定要不要绑定域名、要不要接评论、要不要做统计；等文章超过二十篇、开始有人从搜索进来，再认真处理性能和收录。

这个顺序背后的逻辑很简单：所有基建的价值，都建立在"你确实在写"这个前提上。没有内容，再快的构建速度也只是跑得快而已。我见过太多让人惋惜的站点，配置挑不出毛病，就是首页最新一篇停留在两年前。

真要给一句最实在的建议，那就是把第一篇写完发出去，哪怕格式丑一点、主题用的是默认的、域名还是平台给的二级域名。等你写到第十篇的时候，你会非常清楚地知道自己需要什么、不需要什么，那时候再回来改基建，改动量可能只有现在的一半，而且改的都是真正用得上的地方。