以下仅适用于低于 4k 缩放 200% 的显示器

微软雅黑作为随着 Windows7 出现的字体，加上遥遥领先（？）的 ClearType，在当时的 1080p 显示器上十分清晰易读。

但如今的显示器分辨率越来越高，旧版微软雅黑的设计存在着明显的缺陷。

一是其字形设计并不平衡，中宫过大，有的字形可以以难看来形容；二是微软雅黑字形只在 4K 屏 200% 缩放（以上的配置）上有着较好的显示效果。

微软曾经设计过“另一版的微软雅黑”，即 Noble Scarlet，但并没有在正式的系统中使用。这一版字体设计依然中宫偏大，但相对老版收敛了不少，平衡了一些。

另外，如果你不巧像我一样用着 2K 或 2.5K 屏，

• 在 24寸时，100% 缩放字体比较合适，但与 16 寸 1080p 显示器差不多清晰度，不过屏幕可用空间更大。
• 在 21 寸时，100% 缩放字体会偏小，比较锻炼眼睛。150% 缩放字体大小比较合适，效果更细腻，但字型会比较怪，且屏幕可用空间与 1080p 相同。
• 在 16 寸时，150% 缩放字体稍微偏小，效果比较细腻，但非整数倍缩放+ClearType 的加持下，一些像素被吞掉，笔画的间距不平衡，有种“ windows 特有的字被虫噬的美”。

可以看到，上图的 100% 200% 缩放没有字形变形问题，可以说微软雅黑小字优化是考虑的 100% 缩放。100% 缩放显得糊则是因为图片放大放大倍率过高，实际不会有糊，而是有锯齿感。

150% 缩放会由于 clearType 的“锐化”导致字形变化，不知道的还以为换了个字体。如果是125%、175%的缩放，字体变形更加糟糕。

造成缩放问题的原因大概可以用下图进行简要解释：

Mac 上的 Retina 渲染相当于 4k 200% 缩放起步。而 windows 下， 2k-2.5k 的屏幕都在 200% 以下的缩放中挣扎。如果软件没有适配高分屏，没有 clearType，强制进行双线性缩放（常见于图片UI），就会显得非常糊。想体验这样的糊，可以下载旧版的原神启动器。

需要准备

• Noble Scarlet 替换系统的微软雅黑。由于 Noble Scarlet 是一个未完成的字体，普遍使用的是社区修正版，以下是资源参考。
  • pcbeta
  • bilibili

以上苹方加粗版本不一致性问题太多、新版苹方的英文表现相当糟糕，因此不建议使用，其他版本直接替换的都还不错。

• 系统字体替换工具：搜索 “字体替换工具 by 随风飘扬”。替换完后重启，否则可能有缩放错误。另外，github 上有一个非侵入式的系统字体替换工具 noMeiryoUI，可惜换不全 windows 11，只是作为预览不同字体在系统上的效果倒是个很不错的工具。
• MacType 改善 ClearType 的虫噬渲染方式带来的不均匀，使用后提升非常非常大。
• 思源宋体：推荐将浏览器的 Serif 字体设置为此字体。默认的宋体真的，不论中文英文，都很丑……只适合打印。

字体替换说明

位于 C:\Windows\Fonts 下有三个文件。这个三个文件可以使用上述的系统字体替换工具替换（推荐），或者安全模式下 xcopy 命令也可以替换。但是自己替换时要注意备份，这是真正意义上的替换了底层字体。网上也许会说用 PE 启动，但其实并不需要从 PE 启动这么麻烦。

• msyhbd.ttc
• msyh.ttc
• msyhl.ttc

位于 C:\Users\你的用户名\AppData\Local\Microsoft\Windows\Fonts 也有三个文件，这三个文件可以不用管，直接安装对应新字体就可以让新字体生效，同时老字体也没有被删除，只是会生成 msyhhv_0.ttc，等于是修改了注册表中的字体文件Link。

• msyhhv.ttc
• msyhsb.ttc
• msyhsl.ttc

当然，其实你也可以生成注册表

常用正文黑体简述

苹方

苹方是一款设计上很优秀的字体，其间架结构、中宫非常平衡，既兼顾了传统的汉字笔画细节又有规整而现代的几何化，间距合理，阅读起来非常舒适。

但是……苹方的设计缺字重。 苹方已经发布了可变字体，目前不再缺字重了，下段内容已过时。

在设计上，苹方没有 Heavy 字重（参考）。而在流行的 github 苹方字体仓库中，则是将 Bold 字重映射到了 Heavy，而将原本的Medium 映射到了 bold。虽然这个问题不是苹果设计的导致的，而是一个再次分发时的错误，但致使目前网上能搜索到的第三方仓库的苹方字体整体字重均偏细。

另外，苹方在 2.5K 屏上表现非常糊。 hinting 有了，不糊了，下段内容已过时。

苹方问世时已经进入了 Retina 屏的时代，没考虑过在低 PPI 屏幕上的表现（不是4K屏缩放200%都别用）。

第三，苹果设备的显示的西文字体是 San Francisco，不是苹方。在 细数 Pingfang SC 的七宗罪 中，也提到仅使用苹方导致不同设备字体 fallback 的不一致的问题。而作为系统字体里的其他问题，例如缺失本地化的字型，也是大部分字体所缺乏的，这已经不仅仅是一个字体问题，而是和字体相关的和 UI 技术标准化问题，难以仅通过字体解决。而无比例数字、冒号不垂直居中、没有垂直标点等细节，则都是因为苹果显示标点数字用的 SF 字体，苹方在此类字符上算是基本能用，但缺少多种场景下的细节。

其他资源： Pingfang for windows - Figma

另外，苹方是有版权限制，以下字体除了思源黑体，和大厂的开源黑体，均不可免费商用。

思源黑体系列

思源黑体(Noto sans) 是 google 的开源可商用字体，用于 Android 系统，在开源可商用的的黑体其质量无可替代。

更纱黑体是思源黑体的衍生，修改了西文部分，相比思源黑体上更符合作为 无明显风格特征的系统字体，带 hinting 在 1080p 和 2.5k 下都能保证良好的清晰度。

但是，思源黑体系列设计相比于国产的商用字体并不能算好，有时间架结构比较怪异，字形的细节不太统一，比如“用”字明显矮了一截，整理风格上给人一种不稳定感。同时也不是一个大气的字体，比如口字旁处理对于黑体而言偏小，“用”字矮了一些，但是在宋体设计上，“用”字矮的这一截反而让字体看起来平衡。而一个系列的字体衬线、非衬线的统一感来源于其比例，个人理解为思源/更纱系列是优先考虑宋体的字形，和黑体的比例有一定的结合。整体而言还是宋体的设计更加优秀。

相对而言更纱黑体更适合作为系统字体，有着合理的 hinting。思源黑体是不太适合低 ppi 屏的，它的 Regular 字重看起来像 Bold。

方正兰亭系列（微软雅黑）

Noble Scarlet （社区版）常规体是新设计中宫收窄的微软雅黑，而粗体是方正兰亭黑 Pro，因此在加粗时，字体明显会变小一圈。

微软雅黑系列字体在标点处理上很差，最直观的就是全角引号，太像半角的处理方式，很难看出前引号与后引号的区别。其实我在写这一篇文的时候，换了 Typora 的字体，才发现前后引号全打反了……

方正兰亭黑 Pro 想对于两版微软雅黑都有着更小的中宫，字形设计中正。但也由于稍小了一些，在低 ppi 屏的小字上笔画更容易显得不太均匀，渲染效果不太好。另外使用此字体需要相比于其他所有字体更大的行距，因为其较小的中宫，字间距显得相对宽了。

汉仪旗黑系列

近年来的国产安卓厂商字体都是汉仪旗黑的衍生，代表阿里的普惠体、鸿蒙体、小米的字体、Oppo的字体。

这系列字体间架结构合理，但笔画上更加激进，减弱了起笔与收笔的的传统突出，以追求几何感与现代的科技感。在观感上，这样规矩的方形会使得字体相比方正系列更加圆润，多了现代感但少了汉字的人情味，用于阅读小说时尤其明显。

仅字形而言，作为 UI 是非常不错的。不过 Misans 渲染出来明显偏粗，我没有测试其他同系列字体是否也有这样的问题。

改掉 Windows 的默认中文无衬线字体

