先说结论：这是一个纯静态站。写 Markdown，npm run build，上传 dist/。没有数据库，没有后台，没有运行时框架。

一、图片

放在哪里

assets/images/        站内零散图片（头像、封面、首页大图、友链头像）
assets/gallery/full/      相册原图
assets/gallery/preview/   相册预览（列表用）
assets/gallery/thumbs/    相册缩略图（网格用）

assets/ 会被整目录复制进 dist/，所以路径就是它们未来的 URL。

文章里怎么引用

写相对路径就行，不用带 images/：

![温室里的两只](greenhouse.webp)

构建时会做两件事：

1. 补全成 images/greenhouse.webp（已经写了 images/ 或以 /、http(s) 开头的原样保留）；
2. 读出真实宽高写进 width/height，再挂上 loading="lazy" —— 这是这个站几乎不抖的原因。

能读尺寸的格式：PNG、JPEG、WebP。SVG 和 GIF 读不到，会退化成没有尺寸（可能抖一下），建议别放正文。

封面

cover: greenhouse.webp

cover 会出现在首页置顶卡和文章页顶部。同样只写文件名。

相册

相册不走 Markdown，走数据：data/gallery.json。

{
  "slug": "greenhouse",
  "title": "温室里的两只",
  "desc": "向日葵开满的那个下午。",
  "alt": "两只小兽依偎在花丛中",
  "date": "2026-09-18",
  "width": 1600,
  "height": 901,
  "tags": ["插画"],
  "license": "CC BY-NC-SA 4.0",
  "meta": [["尺寸", "1600 × 901"], ["格式", "WebP"]]
}

三档图按 <slug>.webp 命名放在三个目录下；src / preview / thumb 不写时按约定拼。 相册页支持双击、回车、触控打开灯箱，左右键切换，打开时会预取相邻两张。

图片的缺陷，先讲清楚

自定义壁纸

最底层那张背景默认是内置渐变。想换成图片，改 site.json：

"canvas": {
  "wallpaper": "images/hero-1600.webp",
  "veil": 0
}

• 路径相对 assets/，不用写 assets/ 本身；构建时会按页面深度补前缀，子页面也不会断。
• 留空就用渐变壁纸。
• 设了图片会自动压一层底色（亮色白纱、暗色黑纱），避免正文直接压在照片纹理上。
• 文件找不到时构建会打印一行提示并忽略，不会产出 404。
• 壁纸层同时是玻璃窗口的折射源，换成图片后折射会跟着换。

背景里那三个飘动的光团（.bubble）是纯装饰：位置、时长在 assets/style.css 里，关掉不影响任何功能。

二、Markdown 支持到什么程度

渲染器是 markdown-it 加几个插件，再补一层 Obsidian 方言。支持：

• 基础：标题、段落、粗斜体、行内代码、围栏代码块（带语言 class）、引用、有序/无序/嵌套列表、链接、图片、分隔线
• 表格：带 :---: 对齐，外面自动包一层 .table-wrap（窄屏横向滚动）
• 删除线 ~~删~~、高亮 ==亮==
• 任务列表 - [ ] / - [x]：真 checkbox（禁用态），勾选的自动划线
• 脚注 文字[^1] + [^1]: 内容：正文上标、文末「脚注」区、双向锚点
• callout：> [!note] 标题，类型有 note / info / tip / warning / danger / success / example / quote / fail / bug / important，另有 abstract、summary、tldr、todo、hint、question、help、faq、caution、attention、check、done、failure、missing、error、cite 这些别名
• 内链 [[某个标题]] 或 [[某个标题|别名]]：如果指的是本文里的标题，会变成锚点跳转；指不到就渲染成斜体虚线标记，并在构建时提示
• 注释 ``
• 外链自动加 target="_blank" rel="noopener noreferrer"

标题的两条规矩

1. 文档里最浅的那一级标题对齐到 h2，其余保持相对层级。所以整篇只用 # 写也不会有两个 h1。
2. id 由标题文字生成（中文也保留），重复的自动加 -1。目录、锚点、内链都靠它。

中文软换行

源码里在句子中间换行，中文之间不会多出空格；中英之间保留一个空格。

Markdown 的缺陷

三、新增一篇文章

1. 在 content/posts/ 新建 <slug>.md，文件名就是 URL：content/posts/hello.md → /posts/hello/。
2. 写 frontmatter：

---
title: 标题
date: 2026-11-04        # 2026-11-4 也认
tags: [design, css]
summary: 一句话摘要      # 不写就取正文首段前 96 字
cover: cover.webp       # 可选
draft: false            # 可选，true 时不生成
---

3. 正文随便写，图片放 assets/images/。
4. npm run build。

首页、文章列表、归档、标签页、RSS、Atom、搜索索引、相关阅读，都是从 content/posts/ 里算出来的，不用手动登记任何地方。

四、改标签

标签只写在 frontmatter 里：

tags: [design, css]

改完重新构建，三件事会自动发生：

• 标签页 /tags/ 重新统计数量；
• 每个标签的 /tags/<slug>/ 重新生成，没有文章了就不生成；
• 上一页/下一页的归档、搜索索引一起更新。

标签是「按名字统计」的，大小写和空格都算不同标签；中文标签可以用，URL 会做 percent 编码。

