天狼数字生命这个站点，从动念到上线骨架，前后不到一周。但要说”为什么这一周做出来”,得从更早一点说起。
我此前并没有维持自己博客的习惯。技术笔记散落在 Obsidian 库里、B 站直播的内容大纲里、几次半成品的 Notion page 里——这些都不是”对外发布”的姿态。直到把”长期维护”这件事真正想清楚，才决定从零搭一个能跑两年以上的站点。
这篇是建站手记的第一篇。后面会按主题陆续展开——具体的 Astro 6 / Tailwind 4 / Cloudflare Workers Static Assets / 五时段视觉系统等工程细节，都会有单独的文章。这篇只解释一件事：为什么是现在，为什么是这个组合。
为什么是这个时间点
副线项目最难的不是技术，是节奏。主线（明镜项目）持续吃掉每天的主要时间，副线如果没有”足够稳的工程基线”，就会变成”今天忙完明天再说”——然后无限拖延。
选择 2026 年 5 月这个时间点动手，有几个外部条件刚好凑齐：
- Astro 6 stable 已发布两个月——content collections 重写、Vite 7、Astro Fonts API self-hosting、CSP API 都进入 stable。早做会踩 6.0 RC 的坑，晚做会被 7.0 的预告打断节奏。
- Cloudflare 已经把 Astro 收编（2026-01-16 收购 Astro Technology Company）。从此 Astro + CF 是”一等公民”组合，不需要担心未来某天 Astro 转向其他云。
- Tailwind 4 的 CSS-first 配置已经稳定。
@theme指令把”两层 token 模型”做得天然契合，比 Tailwind 3 的 JS 配置文件清爽。 - **LXGW WenKai（霞鹜文楷）**通过 fontsource 包正式可用。这是我能想到的、最适合”环境插画治愈风”的中文字体——温润、有书写感、不甜不腻。
这些条件都满足之前，硬上一个站点，半年就会被迫重构。
选 Astro 而不是 Hexo 或 Hugo
我评估过的候选不少：Hexo / Hugo / VitePress / Gatsby / Next.js (SSG) / Astro。
Hexo 在国内独立博客圈是默认选择，模板生态丰富，但是模板语法（EJS / Pug）绑得太死，自定义组件成本高。Hugo 极快但 Go 模板对前端不友好，组件化弱。VitePress 是文档站气质，博客元素不足。Gatsby 的 GraphQL 重型方案在 2026 年已经不是主流。Next.js SSG 模式对一个静态博客来说过于重——App Router 在 V14 之后还在演化，副线项目背不起这种持续迁移成本。
最终选 Astro，三个核心理由：
- content collections 是为这种”内容驱动 + 类型安全”项目原生设计的——markdown frontmatter 配 Zod schema，编译期就能挑出字段错误。
- 默认零 JS hydration，性能基线天然高。我可以按需用
<script>块挂客户端逻辑（时段切换 / 粒子层 / 目录跟随高亮），不必为整页 React 付出代价。 - 组件库灵活。未来如果真有重交互需求（V1 用 vanilla TS 顶不住时），可以平滑接 SolidJS / Vue / Preact——不需要换框架。
副带的”sphere 主题”我评估过，最终选择不 fork、不复制源码，只参照它的结构思路在干净 Astro 6 项目里重写。这背后有一个完整的 ADR（架构决策记录），未来会单独写一篇。
Cloudflare Workers 才是新基线
最初的部署计划是 Cloudflare Pages。M-A 阶段我把 Pages 的整套配置文档都写好了。但是动手前两小时主动搜了一下生态变化，发现 2026 年 Cloudflare 已经把 Pages “fold” 进 Workers——新项目推荐用 Workers Static Assets（绑 wrangler.toml 部署），Pages 进入维护模式。
这种事最怕”按训练数据假设当前主流”。所以在动手前主动联网校验，是工程纪律里最便宜也最有价值的一步。
切换到 Workers Static Assets 后：
- 静态资源走 Workers Static Assets，性能与 Pages 几乎一致；
- 未来如果要加边缘函数（彩蛋系统 / 国内访问优化代理），不需要再做平台迁移；
wrangler.toml把”部署配置”沉淀为项目根的一个文件，CODEOWNERS 守护好就行。
代价是：第一次 push 会触发 Workers Builds 构建，build 步骤还没有 dependencies 安装完成时会预期 fail 一次。这是 P0 阶段的”清晰预期 fail”，比”模糊的成功”信号强。
环境插画治愈风 ≠ 普通博客模板
零度博客类站点（IT 领域常见的、技术博客的”基准模型”）有一个共同问题：它们的视觉气质是冷的。代码块、技术列表、纯文字段落组成的”硬阅读体验”，长期看是消耗的。
天狼想做的事情是把这件事变软。环境插画治愈风作为视觉母体——画的是早晨阳光里的窗台、午后木地板上的咖啡、黄昏走廊上的影子，不是流星雨夜空、不是赛博朋克霓虹、不是极简白底。
这套审美决策的源头是博士长期沉淀的”个人化风格画像 v0.1”，包含两份外部 md（理论基础 + 复现手册），明确锁定 10 个色卡 hex 值 + 5 个核心组件协议 + 快速自检清单 10 条。
代码层面，这套审美变成两层 token 模型——底层 10 个 base color（永不漂移）+ 6 个语义槽（按时段切换）。Tailwind 4 的 @theme 指令让这套结构在 CSS 文件里直接写完，不再需要 JavaScript 配置文件。
五时段是设计骨架，不是装饰
如果只是”加一个 dark mode 切换”，那是装饰；如果按本地时间在五个时段（清晨 / 白昼 / 黄昏 / 入夜 / 深夜）切换整套视觉系统——配色 + 插画 + 粒子层 + Hero 叠层——那就是骨架。
骨架是说：每个 UI 决策都要在 5 个时段下都成立。不能”白昼好看，深夜将就一下”。这逼着设计在每个组件 level 都把对比度、可读性、视觉层次想清楚。
V1.0 上线时五时段是按本地时间自动切换 + 顶部 5 图标手动切换器（cookie 持久化偏好）。后续 V1.5 会加季节装饰层（粒子配置按春夏秋冬切换），V2.0 加八节气彩蛋。这是个会持续生长的系统，不是一次性产物。
一个具体的小例子：text-on-accent
夜深时段（深夜青墨）accent 是深蓝灰，按钮上配白字 OK；但清晨时段（雾湿青白）accent 是浅蓝，按钮上的白字就完全看不清。
解决办法不是”白字硬扛”也不是”为每个按钮单独加颜色”——而是在 token 体系里加一个第 7 槽 --tlife-text-on-accent，5 个时段各自定义。dawn / dusk 用深字、night / midnight 用白字、day 用深灰字。这样所有按钮无脑用同一个 CSS 变量，渲染时自动按时段对齐。
这种”token 设计→可读性问题→token 体系扩展”的循环，是五时段视觉系统不断成熟的过程。
接下来三个月做什么
M-A 阶段（站点骨架）已经接近闭环。M-B（视觉系统初稿）会用 AI 出图工具（Codex gpt-image-2）生产 5 张时段 hero 插画 + 5 套粒子配置，把”占位实现”换成真正的视觉。M-C 是 V1.0 公开发布——五时段全量上线 + Pagefind 搜索 + RSS feed + 标签聚合页全部就位。
V1.0 上线后切换到 M-D 内容稳定运营——每周 2-3 篇技术文章 + 工具矩阵卡片陆续录入。预计上线后 2-3 个月做 V1.5（季节装饰层 + 国内访问优化），6-12 个月做 V2.0（八节气彩蛋系统 + 商业实体注册）。
这是个慢生长的项目。不追求每天更新，不上 SEO 黑帽，不挂广告联盟搞流量套路。对得起读者花的时间 是唯一的内容标准。
如果你看到这里——欢迎进站。后面会陆续把这些”建站手记”写完，把”为什么这么选”的每一步沉淀下来。