生活好像总会给你开点小玩笑，哈哈哈……

今天坐地铁上班的时候，在转线下行地铁的过程中，鞋带卡扶梯了。

尝试自己去解决，无奈解决不了，地铁工作人员看到马上过来给我解决了，过程虽然显得有点狼狈：

卡住—尝试自己拔出—未果—脱鞋—站一旁—协助—解决

哈哈哈😁，虽然没有被拍下来，但是自己生成了一张用ai的图片，还挺像……

今天分享的主题相关的内容是关于一个IT基础设施的建设，一个公司，一个系统的正常运转离不开软硬件和天时地利人和同时发挥的作用。

今天的主题让我认识到了基础建设的重要性，和一些相关的知识和关于基础建设的一些词语，比如server,rack server,storage,switch,firewall……其实印象比较深的两句话是please don’t not throw sausage,pizza away.和bulid for today,be reader for tomorrow.

Thinking

其中第一句话是关于osi，开放系统互连参考模型的七层，open systems interconnection reference model,其实我之前没怎么记住，但是呢，这次的分享让我巧记了，物理层-链路层-网络层-网络层-传输层-会话层-展示层-应用层。

虽然自己是数据科学与大数据技术专业，但是其实自己并没有很了解这个方面。

这也是自己需要补的地方。

学习不知专业知识，更有，soft skills，我们玩了三个小游戏，一个是关于团队合作，第二个关于一个银行系统的子系统重要性排序，还有一个就是动态规划。

TeamWork

一个团队中，我们是否需要认真思考一下我们的职责呢？答案是肯定的。

每个人在一个团队都有自己的职责，主要是你是这个team的leader呢还是队员，不同位置有不同的职责，首先我们明确自身职责，接受上级指令，有的人在行动，有的人在白嫖，无法避免，但是可以团队协作，至少要说出来。

其次，其实作为一个甲乙方来说，甲方是提需求的，乙方是完成需求的，那我们是不是应该需要首先完成需求呢？效果是乙方实现的，我们不能总问甲方这步这么做，那一步怎么做。

同理，在工作中也是这样，领导给我们发派任务，我们总不能每一步都向老板询问吧！类比当下，其实很多人他不关注过程，它只关注结果，但我们自己需要对自己的过程负责，产出的效果是由自己过程去实现的，但是没有人会关注你的过程，所言：成功的人说什么都是对的，但是你没有成功，你说话的全权威性就大打折扣。

蓝图画出来，但是需要具体的思考具体的行动去行动，要自己去探索。

Emergency

你需要做的事有各种状态，我记得有一个四象限介绍了这个，重要紧急，重要不紧急，不重要紧急，不重要不紧急。

日常生活亦是如此，作为一个主题，如何执行我们的人物也是根据我们的事情需要完成的状态去执行的。

在第二个游戏中，对一个系统的子系统重要性排序，可能我自己也没怎么思考，也没结合实际考虑，最终我们的排序做错了好几个，好像没几个是对的。

一个东西的重要性似乎不单纯的取决于单个因素，而是需要多个角度，多个因素去考虑，比如说一个app 应用层面是否可以是暂停呢？答案给我们的似乎是不可以，舆论因素也是一个重要的因素！

在执行某件事的时候，我们下意识的以自己仅有的薄弱认知去理解，但是很难做到尽善尽美，最近我看到有一句话这样说“不要重复造轮子”.

感觉挺对，我们可以在已有的成果上去发挥，所言“站在巨人的肩膀上去看世界”，

其实：这个世界上你所遇到的问题，很多人早就遇到了。

Allocation

第三个游戏是关于资源分配的，一个小岛如何建设以增加岛上人口，如何应对紧急危险的事故？如何达到在风险可控的失效效益最大化？

延伸一下，这是一个永久的命题。

这需要我们考虑发展与平衡风险，还有结合各种实际问题。

站在不同的角度有不同的看法，也会产生不一样的执行方案，似乎没有对错。