五、相关阅读怎么来的

文章页底部的「相关阅读」规则很短：

1. 取共享至少一个标签的其他文章；
2. 按文章顺序（日期倒序）取前 2 篇。

所以想让两篇文章互相出现，给它们同一个标签就够了。没有共享标签时，这一块整个不显示——不会硬凑。

六、构建与部署

npm install      # 构建期依赖：markdown-it 与几个插件
npm run build    # 产出 dist/
npm run dev      # 构建 + 本地 8899 预览

dist/ 是纯静态文件，丢给 Cloudflare Workers / Pages 即可，仓库里的 wrangler.jsonc 没有任何 main，只当静态资源用。

七、已知边界

• 构建时警告不影响产物：未解析的内链、不支持的嵌入、解析失败的日期，都会打印一行提示。
• 同屏最多两扇「真折射」窗口（首页 Hero + 最近文章卡），这是性能红线。
• 纸材质自 v5 起冻结，只修可读性问题，不再加新效果。

阅读指引

0.0.拍照现场 · 光

0.前言

无论怎样，在你按下 #快门 的瞬间，就已经决定了你要表达的大部分东西。

1. CMOS 与宽容度

1.1 什么是 CMOS？

这里不赘述画幅概念。在相机领域，#CMOS 特指那块将光信号转换为电信号的感光元件。

• 成像原理：CMOS 将光信号切分为无数方形小格（像素）。采用 #拜耳阵列 设计，每四个小格包含两个绿色、一个红色、一个蓝色（#GRGB），每个小格传回独立的亮度信号采集一组 #RGB 值后合成为数字图像的一个像素。

• 物理构成：通常所说的“CMOS”不仅指感光芯片本身，还包括其前方的 #低通滤光片 和 #红外截止滤光片。

  维护警示

  当人们说“CMOS 上有灰”时，灰尘通常附着在最外层的滤镜玻璃上。即使该玻璃可更换，也请极其爱惜，因为镀膜层极易损坏或沾上清洁液而导致镀膜不平，进而整机光学素质严重下降；而且更换拆卸过程极为繁琐。

• 市场格局：主流制造商为 #索尼 和 #佳能。索尼对外供应 CMOS，因此民用级非佳能品牌相机，极大概率搭载索尼传感器。

  SONY IMX410 sensor

  质优平价，大多2480w左右像素的全画幅相机都搭载了这一块传感器

1.2 宽容度 / 动态范围 (Dynamic Range)

#宽容度（等同 #动态范围）衡量的是传感器记录光线明暗跨度的能力。

• 定义：从最低有效非零信号到最高不饱和信号之间的比值，取以 2 为底的对数。单位为 #档 或 #EV。

  计算示例

  若最高电平为 1024µV，最低有效电平为 1µV，则宽容度 = log⁡2 (1024/1)=10EV 。

• 死黑与死白：超出上述范围的数据将被截断。

  • #死黑：RGB 全为 0，无明度信息，无法提亮恢复。
  • #死白：单像素达到最大光强溢出，无色彩细节，无法压暗找回。

• ISO 与宽容度的关系：ISO 每提升一倍，宽容度约降低一档。

1.3 主流机型宽容度参考表

全画幅 / 中画幅梯队

APS-C / M43 梯队

本章节后续索引

• 0.0.2 光比：从传感器到文件，数据是如何被“压缩”的？
• 0.0.3 光比：现场光线的明暗跨度如何应对？
• 0.0.4 白平衡：色温与色调的物理本质及校正逻辑
• 0.0.5 暗光环境和CMOS热燥：长曝光与高感下的 CMOS 热管理
• 0.0.6 题外话——分辨率和二次裁切构图：像素冗余对二次构图的意义

2.素材宽容度

常见的**视频**色深一般有**8bit、10bit、12bit**。其中，**12bit**一般会出现在**raw**格式上。

 注意：4:4:2 指的是采样方式，与色深无关。

1.1 从CMOS读取的模拟信号的数字化——ADC 、非线性映射与位深

CMOS 捕获的是连续模拟信号，必须经过 #ADC（模数转换器）量化为数字信号。这个过程是素材宽容度的第一道瓶颈。

