1. 金额不公开 —— 让它根本不存在，而不是藏起来#

这是全篇我最想强调的一点。

「不公开金额」有三种常见做法，安全性差着量级：

我选第三种。数据结构长这样：

1
export interface Sponsor {
2
  /** 昵称（必填，公开显示） */
3
  name: string;
4
  /** 头像地址；留空则显示昵称首字符 */
5
  avatar?: string;
6
  /** 留言 / 一句话简介 */
7
  message?: string;
8
  /** 支持日期，格式 YYYY-MM-DD；留空则不显示 */
9
  date?: string;
10
  /** 对方的主页或站点，填了会在卡片右上角显示外链按钮 */
11
  url?: string;
12
}

没有 amount。这不是”暂时没用到”，而是刻意不给它留位置——将来就算我自己想加，也得先改类型定义、再改模板，多一道心理摩擦。约束做进结构里，比写进注释里可靠。

顺带一个细节：名单头部那个 共 N 位 的计数，也是唯一出现的数字。整页没有第二处金额相关的量。

2. 数据手动改 —— 收成一个文件，且不用手动排位置#

所有内容集中在 src/sponsor_data.ts，文件顶部写满了注释，包括图片该放哪、名单怎么写、不想署名怎么办。

真正省事的是排序。人的直觉是”往下追加最新的一条”，但页面上要的是”最新的在最上面”。如果每次加人都得手动挪位置，早晚会忘。所以把排序交给页面：

1
const sortedSponsors = [...sponsors]
2
  .map((item, index) => ({ item, index }))
3
  .sort((a, b) => {
4
    const da = a.item.date ?? "";
5
    const db = b.item.date ?? "";
6
    if (da && db) return db.localeCompare(da); // 都有日期 → 倒序
7
    if (da) return -1;                        // 只有 a 有 → a 在前
8
    if (db) return 1;                         // 只有 b 有 → b 在前
9
    return b.index - a.index;                 // 都没日期 → 按书写顺序，后写的在前
10
  })
11
  .map(({ item }) => item);

规则就三条：有日期的按日期倒序、没日期的排在后面、日期空缺时按写入顺序倒推。于是维护动作退化成”打开文件、往数组末尾粘一段、保存”，不需要读任何其他代码。

3. 收款码占位 —— 靠 onerror 回退，而不是靠我记得补图#

第三个要求最实际：正文和结构现在就能上线，二维码图我手上还没有。

如果直接 <img src="/sponsor/wechat.png">，图不存在时浏览器会渲染一个破图图标加 alt 文字，很难看。常见的笨办法是先放一张占位图，补真图时再替换——但那样就多了一步”记得改代码”。

我让缺图这件事自己暴露：

1
<img
2
  src={way.qr}
3
  alt={`${way.name}收款码`}
4
  width="180"
5
  height="180"
6
  loading="lazy"
7
  onerror="this.closest('.sponsor-qr-frame').classList.add('is-empty')"
8
/>

加载失败时给外层容器加一个 is-empty 类，CSS 里由它切状态：

1
.sponsor-qr-frame.is-empty img { display: none; }
2
.sponsor-qr-frame.is-empty .sponsor-qr-placeholder { display: flex; }

.sponsor-qr-placeholder 是一块虚线框 + 二维码图标 + “待补充”，平时 display: none 待命。

这么写的好处是：补图这个动作不需要改任何代码。把 wechat.png 丢进 public/sponsor/，刷新即生效。同款的还有名单头像——onerror="this.remove()" 直接摘掉失败的 <img>，露出底下用昵称首字符做的字母头像，永远不会看到破图。

坑 1：编辑时缩进模糊匹配，把相邻项吃掉了#

加导航项时我用了编辑器做字符串替换，结果回读发现「开往」那一项被截断并重复了——本来一项变成了两项半。

原因是我给的匹配文本和文件里的真实缩进不完全一致（这文件用的是 Tab，我按习惯写成了空格）。编辑器做了容错匹配，把边界算歪了。这件事的教训不是”这个编辑器不行”，而是：

改配置文件后一定要回读校验，不能信”已保存”。

我的做法是改完立刻用脚本把改动区域的每一行按 repr() 打出来，逐行核对缩进字符：

1
lines = open(path, 'rb').read().decode('utf-8').split('\n')
2
for n, l in enumerate(lines[43:95], 44):
3
    print(n, repr(l))   # repr 会把 Tab 打成 \t，一眼看出真假

在那之后，凡是涉及此类改动，我都走”写脚本改 + 回读核对”，而不是依赖编辑器的模糊匹配。批量替换一律用 Python 按字节处理，因为一旦涉及行尾（\r\n）和编码，文本模式的读写会静默做转换，污染整个文件。

坑 2：Tailwind 静默丢弃了那个类#

坑 1 是手滑，坑 2 是真不知道。

本站友链页有两个「申请友链」「申请标准」的小圆底图标，写法是：

1
<div class="w-10 h-10 rounded-full flex items-center justify-center bg-[var(--primary)]/10">

看起来完全合理——10% 透明度的主题色。但它一直是失效的，圆底其实没有颜色，只是不太明显所以没人发现。

原因：Tailwind v3 没法给 var() 任意值注入 alpha。bg-[var(--primary)] 是合法的，末尾加 /10 之后整个类会被直接丢弃——不报错、不警告，类名还老老实实挂在 DOM 上，所以只能靠肉眼”感觉这里应该有圈底色”来发现。

我用 Tailwind CLI 单独跑了一遍验证，不是猜的：

1
# in.css 里只有一行 @tailwind utilities;
2
# 测试用的 HTML 里放 bg-[var(--primary)]/10 和对照的 bg-white/10
3
node node_modules/tailwindcss/lib/cli.js -i in.css -o out.css --content test.html

结果：产物里 bg-white/10 正常生成，bg-[var(--primary)]/10 一行都没有。

修的办法很简单，用 color-mix() 手写：

1
.icon-badge {
2
    @apply flex items-center justify-center shrink-0 w-10 h-10 rounded-full transition;
3
    color: var(--primary);
4
    background: color-mix(in oklab, var(--primary), transparent 90%);
5
}

顺手做了一件事：这既然是「主题色圆底 + 图标」这种通用视觉原子，就别让它在每个页面里重复一遍。提炼成全局类 .icon-badge 之后，赞赏页和友链页共用同一份定义，以后再出现同类用法直接套类名就行。

color-mix() 还有个额外好处：深色模式不用单独写覆盖。因为 --primary 本身在两个主题下取值不同，混出来的底色自动跟着变。