很多无法分别修改中英字体的 windows 原生应用，当只设置了英文字体时，显示的中文是新宋体（SimSun），比如 vs studio。原因在于系统里的 Microsoft Sans-serif 字体名，回落到的第一个字体就是新宋体……难以想象微软雅黑出了十多年了还有这样的问题。

解决办法：

• winkey + R, 输入 regdit，进入 windows注册表
• 进入 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontLink\SystemLink
• 把 Microsoft Sans Serif 的值中 SIMSUN.TTC 那一行去掉。这样默认的无衬线体就会往后 fallback 到系统的微软雅黑上。
• 把 Segoe UI 的 TAHOMA.TTF,Tahoma 挪到 MSYH.TTC,Microsoft 后面

创建于 2023-09-29 02:25:44

• 2026-03-25 更新：针对苹方字体资讯更新，增加字体替换说明。

更新：1.20.1 版本 mod 列表，有详细的 mod 分类与依赖关系。大部分为实用工具

在 Minecraft 1.20 版本光照引擎被大幅改写，使得帧数提升，模组的数量似乎又多了起来。另外在 fabric 发展起来以后，mod的社区生态有了很大的变化，有很多老牌模组有了更新的替代。现在记录一下实现常用的基本功能需要的模组与修改设置。

我使用的 hmcl 启动器，在其中进行模组下载可显示模组间的依赖情况。以下内容在 1.20.1 中完全兼容，且项目均在维护中。

1. Mods

MC 是一款肝度明显过高的游戏。mod 的选用主要是为了：

1. 使画面养眼
2. 降低肝度，同时少引入额外的快捷键
3. 优化细节使用体验

使用以 fabric-api 构建的模组。

1.1 渲染类

• Sodium: 渲染优化之神，许多模组的前置
• Sodium-extra: 渲染优化之神的扩展，相应 GUI 为reeses sodium options
• Lithium: 原版机制的算法改进
• Iris: Sodium 加光影
• Custom Entity Models: 自定义实体模型，增强对 optifine 材质包的支持
• Continuity: 无缝纹理，安装后需要启用相应的材质包。对第三方材质包支持一般，主要和 optifine 的格式还是不一样。
• Indium: 许多模组的前置，提供 Fabric Rendering API的支持

1.2 功能类

• modmenu: 显示所有模组和相应的设置页面（如果有的话）设置为 \ 开配置
• carpet: 单人生存必备，可使用命令放置假人以常加载区块刷红石
• tweakeroo: 一系列微调的小功能。主要使用 freecamera（灵魂出窍）f5以获得更好的摄影视角，zoom 开启类似 optifine 的按 c 视角放大，handrestock 可自动补货手里的工具、方块
• xaero's minimap: 小地图，降肝度必备。需要设置一下显示的东西，默认会非常多，我只开启了玩家、时间、坐标。关闭了网格显示和生物显示。有世界地图和世界地图的 Plus 版本，联动领地声明功能（虽然单人用不太到）
• Carry on：手里没有东西时，shift+右键 搬运箱子，降低装饰的肝度。
• JEI + EMI + 通用拼音搜索: 物品搜索，查看合成配方、查看方块用途，EMI 增加了查看合成树，在 JEI 的 r 键可看。切换可合成物品。
• Invertory Profile Next: 高版本的 R 键背包整理（但被我改成 z 键整理，R 键通常是 JEI 查看合成表）。自动补充工具、连续合成、捡物品时默认扔到背包中，以及在打开箱子时使用滚轮移动物品。关掉快破损时替换工具。
• imblock: 输入法冲突修复
• Panda's falling tree：砍树时树会倒下，降低砍树的肝度。
• Leawind's Third Person: 更好的第三视角。这算是第一个可以日常使用的第三视角模组，挖方块瞄准都很方便。日常的垂直平滑 0.5 以上，不然爬山能晕死。特点是不绑快捷键。
• better combat: 动作战斗优化，攻速和攻击范围都有反馈了。
• Litematica：投影。辅助红石机械建造，也算是一种降生存建筑的肝度。使用相当简单，一根木棍，control+滚动切换模式，快捷键进菜单。最难的其实是收集足够多的预置模型。但这个模组，要抢 Map 的 M 键……键位需要大改。
• Hey Wiki: 在指向物品时按 h 键查询wiki。在物品越来越多的高版本具有一些引导作用。

1.3 新物品

• Gliders：类似塞尔达的滑翔伞，防摔。在空中按空格展开滑翔。使用方式和大部分游戏一致。只是要占一个盔甲位。动画做得很不错。
• Waystones：传送石碑，后期物品，降低交通的肝度。如果用地图作弊路径点传送就不需要这个东西了，但理想的玩法还是地图只是用来看的，让传送石碑在地图上显示（需要前期多刷小黑），只能传送石碑处，禁止任意传送。传送石不是个好设计，MC背包不能放下更多东西了。除非有单纯扩容用的背包模组。
• travelersbackpack：背包模组，终于有了 fabric 版。虽然 mojang 一直很谨慎地加入新的方块，但似乎从未考虑过方块越来越多时的背包使用问题。再者模组整合包也因为方块种类数爆炸的问题增加背包模组。在 1.12 版本时，背包容量是刚好够的。个人并不是很喜欢背包的设计。

2. 设置

• 画面尺寸: 1920*1080@60fps，窗口化
• 视场角: 85
• 鼠标灵敏度: 75
• 模拟距离：8
• 渲染距离：12

2.1 快捷键修改

总体的键位映射图如下。深绿色为原版的功能。橘色为Mod功能，蓝色为创造模式功能。键位分为直接按键、组合键、修饰键（长按）。MC 原版只能定义直接按键，组合键与修饰键在复杂的 mod 中用得多，并且会覆盖原版的直接按键。

游戏主界面

首先把 ctrl 改到 capslock 键位，方便疾跑。系统全局 powertoys 改的（吐槽一万句control的键位）

• 长按 tab，滚轮切换物品栏。在tweakroo 的「工具」中开启 hotbarscroll，再在 tweakroo 的「快捷键」中把 hotbarscroll 的快捷键设置为 Tab。
• v: 切换第三人称视角(visual)，很常用的功能。原本是f5，实在太远了
• f4: Leawind's Third Person 第三人称视角相机调位置。同时关掉左右切换。点按左右，长按居中
• f5: 灵魂出窍，在 tweakroo 的 freecamera 中设定
• c: 望远镜，在 tweakroo 的 zoomactivate 中设定
• b：开背包（如果物品栏有的话）
• t: 路标点传送管理(transport)。聊天改 enter 键
• x: 锦致装饰-箭袋
• m: 显示大地图和设定。地图的其他快捷键全关掉。
• n Litematica 投影菜单
• h Hey Wiki 查询指向的物品 Wiki
• shift+右键 空手时搬运箱子，carry on 自带。
• \ Mod Menu配置
• n+c Litematica 配置。n系列特别多键。
• x+c tweakroo 配置

特定工具下的修饰键：

• 木棍工具
  • ~ Litematica 木棍工具修饰键，改变区域大小
  • n+enter Litematica 木棍工具模式5且创造模式下放置投影

预留键位：

• g 圆盘菜单
• ~ 特定工具修饰键，比如连锁挖矿
• b 背包(backpack)
• j FTB任务书(journal)
• 左alt 创造模式下，建筑模组 axiom 用 alt 切换专用物品栏。

合成台、箱子UI

• r : JEI 查看光标下物品的合成方式
• u : JEI 查看光标下物品的用途
• ctrl + 左键点击 JEI的物品，移动物品到合成台
• z : 一键整理。在 IPN 的设置中修改。
• 使用滚轮以在背包和箱子间移动物品，按shift移动整组

3. 光影

• BSL v8.2.04，默认配置High，把 Camera 中的 Bloom 关闭，把 Atmosphere 中的 fog 调到 0，开启 lighting 中的handDynamicLight。抗锯齿的TAA随便开不开，取决于风扇响不响
• Complementary Reimagined，配置 medium，high 会开启材质的反射运算量明显变大。夜晚也比较亮，适合生存。
• itt 3.0，更适合搭配了写实系材质的建筑，风格最写实的 shader 没有之一。不适合生存。

4. 材质