实际上我们也无法预估所有可能的风险，只能说将我们的风险降低，把发展机会变大。

但是在面对风险的时候我们自己需要一个plan b,或者plan n.

Build-Ready

关于这个话题是我最想说的，也是这次演讲印象最深的一句话

如何build?如何ready？这也是一个这个深思的问题

我其实自己曾经想过一个问题：我应该如何改变现状？如何成为那个可以被人家依靠的人，但似乎现在还没答案。

现在想法是先于行动了，实际行动没完全落实哈……

有时候发现自己挺懒惰的

思想上的巨人行动上的矮子！！！

但又很庆幸自己一步一步再尝试，虽然很慢很慢，但是似乎是向上的

有人会跟你说，你处于这个阶段，这个年龄你就该干什么就该怎么干，你的人生就应该在特定的时间去完成某些事情，比如说，成家立业，让老一辈抱孙子什么之类的，但是说实话，20几岁的年纪，有什么资本去谈论这些？主要也是确实没钱。又会有人跟你说了，你先成家再立业，这样你就有压力去赚钱了……我在想真的吗？

如果让你抉择你会怎么做？

先去沉淀呢？还是赶急赶忙的完成某些的人生大事？

对于我自己来说我也不知道怎么做……

现在的我20多岁出头，似乎是人生的一个小起点，刚出来实习，没钱，没背景没有殷实的家底，也不能让家里人给我爆点金币，哈哈哈……怎么能现阶段实现我的人生的事呢？

还是需要自己去“觉醒”，也不知道自己什么时候能真正的觉醒，现在在尝试阶段吧！

bulid

这是一个需要用长期注意去发展，去看待的问题，从学习之路来看，从小学，初中，高中，大学，到目前实习的阶段，我似乎都是在不断提升自己的认知，从开始的狂妄自大到后面的知道天外有天人外有人，这始终告诉我：

世界上总有人比你厉害，总有人比你努力，但是你至少要知道自己比以往进步一点点，缓慢进步，哪怕很慢

给自己打点鸡血：道路是曲折的，前途是光明的

但是要行动要行动要行动，某些事情你拖太久了，哈哈哈😁

ready

结合起来，其实就是一句话：种一棵树🌲最好的时间是十年前，其次是当下。

明天会怎么变化你无法预估，但是今天至少可以把握，像今天分享的主题一样，没有IT强大的基础设施的建立又怎么会拥有今天强大的互联网呢？

尚且看众大咖，马云，马化腾，马斯克，黄仁勋等等，虽然我远远不能跟他们相提并论，他们也是天选之子，但是我至少有个小目标，改善自己成为那个自己想要成为的人，step by step。

宏大来看：危机事情的发生需要ready方案去解决，对于个人来说，没有坚实的基础，后来所创建的高楼大厦也会因根基不稳而倒塌。

现在我需要的是：至少学会把自己的根据变得稳一点，慢慢提高自己的认知，才能在某些地方站得住跟脚。

我现在最应该要做的就是:

build for today ，be ready for tomorrow

前一晚想给电瓶车充电，很不幸，没地方充电，侥幸心理，想着够电今天上下班。

没想到不够，上班半路没电了，下班推着车回来，还用脚蹬！！！

现在还有不少地方要慢慢调整，不过页面真正出现在眼前时，还是挺开心的。之前一直想做的事，总算真正开始了。

先把这一刻记下来。以后继续改，也继续写。

上线前需要准备什么

• 一个能够正常构建或直接打开的静态网站
• 一个 GitHub 仓库
• 一个 Cloudflare 账号
• 一个可以修改 DNS 记录的域名

先确认项目的发布目录。纯 HTML 项目可能直接发布仓库根目录；Astro、Vite 等项目通常需要执行构建命令，再发布 dist。目录填错时，部署可能显示成功，打开后却没有目标页面。

理清两条链路

部署时，代码沿着下面的方向流动。

本地项目 → GitHub 仓库 → Cloudflare Pages → 线上文件

