#分享 #工具 用了 SFTPGO。windows 25h2 不知道抽什么风，smb 的服务器文件共享连不上了。

终于把老家 9 年前的路由器换掉了。以前想组 mesh 感想就是面板非常贵，现在的路由器都自带了，虽然各家不兼容就是了……用的是 TPLink 的 7DR3600 Wifi-7 路由器。就看中这个薄薄的一片，没想到还是差点塞不进弱电箱，天线不能弯折，口又是开在正后方的。Easy Mesh 也确实按起来够简单的，只不过当我测出来子路由的公网速度只有 150Mbps 时两眼一黑。但内网速度没问题于是百思不得其解。后面拔线重启了主路由又好了。

然后我换的路由器时候，所有人都说：你又买路由器了，旧的难道不能用了吗……我特意去京东看了一下订单，特么上一个路由器我是 2017 年买的啊！什么叫又！晚上姐夫来也是这么问的，然后把我那老 Wifi5 路由器捡走了，说我姐房间信号不太好……不是……这路由器回收价都只值两块钱。等下……他们有网线吗？应该是没有的……

2026-09-09 11:18:56

说来我领了一个领导派的工作，大概就是学别的地区的同事做 Excel数据分析。领导也没说要分析什么，我打电话问同事才知道。然后一个周了，我连数据源都没见到……有数据源真的很快，没数据源不行。

他们用的二十多年前的腾讯系聊天软件（这个软件早在2015年就停止服务了），不上线接不到消息，文件不会自动接收，不及时手动接就保存不了。一开班又被软件全屏了接不到提醒，上班又不能看手机。

很不一样的就是，Si 为主导的行业学的是流程而不是逻辑（人为规定很多都没法整理出逻辑）。领导说最好是她整理的时候我给打个视频看着一步步做，让我有种 20年前的电脑书籍全是截图，告诉你要点哪里这样。我有点哭笑不得，就一个 Excel 业务在那做加减乘除的，有难成这样吗……

打电话的同事说，处理后重复数据，我当时其实非常纳闷，网上下的数据，自己数据的，怎么会处理出重复数据？她说什么 SUMIF 都算了一遍，然后后面的重复项 CountIF 置 0，我也没懂，但没在现场也问不出个所以然。直到晚上我写 Excel 手册时，写到数据透视表才想起来，特么他们是不知道数据透视表这个东西，就在原表上 SUM……

我把数据透视表给父母试了一下，我演示什么，他们就只能做什么，变一下就完全不会了。我能理解，他们只是记住了我说要点哪里，并不知道这样点数据模型发生了什么变化。而我是完全记不住要点哪里，只知道什么按钮能让数据发生变化。但是我也真的很头疼，因为我似乎是第一次知道数据透视表时就明白了数据透视表的概念，所以我完全无法理解他们为什么是在记流程而不是试图去理解数据发生了什么。

2026-09-04 02:37:33

