用户名.github.io 这个地址上；今天把自己的域名接上了，顺带配了 Cloudflare 的一整套东西。操作本身不复杂，值得记的是几个不照着文档走就会卡住的地方。
这是今天唯一花钱的部分，一年十来美元。
理由不是速度，也不是好看。个人站点相对平台的核心优势是复利——三年前的文章今天仍然在被搜到、被链接、被引用，而一条社交媒体动态四十八小时后就死了。但这条复利完全建立在 URL 稳定的前提上。
用户名.github.io 把你绑在了 GitHub 上。有了自己的域名之后，托管商、CDN、生成器将来都可以换，而那个地址可以跟着走。买的其实是可携带性，不是域名本身。
后缀我最后选了 .com。考虑过 .io，因为它在技术圈观感好，但查清楚之后放弃了：它原本是英属印度洋领地的国家代码域名，而该领地的主权状态正在变动。为一个要持有二十年的地址，去选一个后缀存续性存疑的域名，和买它的初衷相悖。
这是今天卡得最久的一步。
Cloudflare 的 DNS 记录有个代理开关，橙云表示流量经过 Cloudflare，灰云表示它只做解析、不碰流量。直觉上橙云功能更多，应该一开始就打开。
但打开之后，GitHub Pages 的 Enforce HTTPS 这个选项一直是灰的，提示域名未正确配置以支持 HTTPS。
原因是签发证书和使用证书是两回事。GitHub 要向 Let's Encrypt 申请证书，而 Let's Encrypt 不能随便发——否则任何人都能申请别人域名的证书。它要求申请者先证明控制权：在服务器上放一个特定文件，然后自己去访问 http://你的域名/某个路径，看能不能读到。
开着橙云时，这个验证请求到达的是 Cloudflare 的边缘节点，那里没有那个文件，验证失败。
所以正确顺序是：灰云 → 等证书签发 → 再改橙云。证书一旦到手就是一份存在服务器上的文件，使用它不需要任何外部验证，这时候 Cloudflare 插在中间毫无问题。
这个模式值得记住，它不只出现在这里：验证所有权需要直连，提供服务不需要。以后配邮箱域名验证、申请泛域名证书、接入某些第三方服务，大概率还会遇到"先把代理临时关掉"这种要求。
顺带两个相关的坑：
接 Cloudflare Web Analytics 时，我原本以为必须手动把那段 JS 写进模板，因为站点托管在 GitHub 而不是 Cloudflare 自己的产品上。实际上只要开了橙云代理就能自动注入，源站在哪不重要。
原理比结论有意思。橙云状态下 Cloudflare 不只是转发，它可以修改经过的响应内容：从 GitHub 拿到原始 HTML 之后，在 </body> 前插入信标脚本，再发给访客。
所以仓库里的文件从头到尾没变。git clone 下来搜不到那段脚本，浏览器查看源码却能看到——这两个"源码"根本不是同一份东西。
这也顺带解释了另一件事：如果响应头里有 Cache-Control: public, no-transform，注入会失败。no-transform 的字面意思就是禁止中间代理改写内容，Cloudflare 遵守它。
值得意识到的一点是：这个能力意味着 Cloudflare 能读到并修改所有经过的内容。对公开博客无所谓，但它不是一个被动的管道，而是一个有完全访问权的中间人。灰云时它是电话簿，橙云时它是代理人。
今天最有价值的收获不是某个具体配置，而是一个反复出现的模式。
试着把站点迁到 Cloudflare Pages 做备选方案时，构建失败了：
Invalid US-ASCII character "\xE2" on line 5
\xE2 是 UTF-8 里通用标点的首字节——破折号、弯引号这类字符。文件本身没问题，是构建容器的 locale 不是 UTF-8，Ruby 默认按 ASCII 读文件，遇到多字节字符就崩了。
加两条环境变量解决：
LANG=C.UTF-8
LC_ALL=C.UTF-8
用 C.UTF-8 而不是 en_US.UTF-8，因为前者在任何 glibc 系统上都存在，后者需要镜像里预先生成过。
关键在于，同一类问题今天已经是第三次出现：
三次之后它就不是偶然了。对写中文的人来说，任何新的执行环境都要先确认 locale 是 UTF-8，这应该是默认动作，不是出了问题再排查的事项。
配 Pages 时最开始进错了界面。Cloudflare 把 Workers 和 Pages 放在同一个菜单下，两者入口挨得很近。
识别方法：如果界面上出现「部署命令」并预填了 npx wrangler deploy，那是 Workers——用来部署 JavaScript 函数的。Pages 的界面上应该是「框架预设」「构建命令」「构建输出目录」这三栏。
静态站点要走 Pages。Jekyll 那几项填构建命令 bundle exec jekyll build、输出目录 _site，再加一条 RUBY_VERSION——这些和本地构建是一回事，《这个站点是怎么搭的》里写过。
域名所有权 Cloudflare Registrar
DNS 解析 Cloudflare
源码和版本 GitHub
构建和托管 GitHub Pages
CDN / HTTPS Cloudflare
访问统计 Cloudflare Web Analytics
三家产品拼在一起，各管一段。这也是为什么配置要在两个后台来回切——不是哪里搞错了，是架构本来如此。
值得说的是这个结构的可替换性：域名在自己名下、源码在 Git 历史里、内容是纯 Markdown。任何一层想换，改几处配置就能走，不会被锁死在谁手里。
这正是今天那十几美元买到的东西。
]]>第一件：我玩守望先锋。
第二件：游戏里那张以纽约为背景的地图，车站大厅那一段，一眼就能认出原型是中央车站（Grand Central Terminal）。我去实地看了一次，录了一段。
播放器加载不出来的话，直接去 B 站看。
]]>我个人非常在意工作流程的规范性，力求找到所有环节的最佳实践。
硕士期间我长期从事基于机器学习、神经网络模型的古文自动化处理工具的开发与评测，以及中国古代文献的知识组织和知识挖掘研究。过往的研究经历让我意识到，一个不规范的开始，往往使得后续的大量时间浪费在修补和纠正前期工作上。
所以我希望在这里分享大家好用的方法。这里也有我的一点私心：作为合作者，大家使用这些方法，省下的是自己的时间，也会间接地为我提供便利。
建这个站点还有另一方面的动机：想借它探索 AI 的创造力，以及美国互联网生态基础设施的可用性和可靠性。
]]>git push，GitHub 自动构建并发布。
暂时不做评论区。理由不是技术上做不到，而是我想先把写作本身跑顺。多媒体内容一律外链——视频挂在别的平台，大文件放 Releases，站点本身只有文字和少量压缩过的图片。这样加载快，也不会因为某个第三方服务停摆而坏掉。
正文用 Source Serif 4 配思源宋体系统，两者本是同一设计体系，中英混排时横竖笔画的粗细能对上。中文段落两端对齐，西文段落左对齐——汉字等宽，两端对齐不会出现西文那种断裂的空隙。
想订阅的话，页脚有 RSS。
下面是完整的搭建和日常维护记录。原先散在几个文档里，现在归到一处。
仓库命名。 新建一个公开仓库，名字必须严格是 你的用户名.github.io——用户名是 litao，仓库名就得是 litao.github.io。这是 GitHub 识别「个人主站」的唯一命名方式，差一个字符都不行。
上传文件。 把项目全部文件放进仓库根目录。网页上传走「Add file → Upload files」；命令行：
git init
git add .
git commit -m "初始站点"
git branch -M main
git remote add origin https://github.com/你的用户名/你的用户名.github.io.git
git push -u origin main
打开 Pages。 仓库 → Settings → Pages，三项设成：Source 选 Deploy from a branch，Branch 选 main，Folder 选 / (root)。保存后等一两分钟，https://你的用户名.github.io 就能访问了。
_config.yml 顶部那几个字段是唯一需要动的地方：
title / title_en——你的名字。两者相同时，英文那行会自动隐藏。tagline / tagline_en——首页正中的定位语，中英各一行。email——页脚的联系邮箱。url——https://你的用户名.github.io。然后把 about.md 里的占位内容换成自己的介绍。改完 _config.yml 要重新推送才生效。
文件命名。 在 _posts/ 下新建文件，名字必须是 年-月-日-英文短名.md。命名或日期格式不对，文章不会显示——这是最常见的「我明明推上去了怎么没有」的原因。
Front matter 模板：
---
title: "中文标题"
title_en: "English Title"
summary: "首页列表里显示的一两句话。可以不写。"
date: 2026-09-15
lang: zh
---
正文从这里开始。
lang 填 zh 或 en，填 zh 会自动两端对齐。
常用元素。 脚注是正文里写 [^标签]、文末写 [^标签]: 内容，序号和位置自动排；引用块行首加 >。
图片压成 WebP 放进 assets/img/，全宽图控制在 100KB 以内，压缩用 Squoosh 就够。引用方式：
视频不要上传进仓库，嵌一个播放器：
<div class="embed">
<iframe src="https://www.youtube-nocookie.com/embed/视频ID" title="标题" loading="lazy" allowfullscreen></iframe>
</div>
.embed 会保持 16:9 比例，loading="lazy" 减少首屏压力。讲稿 PDF、数据集这类大文件放 GitHub Releases 或 Zenodo，文章里外链引用。
西文正文是 Source Serif 4，中文用系统宋体（Mac 上通常是 Songti SC）。Windows 下宋体屏显偏细，把 _config.yml 里的
typeface: serif
改成 sans，中文就切到黑体（苹方 / 思源黑体 / 微软雅黑）。
本地预览是可选的，不预览直接推上去看效果也行。要在本地跑：
gem install bundler
bundle install
bundle exec jekyll serve
然后访问 http://localhost:4000。
仓库是公开的，源文件对所有人可见，别提交私人内容。更要紧的是：Git 删除文件不会抹掉历史记录，敏感内容一旦提交过，就可能长期可见——发现提交错了，改文件是不够的。
容量上，站点上限约 1GB，月流量软限制约 100GB，所以媒体一律外链。
插件目前只用 GitHub Pages 白名单内的三个（feed、sitemap、seo-tag），所以能原生构建；哪天需要白名单外的插件，就得改成 GitHub Actions 构建流程，这是个不小的切换。想加邮件订阅的话，在 _includes/footer.html 里放个表单就行，不影响现有结构。