• 任意矿物发光材质。比如 New Glowing Ores。主要是因为 BSL 光影没有矿物发光，所以要加一个材质以确保有 fallback。
• 彩虹像素，非常优秀的免费猛男材质包，原版风但更精致。有很多更可爱的附加包。

5. 创造模式附加

5.1 Mod

Axiom 高版本环境必备，可以创建实体方块随意拉伸模型，相当好用。

effortLess structure 快速建造几何体。原 effortless buidling。

lotweaks 自定义材质轮盘

wordedit 经典创世神

快捷键

tab: effortLess structure 轮盘。

r: lotweaks 轮盘，和手中方块有关。会禁用丢东西（但创造模式本来就不用丢东西除了篝火灭火，何不用 Axiom 的调试棒？）

左 alt： Axiom 的大菜单

摘要：本文针对前端中多个元素层叠时 z-index 管理混乱的问题，提出一个名为海浪模型的设计模型，以构建复杂 z-index 管理的最佳实践。

……好像 AI。但我是人，我纯手打的。

基础知识 - 代码的画布

层叠上下文是代码逻辑上的画布。一旦一个元素产生了层叠上下文，它内部的所有子元素就被包裹在这个范围里。

层叠上下文的产生

• 根元素：<html>
• 定位 + 层级：position 为 relative / absolute 且 z-index 不是 auto。
• 固定定位：position: fixed 或 sticky。
• CSS3 属性：
  • opacity 小于 1。
  • transform 不为 none（比如旋转、缩放）。
  • filter（滤镜）、flex/grid 子元素的 z-index 等。

❗注意：层叠上下文的产生，和层内元素关系，是两套规则，两者之间没有关系，没有关系，没有关系。因为部分规则相似，很容易给记混了。

层叠内元素关系

为了好解释，我使用 context-level 说明绝对的上下覆盖关系。

• CL-1: 背景和边框（最底层）
• CL-2: 定位元素（如absolute）且负 z-index
• CL-3: 块级元素（static 定位的普通 div 等）
• CL-4: 浮动元素（float）
• CL-5: 内联/行内块元素（文字、图片）
• CL-6: 定位元素（如absolute）且 z-index 没有设定为负，还有 opacity，transform 等。
• CL-7: 定位元素（如absolute）正 z-index（最顶层）

z-index 在其中的作用相当于是一个算层叠关系的插件。必须和定位配套使用，否则不生效。

从功能上说，层叠上下文才是真正面向用户的Z轴，z-index属性只是这个 z轴的一个插件。

视觉画布

可以发现，被提升到 CL-6 的层，其规则和产生一个层叠上下文高度重合，就像产生了一个新的画布。这也是为什么说，容易把 CL-6 层等同于产生层叠上下文的层，但是不是的，CL-6 是描述自己作为子元素的层级，而“产生层叠上下文”描述的自己作为父元素的行为。

• opacity 且 z-index: 0。位于 CL-3，产生了层叠上下层文，但是其实层级很低，z-index 是无效的。
• CL6: relative 且 z-index: auto。位于 CL-6，产生不了层叠上下文，其子元素如果有更低的层级，可能会被盖掉。子元素有更高的层级，会盖掉别人。
• CL6: relative 且 z-index: 0。位于 CL-6，产生不层叠上下层文，其子元素层级和当前元素严格一致。

理解了这一点，可以记住。在做目录头时，并不是设置了 relative 就万事大吉了，如果你的后面的元素也是 relative，很容易被覆盖。

z-index 划分

考虑到我们不可能把所有画布内元素全挤在 CL-6，全靠 DOM 关系划分层级，因此需要设计 CL-7 的层级，也就是正 index 区域。

正 z-index 的画布内元素应处于同一个层叠上下文内。如果不在同一个，则按产生了新的层叠上下文设计。

基础逻辑

对于一个画布（层叠上下文）内，我设计新产生的画布设计上分100层。对应 z-index 0（CL-6）到 z-index 100。每 20 层为一个全屏大画布，比如 Modal。也就是

• 0-20：画布内组件层级
• 20、40、60、80、100：新画布层级

那 21-39 有什么用？没有用，不要用。只是为了提醒你，这个东西是个大画布。如果把画布内组件设定到了 20 以上，你可能就不知道什么东西溢出到了 Modal。

此外，如果真的想做一些在不同层级上换来换去的小组件，也可以根据模型的定义很快决定放到哪个层级，非常方便。

海浪模型

想象一个海星被 5 层海浪（大画布）冲到沙滩上，每一层海浪上有自己的生物群。

大部分生物都挤在海底（0层以下）层，形成了基石。到第 0-19 层有一堆小东西争先恐后地彰显存在感，但是你又觉得不那么重要。之后的20层、40层、60层通常而言清澈透明，但一旦染色后，就会将下面的生物变得不见天日。

此时你觉得这个海星，你应该看到它吗？应该放在哪一层？

通常而言，层级设计遵循以下基础逻辑。

• 大尺寸元素的层级低小，小尺寸元素的层级高。
• 重要性高的层级高。

第一条是一个视觉规律，第二条则是功能需要。

0-19 层

根据基础的逻辑，0-20 层我会如下划分。

• 移动端菜单栏 -> 中偏小，重要，9
• 浮动按钮 -> 中偏小，但不重要，5
• 侧边栏 -> 大，但重要。你很难说和浮动按钮哪个在上面。这两个要权衡一下，给到 4。
• Hover tips -> 小，重要，19
  如果 Hover tip 也可能本身是一个交互丰富的大画布，这时要看重要性。如果重要性与 Modal 相当，设到 20（新一层海浪）。如果只是随便看看，共享当前层的主要内容，只是覆盖一下正文，设到 0 或 1。大画布谨慎设置中间值，容易造成混乱。
• 目录头：暂时一下冒头，给到 0（注意是 z-index:0，不能是 z-index:auto）
• 拖拽：暂时冒一下头，给到0。

在海浪模型里，带 9 的数字被表示为重要，而整十数表示为新的起点。

20、40、60层

几乎为 Modal 层。通常页面上只会出现一个Modal，20 层足够使用，或者你要设置为40，60，都可以。如果你有很多层 Modal 要排序（窗口管理）。要么从 z-index 入手，要么从 DOM 结构入手。显然，别去动 DOM 结构树，靠 z-index 足够完成窗口层级管理。

最重要的海星

这个海星如果你认为是稀世珍宝，任何时候都需要被看见，请直接设置到 999。但一旦，你认为它有可能会被覆盖，请思考它被覆盖时，是不是还是这么重要。

如果不确定，参考基础逻辑：面积越小通常越重要。这不是一个我定义的规则，而是客观的视觉逻辑。面积越小，通常代表了信息量越密集。一个很常见的对比是：

• Hover tips（小面积）：在一个层非常非常重要。但需要被新画布覆盖
• 消息通知（中小面积）：重要吗？超重要的，但是消息通知上是不是还是应该可以 Hover 一些提示？
• Hover reference（大面积）：比如参考。重要吗？很重要。但是你觉得需要被消息通知、进度条覆盖吗？需要。

天空层（1000+）

总有些东西，你希望他们不要在海浪里浮动，而浮动在天上，不被任何东西覆盖。比如全局进度条、全局 Hover、全局消息。

放在天空的这点问题本身不大。最大的问题是，你觉得这个海星，应该放在海浪还是天空？不要让本该在海里的海星升天。一旦你觉得这个海星会被新逻辑的 Modal 覆盖，请让海星立刻返回 0-19 层。

为什么要思考海浪模型

• 易于复用：对于可复用的浮动组件，不管其父元素的 CL 层级，总能被安插到正确的位置。如果发现异常，那就是忘了使父元素产生层叠上下文来包裹他
• 避免混乱，减少设计的心智负担

• 书名：Better Web Typography for a Better Web
• 译名：更好的网页排版，造就更好的互联网

此书为 90% 的 AI 翻译，完全保留原书排版，由人工校对以确保大部分用词统一。

推荐语

2018 年，我还在大学社团做海报，那时候对排版的理解更多是靠“直觉”。直到接触到了 Matej Latin 的网页排版公开课，也就是这本书的起源。课和中提出“排版的完美等边三角形”——即字号、行高与行宽之间的动态平衡，以及“模块化比例”的概念，彻底改变了我观察网页的视角。我至今铭记在心：“要获得完美的段落，需要三样东西：字体大小、行高和行宽。它们需要达到平衡。”