研究了一下 Obsidian 导出 PDF BOOK。不得不说目前的 HTML 已经很够用了，@media print 里设置分页，Obsidian .print` 类里设置字号，插件 Better Export PDF 可以预览和设置页脚。设置对于没有复杂图文版式的导出完全够用。

要说常见什么 Markdown 刚需不太行的地方，大概要算自动编号了…… 最后还是靠 AUTO-HEADING 插件。

然后就是 PDF Viewer 的100% size，至少我下的软件算出来都是错的……普遍比 Actual Size 里。对于高分屏，Summatra PDF 一定要自己设置 DPI。我也很纳闷就真的不能获取到屏幕的 DPI信息吗……

2026-08-19 22:18:52

Deepseek v4 pro。拿来处理文件资料编译 Wiki 还是不行。本来自然语言规章制度就够不是人读的了，加上情况非常多。 Deepseek 一是在我明确说明要改条款 A2 时，在 A2 里加入了相关的 A1 条款，然后需求 A2 的适用边界也与当前文档的前文 A1 冲突了，还出现了从没有见过的 A2 条款，实际上和 A2 毫无关系。

换回 GPT Sol 瞬间理解对了，适用边界非常清楚。

2026-08-17 21:07:33

#分享 书 现代硬件算法（英文）

2026-08-16 23:32:50

除了父母满意，我对这个工作零点满意。

真的是熬夜网上冲浪了，完全没自己的时间。

好难忍受网不通自动化水平这么低与世隔绝 0 技术发展的行业……

但我自己也没有时间搞开发了。我能偶尔训练图生图模型已经是奢侈了。我是真的很不想在谈论这些时再这么痛苦了。博客有组件还没有写完我觉得我又是永远没有时间去写了。

我虽然知道想法其实更重要，但经验告诉我，想法的发展是会随着技术的学习提高的。想象力与能做的事是基于认知的。我不觉得我十几岁时能写出比现在好的东西。不学习哪里来的认知啊？！

此次 PDF 成品可以 在此下载。

一、Obsidian 导出配置

插件

• Better Export PDF：可预览，可加目录书签
• Code Block Customizer：伟大无需多言！代码块终于像样了，完全换掉了 Obsidian live mode 对于代码块的处理方式。
• Auto Heading：标题自动编号。对于打印来说自动编号是很重要的。不过没有中文数字。
• 一个文本编辑器，编辑打印用的 CSS 配置

CSS 配置

CSS 现在对于打印 (@media print) 的配置比我想得要多得多……

• 自动页码，奇偶页码
• 页眉页脚
• 按大章节分页
• 首页占一整页做封面
• 防止标题被挤到页尾
• 防止图片跨页

表格的跨页表头还是自动续表的，CSS 还有计数器功能。我惊呆了好吧，原来这么强的吗？已经是符合本次基本的书籍导出的要求了。新的 CSS 还在加印刷相关的内容。

Typst 更强也好用，但就一般笔记导出成书而言还是 markdown + css 快且广泛。

上面具体配置我就不细说了，因为本人酷爱装修，样式都是长期累积的结果，印刷用的主题也是在原主题的基础上又叠了一层修修补补，直接放到 gist 链接上了。

软件

一定要一个可以读取屏幕 dpi 查看实际大小的软件。Photoshop 是可以的， SummatraPDF 经过设置后也是可以的。其他的我没有试过。

以 SummatraPDF 为例，在「设置」→「高级选项」中，设置 CustomScreenDPI = 189 。其中 189 是我的屏幕 DPI 。你可以直接查阅屏幕型号，或到 这里 计算。

然后重启 SummatraPDF， Ctrl+1 就是打印大小了。

二、排版

对于主题，初期我尝试了使用网页风格无衬线主题 ，效果算是非常非常不行，主要打印出来的字非常大一个，而且粗细对比过强，网页感太重了。

对于一般的纸张，书籍印刷确实非常不适合使用粗体字（Bold, weight 600)，除非你用铜版纸这类不吸墨的纸。500 的字重比较适合。

适合印刷的主题是需要重新写的，才有了上面的效果。

纸张

可以说 纸张 和 纸张大小 在印刷里的重要程度能占 60%。

• 纸张种类：道林纸（双胶纸），本白色。
• 纸张大小：B5。

首先是排除办公复印用的荧光剂 A4 纸。这个纸，即便你裁为 B5 的大小，认真胶装，加上铜版纸封面。但那种挺度、表面质感和刺眼的荧光白，仿佛小学复印店里复印出来的一样（实际上就是）。

道林纸（双胶纸）是一种比较常见的纸张。值得注意的是，除非你住印厂旁边，街边的复印店是不会准备本白色的双胶纸的，连大学毕业论文打印的地方都是荧光白A4纸。我走完了一条街的广告店，有个女店主很认真介绍了她存放的纸的种类，说对于特种纸要提前给工厂定制，存放也是有要求的。

如果不想寄印，只能自己买一打回去，带给打印店了。

至于为什么 B5 大小……真的会觉得 A4 纸像书吗？

字号

配置

• 网页： 16px
• Obsidian Better Export 导出缩放：80%
• 实际大小：9.6pt

Chromium 的 PDF 导出以 96dpi 导出，于是 16px 的字体对应的是 12pt。之前买过 Rei 的《印刷排雷手册》，12pt 在正文印刷里已经算是老年人字号了。

因为我想制作册子，使用的是 B5 大小印刷。在初期，我只是问了 AI 缩放到 85% 是否可行（字体大小10.2pt），AI 说可以，我印出来也觉得凑合。但当我拿到专业印厂的印刷后，才发现 10.2 pt 和 9.6 pt 虽然看起来差不太多，但舒适度差距比想象得大…… 10 pt 还是更适合 A4 尺寸。

边距

配置

• css:

@media print {
    @page {
        margin: 12mm 10mm 14mm; /* 正文 80% 缩放不知自带 6mm 边距*/
    }
}

• 实际边距：左 16mm，上 18mm，右 16mm，下 20mm

我没有搞懂为什么 margin 为 0 还是有自带了边距，有可能是我的原来的傻逼主题干的（并不）。

实际边距是 GPT 的推荐值，也是我从印厂拿到的胶印书籍里的测量值。

行间距与段间距

这部分反而是祖宗之法。

• 行间距: 1.5倍。
• 段间距: 1倍 margin。

1.5 倍行间距也是考虑到我的笔记有大量的 bullet，没有超过 3 行的长段落，大概比较像教材。小说类的行间距是更稀疏的。

装订

我对册子要求就是能平摊，能平摊，能平摊。我讨厌不工整的纸，谢谢。

最开始我使用了固体胶装，牢固是牢固的，但是好像，因为真的干不了所以到处黏纸……后面还是使用了经典的白乳胶放一晚上，非常牢固且照顾手残。

而印厂因为能打印 B3 的尺寸，小册直接用骑马钉了。

印厂的调整

我发给印厂的 PDF 存在着诸多问题。不标准的字体大小，下边距过窄。但是印厂把各个边距给我裁得相当之标准。骑马钉所在的内侧边距要微大于右侧边距。

我的上边距是标准的，所以印厂没有变上边距，只是整体缩小，给了下边距和左右边距正确的距离，可以说是非常细致地排版过了。

质量相差最大的最难的算是灰度网点，AM 胶印的细腻的网点，家用的激光打印机打不出来……真的打不出来。

整个印刷质量、均匀程度和办公用的激光打印机相比，实在差得太多了。

最近换了 Vivaldi 浏览器，有一段时间了，突然我发现我再也没有漏过 RSS。原因是浏览器的新标签页组件。

在打开新网站时，我一直使用 ctrl +T 新建标签页。在这之前，我有尝试过 Chrome 的订阅类插件。最开始使用的掘金插件，当时掘金初创不久，内容还不错。但实际使用发现，在我新建标签页时，是要准备切换工作了，这时掘金的订阅铺满了一整屏，就不会想阅读这么多的信息。即便换到了其他的插件，也依然存在着信息过载的问题。

后来我开始使用订阅服务，几经转换后使用的是 Innoreader。Innoreader 有 Chrome 插件，红点显示未读数。但是，我依然不会点，如果有红点强迫症，来一篇就点一篇很烦。如果没有红点强迫症，就更不会点了。

Innoreader 还会发邮件提醒什么文章没有读。但是打开邮箱时，通常也需要处理事件（指接收验证码）。我不会摸鱼摸到邮箱里去。

Vivaldi 新标签页组件就很好地解决了这个问题。首先，组件面积不大，信息量保持在人可接收的最佳范围（4篇）。至于为什么是4，参考 【毕导】你有一种连你自己都没意识到的超能力。

其次，组件内默认点击是进入的原始网页，给人感觉是我去别人家的装修的房子里做客，还能看看评论。这也是因为我本来就在使用浏览器，并不会在 App 之间跳来跳去。相比于 all in one 的方便，在个人阅读的场景下，浏览器原始网页能给人更强的满足感。

这样一来，我新建标签页时，如果很忙就直接进行原本的事情，RSS 不会打扰到我。如果不忙，我就会看一眼大家都发了什么，有没有什么有兴趣看的内容。

我认为个人维持阅读 RSS 习惯便应该这样，以少量精简的消息，嵌入到日常一定会使用的软件里，同时不会贴脸打扰到人工作，也不会使用角标进行烦人的提醒。

这样的软件其实不多了，大部分的工作软件打开后全程工作区，很少有浏览器新标签页这样每天都会用的非工作区场景。而社媒平台的推荐给你绑得死死的。我之前还用过即刻的 RSS 机器人，完全符合刷社媒时顺便刷到自己的订阅，非常好用，但很快因为监管问题下架了。要么就是推特了。但是写博客的人，又不一定会发推特。不如说，除了阮一峰，我没有再找到每篇博客都发推特的个人博主了。

然后检查了一下 PDF，确实是导出时糊成一坨。

我用后期画图用的都是 draw.io，之前也写过 draw.io 相关设置的文章，研究了一下，大概分为两种情况。

使用像素图（PNG）

如果使用 PNG 之类的像素图，首先要确保原图像素足够大，在 draw.io 中我会导出为 400% 大小。然后在 Word 选项 -> 高级中：

可以选择以下两种任意其一

• 不压缩文件中的图像
• 默认分辨率设置为「高保真」

之后把糊图全部替换一遍，这样至少设置后图像不会被压缩。

检查方式：放大 Word 界面到 250% 后看看图像的清晰度是否可接受。

但是导出 PDF 或者打印时，像素图始终是以图像像素打印的，带有抗锯齿，没有矢量文字那么清晰。而且流程图用矢量图无疑是更好的。

使用矢量图（SVG）

在使用 draw.io 的 SVG 导出矢量图后，在 Word 中显示不糊了，但是导出为 PDF 发现还是会糊的。

PDF 中明显依然是把 SVG 转换为了像素图。并且，「dobj」 的上框线也被截断了一半，因为 bounding box 是从线条中间算的，导出时 SVG 必须加点边距来避免这个情况。

如果想要 Word 能完全按照矢量图处理 SVG，draw.io 导出时需要取消勾选「嵌入字体」和「嵌入图形」。

但此时渲染更不对了。一是字体不对，其次是 SVG 内的文字默认不换行。

这是因为 draw.io 的 SVG 默认面向 HTML 的，Word 对于很多 HTML SVG 的渲染特性是不支持的。如果需要 draw.io 的渲染和 Word 一致：

1. 在图形框上设置字体，而不是选中文字内部设置字体。
2. 在导出前需要全选图形，然后在右侧栏的文字选项卡中勾选「转换标签为 SVG」。

但是就算是这样，你还是有可能会发现英文字体间距（kerning）有问题。

我看了下官网的说明，这种情况应该要取消前两项。

这样最终效果就完全一致，导出为 PDF 打印后，图表内的文字也和正文一样清晰，而且可以被选中。

总结

如果用像素图，记得图像够大，让图像不要压缩即可。

如果用矢量图，需要

• 全选图像，「文本」中取消「自动换行」和「格式化文本」。手动换行
• draw.io 导出 SVG 时取消「嵌入字体」和「嵌入图像」，并添加一点边距

这样 Word 转 SVG 为 PDF 时，文字可以保持矢量状态，而且可以被选中。

以下仅适用于低于 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 键可看。切换可合成物品。（没更新的话用 REI）
• Invertory Profiles Next: 高版本的 R 键背包整理（但被我改成 z 键整理，R 键通常是 JEI 查看合成表）。自动补充工具、连续合成、捡物品时默认扔到背包中，以及在打开箱子时使用滚轮移动物品。关掉快破损时替换工具。
• imblock: 输入法冲突修复
• Panda's falling tree：砍树时树会倒下，降低砍树的肝度。
• Leawind's Third Person: 更好的第三视角。这算是第一个可以日常使用的第三视角模组，挖方块瞄准都很方便。日常的垂直平滑 0.5 以上，不然爬山能晕死。特点是不绑快捷键。(作者新出了 Perspective API)
• 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 管理的最佳实践。

基础知识 - 代码的画布

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

层叠上下文的产生

• 根元素：<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 是无效的。
• relative 且 z-index: auto。位于 CL-6，没产生层叠上下文，其子元素如果有更低的层级，可能会被盖掉。子元素有更高的层级，会盖掉别人。
• 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

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

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
[[index]]
name = "pytorch-cu126"
url = "https://download.pytorch.org/whl/cu126"
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 管理老项目

要复用必须满足四个相同：python 版本相同, index-url 相同, torch 版本号相同， torch 后端相同。

python 版本由 venv 创建时决定。我们需要指定缓存里的 torch 版本， --index-url 和 --torch-backend。少一个都不行。

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

和用 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. 实践的统一性

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