这是「把自己部署到互联网上」系列的第 3 篇。
前两篇，我先回答了两个问题：2026 年，程序员还有没有必要搭个人博客？我为什么要做一个属于自己的技术品牌？
我的答案是：如果只是找地方发文章，不一定非要博客；但如果想长期建设自己的技术阵地，博客仍然有价值。技术品牌也不是包装自己，而是把真实做过的事、解决过的问题、形成的方法，整理成能被看见、能被验证的证据。
写到这里，下一个问题就来了：如果要开始建设自己的技术阵地，第一步到底该做什么？
这些词经常被混着用，但它们解决的问题并不一样。如果一开始没分清，后面很容易出现一种尴尬：网站搭好了，但自己也说...
这是「把自己部署到互联网上」系列的第 2 篇。
上一篇我讨论了一个问题：2026 年，程序员还有没有必要搭个人博客？我的答案是，如果只是找个地方发文章，不一定非要博客；但如果想长期建设自己的技术阵地，个人博客依然值得做。
这篇继续往前走一步，聊一个更底层的问题：我为什么决定做一个属于自己的技术品牌？
我说的技术品牌，不是把自己包装成某个厉害的 title，也不是做成功学式的个人 IP。更准确地说，它是一组长期可验证的记录：你做过哪些技术实践，解决过什么问题，形成过什么方法，持续关注什么方向。别人通过这些内容，能更稳定地理解你，而不是只通过简历上的几行字或一次面试来判断你。
穷人才知道的多，富人不需要知道那么多，扩容、加硬盘就完了（狗头）
这次服务器根分区 /dev/vda2 只有 40GB，已经用了 32GB，使用率到了 84%。这个状态要及时处理。系统盘一旦写满，后面的问题会很直接：数据库写不进去，日志无法记录，容器启动失败，应用也可能异常退出。
所以这次清理的思路不是上来就删文件，而是三步：先定位，再清理，最后防止它继续涨。
先看根目录下各目录的占用：
sudo du -xhd1 / 2>/dev/null | sort -hr
这里建议加 -x，避免 du 跨文件系统统计，导致结果和 df -h / 对不上。比如根...
这是「把自己部署到互联网上」系列的第一篇。
我准备用这个系列，完整记录一个普通程序员从 0 到 1 搭建个人博客、配置服务器、购买域名、完成备案、部署项目、接入 HTTPS、处理对象存储，最后把博客延伸成个人品牌入口的全过程。
在真正开始买服务器、配环境、写部署脚本之前，我想先回答一个现实的问题：
大模型都发展成这样了，程序员还有必要搭建个人博客吗？
毕竟现在能发内容的平台太多了。微信公众号、掘金、知乎、B 站、小红书、即刻、GitHub、知识星球，每个平台都能承载一部分技术表达。对于大多数程序员来说，写文章已经不一定非要有一个自己的网站。
那为什么还要折腾个人博客？
上两篇分别介绍了 Codex 和 Cursor 的安装和使用，最近试了一下 Cursor 和 Codex，主要是想看看它们在真实开发任务里的差异。
先声明，这不是一篇严格评测，也没有做完整 benchmark。
我的方式比较简单，在应用层面做了几个测试：准备两个空目录，给它们同样的任务，看它们怎么理解、怎么执行、最后产出的东西能不能直接用。
测评数据
CursorBench v3.1 里，Cursor 自家的 Composer 2.5 得分是 63.2%。Opus 4.7 在最高设置下是 64.8%，默认 xhigh 是 61.6%。GPT-5.5 默认成绩是 59.2%（数据来源于网...
写这个 Git 系列，一开始并不是想做一份“命令大全”。
因为 Git 命令真的太多了。
add、commit、branch、merge、rebase、reset、pull、fetch……如果一上来就背命令，新手很容易越学越乱。
但我后来发现，真正让人卡住的，往往不是某个命令本身，而是这些问题：
main 上开发？.gitignore 写了却不生效？所以这个系列真正想讲的，不只是 Git 怎么用，而是 Git 背后的开发...
最近1年，很多程序员开始把 Cursor 当成日常开发工具。
它看起来像 VS Code，但多了一层很强的 AI 能力：能补全代码、解释项目、修改文件、运行命令，甚至能像一个编码助手一样帮你完成一小段功能。
如果你第一次接触 Cursor，最容易困惑的不是“它强不强”，而是：
我装好之后，到底该怎么开始用？
这篇文章就从安装、配置、打开项目、第一次 AI 辅助写代码讲起，帮你把 Cursor 跑起来。
简单说，Cursor 是一个面向 AI 编程的代码编辑器。
你可以把它理解成：
VS Code 风格编辑器 + AI 补全 + AI Chat + Agen...很多刚进入团队开发的程序员，第一次听到 Pull Request，都会有点迷糊。
代码不是已经 git push 上去了吗？
为什么还要发 PR？
PR 是不是就是“提交代码”？
Reviewer 又到底在看什么？
一句话说清楚：
Pull Request 不是提交代码，而是请求团队审查并合并代码。
它真正解决的问题不是“代码怎么传上去”，而是“这段代码能不能进入主分支”。
Pull Request，简称 PR，中文常叫“拉取请求”或“合并请求”。
在 GitHub 里通常叫 Pull Request。
在 GitLab 里通常叫 Merge Request。
名字...
很多程序员第一次遇到 Git 冲突，心里都会一紧。
终端里突然出现：
CONFLICT
Automatic merge failed; fix conflicts and then commit the result.
再打开文件，看到一堆奇怪标记：
<<<<<<< HEAD
=======
>>>>>>> feature/login
一瞬间，仿佛项目已经失控。
但其实，Git 冲突并不是灾难。它只是在提醒你：
同一块代码，两边都改了，Git 不知道该听谁的，需要你来决定。
这篇文章我们不讲复杂理论，直接用实战方式讲清楚：冲突...
很多程序员第一次听到 git rebase，心里都会有点发怵。
因为它不像 git merge 那样直观。
Merge 像是“把两条分支合到一起”，而 Rebase 听起来像是在“重写历史”。
更可怕的是，你可能还听过一句劝告：
不懂 Rebase，千万别乱用。
这话没错，但也容易让人错过一个非常好用的工具。
Rebase 的核心价值其实很简单：让提交历史更干净。
如果你理解了它在做什么，就会发现它不是洪水猛兽，而是一个能让团队协作更清爽的 Git 神器。
rebase 直译是“重新设置基底”。
听起来有点...