从那以后，这三要素就成了我做阅读文字时绕不开的底层直觉。每当我看到一个网页，总会下意识地去拆解它的文字比例是否协调。尽管此书以英文为基准，其中的排版规律对多种语言均适用。

虽然这本书写在八年前，在互联网平面设计风格迭代如此之快的今天，它讨论的核心规则却依然稳固。甚至可以说，如今主流的网页排版方向，就如书中的所言。如果你想摆脱“凭感觉”排版，真正理解排版的美学逻辑，倾情您阅读推荐这本书。

简介

Better Web Typography for a Better Web 是一本源自高分在线课程的著作，旨在向网页设计师和开发人员等网站构建者讲解排版。作者 Matej Latin 将垂直节奏（vertical rhythm）、模块化比例（modular scale）和页面构成（page composition）等复杂概念，以通俗易懂的方式进行了深入浅出的解析。本书配有实时代码示例，读者在阅读过程中将亲历设计并构建一个示例网站的完整流程。这是一本针对新媒介的排印新书：基本规则虽未改变，但除此之外的一切都已焕然一新。

摘录

1. “……如果说我希望你们从这次演讲中记住一个关键要点，那就是以下内容——要获得完美的段落，需要三样东西：字体大小、行高和行宽。它们需要达到平衡。”
2. 大多数网站都会犯的一个错误，就是将主体文本设置得过小。早在21世纪初，将主体文本大小设置在大约11像素是常见的做法。但当时的屏幕更小，分辨率也较低，这意味着11像素的字体在当时看起来比现在更大。
3. 推荐文本行长度为45至75个字符。需考虑所用语言的平均词长。
4. 我认为，我们开始创建网站时，首先应该审视网站的主要目的。不仅仅是我们正在设计的特定网站，而是其真正、根本的目的。我指的是——内容。试想，没有内容的网站是什么？它是一个空壳。内容糟糕但外观精美的网站是什么？它就像一个外表好看但缺乏个性的人。那么反过来说呢——内容出色但外观贫乏的网站？它就像是一个个性鲜明、趣味十足的人，却因为“外表不够标准”而无人关注。

资源链接

CloudFlare - R2 直链下载：

• 更好的网页排版，造就更好的互联网 - Matej Latin

标签： 排版，字体排印，平面设计，网页设计

创意 #分享

• Floor 796一个全是角色的网站，好喜欢的风格

看了下网页几个轻拟物做得比较好的，比较有趣的是 box-shadow 的 inset 属性在加投影前都是凹进去的，一加投影就变凸了。所以要做凸先做投影，外部的颜色必须要更深，不然不符合凸的素描关系。

（顺便凹凸的五笔还是那么难打……）

另外，如果要模拟更真实的效果，需要多重投影 模拟光线的弥散。

以及悬浮效果，需要让投影的面积更小。感觉是模拟的真实世界的漫反射光线。直接投影的效果更像是有磨砂镜面反射。也能够说明为什么用单层外扩的 spread 颜色一深就丑了，这不符合白天光线的素描关系，只在夜晚/摄影棚出现，会显脏。

听黎明和萤火虫还是很好哭，即便拿不拿是一个确实不太会唱歌的人，但这首是真的很喜欢……我相信声音比视觉更容易传递情绪。

2025-12-27 02:11:50

唉，想做设计。真的论文会塑造得人挺无聊的，好不容易摒弃了因果学术那套，也好不容易终于有了点想表达的方向，又被拉回去。在大模型时代反而冷静下来不再追求将人工具化的效率，而更珍视人与想法本身。

2025-12-18 02:58:11

#工具

• cc-switch 中转站API切换GUI，MCP、Skill 管理和配置
  在国内只能使用中转，因此有个 GUI 管理还是方便一点，另外 Skill 也 MCP 也能管理。我不太用 MCP，原因是烧不起，有那种 5 倍 token 干 1.5 倍的事的感觉。Claude Code 的调用方式已经觉得烧不起了。在这之前是终端写了几个设置环境变量的函数来凑合一下的。

真的蛮想复刻一下 ChatGPT 的深度研究 的，做好了帮找论文确实好用，但同时也是 token 杀手。Gemini 的深度研究我觉得不太好用，有太多不够权威的结果。Chatgpt 查的都是专门的学术网站，查不到会触发近义词搜索什么的，非常接近人类找论文的状态了，但调研一次 5刀 token 真的是轻轻松松，论文那四五个点的调研天天查天天改，反复迭代，最后留的都有百篇 reference，真的是查吐了。

至于国内豆包那个结果，我只能说，图一乐……

另外 MCP 我觉得是一个概念先于应用的东西。与其是协议，更像插件 API 规范，MCP 的 P 不应该和 HTTP 的 P 坐一桌，而是和 command/API 坐一桌。LSP 和 DAP 的 P 都比 MCP 像协议，好歹人家是需要全程起一个进程才能给这个进程发消息的。

因为老被说是协议关系，经常会有一些令人误解的描述，比如：“LLM 调用 MCP 工具”。如果说 MCP 真的是印象中的协议，应该是 LLM 发送特定协议格式 mcp:// 给 MCP Server， MCP Server 返回结果给 LLM。但实际上呢？ 是 AI 客户端在 把 MCP 和 toolcall 这两种 API 互相翻译两边倒。MCP Server 也不需要“在线”，只需要是一个随时被 AI 客户端调用的二进制。换个说法，难道你会使用把 「“今天需要commit" -> 使用 git GUI 调用 git commit-> ”告诉 leader 我commit了“」的全过程称为一种协议吗……

甚至可以说 MCP Server 一整圈的定义和 LLM 毫无关系。反正都是处理用户输入，MCP只参与到 「“今天需要commit" -> 使用 git GUI 调用 git commit」，后续结果告诉不告诉大模型关 MCP 什么事 。连第一步 ”今天需要commit“ 也可以不需要 LLM 的参与，你可以直接做成 /commit 调用 MCP。这就是 tool，是个被调用的东西。

另外就 RAG 这个东西总感觉最近风头已经过了。总觉得没理由做好用，瓶颈在向量相似度计算方式上，因为到客户端的相似度计算阶段是简单的线性的数学方法，拟合空间极其有限。前期 embedding 生成模型怎么优化都救不了。新生成的两段 Embedding 等于两个东西之前没有上下文信息也不存在注意力映射一类的，直接线性计算个几层太简单了。如果要做基于注意力机制的相似度推理，检索速度就不行。

2025-12-15 10:53:00

剧 #分享

• 流星花园 看到说是台湾超雄情侣搞笑片所以补了，放到现在这剧情可能会被喷死。当年看剧大家都不带脑子，只是觉得很欢乐。现在看剧都比较上纲上线。不过确实是嗑不到了，男主幼稚和自我中心得有点无语，但放在从前不像现在，从前基本上就是谁爱得多就是谁在付出的观念，也因此道德绑架现象比现多。道明寺吼得厉害，事实上是没有付出什么，他一直在向女主求爱，可女主经历的一切都是他带来的，而他没有能力解决问题，反而在女主最困难的时候视而不见。花泽类是F4里唯一一个靠谱的人。然后女主的塑造也是反复横跳，编剧为了写感情线硬让女主欠男主100万。倒是里面的姐姐都很靠谱，gl真的好嗑。
  感觉看太晚了，这部剧好多人撑起了后面十几年的星周刊。

我好困，写两小时躺两小时，又通宵了，感觉心脏乱跳像要猝死了。而且好饿。没有皮质醇完全醒不了。

2025-12-13 02:59:22

小红书莫名其妙有一条画给推了出去……之前我高强度改画了几天有点 Get 到小红书算法给人的推流感觉了。初始互动率高于一切，评论>点赞，有人评论就多下场聊，得让人感觉能有话讲而不是真好看赞一个就完了。况且画得又没有那么好看。

最近领悟到一个事情是，画画就是一个纯感觉的事情。现在越来越多讲画画技法的了，和从前的条件天差地别。但画画用学技术的目的是和纯技术工种不一样的，学技术是还为了提升感受，去拼效率的话是打不过AI的，真的画得很好的人最终胜在表达而不是技法论。不过以上前提是基础好，真正扎实的基础说实话是无关技法的，如果说换个笔刷都画得很烂了只能是基础本身不够好，就和写字一样，基础好的用啥写都好看，换了个烂笔可能感觉很痛苦效率下降，但如果时间足够，对成品质量不会有太大的影响。