• 位深 (#BitDepth)：决定了灰阶的离散层级数量。
  • 12-bit：4,096 级灰阶。早期入门机或高速连拍模式常见，暗部断层风险较高。
  • 14-bit：16,384 级灰阶。当前主流全画幅标准，平衡了画质与读取速度。
  • 16-bit：65,536 级灰阶。中画幅/旗舰机专属，为极端后期提供巨大余量。
• 非线性映射：人眼对暗部敏感、对亮部迟钝。为了高效存储，ADC 通常采用对数或伽马曲线分配码值——暗部给更多码值，亮部压缩码值。这意味着 RAW 文件的“数字宽容度”分布并不均匀。

1.2 RAW vs. 视频编码：宽容度的两种命运

关于 Log 曲线的补充

#Log 不是魔法，它是一种重新分配码值的策略：

• 将传感器的高光信息压缩进有限的 10-bit 容器中
• 牺牲中间调对比度，换取高光和暗部的记录空间
• 代价：若曝光失误（尤其是欠曝），10-bit 的码值不足以支撑拉伸，比 RAW 更容易出现 #色彩断层

1.3 影响素材宽容度的隐性因素

除了位深和编码，以下因素同样关键：

• 双增益架构 (#DualGain)：在特定 ISO 切换点（如 Sony A7S III 的 ISO 640/12800），传感器切换至高转换增益电路，读出噪声骤降，暗部宽容度瞬间提升约 2-3 档。拍摄时务必了解你相机的第二增益触发点。
• 压缩算法：即使是 RAW，也有无损压缩、有损压缩之分。有损压缩（如 Sony Lossy Compressed）在高光过渡区可能引入 #色调分离，实测宽容度损失约 0.5-1 EV。
• 过热保护：长时间录制时，CMOS 温度升高导致 #热噪声 增加，暗部信噪比恶化，实际可用宽容度随时间衰减。这也是为什么电影机需要主动散热。

1.4 实战建议：如何最大化素材宽容度

3.光比

4.白平衡

5.暗光环境和CMOS热燥

6.题外话——分辨率和二次裁切构图

0.1.调色

1.一级调色与二级调色

2.对象

3.工具

4.审美

5.交付

0.2.视觉呈现

1.色彩空间

2.视觉的e^x曲线

3.有限色域 · SDR

4.无限色域 · HDR

0.3.蒙版

1.蒙版的选择 · 我怎么选中

2.蒙版的选择 · 我怎么选中

3.Lrc的蒙版能做什么

4.Lrc蒙版缺陷——相比于图层

0.4.镜头视角及长宽比

1.焦段

2.画幅

3.光圈与景深

4.T值——电影进阶

5.长宽比

能跑，但有个隐患——纸永远长在玻璃的骨架上。玻璃加一个新特性（比如跟着指针反光），纸就得跟着写一条「不要反光」的规则。久而久之，两套材质都变成了补丁。

这一版反过来了：它们是两个程序。

窗口只有骨架，材质是画上去的

<div class="window">
  <span class="window__backdrop"></span>  <!-- 材质层：折射 或 纸面 -->
  <span class="window__sheen"></span>     <!-- 反射层：只有玻璃有 -->
  <div class="window__content">…</div>    <!-- 内容 -->
</div>

骨架只负责几何：圆角、裁剪、过渡。材质层由 data-surface 选择用哪套程序来画：

两者没有任何共享的材质变量。--lg-* 在纸态下不存在，--pp-* 在玻璃态下也不存在——不存在，就没人会误用。

为什么非要拆开

除了「概念干净」，还有一个很实际的原因：性能预算不一样。

• 玻璃要算折射、要重绘、要 Worker，所以同屏最多两扇窗用真折射，其余退化成「色层 + 高光边」。
• 纸什么都不用算，只是贴一张静态纹理。

如果共用一套变量，这种差异只能靠一堆 if 条件去表达；拆成两个程序之后，它是结构上的差异——玻璃实例登记进渲染器，纸实例压根不登记。

按钮也是窗口

<a class="window window--btn" data-window data-mode="soft" href="…">
  <span class="window__backdrop"></span>
  <span class="window__sheen"></span>
  <span class="window__content">读文章</span>
</a>

因为走的是同一套骨架与同一个材质程序，按钮的圆角、高光边、悬停位移和卡片永远一致——不是「对齐了」，是同源。

切换那一下

data-surface 一变，两个程序交替挂载：

1. 玻璃的反射参数被清空（不再有人写 --sx/--sy）；
2. 纸程序给每扇窗分配一点纤维偏移，避免整页纹理重复；
3. CSS 的 240ms 过渡负责「水分蒸发」。

骨架一点没动，内容一点没动。这就是「切换成本低」的真正含义——换的不是样式，是渲染程序。

代价

说实话：代码量比一套变量多了大约三成，第一次读的人得同时看两段 CSS。

但换来的是一句可以一直用下去的话：

想改纸，只改纸；想改玻璃，只改玻璃。互不牵连。

起点

原来的站是 Hugo 加一套改过的主题。用起来没问题，改起来处处别扭：想调一层玻璃的折射，要先在模板里找它属于哪个 partial；想换首页的结构，得跟主题的短代码较劲。

真正让我下决心的是两件事：

1. 我想要的首页是「一张图 + 一层玻璃」，主题的骨架里没有这个概念；
2. 每次改完都要重新理解一遍别人的抽象。

于是先做减法：整站只有两层——壁纸，和浮在壁纸上的窗口。

这句话后来成了所有设计决策的标尺。窗口是玻璃，它折射壁纸；窗口是纸，光就退回边缘。没有第三层，也就不需要去解释第三层。

第一版：把窗口拆成三层

一个窗口拆成三个兄弟节点，各自负责一件事：

<div class="window">
  <span class="window__backdrop"></span>   <!-- 材质：折射 或 纸面 -->
  <span class="window__sheen"></span>      <!-- 反射：只有玻璃有 -->
  <div class="window__content">…</div>     <!-- 内容 -->
</div>

这样拆的理由不是好看，是顺序：反射必须在内容之下，否则文字会被一起糊掉。第一版我把 sheen 放在内容之上，页面上所有白字都变成了雾——这是最早踩的坑，也是最值得记的一个：分层要按光的路径排，不是按重要性排。

材质：从「看起来像」到「算出来」

玻璃的第一版是老实做法：backdrop-filter: blur() 加几个渐变高光。像，但不对——真实玻璃的边缘会弯折背后的画面。

于是有了第二版：把壁纸复制进窗口，用 feTurbulence 加 feDisplacementMap 推一下。问题随之而来：位移是假的（噪声位移没有方向），而且只对固定背景成立。

第三版换了思路，把边框当成一块有厚度的斜面透镜：

σ(d) = σ_max                        d ≤ rs        ← 与玻璃内部同模糊
       σ_max · (1 − (d−rs)/(rl−rs)) rs < d < rl   ← 线性衰减
       0                            d ≥ rl        ← 中心清晰

Δ(d) = rs · tan(θt − θ) · (1 − d/rs)^1.5

距离用圆角矩形的 SDF 求，位移方向取外法线，θt 由 Snell 定律给出。这样直边、圆角、角落的模糊带宽度自动一致，位移尺度也由折射率和斜面倾角决定，而不是拍脑袋的常数。

实现落在 WebGL：三级模糊纹理、逐像素算 SDF、R/B 通道按 n(λ) 错开做色散。中心是清晰的，边缘是糊的，斜线在边界处有一点点彩边——这就是液态玻璃区别于「毛玻璃」的地方。

首页：让一张图变成一张卡

原本的设计是「满屏图 → 滚动 → 变成玻璃卡」两个状态，中间靠 CSS 过渡。做出来很难看：两个状态之间是跳的。

改成一个变量驱动：

--p 由 scrollY / (0.38 × 视口高) 算出来，写到 <html> 上。整个形变就是一段插值，没有状态机。

顺带的收益：透镜的强度也跟着 --p 走——p=0 时画布就是一张原图，p=1 时才是完整玻璃。一个变量管两件事，改起来不会脱节。

内容层：把解析器交出去

Markdown 最初是我手写的，一千多行。写的时候很爽，因为每个 Obsidian 语法都能照顾到；维护起来很痛，因为每一条语法都是我自己的责任。

转折点是一篇带 date: 2026-11-4 的文章——没补零，new Date() 返回 Invalid Date，整个构建挂掉。那一刻我意识到：这类坑不该由我埋。

于是换成 markdown-it 加三个插件，自己只留 Obsidian 方言那一层：callout、内链、标题层级对齐、中文软换行。渲染器从 1139 行降到 321 行。

迁移时做了一件事：同一批文章用新旧两个渲染器各跑一遍，统计标题、callout、表格、任务项、脚注、内链、目录条数。十个文件全部一致，才敢删旧的。这种比对很笨，但比「看起来没问题」可靠。

交互：目录是块玻璃

目录换过两次。

第一版是侧栏里的一棵静态树，缩进加序号。问题是它太安静——你永远不知道自己在文章的哪一段。

第二版加了实时高亮和折叠，但序号和箭头堆在一起，缩进又吃掉一半宽度，读起来像文件管理器。

现在是第三版：目录是一块贴在右缘的玻璃面板，位置在导航之下、文章之上。

• 有子级才给箭头，没有子级是圆点，序号全部去掉；
• 收起按钮 38×38 放在面板左上角（上一版是 14px 的 »，点不中）；
• 收起后文章居中，点右侧空白或边缘的 ‹ 再唤出，唤出时把文章往左推。

推开这个动作是有意的：它让「目录」和「文章」成为两个独立的东西，而不是一列固定的装饰。

可读性：把「感觉能读」变成数字

玻璃和纸两套材质、亮暗两个模式，四种组合。我一直以为都没问题，直到真的去量。

方法是：同一页在四种组合下各截两张图，一张正常、一张把所有文字设为透明，然后按元素矩形在「只有背景」的那张上取真实像素，算 WCAG 对比度。

量出来的问题都很朴素：

• Hero 名片的材质层被一条后代选择器误关，白字直接压在亮照片上（3.15:1）；
• 纸模式的 Hero 只有浅色 veil，白字在没有暗角的照片上（1.5:1）；
• 导航当前项、目录当前项的底色写死成浅色，暗色模式下变成「浅底浅字」（1.5–1.8:1）。

修完再量，四种组合的最低值都在 4.6:1 以上。方法记在 DESIGN.md，复查时直接照做。

这件事的教训不是「要测对比度」，而是：写死的颜色终会在某个模式里翻车，而模式的数量总是比你以为的多一个。

取舍

有几件事最后没做，理由值得记下来。

没有上 liquid-glass-react。 装了、接了、也真跑通了，但它靠 feImage 生成位移图，而 Chrome 的 backdrop-filter 不执行滤镜里的 feImage——核心效果在主浏览器上是空操作。打出来的包 41 KB gzip，静止状态又几乎没有可见材质。最后只取了它的高光层和饱和度配方。

构建依赖不再坚持为零。 「零依赖」曾经是个卖点，但它换来的是我自己维护一个 Markdown 解析器。现在构建期依赖 markdown-it，产物仍然是纯静态文件——运行时不依赖任何库，这条线才是真的重要。

纸材质冻结。 两套材质都持续迭代的结果是两边都半成品。定下「纸只修 bug」之后，玻璃反而推进得更快。

现状

• 12 篇文章，30 个页面，构建约 0.1 秒；
• 首屏 JS 3.9 KB（gzip），CSS 17.4 KB，光学引擎 10.3 KB 按需加载；
• 同屏最多两扇真折射窗口；
• 四种「材质 × 明暗」组合，正文对比度 ≥ 4.6:1。

这个站现在大概到了「想改哪里都知道该动哪个文件」的状态。对我来说，这比任何一项具体的效果都更重要。

位移不了，就折射不了。这是浏览器给玻璃效果划的硬边界。

那就自己造一层

既然背景是固定的，我可以把它复制到窗口里，然后对这份副本做位移：

.wallpaper,
[data-surface="glass"] .window__backdrop {
  background-image: var(--wallpaper-img), var(--wallpaper-image);
  background-size: cover, auto;
  background-position: center, center;
  background-attachment: fixed, fixed;
}

关键在于 background-attachment: fixed：它让背景的定位基准变成视口，于是窗口里的副本和窗口背后的壁纸像素级对齐。

对齐之后再加位移：

<filter id="lg-refract" x="-10%" y="-10%" width="120%" height="120%">
  <feTurbulence type="fractalNoise" baseFrequency="0.009 0.017" numOctaves="2" seed="11"/>
  <feGaussianBlur in="noise" stdDeviation="1.1" result="field"/>
  <feDisplacementMap in="SourceGraphic" in2="field" scale="18"
                     xChannelSelector="R" yChannelSelector="G"/>
  <feGaussianBlur in="displaced" stdDeviation="7"/>
</filter>

feTurbulence 生成一张平滑的噪声场，feDisplacementMap 用它把每个像素推一点点，最后补一次模糊——玻璃的「毛」和「歪」就都在了。

边界必须写死

这套做法只在三种条件下成立，缺一个就会露馅：

1. 背景必须是固定的。 壁纸贴了 position: fixed 才谈得上「复制一份并对齐」。滚动内容不行。
2. 窗口必须在壁纸之上、且不压别的内容。 副本里只有壁纸，压着图片或文字就会穿帮。
3. 位移场不能动。 feTurbulence 是 CPU 渲染的，每帧重算等于自杀。

所以我的实现里只有首页 Hero 和置顶卡用真折射，其余窗口用「同色层 + 高光边」——远看是玻璃，滚动不掉帧。

滚动时降级

这是设计里最舒服的一处取舍：

[data-surface="glass"].is-scrolling .window[data-mode="refract"] .window__backdrop {
  filter: blur(26px) saturate(150%);
}

滚动中，位移场换成纯模糊（便宜），停手 140ms 后再切回折射。

视觉上像是玻璃「重新对焦」——而实际上，是浏览器替我做了它最擅长的事。

反射交给 Worker

折射是静态的，反射不是：光斑要跟着指针跑，还要随速度变亮。

这部分数学不重，但我还是塞进了 Web Worker：

• 主线程只做一件事：pointermove 时把坐标发给 Worker；
• Worker 算出每扇窗的光斑位置（--sx/--sy）与强度（--li）；
• 主线程收到结果，写三个 CSS 变量。

el.style.setProperty('--sx', data[i * 3].toFixed(1) + '%');
el.style.setProperty('--sy', data[i * 3 + 1].toFixed(1) + '%');
el.style.setProperty('--li', data[i * 3 + 2].toFixed(3));

这样滚动、移动指针时，主线程上没有任何逐帧计算——只有三次赋值。

一句话总结

网页上的「真折射」不是魔法，是复制 + 对齐 + 位移三件事，前提是你得接受它只对固定背景成立。

接受这个前提之后，剩下的都是工程问题。^[1]

前面四次分别死在：主题太花、构建太慢、样式无从下手、以及最经典的——改完首页之后，文章页还是旧样子，像两个网站拼在一起。

这一次我给自己立了一条规矩：先把"美工"拆成可独立替换的积木，再动第一行代码。

拆成五块之后，事情变得简单了

五块之间只通过 CSS 自定义属性和固定的层叠次序说话，谁也不 import 谁。于是我修改背景的时候，不需要重新理解文章页；删掉鼠标特效的时候，也不用担心导航挂掉。

一个界面的可维护性，往往取决于"改一个地方要读几个文件"。

为什么最后选了玻璃

老实说，一开始是因为好看。玻璃会折射背后的颜色，页面一动，光就跟着流动，那种"活物感"是纯色卡片给不了的。

但真正让我决定的是另一件事：玻璃天然自带层次。

头像可以压在卡片上，卡片可以压在封面上，页头可以浮在内容之上。前后景关系一出来，界面就不需要靠边框和分割线去解释了——这正是我在旧版里最缺的东西。

玻璃的代价：它必须一直是"湿"的

问题在于，玻璃不适合读文章。正文后面永远有一片晃动的颜色，长段落读十分钟就想关掉。

所以我把同一块材质做成了两种状态：

• 入口页是玻璃：含水、透明、会反光，适合浏览和"哇一下"。
• 文章页是纸：抽干、不透明、只剩字，适合待很久。

这就是那句总纲——毛玻璃也是一种纸。不是两套风格，是同一块材料的含水量不同。

于是有了那个按钮

页头右上角有一枚小小的药丸按钮：💧 和 📄。

它不做主题切换，只做一件事：把当前页面从"湿"调到"干"，或者反过来。手选过一次之后，它会记住。

我知道这是个很小的功能。但当你亲手把一篇文章从玻璃里"抽干"、看着纸纹一层层浮上来的时候，你大概能明白我为什么愿意为它写那 300 字节。

接下来

站是新的，文章是旧的。我会慢慢把以前散在别处的东西搬过来，顺便把剩下的两块——图章和鼠标特效——再打磨一下。

如果哪天你觉得这里的字太小、玻璃太亮、或者动画太吵，欢迎直接告诉我。好界面是被抱怨出来的。

这一轮把渲染器补齐到「复制过来就能发」。

必须支持的清单

callout 是回报率最高的一项

以前写提示框要手搓 HTML：

<div class="callout callout--warning">…</div>

现在只要：

> [!warning] 注意
> 位移场每帧重算会掉帧。

渲染器会认领首行的 [!type]，把剩下的内容当成正常的块级 Markdown 继续渲染——所以 callout 里照样能放列表、代码、链接。

内链：诚实地提示

静态站没有「双链索引」，所以我没打算假装有：

参考 [[搜索相似度算法·设计]] 里的阈值公式。

渲染成 <span class="wikilink">（斜体 + 虚线下划线），鼠标悬停显示「未解析引用」，构建时再打印一行警告。

中文软换行

Markdown 里一个换行不产生空格，但中文被换行拆开时如果补一个空格，就成了「中 文」。

const a = out.slice(-1);
const b = line[0];
out += CJK.test(a) && CJK.test(b) ? line : ' ' + line;

两端都是中日韩字符就贴着，否则补空格。三行代码，解决了困扰我很久的排版问题。

测试

渲染器现在有 152 条断言：每种语法的关键 HTML、目录编号（1 / 1.1 / 1.1.1）、脚注双向锚点、未解析内链告警、代码块里的 <script> 是否被转义……

跑一次不到 100ms，构建前顺手执行：

node scripts/test-markdown.mjs

152/152 通过，剩下的事交给写作。

• 壁纸是前端的资源，参与材质渲染，必须小、必须快、必须可缓存一辈子；
• 照片是内容，可能很大、会一直增加，应该交给边缘节点。

所以图床单独做。

三档尺寸

每张图在上传时就切成三档，构建时只负责生成索引：

gallery/
  index.json          # 构建产物：条目 + 尺寸 + 元信息
  thumbs/<slug>.webp  # 400w  列表用
  preview/<slug>.webp # 1200w 灯箱先显示这张
  full/<slug>.webp    # 1600w 灯箱随后替换成这张

列表页只加载 thumbs，并带上 srcset。灯箱打开时先给 preview，等 full 加载完再换——眼睛几乎察觉不到，但首屏省下几百 KB。

双击进画廊

桌面端双击缩略图进入，单击不动作（防误触）；触控端没有双击，改成单击；键盘用户按 Enter。

三种入口，一个动作。

灯箱里除了大图，还有一栏信息：

这条「空则省略」的规矩很重要——不然每张插画下面都会挂着「相机：—」，很像模板没填完。

为什么不用 Worker

图床不需要实时缩放：

• 缩略图是构建时（或上传时）一次性生成的；
• 边缘节点只负责把文件吐出去；
• 目录由 gallery/index.json 描述。

一旦引入实时缩放，就多了一个会冷启动、会超时、会按请求计费的东西——而它解决的问题，一张预生成的 WebP 就能解决。

玻璃配方保持一致

相册卡片也是窗口：同样的圆角、同样的高光边、同样的悬停位移。

灯箱是玻璃层的「高潮态」——深色遮罩 + 强模糊 + 中央大图，但配色仍然取自同一套 token（--brand、--seal、--radius）。所以它看起来不像外挂组件，更像这块玻璃被举到了眼前。

剩下的问题

• 三档尺寸 + srcset
• 双击/单击/Enter 三种入口
• 焦点圈定 + Esc 关闭 + ±1 预取
• 图片条目从文件系统自动扫出来
• EXIF 自动读取相机与焦距
• 画廊内的双指缩放

前三个是工程活，最后一个（手势缩放）是产品决定——双击已经被「进入画廊」占用了，再放大就得换手势。

先把能确定性做完的做掉。

一周之后我把它改回来了。原因很简单：冷。

玻璃折射、高光边、饱和度拉满的背景，单看每一屏都很漂亮，连着读三篇东西就像在机场广告灯箱前面站了二十分钟。

后来我意识到问题不在玻璃本身，而在"玻璃背后什么都没有"。玻璃之所以像玻璃，是因为它压着东西。

一个念头：纸是被抽干的玻璃

某个凌晨我盯着磨砂玻璃杯看，突然想到：如果玻璃背后压着的是一张纸呢？

磨砂玻璃本来就是"不完全透明"的材料，它把背后的东西糊成一层薄薄的色块——这不正是被水浸润的纸吗？反过来，纸是抽干了水分的玻璃：不透明、不折射、但保留了纤维的肌理。

于是我把两者放到同一根轴上：

高含水量 ── 玻璃（透明·折射·水印纸纹 .04）
             │
             │  同一个材质轴
             │
低含水量 ── 纸（不透明·暖白·纸纹本体 .55）

这件事的好处立刻显现：入口页和文章页不再是两个网站，它们只是同一块材料的两端。

玻璃的三要素

要让一块面板真的读作"玻璃"，而不是"贴了层灰膜的方框"，必须同时具备三样东西。

1. 顶边高光

--specular: inset 0 1.5px 0 rgba(255,255,255,.85),
            inset 0 -1px 0 rgba(255,255,255,.14);

只有顶边一条 1.5px 的亮线，加底边一条 1px 的微反。少一条，面板立刻变平。

2. 背景折射

backdrop-filter: blur(18px) saturate(170%);

blur 决定"毛"的程度，saturate 决定它吸上来多少颜色。只模糊不增饱和，玻璃会显脏。

3. 中央纸纹

这是我自己加的那一笔。用 feTurbulence 生成一层噪点，铺在玻璃里，opacity: .04：

.glass::after {
  background-image: url("data:image/svg+xml,...");  /* 静态可平铺，不动画 */
  opacity: var(--grain-opacity);
  mix-blend-mode: var(--grain-mix);   /* 亮色 multiply / 暗色 screen */
}

它几乎看不见。但把 opacity 从 .04 调到 0 再对比，玻璃会立刻从"压着纸的磨砂玻璃"变回"一块塑料"。

纸的那一半

纸态反而更简单：不透明度拉满，纸纹浓度从 .04 提到 .55，投影全部去掉。

.paper {
  background: var(--bg);
  --grain-opacity: .55;
  box-shadow: none;   /* 纸不抬离页面 */
}

纸不投影是条硬规矩。加了阴影的纸就是卡片，不是纸。

两条性能红线

材质用得爽，但有两件事千万别做：

1. 不动画 blur 半径。 每一帧都要重新做一次高斯模糊，中端手机上直接掉帧。
2. 不动画纸纹。 feTurbulence 是 CPU 渲染的，动一下就是灾难。纸纹只能是静态的可平铺贴图。

所以我的圆斑只用 transform 漂移，纸纹一次生成、永不再动。

那个开关

材质轴需要一个显式开关，不然用户永远不知道"纸态"存在。

页头那枚 💧 / 📄 的药丸做的就是这件事：<html data-surface="glass|paper">，三值同拍过渡——--glass-bg、backdrop-filter、--grain-opacity——240ms。

入口页默认给你玻璃，文章页默认给你纸，但每一页你都可以亲手把它们调回去。

毛玻璃也是一种纸。玻璃是纸的含水态，纸是玻璃的干态，我们只是在同一个材质轴上滑动。

这句话后来被我写进了设计文档的第一行。

后来我把整套东西删了，只留一个文件：build.mjs。

需要的其实只有三件事

一个静态博客生成器要做的事，拆开看只有三件：

1. 读 frontmatter，拿到标题、日期、标签
2. 把 Markdown 变成 HTML
3. 套上模板，写到 dist/

Node 内置的 fs 和 path 就够了。不需要 remark，不需要 unified，不需要插件生态——因为我写的 Markdown 是我自己写的，我不需要兼容整个 CommonMark。

Markdown 子集就够用了

我实现的是这样一个子集：

• 标题、段落、粗体斜体、行内代码
• 围栏代码块（带语言 class）
• 有序/无序列表、引用、分割线
• 表格、图片、链接
• 任务列表

加起来不到 200 行。剩下的都是我不写的语法，所以它永远不会因为"不支持"而咬我。

有个小细节值得一提：中文软换行。

const CJK = /[\u2e80-\u9fff\u3000-\u303f\uff00-\uffef]/;

function joinSoft(text) {
  const lines = text.split('\n').map(l => l.trim()).filter(Boolean);
  let out = '';
  for (const l of lines) {
    if (!out) { out = l; continue; }
    const a = out.slice(-1), b = l[0];
    out += CJK.test(a) && CJK.test(b) ? l : ' ' + l;
  }
  return out;
}

Markdown 里换行不产生空格，但中文被换行拆开时如果补一个空格，就成了"中 文"。所以判断两端是不是中日韩字符，是就贴着，不是就补空格。

图片尺寸在构建时补上

CLS 最容易被图片搞坏。但我又不想在每篇文章里手写 width / height。

解法很简单：构建时读一遍本地图片的头部，把真实尺寸塞进 <img>。

// WebP 的三种容器格式，尺寸藏在不同的位置
if (fmt === 'VP8X') return { w: 1 + b.readUIntLE(24, 3), h: 1 + b.readUIntLE(27, 3) };
if (fmt === 'VP8L') { const v = b.readUInt32LE(21); return { w: (v & 0x3fff) + 1, h: ((v >> 14) & 0x3fff) + 1 }; }

写完之后，![封面](cover-1.webp) 出来就是 <img width="1200" height="675" loading="lazy">，布局一次都不会跳。

用断言代替肉眼

发布之前跑一遍 node scripts/verify.mjs，它检查：

死链检查最值钱。有一次我把 posts/ 改成 post/，本地看着一切正常，校验脚本直接报出 17 条死链。

代价是什么

说点实话。自己写生成器的代价是：

• 没有热更新，改完要重跑 node build.mjs
• 语法支持靠自己加，想用脚注就得自己写
• 没有插件生态，搜索、评论、图床都得自己接

但收益也很直接：整站只有两种语言，HTML 和 CSS。任何一处不满意，我都能在十分钟内改到满意，不用查文档，不用跟抽象层搏斗。

工具的价值不在于它能做多少，而在于它不挡路。

现在这个站的构建时间

$ time node build.mjs
✓ 生成 5 篇文章 · 6 个标签 · 21 条 sitemap -> dist/

real    0m0.09s

九十毫秒。改完一篇文章，敲一个命令，刷新浏览器就看到了。

这大概就是我愿意继续手写它的原因。

不是因为它最快——虽然它确实很快——而是因为它的部署模型足够无聊：一个只有 assets、没有 main 的 Worker。

没有脚本在跑，就没有冷启动，没有请求计费，没有"函数执行超时"。你的 dist/ 被推到边缘节点上，然后 CDN 直接吐文件。

配置短得离谱

{
  "name": "dream-blog",
  "compatibility_date": "2026-04-01",
  "assets": {
    "directory": "./dist",
    "html_handling": "auto-trailing-slash",
    "not_found_handling": "404-page"
  }
}

三个字段值得解释：

• html_handling: auto-trailing-slash：让 /posts/hello-world 和 /posts/hello-world/ 指向同一个文件，不产生跳转链。
• not_found_handling: 404-page：用你自己的 dist/404.html，而不是 Cloudflare 默认那页。
• 没有 main 字段：这就是它"只是个静态站"的证据。

一键部署

npm run deploy

脚本做六件事：

1/6 环境检查   node 版本、wrangler 是否可用
2/6 构建       node build.mjs
3/6 产物校验   死链、h1、占位符、RSS、配置一致性
4/6 登录状态   wrangler whoami，没登录就停下
5/6 部署       dry-run 预检 -> wrangler deploy
6/6 线上自检   curl 五条关键路径

第 3 步是关键。永远不要部署没校验过的产物——线上排错的成本是本地的一百倍。

三个每年都会忘的坑

1. workers.dev 子域要先注册

第一次部署大概率会报：

You need to register a workers.dev subdomain before publishing

这不是权限问题，是账号还没在 Workers & Pages 里走完 onboarding。去控制台点一次就行，全局唯一、全账号共用。

2. _headers 不生效往往是因为缩进

Cloudflare 的 _headers 文件对格式很敏感——每条规则下面的响应头必须缩进两个空格，规则之间空一行：

/*
  X-Content-Type-Options: nosniff
  Referrer-Policy: strict-origin-when-cross-origin

/images/*
  Cache-Control: public, max-age=31536000, immutable

不缩进的话整段会被静默忽略，你会在三个月后才发现图片没有缓存。

3. 没有浏览器的机器用 Token

wrangler login 需要开浏览器。CI 里只能：

export CLOUDFLARE_API_TOKEN=你的token

Token 权限要包含 Workers Scripts:Edit、Account Settings:Read、User Details:Read、Zone:Read。少了哪一项，报错信息都不会直说是权限问题。

顺手加的几个头

X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
X-Frame-Options: SAMEORIGIN
Permissions-Policy: geolocation=(), microphone=(), camera=()

成本为零，但能挡掉一批低级的扫描告警。

为什么不直接 GitHub Pages

GitHub Pages 也很好，尤其是配合 Actions 的自动构建。区别在于：

• Cloudflare 的免费额度对静态资源几乎无感，Pages 有 100GB/月的软限制
• Cloudflare 的 _headers 能精细控制缓存与安全头，Pages 只能靠 _headers 支持的部分
• 我的域名解析本来就在 Cloudflare

如果你的解析不在 Cloudflare，多出来的那一步 DNS 迁移可能就不值了。部署方案要跟着域名走，不是反过来。

原因很丢人：我在写一段 CSS 的时候，被一条"您的订单已发货"打断，然后顺手刷了四十分钟。等回过神来，box-shadow 的第三个值还是空的。

第一个月很难受

不是想刷手机的那种难受，是手不知道往哪放。

排队的时候、等构建的时候、电梯里那二十秒——这些缝以前都被填满了，现在空着，空得让人心慌。

后来我发现自己开始看东西了。楼下修车摊的大爷用一把改锥就能把链条装回去；地铁站的天花板有一块瓷砖颜色不一样；便利店的关东煮汤底在下午三点会换一次。

这些事没有任何用。但记住它们之后，我写的东西好像变得具体了一点。

关掉订阅号之后

我退订了 70 多个公众号，取消关注了 200 多个技术博主。

留下来的只有三类：

1. 写代码写到我用得上的人——他们的文章我会真的去跑一遍
2. 写生活写到我不敢写的人——他们的句子让我知道中文还能这么用
3. 我现实里认识的人——哪怕他们一年只发一条

其余的都很好，但跟我没关系。资讯的边际收益下降得非常快，而它的边际成本是一条命。

一些具体的变化

第三行影响最大，但第五行最有用。

一个不成熟的结论

我不觉得"少"本身是美德。少只是让你有力气去做那一两件事。

这半年我做完的东西其实比前一年多：这个站、两个小工具、一本读了三个月才读完的书。数量上没什么可骄傲的，但它们都还活着。

时间不是被夺走的，是被切碎的。切碎之后，每一块都小到不值得开始。

写到这里，窗外在修路，冲击钻停了。我也该回去把那个 box-shadow 补完了。