<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
    <id>https://sansui233.com</id>
    <title>Sansui's blog</title>
    <updated>2026-04-17T09:33:03.747Z</updated>
    <generator>https://github.com/jpmonette/feed</generator>
    <author>
        <name>Sansui</name>
        <email>sansuilnm@gmail.com</email>
        <uri>https://sansui233.com/about</uri>
    </author>
    <link rel="alternate" href="https://sansui233.com"/>
    <link rel="self" href="https://sansui233.com/atom.xml"/>
    <subtitle>记录学习和生活的个人博客</subtitle>
    <icon>https://sansui233.com/favicon.ico</icon>
    <rights>All rights reserved 2022, Sansui</rights>
    <entry>
        <title type="html"><![CDATA[Windows 调整之中文字体]]></title>
        <id>https://sansui233.com/posts/2023-09-29-windows-system-chinese-fonts-adjustment</id>
        <link href="https://sansui233.com/posts/2023-09-29-windows-system-chinese-fonts-adjustment"/>
        <updated>2026-03-25T15:33:14.000Z</updated>
        <summary type="html"><![CDATA[让 windows11 字体更好看的一些设置与字体浅谈]]></summary>
        <content type="html"><![CDATA[<blockquote>
<p>以下仅适用于低于 4k 缩放 200% 的显示器</p>
</blockquote>
<p>微软雅黑作为随着 Windows7 出现的字体，加上遥遥领先（？）的 ClearType，在当时的 1080p 显示器上十分清晰易读。</p>
<p>但如今的显示器分辨率越来越高，旧版微软雅黑的设计存在着明显的缺陷。</p>
<p>一是其字形设计并不平衡，中宫过大，有的字形可以以难看来形容；二是微软雅黑字形只在 4K 屏 200% 缩放（以上的配置）上有着较好的显示效果。</p>
<p>微软曾经设计过“另一版的微软雅黑”，即 Noble Scarlet，但并没有在正式的系统中使用。这一版字体设计依然中宫偏大，但相对老版收敛了不少，平衡了一些。</p>
<p>另外，如果你不巧像我一样用着 2K 或 2.5K 屏，</p>
<ul>
<li>在 24寸时，100% 缩放字体比较合适，但与 16 寸 1080p 显示器差不多清晰度，不过屏幕可用空间更大。</li>
<li>在 21 寸时，100% 缩放字体会偏小，比较锻炼眼睛。150% 缩放字体大小比较合适，效果更细腻，但字型会比较怪，且屏幕可用空间与 1080p 相同。</li>
<li>在 16 寸时，150% 缩放字体稍微偏小，效果比较细腻，但非整数倍缩放+ClearType 的加持下，一些像素被吞掉，笔画的间距不平衡，有种“ windows 特有的字被虫噬的美”。</li>
</ul>
<p><img src="https://img-cf.sansui233.com/imgs/2024/08/202408190158527.webp" alt="字形"></p>
<p>可以看到，上图的 100% 200% 缩放没有字形变形问题，可以说微软雅黑小字优化是考虑的 100% 缩放。100% 缩放显得糊则是因为图片放大放大倍率过高，实际不会有糊，而是有锯齿感。</p>
<p>150% 缩放会由于 clearType 的“锐化”导致字形变化，不知道的还以为换了个字体。如果是125%、175%的缩放，字体变形更加糟糕。</p>
<p>造成缩放问题的原因大概可以用下图进行简要解释：</p>
<p><img src="https://img-cf.sansui233.com/imgs/2024/08/202408190318888.webp" alt="缩放"></p>
<p>Mac 上的 Retina 渲染相当于 4k 200% 缩放起步。而 windows 下， 2k-2.5k 的屏幕都在 200% 以下的缩放中挣扎。如果软件没有适配高分屏，没有 clearType，强制进行双线性缩放（常见于图片UI），就会显得非常糊。想体验这样的糊，可以下载旧版的原神启动器。</p>
<h2>需要准备</h2>
<ul>
<li><strong>Noble Scarlet</strong>  替换系统的微软雅黑。由于 Noble Scarlet 是一个未完成的字体，普遍使用的是社区修正版，以下是资源参考。
<ul>
<li><a href="https://bbs.pcbeta.com/viewthread-1960120-1-4.html">pcbeta</a></li>
<li><a href="https://www.bilibili.com/read/cv6059905/">bilibili</a></li>
</ul>
</li>
</ul>
<blockquote>
<p>以上苹方加粗版本不一致性问题太多、新版苹方的英文表现相当糟糕，因此不建议使用，其他版本直接替换的都还不错。</p>
</blockquote>
<ul>
<li>系统字体替换工具：搜索 “<a href="https://www.fishlee.net/soft/SysFontReplacer/">字体替换工具 by 随风飘扬</a>”。替换完后重启，否则可能有缩放错误。另外，github 上有一个非侵入式的系统字体替换工具 <a href="https://github.com/Tatsu-syo/noMeiryoUI">noMeiryoUI</a>，可惜换不全 windows 11，只是作为预览不同字体在系统上的效果倒是个很不错的工具。</li>
<li><a href="https://www.mactype.net/"><strong>MacType</strong></a> 改善 ClearType 的虫噬渲染方式带来的不均匀，使用后提升非常非常大。</li>
<li><strong><a href="https://source.typekit.com/source-han-serif/cn/">思源宋体</a></strong>：推荐将浏览器的 Serif 字体设置为此字体。默认的宋体真的，不论中文英文，都很丑……只适合打印。</li>
</ul>
<h2>字体替换说明</h2>
<p>位于 <code>C:\Windows\Fonts</code> 下有三个文件。这个三个文件可以使用上述的<strong>系统字体替换工具</strong>替换（推荐），或者安全模式下 <code>xcopy</code> 命令也可以替换。但是自己替换时要注意备份，这是真正意义上的替换了底层字体。网上也许会说用 PE 启动，但其实并不需要从 PE 启动这么麻烦。</p>
<ul>
<li><code>msyhbd.ttc</code></li>
<li><code>msyh.ttc</code></li>
<li><code>msyhl.ttc</code></li>
</ul>
<p>位于 <code>C:\Users\你的用户名\AppData\Local\Microsoft\Windows\Fonts</code> 也有三个文件，这三个文件可以不用管，直接安装对应新字体就可以让新字体生效，同时老字体也没有被删除，只是会生成 <code>msyhhv_0.ttc</code>，等于是修改了注册表中的字体文件Link。</p>
<ul>
<li><code>msyhhv.ttc</code></li>
<li><code>msyhsb.ttc</code></li>
<li><code>msyhsl</code>.ttc</li>
</ul>
<p>当然，其实你也可以生成注册表</p>
<h2>常用正文黑体简述</h2>
<p><img src="https://img-cf.sansui233.com/imgs/2024/07/202407260100518.webp" alt=""></p>
<h3>苹方</h3>
<p>苹方是一款设计上很优秀的字体，其间架结构、中宫非常平衡，既兼顾了传统的汉字笔画细节又有规整而现代的几何化，间距合理，阅读起来非常舒适。</p>
<p><del>但是……苹方的设计缺字重。</del> 苹方已经发布了可变字体，目前不再缺字重了，下段内容已过时。</p>
<blockquote>
<p>在设计上，苹方没有 Heavy 字重（<a href="https://support.apple.com/en-us/103203">参考</a>）。而在<a href="https://github.com/paraself/PingFang-Fonts">流行的 github 苹方字体仓库</a>中，则是将 Bold 字重映射到了 Heavy，而将原本的Medium 映射到了 bold。虽然这个问题不是苹果设计的导致的，而是一个再次分发时的错误，但致使目前网上能搜索到的第三方仓库的苹方字体整体字重均偏细。</p>
</blockquote>
<p><del>另外，苹方在 2.5K 屏上表现非常糊。</del> hinting 有了，不糊了，下段内容已过时。</p>
<blockquote>
<p>苹方问世时已经进入了 Retina 屏的时代，没考虑过在低 PPI 屏幕上的表现（不是4K屏缩放200%都别用）。</p>
</blockquote>
<p>第三，苹果设备的显示的西文字体是 <a href="https://zh.wikipedia.org/zh-hans/San_Francisco_(2014%E5%B9%B4%E7%9A%84%E5%AD%97%E4%BD%93)">San Francisco</a>，不是苹方。在 <a href="https://lrd.im/blog/2022-01-17">细数 Pingfang SC 的七宗罪</a> 中，也提到仅使用苹方导致不同设备字体 fallback 的不一致的问题。而作为系统字体里的其他问题，例如缺失本地化的字型，也是大部分字体所缺乏的，这已经不仅仅是一个字体问题，而是和字体相关的和 UI 技术标准化问题，难以仅通过字体解决。而无比例数字、冒号不垂直居中、没有垂直标点等细节，则都是因为苹果显示标点数字用的 SF 字体，苹方在此类字符上算是基本能用，但缺少多种场景下的细节。</p>
<blockquote>
<p>其他资源： <a href="https://www.figma.com/community/file/1089832205783108371">Pingfang for windows - Figma</a></p>
</blockquote>
<p>另外，苹方是有版权限制，以下字体除了思源黑体，和大厂的开源黑体，均不可免费商用。</p>
<h3>思源黑体系列</h3>
<p>思源黑体(Noto sans) 是 google 的开源可商用字体，用于 Android 系统，在开源可商用的的黑体其质量无可替代。</p>
<p>更纱黑体是思源黑体的衍生，修改了西文部分，相比思源黑体上更符合作为 无明显风格特征的系统字体，带 hinting 在 1080p 和 2.5k 下都能保证良好的清晰度。</p>
<p>但是，思源黑体系列设计相比于国产的商用字体并不能算好，有时间架结构比较怪异，字形的细节不太统一，比如“用”字明显矮了一截，整理风格上给人一种不稳定感。同时也不是一个大气的字体，比如口字旁处理对于黑体而言偏小，“用”字矮了一些，但是在宋体设计上，“用”字矮的这一截反而让字体看起来平衡。而一个系列的字体衬线、非衬线的统一感来源于其比例，个人理解为思源/更纱系列是优先考虑宋体的字形，和黑体的比例有一定的结合。整体而言还是宋体的设计更加优秀。</p>
<p>相对而言更纱黑体更适合作为系统字体，有着合理的 hinting。思源黑体是不太适合低 ppi 屏的，它的 Regular 字重看起来像 Bold。</p>
<h3>方正兰亭系列（微软雅黑）</h3>
<p>Noble Scarlet （社区版）常规体是新设计中宫收窄的微软雅黑，而粗体是方正兰亭黑 Pro，因此在加粗时，字体明显会变小一圈。</p>
<p>微软雅黑系列字体在标点处理上很差，最直观的就是全角引号，太像半角的处理方式，很难看出前引号与后引号的区别。其实我在写这一篇文的时候，换了 Typora 的字体，才发现前后引号全打反了……</p>
<p>方正兰亭黑 Pro 想对于两版微软雅黑都有着更小的中宫，字形设计中正。但也由于稍小了一些，在低 ppi 屏的小字上笔画更容易显得不太均匀，渲染效果不太好。另外使用此字体需要相比于其他所有字体更大的行距，因为其较小的中宫，字间距显得相对宽了。</p>
<h3>汉仪旗黑系列</h3>
<p>近年来的国产安卓厂商字体都是汉仪旗黑的衍生，代表阿里的普惠体、鸿蒙体、小米的字体、Oppo的字体。</p>
<p>这系列字体间架结构合理，但笔画上更加激进，减弱了起笔与收笔的的传统突出，以追求几何感与现代的科技感。在观感上，这样规矩的方形会使得字体相比方正系列更加圆润，多了现代感但少了汉字的人情味，用于阅读小说时尤其明显。</p>
<p>仅字形而言，作为 UI 是非常不错的。不过 Misans 渲染出来明显偏粗，我没有测试其他同系列字体是否也有这样的问题。</p>
<h2>改掉 Windows 的默认中文无衬线字体</h2>
<p>很多无法分别修改中英字体的 windows 原生应用，当只设置了英文字体时，显示的中文是新宋体（SimSun），比如 vs studio。原因在于系统里的 Microsoft Sans-serif 字体名，回落到的第一个字体就是新宋体……难以想象微软雅黑出了十多年了还有这样的问题。</p>
<p>解决办法：</p>
<ul>
<li>winkey + R, 输入 regdit，进入 windows注册表</li>
<li>进入 <code>HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontLink\SystemLink</code></li>
<li>把 Microsoft Sans Serif 的值中 SIMSUN.TTC 那一行去掉。这样默认的无衬线体就会往后 fallback 到系统的微软雅黑上。</li>
<li>把 <code>Segoe UI</code> 的 <code>TAHOMA.TTF,Tahoma</code> 挪到 <code>MSYH.TTC,Microsoft </code>后面</li>
</ul>
<hr>
<p>创建于 2023-09-29 02:25:44</p>
<ul>
<li>2026-03-25 更新：针对苹方字体资讯更新，增加字体替换说明。</li>
</ul>]]></content>
        <category label="工具"/>
        <published>2026-03-25T15:33:14.000Z</published>
    </entry>
    <entry>
        <title type="html"><![CDATA[每日见闻 - 说说]]></title>
        <id>https://sansui233.com/memos?id=2026-03-21T18:58:54.000Z</id>
        <link href="https://sansui233.com/memos"/>
        <updated>2026-03-21T18:58:54.000Z</updated>
        <content type="html"><![CDATA[<h2>2026-04-17 16:14:00</h2>
<p>还有 21 小时 45 分钟又要裸考，我要怎么安排。睡 8 小时，剩12小时45分钟。 三顿饭算2小时。剩10小时45分钟，写8小时论文，每50分钟休息15分钟。然后就去裸考。考完出门接待吃饭睡觉。不对，我还要洗头洗澡打扫卫生，至少划去两小时。差不多是满打满算一整天就这么过去了。一天过去什么都干不了。</p>
<p>啊忘了我还想看浪姐。但不想给芒果开会员，真的气死我了黑幕不要太明显了好吧，全开麦改live，最强的组被闭麦个人排名下滑……只能说芒果选了弹幕最多的打法，每播一期都会替一个输的人感到不甘。怎么输的简直没法理解。</p>
<hr/>
<h2>2026-04-17 00:25:47</h2>
<p>6小时激情写了6000多字小说大纲。如果不是我发现自己太容易去抠了，克制住只写大纲别写对话，我觉得可以写一整天写一两万字。所以到底为什么写小说能这样？写论文就不能呢……</p>
<hr/>
<h2>2026-04-15 20:59:16</h2>
<p>今天把 Mac 整理了一下，把 Hermes 挂上了；这篇博文就是我在 Telegram 上让 Hermes 发的。</p>
<p>（等下不是……你怎么还顺便给我润色还改了口癖？？我看着感觉我瞬间变成了 AI 幻觉系老板。下面请欣赏有股微妙 GPT 味的 memo）</p>
<p>我之前对 clawbot 也没什么兴趣，主要是我一直觉得“压缩上下文当记忆”这套方案特别烂。Agent 真正该记的不是知识，更不是压缩后已经变味的知识，网上搜索和 wiki 查询显然更靠谱。真正值得记的是工作流逻辑和用户偏好。Anthropic 提出的 Skill 在这里确实功不可没。</p>
<p>Hermes 说自己是在“进化”，但我觉得这个词太笼统了。它更符合我对学习的定义：快速形成可靠工作流，并让 agent 快速命中。</p>
<p>之前所有东西几乎都离不开上下文和 RAG。我还是不看好 RAG，也不看好把压缩上下文当记忆；这两套东西本质上都像许愿机。Hermes 至少能一次拿到高密度、可实践的信息，记录下来的 skill 也是高密度、可实践的信息。这和 RAG 流、压缩上下文记忆流有很本质的区别。</p>
<p>当然，组织 skill 依旧需要架构能力，也不是想到 skill 套 skill 就能做得很好。目前 skill 调用判断完全依托于 LLM，prompt 的 weight 是不可调的，skill 一多就会有噪音，占上下文，还会影响模型效果。但这个问题是能解决的。要么大模型继续发展，要么工程方向继续推进；就算模型硬件成本真的到头了，训练个 skill PEFT，把工具和记忆对 memory 窗口的挤占问题解决掉，也完全是可行的。</p>
<p>这是我第一次感觉到 AI 的应用流程开始变可靠了。从成本到架构方式到落地到发展方向，不再全是些许愿不可控的东西了。唯一的问题还是出在大模型那边，稳不下来的许愿池。</p>
<p>你会发现这些 agent 接 ds 和 glm 效果都不太好，还不如 gpt 5.4 mini。国外的模型已经在向工具调用方向去特化训练了。虽然说数据可以蒸馏，但是一直蒸就会一直造成这种吃屎的赶不上热乎的现象……</p>
<p>国内也没可能出现搞研究/训练和工程一体化的独角兽公司。硅谷那种环境国内复刻不了，也并不适合国家的体系。即便到民营企业，每家大公司都有研发部门，界限也划得太清了，研发卷研发的产品卷产品的，锤子是锤子螺丝是螺丝。只除了一家，第一次面试的超大包 offer，流动超大、内部废掉的产品超多、重组也超多的那家，确实做出了一些很棒的东西。现在大概已经进不去了，因为五年过去我已经极速腐化了，简历也从不断被捞变成废纸一张了。</p>
<hr/>
<h2>2026-04-13 20:25:01</h2>
<p>#博客 关于全文搜索功能，其实有考虑很多，毕竟我是既要又要的类型</p>
<p>后端：全静态没有服务器，不能有数据库。这样我就不用搞维护了。索引构建时间不要太长，不然我懒得等 build。</p>
<p>前端：索引传输体积要小，UI 组件体积要小，网络下载时间才是网页杀手。准确度属于搜得到就行。</p>
<ul>
<li>全静态没有服务器 -&gt; 我需要提前构建索引文件。</li>
<li>索引构建时间不要太长 -&gt; 不要用过于复杂的算法。</li>
<li>索引传输体积要小 -&gt; 用了复杂的算法全文索引会更大，索引就是空间换时间的。所以不要搞倒排和分词了。</li>
<li>UI 组件体积要小 -&gt; 不要用特别复杂的匹配算法。这也和索引简易程度相关。</li>
<li>准确度 -&gt; 关键字对了就行，时效性排序，简单又很可靠。不需要语义近似权重相关性，又不是谷歌。</li>
</ul>
<p>所以最佳方案就是传 markdown 全文，把非语义URL、语法标记这种给去掉的全文 ……</p>
<p>如果写了几万篇怎么办呢？emm，就是给 index 分块，不用一次把数据库搜完，搜个十篇的就行，找不到再搜下一个 index。根本到不了那一天好吧！连载个 40 万字的小说也就 1M 而已，压缩后也就三、四百 K，不要太提前焦虑了，简单的东西反而更实用……</p>
<p>为啥没用 Flex Search 一类的库？ 他们太复杂了，索引体积也是成倍的，还要一直更新包，动不动给你报依赖的安全问题，算是得不偿失吧。</p>
<hr/>
<h2>2026-03-27 23:55:23</h2>
<p>好了，我觉得还很重要的一点是，早睡，不管多早起，到半夜，由于是因为有事情做才熬到半夜，容易整得人思考人生思考崩溃。</p>
<hr/>
<h2>2026-03-27 04:07:00</h2>
<p>除了 Day One，还真的只有这里让我有记录的欲望了了。 notion 好慢要选分类，也不能马上看昨天和前天的那些黑历史。基本记录到 notion 的东西记完就忘。我还搞了week plan 模版，评价是不如小本本来得方便。社交平台的数据始终不是我的。刚才想说很多话，到了这里就偃旗息鼓了，至少有这个博客永远是你的自己的，也没有登味的人让你干这干那，足够清爽不是吗。要玩就在这里玩好了。</p>
<p>想法永远不相通。她觉得我是没自信，不，我只是对于要一直待在那种充满老登的环境感到绝望。我想去找人一起玩，让我回家比死了还难受。我讨厌为了老登打扮讨厌敬酒讨厌各种被迫参与的关系讨厌虚伪讨厌裙带关系讨厌一切不能投入的事情讨厌不能写代码或者不能创作，光是想想就觉得要窒息了。“你就是缺乏锻炼”“我把你保护地太好了”我真的听了想吐，我不知道别的，但我听了想吐。我无所谓来这里的人是什么看法，起码我给自己留了个完全衷于自我的地方，我没有当键盘侠没有骂别人，我只想好好学东西用学的东西养活自己，我到底犯了什么事要找个把我讨厌的所有 buff 叠满的工作。</p>
<p>我现在对完成的任何事情都没有成就感，好像只是在赎罪的一样，把身上的罪孽一件一件先清掉而已。不要提什么考虑自己，罪人是没有未来的，赎罪就可以了，和在牢里度过余生没什么区别。极端吗？可我没去别的地方骂人，顶多是当一个只会拉点屎的可回收生物。可悲吗？可我没真的坐牢，我又有手有脚有学历有技能学东西还快没欠款远没到 35。那你为什么就没有未来了呢？</p>
<p>也许我该去北医六院看看，开个证明后做长期心理咨询了。但我不记得，我连收拾自己的力气都没有。真没想到想到要面这个试就会整发病。</p>]]></content>
        <published>2026-03-21T18:58:54.000Z</published>
    </entry>
    <entry>
        <title type="html"><![CDATA[Minecraft v1.20.1 常用设置]]></title>
        <id>https://sansui233.com/posts/2023-09-26-minecraft-settings-for-v1-20</id>
        <link href="https://sansui233.com/posts/2023-09-26-minecraft-settings-for-v1-20"/>
        <updated>2026-01-12T18:38:09.000Z</updated>
        <content type="html"><![CDATA[<blockquote>
<p>更新：<a href="/static/mc-1.20.1-mods/dependencies.html">1.20.1 版本 mod 列表</a>，有详细的 mod 分类与依赖关系。大部分为实用工具</p>
</blockquote>
<p>在 Minecraft 1.20 版本光照引擎被大幅改写，使得帧数提升，模组的数量似乎又多了起来。另外在 fabric 发展起来以后，mod的社区生态有了很大的变化，有很多老牌模组有了更新的替代。现在记录一下实现常用的基本功能需要的模组与修改设置。</p>
<p>我使用的 hmcl 启动器，在其中进行模组下载可显示模组间的依赖情况。以下内容在 1.20.1 中完全兼容，且项目均在维护中。</p>
<h2>1. Mods</h2>
<p>MC 是一款肝度明显过高的游戏。mod 的选用主要是为了：</p>
<ol>
<li>使画面养眼</li>
<li>降低肝度，同时少引入额外的快捷键</li>
<li>优化细节使用体验</li>
</ol>
<p>使用以 fabric-api 构建的模组。</p>
<h3>1.1 渲染类</h3>
<ul>
<li>Sodium: 渲染优化之神，许多模组的前置</li>
<li>Sodium-extra: 渲染优化之神的扩展，相应 GUI 为reeses sodium options</li>
<li>Lithium: 原版机制的算法改进</li>
<li>Iris: Sodium 加光影</li>
<li>Custom Entity Models: 自定义实体模型，增强对 optifine 材质包的支持</li>
<li>Continuity: 无缝纹理，安装后需要启用相应的材质包。对第三方材质包支持一般，主要和 optifine 的格式还是不一样。</li>
<li>Indium: 许多模组的前置，提供 Fabric Rendering API的支持</li>
</ul>
<h3>1.2 功能类</h3>
<ul>
<li>modmenu: 显示所有模组和相应的设置页面（如果有的话）设置为 <code>\</code> 开配置</li>
<li>carpet: 单人生存必备，可使用命令放置假人以常加载区块刷红石</li>
<li>tweakeroo: 一系列微调的小功能。主要使用 freecamera（灵魂出窍）<code>f5</code>以获得更好的摄影视角，zoom 开启类似 optifine 的按 <code>c</code> 视角放大，handrestock 可自动补货手里的工具、方块</li>
<li>xaero's minimap: 小地图，降肝度必备。需要设置一下显示的东西，默认会非常多，我只开启了玩家、时间、坐标。关闭了网格显示和生物显示。有世界地图和世界地图的 Plus 版本，联动领地声明功能（虽然单人用不太到）</li>
<li>Carry on：手里没有东西时，<code>shift+右键</code> 搬运箱子，降低装饰的肝度。</li>
<li>JEI + EMI + 通用拼音搜索: 物品搜索，查看合成配方、查看方块用途，EMI 增加了<strong>查看合成树</strong>，在 JEI 的 <code>r</code> 键可看。切换可合成物品。</li>
<li>Invertory Profile Next: 高版本的 R 键背包整理（但被我改成 <code>z</code> 键整理，R 键通常是 JEI 查看合成表）。自动补充工具、连续合成、捡物品时默认扔到背包中，以及在打开箱子时使用滚轮移动物品。关掉快破损时替换工具。</li>
<li>imblock: 输入法冲突修复</li>
<li>Panda's falling tree：砍树时树会倒下，降低砍树的肝度。</li>
<li>Leawind's Third Person: 更好的第三视角。这算是第一个可以日常使用的第三视角模组，挖方块瞄准都很方便。日常的垂直平滑 0.5 以上，不然爬山能晕死。特点是不绑快捷键。</li>
<li>better combat: 动作战斗优化，攻速和攻击范围都有反馈了。</li>
<li>Litematica：投影。辅助红石机械建造，也算是一种降生存建筑的肝度。使用相当简单，一根木棍，control+滚动切换模式，快捷键进菜单。最难的其实是收集足够多的预置模型。但这个模组，要抢 Map 的 M 键……键位需要大改。</li>
<li>Hey Wiki: 在指向物品时按 h 键查询wiki。在物品越来越多的高版本具有一些引导作用。</li>
</ul>
<h3>1.3 新物品</h3>
<ul>
<li>Gliders：类似塞尔达的滑翔伞，防摔。在空中按空格展开滑翔。使用方式和大部分游戏一致。只是要占一个盔甲位。动画做得很不错。</li>
<li>Waystones：传送石碑，后期物品，降低交通的肝度。如果用地图作弊路径点传送就不需要这个东西了，但理想的玩法还是地图只是用来看的，让传送石碑在地图上显示（需要前期多刷小黑），只能传送石碑处，禁止任意传送。传送石不是个好设计，MC背包不能放下更多东西了。除非有单纯扩容用的背包模组。</li>
<li>travelersbackpack：背包模组，终于有了 fabric 版。虽然 mojang 一直很谨慎地加入新的方块，但似乎从未考虑过方块越来越多时的背包使用问题。再者模组整合包也因为方块种类数爆炸的问题增加背包模组。在 1.12 版本时，背包容量是刚好够的。个人并不是很喜欢背包的设计。</li>
</ul>
<h2>2. 设置</h2>
<ul>
<li>画面尺寸: 1920*1080@60fps，窗口化</li>
<li>视场角: 85</li>
<li>鼠标灵敏度: 75</li>
<li>模拟距离：8</li>
<li>渲染距离：12</li>
</ul>
<h3>2.1 快捷键修改</h3>
<p>总体的键位映射图如下。深绿色为原版的功能。橘色为Mod功能，蓝色为创造模式功能。键位分为直接按键、组合键、修饰键（长按）。MC 原版只能定义直接按键，组合键与修饰键在复杂的 mod 中用得多，并且会覆盖原版的直接按键。</p>
<p><img src="https://img-cf.sansui233.com/imgs/2026/01/202601132155912.webp" alt="KeyMaps"></p>
<h4>游戏主界面</h4>
<p>首先把 ctrl 改到 capslock 键位，方便疾跑。系统全局 powertoys 改的（吐槽一万句control的键位）</p>
<ul>
<li>长按 <code>tab</code>，滚轮切换物品栏。在tweakroo 的「工具」中开启 hotbarscroll，再在 tweakroo  的「快捷键」中把 hotbarscroll 的快捷键设置为 Tab。</li>
<li><code>v</code>: 切换第三人称视角(visual)，很常用的功能。原本是f5，实在太远了</li>
<li><code>f4</code>: Leawind's Third Person 第三人称视角相机调位置。同时关掉左右切换。点按左右，长按居中</li>
<li><code>f5</code>:  灵魂出窍，在 tweakroo 的 freecamera 中设定</li>
<li><code>c</code>: 望远镜，在 tweakroo 的 zoomactivate 中设定</li>
<li><code>b</code>：开背包（如果物品栏有的话）</li>
<li><code>t</code>: 路标点传送管理(transport)。聊天改 <code>enter</code> 键</li>
<li><code>x</code>: 锦致装饰-箭袋</li>
<li><code>m</code>:  显示大地图和设定。地图的其他快捷键全关掉。</li>
<li><code>n</code> Litematica 投影菜单</li>
<li><code>h</code> Hey Wiki 查询指向的物品 Wiki</li>
<li><code>shift+右键</code> 空手时搬运箱子，carry on 自带。</li>
<li><code>\</code> Mod Menu配置</li>
<li><code>n+c</code> Litematica 配置。n系列特别多键。</li>
<li><code>x+c</code> tweakroo 配置</li>
</ul>
<p>特定工具下的修饰键：</p>
<ul>
<li>木棍工具
<ul>
<li><code>~</code>  Litematica 木棍工具修饰键，改变区域大小</li>
<li><code>n+enter</code> Litematica 木棍工具模式5且创造模式下放置投影</li>
</ul>
</li>
</ul>
<p>预留键位：</p>
<ul>
<li><code>g</code> 圆盘菜单</li>
<li><code>~</code>  特定工具修饰键，比如连锁挖矿</li>
<li><code>b</code> 背包(backpack)</li>
<li><code>j</code> FTB任务书(journal)</li>
<li><code>左alt</code> 创造模式下，建筑模组 axiom 用 alt 切换专用物品栏。</li>
</ul>
<h4>合成台、箱子UI</h4>
<ul>
<li><code>r</code> : JEI 查看光标下物品的合成方式</li>
<li><code>u</code> : JEI 查看光标下物品的用途</li>
<li><code>ctrl + 左键点击</code> JEI的物品，移动物品到合成台</li>
<li><code>z</code> : 一键整理。在 IPN 的设置中修改。</li>
<li>使用滚轮以在背包和箱子间移动物品，按shift移动整组</li>
</ul>
<h2>3. 光影</h2>
<ul>
<li>BSL v8.2.04，默认配置High，把 Camera 中的 Bloom 关闭，把 Atmosphere 中的 fog 调到 0，开启 lighting 中的handDynamicLight。抗锯齿的TAA随便开不开，取决于风扇响不响</li>
<li>Complementary Reimagined，配置 medium，high 会开启材质的反射运算量明显变大。夜晚也比较亮，适合生存。</li>
<li>itt 3.0，更适合搭配了写实系材质的建筑，风格最写实的 shader 没有之一。不适合生存。</li>
</ul>
<h2>4. 材质</h2>
<ul>
<li>任意矿物发光材质。比如 <a href="https://www.curseforge.com/minecraft/texture-packs/new-glowing-ores">New Glowing Ores</a>。主要是因为 BSL 光影没有矿物发光，所以要加一个材质以确保有 fallback。</li>
<li><a href="https://afdian.net/a/Nan2uu">彩虹像素</a>，非常优秀的免费猛男材质包，原版风但更精致。有很多更可爱的附加包。</li>
</ul>
<h2>5. 创造模式附加</h2>
<h3>5.1 Mod</h3>
<p>Axiom 高版本环境必备，可以创建实体方块随意拉伸模型，相当好用。</p>
<p>effortLess structure 快速建造几何体。原 effortless buidling。</p>
<p>lotweaks 自定义材质轮盘</p>
<p>wordedit 经典创世神</p>
<h3>快捷键</h3>
<p><code>tab</code>: effortLess structure 轮盘。</p>
<p><code>r</code>: lotweaks 轮盘，和手中方块有关。会禁用丢东西（但创造模式本来就不用丢东西除了篝火灭火，何不用 Axiom 的调试棒？）</p>
<p><code>左 alt</code>： Axiom 的大菜单</p>]]></content>
        <category label="游戏"/>
        <published>2026-01-12T18:38:09.000Z</published>
    </entry>
    <entry>
        <title type="html"><![CDATA[z-index 设计与海浪模型]]></title>
        <id>https://sansui233.com/posts/z-index-and-context-management-and-design-logic</id>
        <link href="https://sansui233.com/posts/z-index-and-context-management-and-design-logic"/>
        <updated>2026-01-06T18:20:00.000Z</updated>
        <summary type="html"><![CDATA[z-index 只是个插件，层叠上下文才是真正的 z 轴]]></summary>
        <content type="html"><![CDATA[<blockquote>
<p>摘要：本文针对前端中多个元素层叠时 z-index 管理混乱的问题，提出一个名为海浪模型的设计模型，以构建复杂 z-index 管理的最佳实践。</p>
</blockquote>
<p>……好像 AI。但我是人，我纯手打的。</p>
<h2>基础知识 - 代码的画布</h2>
<p>层叠上下文是代码逻辑上的画布。一旦一个元素产生了层叠上下文，它内部的所有子元素就被包裹在这个范围里。</p>
<p><strong>层叠上下文的产生</strong></p>
<ul>
<li>根元素：<code>&#x3C;html></code></li>
<li>定位 + 层级：<code>position</code> 为 <code>relative</code> / <code>absolute</code> 且 <code>z-index</code> 不是 <code>auto</code>。</li>
<li>固定定位：<code>position: fixed</code> 或 <code>sticky</code>。</li>
<li>CSS3 属性：
<ul>
<li>opacity 小于 1。</li>
<li>transform 不为 none（比如旋转、缩放）。</li>
<li>filter（滤镜）、flex/grid 子元素的 z-index 等。</li>
</ul>
</li>
</ul>
<blockquote>
<p>❗注意：层叠上下文的产生，和层内元素关系，是两套规则，两者之间<strong>没有关系，没有关系，没有关系</strong>。因为部分规则相似，很容易给记混了。</p>
</blockquote>
<p><strong>层叠内元素关系</strong></p>
<p>为了好解释，我使用 context-level 说明绝对的上下覆盖关系。</p>
<ul>
<li>CL-1: 背景和边框（最底层）</li>
<li>CL-2: 定位元素（如absolute）且负 z-index</li>
<li>CL-3: 块级元素（static 定位的普通 div 等）</li>
<li>CL-4: 浮动元素（float）</li>
<li>CL-5: 内联/行内块元素（文字、图片）</li>
<li>CL-6: 定位元素（如absolute）且 z-index 没有设定为负，还有 opacity，transform 等。</li>
<li>CL-7: 定位元素（如absolute）正 z-index（最顶层）</li>
</ul>
<p>z-index 在其中的作用相当于是一个算层叠关系的插件。<strong>必须和定位配套使用，否则不生效。</strong></p>
<p>从功能上说，<strong>层叠上下文才是真正面向用户的Z轴</strong>，z-index属性只是这个 z轴的一个插件。</p>
<h2>视觉画布</h2>
<p>可以发现，被提升到 <strong>CL-6</strong> 的层，其规则和产生一个层叠上下文高度重合，<strong>就像产生了一个新的画布</strong>。这也是为什么说，容易把 CL-6 层等同于产生层叠上下文的层，但是不是的，<strong>CL-6 是描述自己作为子元素的层级</strong>，而“产生层叠上下文”描述的自己作为父元素的行为。</p>
<ul>
<li>opacity 且 z-index: 0。位于 CL-3，产生了层叠上下层文，但是其实层级很低，z-index 是无效的。</li>
<li>CL6: relative 且 z-index: auto。位于 CL-6，产生不了层叠上下文，其子元素如果有更低的层级，可能会被盖掉。子元素有更高的层级，会盖掉别人。</li>
<li>CL6: relative 且 z-index: 0。位于 CL-6，产生不层叠上下层文，其子元素层级和当前元素严格一致。</li>
</ul>
<p>理解了这一点，可以记住。在做目录头时，并不是设置了 <code>relative</code> 就万事大吉了，如果你的后面的元素也是 relative，很容易被覆盖。</p>
<h2>z-index 划分</h2>
<p>考虑到我们不可能把所有画布内元素全挤在 CL-6，全靠 DOM 关系划分层级，因此需要设计 CL-7 的层级，也就是正 index 区域。</p>
<p>正 z-index 的画布内元素应处于同一个层叠上下文内。如果不在同一个，则按产生了新的层叠上下文设计。</p>
<h3>基础逻辑</h3>
<p>对于一个画布（层叠上下文）内，我设计新产生的画布设计上分100层。对应 z-index 0（CL-6）到 z-index 100。每 20 层为一个全屏大画布，比如 Modal。也就是</p>
<ul>
<li>0-20：画布内组件层级</li>
<li>20、40、60、80、100：新画布层级</li>
</ul>
<p>那 21-39 有什么用？<strong>没有用，不要用</strong>。只是为了提醒你，这个东西是个大画布。如果把画布内组件设定到了 20 以上，你可能就不知道什么东西溢出到了 Modal。</p>
<p>此外，如果真的想做一些在不同层级上换来换去的小组件，也可以根据模型的定义很快决定放到哪个层级，非常方便。</p>
<h3>海浪模型</h3>
<p>想象一个海星被 5 层海浪（大画布）冲到沙滩上，每一层海浪上有自己的生物群。</p>
<p>大部分生物都挤在海底（0层以下）层，形成了基石。到第 0-19 层有一堆小东西争先恐后地彰显存在感，但是你又觉得不那么重要。之后的20层、40层、60层通常而言清澈透明，但一旦染色后，就会将下面的生物变得不见天日。</p>
<p>此时你觉得这个海星，你应该看到它吗？应该放在哪一层？</p>
<p>通常而言，层级设计遵循以下基础逻辑。</p>
<ul>
<li>大尺寸元素的层级低小，小尺寸元素的层级高。</li>
<li>重要性高的层级高。</li>
</ul>
<p>第一条是一个视觉规律，第二条则是功能需要。</p>
<h3>0-19 层</h3>
<p>根据基础的逻辑，0-20 层我会如下划分。</p>
<ul>
<li>移动端菜单栏 -> 中偏小，重要，9</li>
<li>浮动按钮 -> 中偏小，但不重要，5</li>
<li>侧边栏 -> 大，但重要。你很难说和浮动按钮哪个在上面。这两个要权衡一下，给到 4。</li>
<li>Hover tips -> 小，重要，19<br>
如果 Hover tip 也可能本身是一个交互丰富的大画布，这时要看重要性。如果重要性与 Modal 相当，设到 20（新一层海浪）。如果只是随便看看，共享当前层的主要内容，只是覆盖一下正文，设到 0 或 1。大画布谨慎设置中间值，容易造成混乱。</li>
<li>目录头：暂时一下冒头，给到 0（注意是 z-index:0，不能是 z-index:auto）</li>
<li>拖拽：暂时冒一下头，给到0。</li>
</ul>
<p>在海浪模型里，<strong>带 9 的数字被表示为重要，而整十数表示为新的起点</strong>。</p>
<h3>20、40、60层</h3>
<p>几乎为 Modal 层。通常页面上只会出现一个Modal，20 层足够使用，或者你要设置为40，60，都可以。如果你有很多层 Modal 要排序（窗口管理）。要么从 z-index 入手，要么从 DOM 结构入手。显然，别去动 DOM 结构树，靠 z-index 足够完成窗口层级管理。</p>
<h3>最重要的海星</h3>
<p>这个海星如果你认为是稀世珍宝，任何时候都需要被看见，请直接设置到 999。但一旦，你认为它有可能会被覆盖，请思考它被覆盖时，是不是还是这么重要。</p>
<p>如果不确定，参考基础逻辑：<strong>面积越小通常越重要</strong>。这不是一个我定义的规则，而是客观的视觉逻辑。面积越小，通常代表了信息量越密集。一个很常见的对比是：</p>
<ul>
<li>Hover tips（小面积）：在一个层非常非常重要。但需要被新画布覆盖</li>
<li>消息通知（中小面积）：重要吗？超重要的，但是消息通知上是不是还是应该可以 Hover 一些提示？</li>
<li>Hover reference（大面积）：比如参考。重要吗？很重要。但是你觉得需要被消息通知、进度条覆盖吗？需要。</li>
</ul>
<h3>天空层（1000+）</h3>
<p>总有些东西，你希望他们不要在海浪里浮动，而浮动在天上，不被任何东西覆盖。比如全局进度条、全局 Hover、全局消息。</p>
<p>放在天空的这点问题本身不大。最大的问题是，你觉得这个海星，应该放在海浪还是天空？<strong>不要让本该在海里的海星升天</strong>。一旦你觉得这个海星会被新逻辑的 Modal 覆盖，请让海星立刻返回 0-19 层。</p>
<h2>为什么要思考海浪模型</h2>
<ul>
<li>易于复用：对于可复用的浮动组件，不管其父元素的 CL 层级，总能被安插到正确的位置。如果发现异常，那就是忘了使父元素产生层叠上下文来包裹他</li>
<li>避免混乱，减少设计的心智负担</li>
</ul>]]></content>
        <category label="学习"/>
        <published>2026-01-06T18:20:00.000Z</published>
    </entry>
    <entry>
        <title type="html"><![CDATA[Better Web Typography for a Better Web 中文版]]></title>
        <id>https://sansui233.com/posts/2025-12-30-Better-Web-Typography-for-a-Better-Web-Chinese-Version</id>
        <link href="https://sansui233.com/posts/2025-12-30-Better-Web-Typography-for-a-Better-Web-Chinese-Version"/>
        <updated>2025-12-29T22:10:00.000Z</updated>
        <summary type="html"><![CDATA[我的排版启蒙书]]></summary>
        <content type="html"><![CDATA[<p>这是一本讲网页排版的书籍，书中内容有在线示例与代码，是这么多年来对我极其有用的平面设计书籍之一，说是我的排版启蒙也不为过。此博客的采用的正文排版均构建于此书所介绍的基础上。</p>
<ul>
<li>书名：Better Web Typography for a Better Web</li>
<li>译名：更好的网页排版，造就更好的互联网</li>
</ul>
<blockquote>
<p>此书为 90% 的 AI 翻译，完全保留原书排版，由人工校对以确保大部分用词统一。</p>
</blockquote>
<h2>推荐语</h2>
<p>2018 年，我还在大学社团做海报，那时候对排版的理解更多是靠“直觉”。直到接触到了 Matej Latin 的网页排版公开课，也就是这本书的起源。课和中提出“排版的完美等边三角形”——即字号、行高与行宽之间的动态平衡，以及“模块化比例”的概念，彻底改变了我观察网页的视角。我至今铭记在心：“要获得完美的段落，需要三样东西：字体大小、行高和行宽。它们需要达到平衡。”</p>
<p>从那以后，这三要素就成了我做阅读文字时绕不开的底层直觉。每当我看到一个网页，总会下意识地去拆解它的文字比例是否协调。尽管此书以英文为基准，其中的排版规律对多种语言均适用。</p>
<p>虽然这本书写在八年前，在互联网平面设计风格迭代如此之快的今天，它讨论的核心规则却依然稳固。甚至可以说，如今主流的网页排版方向，就如书中的所言。如果你想摆脱“凭感觉”排版，真正理解排版的美学逻辑，倾情您阅读推荐这本书。</p>
<h2>简介</h2>
<p>Better Web Typography for a Better Web 是一本源自高分在线课程的著作，旨在向网页设计师和开发人员等网站构建者讲解排版。作者 Matej Latin 将垂直节奏（vertical rhythm）、模块化比例（modular scale）和页面构成（page composition）等复杂概念，以通俗易懂的方式进行了深入浅出的解析。本书配有实时代码示例，读者在阅读过程中将亲历设计并构建一个示例网站的完整流程。这是一本针对新媒介的排印新书：基本规则虽未改变，但除此之外的一切都已焕然一新。</p>
<h2>摘录</h2>
<ol>
<li>“……如果说我希望你们从这次演讲中记住一个关键要点，那就是以下内容——要获得完美的段落，需要三样东西：字体大小、行高和行宽。它们需要达到平衡。”</li>
<li>大多数网站都会犯的一个错误，就是将主体文本设置得过小。早在21世纪初，将主体文本大小设置在大约11像素是常见的做法。但当时的屏幕更小，分辨率也较低，这意味着11像素的字体在当时看起来比现在更大。</li>
<li>推荐文本行长度为45至75个字符。需考虑所用语言的平均词长。</li>
<li>我认为，我们开始创建网站时，首先应该审视网站的主要目的。不仅仅是我们正在设计的特定网站，而是其真正、根本的目的。我指的是——<strong>内容</strong>。试想，没有内容的网站是什么？它是一个空壳。内容糟糕但外观精美的网站是什么？它就像一个外表好看但缺乏个性的人。那么反过来说呢——内容出色但外观贫乏的网站？它就像是一个个性鲜明、趣味十足的人，却因为“外表不够标准”而无人关注。</li>
</ol>
<h2>资源链接</h2>
<p>CloudFlare - R2 直链下载：</p>
<ul>
<li><a href="https://img-cf.sansui233.com/books/%E6%9B%B4%E5%A5%BD%E7%9A%84%E7%BD%91%E9%A1%B5%E6%8E%92%E7%89%88%EF%BC%8C%E9%80%A0%E5%B0%B1%E6%9B%B4%E5%A5%BD%E7%9A%84%E4%BA%92%E8%81%94%E7%BD%91%20-%20Matej%20Latin.epub">更好的网页排版，造就更好的互联网 - Matej Latin</a></li>
</ul>
<p>标签： 排版，字体排印，平面设计，网页设计</p>]]></content>
        <category label="书和剧"/>
        <published>2025-12-29T22:10:00.000Z</published>
    </entry>
    <entry>
        <title type="html"><![CDATA[uv 管理 conda 项目依赖]]></title>
        <id>https://sansui233.com/posts/2025-07-24-embed-python-with-uv</id>
        <link href="https://sansui233.com/posts/2025-07-24-embed-python-with-uv"/>
        <updated>2025-07-24T12:12:32.000Z</updated>
        <summary type="html"><![CDATA[沐神都解决不了的……]]></summary>
        <content type="html"><![CDATA[<h2>conda 的问题</h2>
<p>Python 新项目使用 uv 管理容易，但是总是有一些老项目不用。 conda 包管理一直以来都是 AI 的标配。我用 python 99% 都是在扒别人代码运行。这就导致了我运行了多少个项目，就装了多少份 torch……硬盘再大也经不起十几次折腾。</p>
<p><img src="https://img-cf.sansui233.com/imgs/2025/07/202507242029977.webp" alt="沐神都解决不了的"></p>
<p>conda 的问题在于</p>
<ol>
<li>requirements.txt <strong>全手写</strong>！很多人可能忘更新配置，导致扒拉下来缺库运行不了，先解决一个小时的依赖问题再说。</li>
<li>依赖和安装顺序强相关。比如项目需要更新的 numpy，但你可能要装个别的项目的库，python 发了论文和仓库就跑的项目是很多的。安装一个旧项目导致之前安装 numpy 被卸载，然后整个项目就垮掉。这种情况相当之多，又解决两个小时的依赖问题。</li>
<li>（至少我不愿意看到）电脑里十几个相同版本的 torch 和 cuda。当时的硬盘还只有 256G，多装几个 torch 无法接受，嗯……</li>
</ol>
<p>直到现在都还是这样的，大家主打一个能跑完实验就行。包的更新是激进的，包管理是落后的。在几年前有人说用 PDM，后面有 poetry。这两是不用再手写 <code>requirements.txt</code> 了，依赖也会自动 resolve 不会覆盖来覆盖去的，但还是会装十几个 torch。直到 uv 开始用硬链接进行包管理。</p>
<h2>uv 之于 conda 项目</h2>
<p>uv 接管 python 界的依赖管理按理说已经没什么问题。但实际情况是，很多项目还是在用 conda。除非哪天 torch 和 HF 都把 uv 设置为首推，否则就得一直与  conda 存在的问题战斗。</p>
<h3>1. 不提供 venv 的项目</h3>
<p>用于研究的项目一般都是不提供的打包好的环境的，主要是太大了，每个人设备情况也不一样。所以下载后第一件事是</p>
<pre><code class="language-sh">uv venv
./.venv/Script/activate
</code></pre>
<p>如果这个项目不再更新了，或者是打算迁移到 uv，可以直接使用 uv 的方式管理依赖。uv 会自动维护 <code>pyproject.toml</code> 和 <code>uv.lock</code> 文件。</p>
<pre><code>uv add -r requirements.in -c requirements.txt
</code></pre>
<p>如果这个项目，他还在更新，你时不时就得去拉一下分支。这时候最好用 <code>uv pip</code> 。至于依赖混乱问题，听天由命吧。<del>跑得起来就得了</del></p>
<pre><code>uv pip install -r requirement.txt
</code></pre>
<h3>2. 提供 venv 的项目</h3>
<p>提供 venv 的项目通常是给人用的，b 站的整合包一大堆。这种已经配好环境的项目也意味着你最好只用 pip。通常还是非常原始地调用 pip</p>
<pre><code>./.venv/python -m pip install xxx
</code></pre>
<p>……等于说又开始了安装十几份 torch 的依赖管理模式。用 uv 是可以重复利用缓存的。这个时候 uv 的问题在于无法接管 python 环境，需要设置一下环境变量：</p>
<pre><code class="language-sh">export UV_PYTHON="./.venv/python"
uv pip list
</code></pre>
<p>然后就可以利用 uv 的缓存了。</p>
<p>当然，依赖混乱问题使用 <code>uv pip</code> 是无法避免的。这对于发行版也是一种麻烦。因为发行版的环境全给你配好了，但有的项目设计了插件系统，插件系统又需要装插件的 requirement.txt，安一个许久没更新的插件让主项目废掉的情况也不是不可能……</p>
<p>如果让插件作者指定的兼容版本？只靠规范做不到，必须像MC那样检查版本号，不更新版本号就不放行。这样就算不更新代码了，也得倒逼作者每个版本都进行一次（至少是与主项目的）依赖兼容性测试。</p>
<p>我觉得以当前 python 的运行方式，不 lock 子依赖的版本，这个问题是没法解决的。</p>
<h2>uv 管理 torch 下载源</h2>
<p>通常而言，在不指定 index 时 uv add torch 是去 pypi 或清华镜像源找 CPU 版本。如果打算每个项目都采用一样的 torch 版本 和 cuda ——</p>
<h3>uv 创建的新项目</h3>
<p>共用的 <code>uv.toml</code> 指定下载源。</p>
<p>Linux 在 <code>.config/uv/</code> 下，Windows 在 <code>%APPDATA%/uv/</code> 下。</p>
<pre><code class="language-toml">[[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
</code></pre>
<p>项目级别的 <code>pyproject.toml</code></p>
<pre><code class="language-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"},
]
</code></pre>
<p>然后执行 <code>uv sync</code> 安装。</p>
<h3>uv pip 管理老项目</h3>
<p>直接指定命令行 的 <code>--index-url</code> 和 <code>--torch-backend</code></p>
<pre><code class="language-shell">uv pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu126 --torch-backend=cu126
</code></pre>
<p>和用 pip 的方式差不多，区别是会硬链接到集中的缓存，不会重复占用十几份 torch。当然。该有的依赖冲突还是会有的。<del>关键是装好后就不要更新了</del></p>]]></content>
        <category label="学习"/>
        <published>2025-07-24T12:12:32.000Z</published>
    </entry>
    <entry>
        <title type="html"><![CDATA[踩了一圈 CSS 构建方案的坑]]></title>
        <id>https://sansui233.com/posts/2025-07-12-compare-css-solutions</id>
        <link href="https://sansui233.com/posts/2025-07-12-compare-css-solutions"/>
        <updated>2025-07-12T04:49:09.000Z</updated>
        <summary type="html"><![CDATA[前端代码中质量最薄弱的一环]]></summary>
        <content type="html"><![CDATA[<p>css 的写法一直算比较混乱的。层叠的样式表与 DOM 结构的分离看似清晰，但也因此容易产生屎山，组合太自由，哪些选择器用了哪些选择器没用，共用的嵌套的，分离的。今天小编就带你一探究竟（……）</p>
<h2>CSS类复用粒度</h2>
<p>我自己把 css 选择器（类）的复用粒度分三个层级。</p>
<h3>组件类</h3>
<p>粒度最大的层级，通常按组件级别语义化。选择器一般是下面这些名字</p>
<pre><code class="language-css">.wrapper
.container
.list-item
</code></pre>
<p>组件化的选择器下面通常有很多条的 css。</p>
<h3>功能类</h3>
<p>通常是共用的样式或状态，比如</p>
<pre><code class="language-css">.open
.close
.light
.dark
.glass-effect
</code></pre>
<p>这个看起来好像和组件类不冲突，但硬说的话组件类其实应该是这样</p>
<pre><code class="language-css">.container.open { 此处将 .open 的所有样式全覆盖 }
.container.close { 此处将 .close 的所有样式全覆盖 }
.container.light { 此处将 .light 的所有样式全覆盖 }
.container.dark { 此处将 .dark 的所有样式全覆盖 }
</code></pre>
<p>组件类的状态严格在组件的 scope 下。功能类则是可以不限 Scope 的复用。</p>
<p>这 CSS 容易混乱的根源。在工程维护角度，功能类是最不敢乱动的类，不知道动了后哪里样式就会出问题。但在设计角度，用功能类复用一些状态又确实很方便，统一设计也好用。比如增加统一的圆角、描边、阴影样式。</p>
<p>功能类的优缺点是一体两面——图像的只有主观的好看与否，没有客观的对错。</p>
<h3>原子类</h3>
<p>定义海量常用的基础样式类，在 class 上直接写类名就能获得对应效果。就是 tailwind css。</p>
<p>原子类相较于功能类粒度更小，也不会轻易改动 css 属性。</p>
<pre><code class="language-css">.flex
.col-1
.text-sm
</code></pre>
<h2>方案</h2>
<p>通常来说，一个库的样式会着重在一个某一个粒度上。</p>
<h3>原生 css</h3>
<p>用原生 css 时通常会以 <strong>组件化</strong> 的粒度为主，带极少的功能类。现在配合 css 变量使用。早期的网页简单，一个 CSS 文件就能搞定全站，设计上并没有考虑项目变得越来越复杂后的实践。</p>
<p><strong>优点</strong>：性能好，扁平的结构利好小项目。适合写研究新样式。</p>
<p><strong>缺点</strong>：过于扁平，大量工程化后易屎山，存在样式与 DOM 分离带来的维护混乱。</p>
<h3>SCSS</h3>
<p>古法预处理器，可能多层嵌套 css，可组合。是 <strong>组件化</strong> 的粒度。在 CSS.module 出来前，用 SCSS 分割 Scope 挺好用。</p>
<p><strong>优点</strong>：结构非常清晰</p>
<p><strong>缺点</strong>：</p>
<ol>
<li>编译后的选择器很长一串，从浏览器渲染角度，匹配DOM是耗性能的</li>
<li>难以应对复杂项目 DOM 结构的改变，需要考虑扁平化 + 命名，但这样做和原生 CSS 的维护体验也不相上下。</li>
</ol>
<h3>CSS Module</h3>
<p>CSS Module 是完全 <strong>组件化</strong> 的粒度。相比起 SCSS 的样式与 DOM 分离，CSS Module 为组件内部样式耦合，组件间样式分离。</p>
<p><strong>优点：</strong> 在组件粒度分割合理的情况下，清晰易维护。</p>
<p><strong>缺点</strong>：依赖预构建，写类名写起来太磨叽了。整体我用得不多没法评价。</p>
<pre><code class="language-jsx">const Button = () => {
  return (
    &#x3C;button className={styles.button}>
      Click me
    &#x3C;/button>
  );
};
</code></pre>
<h3>BootStrap</h3>
<p><strong>组件化</strong> 为主，少量原子化修饰的预制样式库，拿来即用是不错的。早期 CSS 框架大多是指预制样式，和预构建的库有本质区别。</p>
<h3>Tailwind css</h3>
<p>完全原子化的神奇之库，通过编译可以有功能类和组件类。它更像是重新定义了 css 语法。</p>
<p><strong>优点</strong></p>
<ol>
<li>灵活，快，好看</li>
<li>工具链齐全，可以裁剪掉不用的原子类。</li>
</ol>
<p><strong>缺点</strong></p>
<ol>
<li>稍微要写复杂一点的样式，DOM 就会被一大堆 class 埋没。</li>
<li>从浏览器渲染角度，匹配、合并大量 CSS 样式是需要更多性能开销的</li>
<li>要做到同种样式的复用，必须组合原子类，变成功能类或组件类，否则维护起来相当麻烦。这似乎违背了用 tailwind css 的初衷，熟悉了 css 的不如直接自己用 css 手撮功能类和组件类。</li>
<li>其实我是 tailwind 黑，嗯。但无法否认开发时确实很快很方便。</li>
</ol>
<pre><code class="language-jsx">function Card({ title, description, imageUrl, imageAlt }) {
  return (
    &#x3C;div className="max-w-sm rounded overflow-hidden shadow-lg">
      &#x3C;img className="w-full" src={imageUrl} alt={imageAlt} />
      &#x3C;div className="px-6 py-4">
        &#x3C;div className="font-bold text-xl mb-2">{title}&#x3C;/div>
        &#x3C;p className="text-gray-700 text-base">{description}&#x3C;/p>
      &#x3C;/div>
      &#x3C;div className="px-6 pt-4 pb-2">
        &#x3C;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&#x3C;/span>
        &#x3C;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&#x3C;/span>
        &#x3C;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&#x3C;/span>
      &#x3C;/div>
    &#x3C;/div>
  );
}
</code></pre>
<h3>原生 css in js</h3>
<p>指 JS Object 转译为 CSS。由于写起来太不像 CSS，复杂的功能写起来过于不直观 ，我直接 PASS。</p>
<pre><code class="language-jsx">const InlineStyleExample = () => {
  const myStyle = {
    color: 'blue',
    backgroundColor: 'lightgray',
    padding: '10px',
    borderRadius: '5px'
  };

  return (
    &#x3C;div style={myStyle}>
      &#x3C;p style={{ fontSize: '18px', fontWeight: 'bold' }}>
        This text is styled with inline CSS.
      &#x3C;/p>
    &#x3C;/div>
  );
};
</code></pre>
<h3>Styled-components</h3>
<p><strong>组件化</strong>的 CSS in JS 方案，写起来像 CSS 实际是 JS。支持客户端动态修改 CSS 具体属性（其他方案做状态改变主要依靠 selector 的匹配）</p>
<p><strong>优点</strong>：</p>
<p>灵活好拓展，比如主题管理不仅仅是颜色，还可以是图片资源一类的。</p>
<p><strong>缺点</strong>：</p>
<ol>
<li>因为是 JS 转 CSS，服务器编译慢和客户端渲染慢得选一个</li>
<li>React 的 useContext 要被废弃了，而 styled-components 严重依赖此 hook，导致进入了维护状态。JS 框架发展太快了。</li>
</ol>
<pre><code class="language-jsx">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;

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

function App() {
  return (
    &#x3C;div>
      &#x3C;StyledButton>Click Me&#x3C;/StyledButton>
    &#x3C;/div>
  );
}
</code></pre>
<h3>Linaria</h3>
<p>自定义 <strong>功能类</strong> 的 CSS in js 方案，同时也支持 <strong>组件化</strong> 写法。生成的是完全静态的 css，样式值的复用靠变量，片段的复用靠 <code>css</code> 生成的类。</p>
<p><strong>优点</strong>：</p>
<p>是预构建方案，在服务端渲染。和原始的 CSS 写法和思路差不多。</p>
<p><strong>缺点</strong>：</p>
<ol>
<li>
<p>值复用靠变量，但是由于是 <strong>静态 css</strong>，这个并不会变。所以变量插值<strong>其实是常量</strong>。比如下面的 font-size 并不会变化。</p>
<pre><code class="language-jsx">const fontSize = 16;
const Title = styled.h1`
  font-size: ${fontSize}px;
`
</code></pre>
<p>也就是说，你如果想在客户端随意改变字体，用 context/zustand 这种 runtime 的 fontSize，这样写报错。不过，Linaria 允许你借助 react 的 props 和 <code>styled</code> 组件来实现客户端的值变化。</p>
<pre><code class="language-jsx">const Title = styled.h1`
  font-size: ${props => props.size}px;
`
export default function MyComponent() {
  const fontSize = useAppStore(state => state.fontSize)
  return &#x3C;Title fontSize={fontSize}>Hello&#x3C;/Title>
}
</code></pre>
<p>相当于生成</p>
<pre><code class="language-jsx">&#x3C;h1
  className="_title_xyz"
  style={{ '--linaria-font-size': `${size}px` }}
>
</code></pre>
<p>那这和 styled-components 写起来已经差不多了。而且要做主题化的值都得用快要废弃的 <code>useContext</code> API。只不过 linaria 改的 style 属性，styled 是改的 css  API。改 style 属性其实已经不能算静态了。</p>
</li>
<li>
<p>组件间的<strong>样式复用方案</strong>只有原生的 CSS 方案，上述的奇妙客户端插值做不了这个需求。假设，你要做一个主题化的对话框的卡片阴影，只能使用原生 css 类中加原生 css 变量。上述动态改变样式的因为依赖 props，只能使用 <code>styled</code> 的写法，但这样就会把 html 标签了也继承了，不同的样式也无法随意组合。这也是为什么我说 Linaria 是原生 css 的替代，而不是 styled-components 的替代，构建方式就决定他们差得太了远。</p>
</li>
<li>
<p>基于2，导致你写组件又要检查 <code>styled</code> 又要确认 <code>css</code> 类又要检查 JSX classname 的顺序。如果用组件继承会被迫连 DOM 类型都继承。</p>
</li>
<li>
<p>使用功能类有点像原子化，又完全不如 tailwind 已经给你预设好一堆东西的效率。写类名和 cssmodule 一样，太磨叽了</p>
</li>
</ol>
<p>我博客本想迁移至此方案，但由于工作量实在巨大而放弃。linaria 主要还是解决了个命名空间冲突的问题，想用得更深入一点就会四不像。</p>
<pre><code class="language-jsx">import { css } from '@linaria/core';

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

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

export default App;
</code></pre>
<h2>构建组建库</h2>
<p>每一个 CSS 方案都有对应的构建组件库的实践。 <a href="https://github.com/shadcn-ui/ui">shadcn</a> 是基于 tailwind 构建组件库实践。</p>
<h2>CSS 框架选择要素</h2>
<ol>
<li>样式复用</li>
<li>样式组合</li>
<li>动态样式</li>
<li>主题切换</li>
<li>代码提示</li>
<li>自动裁剪</li>
<li>随意重构</li>
<li>渲染性能</li>
<li>实践的统一性</li>
</ol>
<p>最重要的还是自己的需求。</p>]]></content>
        <category label="学习"/>
        <published>2025-07-12T04:49:09.000Z</published>
    </entry>
    <entry>
        <title type="html"><![CDATA[Steam 假入库是怎么做的]]></title>
        <id>https://sansui233.com/posts/2025-04-22-techs-about-steam-crack</id>
        <link href="https://sansui233.com/posts/2025-04-22-techs-about-steam-crack"/>
        <updated>2025-04-21T19:59:00.000Z</updated>
        <summary type="html"><![CDATA[入库不仅仅是入库]]></summary>
        <content type="html"><![CDATA[<p>很久以前被淘宝的 Steam 假 CDKey 给坑过，因为价格其实也不便宜，打的正版宣传，其实是盗版，后来感觉太可疑了查了一下确认被坑了。现在突然想起来了解了一下。本文概述是日常语境中的 “Steam假入库”需要的一些步骤，概括起来为五个方面：解锁、下载、入库、DRM、API验证。</p>
<h2>下载验证</h2>
<p>steam 的下载鉴权流程是</p>
<ol>
<li>查找账号是否有拥有此游戏，有则显示下载按钮</li>
<li>点击下载后，把游戏软件 Manifest 对应的密钥（DecryptionKey）明文写入一个本地文件 <code>Steam\config\config.vdf</code></li>
<li>Steam （原版）根据 <code>config.vdf</code>中的信息，发送下载请求至 Steam CDN 进行下载</li>
</ol>
<p>“Steam 解锁” “Steam 假入库” 指的是绕过上述机制。具体而言，如果没有购买游戏，可以：</p>
<ol>
<li>将按钮变为可下载（至于是伪造请求实现还是逆向 hook 实现，我不知道，都可以，因为甚至不需要变按钮，给个外部的下载按钮也可以）</li>
<li>点击按钮后，从不知名渠道获取一个正版账号的 Manifest（下载清单）和 Decryption Key（下载密码），写入<code>Steam\config\config.vdf</code></li>
<li>Steam（原版）根据 <strong><code>config.vdf</code></strong>，发送下载请求至 Steam CDN 进行下载</li>
</ol>
<p>Steam 的下载验证可以说是相当简单，明文本地存密码，CDN 无状态的验证，这么多年没有改过流程，给入库工具空间（虽然说前端的事总有办法 Hack 但也是可以让 Hack 成本变高很多的）。不过 Steam 理念本来就是以平台服务留住玩家的，反倒是扩大了其影响力与营收。</p>
<p>一些名词解释：</p>
<ul>
<li>解锁：指对没有购买的游戏，“可以显示下载按钮”。和能不能下载没有关系。</li>
<li>下载：Steam 根据 <strong><code>Steam\config\config.vdf</code></strong> 的信息下载游戏文件。</li>
<li>入库：指把下载好的游戏，在当前电脑的 Steam 库中显示。</li>
</ul>
<p>以上过程均不涉及对游戏本身的破解，只是对 Steam 下载过程的破解。也就是，破解的是 Steam，不是游戏。</p>
<h2>运行时验证</h2>
<p>这里开始才会涉及到游戏破解。</p>
<p>有的 Steam 游戏下载下来后是不用破解的，直接找到游戏目录，点 exe 可以正常游玩（比如星露谷）。只是无法通过原版 Steam 打开，也就只能离线。</p>
<p>有的游戏是无法脱离 Steam 直接运行的。这里涉及两层验证：</p>
<h3>加密算法层</h3>
<p>这是一层 DRM（数字版权加密保护）。Steam DRM 系统的名称为 SteamStub。SteamStub 的加密有各种的变体，每个游戏使用的不一致。只对 exe 的算法加密，是一个离线的步骤。不涉及 Steam 平台的验证。</p>
<p>网上有一个开源工具叫 Steamless，可以破除 SteamStub 对游戏的 DRM，称为脱壳。但脱壳本身不处理 Steam 在线验证相关，只进行了脱壳的游戏也是无法正常游戏的。</p>
<blockquote>
<p>SteamStub DRM 和 Steamworks API 是两个独立层。Steamless <strong>仅移除 SteamStub 加密外壳</strong>，但游戏代码中与 Steam 平台功能（如成就、云存档、联机）相关的 API 调用（通过 <code>steam_api.dll</code>）仍会保留。</p>
</blockquote>
<h3>Steam API 验证</h3>
<p>游戏还可能调用 Steam api 进行在线通信，如成就、云存档、联机相关的 API 调用。</p>
<p>这是使用入库工具玩破解游戏可能被红信或封号的根本原因，因为对 API 的调用是发送到 Steam 官方服务器的。在小红书上了解到，有的玩的盗版可以与正版联机，说明 Steam 在联机时并不会验证账号是否拥有该游戏。包括 Steamtools 实现的家庭共享联机，也说明了 Steam 对于是否账号可以进行联机鉴权不足。但只要留有记录就有可能导致被封号，取决于 Steam 什么时候想管理盗版现象。</p>
<p>反之，如果伪造一个 Steam 的服务器，并且替换游戏中的 Steam 相关的动态链接库，如 <code>steam_api.dll</code> ，游戏里所有对 Steam API 的调用被发送到假服务器上，返回一个假的结果。这种工具也已经有了，项目为 goldberg_emulator，简称 GBE。破解版的游戏通常会内置一个这样的虚拟 Steam 环境。</p>
<h3>第三方厂商验证</h3>
<p>很多大厂的游戏有自己的联机服务器和验证机制、不仅走 Steam API 的验证。这种也是可以通过虚拟环境破解，但没人做，除非专门对这个游戏的所有 API 做逆向。难度比逆向通用的 Steam API 高很多。</p>
<h2>Steamtools 是什么</h2>
<p>已知 Steamtools 主要是做 <strong>解锁</strong> 和 <strong>入库</strong>。对于会不会破解游戏，网上没有更多的信息。我也不想冒风险尝试使用它。</p>
<p>根据官网的解释，Steamtools 可以离线运行（不如说破解游戏只能是离线运行），是提供了类似 GBE 的验证环境。有没有对 DRM 脱壳不清楚，但个人倾向于有，很多游戏都有 DRM 的保护，除了 SteamStub，还有其他的 DRM 验证方式，不脱壳玩不了。</p>
<p>因此个人推测是，Steamtools 是集 <strong>解锁、下载、入库、破解、运行时验证</strong> 为一体的工具集。</p>
<h2>SteamAutoCrack 是什么</h2>
<p>只做 DRM 脱壳和 Steam API 验证。项目在 Github 上，破解后的游戏会运行在 GBE 的环境下。这种方式是完全离线运行的单机。</p>
<h2>风险来源</h2>
<p>完全脱离 Steam 运行没有风险，只要在线就可能有风险。</p>
<p>假入库阶段的风险主要来自于入库工具对 Steam 请求拦截的覆盖程度不足。例如 Steam 版本更新了，使得 API 和下载流程有变化，而入库工具没有对其做处理，无法完全欺骗下载流程。网上看到假入库的人可能有囤积癖或者是打算做灰产，一次性入库了几十个游戏，直接导致被 SteamCDN 拉黑。</p>
<p>运行时的风险也是来自于在线验证，如果是开着 Steam 玩的破解游戏，没有离线时甚至尝试联机，使得游玩信息发送到了 Steam 的服务器（比如不该有的存档、不该有的联机等等）。</p>
<p>另外，入库工具会侵入式修改 Steam的客户端，直接打开 Steam 可能会有检测文件是否被修改。 Steamtools 提供了三种启动模式，可以随时恢复为原版 Steam 的运行。但淘宝卖的入库工具说不准是什么样的，当年骗我的店家那个用的是早期的 steamtools，使用店家的账号下载游戏后，使用 steamtools 离线运行（本来已经忘记了，努力想想竟然想得起来一点细节）。但现在的店家说不准是什么样的，在 B 站看到说有的是直接修改文件，从此都是盗版Steam 客户端，只能卸载重装。</p>
<p>没有风险的方式：如果你有方式得到 Steam 正版的游戏文件，然后用 SteamAutoCrack 破解，能直接脱离 steam 运行则没有风险。</p>
<p>对于更多的人而言，下载木马是最大的风险。</p>
<h2>参考资料</h2>
<ul>
<li>bbs.steamtools论坛</li>
<li>SteamManifestCache wiki</li>
<li>SteamLess Readme</li>
</ul>]]></content>
        <category label="Diary"/>
        <published>2025-04-21T19:59:00.000Z</published>
    </entry>
    <entry>
        <title type="html"><![CDATA[Windows11 右键菜单自定义 - NileSoft Shell]]></title>
        <id>https://sansui233.com/posts/2025-04-19-windows-context-menu</id>
        <link href="https://sansui233.com/posts/2025-04-19-windows-context-menu"/>
        <updated>2025-04-18T17:21:04.000Z</updated>
        <summary type="html"><![CDATA[颜狗就是得样式和功能性全要，怎么了]]></summary>
        <content type="html"><![CDATA[<p>（发现简中圈居然没有人写这个事，写个草稿发别的地方）</p>
<p>Windows11 右键菜单问题被诟病已有，网上很多还原为 win10 菜单的教程……但 win10 有 win10 的问题，有用的没用的都往里放，常用的不常用的混在一起。有没有一种方法可以兼顾好看，同时有合理的菜单层级呢？</p>
<p>有的 —— Nilesoft Shell。可以自定义的 Win11 右键菜单。已经用了两年多了很好用（以至于差点忘了有这个软件）。</p>
<h2>下载并安装</h2>
<p>下载在官网： <a href="https://nilesoft.org/">https://nilesoft.org/</a></p>
<p>安装完后，新菜单应该已经生效了，并且会开机自启。这时候可以点点看，如果感觉效果满意就不用再看下去了。</p>
<p>当然颜狗是不满意的，大部分一级菜单我用不上，我只想保留我常用的，不用的塞到更多选项。如图</p>
<p><img src="https://img-cf.sansui233.com/imgs/2025/04/202504190843358.webp" alt=""></p>
<h2>挪动菜单层级</h2>
<p>如果你是默认安装，<code>C:\Program Files\Nilesoft Shell</code> 应该能看见以下的文件结构</p>
<pre><code>Nilesoft Shell/
├── shell.exe
├── shell.nss
├── imports/
│   ├── modify.nss
│   └── ...
└── ...
</code></pre>
<p>以 <code>.nss</code> 结尾的是配置文件，可以用记事本打开。以下是几个案例：</p>
<h3>1. 收纳不常用菜单至 “更多选项”</h3>
<p>例如，收纳所有名称里带有 “QQ” 和 “百度” 的菜单项，在 <code>modify.nss</code> 添加如下：</p>
<pre><code>modify(mode=mode.multiple find="QQ|百度|网盘" menu=title.more_options)
</code></pre>
<p>find 中包含的字符串会被匹配，“|”是或。表示匹配“QQ”或“百度”或“网盘”的任意项都会被挪走。</p>
<p>这是主要的挪菜单的方式，我实际上挪了一大堆。</p>
<pre><code>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)
</code></pre>
<h3>2. “创建快捷方式”挪到顶层</h3>
<p>有人可能看不惯 创建快捷方式 放在了 更多选项 里。要恢复把 <code>modify.nss</code> 中一行注释掉就好。</p>
<pre><code>modify(mode=mode.multiple
	where=this.id(
		id.send_to,
		id.share,
		// id.create_shortcut, 这行注释掉
		id.set_as_desktop_background,
		id.rotate_left,
		...
</code></pre>
<h3>3. 顶层添加新菜单项 “使用 vscode 打开”</h3>
<p>在 <code>shell.nss</code> 中，新起一行添加</p>
<pre><code>item(title='Open with VS Code' image=[\uE272, #22A7F2] cmd='code' args='"@sel.path" &#x26;&#x26; exit' sep='top')
</code></pre>
<p>添加的这行可以不在最后，添加的位置决定它在菜单中的位置。我添加在了中间，最后的几个 "import" 之间。</p>
<p>要是问为什么我不用 vscode 自带的右键菜单……我的 vscode 装得太早了，那时还没有右键菜单关联，现在也懒得再装了就将就用吧……</p>
<h3>4. 顶层菜单添加新目录</h3>
<p>你要是在图片上右键，会发现系统自带有“使用 Windows 画图编辑”“使用照片编辑”“向左旋转”“向右旋转”……我的天，哪个天才设计的，你不知道自家照片 App 打开后能编辑也能旋转吗？（我知道这肯定是两波人开发的但还是想吐槽）</p>
<p>秉持着只挪不删的原则，在“更多选项”前加了个“编辑”目录。以下加在了 <code>shell.nss</code></p>
<pre><code>menu(mode="multiple" title="编辑" image=image.glyph("\uE0A1"))
{
}
</code></pre>
<p>然后在 <code>modify.nss</code> 里加了</p>
<pre><code>modify(mode=mode.multiple
	find="*编辑|旋转|PDF"
	menu="编辑")
</code></pre>
<p>这样等于说，编辑和旋转相关都被归到了新的“编辑”目录下。加上 PDF 相关操作挪进去。我没有装 WPS，装了 WPS 也可以把 WPS 挪一个目录。</p>
<h2>生效</h2>
<p>管理员权限运行安装目录下的 <code>shell.exe</code>，点 Register 生效</p>
<h2>其他</h2>
<p>按 shift 后右键菜单，会有一个“Developer” 目录。没错 shift 显示隐藏菜单也可以实现，配置的属性有 <code>vis=key.shift()</code> ，但不是实时变化的所以没有mac 上的好用。除此之外还有喜闻乐见的能配置主题、颜色、图标等……我不管了。</p>
<h2>参考</h2>
<p>官网的文档很详细，但是非常面向程序员。不过大部分的需求被人在论坛上问过了，也有人在 issue 里问。不会就去论坛翻一下。看不懂英文开翻译，看不懂文档丢给 AI。</p>
<p>文档： <a href="https://nilesoft.org/docs">https://nilesoft.org/docs</a></p>
<p>论坛： <a href="https://github.com/moudey/Shell/discussions">https://github.com/moudey/Shell/discussions</a></p>]]></content>
        <category label="工具"/>
        <published>2025-04-18T17:21:04.000Z</published>
    </entry>
    <entry>
        <title type="html"><![CDATA[2024 年的总结与分享]]></title>
        <id>https://sansui233.com/posts/2025-01-05-2024-summary</id>
        <link href="https://sansui233.com/posts/2025-01-05-2024-summary"/>
        <updated>2025-01-04T17:21:04.000Z</updated>
        <summary type="html"><![CDATA[怎么全在写游戏……]]></summary>
        <content type="html"><![CDATA[<p>印象中之前每年其实都有写去年主要干了什么，看了什么作品。但又忘了都写在了哪里。今年想起来还是在这里写吧。</p>
<p>主要说说看了些什么吧。</p>
<h2>实用小技术</h2>
<ol>
<li>无线 iPad 当作电脑副屏</li>
</ol>
<p>某天突然想躺着用手柄玩电脑的游戏，所以 <a href="https://github.com/LizardByte/Sunshine">sunshine</a> + moonlight(iPad) 串流。效果非常不错！</p>
<ol start="2">
<li>便携显示屏</li>
</ol>
<p>后面，我又嫌无线的码率不稳定，组装了个便携显示屏，变成了躺着用电脑副屏……配件全部拼多多的。</p>
<ul>
<li>显示屏，京东方 NV156FHM N69</li>
<li>驱动版、按键板、软排线</li>
<li>外壳、音响</li>
</ul>
<ol start="3">
<li>新的代理协议与客户端</li>
</ol>
<p>今年对于魔法上网，非常重要的事情就是去年年底 clash-core 删库。不过也正好，促使我看看有没有人设计新的协议。</p>
<p>协议方面尝试了 hysteria2 和 naive，测试下来已经把 hysteria2 当作主力了。顺便读了下 http2 <a href="https://github.com/abbshr/rfc7540-translation-zh_cn">rfc7540</a> 和 http3 <a href="https://datatracker.ietf.org/doc/html/rfc9114">rfc 9114</a> （但现在又忘了！）</p>
<p>客户端试了 <a href="https://sing-box.sagernet.org/">singbox</a>，在 ios 上替代了 shadowrocket，性能好非常多。电脑端 GUI 是典型的后端程序配置的思维，很难用，还是用 clash-meta 系列了。</p>
<h2>单机游戏</h2>
<ol>
<li><a href="https://store.steampowered.com/app/240720/Getting_Over_It_with_Bennett_Foddy/">Getting Over it</a> (掘地求升)</li>
</ol>
<p>我的天，有生之年我居然打通了这个8年前的破游戏！</p>
<p>打通的那一瞬间，我感觉觉得自己已经可能面对任何困难无所不能了。但是山顶的聊天室早已空无一人，有一点寂寞。</p>
<p><img src="https://cdn.jsdelivr.net/gh/NamiLing/upic/picgo/202401131219995.webp" alt="Getting over it"></p>
<ol start="2">
<li><a href="https://store.steampowered.com/agecheck/app/1086940/?l=schinese">博德之门3</a></li>
</ol>
<p>tga 2023 年度游戏，不好玩。去年买了，今年和 meme 大师与墨墨联机了好几次，还是玩不下去！打架打一局太久了……而且打不好还要 SL……补药啊！（后面没法联机了其实主要是因为我作息太乱了）</p>
<ol start="3">
<li><a href="https://store.steampowered.com/app/1426210/_/?l=schinese">双人成行</a></li>
</ol>
<p>2021 年度游戏，好玩，这个还是感谢陈 sir 陪我打完了，而且因为他是全成就大师所以我也跟着全成就了。因为我竟然买了两年都没有玩，显得特别可怜……</p>
<ol start="4">
<li><a href="https://store.steampowered.com/app/2198150/Tiny_Glade/">Tiny Glade</a></li>
</ol>
<p>新出的休闲建筑游戏，最不像游戏的游戏。建筑方式新颖，而且好好看哦！</p>
<p>玩了后做了个视频，竟然被 HR 联系了……差点当诈骗私信……</p>
<p><img src="https://img-cf.sansui233.com/imgs/2025/01/202501050253199.webp" alt="Tiny Glade"></p>
<ol start="5">
<li><a href="https://www.nintendo.com/hk/switch/animal_crossing_new_horizons/">动物森友会</a></li>
</ol>
<p>到今年才打开这个几年前的游戏。建岛是好玩的，画风也可爱，但因为手游也有在刷，对于刷刷刷的都有点疲惫了。</p>
<ol start="6">
<li><a href="https://store.steampowered.com/app/976730/Halo_The_Master_Chief_Collection/">Halo</a></li>
</ol>
<p>meme 大师带飞的经典 FPS，有剧情，非常好游戏！我只用跟在后面捡各种好玩的枪就好了（不是）</p>
<ol start="7">
<li><a href="https://store.steampowered.com/app/620/Portal_2/?l=schinese&#x26;curator_clanid=31468181">传送门2</a></li>
</ol>
<p>十几年前的解谜神作，好丸！多人模式也是 meme 大师带飞的。</p>
<ol start="8">
<li><a href="https://www.bilibili.com/video/BV1hS411w7tR">Second Eden-理想箱庭物语</a></li>
</ol>
<p>这是个新的 minecraft 深度魔改整合包，基于模拟殖民地 mod。我觉得比很多整合包都要好，考虑了流程、循环、引导，有些 mod 加的解谜结构很好玩。但模拟殖民地本身有 bug，加上流程上其实也不是特别完整，只建了一小半。</p>
<ol start="9">
<li>零大陆</li>
</ol>
<p>这是个超老的 Minecraft1.8 原版 RPG 整合包。真的非常震撼能做到这个程度，流程设计、地图设计上超级完整……可惜循环有问题，卡在一个冒险模式下的银河城地下区域了。</p>
<p><img src="https://img-cf.sansui233.com/imgs/2025/01/202501050335032.webp" alt="零大陆"></p>
<ol start="10">
<li>模拟地铁</li>
</ol>
<p>休闲小游戏，也是老游戏了，极简地铁规划，最后发现还是开滴滴比较好。内容对得起价格。也因此和喜欢地铁的朋友有聊些城建游戏。</p>
<p><img src="https://img-cf.sansui233.com/imgs/2025/01/202501050330486.webp" alt="模拟地铁"></p>
<ol start="11">
<li><a href="https://store.steampowered.com/app/813230/ANIMAL_WELL/?l=schinese">动物井 (Animal Well)</a></li>
</ol>
<p>解谜 + 平台跳跃。太好玩了，这才是真正的 2024 年度游戏！！而且只 33 M，性能也超好！是像素美术但是是很现代的赛博梦幻像素美术，好看的！</p>
<p><img src="https://img-cf.sansui233.com/imgs/2025/01/202501050325838.webp" alt="Animal Well"></p>
<ol start="12">
<li><a href="https://store.steampowered.com/app/391540/Undertale/?l=schinese&#x26;curator_clanid=31318556">传说之下 (UnderTale)</a></li>
</ol>
<p>经典日式 RPG，脑洞超大角色有意思，剧情很温暖。是Meme 依据本人的游戏时长与偏好定制的 steam 礼物……非常喜欢！</p>
<p><img src="https://img-cf.sansui233.com/imgs/2025/01/202501050055049.webp" alt="UnderTale"></p>
<h2>动画&#x26;漫画</h2>
<ol>
<li><a href="https://www.bilibili.com/bangumi/media/md21087073">葬送的芙莉莲</a></li>
</ol>
<p>中世纪魔法动画，难得味这么正，不算是我非常喜欢的类型但能看下去。而且作画的流畅程度真的……太有钱了！整体比较日常，很温馨。</p>
<ol start="2">
<li><a href="https://www.bilibili.com/bangumi/media/md28339713">蓝色禁区 Blue Lock</a></li>
</ol>
<p>足球番，我原以为我不喜欢看，最后根本停不下来……动画第一季做得实在太好了，但第二季是 PPT，1 分都不想给……漫画非常棒，不愧2024 年的日本漫画销冠。</p>
<p>不过我是其实从其中一对 CP 图决定看，结果看完动画觉得这两人麦太多了……不如好好看球！</p>
<ol start="3">
<li><a href="https://www.bilibili.com/video/BV1ag4y1W78U">异形舞台 Alien Stage</a></li>
</ol>
<p>动画音乐剧，讲的外星人饲养地球人当宠物，看人们在舞台上通过选秀比赛相杀的故事。特点是，一集一个寡妇（夫）……太刀了！</p>
<h2>电影</h2>
<ol>
<li>你想活出怎样的人生</li>
</ol>
<p>宫崎骏动画电影，我觉得依旧很好看，很温暖。</p>
<ol start="2">
<li>蓦然回首（Look Back）</li>
</ol>
<p>藤本树动画电影，讲普通画画人的故事。非常牛美术风格。尽管我不是画画人，也没有很好的画画天赋。但也有一些感受有经历过，日复一日练基础，什么时候都在考虑画画……</p>
<p>以及藤本树居然开始走治愈系了！</p>
<ol start="3">
<li>志愿库 - 存亡之战</li>
</ol>
<p>怎么突然出现了国庆战争片……这个真的拍得挺好的，算是近年陈凯歌的不那么扑的了。以及我有朱一龙演技滤镜，在超烂低成本不被任何人看好的改编网剧里，因为演技太好而突然红的，真的没得说。</p>
<ol start="4">
<li>名侦探柯南 - 黑铁的鱼影</li>
</ol>
<p>和雨疏的年度固定节目，不错的粉丝向主线剧场。真好啊真好十年后还在和她一起看柯南。</p>
<h2>音乐</h2>
<p>年度歌手还是 Radwimps，基本老歌。上半年没怎么听</p>
<p>年底听 4 块钱的直播，才发现日系真是年年有天才。「晚餐歌」真的很厉害。原来不是我不喜欢听歌了，是没关注到好听的歌了，网易云日推越来越不行了，一直推各种时下 OP ED。</p>
<h2>技能相关</h2>
<ul>
<li>
<p>游戏，给 MC 服务器写了 彩虹帽子 数据包。想来这其实是第一次和游戏有关的编程，经典入口是帧更新 tick()。</p>
</li>
<li>
<p>画画，学了平面设计的课，作业也很肝完了，有一些收获。然后又看了些曼奇的网课，素描关系有提升，就是增加了短调子、空间感、体积感的意识。我之前也不是感受不到，而是没觉得差一点明度就会差很多。这是 Ti - Se 画画相比于 Se - Ti 的劣势，需要有理论后才能画得好……</p>
</li>
<li>
<p>原神里头一回赶上音游的版本，写了几首比较难的谱面，这个非常满意，是我自己都可以反复玩的！</p>
</li>
</ul>
<h2>专业相关</h2>
<p><del>这随便吧又没人看。</del></p>
<ul>
<li>
<p>笔记主题没怎么更，我也用得越来越少了</p>
</li>
<li>
<p>博客有更新，但忘了！</p>
</li>
<li>
<p>新写了个服务器的监控页。</p>
</li>
<li>
<p>论文挣扎着狂补。</p>
</li>
<li>
<p>有去接触 GPU 相关的，不想只停留在业务 MVC 再 CRUD。但看了发现没需求的话确实用不上。</p>
</li>
</ul>
<p>公司的相关还是不说了……主要是图形学和，久违的 OOP 编程，新的语言 C#，但长得非常通用面向对象，没有太多的入门门槛。不禁感叹外面世界的语言真是五花八门……但要说写界面好用还是声明式的，OOP 写界面特别过程式就，扭曲，痛苦，但无疑性能会更好。</p>]]></content>
        <category label="Diary"/>
        <published>2025-01-04T17:21:04.000Z</published>
    </entry>
</feed>