另一个感觉是，画画基础其实是种感受，而不是理论。诚然你可以画透视线去推算是否正确，通过建模分析光影与亮暗，但这样可能会把“体积就是要画得伦伯朗那样黑”奉为圭臬。然后近代流行了对比后，又加上“体积就是在短调子里画得伦伯朗那样黑”。直到你看到一张图，几乎是色彩关系画的超强体积……嗯这次又要加个什么理论进去呢？到底什么决定了体积感呢？物体距离人眼的呈现的规律性色彩变化？但你看平设Icon，他们体积感又很强吗？然后再加一条，有规律变化且有明确的面的拐点……我觉得我理解体积是什么这事真的花了有五年，最终不得不承认回到了原点……体积是种感受。而我是那种体积感天崩选手，仅有的天赋点全去色彩上了。

说回来在 AI 出来之前我是把喜欢分条列点的大纲的，视觉形式的实用主义者觉得这样很清晰。论文那样的写法对于Ne人非常不友好直接一整个大分心重点跑偏。但思维链 AI 出来之后，这所有东西都是分条列点的 Ne 味已经被滥用了……我觉得seq2seq本来就是天然Ne，使用大纲能增强抓重点的逻辑能力不奇怪，但有的东西真的不是 Ne-Ti 能解释的，过于强调逻辑也是一种非人感的 Pattern，但不强调逻辑上下文一长又在胡说八道……Fine，也不能说是一无是处吧。但是处不多。

2025-12-12 22:33:55

说来为什么静态博客能不能依赖就不用，其实只是我不想经常更新依赖。总想写点新东西不想把时间耗在维护上，而且维护这个什么也得不到。社区的项目大抵也是一样。其实我想把nextjs也换掉，ssg能力严重影响我细化过渡动画。

Python 新项目使用 uv 管理容易，但是总是有一些老项目不用。 conda 包管理一直以来都是 AI 的标配。我用 python 99% 都是在扒别人代码运行。这就导致了我运行了多少个项目，就装了多少份 torch……硬盘再大也经不起十几次折腾。

conda 的问题在于

1. requirements.txt 全手写！很多人可能忘更新配置，导致扒拉下来缺库运行不了，先解决一个小时的依赖问题再说。
2. 依赖和安装顺序强相关。比如项目需要更新的 numpy，但你可能要装个别的项目的库，python 发了论文和仓库就跑的项目是很多的。安装一个旧项目导致之前安装 numpy 被卸载，然后整个项目就垮掉。这种情况相当之多，又解决两个小时的依赖问题。
3. （至少我不愿意看到）电脑里十几个相同版本的 torch 和 cuda。当时的硬盘还只有 256G，多装几个 torch 无法接受，嗯……

直到现在都还是这样的，大家主打一个能跑完实验就行。包的更新是激进的，包管理是落后的。在几年前有人说用 PDM，后面有 poetry。这两是不用再手写 requirements.txt 了，依赖也会自动 resolve 不会覆盖来覆盖去的，但还是会装十几个 torch。直到 uv 开始用硬链接进行包管理。

uv 之于 conda 项目

uv 接管 python 界的依赖管理按理说已经没什么问题。但实际情况是，很多项目还是在用 conda。除非哪天 torch 和 HF 都把 uv 设置为首推，否则就得一直与 conda 存在的问题战斗。

1. 不提供 venv 的项目

用于研究的项目一般都是不提供的打包好的环境的，主要是太大了，每个人设备情况也不一样。所以下载后第一件事是

uv venv
./.venv/Script/activate

如果这个项目不再更新了，或者是打算迁移到 uv，可以直接使用 uv 的方式管理依赖。uv 会自动维护 pyproject.toml 和 uv.lock 文件。

uv add -r requirements.in -c requirements.txt

如果这个项目，他还在更新，你时不时就得去拉一下分支。这时候最好用 uv pip 。至于依赖混乱问题，听天由命吧。跑得起来就得了

uv pip install -r requirement.txt

2. 提供 venv 的项目

提供 venv 的项目通常是给人用的，b 站的整合包一大堆。这种已经配好环境的项目也意味着你最好只用 pip。通常还是非常原始地调用 pip

./.venv/python -m pip install xxx

……等于说又开始了安装十几份 torch 的依赖管理模式。用 uv 是可以重复利用缓存的。这个时候 uv 的问题在于无法接管 python 环境，需要设置一下环境变量：

export UV_PYTHON="./.venv/python"
uv pip list

然后就可以利用 uv 的缓存了。

当然，依赖混乱问题使用 uv pip 是无法避免的。这对于发行版也是一种麻烦。因为发行版的环境全给你配好了，但有的项目设计了插件系统，插件系统又需要装插件的 requirement.txt，安一个许久没更新的插件让主项目废掉的情况也不是不可能……

如果让插件作者指定的兼容版本？只靠规范做不到，必须像MC那样检查版本号，不更新版本号就不放行。这样就算不更新代码了，也得倒逼作者每个版本都进行一次（至少是与主项目的）依赖兼容性测试。

我觉得以当前 python 的运行方式，不 lock 子依赖的版本，这个问题是没法解决的。

uv 管理 torch 下载源

通常而言，在不指定 index 时 uv add torch 是去 pypi 或清华镜像源找 CPU 版本。如果打算每个项目都采用一样的 torch 版本 和 cuda ——

uv 创建的新项目

共用的 uv.toml 指定下载源。

Linux 在 .config/uv/ 下，Windows 在 %APPDATA%/uv/ 下。

[[index]]
url = "https://mirrors.tuna.tsinghua.edu.cn/pypi/web/simple/"
default = true
[[index]]
name = "pytorch-cu128"
url = "https://download.pytorch.org/whl/cu128"
explicit = true

项目级别的 pyproject.toml

dependencies = [
  "torch>=2.8.0",
  "torchvision>=0.23.0",
  "torchaudio>=2.8.0",
]

[tool.uv.sources]
torch = [
  { index = "pytorch-cu128"},
]
torchvision = [
  { index = "pytorch-cu128"},
]
torchaudio = [
  { index = "pytorch-cu128"},
]

然后执行 uv sync 安装。

uv pip 管理老项目

直接指定命令行 的 --index-url 和 --torch-backend

uv pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu126 --torch-backend=cu126

和用 pip 的方式差不多，区别是会硬链接到集中的缓存，不会重复占用十几份 torch。当然。该有的依赖冲突还是会有的。关键是装好后就不要更新了

CSS类复用粒度

我自己把 css 选择器（类）的复用粒度分三个层级。

组件类

粒度最大的层级，通常按组件级别语义化。选择器一般是下面这些名字

.wrapper
.container
.list-item

组件化的选择器下面通常有很多条的 css。

功能类

通常是共用的样式或状态，比如

.open
.close
.light
.dark
.glass-effect

这个看起来好像和组件类不冲突，但硬说的话组件类其实应该是这样

.container.open { 此处将 .open 的所有样式全覆盖 }
.container.close { 此处将 .close 的所有样式全覆盖 }
.container.light { 此处将 .light 的所有样式全覆盖 }
.container.dark { 此处将 .dark 的所有样式全覆盖 }

组件类的状态严格在组件的 scope 下。功能类则是可以不限 Scope 的复用。

这 CSS 容易混乱的根源。在工程维护角度，功能类是最不敢乱动的类，不知道动了后哪里样式就会出问题。但在设计角度，用功能类复用一些状态又确实很方便，统一设计也好用。比如增加统一的圆角、描边、阴影样式。

功能类的优缺点是一体两面——图像的只有主观的好看与否，没有客观的对错。

原子类

定义海量常用的基础样式类，在 class 上直接写类名就能获得对应效果。就是 tailwind css。

原子类相较于功能类粒度更小，也不会轻易改动 css 属性。

.flex
.col-1
.text-sm

方案

通常来说，一个库的样式会着重在一个某一个粒度上。

原生 css

用原生 css 时通常会以 组件化 的粒度为主，带极少的功能类。现在配合 css 变量使用。早期的网页简单，一个 CSS 文件就能搞定全站，设计上并没有考虑项目变得越来越复杂后的实践。

优点：性能好，扁平的结构利好小项目。适合写研究新样式。

