现在这个站点能正常访问了。但它不是一次写完的 —— 中间返工过几轮，也踩了几个回头看很明显的坑。这篇把过程记下来：一是给自己留个存档，二是如果你也在搭个人站，能少走两段弯路。
一、先想清楚这个站是干什么的
个人站最容易犯的错是"什么都想放"。一开始我的想法是把技术沉淀、项目、文章、联系方式全塞进首页。真动手才发现，关键不是"放什么"，而是"每块内容服务于什么"。最后定成三个板块，职责分得很清：
专题：系统化的学习路径，按章节组织，一篇一篇往下读；
博客：时间流，记录单点问题和过程复盘；
产品：能直接打开或下载的东西，是资产的积累，也是能力的证据。
这三个定位一旦分清，后面的页面结构、数据结构、导航顺序都顺了。
二、技术栈：先看约束，再看喜好
约束是「一个人维护，还要能长期改」。所以选型只看三条：改起来快、部署简单、出问题好排查。最后定下来的是：
前台：HTML + Tailwind + 原生 JavaScript，不引入构建工具 —— 改完刷新就能看效果，不用等打包；
后台：FastAPI（Python），同一套代码既提供接口、又提供管理界面；
数据库：MySQL —— 内容、分组、标签都放在里面；
部署：一台服务器 + Nginx 反向代理 + HTTPS。
这套组合里没有"先进"的东西，但一个人维护够用了：遇到问题基本能靠日志和浏览器直接定位。
三、内容驱动：让结构跟着内容走
最初我把"专题"和"博客"当成两套独立的东西，各写一套增删改查。做到一半发现重复太多，于是抽出一套统一的「文件夹树」：
内容（专题章节、博客文章）挂在 content 模块的文件夹树下；
项目挂在 project 模块的文件夹树下；
分组、排序、公开/私密，都用同一套逻辑。
省下来的不只是代码量 —— 后台的交互也统一了，不用在两套界面之间来回切。
四、上线：真正的成本在"来回几次"
写功能本身花的时间不多，反复调整的都是细节：
前台有缓存：改了前端资源要处理版本号，否则拿到的还是旧页面；
本地改完内容，线上不会自动变：数据在数据库里，中间漏了一次同步，排查了好一会儿；
部署尽量脚本化：比手动传文件稳，而且部署完顺手验一下服务状态，能第一时间发现问题。
这几件事都不难，但每一件都值得固化成流程，不然下次还会踩一遍。
五、V1.0 现在是什么状态
不急着"填满"，先把结构和流程跑顺，后面加内容才不别扭。目前：
专题：第一个专题（iOS 开发）的基础篇已上线，按章节持续更新；
博客：从这篇开始按节奏更新，记录过程和技术点；
产品：还没放 —— 等第一个真正能用的东西做完再上。
感受
回头做这件事，最大的体会是：个人站的难点不在写页面，而在"先把要放什么想清楚"。一开始我急着写代码，结果内容分类改了两次，页面结构也跟着返工。
如果重来一次，我会先花半天把"三个板块各自服务什么"写成一页纸，再动手写第一行代码。
相关推荐
专题：iOS 开发：从 0 到上架（正在更新）。后续会写技术栈选型、部署脚本怎么写、内容同步里踩过的坑。