访客打开网站时，浏览器走的是另一条路。

浏览器 → DNS 查询 → Cloudflare Pages → HTTPS 响应 → 页面渲染

这两条链路分开以后，排错会简单很多。Pages 提供的 pages.dev 地址异常，应先检查代码、构建命令和输出目录。pages.dev 正常而自定义域名异常，检查范围就能收窄到 DNS、域名验证和证书。

连接 GitHub 与 Pages

先把网站推送到 GitHub，并确定用于生产发布的分支。随后在 Cloudflare Pages 中导入仓库，填写生产分支、构建命令和输出目录。

常见配置如下。

首次部署完成后，先打开平台生成的 *.pages.dev 地址。确认状态码、页面标题、样式和主要交互均正常，再继续绑定域名。

curl -I https://项目名.pages.dev/

预期结果包含成功的 HTTP 状态码和正确的内容类型。浏览器检查仍然不可省略，因为 curl -I 看不到布局和前端交互。

绑定自定义域名

在 Pages 项目中添加自定义域名。若域名的权威 DNS 仍由其他服务商管理，需要在该服务商处增加 CNAME。

类型  CNAME
名称  knowledge
目标  项目名.pages.dev.

部分 DNS 控制台会自动处理目标末尾的点，部分控制台会把没有末尾点的目标当成相对域名。保存后要检查最终记录，确保目标没有被拼成下面这种形式。

项目名.pages.dev.你的域名.

可以通过公共 DNS 查询验证记录。

curl -fsS \
  'https://dns.google/resolve?name=你的完整域名&type=CNAME'

DNS 返回正确结果后，等待 Pages 将自定义域名标记为可用，并确认 HTTPS 已生效。DNS 缓存受 TTL 影响，刚修改记录时，不同网络可能在一段时间内得到不同结果。

按层验收

按固定顺序检查，可以避免同时追查多个无关问题。

本地构建
   ↓
GitHub 生产分支
   ↓
Pages 临时域名
   ↓
公共 DNS
   ↓
自定义域名与 HTTPS
   ↓
页面内容

1. 本地构建成功，预览页面正常。
2. GitHub 的生产分支包含目标提交。
3. pages.dev 地址能够返回目标页面。
4. 公共 DNS 返回正确的 CNAME。
5. Pages 中的自定义域名处于可用状态。
6. 正式域名通过 HTTPS 返回目标页面。

curl -I https://项目名.pages.dev/
curl -I https://你的完整域名/

curl -sS https://你的完整域名/ \
  | rg -o '<title>[^<]+</title>' \
  | head -1

最后一条命令可以确认服务器返回的页面标题，避免只看到 200 就误以为内容已经更新。

常见故障

pages.dev 无法访问

查看 Pages 的部署日志，核对生产分支、构建命令和输出目录。纯静态项目不需要虚构一套构建流程，有构建工具的项目则必须发布生成后的目录。

自定义域名无法访问

先确认 pages.dev 正常，再查询公共 DNS。CNAME 目标错误、记录尚未传播或 Pages 域名验证失败，都只影响自定义域名这一段。

CNAME 被追加当前域名

DNS 服务商把目标识别成了相对域名。按照该服务商的规则，将目标改为完整域名，必要时补上末尾的 .，保存后重新查询公共 DNS。

Pages 一直显示域名验证失败

先保证公共 DNS 已经返回正确记录，再重试验证。若控制台保留了旧的失败任务，可以移除失败的域名绑定后重新添加。删除绑定前保留正确的 DNS 记录，避免再次引入变量。

GitHub CLI 登录出现网络错误

检查终端中的代理变量和本机代理端口是否一致。代理变量存在，但对应程序没有运行时，请求也会失败。

env | rg -i '^(http|https|all)_proxy='
ss -lntup
gh auth status

日常发布与恢复

网站上线后，不需要每次重新配置域名。日常更新完成本地验证、提交和推送后，生产分支会触发下一次 Pages 部署。