缺点：过于扁平，大量工程化后易屎山，存在样式与 DOM 分离带来的维护混乱。

SCSS

古法预处理器，可能多层嵌套 css，可组合。是 组件化 的粒度。在 CSS.module 出来前，用 SCSS 分割 Scope 挺好用。

优点：结构非常清晰

缺点：

1. 编译后的选择器很长一串，从浏览器渲染角度，匹配DOM是耗性能的
2. 难以应对复杂项目 DOM 结构的改变，需要考虑扁平化 + 命名，但这样做和原生 CSS 的维护体验也不相上下。

CSS Module

CSS Module 是完全 组件化 的粒度。相比起 SCSS 的样式与 DOM 分离，CSS Module 为组件内部样式耦合，组件间样式分离。

优点： 在组件粒度分割合理的情况下，清晰易维护。

缺点：依赖预构建，写类名写起来太磨叽了。整体我用得不多没法评价。

const Button = () => {
  return (
    <button className={styles.button}>
      Click me
    </button>
  );
};

BootStrap

组件化 为主，少量原子化修饰的预制样式库，拿来即用是不错的。早期 CSS 框架大多是指预制样式，和预构建的库有本质区别。

Tailwind css

完全原子化的神奇之库，通过编译可以有功能类和组件类。它更像是重新定义了 css 语法。

优点

1. 灵活，快，好看
2. 工具链齐全，可以裁剪掉不用的原子类。

缺点

1. 稍微要写复杂一点的样式，DOM 就会被一大堆 class 埋没。
2. 从浏览器渲染角度，匹配、合并大量 CSS 样式是需要更多性能开销的
3. 要做到同种样式的复用，必须组合原子类，变成功能类或组件类，否则维护起来相当麻烦。这似乎违背了用 tailwind css 的初衷，熟悉了 css 的不如直接自己用 css 手撮功能类和组件类。
4. 其实我是 tailwind 黑，嗯。但无法否认开发时确实很快很方便。

function Card({ title, description, imageUrl, imageAlt }) {
  return (
    <div className="max-w-sm rounded overflow-hidden shadow-lg">
      <img className="w-full" src={imageUrl} alt={imageAlt} />
      <div className="px-6 py-4">
        <div className="font-bold text-xl mb-2">{title}</div>
        <p className="text-gray-700 text-base">{description}</p>
      </div>
      <div className="px-6 pt-4 pb-2">
        <span className="inline-block bg-gray-200 rounded-full px-3 py-1 text-sm font-semibold text-gray-700 mr-2 mb-2">#photography</span>
        <span className="inline-block bg-gray-200 rounded-full px-3 py-1 text-sm font-semibold text-gray-700 mr-2 mb-2">#travel</span>
        <span className="inline-block bg-gray-200 rounded-full px-3 py-1 text-sm font-semibold text-gray-700 mr-2 mb-2">#adventure</span>
      </div>
    </div>
  );
}

原生 css in js

指 JS Object 转译为 CSS。由于写起来太不像 CSS，复杂的功能写起来过于不直观 ，我直接 PASS。

const InlineStyleExample = () => {
  const myStyle = {
    color: 'blue',
    backgroundColor: 'lightgray',
    padding: '10px',
    borderRadius: '5px'
  };

  return (
    <div style={myStyle}>
      <p style={{ fontSize: '18px', fontWeight: 'bold' }}>
        This text is styled with inline CSS.
      </p>
    </div>
  );
};

Styled-components

组件化的 CSS in JS 方案，写起来像 CSS 实际是 JS。支持客户端动态修改 CSS 具体属性（其他方案做状态改变主要依靠 selector 的匹配）

优点：

灵活好拓展，比如主题管理不仅仅是颜色，还可以是图片资源一类的。

缺点：

1. 因为是 JS 转 CSS，服务器编译慢和客户端渲染慢得选一个
2. React 的 useContext 要被废弃了，而 styled-components 严重依赖此 hook，导致进入了维护状态。JS 框架发展太快了。

import styled from 'styled-components';

// Create a styled button component
const StyledButton = styled.button`
  background-color: blue;
  font-size: 16px;
  padding: 10px 20px;
  border-radius: 5px;

  &:hover {
    background-color: darkblue;
  }
`;

function App() {
  return (
    <div>
      <StyledButton>Click Me</StyledButton>
    </div>
  );
}

Linaria

自定义 功能类 的 CSS in js 方案，同时也支持 组件化 写法。生成的是完全静态的 css，样式值的复用靠变量，片段的复用靠 css 生成的类。

优点：

是预构建方案，在服务端渲染。和原始的 CSS 写法和思路差不多。

缺点：

1. 值复用靠变量，但是由于是 静态 css，这个并不会变。所以变量插值其实是常量。比如下面的 font-size 并不会变化。

   const fontSize = 16;
   const Title = styled.h1`
     font-size: ${fontSize}px;
   `
   

   也就是说，你如果想在客户端随意改变字体，用 context/zustand 这种 runtime 的 fontSize，这样写报错。不过，Linaria 允许你借助 react 的 props 和 styled 组件来实现客户端的值变化。

   const Title = styled.h1`
     font-size: ${props => props.size}px;
   `
   export default function MyComponent() {
     const fontSize = useAppStore(state => state.fontSize)
     return <Title fontSize={fontSize}>Hello</Title>
   }
   

   相当于生成

   <h1
     className="_title_xyz"
     style={{ '--linaria-font-size': `${size}px` }}
   >
   

   那这和 styled-components 写起来已经差不多了。而且要做主题化的值都得用快要废弃的 useContext API。只不过 linaria 改的 style 属性，styled 是改的 css API。改 style 属性其实已经不能算静态了。

2. 组件间的样式复用方案只有原生的 CSS 方案，上述的奇妙客户端插值做不了这个需求。假设，你要做一个主题化的对话框的卡片阴影，只能使用原生 css 类中加原生 css 变量。上述动态改变样式的因为依赖 props，只能使用 styled 的写法，但这样就会把 html 标签了也继承了，不同的样式也无法随意组合。这也是为什么我说 Linaria 是原生 css 的替代，而不是 styled-components 的替代，构建方式就决定他们差得太了远。

3. 基于2，导致你写组件又要检查 styled 又要确认 css 类又要检查 JSX classname 的顺序。如果用组件继承会被迫连 DOM 类型都继承。

4. 使用功能类有点像原子化，又完全不如 tailwind 已经给你预设好一堆东西的效率。写类名和 cssmodule 一样，太磨叽了

我博客本想迁移至此方案，但由于工作量实在巨大而放弃。linaria 主要还是解决了个命名空间冲突的问题，想用得更深入一点就会四不像。

import { css } from '@linaria/core';

const eleStyle = css`
  color: red;
  font-size: 3rem;
  &:hover {
    color: blue;
  }
`;

function App() {
  return <h1 className={eleStyle}>Hello Linaria!</h1>;
}

export default App;

构建组建库

每一个 CSS 方案都有对应的构建组件库的实践。 shadcn 是基于 tailwind 构建组件库实践。

CSS 框架选择要素

1. 样式复用
2. 样式组合
3. 动态样式
4. 主题切换
5. 代码提示
6. 自动裁剪
7. 随意重构
8. 渲染性能
9. 实践的统一性

最重要的还是自己的需求。

下载验证

steam 的下载鉴权流程是

1. 查找账号是否有拥有此游戏，有则显示下载按钮
2. 点击下载后，把游戏软件 Manifest 对应的密钥（DecryptionKey）明文写入一个本地文件 Steam\config\config.vdf
3. Steam （原版）根据 config.vdf中的信息，发送下载请求至 Steam CDN 进行下载

“Steam 解锁” “Steam 假入库” 指的是绕过上述机制。具体而言，如果没有购买游戏，可以：

1. 将按钮变为可下载（至于是伪造请求实现还是逆向 hook 实现，我不知道，都可以，因为甚至不需要变按钮，给个外部的下载按钮也可以）
2. 点击按钮后，从不知名渠道获取一个正版账号的 Manifest（下载清单）和 Decryption Key（下载密码），写入Steam\config\config.vdf
3. Steam（原版）根据 config.vdf，发送下载请求至 Steam CDN 进行下载

Steam 的下载验证可以说是相当简单，明文本地存密码，CDN 无状态的验证，这么多年没有改过流程，给入库工具空间（虽然说前端的事总有办法 Hack 但也是可以让 Hack 成本变高很多的）。不过 Steam 理念本来就是以平台服务留住玩家的，反倒是扩大了其影响力与营收。

一些名词解释：

• 解锁：指对没有购买的游戏，“可以显示下载按钮”。和能不能下载没有关系。
• 下载：Steam 根据 Steam\config\config.vdf 的信息下载游戏文件。
• 入库：指把下载好的游戏，在当前电脑的 Steam 库中显示。

以上过程均不涉及对游戏本身的破解，只是对 Steam 下载过程的破解。也就是，破解的是 Steam，不是游戏。

运行时验证

这里开始才会涉及到游戏破解。

有的 Steam 游戏下载下来后是不用破解的，直接找到游戏目录，点 exe 可以正常游玩（比如星露谷）。只是无法通过原版 Steam 打开，也就只能离线。

有的游戏是无法脱离 Steam 直接运行的。这里涉及两层验证：

加密算法层

这是一层 DRM（数字版权加密保护）。Steam DRM 系统的名称为 SteamStub。SteamStub 的加密有各种的变体，每个游戏使用的不一致。只对 exe 的算法加密，是一个离线的步骤。不涉及 Steam 平台的验证。

网上有一个开源工具叫 Steamless，可以破除 SteamStub 对游戏的 DRM，称为脱壳。但脱壳本身不处理 Steam 在线验证相关，只进行了脱壳的游戏也是无法正常游戏的。

SteamStub DRM 和 Steamworks API 是两个独立层。Steamless 仅移除 SteamStub 加密外壳，但游戏代码中与 Steam 平台功能（如成就、云存档、联机）相关的 API 调用（通过 steam_api.dll）仍会保留。

Steam API 验证

游戏还可能调用 Steam api 进行在线通信，如成就、云存档、联机相关的 API 调用。

这是使用入库工具玩破解游戏可能被红信或封号的根本原因，因为对 API 的调用是发送到 Steam 官方服务器的。在小红书上了解到，有的玩的盗版可以与正版联机，说明 Steam 在联机时并不会验证账号是否拥有该游戏。包括 Steamtools 实现的家庭共享联机，也说明了 Steam 对于是否账号可以进行联机鉴权不足。但只要留有记录就有可能导致被封号，取决于 Steam 什么时候想管理盗版现象。

反之，如果伪造一个 Steam 的服务器，并且替换游戏中的 Steam 相关的动态链接库，如 steam_api.dll ，游戏里所有对 Steam API 的调用被发送到假服务器上，返回一个假的结果。这种工具也已经有了，项目为 goldberg_emulator，简称 GBE。破解版的游戏通常会内置一个这样的虚拟 Steam 环境。

第三方厂商验证

很多大厂的游戏有自己的联机服务器和验证机制、不仅走 Steam API 的验证。这种也是可以通过虚拟环境破解，但没人做，除非专门对这个游戏的所有 API 做逆向。难度比逆向通用的 Steam API 高很多。

Steamtools 是什么

已知 Steamtools 主要是做 解锁 和 入库。对于会不会破解游戏，网上没有更多的信息。我也不想冒风险尝试使用它。

根据官网的解释，Steamtools 可以离线运行（不如说破解游戏只能是离线运行），是提供了类似 GBE 的验证环境。有没有对 DRM 脱壳不清楚，但个人倾向于有，很多游戏都有 DRM 的保护，除了 SteamStub，还有其他的 DRM 验证方式，不脱壳玩不了。

因此个人推测是，Steamtools 是集 解锁、下载、入库、破解、运行时验证 为一体的工具集。

SteamAutoCrack 是什么

只做 DRM 脱壳和 Steam API 验证。项目在 Github 上，破解后的游戏会运行在 GBE 的环境下。这种方式是完全离线运行的单机。

风险来源

完全脱离 Steam 运行没有风险，只要在线就可能有风险。

假入库阶段的风险主要来自于入库工具对 Steam 请求拦截的覆盖程度不足。例如 Steam 版本更新了，使得 API 和下载流程有变化，而入库工具没有对其做处理，无法完全欺骗下载流程。网上看到假入库的人可能有囤积癖或者是打算做灰产，一次性入库了几十个游戏，直接导致被 SteamCDN 拉黑。

运行时的风险也是来自于在线验证，如果是开着 Steam 玩的破解游戏，没有离线时甚至尝试联机，使得游玩信息发送到了 Steam 的服务器（比如不该有的存档、不该有的联机等等）。

另外，入库工具会侵入式修改 Steam的客户端，直接打开 Steam 可能会有检测文件是否被修改。 Steamtools 提供了三种启动模式，可以随时恢复为原版 Steam 的运行。但淘宝卖的入库工具说不准是什么样的，当年骗我的店家那个用的是早期的 steamtools，使用店家的账号下载游戏后，使用 steamtools 离线运行（本来已经忘记了，努力想想竟然想得起来一点细节）。但现在的店家说不准是什么样的，在 B 站看到说有的是直接修改文件，从此都是盗版Steam 客户端，只能卸载重装。

没有风险的方式：如果你有方式得到 Steam 正版的游戏文件，然后用 SteamAutoCrack 破解，能直接脱离 steam 运行则没有风险。

对于更多的人而言，下载木马是最大的风险。

参考资料

• bbs.steamtools论坛
• SteamManifestCache wiki
• SteamLess Readme

Windows11 右键菜单问题被诟病已有，网上很多还原为 win10 菜单的教程……但 win10 有 win10 的问题，有用的没用的都往里放，常用的不常用的混在一起。有没有一种方法可以兼顾好看，同时有合理的菜单层级呢？

有的 —— Nilesoft Shell。可以自定义的 Win11 右键菜单。已经用了两年多了很好用（以至于差点忘了有这个软件）。

下载并安装

下载在官网： https://nilesoft.org/

安装完后，新菜单应该已经生效了，并且会开机自启。这时候可以点点看，如果感觉效果满意就不用再看下去了。

当然颜狗是不满意的，大部分一级菜单我用不上，我只想保留我常用的，不用的塞到更多选项。如图

挪动菜单层级

如果你是默认安装，C:\Program Files\Nilesoft Shell 应该能看见以下的文件结构

Nilesoft Shell/
├── shell.exe
├── shell.nss
├── imports/
│   ├── modify.nss
│   └── ...
└── ...

以 .nss 结尾的是配置文件，可以用记事本打开。以下是几个案例：

1. 收纳不常用菜单至 “更多选项”

例如，收纳所有名称里带有 “QQ” 和 “百度” 的菜单项，在 modify.nss 添加如下：

modify(mode=mode.multiple find="QQ|百度|网盘" menu=title.more_options)

find 中包含的字符串会被匹配，“|”是或。表示匹配“QQ”或“百度”或“网盘”的任意项都会被挪走。

这是主要的挪菜单的方式，我实际上挪了一大堆。

modify(mode=mode.multiple
	find="收藏夹|打印|共享|PowerRename|Microsoft Defender|Change Attributes|File Locksmith|upic|火绒|百度|QQ|Acrobat|Adobe|OneDrive|在沙盒中运行|PicList|旧版 Windows Media Player"
	menu=title.more_options)

2. “创建快捷方式”挪到顶层

有人可能看不惯 创建快捷方式 放在了 更多选项 里。要恢复把 modify.nss 中一行注释掉就好。