git status --short --branch
npm run build
git diff --check
git add 计划发布的文件
git commit -m "Update website content"
git push

具体的分支安排、Preview 验收和回滚方法见《用 Git 维护个人网站》。部署侧继续确认生产部署对应目标提交，并检查临时域名、正式域名和页面内容。域名、Pages 项目或平台目标没有变化时，不要改动 DNS。

同步 main
   ↓
本地修改 → 自动检查 → 提交开发分支 → Preview 验收
                                      ↓
                                  合并 main
                                      ↓
                                  正式部署

每个箭头都对应一次可以验证的状态变化。Git 状态确认分支是否放对，自动检查确认网站能否交付，Preview 负责检查真实部署，main 只负责发布。

本文使用这个网站当前的分支安排。

main                  生产分支，对应正式网站
v3                    当前开发分支
feat/*                新功能分支
fix/*                 修复分支

如果你正在使用 feat/* 或 fix/*，把后文命令里的 v3 换成实际分支名即可。

开始修改前先把分支放对

进入项目，切换到开发分支，再看一眼工作区状态。

cd ~/Projects/knowledge-site
git switch v3
git status --short --branch
git fetch origin

git status --short --branch 会显示当前分支，也会列出尚未提交的文件。这里值得停几秒， 确认自己没有带着上一次留下的修改开始新工作。

git fetch origin 只更新远程分支信息，不会改动当前文件。远程 main 如果已有新提交， 可以把最新的生产版本接到开发分支上。

git rebase origin/main

rebase 没有冲突时会直接结束。出现冲突后，打开 Git 标出的文件，处理冲突内容，再继续。

git add 冲突文件
git rebase --continue

如果发现这次 rebase 不该继续，可以回到开始前的状态。

git rebase --abort

在本地运行网站

本地需要 Node.js 22 或更高版本。完整检查还会用到 Deno 2。第一次拉取项目时，先按 锁文件安装依赖。

npm ci

平时启动开发服务器只需要运行下面的命令。

npm run dev

浏览器访问 http://localhost:4321/。改了布局或交互以后，桌面和移动端都要看一遍。 开发页面能打开，只能说明本地服务器正常运行。类型、构建和站内链接还要交给提交前检查。

需要查看生产构建的结果时，先构建，再启动本地预览。

npm run build
npm run preview

提交前检查网站

这个项目把常用检查收进了一个命令。

npm run verify

它会检查格式、脚本语法、Astro 类型和生产构建，还会核对站内链接、搜索索引、草稿排除、 文章元数据、RSS、sitemap、robots、CSS 资源引用、标签 slug 冲突和 Git 空白字符。 看到命令成功结束，才能确认这次修改通过了项目现有的自动检查。

需要单独定位问题时，可以拆开运行。

npm run format:check
npm run check:scripts
npm run build
npm run validate:site
git diff --check

测试通过以后，再检查自己准备提交的内容。

git status --short
git diff

暂存文件以后，还可以查看最终将进入提交的差异。

git diff --staged

这一步主要防止误加 dist/、.env、私人日记、公司资料和临时文件。自动检查关心网站能否 正常构建，提交者仍要判断每个文件是否应该公开。

提交并推送开发分支

确认差异以后，把修改提交到 v3。

git add .
git status --short
git commit -m "Update website content"
git push origin v3

git add . 会暂存当前目录下的全部改动，所以紧接着再看一次状态很有必要。提交说明应当写清 这次做了什么，例如 Update Git operations guide，以后查历史会省事很多。

这个项目的本地 v3 以上游 origin/main 为比较基准。推送时显式写出 origin v3， 可以保留这项设置。功能分支也应当写出实际分支名。

git push origin feat/分支名

推送以后，仓库里的 GitHub Actions 会安装依赖并重新运行 npm run verify。这项检查会 在 Pull Request 和非 main 分支的推送上触发。本地通过以后，仍要确认远程检查成功。

在 Preview 中检查真实页面

推送 v3、feat/* 或 fix/* 后，Cloudflare Pages 会生成 Preview Deployment。它比本地 开发服务器更接近实际部署环境，也适合在发布前分享给别人检查。

至少打开这些页面。

/
/learn/
/blog/
/notes/
/chatter/
/about/
/search/
/tags/
/timeline/
/404.html

再打开一篇文章，检查正文、标签链接、搜索、主题切换和移动端导航。页面或路由有改动时， 还要确认构建输出、搜索索引、sitemap 和 robots 是否符合预期。

首页
 ├─ 导航与最近更新
 ├─ 栏目页
 │   ├─ 文章列表
 │   └─ 筛选与空状态
 ├─ 文章页
 │   ├─ 正文与目录
 │   └─ 标签与返回按钮
 └─ 辅助入口
     ├─ 搜索与标签
     ├─ 时间线
     └─ 404

把确认过的版本发布到 main

推荐在 GitHub 创建一个从 v3 到 main 的 Pull Request。自动检查通过，Preview 也确认 无误以后，再合并 Pull Request。main 收到新提交后，Cloudflare Pages 会自动部署正式网站。

确定需要从本地直接发布时，可以运行。

git fetch origin main
git push origin v3:main

直接推送少了 Pull Request 提供的检查记录和合并确认，更适合你已经明确核对过分支差异的 情况。GitHub Actions 的 push 检查排除了 main，所以直接发布前要确认本地 npm run verify 和开发分支最近一次远程检查都已通过。

线上出错时怎样回滚

优先使用 git revert。它会创建一个抵消旧改动的新提交，原来的提交记录仍然保留，出了 问题也容易继续追查。

git switch main
git pull --ff-only origin main
git log --oneline --decorate -20
git revert 提交号
npm run verify
git push origin main

Cloudflare Pages 收到这个新提交后会重新部署。你也可以在 Cloudflare Pages 的 Deployments 页面选择以前成功的生产部署并执行 Rollback。页面回滚能较快恢复网站，之后 仍建议在 Git 里补上对应的修复提交，让仓库记录与线上状态重新一致。

线上恢复以后，把 main 的新提交接回开发分支。

git switch v3
git rebase origin/main

改错文件时怎样恢复

恢复以前先看这个文件改了什么。

git diff -- 文件路径

丢弃尚未提交的修改，可以运行。

git restore 文件路径

文件已经暂存，但你想保留本地修改，只把它移出暂存区，可以运行。

git restore --staged 文件路径

需要取回旧提交里的单个文件，可以指定提交号。

git restore --source 提交号 -- 文件路径

这些命令处理的对象不同。执行前确认文件路径和当前差异，尤其要留意 git restore 文件路径 会丢弃该文件尚未提交的修改。

覆盖远程 main 前再确认一次

只有确认远程 main 上独有的提交可以舍弃时，才考虑改写它的历史。先比较开发分支与远程 生产分支。

git fetch origin main
git log --oneline --left-right v3...origin/main

确认差异以后，使用带租约检查的强制推送。

git push --force-with-lease origin v3:main

不要把它换成普通的 --force。--force-with-lease 会在远程分支已经被别人更新时拒绝 覆盖，能挡住一部分误操作。它仍然会改写历史，不能代替发布前的人工确认。

一次完整的日常操作

熟悉各步骤以后，日常流程可以收拢成下面这组命令。

cd ~/Projects/knowledge-site
git switch v3
git status --short --branch
git fetch origin
npm ci
npm run verify
git add .
git status --short
git commit -m "Update website"
git push origin v3

推送完成后查看 Cloudflare Preview。确认页面无误，再通过 Pull Request 合并到 main。 本地检查、远程预览和正式发布各解决一类问题，把这三处都走完，一次网站更新才算结束。

开始工作      switch → status → fetch → rebase
本地检查      dev → verify → diff
提交预览      add → diff --staged → commit → push
正式发布      Actions → Preview → Pull Request → main
故障恢复      定位提交 → revert → verify → push