modify(mode=mode.multiple
	where=this.id(
		id.send_to,
		id.share,
		// id.create_shortcut, 这行注释掉
		id.set_as_desktop_background,
		id.rotate_left,
		...

3. 顶层添加新菜单项 “使用 vscode 打开”

在 shell.nss 中，新起一行添加

item(title='Open with VS Code' image=[\uE272, #22A7F2] cmd='code' args='"@sel.path" && exit' sep='top')

添加的这行可以不在最后，添加的位置决定它在菜单中的位置。我添加在了中间，最后的几个 "import" 之间。

要是问为什么我不用 vscode 自带的右键菜单……我的 vscode 装得太早了，那时还没有右键菜单关联，现在也懒得再装了就将就用吧……

4. 顶层菜单添加新目录

你要是在图片上右键，会发现系统自带有“使用 Windows 画图编辑”“使用照片编辑”“向左旋转”“向右旋转”……我的天，哪个天才设计的，你不知道自家照片 App 打开后能编辑也能旋转吗？（我知道这肯定是两波人开发的但还是想吐槽）

秉持着只挪不删的原则，在“更多选项”前加了个“编辑”目录。以下加在了 shell.nss

menu(mode="multiple" title="编辑" image=image.glyph("\uE0A1"))
{
}

然后在 modify.nss 里加了

modify(mode=mode.multiple
	find="*编辑|旋转|PDF"
	menu="编辑")

这样等于说，编辑和旋转相关都被归到了新的“编辑”目录下。加上 PDF 相关操作挪进去。我没有装 WPS，装了 WPS 也可以把 WPS 挪一个目录。

生效

管理员权限运行安装目录下的 shell.exe，点 Register 生效

其他

按 shift 后右键菜单，会有一个“Developer” 目录。没错 shift 显示隐藏菜单也可以实现，配置的属性有 vis=key.shift() ，但不是实时变化的所以没有mac 上的好用。除此之外还有喜闻乐见的能配置主题、颜色、图标等……我不管了。

参考

官网的文档很详细，但是非常面向程序员。不过大部分的需求被人在论坛上问过了，也有人在 issue 里问。不会就去论坛翻一下。看不懂英文开翻译，看不懂文档丢给 AI。

文档： https://nilesoft.org/docs

论坛： https://github.com/moudey/Shell/discussions

主要说说看了些什么吧。

实用小技术

1. 无线 iPad 当作电脑副屏

某天突然想躺着用手柄玩电脑的游戏，所以 sunshine + moonlight(iPad) 串流。效果非常不错！

2. 便携显示屏

后面，我又嫌无线的码率不稳定，组装了个便携显示屏，变成了躺着用电脑副屏……配件全部拼多多的。

• 显示屏，京东方 NV156FHM N69
• 驱动版、按键板、软排线
• 外壳、音响

3. 新的代理协议与客户端

今年对于魔法上网，非常重要的事情就是去年年底 clash-core 删库。不过也正好，促使我看看有没有人设计新的协议。

协议方面尝试了 hysteria2 和 naive，测试下来已经把 hysteria2 当作主力了。顺便读了下 http2 rfc7540 和 http3 rfc 9114 （但现在又忘了！）

客户端试了 singbox，在 ios 上替代了 shadowrocket，性能好非常多。电脑端 GUI 是典型的后端程序配置的思维，很难用，还是用 clash-meta 系列了。

单机游戏

1. Getting Over it (掘地求升)

我的天，有生之年我居然打通了这个8年前的破游戏！

打通的那一瞬间，我感觉觉得自己已经可能面对任何困难无所不能了。但是山顶的聊天室早已空无一人，有一点寂寞。

2. 博德之门3

tga 2023 年度游戏，不好玩。去年买了，今年和 meme 大师与墨墨联机了好几次，还是玩不下去！打架打一局太久了……而且打不好还要 SL……补药啊！（后面没法联机了其实主要是因为我作息太乱了）

3. 双人成行

2021 年度游戏，好玩，这个还是感谢陈 sir 陪我打完了，而且因为他是全成就大师所以我也跟着全成就了。因为我竟然买了两年都没有玩，显得特别可怜……

4. Tiny Glade

新出的休闲建筑游戏，最不像游戏的游戏。建筑方式新颖，而且好好看哦！

玩了后做了个视频，竟然被 HR 联系了……差点当诈骗私信……

5. 动物森友会

到今年才打开这个几年前的游戏。建岛是好玩的，画风也可爱，但因为手游也有在刷，对于刷刷刷的都有点疲惫了。

6. Halo

meme 大师带飞的经典 FPS，有剧情，非常好游戏！我只用跟在后面捡各种好玩的枪就好了（不是）

7. 传送门2

十几年前的解谜神作，好丸！多人模式也是 meme 大师带飞的。

8. Second Eden-理想箱庭物语

这是个新的 minecraft 深度魔改整合包，基于模拟殖民地 mod。我觉得比很多整合包都要好，考虑了流程、循环、引导，有些 mod 加的解谜结构很好玩。但模拟殖民地本身有 bug，加上流程上其实也不是特别完整，只建了一小半。

9. 零大陆

这是个超老的 Minecraft1.8 原版 RPG 整合包。真的非常震撼能做到这个程度，流程设计、地图设计上超级完整……可惜循环有问题，卡在一个冒险模式下的银河城地下区域了。

10. 模拟地铁

休闲小游戏，也是老游戏了，极简地铁规划，最后发现还是开滴滴比较好。内容对得起价格。也因此和喜欢地铁的朋友有聊些城建游戏。

11. 动物井 (Animal Well)

解谜 + 平台跳跃。太好玩了，这才是真正的 2024 年度游戏！！而且只 33 M，性能也超好！是像素美术但是是很现代的赛博梦幻像素美术，好看的！

12. 传说之下 (UnderTale)

经典日式 RPG，脑洞超大角色有意思，剧情很温暖。是Meme 依据本人的游戏时长与偏好定制的 steam 礼物……非常喜欢！

动画&漫画

1. 葬送的芙莉莲

中世纪魔法动画，难得味这么正，不算是我非常喜欢的类型但能看下去。而且作画的流畅程度真的……太有钱了！整体比较日常，很温馨。

2. 蓝色禁区 Blue Lock

足球番，我原以为我不喜欢看，最后根本停不下来……动画第一季做得实在太好了，但第二季是 PPT，1 分都不想给……漫画非常棒，不愧2024 年的日本漫画销冠。

不过我是其实从其中一对 CP 图决定看，结果看完动画觉得这两人麦太多了……不如好好看球！

3. 异形舞台 Alien Stage

动画音乐剧，讲的外星人饲养地球人当宠物，看人们在舞台上通过选秀比赛相杀的故事。特点是，一集一个寡妇（夫）……太刀了！

电影

1. 你想活出怎样的人生

宫崎骏动画电影，我觉得依旧很好看，很温暖。

2. 蓦然回首（Look Back）

藤本树动画电影，讲普通画画人的故事。非常牛美术风格。尽管我不是画画人，也没有很好的画画天赋。但也有一些感受有经历过，日复一日练基础，什么时候都在考虑画画……

以及藤本树居然开始走治愈系了！

3. 志愿库 - 存亡之战

怎么突然出现了国庆战争片……这个真的拍得挺好的，算是近年陈凯歌的不那么扑的了。以及我有朱一龙演技滤镜，在超烂低成本不被任何人看好的改编网剧里，因为演技太好而突然红的，真的没得说。

4. 名侦探柯南 - 黑铁的鱼影

和雨疏的年度固定节目，不错的粉丝向主线剧场。真好啊真好十年后还在和她一起看柯南。

音乐

年度歌手还是 Radwimps，基本老歌。上半年没怎么听

年底听 4 块钱的直播，才发现日系真是年年有天才。「晚餐歌」真的很厉害。原来不是我不喜欢听歌了，是没关注到好听的歌了，网易云日推越来越不行了，一直推各种时下 OP ED。

技能相关

• 游戏，给 MC 服务器写了 彩虹帽子 数据包。想来这其实是第一次和游戏有关的编程，经典入口是帧更新 tick()。

• 画画，学了平面设计的课，作业也很肝完了，有一些收获。然后又看了些曼奇的网课，素描关系有提升，就是增加了短调子、空间感、体积感的意识。我之前也不是感受不到，而是没觉得差一点明度就会差很多。这是 Ti - Se 画画相比于 Se - Ti 的劣势，需要有理论后才能画得好……

• 原神里头一回赶上音游的版本，写了几首比较难的谱面，这个非常满意，是我自己都可以反复玩的！

专业相关

这随便吧又没人看。

• 笔记主题没怎么更，我也用得越来越少了

• 博客有更新，但忘了！

• 新写了个服务器的监控页。

• 论文挣扎着狂补。

• 有去接触 GPU 相关的，不想只停留在业务 MVC 再 CRUD。但看了发现没需求的话确实用不上。

公司的相关还是不说了……主要是图形学和，久违的 OOP 编程，新的语言 C#，但长得非常通用面向对象，没有太多的入门门槛。不禁感叹外面世界的语言真是五花八门……但要说写界面好用还是声明式的，OOP 写界面特别过程式就，扭曲，痛苦，但无疑性能会更好。