cyp0633's Blog

1013

Tue, 28 Apr 2026 17:19:45 +0800

今天得到的一些教训：

不要为了图一时便宜买新TLD。reputation差到无法想象，.icu基本也就比.xyz强点，首年后未必比.com便宜。等到用邮箱的时候就老实了，邮箱换起来也实在困难。

不要侥幸认为政府不敢在网络审查上下狠手。封锁整个.icu TLD在2026年4月28日之前就像天方夜谭一样，但它确实真的发生了。防火墙开始秀肌肉了，协议识别、SNI阻断、DNS污染轮番上阵，最悲观的情况下未来真的是全面脱钩的大内网了。

作为小TLD，全封掉的假阳性率不太高，近期内政府该不敢对整个.com动手，当然也要看GFW的算力什么时候能精准监测备案，或者说「泉州模式」什么时候会蔓延全国。但不管怎么说，在破费买了.com后，现在起码是可以访问的了。

Pixel Watch 2：最终还是只能成为大号手环吗

Wed, 22 Apr 2026 12:42:27 +0800

我其实很久以来都对智能手表没什么兴趣，一方面是不喜欢比手环再宽一圈的表体，另一方面也是实际上并没有那么大的需求。从小米手环2开始，我便一直以差不多两代一换的频率使用小米手环，中途只有一次换了红米手表，后来证明它也只是个大号手环，literally，没有GPS没有强力的健康监测，只是屏幕方了，质感还反而变差了。

购买Pixel Watch 2其实缘起于找实习时压力太大，重操旧业买点数码产品玩玩。偶然看到了仅在海外发售的小米手表2 Pro，几乎全新的产品仅售300块钱左右，便能得到骁龙W5+这一当前两三千元的主流芯片；后被朋友提醒Pixel Watch 2也差不多这个钱，又一想小米的系统维护，本身作为两年多前的产品也确实不能指望更新了，于是以不到400块钱的价格，在闲鱼某贩子处入手了一块二手Pixel Watch 2（WiFi版）。

手腕上的一颗鹅卵石

之前最担心的佩戴体验，反而在这块表上解决得很好。整块表上除了表冠几乎完全没有任何凸起，从来没有刮衣服之虞。正面由一整块曲面玻璃覆盖，一直圆润地过渡到铝合金表体，没有多余的表环等装饰。屏幕隐藏在玻璃的下方，无论亮屏与否均一体感极强，只有在十分刁钻的光照强度下才会看到玻璃下面不点亮的AMOLED屏；虽然实际上的黑边很大但却并不会被察觉到，反而拜极强的一体性所赐，不需要使用全屏AOD来遮掩黑边。41mm的直径虽然的确比手环宽了不少，但是相对来说仍然小巧，如果并不将手表作为重要的信息摄取工具的话非常合适，手腕能够自由伸展，不会阻碍活动。

手表外观

屏幕的可视度做得还算不错，在室外强光下虽无法消除反光，但亮度完全够用，文字清晰可辨；AOD模式下也提供了相对比较充裕的亮度，室外的可用性是有保证的。抬腕亮屏的算法也十分精准，无论是躺着、坐着敲键盘还是站着，基本只有表盘真正对着脸的时候才会触发，搭配抬手才会显示详细信息的通知推送策略，比无脑地收到消息直接显示的策略智能得多。

得益于高通在手表端的完全摆烂状态，骁龙W5的性能完全不成问题，毕竟开发者不得不针对它做优化（笑）。发热仅在重度使用时出现，系统动画基本流畅，加载速度也完全可以接受。

AOD虽好，然而我却并不能时时刻刻放心开，因为它的电池续航实在是有限了。在比小米手环8 NFC仅仅大60%的电池下，需要塞进更强大更复杂的传感器，更激进的健康监测策略，更大更亮的屏幕，甚至还有在更强大的芯片中运行的Android（Wear OS）系统。这造成了它一天下来常常只剩30%不到的电量¹，如果再开启GPS跑步半小时，更是会再下降10%左右。充电速度上，则基本是半小时几乎充满，一小时到100%。

谷歌全家桶来了也是毛坯房

Google是软件公司，但这不代表Google的软件质量一定高，也不代表Google的号召力能够一呼百应——Wear OS在国际上，存在感类似于Google Play之于某东方大国。应用之匮乏令人发指，Play商店里站台的大厂商寥寥无几，排行榜里仅需多翻两下就没几个大平台的客户端了，基本上就寥寥几类，运动记录（你们自己OEM没有吗）、表盘（我还是习惯自带表盘），以及车钥匙（可惜我没车）。

与应用商店的荒凉形成对比的是，系统自带了大量不可卸载的Google服务。我请问了，预装个查找中心就算了，为什么要预装卸不掉的Google Home和YouTube Music呢？塞进了这么多Google服务，怎么就没想到内置个指南针呢²？从Play商店的边边角角发现了Wear OS版的Pixel录音机，然而录音只能保存在手表上，暂时不能同步到手机上——那我录了干什么呢？

最难以理解的还是语音助手应用，这个东西是跟着Google账号走的，手表商安装的App都是同一个，如果账号之前使用过Google Assistant的话，那么手表上的语音助手就是Google Assistant；要在手表上使用Gemini，则必须在手机的Gemini App中切换数字助理，手表会自动同步。以上的信息没有在手表Gemini App和手机Pixel Watch App的任何地方提到，只在官网的文档中提了一句。

只在网站角落的文档中提到了手机的数字助理设置

国内的生态相对来说也比较灾难。高德地图根本没得用，微信手表版死活绑不上，QQ完全不支持表冠交互，看起来也没给圆表做适配，只有IT之家和支付宝等少数App的Wear OS版本比较正常。当然，在这些自行设计的App中，屏幕的黑边就变得非常明显了。还有一些人借助第三方应用商店中上架的第三方微信/QQ，但连at符号都打不出来的触摸键盘恐怕很难有什么好的体验。

如果要我挑一个最不满意的软件功能，那必然是缺少了门卡模拟，甚至不支持写空白卡，交通卡那确实不能强求了。似乎国外对这个功能的需求也不大，隔壁Ticwatch也只有国行版支持，而Google Pay支持完善的刷银行卡功能在内地没有合作银行，一根筋两头堵，相当于NFC就这么废掉了。现在它甚至完全不会与其他NFC设备产生交互，手痒充了3美元的Clipper后也没有任何反应。

另外还有些小细节，比如手机和手表的勿扰和睡眠模式同步，这个可能在Pixel手机上能做到，但国行Android手机上能连Pixel Watch就不容易了，就不强求这些魔改系统实现功能了。

Fitbit之魂

不是所有智能穿戴品牌都具有健康监测的历史积累的，Google也没有，但它有钱，把Fitbit买下来了。与小米手环8 NFC相比，准确度体感上的确有了一定的提升，尤其是睡眠检测，躺着玩手机不会再计入睡眠了。虽然并没有条件去核实准确性，但计算出的各种指标确实很能给人情绪价值，让人觉得很厉害的样子。

GPS的准确度不错，虽然相比手机来说搜星速度仍然有巨大差距，但在室外开始跑步后基本不需要等待了。

Fitbit App具有新旧两款界面可选。旧版的界面很有意思，所有的健康指标全部集中在“今天”页面上，而当希望查看记录下来的锻炼的时候，打开“教练”页面却发现全都是Premium专有的卖课内容；运动记录需要从“今天”找到“心肺负荷”，才有当日的锻炼记录列表。对于非Premium的我来说，其他两个tab基本相当于废掉了。

Fitbit App的旧界面

新界面就好得多，分为“今天”“健身”“睡眠”“健康”四个tab，卖课内容非常收敛，不再占据显要位置，每个tab都是某个方面的数据速览，相对来说更加高效。但似乎新版界面也带来了新的数据统计流程，心肺负荷目标变为了以周计，而且一周的负荷目标似乎也和之前的日负荷之和不太一样。

Fitbit App的新界面

手表究竟是个什么角色？

作为一个长期的手环用户，腕上的设备对我来说一直几乎只是一个健康记录工具，甚至激进地来说，我都不需要它带屏幕。在戴了20天全智能手表后，我的观点依然没有改变：我得到了更大的屏幕、更好的健康检测，但却失去了两天一充、最长能坚持七天的续航；得到了更自由的软件生态，但却失去了软件接口并未开放的门卡模拟功能。

如果有了eSIM，会解锁更多的可能性吗？有可能但不多，我还是更希望手腕上的设备能尽量不要太大，尺寸限制住之后屏幕就没有什么可发挥的空间了。穿戴设备上的应用再多，信息交互的效率却仍然比不上更大屏幕的手机，也不能完整地覆盖应用场景——除非是远离电子设备放空自己，那话又说回来了，我不带手机该如何刷门卡呢？

Pixel Watch 2给了我许多的新体验，作为全智能手表来说也超出了我对这个价位的期望，但也许下一次，我会选择一个国行大号手环。

已使用ADB做电量估算，软件电池健康度接近100%，但考虑到已生产3年，电池的实际容量可能已经衰减了不少。 ↩︎
疑似陀螺仪的精度有点太差了，所有第三方指南针App均有着严重的误差，校准起来并不容易。 ↩︎

不用买网关，ESP32蓝牙代理解决Home Assistant BLE问题

Tue, 03 Mar 2026 22:17:05 +0800

相比几年前，Home Assistant的生态真是有了长足的进步。价格合适的小米蓝牙温湿度计2，现在不需要刷写第三方固件，也不需要抛弃米家App，便可以连接Home Assistant了。通过Xiaomi BLE插件，Home Assistant可以直接读取小米账户中的蓝牙key（或手动输入key），并解密蓝牙Beacon数据。然而，鉴于这次运行Home Assistant的电脑也不再是之前那台，设备的问题变成了网卡的问题。之前使用的MT7925相对比较稳定，而现在的AX200则经常无法收到BLE广播，导致Home Assistant获取到的数据时断时续，最严重的时候一天加起来也就收集几个小时。偶然ChatGPT告诉我，可以使用ESP32作为蓝牙代理，信号好很多。事实证明的确，而且没有嵌入式开发经验的人也能轻松上手。

购买

我购买的是ESP32-WROOM-32E开发板，二三十块钱，不用焊引脚，因为不需要任何扩展性。需要更强信号的可以试试能够外置天线的-32UE，但我使用的-32E对于一个人住的环境已经非常足够。

为了方便刷写，板子当然还需要搭载串口转USB模块，也就是带个USB口。

刷写

把板子接上电脑，这个时候有两种选择。对于像我一样只需要靠它扩展蓝牙范围的用户来说，可以直接用Chromium内核的浏览器打开这个网站，确保上面选中的是Bluetooth proxy，选择generic ESP32，然后点击下面的Connect。你将会看到一个类似这样但又有所不同的界面：

刷写菜单

上面会有一个Flash选项，这时直接点击它就可以自动刷写含有蓝牙代理功能的固件了。之后它会提示你连接到你的2.4GHz Wi-Fi网络。

如果遇到问题也不要慌，当出现类似improv wifi serial not detected之类的错误时，点击菜单中的Logs & Console查看日志，或点击Reset Device让它重启一下。日志会表明重启进程，之后就可以继续配置Wi-Fi了。

上面没提到的另一种选择是使用ESPHome Dashboard，但由于当前受支持的Docker部署HA方式不再支持Add-on，HACS也没有上架，后续还要改配置文件，略麻烦一些，所以这里就不赘述了。只是要注意一点，刷写空ESPHome固件后也可以添加到Home Assistant中，但是它默认没有任何实体，需要在ESPHome Dashboard中（而非Home Assistant中）修改YAML配置文件。

配置

配置更简单，打开Home Assistant，进入设置-设备与服务，这时很大概率会出现发现到你的ESPHome板子，直接添加即可；如果没有发现，再点击右下角的加号，选择ESPHome，输入你的ESP32的IP地址，点击提交即可。获取IP地址有多种方法，最暴力的方法是直接扫一遍局域网，找到它的MAC。

添加完成后，它会像本机的蓝牙一样出现在Home Assistant的蓝牙设置中，和机器自带的网卡享有同等待遇，包括那个酷炫的可视化界面——现在内置网卡和ESP32都可以连接附近的BLE设备了。

蓝牙设备列表

1012

Wed, 25 Feb 2026 09:39:17 +0800

之前只是觉得OpenClaw闭眼开车容易把系统都炸掉，目前看来还是我多虑了，在装上的那一刻系统就已经沾上屎了。从agent逻辑到前端再到文档像是一个完全没有软件工程经验的人vibe出来的屎山，痛苦从安装便会开始。文档看似很全面，又有一键安装又有Docker/Podman的，但实际上Podman安装后连 openclaw CLI都没有，逼着人去翻AI写的其他文档。Quadlet文件更是正斜杠和反斜杠乱飞，根本解析不出来文件。至于一键安装脚本，没有人告诉你它做了什么，也没有任何的断点续装。LLM API key写在自己家目录中，没有任何强制的权限控制，利好安装脚本一把梭……的攻击者。卸载脚本卸不干净，上述的API key和配置文件都不会删除。context management也是很迷，用户的input token仿佛不要钱一样用，一股脑把工具全都加载进去，每次几十上百K token的烧，不管是速度还是花费都是灾难级别的。

在一般的开源项目中，即使做成这样也是有救的，至少看着不顺眼可以提PR，然后由collaborator review后合入。OpenClaw看起来仍然是这一套流程，但考虑到其问题奇多，很容易找到切入点，且已有近4000个open issue和4000个open PR，又大概率不存在熟悉其代码的人类，大概率是AI发PR，AI review，AI合并……的流程。所以从某种意义上来说，既然原作者选择了直接撒手，那么OpenClaw大概也可以算是最活跃的LLM驱动的开源项目了。

如果有人想看看不受人控制的vibe coding到底是个什么样子，那就装个OpenClaw吧，品尝一下屎山之美。至于未来是什么claw，那是未来的事了。

终端Agent是更趁手的通用Agent

Mon, 02 Feb 2026 21:40:54 +0800

体验了许多的AI工具，我觉得最趁手的还是OpenCode之类的终端agent。决定终端agent优势的因素，我分三个部分：基于本地、终端形态，以及human in the loop。

为什么是本地agent？

当LLM能够通过工具调用和外界打配合的时候，就已经意味着它的能力已经超越了单纯的聊天解闷，或是解决一些逻辑问题。无论是调用Python增强自己的计算精度，还是调用网络搜索获取最新的结果，甚至调用生图工具另请高明生成一张图片，这项能力似乎在至少9个月前就已经在ChatGPT中落地了。然后就是轰轰烈烈的大agent时代，先是Cursor和Claude Code等coding agent使劲从 ~~程序员~~ vibe coder钱包里榨钱，以及MCP赋予了自定义工具的能力，之后中间省略直到最近千问整合接入了阿里的各种产品，大模型的能力边界也确确实实地随着工具的丰富而不断地扩展。

模型决定了agent分析问题的准确性、调用工具的技巧，工具（或者MCP/Skills）决定了agent可以做到的事情，而agent本身运行的平台，则决定了其在不额外添加工具的情况下能办到什么。回想我体验过agent，在第三个方面都有一些特征：

ChatGPT普通模式，不清楚是怎么做的，不过可以调用Python，只能用一些已有的包。可以读取用户上传的文件，另有多种App（可能是类似skill的东西），可以连接云盘。
ChatGPT agent模式，在OpenAI的服务器上起一个类似Debian的容器，天然沙盒化。在上述功能外支持了接近完整的Linux能力。
千问App¹，全都做成了单独的模式，单独的deep research，单独的代码执行，而用阿里旗下的点外卖、找路线，嘿，又是一个单独的模式。
Cursor/Copilot/Cline等AI IDE（插件），在IDE中运行，以代码为中心，改代码甚至写论文都非常方便。
Codex和OpenCode等终端编码agent，通常依托终端界面，以及本地文件系统和程序工具。
Claude for Desktop和Codex App，像是Claude Code套了个壳子，不过拥有更友好的GUI界面。

当agent在本地电脑上运行的时候，它更能够像人类一样使用电脑，而不是被局限在某个App或某个平台里。利用现有的环境也可以节省很多重复性的安装依赖等工作，并使用当前人类熟悉的配置文件。更重要的是，本地agent具有本地文件系统的优势，除了代码仓库，也可以十分方便地浏览工作资料等文件，甚至操纵本地运行的客户端程序。相反，在云端运行的agent仿佛带有一种隔阂，不依赖本地的状态则不像是在“为用户”处理工作。，

的确，本地的文件太过繁杂，而现在仍然需要明确告诉agent哪里有文件，它才能自觉去引用、去综合、去整理，而不能自动地附带上下文。而我要说，基于云、连接网盘的方案有一样的问题，且难以推动云存储商实现便捷的文件查找接口（即使强如OneDrive搜索功能，也未必能给ChatGPT相似级别的权限）；而对于本地，大规模RAG是一个理论上可解且工程上可行的问题，但目前确实有一些文件检索路线上的争论。

本地终端的另一个优势在于，通过利用本地的命令行工具链，它能够很好地遵守Unix哲学，通过shell管道和文件系统组合各种小工具，以达到极高的自由度。丰富的训练数据令LLM天生熟练使用shell，而无需花费额外context介绍工具调用或者MCP的spec。这是云端agent难以办到的，而即使是提供一个容器的ChatGPT agent模式，也更难包含所有任务需要的工具。

至于chatbot提供的工具，Codex App和Claude App也能够添加其他MCP/工具，体验也已经基本是对齐的。

为什么是终端？

我们暂且认为本地相对更有优势，好，那么为什么是终端，而不是IDE或者GUI的形式？有主观原因也有客观原因。

其一是大多的AI IDE均基于VS Code，其性能虽然在IDE中算是较为优秀，但打开项目后仍然常有数百至数千MB的开销。这在编码任务中非常方便，因为能随时审查agent对代码的修改；但在常常涉及二进制文件的其他通用任务中，则显得相对累赘。正如朱亦博老师在Step 3.5 Flash博客中提到的，许多人并不会紧盯着执行过程中的过程，写了什么样的Python脚本，而是希望专注于运行结果，而结果很可能并不由代码呈现。

倒不是说终端agent都多轻多快，当然OpenCode和Claude Code等工具由于实现问题，占用内存也很大，所以这里重的感觉也未必客观，或者更多的是一种跟手感。

Claude for Desktop等桌面agent很好，有很强的computer use能力，在代替人解放繁杂工作这一方面，Anthropic算是起步比较早，整得也比较明白的。也有一个比较全面的marketplace，提供了接入各种第三方平台的工具。对于买了Claude订阅的普通人来说，它是一个比较理想的通用agent形态。

大部分GUI形式agent也有自己的问题，就是在远程主机上用起来十分不方便。且不提三大系统唯独缺了一个Linux版本，不管是连接Windows本地的WSL，还是远程Linux服务器，都不能指定agent的实际运行环境。Windows上的PowerShell还是不要谈Unix哲学了，毕竟它连Unix都不是。相比于标准稀碎、网络要求高的远程桌面，SSH（或类SSH）作为既成标准，连接起来一般不会出什么差错，且由于传输的数据量不太大，在处理一些主要依赖远程机器的任务时，效率也更高。当然这并不是一个常见的需求，更多的还是我的个人喜好，如果Claude for Desktop糊一层客户端与服务端通信的协议，或许也会解决这个问题。

为什么不是OpenClaw？

OpenClaw很好，好在它打通了自主行动的链条，比被动的一问一答、等待指令更加灵活；但它坏就坏在过于灵活，对于人类完全是黑盒，几乎完全不可控也不受监管，也没有内置沙盒机制（当然用户应该有这样的自觉），甚至还有Moltbook这样的注入攻击温床。如果说使用Antigravity删除家目录这种事可以通过停止agent运行或者加入命令黑白名单来解决，那么对于并不会全程暴露执行过程的OpenClaw来说，则无异于蒙着眼睛凭感觉开车，一般来说能到达终点，而翻下悬崖也没什么意外。

经过几年的发展，coding agent已经有了很多防止把代码库改炸掉的方案，比如建立多个worktree分别编辑，比如利用git的功能来暂存修改，比如使用bubblewrap把agent装进沙盒，等等等等。然而，显然OpenClaw一个都没做到，顶多也就是个MVP（2026年2月）。Docker并不能解决所有问题，agent的权限范围越大，其能力也就越强，辛辛苦苦写了一大串ACL，到头来总会遇到因权限而无法完成的任务。还不如使用声明式的方案，所有的更改以文件形式暂存，用户审核后再应用到系统中——文件而非命令的配置，某种程度上又是一种Unix哲学。或者甚至直接给整个硬盘打快照，起码给了用户救回来的机会。

毫无疑问这种高度自主化的agent将会是未来的发展方向，但在它彻底融入日常生活，放心地把任务交给它之前，起码还是先加一些安全措施吧。起码现在，我宁愿盯着OpenCode的执行过程，并随时准备停止、接管或者完善任务。

为什么老是提千问？只是因为我没用过豆包，元宝只用来抢红包。 ↩︎

1011

Mon, 26 Jan 2026 14:23:22 +0800

发现了一种远程VS Code走代理的办法，因为其不依赖特定的Shell，所以可以解决各种VS Code Server下载不下来、Cursor无法使用高级模型之类的问题，同时也兼顾其他终端工具（如OpenCode）。

现有的方法大多基于修改Shell配置文件，但VS Code启动时不一定会先加载特定Shell；另外一些方法是修改VS Code的启动配置，但这种方法只能解决VS Code本身的问题；还可以在本地设置环境变量，然后用 SendEnv 传递给远程，但这种方法需要污染本地的环境变量，或在ssh以外包一层，前者不够优雅，后者兼容性不行。

如果两端都使用比较新的OpenSSH，那么可以使用 SetEnv。其在连接远端的时候先于Shell传递环境变量，从而所有通过SSH运行的命令都可以读取。

在远端的 ~/.ssh/sshd_config 中添加：

AcceptEnv HTTP_PROXY HTTPS_PROXY ALL_PROXY NO_PROXY

而在本地的 ~/.ssh/config 中，根据远端能访问到的代理服务器（如运行的v2rayN、Clash Meta等）填写代理地址（不需要双引号）：

Host ******-pc-proxied
    User cyp0633
    HostName ******-pc
    SetEnv HTTP_PROXY=http://127.0.0.1:10808 HTTPS_PROXY=http://127.0.0.1:10808 ALL_PROXY=http://127.0.0.1:10808 http_proxy=http://127.0.0.1:10808 https_proxy=http://127.0.0.1:10808 all_proxy=http://127.0.0.1:10808

然后连接这个 -proxied，就可以让远端的VS Code Server、Cursor等工具走代理了。

目前看起来没有任何LLM直接推荐这种办法，所以我暂且认为记录下来有一定意义。

1010

Sat, 17 Jan 2026 23:18:33 +0800

又多亏了vibe coding，给博客加了两个小功能。一个其实算是个大工程，去掉了所有中英文之间手打的空格（但习惯一时半会改不回来）。现代浏览器有了 text-autospace 这个CSS属性，就可以在CJK和拉丁文字之间自动添加一小段空格，看起来非常美观，也不会污染原本内容。下面的例子来自 MDN（MIT许可证），可以自己对比一下效果。

你的浏览器不支持 text-autospace。


          text-autospace: no-autospace;

HTML超文本标记语言

42四十二

另一个是加了浏览器的HDR感知和开关切换。部分图片是没有gainmap的原生HDR格式，对于Firefox等浏览器会有严重的颜色映射问题；而对于Chromium，不管屏幕和系统是否支持HDR，都具有较好的色彩映射。研究了很久也没有研究出来如何在保持观感的情况下转换成gainmap，索性一刀切，只要屏幕、系统、浏览器任何一个链条不支持HDR，则强制加载SDR图片；反之则提供一个开关，允许用户在SDR和HDR之间切换。我在《无限试驾：太阳王冠》那篇文章中加入了一些HDR图片，有条件的读者可以试一试，后续我也打算传一些自己拍的图片，HDR真的让图片鲜活了很多。

《无限试驾：太阳王冠》：小作坊别出来骗钱

Sat, 17 Jan 2026 11:20:48 +0800

相信《无限试驾》系列应该是许多RAC爱好者的白月光，可惜我入坑太晚，之前一部都没有玩过。如今赶上了许久之后的系列新作《太阳王冠》，其发售后经历了早已经看腻了的风评反转环节。本来36%好评率的游戏打折到55块钱我也不会看一眼，但是正好碰上了免费周末，本着不吃白不吃的心态，腾出了100G的空间安放这个游戏。从游戏数据来看，似乎同时有最高700名和我一样爱赤石体验不同RAC的玩家被免费周末吸引而来。

为了防止缺点太震撼，先说说做得不差的地方吧。首先，有手柄扳机振动。左扳机刹车会模拟降档时发动机的振动，而手柄振动通常模拟升档、路面和碰撞，不算顶级但也不错。车辆的驾驶手感也相对容易上手，轮胎死死地抓住地面，轮胎叫声再尖锐都能把车身姿态救回来，是比较能给休闲玩家正反馈的类型。

另外一个可能是TDU系列传统，就是对车辆细节的把控。买车时除了车漆还可以定制内饰、轮毂、刹车卡钳等细节，甚至驾驶时专门留出了一个圆盘菜单，用于操控车灯（包括双闪）和雨刷等功能。虽然定制车漆甚至轮毂都算是烂大街的功能，但TDUSC的真实程度更上一层（~~非默认选项要加钱~~）。许多（如果不是每辆）车都有听起来单独录制的引擎声音和喇叭声音，敞篷车能够开关顶棚，也有完整的开关窗户动画。车内视角建模不是太精细但胜在全面，仪表盘还原很不错，Mustang的仪表盘甚至有中文。对于宝马i8和保时捷918 Spyder这种混动车，甚至有一个单独的电量HUD仪表盘，松开油门使用动力回收充电，有电时则同时使用电机驱动。美中不足的是车单似乎比较小，四个德国车品牌拆进两个车商，美国车商只有福特，要不还是改名叫福特4S店吧。

定制能力

好了那么接下来就是震撼赤石环节，首先是性能问题。要不是最近还在玩EA Sports WRC，连遇到两个超烂优化RAC（另一个是老前辈《赛车计划3》），我还以为4060Ti才过两年多已经被RAC抛弃了呢。在中预设、4K分辨率下、DLSS性能档（渲染分辨率1080p），帧率能上30就谢天谢地了，更多的情况只有20出头，10出头也不少见，此时的显存占用已经超过了7 GB。即使有了帧生成神力，也仅仅能将帧率推向40出头，而此时由于未知原因造成的开不了垂直同步，画面撕裂又成了常态。最神奇的是UI分辨率并没有保持在4K，文字边缘都是毛边，那我开DLSS为了啥呢，为啥不直接降到1080？更何况很可能由于爆显存的原因，游戏内帧率常常降到5 FPS，此时必须将纹理质量再次降低到低，才可得到一个正常游玩的帧率。很神奇吧，这是黑猴以外头一个DLSS性能档都会爆显存的游戏了，即使去掉爆显存问题也跑不到60 FPS。

对香港的还原也堪称外交事故级。首先一个正常的人从太平山顶往下看，应该能看到灯火通明的中环，或者起码标志性的中银大厦。然而在游戏中，只能看到一片漆黑，偶尔能看到一些零星的灯光，不知道的还真以为小渔村了。我尝试过调整游戏中的“视距”选项，但并没有任何帮助，维港的夜晚总是静悄悄。

未曾设想之中环

至于像巴士站的细节，只能说有但是不多，更像是开发商随便Google了“Hong Kong bus stop”，把图扒下来去掉logo，然后贴到了所有的站牌上；电车则更加简单粗暴，是纯原版。我们先不追究为什么站牌直插在沥青路上，难道用这种素材真的没有版权问题么。

巴士站

对应的巴士路线图

除此之外，红色的士也没拿到丰田的授权，香港应该也没有这么宽的路。当然从上手难度和设计难度上来说，建一些宽的路确实有一定必要性。路边的商店倒是让我想起了《战地4》，有“甘宁斯 gannings”（如图）和“范森斯 Vansons”，不由得想起来《战地4》里的啃得起。另外TDUSC里也有完整的普通话配音，但非常棒读，什么粤语在哪儿？哈哈，香港为背景的游戏，配音没粤语。

游戏街景

作为以肾上腺素为第一要务的arcade RAC，《极品飞车》的地图设计常常“缝合”多种地形，以满足不同的玩法；而更加“养老”的《极限竞速：地平线》取材真实的爱丁堡，其地图制作相对精良，即使不参加比赛，也可以遨游于城市的每个角落，看看风景，拍拍照（《飙酷车神》中也是类似）；而TDUSC中的香港则并不是很香港，地标也不地标，街道也不街道，造景也不造景，中环风貌也与实景所见相去甚远，有时候现代化的写字楼旁就是拥挤的唐楼，感觉像是素材库限时免费了，地图设计者先导入香港路网图，然后索性胡乱摆一下，找几个中文字贴上去完事，然后便可以宣称1:1比例完全复刻香港岛。这的确是赛车游戏史上第一次出现香港岛，但如果由它来代表香港的话也太可惜了。

作为全程联网的游戏，老实说其网络表现超出了我的预期，也可能是因为900多并发算不了什么。在几个小时的游玩过程中，没有任何的断连情况发生。然而，通过对其他车辆的观察，我猜想即使是街车也是由服务器控制的；顶着900 ms的延迟，服务器下发的NPC车辆位置也会有明显的跳跃，或是突然出现、突然消失。于是，驾车漫游在街头的时候，会发现有些车突然往前往后瞬移，两辆车撞在一起，或是离地几十厘米，甚至会把停在路边的无辜玩家车辆顶飞。考虑到这游戏的物理也比较神奇，我认为其令人讨厌的程度不亚于《极品飞车》中十分随机出现的街车。

网络上诟病比较多的赛事AI我反倒感觉还好，可能是AI加成开得比较低没有侵略性。但赛事这一块也确实没什么新意，机器语音抛过来个任务接就是了，可能它想做的是类似入门教程的简短剧情，但剩下的内容主要靠长线运营来填，但就平常只有200多人在线的情况来看，似乎也没填上性能和地图问题的坑。也难怪，一年半了还有这么严重的问题，能吸引到首发时的5000多玩家会坑才是怪事。

总之多亏了Nacon和KT Racing的免费试玩机会，我不必浪费钱买这部作品，不过Nacon给我赔偿精神损失费也是可以的。除了被毁掉的TDU之外，也替WRC粉丝感到可惜，毕竟如果EA继续买授权，WRC版权也就不会落到KT Racing手里了。

《赛车计划 3》：早该下架的史级烂作

Fri, 12 Dec 2025 21:09:36 +0800

出于对年度诈骗赛车大作Project Motor Racing和Ian Bell的好奇，玩了一下《赛车计划3》这部史诗史级赛车巨作。玩了没几分钟我脑袋里就只剩两个想法：一个是庆幸，玩这么多年赛车游戏只品鉴过Ian手下的一款游戏（即《极品飞车：变速》）；一个是疑惑，Codemasters到底是怎么看上Slightly Mad Studios的？

一上来就让我没绷住，我一般同时使用笔记本内屏和外接显示器，上下叠放，没想到画面自动被扩展到了两块屏上，每次进游戏必须先切换仅外接屏幕，然后再切回扩展模式，谁懂两块屏幕分别出现半个万代南梦宫logo的救赎感。

并非三联屏

作为赛车游戏来说跑起来之后不会太关注画面，然而这游戏不一样，它太卡了，4K高画质只有20~30 FPS，CPU和GPU全吃满。这么高的硬件需求一定效果秒杀晚辈吧，并不，建模塑料感，光影廉价感，赛道锯齿感，就连UI文字也不清晰，我都觉得是1080p上采样来的。

太顶级了这画质

作为拟真赛车，操控难度比开拉力还高；作为休闲街机，玩法又比不上那几个老资格系列；作为simcade，也不能像《极限竞速》一样给人情绪价值。说到操控，这游戏碰撞成本极高，擦边就像被黏住了一样，而给得比较严格的赛道边界更是使其雪上加霜。一spin起来就发狠了忘情了，车有自己的想法了，再也管不着它了。

好在这东西已经在半年以前下架了，更好的消息是Project Motor Racing已经收获了“多半差评”。

1009

Wed, 03 Dec 2025 23:38:46 +0800

说云端的豆包手机 Agent 会被注入、有隐私上传问题也好，说微信支付掌管着用户的钱袋子也罢，确实，一个关键的金融 App，理应得到更严格的安全保障。

但是有没有可能，微信能支付、能订餐、能凭借一个 App 触及用户的海量隐私，本来就是不合理的事情？毕竟“自动记账”们确实与微信的安全性有关，通用 Agent 却可能只是看个文章，总结一下而已。

有没有可能，让支付部分和其他非敏感部分具有相同的风控水平，更是一种项庄舞剑，意在沛公的行为？毕竟公众号、小程序也都是微信重要的活力所在，让张小龙限制机器操作非敏感内容的，我不好说，可能是广告收入。

总之观点还是一贯的，超级 App 就不应该存在。

Cumulus Linux 5.1 & NVUE 使用笔记

Wed, 12 Nov 2025 22:55:22 +0800

~~怎么前一段时间搞软路由，这次搞起大号硬路由了（并非）~~

Cumulus Linux是NVIDIA给交换机做的Linux系统，基于Debian。NVIDIA把交换机ASIC的配置抽象出来以Linux配置的方式呈现，实际用下来使用相对熟悉的逻辑还是更方便一些。

虽然是基于Debian的，但NV似乎并没有完全承诺兼容，况且交换机上那颗双核X86 CPU恐怕连星露谷都带不起来，还是别整花活了。不同的Cumulus Linux版本自带的软件包也不同，操作逻辑等有着显著的差距。NV网站上有适用于各个版本的文档，当确定不下来的时候，与其找一个不知哪来的野文档 ~~（包括这篇）~~ 或是版本号对不上，不妨问问ChatGPT，让它开联网搜一搜。

从5.0版本开始，Cumulus Linux引入了NVUE（NVIDIA Unified Extensible）配置框架（也就是 nv 命令这一套），用来取代NCLU（即 net 命令）。在包括5.1在内的多个版本中，NCLU的后端也是NVUE，而在更新的一些版本中，则干脆没有了NCLU。无论如何什么时候，都应该尽量避免直接编辑 /etc/network/interfaces，更不应该使用systemd-networkd、netplan或者NetworkManager之类的工具，尽量将NVUE作为single source of truth。

用户管理

https://docs.nvidia.com/networking-ethernet-software/cumulus-linux-51/System-Configuration/Authentication-Authorization-and-Accounting/User-Accounts/

默认用户名是 cumulus，但和其他许多Linux一样，可以通过 adduser 工具添加用户，正常地设置密码，正常地配置SSH public key。

与简单的判断sudoer不同，NVUE有着自己的更细粒度的用户组权限控制。三个不同等级的用户组分别为：

nvshow，只能查看配置（如 nv show config），不能修改
nvset，可以执行 set 或 unset 命令，但不能实际提交（即真正生效）
nvapply，不仅可以编辑staging的配置，还可以提交生效

声明式配置管理

https://docs.nvidia.com/networking-ethernet-software/nvue-reference/Config-Commands/

NVUE进行系统配置的方法是声明式的。有些读者可能会立即想到Nix，事实上它们确实很相似：系统的状态由配置文件描述，更改系统的配置本质上就是更新配置文件，然后触发系统的重配置。的确，Linux系统的网络配置仍然由命令式的 ifupdown 等工具处理，NVUE只是将配置文件抽象为NVUE的配置模型，然后替我们生成底层的配置文件，或是调用对应的命令。只需查看 nvued.service 的日志就能发现这一点。

声明式配置的一个好处是，可以用一个文件直接描述系统的配置状态。只需要 nv config show 命令，就可以看到当前交换机的所有配置信息，就像这样：

yaml

- set:
    bridge:
      domain:
        tor_bridge:
          type: vlan-aware
          stp:
            state:
              up: {}
          vlan:
            '102': {}

    qos:
      roce:
        enable: on
        mode: lossless

    system:
      config:
        snippet:
          ifupdown2_eni:
            swp1: |
              post-up   ip neigh replace 10.0.255.2 lladdr 90:0a:84:xx:xx:xx dev swp1 nud permanent
              pre-down  ip neigh del     10.0.255.2 dev swp1              

    vrf:
      tora:
        table: auto
        router:
          static:
            192.168.106.0/24:
              address-family: ipv4-unicast
              via:
                10.0.255.2:
                  type: ipv4-address

    interface:
      eth0:
        type: eth
        ip:
          address:
            10.0.25.1/16: {}

      swp1:
        type: swp
        ip:
          address:
            10.0.255.1/24: {}
          vrf: tora

      tor_bridge:
        type: bridge

      vlan102:
        base-interface: tor_bridge
        type: svi
        vlan: 102
        ip:
          address:
            192.168.102.1/24: {}

这个片段展示了一个简单的交换机配置，包括VLAN、VRF、QoS以及接口配置等。可以看到，配置是以层次化的YAML格式呈现的，非常直观。值得注意的是里面有以命令形式存在的snippet，虽然的确是命令式配置，但也是NVUE不支持配置情况下的无奈之举（5.1.0还不支持固定neighbor）。

用文件描述配置的另一个好处在于，版本控制非常方便。事实上NVUE也是这么做的：它真的用Git来管理历史，不信可以试试 nv config history 命令，应用的配置相当于被commit了。同样还有来自Git的staging概念，熟悉Git的读者应该很容易上手这几个选项：

nv config apply：将暂存中的配置生效
nv config detach：放弃暂存的配置，从当前应用的配置开始做修改

对暂存的配置作出修改，有三种方式：其一是直接使用 nv set 和 nv unset 命令，其二是用新的配置文件替换当前的配置，其三则是将新的配置文件合并到当前的配置中。第一种方式相对更接近先前的命令式配置习惯，至于后两种方式，则使用下面的例子来说明。

假设当前 nv show config 输出如下：

yaml

- set:
    interface:
      eth0:
        type: eth
        ip:
          address:
            10.0.25.1/16: {}

有一个新的配置文件 new.yaml，内容如下：

yaml

- set:
      swp1:
        type: swp
        ip:
          address:
            10.0.255.1/24: {}

如果使用 nv config replace new.yaml 进行替换，那非常不巧，你的 eth0 配置就丢了，下一步大概就是去找串口线改配置了。而如果使用 nv config merge new.yaml，那就会把 swp1 的配置加进去，eth0 依然保留。

当你终于下定决心，要试试新调整的配置会不会把交换机搞崩的时候，可以使用 nv config apply 把配置提交生效。好消息是NVIDIA早就考虑到了配置错了SSH都连不上的问题，所以可以加一个 --confirm 选项，在10分钟内没有手动确认的话，配置会自动回滚，即使刚刚误用了 replace，也只是断10分钟而已。

排除连接问题

https://docs.nvidia.com/networking-ethernet-software/cumulus-linux-51/Monitoring-and-Troubleshooting/Troubleshooting-Network-Interfaces/Troubleshoot-Layer-1/

有时候因为各种原因某个口死活up不起来，Cumulus Linux提供了一个方便的工具：l1-show。

shell

cyp0633@cumulus:mgmt:~$ sudo l1-show 1-3
Port:  swp1
  Module Info
      Vendor Name: FINISAR CORP.          PN: FTLC1154RDNL-FH
      Identifier: 0x11 (QSFP28)           Type: 100g-lr4
  Configured State
      Admin: Admin Up     Speed: 100G     MTU: 9216
      Autoneg: Off                        FEC: Auto
  Operational State
      Link Status: Kernel: Up             Hardware: Up
      Speed: Kernel: 100G                 Hardware: 100G
      Autoneg: Off                        FEC: RS
      TX Power (mW): [1.8559, 1.839, 1.7584, 1.783]
      RX Power (mW): [0.878, 1.0508, 0.9174, 0.9853]
      Topo File Neighbor: None, None
      LLDP Neighbor:      cumulus, swp3
  Port Hardware State:
      Compliance Code: 100GBASE-LR4 or 25GBASE-LR
      Cable Type: Optical Module (separated)
      Speed: 100G                         Autodetect: FORCE - 100G
      Eyes: 385, 365, 419, 366            Grade: 31012, 21952, 31012, 25147
      Troubleshooting Info: No issue was observed.

当某个接口起不来的时候，不妨直接看 l1-show 的输出，在Troubleshooting Info一栏中，基本上有什么问题一目了然。

屏蔽了一些爬虫

Sun, 07 Sep 2025 10:57:46 +0800

本来读了研也确实没有本科那么强的折腾精神了，服务器除了续费和升级软件也没怎么动过。按理说这么小的网站Googlebot都基本不访问才对，但偶然检查一下还是发现了一些异样。以下分享三则最近发现的乱爬案例。

阿里云阴兵过境

第一关是不明新加坡阿里云爬虫。

位于香港的服务器上一直运行着一个Gitea做自己GitHub的镜像，由于某些原因没有挂Cloudflare，我那点垃圾代码按理说也没人看吧。诶恰恰相反，其实早在很久之前就有相当数量的爬虫在爬，只是比较节制，不会爬个没完。直到前段时间登上腾讯云，发现一个月竟然差不多用完了1TB的流量，并非互联网上一个偏远角落的正常访问量。以7天为尺度观察统计图表，好家伙直接把我CPU全跑满了呀。

腾讯云的统计

不过话说回来幸亏是CPU-bound的Gitea，CPU打满了，30M的带宽还没打满，不然下场估计是先被腾讯断网，现在跑得慢但起码还能访问。导出Gitea的日志一看（共49万行），大部分是我本科边抄边写的操作系统实验，算是别人的代码，不是垃圾代码：

log

Aug 05 08:57:04 VM-8-17-ubuntu gitea[4160705]: 2025/08/05 08:57:04 ...eb/routing/logger.go:102:func1() [I] router: completed GET /cyp0633/ucore-lab/rss/commit/5204cd45e8a0f09f7a27ddad803bf28d56474dba/labcodes_answer/lab3_result/tools/sign.c for 47.79.214.90:0, 404 Not Found in 0.2ms @ <autogenerated>:1(WebNotFound)
Aug 05 08:57:04 VM-8-17-ubuntu gitea[4160705]: 2025/08/05 08:57:04 ...eb/routing/logger.go:102:func1() [I] router: completed GET /cyp0633/ucore-lab/commits/commit/5204cd45e8a0f09f7a27ddad803bf28d56474dba/labcodes_answer/lab3_result/tools/kernel.ld for 47.79.199.163:0, 200 OK in 365.3ms @ repo/commit.go:44(repo.RefCommits)
Aug 05 08:57:04 VM-8-17-ubuntu gitea[4160705]: 2025/08/05 08:57:04 ...eb/routing/logger.go:102:func1() [I] router: completed GET /cyp0633/ucore-lab/src/commit/a29ae0982ac021cc2abeb75004af69b1b0d29f53/labcodes_answer/lab8_result/libs/printfmt.c for 47.79.215.248:0, 200 OK in 518.0ms @ repo/view_home.go:332(repo.Home)
Aug 05 08:57:04 VM-8-17-ubuntu gitea[4160705]: 2025/08/05 08:57:04 ...eb/routing/logger.go:102:func1() [I] router: completed GET /cyp0633/ucore-lab/src/commit/a29ae0982ac021cc2abeb75004af69b1b0d29f53/labcodes_answer/lab1_result/tools/lab1init for 47.79.197.254:0, 200 OK in 481.5ms @ repo/view_home.go:332(repo.Home)
Aug 05 08:57:04 VM-8-17-ubuntu gitea[4160705]: 2025/08/05 08:57:04 ...eb/routing/logger.go:102:func1() [I] router: completed GET /cyp0633/ucore-lab/rss/commit/5204cd45e8a0f09f7a27ddad803bf28d56474dba/labcodes_answer/lab2_result/libs/stdarg.h for 47.79.193.156:0, 404 Not Found in 0.5ms @ <autogenerated>:1(WebNotFound)
Aug 05 08:57:04 VM-8-17-ubuntu gitea[4160705]: 2025/08/05 08:57:04 ...eb/routing/logger.go:102:func1() [I] router: completed GET /cyp0633/ucore-lab/commits/commit/0a7d3faa0b7804e45252a70e583ede3459b16949/labcodes/lab7/tools for 47.79.213.176:0, 200 OK in 223.1ms @ repo/commit.go:44(repo.RefCommits)
Aug 05 08:57:04 VM-8-17-ubuntu gitea[4160705]: 2025/08/05 08:57:04 ...eb/routing/logger.go:102:func1() [I] router: completed GET /cyp0633/ucore-lab/src/commit/a29ae0982ac021cc2abeb75004af69b1b0d29f53/labcodes_answer/lab8_result/libs/string.h for 47.79.199.252:0, 200 OK in 568.3ms @ repo/view_home.go:332(repo.Home)
Aug 05 08:57:04 VM-8-17-ubuntu gitea[4160705]: 2025/08/05 08:57:04 ...eb/routing/logger.go:102:func1() [I] router: completed GET /cyp0633/ucore-lab/raw/commit/5204cd45e8a0f09f7a27ddad803bf28d56474dba/labcodes_answer/lab2_result/libs/error.h for 47.79.215.8:0, 200 OK in 201.5ms @ repo/download.go:111(repo.SingleDownload)
Aug 05 08:57:04 VM-8-17-ubuntu gitea[4160705]: 2025/08/05 08:57:04 ...eb/routing/logger.go:102:func1() [I] router: completed GET /cyp0633/ucore-lab/src/commit/0a7d3faa0b7804e45252a70e583ede3459b16949/labcodes_answer/lab2_result/kern/debug for 47.79.204.14:0, 200 OK in 351.2ms @ repo/view_home.go:332(repo.Home)
Aug 05 08:57:04 VM-8-17-ubuntu gitea[4160705]: 2025/08/05 08:57:04 ...eb/routing/logger.go:102:func1() [I] router: completed GET /cyp0633/ucore-lab/src/commit/5204cd45e8a0f09f7a27ddad803bf28d56474dba/labcodes_answer/lab2_result/kern/libs/readline.c for 47.79.213.33:0, 200 OK in 519.4ms @ repo/view_home.go:332(repo.Home)
Aug 05 08:57:04 VM-8-17-ubuntu gitea[4160705]: 2025/08/05 08:57:04 ...eb/routing/logger.go:102:func1() [I] router: completed GET /cyp0633/ucore-lab/raw/commit/5204cd45e8a0f09f7a27ddad803bf28d56474dba/labcodes_answer/lab3_result/tools/kernel.ld for 47.79.194.9:0, 200 OK in 121.7ms @ repo/download.go:111(repo.SingleDownload)
Aug 05 08:57:04 VM-8-17-ubuntu gitea[4160705]: 2025/08/05 08:57:04 ...eb/routing/logger.go:102:func1() [I] router: completed GET /cyp0633/ucore-lab/src/commit/a29ae0982ac021cc2abeb75004af69b1b0d29f53/labcodes_answer/lab8_result/libs/stdlib.h for 47.79.192.216:0, 200 OK in 272.8ms @ repo/view_home.go:332(repo.Home)
Aug 05 08:57:04 VM-8-17-ubuntu gitea[4160705]: 2025/08/05 08:57:04 ...eb/routing/logger.go:102:func1() [I] router: completed GET /cyp0633/ucore-lab/src/commit/a29ae0982ac021cc2abeb75004af69b1b0d29f53/labcodes_answer/lab8_result/libs/dirent.h for 47.79.205.12:0, 200 OK in 283.5ms @ repo/view_home.go:332(repo.Home)
Aug 05 08:57:04 VM-8-17-ubuntu gitea[4160705]: 2025/08/05 08:57:04 ...eb/routing/logger.go:102:func1() [I] router: completed GET /cyp0633/ucore-lab/commits/commit/a29ae0982ac021cc2abeb75004af69b1b0d29f53/labcodes_answer/lab8_result/libs for 47.79.212.251:0, 200 OK in 163.6ms @ repo/commit.go:44(repo.RefCommits)
Aug 05 08:57:04 VM-8-17-ubuntu gitea[4160705]: 2025/08/05 08:57:04 ...eb/routing/logger.go:102:func1() [I] router: completed GET /cyp0633/ucore-lab/blame/commit/d41b9e7f4fce933f5ce58c9c42e2f0bd5c7f6fc4/labcodes/lab7/Makefile for 47.79.213.33:0, 200 OK in 521.9ms @ repo/blame.go:42(repo.RefBlame)
Aug 05 08:57:04 VM-8-17-ubuntu gitea[4160705]: 2025/08/05 08:57:04 ...eb/routing/logger.go:102:func1() [I] router: completed GET /cyp0633/ucore-lab/src/commit/0a7d3faa0b7804e45252a70e583ede3459b16949/labcodes/lab7/tools/kernel.ld for 47.79.194.123:0, 200 OK in 392.8ms @ repo/view_home.go:332(repo.Home)
Aug 05 08:57:04 VM-8-17-ubuntu gitea[4160705]: 2025/08/05 08:57:04 ...eb/routing/logger.go:102:func1() [I] router: completed GET /cyp0633/ucore-lab/src/commit/5204cd45e8a0f09f7a27ddad803bf28d56474dba/labcodes_answer/lab3_result/tools for 47.79.192.112:0, 200 OK in 138.9ms @ repo/view_home.go:332(repo.Home)
Aug 05 08:57:04 VM-8-17-ubuntu gitea[4160705]: 2025/08/05 08:57:04 ...eb/routing/logger.go:102:func1() [I] router: completed GET /cyp0633/ucore-lab/commits/commit/5204cd45e8a0f09f7a27ddad803bf28d56474dba/labcodes_answer/lab3_result/tools/sign.c for 47.79.205.59:0, 200 OK in 105.0ms @ repo/commit.go:44(repo.RefCommits)
Aug 05 08:57:04 VM-8-17-ubuntu gitea[4160705]: 2025/08/05 08:57:04 ...eb/routing/logger.go:102:func1() [I] router: completed GET /cyp0633/ucore-lab/src/commit/a29ae0982ac021cc2abeb75004af69b1b0d29f53/labcodes_answer/lab8_result/libs/defs.h for 47.79.192.12:0, 200 OK in 154.0ms @ repo/view_home.go:332(repo.Home)
Aug 05 08:57:04 VM-8-17-ubuntu gitea[4160705]: 2025/08/05 08:57:04 ...eb/routing/logger.go:102:func1() [I] router: completed GET /cyp0633/ucore-lab/src/commit/a29ae0982ac021cc2abeb75004af69b1b0d29f53/labcodes_answer/lab8_result/libs/x86.h for 47.79.192.12:0, 200 OK in 345.3ms @ repo/view_home.go:332(repo.Home)
Aug 05 08:57:04 VM-8-17-ubuntu gitea[4160705]: 2025/08/05 08:57:04 ...eb/routing/logger.go:102:func1() [I] router: completed GET /cyp0633/ucore-lab/blame/commit/5204cd45e8a0f09f7a27ddad803bf28d56474dba/labcodes_answer/lab2_result/libs/defs.h for 47.79.198.73:0, 200 OK in 164.4ms @ repo/blame.go:42(repo.RefBlame)

Aug 05 08:57:04 VM-8-17-ubuntu gitea[4160705]: 2025/08/05 08:57:04 ...eb/routing/logger.go:102:func1() [I] router: completed GET /cyp0633/ucore-lab/rss/commit/5204cd45e8a0f09f7a27ddad803bf28d56474dba/labcodes_answer/lab3_result/tools/sign.c for 47.79.214.90:0, 404 Not Found in 0.2ms @ <autogenerated>:1(WebNotFound)
Aug 05 08:57:04 VM-8-17-ubuntu gitea[4160705]: 2025/08/05 08:57:04 ...eb/routing/logger.go:102:func1() [I] router: completed GET /cyp0633/ucore-lab/commits/commit/5204cd45e8a0f09f7a27ddad803bf28d56474dba/labcodes_answer/lab3_result/tools/kernel.ld for 47.79.199.163:0, 200 OK in 365.3ms @ repo/commit.go:44(repo.RefCommits)
Aug 05 08:57:04 VM-8-17-ubuntu gitea[4160705]: 2025/08/05 08:57:04 ...eb/routing/logger.go:102:func1() [I] router: completed GET /cyp0633/ucore-lab/src/commit/a29ae0982ac021cc2abeb75004af69b1b0d29f53/labcodes_answer/lab8_result/libs/printfmt.c for 47.79.215.248:0, 200 OK in 518.0ms @ repo/view_home.go:332(repo.Home)
Aug 05 08:57:04 VM-8-17-ubuntu gitea[4160705]: 2025/08/05 08:57:04 ...eb/routing/logger.go:102:func1() [I] router: completed GET /cyp0633/ucore-lab/src/commit/a29ae0982ac021cc2abeb75004af69b1b0d29f53/labcodes_answer/lab1_result/tools/lab1init for 47.79.197.254:0, 200 OK in 481.5ms @ repo/view_home.go:332(repo.Home)
Aug 05 08:57:04 VM-8-17-ubuntu gitea[4160705]: 2025/08/05 08:57:04 ...eb/routing/logger.go:102:func1() [I] router: completed GET /cyp0633/ucore-lab/rss/commit/5204cd45e8a0f09f7a27ddad803bf28d56474dba/labcodes_answer/lab2_result/libs/stdarg.h for 47.79.193.156:0, 404 Not Found in 0.5ms @ <autogenerated>:1(WebNotFound)
Aug 05 08:57:04 VM-8-17-ubuntu gitea[4160705]: 2025/08/05 08:57:04 ...eb/routing/logger.go:102:func1() [I] router: completed GET /cyp0633/ucore-lab/commits/commit/0a7d3faa0b7804e45252a70e583ede3459b16949/labcodes/lab7/tools for 47.79.213.176:0, 200 OK in 223.1ms @ repo/commit.go:44(repo.RefCommits)
Aug 05 08:57:04 VM-8-17-ubuntu gitea[4160705]: 2025/08/05 08:57:04 ...eb/routing/logger.go:102:func1() [I] router: completed GET /cyp0633/ucore-lab/src/commit/a29ae0982ac021cc2abeb75004af69b1b0d29f53/labcodes_answer/lab8_result/libs/string.h for 47.79.199.252:0, 200 OK in 568.3ms @ repo/view_home.go:332(repo.Home)
Aug 05 08:57:04 VM-8-17-ubuntu gitea[4160705]: 2025/08/05 08:57:04 ...eb/routing/logger.go:102:func1() [I] router: completed GET /cyp0633/ucore-lab/raw/commit/5204cd45e8a0f09f7a27ddad803bf28d56474dba/labcodes_answer/lab2_result/libs/error.h for 47.79.215.8:0, 200 OK in 201.5ms @ repo/download.go:111(repo.SingleDownload)
Aug 05 08:57:04 VM-8-17-ubuntu gitea[4160705]: 2025/08/05 08:57:04 ...eb/routing/logger.go:102:func1() [I] router: completed GET /cyp0633/ucore-lab/src/commit/0a7d3faa0b7804e45252a70e583ede3459b16949/labcodes_answer/lab2_result/kern/debug for 47.79.204.14:0, 200 OK in 351.2ms @ repo/view_home.go:332(repo.Home)
Aug 05 08:57:04 VM-8-17-ubuntu gitea[4160705]: 2025/08/05 08:57:04 ...eb/routing/logger.go:102:func1() [I] router: completed GET /cyp0633/ucore-lab/src/commit/5204cd45e8a0f09f7a27ddad803bf28d56474dba/labcodes_answer/lab2_result/kern/libs/readline.c for 47.79.213.33:0, 200 OK in 519.4ms @ repo/view_home.go:332(repo.Home)
Aug 05 08:57:04 VM-8-17-ubuntu gitea[4160705]: 2025/08/05 08:57:04 ...eb/routing/logger.go:102:func1() [I] router: completed GET /cyp0633/ucore-lab/raw/commit/5204cd45e8a0f09f7a27ddad803bf28d56474dba/labcodes_answer/lab3_result/tools/kernel.ld for 47.79.194.9:0, 200 OK in 121.7ms @ repo/download.go:111(repo.SingleDownload)
Aug 05 08:57:04 VM-8-17-ubuntu gitea[4160705]: 2025/08/05 08:57:04 ...eb/routing/logger.go:102:func1() [I] router: completed GET /cyp0633/ucore-lab/src/commit/a29ae0982ac021cc2abeb75004af69b1b0d29f53/labcodes_answer/lab8_result/libs/stdlib.h for 47.79.192.216:0, 200 OK in 272.8ms @ repo/view_home.go:332(repo.Home)
Aug 05 08:57:04 VM-8-17-ubuntu gitea[4160705]: 2025/08/05 08:57:04 ...eb/routing/logger.go:102:func1() [I] router: completed GET /cyp0633/ucore-lab/src/commit/a29ae0982ac021cc2abeb75004af69b1b0d29f53/labcodes_answer/lab8_result/libs/dirent.h for 47.79.205.12:0, 200 OK in 283.5ms @ repo/view_home.go:332(repo.Home)
Aug 05 08:57:04 VM-8-17-ubuntu gitea[4160705]: 2025/08/05 08:57:04 ...eb/routing/logger.go:102:func1() [I] router: completed GET /cyp0633/ucore-lab/commits/commit/a29ae0982ac021cc2abeb75004af69b1b0d29f53/labcodes_answer/lab8_result/libs for 47.79.212.251:0, 200 OK in 163.6ms @ repo/commit.go:44(repo.RefCommits)
Aug 05 08:57:04 VM-8-17-ubuntu gitea[4160705]: 2025/08/05 08:57:04 ...eb/routing/logger.go:102:func1() [I] router: completed GET /cyp0633/ucore-lab/blame/commit/d41b9e7f4fce933f5ce58c9c42e2f0bd5c7f6fc4/labcodes/lab7/Makefile for 47.79.213.33:0, 200 OK in 521.9ms @ repo/blame.go:42(repo.RefBlame)
Aug 05 08:57:04 VM-8-17-ubuntu gitea[4160705]: 2025/08/05 08:57:04 ...eb/routing/logger.go:102:func1() [I] router: completed GET /cyp0633/ucore-lab/src/commit/0a7d3faa0b7804e45252a70e583ede3459b16949/labcodes/lab7/tools/kernel.ld for 47.79.194.123:0, 200 OK in 392.8ms @ repo/view_home.go:332(repo.Home)
Aug 05 08:57:04 VM-8-17-ubuntu gitea[4160705]: 2025/08/05 08:57:04 ...eb/routing/logger.go:102:func1() [I] router: completed GET /cyp0633/ucore-lab/src/commit/5204cd45e8a0f09f7a27ddad803bf28d56474dba/labcodes_answer/lab3_result/tools for 47.79.192.112:0, 200 OK in 138.9ms @ repo/view_home.go:332(repo.Home)
Aug 05 08:57:04 VM-8-17-ubuntu gitea[4160705]: 2025/08/05 08:57:04 ...eb/routing/logger.go:102:func1() [I] router: completed GET /cyp0633/ucore-lab/commits/commit/5204cd45e8a0f09f7a27ddad803bf28d56474dba/labcodes_answer/lab3_result/tools/sign.c for 47.79.205.59:0, 200 OK in 105.0ms @ repo/commit.go:44(repo.RefCommits)
Aug 05 08:57:04 VM-8-17-ubuntu gitea[4160705]: 2025/08/05 08:57:04 ...eb/routing/logger.go:102:func1() [I] router: completed GET /cyp0633/ucore-lab/src/commit/a29ae0982ac021cc2abeb75004af69b1b0d29f53/labcodes_answer/lab8_result/libs/defs.h for 47.79.192.12:0, 200 OK in 154.0ms @ repo/view_home.go:332(repo.Home)
Aug 05 08:57:04 VM-8-17-ubuntu gitea[4160705]: 2025/08/05 08:57:04 ...eb/routing/logger.go:102:func1() [I] router: completed GET /cyp0633/ucore-lab/src/commit/a29ae0982ac021cc2abeb75004af69b1b0d29f53/labcodes_answer/lab8_result/libs/x86.h for 47.79.192.12:0, 200 OK in 345.3ms @ repo/view_home.go:332(repo.Home)
Aug 05 08:57:04 VM-8-17-ubuntu gitea[4160705]: 2025/08/05 08:57:04 ...eb/routing/logger.go:102:func1() [I] router: completed GET /cyp0633/ucore-lab/blame/commit/5204cd45e8a0f09f7a27ddad803bf28d56474dba/labcodes_answer/lab2_result/libs/defs.h for 47.79.198.73:0, 200 OK in 164.4ms @ repo/blame.go:42(repo.RefBlame)

vibe了一个分析脚本，发现28分钟的记录时间内处理了 56182 个请求，平均每分钟高达2000多个；请求来自于750个不同的IP，全都来自于47.79.0.0/16这个阿里云新加坡的IP段，这样分摊到每个IP上，半个小时不到200次请求，看起来非常的人畜无害。这使得手写IP封禁或者速率限制变得不切实际。为了保险起见，该日先把Gitea关掉了。

为了进一步确认这些IP的身份，将Gitea暂时关闭数天后，还导出了Caddy的日志。

log

Aug 19 21:00:32 VM-8-17-ubuntu caddy[5430]: {"level":"error","ts":1755608432.2537313,"logger":"http.log.error","msg":"dial tcp :3001: connect: connection refused","request":{"remote_ip":"47.79.201.138","remote_port":"56801","client_ip":"47.79.201.138","proto":"HTTP/1.1","method":"GET","host":"git.cyp0633.icu","uri":"/cyp0633/stack-mod/raw/commit/b66679d36acc0443078dafdfc5452880f376e015/layouts/partials/footer/script.html","headers":{"Cache-Control":["no-cache"],"Accept":["*/*"],"Sec-Ch-Ua-Platform":["\"macOS\""],"Accept-Language":["en,en-US"],"Sec-Fetch-Mode":["navigate"],"Sec-Fetch-Site":["none"],"Sec-Ch-Ua":["\"Google Chrome\";v=\"135\", \"Not-A.Brand\";v=\"8\", \"Chromium\";v=\"135\""],"Connection":["keep-alive"],"Pragma":["no-cache"],"Sec-Ch-Ua-Mobile":["?0"],"Upgrade-Insecure-Requests":["1"],"Sec-Fetch-User":["?1"],"Priority":["u=0, i"],"Sec-Fetch-Dest":["document"],"User-Agent":["Mozilla/5.0 (Windows NT 10.0; Win64; x64) Chrome/91.0.4472.124"],"Accept-Encoding":["gzip, deflate"]},"tls":{"resumed":false,"version":772,"cipher_suite":4865,"proto":"http/1.1","server_name":"git.cyp0633.icu"}},"duration":0.000190728,"status":502,"err_id":"00uu9mrsp","err_trace":"reverseproxy.statusError (reverseproxy.go:1373)"}
Aug 19 21:00:32 VM-8-17-ubuntu caddy[5430]: {"level":"error","ts":1755608432.260209,"logger":"http.log.error","msg":"dial tcp :3001: connect: connection refused","request":{"remote_ip":"47.79.212.84","remote_port":"39054","client_ip":"47.79.212.84","proto":"HTTP/1.1","method":"GET","host":"git.cyp0633.icu","uri":"/cyp0633/stack-mod/src/commit/25581cc44637909a75aacdf33f896192f0569689/layouts/partials/head/opengraph/include.html","headers":{"Accept-Language":["en,en-US"],"Connection":["keep-alive"],"Priority":["u=0, i"],"Sec-Fetch-Mode":["navigate"],"User-Agent":["Mozilla/5.0 (Windows NT 10.0; Win64; x64) Chrome/91.0.4472.124"],"Accept-Encoding":["gzip, deflate"],"Accept":["*/*"],"Sec-Ch-Ua-Platform":["\"macOS\""],"Sec-Fetch-Dest":["document"],"Pragma":["no-cache"],"Upgrade-Insecure-Requests":["1"],"Sec-Ch-Ua":["\"Google Chrome\";v=\"135\", \"Not-A.Brand\";v=\"8\", \"Chromium\";v=\"135\""],"Sec-Fetch-Site":["none"],"Sec-Fetch-User":["?1"],"Cache-Control":["no-cache"],"Sec-Ch-Ua-Mobile":["?0"]},"tls":{"resumed":false,"version":772,"cipher_suite":4865,"proto":"http/1.1","server_name":"git.cyp0633.icu"}},"duration":0.000227457,"status":502,"err_id":"aa84vne2s","err_trace":"reverseproxy.statusError (reverseproxy.go:1373)"}
Aug 19 21:00:32 VM-8-17-ubuntu caddy[5430]: {"level":"error","ts":1755608432.2617188,"logger":"http.log.error","msg":"dial tcp :3001: connect: connection refused","request":{"remote_ip":"47.79.206.1","remote_port":"30313","client_ip":"47.79.206.1","proto":"HTTP/1.1","method":"GET","host":"git.cyp0633.icu","uri":"/cyp0633/stack-mod/blame/commit/25a72940b8184b41de36fec9a3fcdd6387e006b0/layouts/partials/sidebar/left.html","headers":{"Sec-Fetch-Dest":["document"],"Upgrade-Insecure-Requests":["1"],"Cache-Control":["no-cache"],"Sec-Ch-Ua-Mobile":["?0"],"Accept-Encoding":["gzip, deflate"],"Pragma":["no-cache"],"Connection":["keep-alive"],"Sec-Fetch-Mode":["navigate"],"User-Agent":["Mozilla/5.0 (Windows NT 10.0; Win64; x64) Chrome/91.0.4472.124"],"Sec-Fetch-Site":["none"],"Sec-Fetch-User":["?1"],"Priority":["u=0, i"],"Sec-Ch-Ua-Platform":["\"macOS\""],"Accept-Language":["en,en-US"],"Sec-Ch-Ua":["\"Google Chrome\";v=\"135\", \"Not-A.Brand\";v=\"8\", \"Chromium\";v=\"135\""],"Accept":["*/*"]},"tls":{"resumed":false,"version":772,"cipher_suite":4865,"proto":"http/1.1","server_name":"git.cyp0633.icu"}},"duration":0.000177793,"status":502,"err_id":"7jqfa7yiq","err_trace":"reverseproxy.statusError (reverseproxy.go:1373)"}
Aug 19 21:00:32 VM-8-17-ubuntu caddy[5430]: {"level":"error","ts":1755608432.2736785,"logger":"http.log.error","msg":"dial tcp :3001: connect: connection refused","request":{"remote_ip":"47.79.198.78","remote_port":"25315","client_ip":"47.79.198.78","proto":"HTTP/1.1","method":"GET","host":"git.cyp0633.icu","uri":"/cyp0633/stack-mod/raw/commit/2fd3bde9a40790bf98893b0c5062a2f4c0ac9d8f/layouts/partials/article-list/compact.html","headers":{"Sec-Ch-Ua-Platform":["\"macOS\""],"Connection":["keep-alive"],"Cache-Control":["no-cache"],"Pragma":["no-cache"],"Sec-Fetch-Site":["none"],"Accept":["*/*"],"Sec-Ch-Ua-Mobile":["?0"],"Accept-Language":["en,en-US"],"Sec-Fetch-Dest":["document"],"Upgrade-Insecure-Requests":["1"],"Sec-Fetch-Mode":["navigate"],"Sec-Fetch-User":["?1"],"User-Agent":["Mozilla/5.0 (Windows NT 10.0; Win64; x64) Chrome/91.0.4472.124"],"Accept-Encoding":["gzip, deflate"],"Priority":["u=0, i"],"Sec-Ch-Ua":["\"Google Chrome\";v=\"135\", \"Not-A.Brand\";v=\"8\", \"Chromium\";v=\"135\""]},"tls":{"resumed":false,"version":772,"cipher_suite":4865,"proto":"http/1.1","server_name":"git.cyp0633.icu"}},"duration":0.000182872,"status":502,"err_id":"89gyde5bz","err_trace":"reverseproxy.statusError (reverseproxy.go:1373)"}
Aug 19 21:00:32 VM-8-17-ubuntu caddy[5430]: {"level":"error","ts":1755608432.2741818,"logger":"http.log.error","msg":"dial tcp :3001: connect: connection refused","request":{"remote_ip":"47.79.215.201","remote_port":"12618","client_ip":"47.79.215.201","proto":"HTTP/1.1","method":"GET","host":"git.cyp0633.icu","uri":"/cyp0633/stack-mod/commits/commit/25a72940b8184b41de36fec9a3fcdd6387e006b0/layouts/partials/sidebar/left.html","headers":{"Sec-Ch-Ua-Mobile":["?0"],"Accept":["*/*"],"Accept-Language":["en,en-US"],"Priority":["u=0, i"],"Sec-Fetch-Site":["none"],"Connection":["keep-alive"],"Upgrade-Insecure-Requests":["1"],"Sec-Fetch-Dest":["document"],"Accept-Encoding":["gzip, deflate"],"Sec-Ch-Ua-Platform":["\"macOS\""],"Sec-Fetch-Mode":["navigate"],"Sec-Fetch-User":["?1"],"Cache-Control":["no-cache"],"Pragma":["no-cache"],"Sec-Ch-Ua":["\"Google Chrome\";v=\"135\", \"Not-A.Brand\";v=\"8\", \"Chromium\";v=\"135\""],"User-Agent":["Mozilla/5.0 (Windows NT 10.0; Win64; x64) Chrome/91.0.4472.124"]},"tls":{"resumed":false,"version":772,"cipher_suite":4865,"proto":"http/1.1","server_name":"git.cyp0633.icu"}},"duration":0.000194264,"status":502,"err_id":"mzpuq5vau","err_trace":"reverseproxy.statusError (reverseproxy.go:1373)"}
Aug 19 21:00:32 VM-8-17-ubuntu caddy[5430]: {"level":"error","ts":1755608432.2894285,"logger":"http.log.error","msg":"dial tcp :3001: connect: connection refused","request":{"remote_ip":"47.79.195.97","remote_port":"5843","client_ip":"47.79.195.97","proto":"HTTP/1.1","method":"GET","host":"git.cyp0633.icu","uri":"/cyp0633/stack-mod/commits/commit/2fd3bde9a40790bf98893b0c5062a2f4c0ac9d8f/layouts/partials/article-list/tile.html","headers":{"Accept":["*/*"],"Cache-Control":["no-cache"],"Sec-Fetch-Mode":["navigate"],"Sec-Ch-Ua-Mobile":["?0"],"Sec-Fetch-Site":["none"],"Upgrade-Insecure-Requests":["1"],"User-Agent":["Mozilla/5.0 (Windows NT 10.0; Win64; x64) Chrome/91.0.4472.124"],"Sec-Ch-Ua":["\"Google Chrome\";v=\"135\", \"Not-A.Brand\";v=\"8\", \"Chromium\";v=\"135\""],"Pragma":["no-cache"],"Priority":["u=0, i"],"Accept-Encoding":["gzip, deflate"],"Sec-Ch-Ua-Platform":["\"macOS\""],"Sec-Fetch-Dest":["document"],"Sec-Fetch-User":["?1"],"Connection":["keep-alive"],"Accept-Language":["en,en-US"]},"tls":{"resumed":false,"version":772,"cipher_suite":4865,"proto":"http/1.1","server_name":"git.cyp0633.icu"}},"duration":0.00023476,"status":502,"err_id":"v3azrf597","err_trace":"reverseproxy.statusError (reverseproxy.go:1373)"}
Aug 19 21:00:32 VM-8-17-ubuntu caddy[5430]: {"level":"error","ts":1755608432.2902029,"logger":"http.log.error","msg":"dial tcp :3001: connect: connection refused","request":{"remote_ip":"47.79.193.3","remote_port":"51386","client_ip":"47.79.193.3","proto":"HTTP/1.1","method":"GET","host":"git.cyp0633.icu","uri":"/cyp0633/stack-mod/blame/commit/d04b3a8771386c9988be00adda53f0bf542cf269/layouts/partials/helper/image.html","headers":{"Cache-Control":["no-cache"],"Sec-Ch-Ua-Mobile":["?0"],"Accept-Encoding":["gzip, deflate"],"Sec-Ch-Ua":["\"Google Chrome\";v=\"135\", \"Not-A.Brand\";v=\"8\", \"Chromium\";v=\"135\""],"Upgrade-Insecure-Requests":["1"],"Accept-Language":["en,en-US"],"Sec-Fetch-Mode":["navigate"],"Sec-Fetch-User":["?1"],"Sec-Ch-Ua-Platform":["\"macOS\""],"Connection":["keep-alive"],"Sec-Fetch-Dest":["document"],"Sec-Fetch-Site":["none"],"Accept":["*/*"],"Priority":["u=0, i"],"Pragma":["no-cache"],"User-Agent":["Mozilla/5.0 (Windows NT 10.0; Win64; x64) Chrome/91.0.4472.124"]},"tls":{"resumed":false,"version":772,"cipher_suite":4865,"proto":"http/1.1","server_name":"git.cyp0633.icu"}},"duration":0.000307345,"status":502,"err_id":"6gv9knvpm","err_trace":"reverseproxy.statusError (reverseproxy.go:1373)"}
Aug 19 21:00:32 VM-8-17-ubuntu caddy[5430]: {"level":"error","ts":1755608432.2950988,"logger":"http.log.error","msg":"dial tcp :3001: connect: connection refused","request":{"remote_ip":"47.79.193.80","remote_port":"24245","client_ip":"47.79.193.80","proto":"HTTP/1.1","method":"GET","host":"git.cyp0633.icu","uri":"/cyp0633/stack-mod/commits/commit/c6661196ad92dfa72513582c40f75a6a5f514851/layouts/partials?page=1","headers":{"Sec-Ch-Ua-Mobile":["?0"],"User-Agent":["Mozilla/5.0 (Windows NT 10.0; Win64; x64) Chrome/91.0.4472.124"],"Sec-Fetch-User":["?1"],"Sec-Ch-Ua-Platform":["\"macOS\""],"Accept":["*/*"],"Upgrade-Insecure-Requests":["1"],"Sec-Ch-Ua":["\"Google Chrome\";v=\"135\", \"Not-A.Brand\";v=\"8\", \"Chromium\";v=\"135\""],"Pragma":["no-cache"],"Sec-Fetch-Dest":["document"],"Accept-Encoding":["gzip, deflate"],"Cache-Control":["no-cache"],"Accept-Language":["en,en-US"],"Priority":["u=0, i"],"Sec-Fetch-Mode":["navigate"],"Connection":["keep-alive"],"Sec-Fetch-Site":["none"]},"tls":{"resumed":false,"version":772,"cipher_suite":4865,"proto":"http/1.1","server_name":"git.cyp0633.icu"}},"duration":0.000194966,"status":502,"err_id":"ju8k688tg","err_trace":"reverseproxy.statusError (reverseproxy.go:1373)"}
Aug 19 21:00:32 VM-8-17-ubuntu caddy[5430]: {"level":"error","ts":1755608432.3023942,"logger":"http.log.error","msg":"dial tcp :3001: connect: connection refused","request":{"remote_ip":"47.79.205.248","remote_port":"12381","client_ip":"47.79.205.248","proto":"HTTP/1.1","method":"GET","host":"git.cyp0633.icu","uri":"/cyp0633/stack-mod/rss/commit/0af9d23e4989ed7ada10e6990802ccd9a28d8797/layouts/partials/sidebar/right.html","headers":{"Sec-Ch-Ua-Platform":["\"macOS\""],"Sec-Ch-Ua":["\"Google Chrome\";v=\"135\", \"Not-A.Brand\";v=\"8\", \"Chromium\";v=\"135\""],"Sec-Fetch-Mode":["navigate"],"Upgrade-Insecure-Requests":["1"],"Pragma":["no-cache"],"Cache-Control":["no-cache"],"Sec-Ch-Ua-Mobile":["?0"],"Sec-Fetch-Dest":["document"],"Sec-Fetch-User":["?1"],"Accept-Language":["en,en-US"],"User-Agent":["Mozilla/5.0 (Windows NT 10.0; Win64; x64) Chrome/91.0.4472.124"],"Accept-Encoding":["gzip, deflate"],"Accept":["*/*"],"Priority":["u=0, i"],"Connection":["keep-alive"],"Sec-Fetch-Site":["none"]},"tls":{"resumed":false,"version":772,"cipher_suite":4865,"proto":"http/1.1","server_name":"git.cyp0633.icu"}},"duration":0.000187251,"status":502,"err_id":"4m19ms28b","err_trace":"reverseproxy.statusError (reverseproxy.go:1373)"}
Aug 19 21:00:32 VM-8-17-ubuntu caddy[5430]: {"level":"error","ts":1755608432.3110833,"logger":"http.log.error","msg":"dial tcp :3001: connect: connection refused","request":{"remote_ip":"47.79.212.84","remote_port":"57044","client_ip":"47.79.212.84","proto":"HTTP/1.1","method":"GET","host":"git.cyp0633.icu","uri":"/cyp0633/stack-mod/commits/commit/2fd3bde9a40790bf98893b0c5062a2f4c0ac9d8f/layouts/partials/article-list/compact.html","headers":{"User-Agent":["Mozilla/5.0 (Windows NT 10.0; Win64; x64) Chrome/91.0.4472.124"],"Sec-Fetch-Site":["none"],"Priority":["u=0, i"],"Cache-Control":["no-cache"],"Pragma":["no-cache"],"Sec-Ch-Ua":["\"Google Chrome\";v=\"135\", \"Not-A.Brand\";v=\"8\", \"Chromium\";v=\"135\""],"Sec-Ch-Ua-Platform":["\"macOS\""],"Upgrade-Insecure-Requests":["1"],"Sec-Ch-Ua-Mobile":["?0"],"Connection":["keep-alive"],"Sec-Fetch-Mode":["navigate"],"Sec-Fetch-User":["?1"],"Accept":["*/*"],"Accept-Language":["en,en-US"],"Accept-Encoding":["gzip, deflate"],"Sec-Fetch-Dest":["document"]},"tls":{"resumed":false,"version":772,"cipher_suite":4865,"proto":"http/1.1","server_name":"git.cyp0633.icu"}},"duration":0.000179277,"status":502,"err_id":"hk01fb751","err_trace":"reverseproxy.statusError (reverseproxy.go:1373)"}
Aug 19 21:00:32 VM-8-17-ubuntu caddy[5430]: {"level":"error","ts":1755608432.31186,"logger":"http.log.error","msg":"dial tcp :3001: connect: connection refused","request":{"remote_ip":"47.79.205.70","remote_port":"51797","client_ip":"47.79.205.70","proto":"HTTP/1.1","method":"GET","host":"git.cyp0633.icu","uri":"/cyp0633/stack-mod/src/commit/d04b3a8771386c9988be00adda53f0bf542cf269/layouts/partials/helper/icon.html","headers":{"Accept":["*/*"],"Accept-Language":["en,en-US"],"User-Agent":["Mozilla/5.0 (Windows NT 10.0; Win64; x64) Chrome/91.0.4472.124"],"Pragma":["no-cache"],"Sec-Fetch-Site":["none"],"Sec-Ch-Ua-Mobile":["?0"],"Accept-Encoding":["gzip, deflate"],"Priority":["u=0, i"],"Sec-Ch-Ua":["\"Google Chrome\";v=\"135\", \"Not-A.Brand\";v=\"8\", \"Chromium\";v=\"135\""],"Sec-Fetch-Dest":["document"],"Cache-Control":["no-cache"],"Connection":["keep-alive"],"Upgrade-Insecure-Requests":["1"],"Sec-Ch-Ua-Platform":["\"macOS\""],"Sec-Fetch-User":["?1"],"Sec-Fetch-Mode":["navigate"]},"tls":{"resumed":false,"version":772,"cipher_suite":4865,"proto":"http/1.1","server_name":"git.cyp0633.icu"}},"duration":0.00037888,"status":502,"err_id":"7dz5tnw6r","err_trace":"reverseproxy.statusError (reverseproxy.go:1373)"}
Aug 19 21:00:32 VM-8-17-ubuntu caddy[5430]: {"level":"error","ts":1755608432.3274698,"logger":"http.log.error","msg":"dial tcp :3001: connect: connection refused","request":{"remote_ip":"47.79.200.118","remote_port":"13643","client_ip":"47.79.200.118","proto":"HTTP/1.1","method":"GET","host":"git.cyp0633.icu","uri":"/cyp0633/stack-mod/rss/commit/0af9d23e4989ed7ada10e6990802ccd9a28d8797/layouts/partials/data/description.html","headers":{"Priority":["u=0, i"],"Sec-Ch-Ua-Mobile":["?0"],"User-Agent":["Mozilla/5.0 (Windows NT 10.0; Win64; x64) Chrome/91.0.4472.124"],"Sec-Fetch-Mode":["navigate"],"Sec-Ch-Ua-Platform":["\"macOS\""],"Connection":["keep-alive"],"Cache-Control":["no-cache"],"Sec-Fetch-User":["?1"],"Sec-Ch-Ua":["\"Google Chrome\";v=\"135\", \"Not-A.Brand\";v=\"8\", \"Chromium\";v=\"135\""],"Upgrade-Insecure-Requests":["1"],"Sec-Fetch-Dest":["document"],"Accept-Encoding":["gzip, deflate"],"Accept":["*/*"],"Accept-Language":["en,en-US"],"Sec-Fetch-Site":["none"],"Pragma":["no-cache"]},"tls":{"resumed":false,"version":772,"cipher_suite":4865,"proto":"http/1.1","server_name":"git.cyp0633.icu"}},"duration":0.000217268,"status":502,"err_id":"ht5drxez1","err_trace":"reverseproxy.statusError (reverseproxy.go:1373)"}
Aug 19 21:00:32 VM-8-17-ubuntu caddy[5430]: {"level":"error","ts":1755608432.3605616,"logger":"http.log.error","msg":"dial tcp :3001: connect: connection refused","request":{"remote_ip":"47.79.215.215","remote_port":"44762","client_ip":"47.79.215.215","proto":"HTTP/1.1","method":"GET","host":"git.cyp0633.icu","uri":"/cyp0633/stack-mod/src/commit/25581cc44637909a75aacdf33f896192f0569689/layouts/partials/head/opengraph/provider","headers":{"Sec-Fetch-Site":["none"],"Sec-Ch-Ua":["\"Google Chrome\";v=\"135\", \"Not-A.Brand\";v=\"8\", \"Chromium\";v=\"135\""],"Cache-Control":["no-cache"],"Priority":["u=0, i"],"Sec-Fetch-User":["?1"],"Pragma":["no-cache"],"Accept-Language":["en,en-US"],"Sec-Ch-Ua-Mobile":["?0"],"Sec-Fetch-Dest":["document"],"User-Agent":["Mozilla/5.0 (Windows NT 10.0; Win64; x64) Chrome/91.0.4472.124"],"Connection":["keep-alive"],"Upgrade-Insecure-Requests":["1"],"Accept-Encoding":["gzip, deflate"],"Sec-Ch-Ua-Platform":["\"macOS\""],"Accept":["*/*"],"Sec-Fetch-Mode":["navigate"]},"tls":{"resumed":false,"version":772,"cipher_suite":4865,"proto":"http/1.1","server_name":"git.cyp0633.icu"}},"duration":0.000191609,"status":502,"err_id":"fhuzf2976","err_trace":"reverseproxy.statusError (reverseproxy.go:1373)"}
Aug 19 21:00:32 VM-8-17-ubuntu caddy[5430]: {"level":"error","ts":1755608432.3730135,"logger":"http.log.error","msg":"dial tcp :3001: connect: connection refused","request":{"remote_ip":"47.79.215.163","remote_port":"20753","client_ip":"47.79.215.163","proto":"HTTP/1.1","method":"GET","host":"git.cyp0633.icu","uri":"/cyp0633/stack-mod/raw/commit/0af9d23e4989ed7ada10e6990802ccd9a28d8797/layouts/partials/data/description.html","headers":{"Sec-Ch-Ua":["\"Google Chrome\";v=\"135\", \"Not-A.Brand\";v=\"8\", \"Chromium\";v=\"135\""],"Pragma":["no-cache"],"Cache-Control":["no-cache"],"Sec-Ch-Ua-Platform":["\"macOS\""],"Sec-Fetch-Mode":["navigate"],"Connection":["keep-alive"],"Accept-Language":["en,en-US"],"Accept-Encoding":["gzip, deflate"],"Upgrade-Insecure-Requests":["1"],"User-Agent":["Mozilla/5.0 (Windows NT 10.0; Win64; x64) Chrome/91.0.4472.124"],"Accept":["*/*"],"Sec-Ch-Ua-Mobile":["?0"],"Sec-Fetch-Site":["none"],"Sec-Fetch-Dest":["document"],"Sec-Fetch-User":["?1"],"Priority":["u=0, i"]},"tls":{"resumed":false,"version":772,"cipher_suite":4865,"proto":"http/1.1","server_name":"git.cyp0633.icu"}},"duration":0.000226774,"status":502,"err_id":"kprf6bcji","err_trace":"reverseproxy.statusError (reverseproxy.go:1373)"}
Aug 19 21:00:32 VM-8-17-ubuntu caddy[5430]: {"level":"error","ts":1755608432.4402184,"logger":"http.log.error","msg":"dial tcp :3001: connect: connection refused","request":{"remote_ip":"47.79.195.231","remote_port":"49027","client_ip":"47.79.195.231","proto":"HTTP/1.1","method":"GET","host":"git.cyp0633.icu","uri":"/cyp0633/stack-mod/raw/commit/25581cc44637909a75aacdf33f896192f0569689/layouts/partials/head/style.html","headers":{"User-Agent":["Mozilla/5.0 (Windows NT 10.0; Win64; x64) Chrome/91.0.4472.124"],"Sec-Ch-Ua-Mobile":["?0"],"Pragma":["no-cache"],"Sec-Fetch-User":["?1"],"Cache-Control":["no-cache"],"Connection":["keep-alive"],"Accept":["*/*"],"Sec-Fetch-Mode":["navigate"],"Upgrade-Insecure-Requests":["1"],"Accept-Language":["en,en-US"],"Sec-Ch-Ua":["\"Google Chrome\";v=\"135\", \"Not-A.Brand\";v=\"8\", \"Chromium\";v=\"135\""],"Sec-Fetch-Dest":["document"],"Sec-Fetch-Site":["none"],"Accept-Encoding":["gzip, deflate"],"Priority":["u=0, i"],"Sec-Ch-Ua-Platform":["\"macOS\""]},"tls":{"resumed":false,"version":772,"cipher_suite":4865,"proto":"http/1.1","server_name":"git.cyp0633.icu"}},"duration":0.000254457,"status":502,"err_id":"yp9xbpai2","err_trace":"reverseproxy.statusError (reverseproxy.go:1373)"}
Aug 19 21:00:32 VM-8-17-ubuntu caddy[5430]: {"level":"error","ts":1755608432.4595432,"logger":"http.log.error","msg":"dial tcp :3001: connect: connection refused","request":{"remote_ip":"47.79.200.216","remote_port":"3491","client_ip":"47.79.200.216","proto":"HTTP/1.1","method":"GET","host":"git.cyp0633.icu","uri":"/cyp0633/stack-mod/raw/commit/d04b3a8771386c9988be00adda53f0bf542cf269/layouts/partials/helper/icon.html","headers":{"Connection":["keep-alive"],"Accept-Encoding":["gzip, deflate"],"Sec-Fetch-Dest":["document"],"Cache-Control":["no-cache"],"Accept-Language":["en,en-US"],"Accept":["*/*"],"Sec-Fetch-Site":["none"],"Sec-Ch-Ua-Mobile":["?0"],"Sec-Ch-Ua-Platform":["\"macOS\""],"Pragma":["no-cache"],"Sec-Fetch-User":["?1"],"Sec-Fetch-Mode":["navigate"],"User-Agent":["Mozilla/5.0 (Windows NT 10.0; Win64; x64) Chrome/91.0.4472.124"],"Priority":["u=0, i"],"Sec-Ch-Ua":["\"Google Chrome\";v=\"135\", \"Not-A.Brand\";v=\"8\", \"Chromium\";v=\"135\""],"Upgrade-Insecure-Requests":["1"]},"tls":{"resumed":false,"version":772,"cipher_suite":4865,"proto":"http/1.1","server_name":"git.cyp0633.icu"}},"duration":0.000294471,"status":502,"err_id":"txnhq2xhy","err_trace":"reverseproxy.statusError (reverseproxy.go:1373)"}
Aug 19 21:00:32 VM-8-17-ubuntu caddy[5430]: {"level":"error","ts":1755608432.4613986,"logger":"http.log.error","msg":"dial tcp :3001: connect: connection refused","request":{"remote_ip":"47.79.200.119","remote_port":"54239","client_ip":"47.79.200.119","proto":"HTTP/1.1","method":"GET","host":"git.cyp0633.icu","uri":"/cyp0633/stack-mod/src/commit/25a72940b8184b41de36fec9a3fcdd6387e006b0/layouts/partials/sidebar/left.html","headers":{"Sec-Ch-Ua-Mobile":["?0"],"Priority":["u=0, i"],"Upgrade-Insecure-Requests":["1"],"Cache-Control":["no-cache"],"Connection":["keep-alive"],"Pragma":["no-cache"],"Accept-Language":["en,en-US"],"User-Agent":["Mozilla/5.0 (Windows NT 10.0; Win64; x64) Chrome/91.0.4472.124"],"Sec-Ch-Ua":["\"Google Chrome\";v=\"135\", \"Not-A.Brand\";v=\"8\", \"Chromium\";v=\"135\""],"Accept-Encoding":["gzip, deflate"],"Sec-Ch-Ua-Platform":["\"macOS\""],"Sec-Fetch-Dest":["document"],"Accept":["*/*"],"Sec-Fetch-Mode":["navigate"],"Sec-Fetch-Site":["none"],"Sec-Fetch-User":["?1"]},"tls":{"resumed":false,"version":772,"cipher_suite":4865,"proto":"http/1.1","server_name":"git.cyp0633.icu"}},"duration":0.000191127,"status":502,"err_id":"a7uvn7yxk","err_trace":"reverseproxy.statusError (reverseproxy.go:1373)"}

没想到即使遭遇了数天的HTTP 502，这些IP还是不死心，在坚持不懈地进行访问。一模一样的IP段，一模一样的访问模式，一模一样的假User-Agent。在意识到还是不如套个Cloudflare来得方便后，我便打开了代理开关，把这些IP全都上报到了AbuseIPDB。这个阿里云用户似乎没有完全罢休，在切换到Cloudflare后仍然锲而不舍地爬了好一会，造成了Cloudflare访问统计上的一座高峰；之后还使用阿里云香港，隶属于AS45102的IP继续尝试访问，不过都被Cloudflare挡下来了。

Cloudflare 访问统计

刷爆对象存储，但是细水长流

前段时间阿里云给我发了条短信：

【阿里云】尊敬的cyp*33，截至2025-08-21 18:02:57，您的剩余可用额度为1.24元。根据您以往消费情况预测，剩余可用额度可能不足以支撑您未来7天的消费，为了避免欠费导致产品停止服务，请您及时充值。您可以登录阿里云官网查询账户可用额度信息和延停权益。

当时没太在意，以为是正常的余额消耗，因为虽然OSS一个月花不了几毛钱，但阿里云上还有大模型推理，可能最近用模型太多了。然而过了四天，就用掉了0.71元，消耗速度有些异常：

【阿里云】尊敬的cyp*33，截至2025-08-25 15:02:10，您的剩余可用额度为0.53元。根据您以往消费情况预测，剩余可用额度可能不足以支撑您未来3天的消费。为了避免欠费导致产品停止服务，请您及时充值。您可以登录阿里云官网查询账户可用额度信息和延停权益。

进阿里云一看，才发现是OSS在花钱。为了节省Netlify的空间，提高国内的访问速度，Netlify上仅有博客的核心静态资源，而图片等大文件托管在内地的一个公共读阿里云OSS上。虽然开启了Referer白名单防盗链，但鉴于Referer投可以伪造，所以还是不保险。相比于之前的消耗速度，一天两毛钱已经算是警告了：如果再不处理，恐怕真的要欠费了。

依旧导出了一些OSS的日志：

csv

__source__,__time__,__topic__,acc_access_region,access_id,archive_direct_read_size,bucket,bucket_location,bucket_storage_type,cdn_in,cdn_out,client_ip,content_length_in,content_length_out,delta_data_size,ec,end_time,error_code,extend_information,get_request,host,http_method,http_status,http_type,intranet_in,intranet_out,logging_flag,metering_datasize,metering_datasize_ca,metering_datasize_zrs,metering_datasize_zrsii,network_in,network_out,object,object_size,operation,owner_id,process_img,process_img_size,put_request,referer,region,request_id,request_length,request_uri,requester_id,response_body_length,response_time,restore_priority,server_cost_time,sign_type,start_time,storage,storage_type,sync_in,sync_out,sync_request,target_storage_class,time,user_agent,user_defined_log_fields,vpc_addr,vpc_id
log_dispatch,1756752249,oss_access_log,-,-,-,cyp0633-blogasset,oss-cn-qingdao-h,standard,,,46.62.169.27,-,185189,-,-,,-,-,,cyp0633-blogasset.cn-qingdao.oss.aliyuncs.com,GET,200,https,,,true,,,,,,,need-for-speed-unbound%2FNeed%20for%20Speed%E2%84%A2%20Unbound%202023-01-22%2010-57-14.mp4_20230122_151607.850.avif,185189,GetObject,1385315732671155,,,,https://cyp0633-blogasset.cn-qingdao.oss.aliyuncs.com,,68B5E979E8569830337BD3AC,750,/need-for-speed-unbound/Need%20for%20Speed%E2%84%A2%20Unbound%202023-01-22%2010-57-14.mp4_20230122_151607.850.avif HTTP/1.1,-,185189,24,-,22,NotSign,,,,,,-,-,02/Sep/2025:02:44:09,"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36",-,172563320,0
log_dispatch,1756752249,oss_access_log,-,-,-,cyp0633-blogasset,oss-cn-qingdao-h,standard,,,46.62.169.27,-,76636,-,-,,-,-,,cyp0633-blogasset.cn-qingdao.oss.aliyuncs.com,GET,200,https,,,true,,,,,,,nuc-homelab%2Fdiskperf.avif,76636,GetObject,1385315732671155,,,,https://cyp0633-blogasset.cn-qingdao.oss.aliyuncs.com,,68B5E97978A51C363838F585,662,/nuc-homelab/diskperf.avif HTTP/1.1,-,76636,41,-,41,NotSign,,,,,,-,-,02/Sep/2025:02:44:09,"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36",-,172563320,0
log_dispatch,1756752249,oss_access_log,-,-,-,cyp0633-blogasset,oss-cn-qingdao-h,standard,,,46.62.169.27,-,233860,-,-,,-,-,,cyp0633-blogasset.cn-qingdao.oss.aliyuncs.com,GET,200,https,,,true,,,,,,,vscode-latex%2Fvscode-with-extension.avif,233860,GetObject,1385315732671155,,,,https://cyp0633-blogasset.cn-qingdao.oss.aliyuncs.com,,68B5E97978A51C35354AF585,676,/vscode-latex/vscode-with-extension.avif HTTP/1.1,-,233860,33,-,31,NotSign,,,,,,-,-,02/Sep/2025:02:44:09,"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36",-,172563320,0
log_dispatch,1756752249,oss_access_log,-,-,-,cyp0633-blogasset,oss-cn-qingdao-h,standard,,,46.62.169.27,-,144022,-,-,,-,-,,cyp0633-blogasset.cn-qingdao.oss.aliyuncs.com,GET,200,https,,,true,,,,,,,windows-11-bugs%2Fwin11bug21.avif,144022,GetObject,1385315732671155,,,,https://cyp0633-blogasset.cn-qingdao.oss.aliyuncs.com,,68B5E9794A68943931DED990,668,/windows-11-bugs/win11bug21.avif HTTP/1.1,-,144022,31,-,30,NotSign,,,,,,-,-,02/Sep/2025:02:44:09,"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36",-,172563320,0
log_dispatch,1756752249,oss_access_log,-,-,-,cyp0633-blogasset,oss-cn-qingdao-h,standard,,,46.62.169.27,-,158049,-,-,,-,-,,cyp0633-blogasset.cn-qingdao.oss.aliyuncs.com,GET,200,https,,,true,,,,,,,wild-chicken-university%2Ftianyancha.avif,158049,GetObject,1385315732671155,,,,https://cyp0633-blogasset.cn-qingdao.oss.aliyuncs.com,,68B5E9798F796838331F52B9,676,/wild-chicken-university/tianyancha.avif HTTP/1.1,-,158049,30,-,27,NotSign,,,,,,-,-,02/Sep/2025:02:44:09,"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36",-,172563320,0
log_dispatch,1756752249,oss_access_log,-,-,-,cyp0633-blogasset,oss-cn-qingdao-h,standard,,,46.62.169.27,-,28216,-,-,,-,-,,cyp0633-blogasset.cn-qingdao.oss.aliyuncs.com,GET,200,https,,,true,,,,,,,vmware-ubuntu-12.04%2Faccount.avif,28216,GetObject,1385315732671155,,,,https://cyp0633-blogasset.cn-qingdao.oss.aliyuncs.com,,68B5E9792E174C34349AADA1,669,/vmware-ubuntu-12.04/account.avif HTTP/1.1,-,28216,33,-,32,NotSign,,,,,,-,-,02/Sep/2025:02:44:09,"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36",-,172563320,0
log_dispatch,1756752249,oss_access_log,-,-,-,cyp0633-blogasset,oss-cn-qingdao-h,standard,,,46.62.169.27,-,55299,-,-,,-,-,,cyp0633-blogasset.cn-qingdao.oss.aliyuncs.com,GET,200,https,,,true,,,,,,,windows-11-21996-leaked%2Fstart-menu.avif,55299,GetObject,1385315732671155,,,,https://cyp0633-blogasset.cn-qingdao.oss.aliyuncs.com,,68B5E979AF9A9630396238AC,676,/windows-11-21996-leaked/start-menu.avif HTTP/1.1,-,55299,27,-,26,NotSign,,,,,,-,-,02/Sep/2025:02:44:09,"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36",-,172563320,0
log_dispatch,1756752249,oss_access_log,-,-,-,cyp0633-blogasset,oss-cn-qingdao-h,standard,,,46.62.169.27,-,14143,-,-,,-,-,,cyp0633-blogasset.cn-qingdao.oss.aliyuncs.com,GET,200,https,,,true,,,,,,,windows-11-21996-leaked%2Foobe4.avif,14143,GetObject,1385315732671155,,,,https://cyp0633-blogasset.cn-qingdao.oss.aliyuncs.com,,68B5E979AF9A9635306338AC,671,/windows-11-21996-leaked/oobe4.avif HTTP/1.1,-,14143,33,-,32,NotSign,,,,,,-,-,02/Sep/2025:02:44:09,"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36",-,172563320,0
log_dispatch,1756752249,oss_access_log,-,-,-,cyp0633-blogasset,oss-cn-qingdao-h,standard,,,46.62.169.27,-,20354,-,-,,-,-,,cyp0633-blogasset.cn-qingdao.oss.aliyuncs.com,GET,200,https,,,true,,,,,,,windows-11-21996-leaked%2Fwindows-10-calendar.avif,20354,GetObject,1385315732671155,,,,https://cyp0633-blogasset.cn-qingdao.oss.aliyuncs.com,,68B5E9798D51EC3531998676,685,/windows-11-21996-leaked/windows-10-calendar.avif HTTP/1.1,-,20354,34,-,34,NotSign,,,,,,-,-,02/Sep/2025:02:44:09,"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36",-,172563320,0
log_dispatch,1756752249,oss_access_log,-,-,-,cyp0633-blogasset,oss-cn-qingdao-h,standard,,,46.62.169.27,-,32798,-,-,,-,-,,cyp0633-blogasset.cn-qingdao.oss.aliyuncs.com,GET,200,https,,,true,,,,,,,windows-11-21996-leaked%2Foobe5.avif,32798,GetObject,1385315732671155,,,,https://cyp0633-blogasset.cn-qingdao.oss.aliyuncs.com,,68B5E9798D51EC3230A48676,671,/windows-11-21996-leaked/oobe5.avif HTTP/1.1,-,32798,32,-,30,NotSign,,,,,,-,-,02/Sep/2025:02:44:09,"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36",-,172563320,0
log_dispatch,1756752249,oss_access_log,-,-,-,cyp0633-blogasset,oss-cn-qingdao-h,standard,,,46.62.169.27,-,61159,-,-,,-,-,,cyp0633-blogasset.cn-qingdao.oss.aliyuncs.com,GET,200,https,,,true,,,,,,,windows-11-bugs%2Fwin11bug5.avif,61159,GetObject,1385315732671155,,,,https://cyp0633-blogasset.cn-qingdao.oss.aliyuncs.com,,68B5E979C759F63035B22080,667,/windows-11-bugs/win11bug5.avif HTTP/1.1,-,61159,23,-,18,NotSign,,,,,,-,-,02/Sep/2025:02:44:09,"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36",-,172563320,0
log_dispatch,1756752249,oss_access_log,-,-,-,cyp0633-blogasset,oss-cn-qingdao-h,standard,,,46.62.169.27,-,199772,-,-,,-,-,,cyp0633-blogasset.cn-qingdao.oss.aliyuncs.com,GET,200,https,,,true,,,,,,,nuc-homelab%2Fsiyuan.avif,199772,GetObject,1385315732671155,,,,https://cyp0633-blogasset.cn-qingdao.oss.aliyuncs.com,,68B5E979C70CA13536A34EB1,660,/nuc-homelab/siyuan.avif HTTP/1.1,-,199772,45,-,44,NotSign,,,,,,-,-,02/Sep/2025:02:44:09,"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36",-,172563320,0
log_dispatch,1756752249,oss_access_log,-,-,-,cyp0633-blogasset,oss-cn-qingdao-h,standard,,,46.62.169.27,-,41757,-,-,,-,-,,cyp0633-blogasset.cn-qingdao.oss.aliyuncs.com,GET,200,https,,,true,,,,,,,csapp-bufferlab%2Fstackframe.avif,41757,GetObject,1385315732671155,,,,https://cyp0633-blogasset.cn-qingdao.oss.aliyuncs.com,,68B5E979C70CA13931A94EB1,668,/csapp-bufferlab/stackframe.avif HTTP/1.1,-,41757,67,-,66,NotSign,,,,,,-,-,02/Sep/2025:02:44:09,"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36",-,172563320,0

__source__,__time__,__topic__,acc_access_region,access_id,archive_direct_read_size,bucket,bucket_location,bucket_storage_type,cdn_in,cdn_out,client_ip,content_length_in,content_length_out,delta_data_size,ec,end_time,error_code,extend_information,get_request,host,http_method,http_status,http_type,intranet_in,intranet_out,logging_flag,metering_datasize,metering_datasize_ca,metering_datasize_zrs,metering_datasize_zrsii,network_in,network_out,object,object_size,operation,owner_id,process_img,process_img_size,put_request,referer,region,request_id,request_length,request_uri,requester_id,response_body_length,response_time,restore_priority,server_cost_time,sign_type,start_time,storage,storage_type,sync_in,sync_out,sync_request,target_storage_class,time,user_agent,user_defined_log_fields,vpc_addr,vpc_id
log_dispatch,1756752249,oss_access_log,-,-,-,cyp0633-blogasset,oss-cn-qingdao-h,standard,,,46.62.169.27,-,185189,-,-,,-,-,,cyp0633-blogasset.cn-qingdao.oss.aliyuncs.com,GET,200,https,,,true,,,,,,,need-for-speed-unbound%2FNeed%20for%20Speed%E2%84%A2%20Unbound%202023-01-22%2010-57-14.mp4_20230122_151607.850.avif,185189,GetObject,1385315732671155,,,,https://cyp0633-blogasset.cn-qingdao.oss.aliyuncs.com,,68B5E979E8569830337BD3AC,750,/need-for-speed-unbound/Need%20for%20Speed%E2%84%A2%20Unbound%202023-01-22%2010-57-14.mp4_20230122_151607.850.avif HTTP/1.1,-,185189,24,-,22,NotSign,,,,,,-,-,02/Sep/2025:02:44:09,"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36",-,172563320,0
log_dispatch,1756752249,oss_access_log,-,-,-,cyp0633-blogasset,oss-cn-qingdao-h,standard,,,46.62.169.27,-,76636,-,-,,-,-,,cyp0633-blogasset.cn-qingdao.oss.aliyuncs.com,GET,200,https,,,true,,,,,,,nuc-homelab%2Fdiskperf.avif,76636,GetObject,1385315732671155,,,,https://cyp0633-blogasset.cn-qingdao.oss.aliyuncs.com,,68B5E97978A51C363838F585,662,/nuc-homelab/diskperf.avif HTTP/1.1,-,76636,41,-,41,NotSign,,,,,,-,-,02/Sep/2025:02:44:09,"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36",-,172563320,0
log_dispatch,1756752249,oss_access_log,-,-,-,cyp0633-blogasset,oss-cn-qingdao-h,standard,,,46.62.169.27,-,233860,-,-,,-,-,,cyp0633-blogasset.cn-qingdao.oss.aliyuncs.com,GET,200,https,,,true,,,,,,,vscode-latex%2Fvscode-with-extension.avif,233860,GetObject,1385315732671155,,,,https://cyp0633-blogasset.cn-qingdao.oss.aliyuncs.com,,68B5E97978A51C35354AF585,676,/vscode-latex/vscode-with-extension.avif HTTP/1.1,-,233860,33,-,31,NotSign,,,,,,-,-,02/Sep/2025:02:44:09,"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36",-,172563320,0
log_dispatch,1756752249,oss_access_log,-,-,-,cyp0633-blogasset,oss-cn-qingdao-h,standard,,,46.62.169.27,-,144022,-,-,,-,-,,cyp0633-blogasset.cn-qingdao.oss.aliyuncs.com,GET,200,https,,,true,,,,,,,windows-11-bugs%2Fwin11bug21.avif,144022,GetObject,1385315732671155,,,,https://cyp0633-blogasset.cn-qingdao.oss.aliyuncs.com,,68B5E9794A68943931DED990,668,/windows-11-bugs/win11bug21.avif HTTP/1.1,-,144022,31,-,30,NotSign,,,,,,-,-,02/Sep/2025:02:44:09,"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36",-,172563320,0
log_dispatch,1756752249,oss_access_log,-,-,-,cyp0633-blogasset,oss-cn-qingdao-h,standard,,,46.62.169.27,-,158049,-,-,,-,-,,cyp0633-blogasset.cn-qingdao.oss.aliyuncs.com,GET,200,https,,,true,,,,,,,wild-chicken-university%2Ftianyancha.avif,158049,GetObject,1385315732671155,,,,https://cyp0633-blogasset.cn-qingdao.oss.aliyuncs.com,,68B5E9798F796838331F52B9,676,/wild-chicken-university/tianyancha.avif HTTP/1.1,-,158049,30,-,27,NotSign,,,,,,-,-,02/Sep/2025:02:44:09,"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36",-,172563320,0
log_dispatch,1756752249,oss_access_log,-,-,-,cyp0633-blogasset,oss-cn-qingdao-h,standard,,,46.62.169.27,-,28216,-,-,,-,-,,cyp0633-blogasset.cn-qingdao.oss.aliyuncs.com,GET,200,https,,,true,,,,,,,vmware-ubuntu-12.04%2Faccount.avif,28216,GetObject,1385315732671155,,,,https://cyp0633-blogasset.cn-qingdao.oss.aliyuncs.com,,68B5E9792E174C34349AADA1,669,/vmware-ubuntu-12.04/account.avif HTTP/1.1,-,28216,33,-,32,NotSign,,,,,,-,-,02/Sep/2025:02:44:09,"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36",-,172563320,0
log_dispatch,1756752249,oss_access_log,-,-,-,cyp0633-blogasset,oss-cn-qingdao-h,standard,,,46.62.169.27,-,55299,-,-,,-,-,,cyp0633-blogasset.cn-qingdao.oss.aliyuncs.com,GET,200,https,,,true,,,,,,,windows-11-21996-leaked%2Fstart-menu.avif,55299,GetObject,1385315732671155,,,,https://cyp0633-blogasset.cn-qingdao.oss.aliyuncs.com,,68B5E979AF9A9630396238AC,676,/windows-11-21996-leaked/start-menu.avif HTTP/1.1,-,55299,27,-,26,NotSign,,,,,,-,-,02/Sep/2025:02:44:09,"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36",-,172563320,0
log_dispatch,1756752249,oss_access_log,-,-,-,cyp0633-blogasset,oss-cn-qingdao-h,standard,,,46.62.169.27,-,14143,-,-,,-,-,,cyp0633-blogasset.cn-qingdao.oss.aliyuncs.com,GET,200,https,,,true,,,,,,,windows-11-21996-leaked%2Foobe4.avif,14143,GetObject,1385315732671155,,,,https://cyp0633-blogasset.cn-qingdao.oss.aliyuncs.com,,68B5E979AF9A9635306338AC,671,/windows-11-21996-leaked/oobe4.avif HTTP/1.1,-,14143,33,-,32,NotSign,,,,,,-,-,02/Sep/2025:02:44:09,"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36",-,172563320,0
log_dispatch,1756752249,oss_access_log,-,-,-,cyp0633-blogasset,oss-cn-qingdao-h,standard,,,46.62.169.27,-,20354,-,-,,-,-,,cyp0633-blogasset.cn-qingdao.oss.aliyuncs.com,GET,200,https,,,true,,,,,,,windows-11-21996-leaked%2Fwindows-10-calendar.avif,20354,GetObject,1385315732671155,,,,https://cyp0633-blogasset.cn-qingdao.oss.aliyuncs.com,,68B5E9798D51EC3531998676,685,/windows-11-21996-leaked/windows-10-calendar.avif HTTP/1.1,-,20354,34,-,34,NotSign,,,,,,-,-,02/Sep/2025:02:44:09,"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36",-,172563320,0
log_dispatch,1756752249,oss_access_log,-,-,-,cyp0633-blogasset,oss-cn-qingdao-h,standard,,,46.62.169.27,-,32798,-,-,,-,-,,cyp0633-blogasset.cn-qingdao.oss.aliyuncs.com,GET,200,https,,,true,,,,,,,windows-11-21996-leaked%2Foobe5.avif,32798,GetObject,1385315732671155,,,,https://cyp0633-blogasset.cn-qingdao.oss.aliyuncs.com,,68B5E9798D51EC3230A48676,671,/windows-11-21996-leaked/oobe5.avif HTTP/1.1,-,32798,32,-,30,NotSign,,,,,,-,-,02/Sep/2025:02:44:09,"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36",-,172563320,0
log_dispatch,1756752249,oss_access_log,-,-,-,cyp0633-blogasset,oss-cn-qingdao-h,standard,,,46.62.169.27,-,61159,-,-,,-,-,,cyp0633-blogasset.cn-qingdao.oss.aliyuncs.com,GET,200,https,,,true,,,,,,,windows-11-bugs%2Fwin11bug5.avif,61159,GetObject,1385315732671155,,,,https://cyp0633-blogasset.cn-qingdao.oss.aliyuncs.com,,68B5E979C759F63035B22080,667,/windows-11-bugs/win11bug5.avif HTTP/1.1,-,61159,23,-,18,NotSign,,,,,,-,-,02/Sep/2025:02:44:09,"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36",-,172563320,0
log_dispatch,1756752249,oss_access_log,-,-,-,cyp0633-blogasset,oss-cn-qingdao-h,standard,,,46.62.169.27,-,199772,-,-,,-,-,,cyp0633-blogasset.cn-qingdao.oss.aliyuncs.com,GET,200,https,,,true,,,,,,,nuc-homelab%2Fsiyuan.avif,199772,GetObject,1385315732671155,,,,https://cyp0633-blogasset.cn-qingdao.oss.aliyuncs.com,,68B5E979C70CA13536A34EB1,660,/nuc-homelab/siyuan.avif HTTP/1.1,-,199772,45,-,44,NotSign,,,,,,-,-,02/Sep/2025:02:44:09,"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36",-,172563320,0
log_dispatch,1756752249,oss_access_log,-,-,-,cyp0633-blogasset,oss-cn-qingdao-h,standard,,,46.62.169.27,-,41757,-,-,,-,-,,cyp0633-blogasset.cn-qingdao.oss.aliyuncs.com,GET,200,https,,,true,,,,,,,csapp-bufferlab%2Fstackframe.avif,41757,GetObject,1385315732671155,,,,https://cyp0633-blogasset.cn-qingdao.oss.aliyuncs.com,,68B5E979C70CA13931A94EB1,668,/csapp-bufferlab/stackframe.avif HTTP/1.1,-,41757,67,-,66,NotSign,,,,,,-,-,02/Sep/2025:02:44:09,"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36",-,172563320,0

在开启日志后5天的时间里，OSS总共有10217次访问，而其中：

有一个IP 46.62.169.27猜出了我的Referer白名单，访问了 5571 次，其中最多的一个小时访问了376次；
有至少7个GCP的IP带着Thumbor的User-Agent和空Referer访问了1451次，鉴于我并不用这个软件，应该是被盗图了；
还有一些其他的可疑访问，但数量较少。

为了防止进一步当冤大头，我再次开始了vibe。ChatGPT给我提供了一个方案：利用Netlify Functions给图片签名，一次访问签整个页面的图片，然后用户使用带签名的URL访问OSS。OSS可以设为私有读，从而防止被猜出OSS白名单；签名TTL可以设置得很小，以防止损失过大。以下是基于Hugo完整的代码，虽然全是vibe的，但证明有效。

netlify/functions/sign-oss.js，在Netlify服务器上运行，用于访问阿里服务器进行签名（同时要安装 ali-oss NPM包）：

javascript

'use strict';

const OSS = require('ali-oss');

// Allow all by default for a dedicated bucket; override via OSS_ALLOWED_PREFIXES
const RAW_PREFIXES = process.env.OSS_ALLOWED_PREFIXES;
const ALLOWED_PREFIXES = (RAW_PREFIXES && RAW_PREFIXES.trim().length > 0 ? RAW_PREFIXES : '*')
 .split(',').map(s => s.trim()).filter(Boolean);

function isAllowedKey(key) {
 if (!/^[\w\-./]+$/.test(key)) return false;
 if (ALLOWED_PREFIXES.includes('*')) return true;
 return ALLOWED_PREFIXES.some(p => key.startsWith(p));
}

function parseAllowedOrigins() {
 return (process.env.ALLOWED_ORIGINS || '')
  .split(',')
  .map(s => s.trim())
  .filter(Boolean);
}

const client = new OSS({
 region: process.env.OSS_REGION,
 accessKeyId: process.env.OSS_ACCESS_KEY_ID,
 accessKeySecret: process.env.OSS_ACCESS_KEY_SECRET,
 bucket: process.env.OSS_BUCKET
});

exports.handler = async (event) => {
 try {
  const method = (event.httpMethod || 'GET').toUpperCase();
  const headers = event.headers || {};
  const origin = headers.origin || headers.Origin || '';
  const allowedOrigins = parseAllowedOrigins();
  const acao = allowedOrigins.length ? (allowedOrigins.includes(origin) ? origin : '*') : '*';

  if (method === 'OPTIONS') {
   return {
    statusCode: 204,
    headers: {
     'access-control-allow-origin': acao,
     'access-control-allow-methods': 'GET,POST,OPTIONS',
     'access-control-allow-headers': 'content-type',
     'cache-control': 'private, max-age=60'
    }
   };
  }

  if (method !== 'GET' && method !== 'POST') {
   return { statusCode: 405, body: 'Method Not Allowed' };
  }

  if (allowedOrigins.length && !allowedOrigins.includes(origin)) {
   return { statusCode: 403, body: 'Forbidden', headers: { 'access-control-allow-origin': acao } };
  }

  let keys = [], ttl = 600;
  if (method === 'GET') {
   const qs = event.queryStringParameters || {};
   const rawKeys = qs.keys || '';
   keys = String(rawKeys).split(',').map(s => s.trim()).filter(Boolean);
   ttl = parseInt(qs.ttl || '600', 10);
  } else {
   let bodyObj = {};
   if (event.body) {
    try {
     const text = event.isBase64Encoded ? Buffer.from(event.body, 'base64').toString('utf8') : event.body;
     bodyObj = JSON.parse(text);
    } catch (_) {
     bodyObj = {};
    }
   }
   keys = Array.isArray(bodyObj.keys) ? bodyObj.keys : [];
   ttl = parseInt(bodyObj.ttl ?? 600, 10);
  }

  ttl = Math.min(Math.max(ttl, 30), 3600);
  const sanitized = keys.filter(isAllowedKey);
  if (sanitized.length === 0) {
   return {
    statusCode: 400,
    headers: { 'access-control-allow-origin': acao },
    body: JSON.stringify({ error: 'No valid keys' })
   };
  }

  const now = Math.floor(Date.now() / 1000);
  const urls = await Promise.all(sanitized.map(async (key) => {
   const url = client.signatureUrl(key, { expires: ttl, method: 'GET' });
   return { key, url, exp: now + ttl };
  }));

  return {
   statusCode: 200,
   headers: {
    'content-type': 'application/json; charset=utf-8',
    'cache-control': 'private, max-age=60',
    'access-control-allow-origin': acao,
    'access-control-allow-methods': 'GET,POST,OPTIONS',
    'access-control-allow-headers': 'content-type'
   },
   body: JSON.stringify({ urls })
  };
 } catch (e) {
  return { statusCode: 500, body: JSON.stringify({ error: 'Server error' }) };
 }
};

'use strict';

const OSS = require('ali-oss');

// Allow all by default for a dedicated bucket; override via OSS_ALLOWED_PREFIXES
const RAW_PREFIXES = process.env.OSS_ALLOWED_PREFIXES;
const ALLOWED_PREFIXES = (RAW_PREFIXES && RAW_PREFIXES.trim().length > 0 ? RAW_PREFIXES : '*')
 .split(',').map(s => s.trim()).filter(Boolean);

function isAllowedKey(key) {
 if (!/^[\w\-./]+$/.test(key)) return false;
 if (ALLOWED_PREFIXES.includes('*')) return true;
 return ALLOWED_PREFIXES.some(p => key.startsWith(p));
}

function parseAllowedOrigins() {
 return (process.env.ALLOWED_ORIGINS || '')
  .split(',')
  .map(s => s.trim())
  .filter(Boolean);
}

const client = new OSS({
 region: process.env.OSS_REGION,
 accessKeyId: process.env.OSS_ACCESS_KEY_ID,
 accessKeySecret: process.env.OSS_ACCESS_KEY_SECRET,
 bucket: process.env.OSS_BUCKET
});

exports.handler = async (event) => {
 try {
  const method = (event.httpMethod || 'GET').toUpperCase();
  const headers = event.headers || {};
  const origin = headers.origin || headers.Origin || '';
  const allowedOrigins = parseAllowedOrigins();
  const acao = allowedOrigins.length ? (allowedOrigins.includes(origin) ? origin : '*') : '*';

  if (method === 'OPTIONS') {
   return {
    statusCode: 204,
    headers: {
     'access-control-allow-origin': acao,
     'access-control-allow-methods': 'GET,POST,OPTIONS',
     'access-control-allow-headers': 'content-type',
     'cache-control': 'private, max-age=60'
    }
   };
  }

  if (method !== 'GET' && method !== 'POST') {
   return { statusCode: 405, body: 'Method Not Allowed' };
  }

  if (allowedOrigins.length && !allowedOrigins.includes(origin)) {
   return { statusCode: 403, body: 'Forbidden', headers: { 'access-control-allow-origin': acao } };
  }

  let keys = [], ttl = 600;
  if (method === 'GET') {
   const qs = event.queryStringParameters || {};
   const rawKeys = qs.keys || '';
   keys = String(rawKeys).split(',').map(s => s.trim()).filter(Boolean);
   ttl = parseInt(qs.ttl || '600', 10);
  } else {
   let bodyObj = {};
   if (event.body) {
    try {
     const text = event.isBase64Encoded ? Buffer.from(event.body, 'base64').toString('utf8') : event.body;
     bodyObj = JSON.parse(text);
    } catch (_) {
     bodyObj = {};
    }
   }
   keys = Array.isArray(bodyObj.keys) ? bodyObj.keys : [];
   ttl = parseInt(bodyObj.ttl ?? 600, 10);
  }

  ttl = Math.min(Math.max(ttl, 30), 3600);
  const sanitized = keys.filter(isAllowedKey);
  if (sanitized.length === 0) {
   return {
    statusCode: 400,
    headers: { 'access-control-allow-origin': acao },
    body: JSON.stringify({ error: 'No valid keys' })
   };
  }

  const now = Math.floor(Date.now() / 1000);
  const urls = await Promise.all(sanitized.map(async (key) => {
   const url = client.signatureUrl(key, { expires: ttl, method: 'GET' });
   return { key, url, exp: now + ttl };
  }));

  return {
   statusCode: 200,
   headers: {
    'content-type': 'application/json; charset=utf-8',
    'cache-control': 'private, max-age=60',
    'access-control-allow-origin': acao,
    'access-control-allow-methods': 'GET,POST,OPTIONS',
    'access-control-allow-headers': 'content-type'
   },
   body: JSON.stringify({ urls })
  };
 } catch (e) {
  return { statusCode: 500, body: JSON.stringify({ error: 'Server error' }) };
 }
};

netlify.toml 添加配置，指定函数目录：

toml

[build]
  functions = "netlify/functions"

[functions]
  node_bundler = "esbuild"

config.toml，定义OSS前缀链接：

toml

[params.oss]
hosts = [
  "https://cyp0633-blogasset.oss-cn-qingdao.aliyuncs.com/",
  "https://cyp0633-blogasset.cn-qingdao.oss.aliyuncs.com/"
]

layouts/_default/_markup/render-image.html，将具有上述前缀的链接替换为 data-oss-key：

html

{{- /*
 Override: detect OSS remote images and emit data-oss-key for client signing,
 other images fall back to theme default behavior.
*/ -}}
{{- $dest := .Destination | safeURL -}}
{{- $alt := .PlainText | safeHTML -}}

{{- /* Determine if remote and hosted on OSS */ -}}
{{- $isRemote := or (hasPrefix $dest "http://") (hasPrefix $dest "https://") -}}
{{- $ossHosts := site.Params.oss.hosts | default (slice) -}}
{{- $matchOss := false -}}
{{- if $isRemote -}}
 {{- if gt (len $ossHosts) 0 -}}
  {{- range $ossHosts -}}
   {{- if hasPrefix $dest . -}}
    {{- $matchOss = true -}}
   {{- end -}}
  {{- end -}}
 {{- else -}}
  {{- /* Fallback: aliyun OSS domain heuristic (aliyuncs.com and aliyun.com) */ -}}
  {{- if or (findRE `^https?://[^/]*(aliyuncs\.com)/` $dest) (findRE `^https?://[^/]*(aliyun\.com)/` $dest) -}}
   {{- $matchOss = true -}}
  {{- end -}}
 {{- end -}}
{{- end -}}

{{- if and $isRemote $matchOss -}}
 {{- /* Extract object key (path without leading slash) */ -}}
 {{- $key := (replaceRE `^https?://[^/]*/` `` $dest) -}}
 {{- $key = (replaceRE `^/` `` $key) -}}
 {{- $placeholder := `data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///ywAAAAAAQABAAACAUwAOw==` -}}
 <figure style="max-width: 80%; margin: auto;">
  <img data-oss-key="{{ $key }}" src="{{ $placeholder | safeURL }}" loading="lazy" {{ with $alt }} alt="{{ . }}" {{ end }}
   style="width: 100%; height: auto; max-height: 70vh; object-fit: contain;">
  {{ if .Title }}
  <figcaption>{{ .Title | markdownify }}</figcaption>
  {{ end }}
 </figure>
{{- else -}}
 {{- /* Default theme behavior for local or non-OSS remote images */ -}}
 {{- $image := .Page.Resources.GetMatch (printf "%s" (.Destination | safeURL)) -}}
 {{- $Permalink := .Destination | relURL | safeURL -}}
 <figure style="max-width: 80%; margin: auto;">
  <img src="{{ $Permalink }}" loading="lazy" {{ with $alt }} alt="{{ . }}" {{ end }}
   style="width: 100%; height: auto; max-height: 70vh; object-fit: contain;">
  {{ if .Title }}
  <figcaption>{{ .Title | markdownify }}</figcaption>
  {{ end }}
 </figure>
{{- end -}}

{{- /*
 Override: detect OSS remote images and emit data-oss-key for client signing,
 other images fall back to theme default behavior.
*/ -}}
{{- $dest := .Destination | safeURL -}}
{{- $alt := .PlainText | safeHTML -}}

{{- /* Determine if remote and hosted on OSS */ -}}
{{- $isRemote := or (hasPrefix $dest "http://") (hasPrefix $dest "https://") -}}
{{- $ossHosts := site.Params.oss.hosts | default (slice) -}}
{{- $matchOss := false -}}
{{- if $isRemote -}}
 {{- if gt (len $ossHosts) 0 -}}
  {{- range $ossHosts -}}
   {{- if hasPrefix $dest . -}}
    {{- $matchOss = true -}}
   {{- end -}}
  {{- end -}}
 {{- else -}}
  {{- /* Fallback: aliyun OSS domain heuristic (aliyuncs.com and aliyun.com) */ -}}
  {{- if or (findRE `^https?://[^/]*(aliyuncs\.com)/` $dest) (findRE `^https?://[^/]*(aliyun\.com)/` $dest) -}}
   {{- $matchOss = true -}}
  {{- end -}}
 {{- end -}}
{{- end -}}

{{- if and $isRemote $matchOss -}}
 {{- /* Extract object key (path without leading slash) */ -}}
 {{- $key := (replaceRE `^https?://[^/]*/` `` $dest) -}}
 {{- $key = (replaceRE `^/` `` $key) -}}
 {{- $placeholder := `data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///ywAAAAAAQABAAACAUwAOw==` -}}
 <figure style="max-width: 80%; margin: auto;">
  <img data-oss-key="{{ $key }}" src="{{ $placeholder | safeURL }}" loading="lazy" {{ with $alt }} alt="{{ . }}" {{ end }}
   style="width: 100%; height: auto; max-height: 70vh; object-fit: contain;">
  {{ if .Title }}
  <figcaption>{{ .Title | markdownify }}</figcaption>
  {{ end }}
 </figure>
{{- else -}}
 {{- /* Default theme behavior for local or non-OSS remote images */ -}}
 {{- $image := .Page.Resources.GetMatch (printf "%s" (.Destination | safeURL)) -}}
 {{- $Permalink := .Destination | relURL | safeURL -}}
 <figure style="max-width: 80%; margin: auto;">
  <img src="{{ $Permalink }}" loading="lazy" {{ with $alt }} alt="{{ . }}" {{ end }}
   style="width: 100%; height: auto; max-height: 70vh; object-fit: contain;">
  {{ if .Title }}
  <figcaption>{{ .Title | markdownify }}</figcaption>
  {{ end }}
 </figure>
{{- end -}}

assets/ts/custom.ts，用于收集 data-oss-key 请求签名：

typescript

type SignedEntry = { key: string; url: string; exp: number };

function collectOssKeys(): string[] {
 const imgs = Array.from(document.querySelectorAll<HTMLImageElement>('img[data-oss-key]'));
 const keys = imgs
  .map((img) => img.dataset.ossKey || '')
  .filter((k) => k.length > 0);
 return Array.from(new Set(keys));
}

async function fetchSignedUrls(keys: string[], ttlSeconds = 600): Promise<Map<string, string>> {
 const endpoint = '/.netlify/functions/sign-oss';
 const url = `${endpoint}?ttl=${encodeURIComponent(String(ttlSeconds))}&keys=${encodeURIComponent(keys.join(','))}`;
 const res = await fetch(url, { credentials: 'omit', cache: 'no-store' });
 if (!res.ok) return new Map();
 const data = (await res.json()) as { urls?: SignedEntry[] };
 const map = new Map<string, string>();
 (data.urls || []).forEach((u) => {
  if (u && u.key && u.url) map.set(u.key, u.url);
 });
 return map;
}

function applySignedUrls(map: Map<string, string>): void {
 document.querySelectorAll<HTMLImageElement>('img[data-oss-key]').forEach((img) => {
  const key = img.dataset.ossKey || '';
  const signed = key ? map.get(key) : undefined;
  if (signed) {
   img.src = signed;
   img.removeAttribute('data-oss-key');
  }
 });
}

async function initOssSigning(): Promise<void> {
 const keys = collectOssKeys();
 if (keys.length === 0) return;
 try {
  const map = await fetchSignedUrls(keys, 600);
  applySignedUrls(map);
 } catch {
  // no-op
 }
}

if (document.readyState === 'loading') {
 document.addEventListener('DOMContentLoaded', () => {
  void initOssSigning();
 });
} else {
 void initOssSigning();
}

另外还需要在Netlify上设置环境变量：

ALLOWED_PREFIXES：如果所有图片都在同一个目录下可以使用；
OSS_REGION：OSS地域，例如 oss-cn-qingdao；
OSS_BUCKET：OSS Bucket名称，例如 cyp0633-blogasset；
OSS_ACCESS_KEY_ID 和 OSS_ACCESS_KEY_SECRET：访问密钥。

就行了。构建时Hugo会自动将OSS链接替换为key，只能在访问时签名，签名只能用于特定的文件，且有效期有限；即使key特征明显，也无法直接访问OSS。

在部署这个方案之后，收到的成效非常显著：

46.62.169.27再也没有出现过；
盗图的Thumbor也没有再出现过；
搜索引擎索引（包括Bingbot、Googlebot、ChatGPT搜索和Petalbot等）正常访问。

按小时的访问量统计

Top IP 访问量统计

不出意外的话，你也能访问这个页面的图片内容，如果不能的话，请你在评论区留言，除非你的评论区也加载不出来：）

超级分布式Gitea爬虫

其实大家都知道上面的办法治标不治本，我也知道。8月针对爬取Gitea的办法是屏蔽网段+挂CF，而一旦网段这个简单的特征被稀释，或者说爬取者找到了足够大的IP池，这个办法就不会有任何效果了。而对于大的AI训练者来说，他们最不缺的就是钱——起码与几万张B200相比，几台VPS根本不算什么。

于是在10月末，我又收到了这样的日志：

json

{"level":"info","ts":1761649310.1998942,"logger":"http.log.access.log1","msg":"handled request","request":{"remote_ip":"172.70.42.189","remote_port":"11100","client_ip":"172.70.42.189","proto":"HTTP/2.0","method":"GET","host":"git.cyp0633.icu","uri":"/cyp0633/stack-mod/raw/commit/028ae12ea56077fb630bbf12ed46781db583fe2a/layouts/_default/baseof.html","headers":{"User-Agent":["Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/134.0.0.0 Safari/537.36 Edg/134.0.0.0"],"Accept-Language":["en-US,en;q=0.5"],"Referrer":["https://www.google.com/"],"Cf-Visitor":["{\"scheme\":\"https\"}"],"X-Forwarded-For":["23.239.187.90"],"Accept":["text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8"],"Cdn-Loop":["cloudflare; loops=1"],"X-Forwarded-Proto":["https"],"Cf-Connecting-Ip":["23.239.187.90"],"Cf-Ipcountry":["US"],"Accept-Encoding":["gzip, br"],"Cf-Ray":["9959effb9b4a057f-IAD"]},"tls":{"resumed":false,"version":772,"cipher_suite":4865,"proto":"h2","server_name":"git.cyp0633.icu"}},"bytes_read":0,"user_id":"","duration":0.065625343,"size":352,"status":200,"resp_headers":{"Alt-Svc":["h3=\":443\"; ma=2592000"],"Last-Modified":["Thu, 24 Dec 2020 10:06:58 GMT"],"X-Frame-Options":["SAMEORIGIN"],"Cache-Control":["private, max-age=300"],"Content-Disposition":["inline; filename=\"baseof.html\"; filename*=UTF-8''baseof.html"],"Content-Encoding":["gzip"],"Date":["Tue, 28 Oct 2025 11:01:50 GMT"],"Access-Control-Expose-Headers":["Content-Disposition"],"Content-Type":["text/plain; charset=utf-8"],"Server":["Caddy"],"Set-Cookie":["REDACTED"],"X-Content-Type-Options":["nosniff"],"Etag":["\"ce0ddae104d973c67c938411e1c9fc19c4f383ef-gzip\""],"Vary":["Accept-Encoding"]}}
{"level":"info","ts":1761649310.2023957,"logger":"http.log.access.log1","msg":"handled request","request":{"remote_ip":"162.158.79.51","remote_port":"11567","client_ip":"162.158.79.51","proto":"HTTP/2.0","method":"GET","host":"git.cyp0633.icu","uri":"/cyp0633/ns3-datacenter/commits/commit/dc680c3cf9a4de64facbb20355ae718e1a51adbb/simulator/bake","headers":{"Cf-Visitor":["{\"scheme\":\"https\"}"],"User-Agent":["Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/107.0.0.0 Safari/537.3"],"Accept-Encoding":["gzip, br"],"Cf-Ray":["9959effb9a9cd679-IAD"],"Accept":["text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8"],"Cdn-Loop":["cloudflare; loops=1"],"Cf-Connecting-Ip":["45.41.164.103"],"X-Forwarded-For":["45.41.164.103"],"Cf-Ipcountry":["US"],"Accept-Language":["en-US,en;q=0.5"],"Referrer":["https://www.google.com/"],"X-Forwarded-Proto":["https"]},"tls":{"resumed":false,"version":772,"cipher_suite":4865,"proto":"h2","server_name":"git.cyp0633.icu"}},"bytes_read":0,"user_id":"","duration":0.071713334,"size":26876,"status":200,"resp_headers":{"Date":["Tue, 28 Oct 2025 11:01:50 GMT"],"Cache-Control":["max-age=0, private, must-revalidate, no-transform"],"Content-Type":["text/html; charset=utf-8"],"Server":["Caddy"],"Alt-Svc":["h3=\":443\"; ma=2592000"],"Set-Cookie":["REDACTED"],"X-Frame-Options":["SAMEORIGIN"]}}
{"level":"info","ts":1761649310.2423117,"logger":"http.log.access.log1","msg":"handled request","request":{"remote_ip":"172.71.166.230","remote_port":"11416","client_ip":"172.71.166.230","proto":"HTTP/2.0","method":"GET","host":"git.cyp0633.icu","uri":"/cyp0633/compiler-lab/raw/commit/f9764c54da2bf5ed944b69de05030d407fd32a16/lab1/convert_test.go","headers":{"Cf-Visitor":["{\"scheme\":\"https\"}"],"Accept-Language":["en-US,en;q=0.5"],"Cf-Connecting-Ip":["140.99.218.213"],"Cf-Ipcountry":["MX"],"User-Agent":["Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/113.0.0.0 Safari/537.3"],"Referrer":["https://www.google.com/"],"Cf-Ray":["9959effbef97379d-DFW"],"Cdn-Loop":["cloudflare; loops=1"],"X-Forwarded-For":["140.99.218.213"],"Accept-Encoding":["gzip, br"],"Accept":["text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8"],"X-Forwarded-Proto":["https"]},"tls":{"resumed":false,"version":772,"cipher_suite":4865,"proto":"h2","server_name":"git.cyp0633.icu"}},"bytes_read":0,"user_id":"","duration":0.088202332,"size":1103,"status":200,"resp_headers":{"Alt-Svc":["h3=\":443\"; ma=2592000"],"X-Frame-Options":["SAMEORIGIN"],"Cache-Control":["private, max-age=300"],"Last-Modified":["Sat, 25 Mar 2023 02:59:49 GMT"],"Content-Disposition":["inline; filename=\"convert_test.go\"; filename*=UTF-8''convert_test.go"],"Etag":["\"b4da01f8edc68fb19d2ea64add3fb0cdf169de00-gzip\""],"X-Content-Type-Options":["nosniff"],"Access-Control-Expose-Headers":["Content-Disposition"],"Date":["Tue, 28 Oct 2025 11:01:50 GMT"],"Set-Cookie":["REDACTED"],"Server":["Caddy"],"Content-Type":["text/plain; charset=utf-8"],"Content-Encoding":["gzip"],"Vary":["Accept-Encoding"]}}
{"level":"info","ts":1761649310.269168,"logger":"http.log.access.log1","msg":"handled request","request":{"remote_ip":"172.71.210.233","remote_port":"10408","client_ip":"172.71.210.233","proto":"HTTP/2.0","method":"GET","host":"git.cyp0633.icu","uri":"/cyp0633/stack-mod/rss/commit/92a6d71ce5d49583a8ad6ac0819cdbef740e6fe4/exampleSite/README.md","headers":{"Cf-Connecting-Ip":["75.102.28.121"],"User-Agent":["Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.0.0 Safari/537.3"],"Accept-Language":["en-US,en;q=0.5"],"Accept":["text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8"],"Cdn-Loop":["cloudflare; loops=1"],"Referrer":["https://www.google.com/"],"Cf-Ray":["9959effd19159b4a-HKG"],"X-Forwarded-Proto":["https"],"Cf-Ipcountry":["JP"],"Cf-Visitor":["{\"scheme\":\"https\"}"],"X-Forwarded-For":["75.102.28.121"],"Accept-Encoding":["gzip, br"]},"tls":{"resumed":false,"version":772,"cipher_suite":4865,"proto":"h2","server_name":"git.cyp0633.icu"}},"bytes_read":0,"user_id":"","duration":0.00977558,"size":9325,"status":404,"resp_headers":{"Set-Cookie":["REDACTED"],"X-Frame-Options":["SAMEORIGIN"],"Date":["Tue, 28 Oct 2025 11:01:50 GMT"],"Cache-Control":["max-age=0, private, must-revalidate, no-transform"],"Server":["Caddy"],"Alt-Svc":["h3=\":443\"; ma=2592000"],"Content-Type":["text/html; charset=utf-8"]}}
{"level":"info","ts":1761649310.327542,"logger":"http.log.access.log1","msg":"handled request","request":{"remote_ip":"172.71.166.230","remote_port":"11416","client_ip":"172.71.166.230","proto":"HTTP/2.0","method":"GET","host":"git.cyp0633.icu","uri":"/cyp0633/stack-mod/rss/commit/57bfea833850e0565cf81d9a26c52359427151a2/archetypes/tags.md","headers":{"Accept-Encoding":["gzip, br"],"Referrer":["https://www.google.com/"],"Cdn-Loop":["cloudflare; loops=1"],"Cf-Connecting-Ip":["23.230.234.184"],"Cf-Ipcountry":["US"],"X-Forwarded-For":["23.230.234.184"],"Accept-Language":["en-US,en;q=0.5"],"Cf-Ray":["9959effcdcf3e956-DFW"],"Cf-Visitor":["{\"scheme\":\"https\"}"],"Accept":["text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8"],"X-Forwarded-Proto":["https"],"User-Agent":["Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/134.0.0.0 Safari/537.36 Trailer/93.3.8652.5"]},"tls":{"resumed":false,"version":772,"cipher_suite":4865,"proto":"h2","server_name":"git.cyp0633.icu"}},"bytes_read":0,"user_id":"","duration":0.013796775,"size":9322,"status":404,"resp_headers":{"X-Frame-Options":["SAMEORIGIN"],"Date":["Tue, 28 Oct 2025 11:01:50 GMT"],"Server":["Caddy"],"Alt-Svc":["h3=\":443\"; ma=2592000"],"Cache-Control":["max-age=0, private, must-revalidate, no-transform"],"Content-Type":["text/html; charset=utf-8"],"Set-Cookie":["REDACTED"]}}
{"level":"info","ts":1761649310.4023278,"logger":"http.log.access.log1","msg":"handled request","request":{"remote_ip":"172.70.115.160","remote_port":"10314","client_ip":"172.70.115.160","proto":"HTTP/2.0","method":"GET","host":"git.cyp0633.icu","uri":"/cyp0633/ns3-datacenter/src/commit/f92fef3b51b8354ae8941280a43a2554c9646017/simulator/pybindgen-0.22.0/tox.ini","headers":{"Cdn-Loop":["cloudflare; loops=1"],"Cf-Connecting-Ip":["213.201.198.112"],"Cf-Visitor":["{\"scheme\":\"https\"}"],"Accept-Encoding":["gzip, br"],"Accept":["text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8"],"User-Agent":["Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/134.0.0.0 Safari/537.3"],"Referrer":["https://www.google.com/"],"X-Forwarded-For":["213.201.198.112"],"Accept-Language":["en-US,en;q=0.5"],"X-Forwarded-Proto":["https"],"Cf-Ray":["9959effbbf96dd82-EWR"],"Cf-Ipcountry":["US"]},"tls":{"resumed":false,"version":772,"cipher_suite":4865,"proto":"h2","server_name":"git.cyp0633.icu"}},"bytes_read":0,"user_id":"","duration":0.26401861,"size":30170,"status":200,"resp_headers":{"Server":["Caddy"],"Alt-Svc":["h3=\":443\"; ma=2592000"],"Cache-Control":["max-age=0, private, must-revalidate, no-transform"],"Content-Type":["text/html; charset=utf-8"],"Set-Cookie":["REDACTED"],"X-Frame-Options":["SAMEORIGIN"],"Date":["Tue, 28 Oct 2025 11:01:50 GMT"]}}
{"level":"info","ts":1761649310.4635193,"logger":"http.log.access.log1","msg":"handled request","request":{"remote_ip":"172.70.38.6","remote_port":"14185","client_ip":"172.70.38.6","proto":"HTTP/2.0","method":"GET","host":"git.cyp0633.icu","uri":"/cyp0633/ModelComputer/commits/commit/8f16f8e97d493fd4683831f95cd8825f4ea9f760/ALU","headers":{"Accept-Encoding":["gzip, br"],"Accept":["text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8"],"Cf-Connecting-Ip":["23.226.223.128"],"Cf-Visitor":["{\"scheme\":\"https\"}"],"Accept-Language":["en-US,en;q=0.5"],"Cf-Ray":["9959effc7d1c392b-IAD"],"Cdn-Loop":["cloudflare; loops=1"],"X-Forwarded-For":["23.226.223.128"],"User-Agent":["Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/107.0.0.0 Safari/537.3"],"Referrer":["https://www.google.com/"],"X-Forwarded-Proto":["https"],"Cf-Ipcountry":["US"]},"tls":{"resumed":false,"version":772,"cipher_suite":4865,"proto":"h2","server_name":"git.cyp0633.icu"}},"bytes_read":0,"user_id":"","duration":0.195946316,"size":26304,"status":200,"resp_headers":{"Server":["Caddy"],"Alt-Svc":["h3=\":443\"; ma=2592000"],"Set-Cookie":["REDACTED"],"X-Frame-Options":["SAMEORIGIN"],"Date":["Tue, 28 Oct 2025 11:01:50 GMT"],"Cache-Control":["max-age=0, private, must-revalidate, no-transform"],"Content-Type":["text/html; charset=utf-8"]}}
{"level":"info","ts":1761649310.4655995,"logger":"http.log.access.log1","msg":"handled request","request":{"remote_ip":"172.71.194.111","remote_port":"14185","client_ip":"172.71.194.111","proto":"HTTP/2.0","method":"GET","host":"git.cyp0633.icu","uri":"/cyp0633/stack-mod/src/commit/c41a3e0621b51c831804502d761b2ddd370ccd38/layouts/index.html","headers":{"Referrer":["https://www.google.com/"],"Accept-Language":["en-US,en;q=0.5"],"X-Forwarded-Proto":["https"],"User-Agent":["Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/132.0.0.0 Safari/537.36 OPR/117.0.0.0"],"X-Forwarded-For":["89.116.14.139"],"Cf-Ray":["9959effc0c1cd6e8-IAD"],"Cf-Connecting-Ip":["89.116.14.139"],"Cf-Visitor":["{\"scheme\":\"https\"}"],"Accept-Encoding":["gzip, br"],"Accept":["text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8"],"Cdn-Loop":["cloudflare; loops=1"],"Cf-Ipcountry":["US"]},"tls":{"resumed":false,"version":772,"cipher_suite":4865,"proto":"h2","server_name":"git.cyp0633.icu"}},"bytes_read":0,"user_id":"","duration":0.262741163,"size":32454,"status":200,"resp_headers":{"Set-Cookie":["REDACTED"],"X-Frame-Options":["SAMEORIGIN"],"Date":["Tue, 28 Oct 2025 11:01:50 GMT"],"Server":["Caddy"],"Alt-Svc":["h3=\":443\"; ma=2592000"],"Cache-Control":["max-age=0, private, must-revalidate, no-transform"],"Content-Type":["text/html; charset=utf-8"]}}
{"level":"info","ts":1761649310.472112,"logger":"http.log.access.log1","msg":"handled request","request":{"remote_ip":"162.158.175.131","remote_port":"11188","client_ip":"162.158.175.131","proto":"HTTP/2.0","method":"GET","host":"git.cyp0633.icu","uri":"/cyp0633/ns3-datacenter/src/commit/281afc20f5e6a6ba20a13cab31e730a435959050/simulator/ns-3.39/.vscode/tasks.json","headers":{"Referrer":["https://www.google.com/"],"Cf-Visitor":["{\"scheme\":\"https\"}"],"Cf-Connecting-Ip":["45.56.186.71"],"Accept-Encoding":["gzip, br"],"Cf-Ray":["9959effbb9ee4796-DFW"],"X-Forwarded-Proto":["https"],"Accept-Language":["en-US,en;q=0.5"],"User-Agent":["Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/107.0.0.0 Safari/537.3"],"Accept":["text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8"],"Cdn-Loop":["cloudflare; loops=1"],"Cf-Ipcountry":["US"],"X-Forwarded-For":["45.56.186.71"]},"tls":{"resumed":false,"version":772,"cipher_suite":4865,"proto":"h2","server_name":"git.cyp0633.icu"}},"bytes_read":0,"user_id":"","duration":0.342308283,"size":35925,"status":200,"resp_headers":{"Server":["Caddy"],"Alt-Svc":["h3=\":443\"; ma=2592000"],"Cache-Control":["max-age=0, private, must-revalidate, no-transform"],"Content-Type":["text/html; charset=utf-8"],"Set-Cookie":["REDACTED"],"X-Frame-Options":["SAMEORIGIN"],"Date":["Tue, 28 Oct 2025 11:01:50 GMT"]}}
{"level":"info","ts":1761649310.4908528,"logger":"http.log.access.log1","msg":"handled request","request":{"remote_ip":"172.69.22.17","remote_port":"12062","client_ip":"172.69.22.17","proto":"HTTP/2.0","method":"GET","host":"git.cyp0633.icu","uri":"/cyp0633/ns3-datacenter/src/commit/40b84300cf5bc6b41953239419aa8b9022a793d4/simulator/ns-3.35/bindings/python/ns__init__.py","headers":{"Referrer":["https://www.google.com/"],"Accept":["text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8"],"Cdn-Loop":["cloudflare; loops=1"],"Accept-Encoding":["gzip, br"],"X-Forwarded-Proto":["https"],"Cf-Ray":["9959effbeaef15e1-SJC"],"Cf-Ipcountry":["US"],"X-Forwarded-For":["166.0.180.40"],"User-Agent":["Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.10 Safari/605.1.1"],"Cf-Visitor":["{\"scheme\":\"https\"}"],"Accept-Language":["en-US,en;q=0.5"],"Cf-Connecting-Ip":["166.0.180.40"]},"tls":{"resumed":false,"version":772,"cipher_suite":4865,"proto":"h2","server_name":"git.cyp0633.icu"}},"bytes_read":0,"user_id":"","duration":0.341574757,"size":28822,"status":200,"resp_headers":{"Server":["Caddy"],"Alt-Svc":["h3=\":443\"; ma=2592000"],"Cache-Control":["max-age=0, private, must-revalidate, no-transform"],"Content-Type":["text/html; charset=utf-8"],"Set-Cookie":["REDACTED"],"X-Frame-Options":["SAMEORIGIN"],"Date":["Tue, 28 Oct 2025 11:01:50 GMT"]}}
{"level":"info","ts":1761649310.4981875,"logger":"http.log.access.log1","msg":"handled request","request":{"remote_ip":"172.71.191.124","remote_port":"12844","client_ip":"172.71.191.124","proto":"HTTP/2.0","method":"GET","host":"git.cyp0633.icu","uri":"/cyp0633/stack-mod/blame/commit/a5986b92fdd601bd8b9e6907b01750bf9fbde741/layouts/_default/single.html","headers":{"User-Agent":["Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.10 Safari/605.1.1"],"Accept-Language":["en-US,en;q=0.5"],"X-Forwarded-Proto":["https"],"Cf-Connecting-Ip":["104.194.220.229"],"Cf-Visitor":["{\"scheme\":\"https\"}"],"X-Forwarded-For":["104.194.220.229"],"Cf-Ray":["9959effbfb0be639-IAD"],"Cdn-Loop":["cloudflare; loops=1"],"Accept-Encoding":["gzip, br"],"Accept":["text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8"],"Cf-Ipcountry":["US"],"Referrer":["https://www.google.com/"]},"tls":{"resumed":false,"version":772,"cipher_suite":4865,"proto":"h2","server_name":"git.cyp0633.icu"}},"bytes_read":0,"user_id":"","duration":0.297898894,"size":86599,"status":200,"resp_headers":{"Set-Cookie":["REDACTED"],"X-Frame-Options":["SAMEORIGIN"],"Server":["Caddy"],"Alt-Svc":["h3=\":443\"; ma=2592000"],"Date":["Tue, 28 Oct 2025 11:01:50 GMT"],"Cache-Control":["max-age=0, private, must-revalidate, no-transform"],"Content-Type":["text/html; charset=utf-8"]}}
{"level":"info","ts":1761649310.509331,"logger":"http.log.access.log1","msg":"handled request","request":{"remote_ip":"162.158.122.174","remote_port":"10970","client_ip":"162.158.122.174","proto":"HTTP/2.0","method":"GET","host":"git.cyp0633.icu","uri":"/cyp0633/stack-mod/src/commit/34cd7852bc115f926b131e99c6384609d048f28f/layouts/partials/pagination.html","headers":{"Referrer":["https://www.google.com/"],"Cdn-Loop":["cloudflare; loops=1"],"Cf-Visitor":["{\"scheme\":\"https\"}"],"X-Forwarded-For":["45.157.185.71"],"Accept-Language":["en-US,en;q=0.5"],"Accept-Encoding":["gzip, br"],"Cf-Ray":["9959effc4a4acbb6-MAD"],"Cf-Ipcountry":["ES"],"User-Agent":["Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/107.0.0.0 Safari/537.3"],"Accept":["text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8"],"X-Forwarded-Proto":["https"],"Cf-Connecting-Ip":["45.157.185.71"]},"tls":{"resumed":false,"version":772,"cipher_suite":4865,"proto":"h2","server_name":"git.cyp0633.icu"}},"bytes_read":0,"user_id":"","duration":0.291499759,"size":36375,"status":200,"resp_headers":{"Server":["Caddy"],"Alt-Svc":["h3=\":443\"; ma=2592000"],"X-Frame-Options":["SAMEORIGIN"],"Date":["Tue, 28 Oct 2025 11:01:50 GMT"],"Cache-Control":["max-age=0, private, must-revalidate, no-transform"],"Content-Type":["text/html; charset=utf-8"],"Set-Cookie":["REDACTED"]}}
{"level":"info","ts":1761649310.5167801,"logger":"http.log.access.log1","msg":"handled request","request":{"remote_ip":"172.71.23.49","remote_port":"10556","client_ip":"172.71.23.49","proto":"HTTP/2.0","method":"GET","host":"git.cyp0633.icu","uri":"/cyp0633/NanaMail-android/src/commit/59c843537d84d1c6737d5d71a708b459ab53cf98/.idea/gradle.xml","headers":{"Cf-Ipcountry":["US"],"Cf-Connecting-Ip":["85.254.125.48"],"X-Forwarded-For":["85.254.125.48"],"Accept-Language":["en-US,en;q=0.5"],"Referrer":["https://www.google.com/"],"Cf-Ray":["9959effc2e95afbf-ATL"],"User-Agent":["Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.0.0 Safari/537.3"],"Accept-Encoding":["gzip, br"],"Cf-Visitor":["{\"scheme\":\"https\"}"],"Cdn-Loop":["cloudflare; loops=1"],"Accept":["text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8"],"X-Forwarded-Proto":["https"]},"tls":{"resumed":false,"version":772,"cipher_suite":4865,"proto":"h2","server_name":"git.cyp0633.icu"}},"bytes_read":0,"user_id":"","duration":0.298081216,"size":34775,"status":200,"resp_headers":{"Date":["Tue, 28 Oct 2025 11:01:50 GMT"],"Server":["Caddy"],"Alt-Svc":["h3=\":443\"; ma=2592000"],"Cache-Control":["max-age=0, private, must-revalidate, no-transform"],"Content-Type":["text/html; charset=utf-8"],"Set-Cookie":["REDACTED"],"X-Frame-Options":["SAMEORIGIN"]}}
{"level":"info","ts":1761649310.5189972,"logger":"http.log.access.log1","msg":"handled request","request":{"remote_ip":"172.68.234.49","remote_port":"11517","client_ip":"172.68.234.49","proto":"HTTP/2.0","method":"GET","host":"git.cyp0633.icu","uri":"/cyp0633/ostep-homework/commits/commit/375d19ba4b693a0f70f7632b82729fb212471564/threads-locks/test-and-set.s","headers":{"Cdn-Loop":["cloudflare; loops=1"],"User-Agent":["Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/107.0.0.0 Safari/537.3"],"Cf-Ray":["9959effd0f4de1cd-MRS"],"Accept":["text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8"],"Referrer":["https://www.google.com/"],"Cf-Ipcountry":["IN"],"X-Forwarded-For":["110.44.2.253"],"X-Forwarded-Proto":["https"],"Cf-Visitor":["{\"scheme\":\"https\"}"],"Cf-Connecting-Ip":["110.44.2.253"],"Accept-Language":["en-US,en;q=0.5"],"Accept-Encoding":["gzip, br"]},"tls":{"resumed":false,"version":772,"cipher_suite":4865,"proto":"h2","server_name":"git.cyp0633.icu"}},"bytes_read":0,"user_id":"","duration":0.195997813,"size":26607,"status":200,"resp_headers":{"Set-Cookie":["REDACTED"],"X-Frame-Options":["SAMEORIGIN"],"Date":["Tue, 28 Oct 2025 11:01:50 GMT"],"Server":["Caddy"],"Alt-Svc":["h3=\":443\"; ma=2592000"],"Cache-Control":["max-age=0, private, must-revalidate, no-transform"],"Content-Type":["text/html; charset=utf-8"]}}
{"level":"info","ts":1761649310.554788,"logger":"http.log.access.log1","msg":"handled request","request":{"remote_ip":"104.23.190.253","remote_port":"10096","client_ip":"104.23.190.253","proto":"HTTP/2.0","method":"GET","host":"git.cyp0633.icu","uri":"/cyp0633/ns3-datacenter/src/commit/cbf82ca5c485aa25a521641d98f7057869b65c98/simulator/netanim-3.109/qtpropertybrowser/src/QtCheckBoxFactory","headers":{"User-Agent":["Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/107.0.0.0 Safari/537.3"],"Cf-Visitor":["{\"scheme\":\"https\"}"],"Cf-Ray":["9959effc08b82732-EWR"],"Cdn-Loop":["cloudflare; loops=1"],"X-Forwarded-Proto":["https"],"Accept":["text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8"],"Cf-Ipcountry":["US"],"X-Forwarded-For":["84.37.134.1"],"Accept-Language":["en-US,en;q=0.5"],"Accept-Encoding":["gzip, br"],"Referrer":["https://www.google.com/"],"Cf-Connecting-Ip":["84.37.134.1"]},"tls":{"resumed":false,"version":772,"cipher_suite":4865,"proto":"h2","server_name":"git.cyp0633.icu"}},"bytes_read":0,"user_id":"","duration":0.362997391,"size":29091,"status":200,"resp_headers":{"Content-Type":["text/html; charset=utf-8"],"Set-Cookie":["REDACTED"],"Server":["Caddy"],"Alt-Svc":["h3=\":443\"; ma=2592000"],"X-Frame-Options":["SAMEORIGIN"],"Date":["Tue, 28 Oct 2025 11:01:50 GMT"],"Cache-Control":["max-age=0, private, must-revalidate, no-transform"]}}
{"level":"info","ts":1761649310.5676897,"logger":"http.log.access.log1","msg":"handled request","request":{"remote_ip":"172.71.175.92","remote_port":"12402","client_ip":"172.71.175.92","proto":"HTTP/2.0","method":"GET","host":"git.cyp0633.icu","uri":"/cyp0633/ostep-homework/blame/commit/a9800f62f7c4b5b73acf8b239912981066893c30/threads-cv/main-common.c","headers":{"Cf-Visitor":["{\"scheme\":\"https\"}"],"Cdn-Loop":["cloudflare; loops=1"],"User-Agent":["Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/113.0.0.0 Safari/537.3"],"Cf-Ray":["9959effcecf13acd-DFW"],"X-Forwarded-For":["85.254.139.44"],"Accept-Encoding":["gzip, br"],"Cf-Connecting-Ip":["85.254.139.44"],"Cf-Ipcountry":["US"],"Accept":["text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8"],"Accept-Language":["en-US,en;q=0.5"],"Referrer":["https://www.google.com/"],"X-Forwarded-Proto":["https"]},"tls":{"resumed":false,"version":772,"cipher_suite":4865,"proto":"h2","server_name":"git.cyp0633.icu"}},"bytes_read":0,"user_id":"","duration":0.232635982,"size":148573,"status":200,"resp_headers":{"Date":["Tue, 28 Oct 2025 11:01:50 GMT"],"Server":["Caddy"],"Alt-Svc":["h3=\":443\"; ma=2592000"],"Cache-Control":["max-age=0, private, must-revalidate, no-transform"],"Content-Type":["text/html; charset=utf-8"],"Set-Cookie":["REDACTED"],"X-Frame-Options":["SAMEORIGIN"]}}
{"level":"info","ts":1761649310.5740168,"logger":"http.log.access.log1","msg":"handled request","request":{"remote_ip":"172.70.34.170","remote_port":"12627","client_ip":"172.70.34.170","proto":"HTTP/2.0","method":"GET","host":"git.cyp0633.icu","uri":"/cyp0633/k12-math-paper-generator/commits/commit/a42e3bc68b2f3285da3368127b642b5999fef9a0/frontend/src/App.vue","headers":{"X-Forwarded-For":["89.116.14.10"],"X-Forwarded-Proto":["https"],"Cf-Ipcountry":["US"],"User-Agent":["Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.10 Safari/605.1.1"],"Accept-Language":["en-US,en;q=0.5"],"Accept":["text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8"],"Accept-Encoding":["gzip, br"],"Referrer":["https://www.google.com/"],"Cdn-Loop":["cloudflare; loops=1"],"Cf-Visitor":["{\"scheme\":\"https\"}"],"Cf-Ray":["9959effc0f995a45-IAD"],"Cf-Connecting-Ip":["89.116.14.10"]},"tls":{"resumed":false,"version":772,"cipher_suite":4865,"proto":"h2","server_name":"git.cyp0633.icu"}},"bytes_read":0,"user_id":"","duration":0.371793012,"size":68154,"status":200,"resp_headers":{"Alt-Svc":["h3=\":443\"; ma=2592000"],"X-Frame-Options":["SAMEORIGIN"],"Date":["Tue, 28 Oct 2025 11:01:50 GMT"],"Cache-Control":["max-age=0, private, must-revalidate, no-transform"],"Content-Type":["text/html; charset=utf-8"],"Set-Cookie":["REDACTED"],"Server":["Caddy"]}}
{"level":"info","ts":1761649310.6670785,"logger":"http.log.access.log1","msg":"handled request","request":{"remote_ip":"162.158.167.69","remote_port":"12289","client_ip":"162.158.167.69","proto":"HTTP/2.0","method":"GET","host":"git.cyp0633.icu","uri":"/cyp0633/stack-mod/blame/commit/41c3033d1ac6b9596ce3ae861484e855b619705a/i18n/en.yaml","headers":{"Referrer":["https://www.google.com/"],"Accept-Encoding":["gzip, br"],"Cf-Ray":["9959effec835cf2e-SJC"],"Cf-Connecting-Ip":["50.114.108.24"],"Accept":["text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8"],"Cdn-Loop":["cloudflare; loops=1"],"Cf-Ipcountry":["US"],"Cf-Visitor":["{\"scheme\":\"https\"}"],"User-Agent":["Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.10 Safari/605.1.1"],"Accept-Language":["en-US,en;q=0.5"],"X-Forwarded-For":["50.114.108.24"],"X-Forwarded-Proto":["https"]},"tls":{"resumed":false,"version":772,"cipher_suite":4865,"proto":"h2","server_name":"git.cyp0633.icu"}},"bytes_read":0,"user_id":"","duration":0.064485444,"size":121024,"status":200,"resp_headers":{"X-Frame-Options":["SAMEORIGIN"],"Server":["Caddy"],"Alt-Svc":["h3=\":443\"; ma=2592000"],"Date":["Tue, 28 Oct 2025 11:01:50 GMT"],"Cache-Control":["max-age=0, private, must-revalidate, no-transform"],"Content-Type":["text/html; charset=utf-8"],"Set-Cookie":["REDACTED"]}}

与上次Gitea被大规模爬取不同，日志中的2134个不同的源IP来自世界各地的不同国家，也有着各种可以以假乱真的User-Agent，光凭最简单的两个特征已经无法分辨爬虫和正常访问；Referrer 字段倒是统一的Google，一个根本无法屏蔽的值。在开始记录到爬取停止的30分钟内总共有超过25000条请求，也就是说平均每秒近14条，且endpoint基本都是 /src、/raw/ 和 /blame/ 之类的高开销请求。

怎么办呢？部分在ChatGPT的帮助下（用AI防御AI），本着尽量不影响正常用户访问（虽然没几个）、尽量block掉爬虫的原则，有了这么几种办法：

表层特征过滤和速率限制

由于爬虫有着巨大的IP池和不断变化的User-Agent，这些表层措施（甚至包括fail2ban）可以说收效甚微。而这些爬虫IP十分随机，以至于试了好几个都在AbuseIPDB上完全没有风险，下载其数据库也无法有效匹配。

同样的，由于请求被分摊到了大量IP上，针对IP做限速也是完全无效的。半小时的请求平均下来每个IP才12次，真人的请求都比这个多。

JS challenge

就像前两天被打得叫苦不迭的GNOME GitLab和AUR一样，上Anubis之类的JS challenge？其实很可能没什么用，从代价来看它根本防御不了爬虫。

无节制的爬虫与DDoS有着本质的区别。DDoS的目的是把服务器打垮、资源耗尽，即内存频繁缺页、CPU负载过高、刷爆CDN流量，或是令网络提供商不得不进行路由黑洞等，而不追求真的能访问到网页内容，因此DDoS通常有着极高的强度，而平均到每次请求所允许的开销很低，尤其考虑到DDoS的直接请求者经常是各种IoT肉鸡的情况下。从这个角度上来说，JS challenge通过大幅增加请求者的计算开销来阻挡DDoS是非常有效的。

而爬虫则不同。一方面，它们在提高爬取强度之前，需要确保访问的内容是可用的，所以不会以“打死”为目的；另一方面，财大气粗的AI企业能够购买大量合法的网络资源。更多的总资源，更少的请求频率，使得分配到每次请求的计算开销显著提高，即使让爬虫去解JS challenge成本也是可控的，AI企业有足够的动机去做这件事。

上面链接中的博客说的是同一件事。计算发现解一个Anubis这样的challenge成本几乎为零，而某个刚刚套壳了别人模型的厂恰巧也发现了，只要给爬虫加个runtime就行了。

Gitea限制用户访问

Gitea配置中自带一个限制高开销endpoint的选项：

ini

1
2

[service]
REQUIRE_SIGNIN_VIEW = expensive

开启后，所有未登录用户访问 /src、/raw/、/blame/ 等高开销页面时会被重定向到登录页面。这非常非常有效，只需检测一下登录状态，就能让正常用户继续访问，起码可以clone下来仓库自己研究，而爬虫则会收到一个Unauthorized。

直到爬虫（或者后面的人）找到了个口子：/compare/ 路径。不知为何这个路径没有被Gitea算作高开销，反而实际上开销比前三个更大。所以这个办法也宣告失败了。

自己写一层gateway

Anubis也是gateway，不过自己写一个gateway可以做很多自由的事，甚至坏事。Gitea本身对外提供OAuth2接口，可以在gateway中判断是否登录，然后决定是否放行请求。还可以根据系统负载来动态决定是否对未登录用户进行更严格的限制。

我有一个坏想法：Gitea的上述高开销端点都是根据模板渲染出来的，gateway也可以使用这些模板来伪造以假乱真的响应内容。与此同时，也有足够轻量的生成乱序假代码的逻辑。你可能猜到了我的目的：对爬虫进行投毒。只要做好足够的禁止爬虫声明，并在渲染出来的网页上显著标识“这是伪造内容”，大概便无需为此而自责，正常人应该都可以识别出来。

只是写这样的gateway有点工作量，等开题结束再说吧。

深层特征辨别

TLS指纹也算是一种特征，这可能是一种可行的方向，但效率恐怕没有下面这种的高。

验证Cookie

同样是揭露 Anubis 有效性的那篇博客探讨了一种Caddy设置cookie的方法（具体请自己点进去看），我推测这是一个非常简单且有效的办法。Gitea对于每个初次访问者都会设置CSRF token cookie，而统计发现上述爬取时段内非首次访问的请求仅有0.41% 具有cookie；这证明了这些爬虫没有处理cookie的能力。

这个博客提到的方法中，如果没有携带cookie，则仅能返回一个自动刷新的空页面；而携带了cookie的请求则会被正常转发到后端Gitea。这样一来，爬虫就只能拿到空页面了。

未雨绸缪，好消息是我的博客是静态页面，爬也没用。坏消息是评论系统是动态的，而且开销还不低。不过也好搞，到时候把评论关了完事。

Meta连爬6天

怎么都挑我时间紧的时候打啊，上次是忙开题，这次又是忙找实习，我真没空陪你们闹了。

感谢阿里巴巴公开免费的Qwen3.6-Plus，对于这些数据分析来说非常够用，又没有GPT-5.4那样的严重AI味。

最重量级的一集，robots.txt 也不管，登录限制的endpoint遇到redirect也嗯爬，之前提到的 /compare/ 口子也嗯爬，6天爬了110万次请求。几点观察：

完全无视 robots.txt，作为落在通配符上的其他UA，仍然应爬尽爬。
前几天的爬取主要落在 src、commits、raw、blame、rss 等endpoint上，而最近几个小时才转移到 compare 这个未拦截的端点。所以到第6天才被腾讯云告警发现，之前流量也没浪费多少。
6天内也不是一直在爬，每天总有那么几个小时没有爬；但在爬取时段，基本维持在每秒3次左右的频率上。
find、releases、actions、commit、activity 等endpoint也有所爬取，但并不随着commit变化，加之 find 被验证登录了，所以频率也不高，加起来才几千次请求。
几个高开销端点的commit hash均为真实存在，我就奇怪了，上述的endpoint都加了登录限制，compare爬得又晚，它到底是怎么知道commit hash的？而且有36%的请求是重复的，看样子还是不太死心。
IP段比较集中，103个IPv6分布在2a03:2880:f810::/48下，101个IPv4分布在/24下，都是Meta自己的归属地西雅图的IP。

当然，也不是所有的bot都遵守了 robots.txt 要求，但是这么久的请求中，根本不查询这些要求的，只有Meta一家别无分店。不同于ExternalFetcher，ExternalAgent并没有标明不遵守 robots.txt。

UA	结论
meta-externalagent/1.1	❌ 从未查询，直接无视
Applebot	❌ 查了但照爬不误
DotBot/1.2 (Moz)	✅ 完全遵守
YandexBot/3.0	✅ 完全遵守（在允许名单内）
ClaudeBot/1.0	✅ 完全遵守
facebookexternalhit/1.1	✅ 完全遵守
bingbot/2.0	✅ 完全遵守（在允许名单内）

剩下的不必多言，大家请看图。

分端点爬取次数随时间的分布

话又说回来了，说这些我自己也没什么办法，不管是上面的阿里云还是各路IP池，还都是用黑手套的IP来爬取的，给雇主留点面子。直到这里明晃晃地使用了Meta自己的IP段、Meta自己的User-Agent，更是肆无忌惮，目前的时间也只能谴责而已。总之Meta是真的找不出数据训llama5了是吧，能爬我的代码爬得起劲那真是这辈子有了。

中国互联网上，到底还能用什么获取信息

Thu, 15 May 2025 23:14:49 +0800

中国互联网上，到底还能用什么获取信息？

这个获取信息可以指代很多东西，比如知乎投毒，比如小红书关闭索引，不过这次想说的不是这个。

今日刷到V2EX上一篇文章，曰 F 搜被 360 告了，于是想起数年前确实有一群人，为了给中国互联网提供一个优质的信息检索工具，做了F搜。没记错的话，这个东西抓取Google等搜索引擎的信息，自己并不爬互联网；同时它又在墙内可用，堪称国内最好用的搜索引擎了。查了一下甚至早在2021年就已经公开发布了——也在V站。

好的东西还是活不长久，还记得过了一段时间，F搜就遇到了各种各样影响使用的问题，包括但不限于被监管机构封锁，检索变慢，以及其他无法访问的问题。而我的浏览器中能查找到最后一次搜索，停留在了2024年4月，但自然，这个时间点的F搜已经不会响应查询了。

虽然搜索结果的质量表明它显然不可能剽窃360的搜索结果，但F搜势单力薄，未能改变中国搜索市场。它来时，只有百度是彻底的垃圾桶，其他墙内搜索引擎还算有些优点；它走后，也并没有在国内搜索引擎中扬起什么波澜；又两年后，浓眉大眼的必应也开始加入假Steam广告（已经消失，但假Epic Games仍在），一个及格线以上的搜索引擎需求，起码在我看来是更迫切了。

哦差点忘了，必应搜索广告引导的假Steam客户端似乎用的是360的数字签名，现在必应的假Epic Games客户端则来源于……百度广告。呸。

OPPO Enco Free 4：技能树全点歪了的耳机

Thu, 17 Apr 2025 22:19:01 +0800

很久没有看到全网都在吹同一台耳机的现象了。从部分博主放出降噪曲线，然后开始营销500价位预期，再然后更多的博主开始对这款耳机大加赞扬，一直到正式发售，互联网对它的狂热，就像是低价位的救世主降临了。

入手价格：原价369 - 学生优惠30 - 国家补贴55.35 = 313.65人民币

音质、调音与主观听感

很遗憾的是它并没有发挥OPPO声学的优良传统——或者说，很好地保持了近期OPPO声学产品的糟粕。低频量巨大，其他频段也只是中规中矩，虽然听感相对于Enco X3一耳朵屎有了明显提升，但仍然连小米的审美都不如，起码小米有人懂科Hi。

设备：小米15 / 调音：至臻原音 / LHDCv5 + Hi-Res模式 / 固件115.115.105 / Apple Music无损

下面以几首曲子为例来说说我的感受：

德沃夏克《第九交响曲》，第4乐章（1959柏林爱乐乐团 & 卡拉扬）：表现尚可，号的音色渲染不错，而单簧管的音色则显得逊色。
柴可夫斯基《天鹅湖》，No. 2（1976伦敦交响乐团）：大提琴响起时已经有一定的轰头感，而三角铁的声音相对正常乐团排布较近。在演奏钹与定音鼓的时候，弦乐、铜管乐器和打击乐的声音混在一起，十分混沌，听感糟糕，这点在最后一段高潮部分尤为明显。
维瓦尔第《四季》，春（1984维也纳爱乐 & 卡拉扬）：小提琴协奏曲，然而让人摸不清独奏的小提琴到底在哪里。
何占豪《梁祝》（1996中国交响乐团 & 吕思清）：没有渲染出小提琴中高频下所表达的清亮音色，导致不管是欢快情节还是悲伤情节，都发挥不出情绪。
周杰伦《搁浅》：作为一首鼓点声音比较大的歌，鼓点一上来就开始轰头了，一轰到尾，很大程度上盖过了人声的细节。周杰伦的人声渲染得较为粗糙，还有种闷着的感觉。
许嵩《温泉》：本来一首甜甜的歌，甜味都没了，像土嗨一样，问题和《搁浅》差不多。
《明天会更好》：独唱的人声很不错，伴奏乐器尚可，合唱则显得闷而混沌。
OneRepublic《Love Runs Out》：这首歌的鼓点频率稍高一点，正好避开了最轰头的区域，没有前两首那么惨。这本应该是它的优势区间，然而对于Tedder假声的渲染则稍显单薄，情绪的表达就卡那儿了。
Shawn Mendes & Camila Cabello《Señorita》：把低频拉低后勉强能听了，人声的音色渲染相对OK，但男女声完全混在一起，没有层次感。
Taylor Swift《Blank Space》：Taylor的声音符合我的预期，这是这款耳机表现相对好的一首歌。
HOYO-MiX & Chevy《使一颗心免于哀伤》：果然让这个耳机变能听的最简单方法就是挑一首没多少低频的歌，人声不错，不过气声相对来说还是有些放大了，我个人不喜欢。

总的来说最大的问题其实仍然存在于致死量低频上，其自带均衡器的调节范围仅有 ±6dB，所以不仅需要将50Hz左右拉到最底端，而且要给其他频段额外加入增益才算是能听。另外也有一些需要解决的小问题，比如各种乐器混在一起没有区分感等，但最基本的能听已经保证了。

其实我本来副标题都想好了，叫做“建议售价4001元”，没别的只是想嘲讽一下那个“4000以内音质最好”的耳机。然而它现在搞成这个样子我也很没办法呀，它确实是不如。带强烈主观的渲染，如果不能控制好方向，那么适得其反，不如白开水性冷淡调音。

大致概括一下内置的几种调音风格：

至臻原音：大量低频，很轰头；其他频段也偏闷
纯享人声：人声大幅拉高，很突出，但低频也不小
澎湃低音：💩
活力动感：相比至臻原音，低频略有削弱，声音的表现更加明快，但与至臻原音没有本质的区别

主动噪音控制

与乏善可陈的音质音效相比，降噪和通透模式的表现则是它的巨大亮点。

单论极限降噪深度斗蛐蛐数值，Enco Free 4并不出众，波谷值仅在 -42分贝左右。然而每个媒体测试结果都表明，其降噪曲线异常平坦。实际体验中也印证了这一现象，它对于中高频噪音的降噪效果，不光能够将同价位耳机抛在身后，也能够与友商的旗舰TWS相提并论。它对人说话声有着明显的抑制效果，基本能够完全盖过空气净化器开大档的声音，甚至只要开一点声音听歌，能够完全盖过红轴机械键盘的敲击声。虽然感觉确实人为增大了耳套来进行被动降噪，但主动降噪效果相对于忧伤机型来说也并不落于下风，也并未明显牺牲佩戴。相比于仍然沉湎于廉价低频冲击的调音，起码降噪是真正为听感着想了。

通透的效果称得上略有瑕疵，瑕疵来源于其时有时无的巨大底噪。沙沙声的底噪会在刚切换到通透模式时非常明显，然后几乎完全消失，但在其他某些情况下也会出现，不过其实很难察觉，并不影响体验。对全频段的还原也是相当不错的，重要的人声和交通噪音也得到了恰到好处的还原。耳机柄上方巨大的麦克风开孔，也保证了其在通透模式下的拾音效果，确保了各个方向都能够捕捉外界声音。

单只佩戴可以支持通透或者降噪，效果非常好，且模式设定与双耳佩戴分离（如可以设置单耳通透、双耳降噪，互不干扰），非常理想的逻辑。

抗风噪的逻辑在我体验的耳机中算是比较好的，但仍然不能满足戴耳机骑车的需要。相比于许多耳机检测到风噪就直接禁用主动噪音控制的办法，听起来Enco Free 4并不是完全降低所有频段下的噪音控制效果，针对频段有所不同；而且这个应对效果也并非两档一刀切，而是针对风噪声的大小动态调整。但不巧的是，在降低风噪增益的同时，交通噪音也不再那么明显了，而这对于骑车来说是个很大的问题，因为不再能够单凭声音预料到后方来车了。

自适应模式平平无奇，如果说上述的噪音控制功能已经做得够好了，那自适应模式也算不上锦上添花——真的不智能。

App与互联

欢律App称得上是非常可靠，基本不会故意不给其他厂商阉割功能。逻辑比索尼的正常很多，也不会管不该管的事。

App中可以显示当前连接的两台设备名称，但不能手动取消其中一个的配对。不得不提的是，双设备连接的逻辑非常感人，它不同于暂停原先设备播放、切换到另一台设备的逻辑，也不是切换设备但却不主动暂停原设备（但声音是新设备的），而是在有声音输入时，直接忽略另一台设备的声音。比如在电脑上看片，耳机输出电脑的声音；此时手机来了个电话，耳机仍然播放电脑的声音，手机却以为自己连着耳机所以不响铃，于是手机铃声就这么完全被忽略掉了。

切换模式的人声提示音竟然有好几种可选，可惜我并不想要人声，只想要简单的提示音，如果这样能把切换模式连带播提示音的用时降下来，那便是极好的了。

佩戴与操控

个人认为在柄式TWS中这个算比较大的，因为它戴不牢。虽然比不上豆式的索尼WF-1000XM3或者红米AirDots 3（无Pro）那么大，但相比贴合耳廓非常牢靠的小米Buds 3 Pro、OPPO Enco X3和小米Buds 5 Pro——没错，虽然它听感和降噪都不行，但它佩戴特别特别舒服——还是差了不少。好在入耳的部分固定非常牢靠，单耳重量也不过分，所以其实不用担心掉落。

掉不下来归掉不下来，有时候还是觉得它会掉，于是会时不时用手扶一下。这就引入了另一个问题，它的便捷操控是通过按压滑动（或者说触摸）耳机柄上方的一块区域实现的。因为区域本身不小，所以还是有一定可能会误触单击。就这一点上，我认为不如捏耳机柄。

质感非常一般，纯纯的大塑料感，甚至没有磨砂或者别的什么涂层。好在做工处于不错的水平，接缝等处理得十分顺滑。

续航与充电

续航可以信赖，充电盒充电速度高达约5W，基本构不成瓶颈。原价300多块钱的耳机确实不适合要求无线充电。

总结

中端降噪神塞，确实担当得起救世主的地位，但除了降噪以外的功能，顶多符合价位罢了。很适合大部分只需要听个响、经常遇到嘈杂环境，但从不正经欣赏音乐的人。

在 Linux 上使用微软套件的最好办法，就是没有办法

Wed, 05 Mar 2025 16:49:43 +0800

大半年前，在工位的电脑上装了EndeavourOS，从此开始了无Windows的学习生活尝试。在Linux上打大部分游戏都有完善方案的现在，用Linux办公仍然是个难题，很神奇吧？拜微软所赐，Linux上现在还没有我习惯的原生版MS Office，更没有OneDrive和Office 365。

WPS Office：又不是不能用

在Windows上，WPS Office就已经与MS Office（Microsoft 365）相爱相杀了二十多年；而在缺失MS Office的Linux原生办公方案中，WPS Office仍然是其中翘楚，比什么LibreOffice高到不知哪里去了。

或许拜近些年的信创风所赐，需要称赞的是Linux上的WPS Office清爽无广告，该有的基本功能也都有。不出意外的话，这已经是原生Linux办公软件中体验最好的一个了。然而在一些小细节上，雷老板的产品仍然没打磨好：比如交叉引用功能，Word会自动提取文章中已有的标签和编号格式，而WPS文字就不会，不得不手动添加标签。

OneDrive也是个麻烦：第三方的onedriver客户端经常丢认证掉挂载，只能重新打开开关，同时用WPS也没有增量同步和自动保存。

Office Online：六边形战士，但六边都不长

微软原厂方案，OneDrive集成，在线编辑实时保存，不需要虚拟机或者转译，占用空间小，真有这种美事？有的兄弟有的，但这些话都只说了一半。只有最基础的功能，打开网页巨慢无比（挂了梯子），打的字时不时会被吃掉，字体都不能正常显示，操作比虚拟机还卡。套着微软的光环也不行，如果说WPS的同步和细节问题都可以克服一下，那么有以上任何一条都表示，Office Online基本是不可用的。

我看大家也别笑金山文档、腾讯文档甚至Google Docs什么的，起码人家操作真流畅。

虚拟机：堕落的混乱邪恶派

虚拟机纯属无奈之举呀，毕竟要划走好几个核，以及数GB的内存；明明是为了躲避垃圾Windows才装的Linux，反过来又把Windows请回来了。但除此之外基本都是优点，全功能的Office，一般不出岔子的OneDrive，剩下的缺点基本只有与GNOME桌面环境格格不入了。

WinApps：想法很美好，但没有Wayland

虚拟机的更进一步，加入了与桌面环境的深度集成，甚至可以在主机中注册文件扩展，听起来非常美好。但装了一半才发现没有Wayland显示协议，都5202年了真有人用X11吗。

总结

除了原生WPS和虚拟机以外都不及格。如果能忍虚拟机带来的额外开销，那么虚拟机是最好的；如果不能，我会选择WPS Office。

索尼 WH-CN720N：我就知道会缺点什么

Fri, 21 Feb 2025 22:42:57 +0800

一提到降噪头戴式耳机，很多人脱口而出的显然是索尼WH-1000XM系列，降噪效果优秀，降价交朋友也很勤快，属于是索尼消费级音频产品线的拳头产品。但是即使上代WH-1000XM4降完价也要1200块钱，那么大法有没有什么便宜的降噪耳机呢？有的兄弟有的，这样的产品一共有三代，索尼在2023年推出了最新的WH-CH720N，发售价900多块钱，现在已经降到了500多块钱。那么索尼会在一半的价格给到什么呢？

设备连接与App体验

35个小时的续航基本不是吹的，日常听几乎不会遇到没电的情况。不过既然没有佩戴检测，也就更谈不上基于其做的各种省电功能了。

和影像产品一样，索尼并没有给穷哥们单独安排一个App，和高端货用的是一样的Sound Connect（即Headphones Connect）。作为索尼的产品来说逻辑相对还算正常，起码最常用的功能一看就知道在哪里。

双设备连接的体验是相对比较领先的，当另一个设备开始播放的时候，正在播放的设备会自动暂停，这也是大部分耳机选择的逻辑。连接控制由App完成，而非引导用户去按键，这使得可以自由控制什么时候配对另一台设备，什么时候忘掉某一台设备，甚至什么时候固定由某台设备进行播放。考虑延迟后，切换速度也是可以接受的。在无法连接更多台设备的情况下，这种程度基本上是完美的。

除了手动均衡器外，App还支持根据用户的听感定制均衡器。均衡器的效果基本确实能满足个人的偏好，只不过高频要翘好多才能做到白开水的效果。

App的一大亮点是支持根据运动状态调整环境音控制模式，如走路、停留、跑步和搭乘交通工具。虽说总比没有强，识别率也还算乐观，但这个功能必须依托App才能实现，搭配某些手机厂商臭名昭著的后台控制，到头还是不方便。

音质与调音

默认调音低频量偏大，但却不轰头，脱离了OPPO Enco X3等耳机的低级趣味，但也没往所谓的科Hi偏移多少。好在调过均衡器之后能够符合我个人偏好了，上文提到的自动听感调节大大降低了调均衡器的工作量。然而除低频下潜的质量外，我并未发现WH-CH720N的音质有什么亮眼之处；即使抛开不支持LDAC不谈，同样在AAC模式下，如高频质量与声场等方面也并未见到优势。

降噪与通透

作为头戴式耳机，它的拿手好戏当然是高频降噪。归功于把耳朵罩起来的设计，其能够在保持佩戴舒适度的情况下，获得比入耳式耳机更好的密封效果。然而低频降噪并不出彩，怪不得降噪只有一档，多切哪怕一档都显得黄仁勋的刀法相形见绌。

在飞机上，这款耳机的降噪效果差强人意。十几年的中年飞机机舱里难免会有些部件响动，而它的高频降噪性能很好地掩盖了这一点，哪怕不开电源，对这种噪音也有显著的抑制作用。然而低频降噪远远低于小米Buds 3 Pro，一款早在两年前就只要300块钱的入耳式TWS；耳压感也严重很多，令人长久有一种烦躁感。地铁场景的表现则不能一概而论，如长沙3号线这种噪音严重的线路，体感的噪音更是降了但没完全降，处于一个不上不下的状态；而较新的线路质量更好，这款耳机的降噪效果也就刚好能够用了。总的来说，WH-CH720N的降噪也只是在特定频段下有优势，而这种优势买个大耳罩子也能有。

通透模式，索尼称环境音控制，反而切成了20档外加一个人声增强开关，与一般耳机降噪分档但通透不分档的设计完全相反。拉到20级基本能够正常还原环境音，这个挺不错的。

抗风噪效果尚可，最起码不会风一吹就摆烂关闭降噪/通透。

佩戴舒适度

包耳的设计使它注定要与耳朵上戴的东西有一定冲突，比如眼镜腿。降噪效果极其依赖于耳机与头部的贴合性，只要被眼镜腿挤开一点点，耳罩与头部出现一点缝隙，降噪效果就会大打折扣。但好消息是夹头感并不强，如果不考虑降噪，即使夹着眼镜腿也能保证佩戴的体验。继续用手按压两侧耳罩，降噪效果也并未有明显的提升，头梁的松紧度就这样卡在了一个非常平衡的位置。

多亏了毫无质感的大塑料机身，这款耳机非常轻，与听半小时脖子开始累的AirPods Max拉开了巨大的差距。这意味着除了必要的一点夹头之外，戴上这款耳机的体验是非常舒适的。

这款耳机几乎没有做任何的可收纳设计，只有耳机的旋转，这导致带出去基本只能挂在脖子上，这下又对标AirPods Max了（笑）。

总结

如果不是对头戴式降噪耳机有特殊需求，我的建议是购买市场已经非常成熟非常卷的入耳式TWS耳机，500多块钱足够买一个性价比极高的产品，多的钱还能吃顿好的。如果限定在降噪头戴方面，WH-CH720N也是交出了一份合格的答卷，在App和舒适度方面甚至有一定的亮点。考虑到性价比市场也有漫步者这样的超级卷王，我建议购买前先找个体验店试试300多价位的机型，毕竟上述这些东西能不能值200块钱，还是要自己去体验一下。

1007

Tue, 21 Jan 2025 10:41:14 +0800

Deepseek大概真的是国产大模型王者了。V3和Claude 3.5 Sonnet打得有来有回，除了少点人味儿之外（毕竟大概率蒸馏了GPT-4o），输出都挺让人满意的，token价格却几乎相当于白送；R1只用12000个token完美解决了o1至少用30000 token才解决的问题，更别提token单价的差距。

月之暗面的长上下文能力确实挺震撼的，是能塞下一整本课本的级别。但陷入无意义重复的情况也很多，正如网上那张给猫取名的梗图那样。

新秀MiniMax-01调得就没那么细心了，整体质量略逊于Deepseek V3，但考虑到这玩意巨巨巨巨巨长的上下文，倒是可以成为Kimi的上位替代。

阿里通义不知道在干嘛，QvQ除了名字比较萌之外，自个儿推理好久经常都是错的。当然这毕竟是个小模型，72B的参数量比起别人成千上万亿参数的MoE确实有着量级上的差距。14B的小模型质量确实还是不错的。

希望有一天我可以不再需要订阅ChatGPT Plus。

记导出 Android 版 NTQQ 聊天记录

Tue, 31 Dec 2024 16:46:00 +0800

正值2024年的最后一天，群友突发奇想，该做群聊年终总结了。而众所周知，自从QQ全平台更新到了NT架构，原有的聊天记录导出方法就全都失效了。本文记录一下根据网上现有方案导出Android版NTQQ（版本9.1.5）聊天记录的过程。

我准备了一台root过的小米15，以及一台Linux PC。

导出数据库¹

其实由于各平台使用了统一的NT架构进行核心的消息处理，各个平台导出的数据库大同小异，但获取密钥的方式差异比较大。PC版QQ需要使用IDA进行反编译调试，试了几次并没有成功，Android设备没有root的读者可以尝试使用PC版QQ的方法，在此不详述。而root后的Android手机可以通过adb shell运行 su 切换为root用户，这样能够方便地进入QQ的私有目录浏览所需的文件。

shell

1
2
3

dada:/ $ su
dada:/ # whoami
root

密钥由 uid 和 rand 两个参数生成。其中 uid 并不是用户的QQ号，而是形如 u_xxxxxxx 的一串字符串；rand 嵌在数据库文件中。

首先获取 uid。进入 /data/data/com.tencent.mobileqq/files/uid/ 目录，其中的文件名记录了QQ号和 uid 的对应关系。

shell

1
2
3

dada:/ # ls -l /data/user/0/com.tencent.mobileqq/files/uid/                                                                              
total 0
-rw------- 1 u0_a327 u0_a327 0 2023-12-22 18:49 2660000000###u_U6vwQunVqPOUxxxxxxxxxx

然后获取数据库。这个时候强烈建议暂时关闭QQ的 自启动和后台运行权限，以防QQ运行时修改数据库，从而影响校验和计算和比对。其数据库保存在 /data/user/0/com.tencent.mobileqq/databases/nt_db/nt_qq_<QQ_path_hash>/nt_msg.db 中，其中 QQ_path_hash 可以在 ¹ 页面顶部的小工具中计算得到。

shell

dada:/ # ls -lh /data/user/0/com.tencent.mobileqq/databases/nt_db/nt_qq_5937760ce9717f9d58748067ce3a5e3b                                                            
total 3.5M
......
-rw------- 1 u0_a327 u0_a327 2.3G 2024-12-31 18:20 nt_msg.db
-rw------- 1 u0_a327 u0_a327  16K 2024-12-31 15:56 nt_msg.db-first.material
-rw------- 1 u0_a327 u0_a327  16K 2024-12-31 15:48 nt_msg.db-last.material
-rw------- 1 u0_a327 u0_a327  32K 2024-12-31 18:21 nt_msg.db-shm
-rw------- 1 u0_a327 u0_a327 499K 2024-12-31 18:21 nt_msg.db-wal
......

先将数据库复制到一个普通用户可以获取的位置，然后使用 adb pull 将其保存到电脑上：

shell

dada:/ # cp /data/user/0/com.tencent.mobileqq/databases/nt_db/nt_qq_5937760ce9717f9d58748067ce3a5e3b/nt_msg.db /sdcard/

# 这之后都在本机 shell 中运行
$ adb pull sdcard/nt_msg.db ./
sdcard/nt_msg.db: 1 file pulled, 0 skipped. 171.7 MB/s (2487477248 bytes in 13.817s)

提取字符串后，建议在手机和PC上分别计算校验和，确保数据完整性。 rand 字段在数据库二进制文件的 QQ_NT 字段附近。使用 strings 提取数据库中的可读字符串，然后使用 grep 将其找出，或使用其他类似工具读取二进制文件：

shell

$ strings nt_msg.db | grep --context 3 "QQ_NT"
SQLite header 3
QQ_NT DB
Z68aUxXX
1.0.0.1" HMAC_SHA1
\[`-

由上述信息，得到 rand 字符串为 Z68aUxXX。

解密数据库²

先计算数据库口令，在 ¹ 顶部的小工具中可以计算。看起来腾讯在数据库的头上加了些元数据，先把它截掉：

shell

`1`	`tail -c +1025 nt_msg.db > nt_msg.clean.db`

之后用sqlcipher打开，输入以下内容，将你的口令替换进去，尝试解密：

shell

$ sqlcipher nt_msg.clean.db
SQLite version 3.45.3 2024-04-15 13:34:05 (SQLCipher 4.6.0 community)
Enter ".help" for usage hints.
sqlite> PRAGMA key = '<your-key>';
PRAGMA kdf_iter = 4000;
PRAGMA cipher_hmac_algorithm = HMAC_SHA1;
ok
sqlite> SELECT name FROM sqlite_master WHERE type='table';
c2c_msg_table
c2c_msg_flow_table
group_msg_table
group_msg_flow_table
c2c_temp_msg_table
c2c_temp_msg_flow_table
......

如果能像上面这样看到表名，那么到这一步都是正确的。解密时，若按照 ² 中的教程操作可能出现“database disk image is malformed”，这可能并没有出问题。这时候可以先dump下来，然后再导入未加密的SQLite数据库³：

shell

sqlite> .output nt_msg.sql
sqlite> .dump
sqlite> .exit
$ cat nt_msg.sql | sed -e 's|^ROLLBACK;\( -- due to errors\)*$|COMMIT;|g' | sqlite3 nt_msg.decrypt.db

现在得到的 nt_msg.decrypt.db 就是解密后的数据库了，可以直接打开查看。

导出聊天记录

数据库的schema很抽象，其中一列甚至是二进制。好在网络上已经有了数据库字段含义 ⁴ 和二进制Protobuf payload定义⁵，对于提取文字消息而言是非常够用的。

首先将该链接内的Protobuf定义编译为Python类：

shell

`1`	`protoc --python_out=. message.proto`

我让Claude帮我写了一份代码，用于把特定群组的文字消息导出为JSON，包含发送方和发送时间，效果还行，搭配上述Python类食用即可，可以选择发送时间：

python

import sqlite3
import base64
import json
from datetime import datetime
import argparse
from message_pb2 import Message

def timestamp_to_datetime(timestamp):
    """将时间戳转换为可读的日期时间格式"""
    return datetime.fromtimestamp(timestamp).strftime('%Y-%m-%d %H:%M:%S')

def decode_message(blob_content):
    """解码BLOB数据并解析protobuf消息"""
    try:
        message = Message()
        message.ParseFromString(blob_content)
        return message
    except Exception as e:
        print(f"Error decoding message: {e}")
        return None


def extract_text_messages(message):
    """从消息中提取文字内容"""
    messages = []
    for single_msg in message.messages:
        if single_msg.messageType == 1:  # 文字消息
            print("Debug info for message:")
            print(f"Raw sendTimestamp: {single_msg.sendTimestamp}")
            print(f"Raw senderUid: {single_msg.senderUid}")
            print(f"Raw messageText: {single_msg.messageText}")
            print("Message full content:")
            print(single_msg)
            print("------------------------")
            
            messages.append({
                'time': timestamp_to_datetime(single_msg.sendTimestamp),
                'sender_id': single_msg.senderUid,
                'content': single_msg.messageText
            })
    return messages


def fetch_messages(db_path, group_id, start_time=None, end_time=None):
    """从数据库中获取消息"""
    conn = sqlite3.connect(db_path)
    cursor = conn.cursor()
    
    query = 'SELECT "40050", "40033", "40800" FROM group_msg_table WHERE "40027" = ?'
    params = [group_id]
    
    if start_time:
        query += ' AND "40050" >= ?'
        params.append(start_time)
    if end_time:
        query += ' AND "40050" <= ?'
        params.append(end_time)
    
    query += ' ORDER BY "40050" ASC'
    
    try:
        cursor.execute(query, params)
        results = cursor.fetchall()
        
        all_messages = []
        for timestamp, sender_id, content in results:
            if content:  # 确保内容不为空
                message = decode_message(content)
                if message:
                    # 从protobuf中只提取消息文本
                    for single_msg in message.messages:
                        if single_msg.messageType == 1:  # 文字消息
                            all_messages.append({
                                'timestamp': timestamp_to_datetime(timestamp),
                                'sender_id': sender_id,
                                'content': single_msg.messageText
                           python extract.py --help                                                                                                                    ✔  20:21:06   
usage: extract.py [-h] [--start START] [--end END] [--output OUTPUT] db_path group_id

Extract QQ group chat messages

positional arguments:
  db_path          Path to the SQLite database file
  group_id         Group ID to extract messages from

options:
  -h, --help       show this help message and exit
  --start START    Start timestamp (optional)
  --end END        End timestamp (optional)
  --output OUTPUT  Output JSON file path (optional)

        conn.close()


def main():
    parser = argparse.ArgumentParser(description='Extract QQ group chat messages')
    parser.add_argument('db_path', help='Path to the SQLite database file')
    parser.add_argument('group_id', type=int, help='Group ID to extract messages from')
    parser.add_argument('--start', type=int, help='Start timestamp (optional)')
    parser.add_argument('--end', type=int, help='End timestamp (optional)')
    parser.add_argument('--output', help='Output JSON file path (optional)')
    
    args = parser.parse_args()
    
    messages = fetch_messages(args.db_path, args.group_id, args.start, args.end)
    
    # 将结果转换为JSON
    output = {
        'group_id': args.group_id,
        'messages': messages
    }
    
    # 输出结果
    if args.output:
        with open(args.output, 'w', encoding='utf-8') as f:
            json.dump(output, f, ensure_ascii=False, indent=2)
    else:
        print(json.dumps(output, ensure_ascii=False, indent=2))

if __name__ == "__main__":
    main()

import sqlite3
import base64
import json
from datetime import datetime
import argparse
from message_pb2 import Message

def timestamp_to_datetime(timestamp):
    """将时间戳转换为可读的日期时间格式"""
    return datetime.fromtimestamp(timestamp).strftime('%Y-%m-%d %H:%M:%S')

def decode_message(blob_content):
    """解码BLOB数据并解析protobuf消息"""
    try:
        message = Message()
        message.ParseFromString(blob_content)
        return message
    except Exception as e:
        print(f"Error decoding message: {e}")
        return None


def extract_text_messages(message):
    """从消息中提取文字内容"""
    messages = []
    for single_msg in message.messages:
        if single_msg.messageType == 1:  # 文字消息
            print("Debug info for message:")
            print(f"Raw sendTimestamp: {single_msg.sendTimestamp}")
            print(f"Raw senderUid: {single_msg.senderUid}")
            print(f"Raw messageText: {single_msg.messageText}")
            print("Message full content:")
            print(single_msg)
            print("------------------------")
            
            messages.append({
                'time': timestamp_to_datetime(single_msg.sendTimestamp),
                'sender_id': single_msg.senderUid,
                'content': single_msg.messageText
            })
    return messages


def fetch_messages(db_path, group_id, start_time=None, end_time=None):
    """从数据库中获取消息"""
    conn = sqlite3.connect(db_path)
    cursor = conn.cursor()
    
    query = 'SELECT "40050", "40033", "40800" FROM group_msg_table WHERE "40027" = ?'
    params = [group_id]
    
    if start_time:
        query += ' AND "40050" >= ?'
        params.append(start_time)
    if end_time:
        query += ' AND "40050" <= ?'
        params.append(end_time)
    
    query += ' ORDER BY "40050" ASC'
    
    try:
        cursor.execute(query, params)
        results = cursor.fetchall()
        
        all_messages = []
        for timestamp, sender_id, content in results:
            if content:  # 确保内容不为空
                message = decode_message(content)
                if message:
                    # 从protobuf中只提取消息文本
                    for single_msg in message.messages:
                        if single_msg.messageType == 1:  # 文字消息
                            all_messages.append({
                                'timestamp': timestamp_to_datetime(timestamp),
                                'sender_id': sender_id,
                                'content': single_msg.messageText
                           python extract.py --help                                                                                                                    ✔  20:21:06   
usage: extract.py [-h] [--start START] [--end END] [--output OUTPUT] db_path group_id

Extract QQ group chat messages

positional arguments:
  db_path          Path to the SQLite database file
  group_id         Group ID to extract messages from

options:
  -h, --help       show this help message and exit
  --start START    Start timestamp (optional)
  --end END        End timestamp (optional)
  --output OUTPUT  Output JSON file path (optional)

        conn.close()


def main():
    parser = argparse.ArgumentParser(description='Extract QQ group chat messages')
    parser.add_argument('db_path', help='Path to the SQLite database file')
    parser.add_argument('group_id', type=int, help='Group ID to extract messages from')
    parser.add_argument('--start', type=int, help='Start timestamp (optional)')
    parser.add_argument('--end', type=int, help='End timestamp (optional)')
    parser.add_argument('--output', help='Output JSON file path (optional)')
    
    args = parser.parse_args()
    
    messages = fetch_messages(args.db_path, args.group_id, args.start, args.end)
    
    # 将结果转换为JSON
    output = {
        'group_id': args.group_id,
        'messages': messages
    }
    
    # 输出结果
    if args.output:
        with open(args.output, 'w', encoding='utf-8') as f:
            json.dump(output, f, ensure_ascii=False, indent=2)
    else:
        print(json.dumps(output, ensure_ascii=False, indent=2))

if __name__ == "__main__":
    main()

用法：

shell

$ python extract.py --help
usage: extract.py [-h] [--start START] [--end END] [--output OUTPUT] db_path group_id

Extract QQ group chat messages

positional arguments:
  db_path          Path to the SQLite database file
  group_id         Group ID to extract messages from

options:
  -h, --help       show this help message and exit
  --start START    Start timestamp (optional)
  --end END        End timestamp (optional)
  --output OUTPUT  Output JSON file path (optional)

最后祝各位新年快乐！

1006

Thu, 19 Dec 2024 10:23:39 +0800

最近高贵的CN2 GIA梯子每到晚上就会炸，速度甚至跑不上20Mbps。以前只是以为技术性调整，然而这炸得也太久了。

MTR了一下发现走的是北京联通出口，那这就不奇怪了，早在N个月前就有人提到过北京联通到北京电信互联会炸的事儿。

这种猛丢包还不如世界加钱可及的奠信，毕竟我是真加了钱上CN2的。

1005

Sun, 01 Dec 2024 19:26:56 +0800

嫌Fastmail贵，趁黑五投奔了MXroute。去了才发现，有Fastmail一样好用的网页界面并不是理所当然。除了配置域名和DNS之外，Fastmail其余的体验甚至可以接近Gmail；如果没预先买域名的话，他们甚至可以代你注册一个，或者直接用他们的 @fastmail.com邮箱！反垃圾邮件比较傻，但配置起来也还好。Passkey、（真正有用的）应用密码和二步验证等安全性功能都有，无限量创建别名之类的能想到的功能基本都有。It Just Works™️。

MXroute就完全是另一回事了，毕竟曾经运营过MJJ界知名的LET站，便宜是真的便宜，但无奈易用性上非常捉襟见肘。比如财务支持账户管理是一个面板，邮箱管理是另一个面板，Webmail又是一……三个面板，看样子各自都是采购现成的方案，所以难以整合到一起；开源的Webmail也基本是一言难尽，总是让人觉得逻辑不方便，让人无不怀念起Thunderbird来。至于日历那更是让人没有用的欲望，逼着我找第三方解决方案。好在回工单还是很快的，毕竟是大洋彼岸，怎么着睡一觉都能有回复了。

原来这就是50刀一年和15刀三年的区别。但毕竟一年省45刀，便宜是真便宜。先用着吧，三年后再看情况嫖嫖企业邮箱。

1004

Sat, 23 Nov 2024 22:21:39 +0800

没想到EA一家人还能做出两家游戏，也可能是Codemasters被收购没多久，NFS烂成那个样子，F1 24反而还有点好玩。排除掉登录EA账号时的各种bug，F1 24作为一个年货游戏，质量仍然算是过硬水准。

毕竟既没有警察又不能开飞机，或者与气垫船竞速，我一直以为严肃RAC的乐趣就是纯粹的跑圈跑圈跑圈。但F1 24的养车队玩法还是挺有意思。这游戏对小白也还算友好，即使完全不知道赛制，也能从各种地方摸索到教程；操作门槛也不太高，甚至有可用度非常高的自动刹车，简单难度下的AI也可以做到非常菜。

总之娱乐下还是不错的，至于网上褒贬不一的评价，是不是丢了基本盘，我就没法评价了。

1002

Sun, 10 Nov 2024 21:20:44 +0800

游科的美术配乐场景设计有点东西的。剧情也还算有脉络，画质也是少见的好写实。

蛮不错的场景美术

但是有些Boss设计又挺令人抓不住头脑的，也难怪人叫杨奇/冯骥英高。

test

Sun, 10 Nov 2024 08:12:00 +0800

给博客撸了个新功能，从现在起这个地方就用来发一些碎碎念了。考虑过上Fediverse，但感觉还是这种方式更容易控制。

感谢GPT，让一个N年没摸过前端的人也能撸出来个大概。

小米 15：「锐利」当道的「圆滑」异类

Sat, 09 Nov 2024 00:00:00 +0000

往常吊打友商的发布会逐渐换了方向，一打眼的参数拉个表也不见得有优势；一次次系统优化的说辞已经变成“狼来了”，金凡苦口婆心的演讲仍然打动不了网友。当最能直接刺激神经的参数斗蛐蛐逐渐落于下风，小米更加「圆滑」的新一代冲高作品，又会交出怎样的答卷？

虽然零售铺开前大家还都将信将疑，但架不住碎屏险很香啊。大家都说小米旗舰不能冲首发，但这次我却偏要直接全款预订。毕竟不冲首发也要买碎屏险，How could it possibly go wrong?

配置：小米15浅草绿，16GB RAM，512GB ROM。 如未提及，所有体验均基于首发前后的系统版本。

CMF（色材工艺）

首先还是要说，做工保持了一些小米的“优良传统”。我这台绿色的音量键的公差很大，而朋友一起提的机器则好很多；某些展示机的扬声器孔排列并不与底边平行，而镜头模组四周的塑料包边和玻璃盖板之间也有一些间隙，容易藏污纳垢。抛开这些小问题不谈，小米15的外观虽然只是在前代的基础上小修小补（据称可以套上14的手机壳），但对手感却是大提升。

手机背面。在较亮的光线下，并没有那么绿

在机身的背面，边框向内弯曲，制造了一定的弧度，免除了许多直边手机，比如iPhone 13 mini，的割手感问题。后盖玻璃和边框之间也并未出现明显的高度差与缝隙，在这一点上保持了做工的水准。相机模组周围去掉了一圈无意义的巴黎饰钉，你看还是不要跟着华为亦步亦趋的好。

正面的四边等宽极窄黑边对观感非常加分，至于有没有影响信号，这个之后再去探讨；但我觉得已经影响耐摔了，因为文章还没写完，朋友的首发机内屏已经摔坏了，外屏却毫发无损。不过为了视觉上黑边尽量窄，边框并没有像背面那样明显地向内弯。充电口依然没有注塑，有线充用得多的话难免有磨损。

机身厚度还算可以接受，镜头模组的凸起比12S高很多；重量分配尚可，不会明显的头重脚轻，但如果习惯单手握持时托住底部，仍然会感觉到向前倾。

当然手感仍然是一个难以量化的东西，如果有兴趣建议直接去店里摸。我相信它会是直角边框的直屏机中，手感最好的之一；但即使如此，与12S等更小弧度更大的机型相比，仍然存在着天堑。

性能

传说一人名唤Nuvia，窃爱剖思力空之灵魂而降下凡间。高通观其材，以为重任。乃作Oryon，……编不下去了。早在Nuvia团队在高通的第一个作品，搭载Oryon核心的骁龙X Elite发布时，许多媒体就曾提到，其微架构与苹果M系列有许多相似之处。只是骁龙X系列的笔记本价格都降不下来，Windows又祖传拖后腿，导致掩盖了Oryon的光芒。这次我可以非常肯定地说，8 Elite没翻车。

Geekbench 6 CPU常温跑分2902/8982（链接），6℃ 冰箱跑分3068/9527（链接）；3DMark Wild Life Stress Test稳定性73.4%，Wild Life Extreme得分5719（约为RTX 4060 Ti的23%）。

HyperOS 2

常言道，金凡一年闭关一次，一次闭关一年，老实说去年出关后还是带来一些明显的体验提升，可惜后面支棱不起来了。看起来目前的剧情走向也差不多，称不上不好，至于后面拉不拉，要等半年多后才有答案。

传统体验

并不像前两年首发只能买到半成品，新机更新首日包后据我体验问题不大。还是有些米味bug，但称一句丝滑还是OK的。

新版本系统优化最大的还是跟手感，包括滑动阻尼感和点按的响应速度等方面。桌面上下了大功夫，基本上是指哪打哪，甚至还有点不习惯；而这样的跟手感很可能真的归功于系统自身的优化，因为这样的跟手感是我在以前小米高性能机型上从未体验到的。桌面还添加了大量的模糊效果，据某些媒体的说法，可能是用了之前下拉通知栏同款的模糊效果，所以性能开销没有那么大。应用加载速度也有提升了，个人观察使用了非常激进的预加载。还好砍掉了坑人8GB内存版，不然不得不区别对待又要有人闹了。

如何测量“跟手感”呢？就比如从桌面启动应用，可以用另一台手机的慢动作拍摄，测量从点按到出动画所需的时间。相机作为传统重量级杀后台项目，小米12S用了0.15s出现点按特效，又用了0.21s出现缩放动画，而小米15整个过程仅用了0.06s；国民3A大作淘宝，小米12S用时0.25s，小米15用时0.05s。当然两台手机平台不同，相机app也不完全一样，主要图一乐，但顿一下的感觉确实没有了。

高德地图、淘宝、美团等国产3A大作的流畅度偶有掉帧，但称得上流畅，不过每个高性能机型刚发售的时候也都是这种感觉，这个仍然需要时间检验。在淘宝等app上似乎有一个比较鸡贼的策略，那就是提高阻尼感，降低滑动速度，这样同样的手势，内容的滚动速度就会更慢。但这个没有量化，图一乐。

去年为了一个最小系统占用的flag，“瘦身”了一连串功能，包括我十分需要的日历iCloud登录；今年终于拨乱反正，克制地给系统应用加一些功能。不过更多的系统应用没啥变化，该割裂的还是割裂，感觉重点全放在基础界面上了。顺便一提，小米15官方完整包的大小超过了7GB，这也可能是内置了诸如语音转录之类模型的原因。

比如应用详情页面也算是拨乱反正，之前电量消耗和省电策略、流量消耗和联网控制分开我就忍了，“权限管理”“应用管理措施”都分成两个，就真的不能理解了。这次一合并就简单多了。

合并前后的应用信息页

由“屏幕时间管理”升级来的新版“健康使用手机”功能并不是简单的改名，而是加入了健康用眼检测，依赖的可能也是类似于注视感知的东西。它会识别你的动作，如距离过近、长时间用眼、躺卧用眼等，并给出提示，以及统计不健康用眼的时间。由于一般使用时都是直盯手机，这个比注视AOD要灵敏不少。然而禅定专注模式的入口不知道被藏到哪里去了，只能搜索找到。

小插曲还是有一个的。在等待解BL锁的72小时内，我登录了Google账户，下了些软件；而到解锁清除数据后，突然发现死活设置不了锁屏密码。一查才发现，在Android 15下，恢复出厂后需要重新登陆Google账户才能设置锁屏密码，而国行机器由于你懂的原因并没有这一步明确提示。

AI

许多AI功能已经在新系统上得到了实装（或者改名），事实证明也并非都是噱头。但我觉得目前很大的一个问题是，有哪些功能是可以完全离线的，有哪些是使用了云端模型，有哪些虽然使用了端侧模型但需要联网。由于国内的审核政策限制，恐怕第三种方式会比想象中多。

曾经一台小米手机上有三个不同的语音转录方式：小爱字幕、小米闻声和录音机转录，除讯飞听见外，均使用离线转录。然而新系统上把小米闻声砍掉了，然后给录音机加上了实时转录功能。转录要联网，目前不知道是在线转录还是在线审核输出内容。至于转录效果如何，我使用手机录音机录了一段某湖南塑普课程的音频，分别使用录音机实时转录、录音机后期转录和 Belle-whisper-large-v3-punct 模型转录，结果如下：

实时转录：当然这种机会很少，一八。年不到你去了对这个东西。我们一般都最多是来这个设计的数据库。所谓设计一个数据库就完了，就是你需要把这个。自己股价。就是您的表结了个价那么这个表表结构价我这个东西大概随时带了一个例子……
后期转录：当然这种机会很少。一八年不到，你去了这个东西。我们一般都最多时间就设计一个数据库。所谓设计一个数据库就完了，就是你需要把这个。自己股价。就是您的表结了的价，那么这个表结的价，我这个东西大概可随时带入一个例子……
Belle模型转录：当然，这种机会很少，你把它引发到你去来建立的东西。我们应该做最多是来设计一个数据库，所谓设计一个数据库做完了。就是你需要把这个数据谱给建好，就是你的表结构的建好。那么这个表结的建好，我这个可随时带了一个例子……
人工转录：当然这种机会很少，你一般你不需要建这个东西。我们一般一般最多做的事情就是设计一个数据库。所谓设计一个数据库，说白了就是你需要把这个数据库给建好，就是你把表结构给建好。那么这个表的结构建好，我这个东西大可随时带着一个例子……

嗯都挺图一乐的，哪怕是拉来参评的1.55B规模的大模型也不是很完美，毕竟这玩意要吃好几GB显存呢。但很惊喜的是小米转录可以识别如MySQL的一些特殊读音（即my-sequel）。

相册的AI功能也得到了一定的扩充，在本地的魔法消除基础上，增加了画质修复、扩图和更强的修复等功能。但这些新功能中也有许多用的是云端模型，而显然在云端跑模型是要花厂商的钱的。在HyperOS 2根本没大规模推送的现在就因“使用人数过多”而限流，之后的体验将会如何也可想而知了。新系统还使用了基于图片内容的图片搜索，包括类似CLIPS的语义识别、人脸识别和OCR文字提取等。所有功能均可在本地完成，即使不开小米云服务也可使用，精度也勉强可以，起码中文语义搜索是强于许多开源CLIPS模型的。

相比领先的友商，系统的主动建议仍然是落后的；它甚至算AI都有些勉强，但这里还是按照营销词汇来划分。在iOS数年前就支持按照日程位置路程提前提醒的情况下，小米到现在还仅支持手动设置时间；行程助手不出意外也是Hyper OS 1的东西，举例来说，有多段换乘行程的时候也并不能自动识别。

其他的比如什么AI生成动态壁纸什么的，评价为十分鸡肋，虽然某种程度上也算是一种自定义超级壁纸？而且也需要调用在线模型。

影像

仍然需要注明的是，小米提供了两种色彩风格选择，徕卡经典和徕卡生动。前者虽然不像初代联名的小米12S一样风格浓郁，拍摄食物效果也不再灾难，但相比后者，仍然具有较高的对比度和较低的饱和度。作为在相机里直接给开关的先驱，这方面还是可以信任的。

下文中的相机对照组为索尼ZV-E10，镜头腾龙17-70mm F2.8和索尼55-210mm F4.5-6.3。相机样张经过ARW格式后处理。争论手机和相机的效果好坏当然是不公平的，这里放相机的效果只是为了让读者明白，这台手机能做到多少。

如果真的要从出片的角度来说，小米15仍然是主摄战士，其他焦段主打一个能看就行。在大部分场景下，主摄是能够让人满意的；但在小部分场景中嘛……请看样片。

主摄样张 1，1/313s，ISO 50

主摄样张 1（相机对照组），17mm，f/5，1/100s，ISO 100

小米还是发挥了它的优良传统，对各种植物的处理欠妥，顶部的树叶糊成一坨，观感极差。地面的细节尚可，只要不太追求数毛，我认为是够用的，毕竟需要细节的时候不会用主摄焦段不是吗。

主摄样张 2，1/1000s，ISO 50

主摄样张 2（相机对照组），17mm，f/5.6，1/400s，ISO 100

这组样张，手机的曝光有些过度，远处的校舍发白，反而把近处的短处（没错，又是树叶）给展现得淋漓尽致。这两张样片使用的都是徕卡经典风格，或许在这种场景下换成徕卡生动会更讨喜。个人感觉理解用户的意图可能比留开关更加好，但现在来看并不能理解准确。

超广角依然不支持自动对焦，四舍五入只需要负责广就行了。

长焦主打一个功能性，即拍到为主，不太能追求画质。特别是光线不太好的条件下，基本相当于没法成片。

暗光长焦样张，1/17s，ISO 6400

光线充足的情况下，这颗长焦也并不能当作望远镜使用。

长焦望远样张，13.3 倍（等效 306mm），1/714s，ISO 50

长焦望远样张（相机对照组），210mm，f/6.3，1/500s，ISO 100

这个机型也配备了长焦大模型增强功能。由于端侧大模型参数量限制，在较简单的场景下可能确实能提高锐度和纯净度，但在复杂场景下几乎是必定会出问题。左侧体育馆墙壁上的砖缝已经算是简单场景的代表了，但经过一通瞎算，仍然失去了大部分纹理。再比如远处道路上的车扭曲变形不说，艾滋病红丝带已经变成小红人扣篮了。

这个长焦的微距，光线略暗一点就比较废，虽然具有10cm的最近对焦距离，但与前几代的专用长焦微距相比完全不可同日而语。这颗JN5长焦在小米15上仍需9cm的最近对焦距离，这导致其并不能离得够近大力出奇迹，就像小米12S一样。所以你网上看到的长焦效果都是光线充足的情况下拍出来的。备注：小米15拍摄的微距样张均经专业模式手动峰值对焦。

室内长焦微距样张，1/105s，ISO 1250

室内长焦微距对比。左：小米 15（经裁切），1/17s，ISO 5000；右：小米 12S，1/20s，ISO 1673

前摄有了低功耗注视感知特性，所以可以做一些自动AOD和用眼健康检测之类的功能。但是这个功能并不是很好用，因为前置的视角并不大，导致比如手机平放在桌子上，瞟一眼AOD就不会亮；采样间隔也太高，经常要等好久才能检测到。

视频方面也算是常规升级吧，后置三摄均支持4K 60FPS杜比视界，均支持至少720p原生480FPS慢动作。在后续更新中已经支持了4K 60FPS杜比视界录制过程中切换镜头，个人认为还是比较丝滑的。

另外，在不为人知的角落，在Adobe Camera Raw 10月更新中，已经添加了对小米15/Pro的支持。

显示

屏幕素质并没有一些媒体所言那么差，也可能是这两年国产屏人均提升太大了吧。

可视角度的不足主要体现在亮度的损失上，而偏色显得不是那么严重。这次的自动亮度出乎意料地激进，很亮，这更容易让人感觉更通透，也体现了厂商对于功耗的极度自信（也可能是首发促销伎俩）。发色看起来也更冷，某些媒体说是因为什么CIE 2015白点值不同造成的。

这代上了一个似曾相识的新功能：全屏AOD。说白了，就是全屏幕都有内容显示，而非传统息屏显示，仅有时间、通知图标等内容点亮，其他全黑。那有人会问了，不是说LCD屏幕不能做AOD的原因，就是全屏点亮很耗电吗？还是先来看看友商是怎么做全屏AOD的吧：微软Windows 10 Mobile的全屏Glance Screen，似乎只有一部分像素点是亮的，刚好够显示出图案，其余不点亮；而苹果则利用了LTPO的特性，把刷新率降到1Hz，尽量降低息屏时的功耗。这两种路子，都是现有LCD屏幕依然做不来的。

全屏 AOD 的效果。值得一提的是，壁纸是自己拍的。

目前看来，小米选的路应该主要是后者，息屏时刷新率降到1Hz（其他场景刷新率升降也非常激进），但全屏点亮。再加上默认“智能点亮”模式较低的注视传感灵敏度，实际息屏时平均点亮的像素数可能不升反降了。但不得不提，小米现在的全屏AOD不支持息屏光效和通知图标，可以显示完整通知但画面完全静止，食之无味弃之可惜，新鲜劲儿一过就关了。

通信

相比于本就令我满意的小米12S，小米15的信号表现确实有较大的提升。

WiFi信号确实有一定的提升，在同一位置下，大部分时候握手速率都高于小米12S，强度高3dBm左右。

移动网络频段出乎意料地多，一改小米非顶级旗舰大肆阉割频段的传统。不过我可见的未来又不会去北美 ~~（除非中了什么顶会）~~，所以对我没啥用。但是移动网络的信号确实有不小的提升，在楼内相同的位置下，甚至可以达到8dBm的差距；而在另一座楼地下1层，小米12S挣扎着找信号的时候，小米15已经能跑到下行40 Mbps了。

电池

老实说我觉得4500mAh其实挺足够的。平常每天也不会看太久手机，或者充电不是很困难，出去逛一晚上也正好够用，如果出门更久的话，4500也好，5500也罢，没有什么本质的区别。然而小米15把电池加到了5400mAh，迈上了20Wh的大台阶，一个三年前没人敢想的数字。

续航像是借鉴了苹果的做法，堆大电池不是因为要加续航了，而是因为要加性能释放了，起码首发系统的功耗就不见得比12S更低，估测使用时间虽有提升，但与电池容量提升幅度并不成正比。夜间耗电问题基本没什么改观，一晚上仍要用掉7% 左右。更新：升级到2.0.16.0之后，耗电有一定的改善，功耗下得去了。

与传闻不完全相同的是，它这样的新机型所搭载的50W无线充，并不会遇到老充电器就只能以30W充电，起码使用80W风帆无线充的时候，屏幕上显示的是50W。功率还是非常保守，发热解决不了，温度上限差不多在41度，充电功率大概在15到20瓦，策略很简单，除非刚充上，没过热就20W，过热就15W。

有线充电基本是钟文泽型够用。联想C135充电器（100W PD/PPS）最高功率仅为25W但还算能坚挺，也就勉强能维持1分钟充2% 的速度。室温25度下，使用自带90W充电器（MDY-14-EC，用料不是很结实的样子）和充电线，开启快充加速模式，前一两分钟能维持在60W上下¹，充满50分钟出头；若不开启快充加速功能，充满时间并没有太大差距，只不过低电量下快速补能更有效率些。也可参考一些博主的测评。

有线充电速度示意

或许会有人说，我就喜欢室温15度，上面这个结果不合适，那么下面是室温15度下的充电速度。左侧是小米15，13% 到99%；右侧是两年半用了近2000个循环的小米12S，1% 到完全充满，仅供参考。两者都使用小米15自带的90W充电套装，小米15开启快充加速。新机这个表现起码是令我不满意的。

15 度下有线充电速度对比

其他外围配置

作为一个标准版来说，外围配置是完全合格的；而作为一个4500元起售的机型，又是理所应当。

虽然和许多小尺寸机型一样配备了小尺寸0809马达，但振感更加清脆有力。然而小米自作孽把自然震感砍得七零八落，解锁哒一下，按下快捷开关哒一下，长按桌面图标和交换位置是一样的哒一下，侧滑返回不管长按还是短按都是哒一下，清后台哒哒哒三下，原来丰富多彩的触感效果，现在只剩下系统设置里的一个demo，就连那个区分度也不及小米12S，合着自然触感连全尸都没有。很难说是不是与吵着不要嗡嗡嗡的神秘群体有关。

随着超声波指纹而来的，是识别区终于回到了该在的位置。与小米5S的残废超声波指纹形成鲜明对比，这次的超声波屏下指纹解锁明显更快、识别率也高，的确是碰一下就解锁；但系统缺少提示，也没有了光学指纹的白光，导致很难准确按到传感器上。不过终归还是个适应的问题，自适应一下就行了。

NFC稳定发挥，线圈的位置也阳间。还添加了一个令人兴奋的新功能：防止靠近手机误触发选卡界面。这似乎意味着理论上是可以做根据刷卡机选卡的，至于为什么没做就不知道了。

本来还担心麦克风移到背面会不会影响正面朝上的录音效果，后来发现没有，因为这次破天荒给了四个麦克风——底部两个，背面一个，前面还有一个和听筒放在一起。有点好奇最后一个如何做降噪。

扬声器能响，非常干瘪，还不对称。响度没问题，音量大时下部机身略有震手。

有气压计，有红外。

结语

常有人提起性价比桎梏，我觉得小米终归还是很难逃离的，存储和SoC一轮涨价之后价格也终于绷不住了，价格波动受影响还是不小。但对标iPhone终于不完全是说说而已，抛开不自量力对标iPhone Pro的操作，小米近些年对数字系列的下的功夫也慢慢有了回报，在4000档位也算有了立足之地。今年高通不翻车，已足够使其守成；而系统的优化，也算是亡羊补牢。至于市场的会给出怎样的答案，我相信是乐观的。

体验已经脱离了简单的参数堆砌，面对友商横比也不再是个个参数碾压，但这也代表失去了许多大家所熟知的的量化标准。如果旧有的量化标准不能适应，是该探索新的标准，还是直接放弃量化，学苹果每款都是史上最强呢？

软件测量，仅供参考。 ↩︎

「超值」的宽体机体验：南航 CZ6043 A359

Thu, 08 Aug 2024 00:00:00 +0000

时间为2024年5月7日。思来想去这段旅程好像也挺特殊的，遂记下来。

由于各种因素的影响与竞争，国内的宽体机航线长期集中于几个超大城市之间，这意味着要在长沙体验到宽体机，无异于天方夜谭。然而有一班CZ6043，从广州出发经停长沙到达肯尼亚首都内罗毕，通常使用波音787执飞。前半程开放购票，我也得以趁着去广州玩，有机会一瞥梦想之翼涂装787的风采。

不过这787终究还是没坐上，偏偏在这一天执飞机型换成了A350-900。这次属于是意外之喜，毕竟A380退役之后，A350很快就是内地航司的旗舰机型了¹。票价670块钱，差不多是复速后京广大标杆的两倍价格，性价比当然是没有一点的，但毕竟咱们的目的是体验飞机不是吗。

18:32 广州地铁3号线，广州的机场快线，也是纵贯广州城的干线。正值晚高峰，虽然羊角把小编组高密度发挥到了极致，但并不妨碍我等了20分钟才被挤上车。

广州 3 号线的离谱间隔

19:26 五一假期过去，~~广州最大蟑螂的屁股~~白云T2也空荡了起来，值机安检还是蛮有效率的。

白云 T2 宽敞的航站楼

很不巧的是这么个宽体机竟然被扔到了远机位。座位非常充裕，黑哥也自然不少，看起来候机的人能不能装得下一架737都成问题。但大部分人拿的都是护照而不是身份证，看来我这种没事找事（误）不太多啊。~~之后不会换成A321XLR了吧~~

偶然看到了隔壁登机口电子标识牌竟然是Ubuntu，再一看log竟然是内存不足崩掉了。唉Java，很难理解一个标识牌竟然能用掉2G RAM……等等，这GNOME，上百个登机口的标识牌不会都是人工启动的吧。

崩溃的电子标识牌

约20:20 坐上了摆渡车，但与想象的不同，摆渡车非但没有将乘客很快送到某个蟑螂旁边的机位，反而径直开向了……北端的货场。

某国航货运 777F

20:38 在检票将近20分钟，开过头又倒回来后，终于到达了机场最北端的远远远机位，准备登机。停在这里的，就是墨镜侠A350-900，编号B-32ED，届时机龄仅0.9年。远机位倒也是个好事，毕竟廊桥上哪有这么好的视野。

近距离感受一下Trent XWB的震撼。

Trent XWB 引擎

不知道为啥，近年来的新飞机基本都换成薄座椅了。但相比可怜巴巴主飞国内的A320/B737来说，不管是座椅间距还是宽度，都高了不止一个档次，正儿八经的洲际级别。头枕高度可调，不同身高基本都能适应。娱乐设备更是每个座都标配，而不是弹又弹不出收又收不回的小电视。

客舱

果然不出所料，整个飞机不能说是满满当当吧，至少也是有些空旷。经济舱3-3-3的座位安排基本只有左右两边有人坐，拿A359也确实有些大材小用了；空乘配备反而不会相应减少，甚至为这架大飞机做准备还挺忙的。A350标志性的彩虹客舱灯此时并没有亮起，或许机组也觉得有些炫酷价值大于实用价值了。（~~阳光彩虹小白马~~）

俗话说，不玩PTV的飞友不是好数码玩家。我认为的核心功能（地图、电影和外置摄像头）都有，但电影资源并不是很充足的样子。屏幕是塑料覆盖，防眩光做得也不太好，但毕竟是在飞机上，所以只能李姐万岁了。

虽然是0.9年的新飞机，但娱乐系统似乎并不流畅，加载地图很慢，滑动起来比高德地图还卡。

地图滑动流畅度

（以上动图已知亮度有问题，与HDR转SDR有关。后续有时间可能会换源）

相比于数年前坐过仅提供一个机头视角的国泰B777来说，这架A359提供了机尾、机腹和机头三个视角。机尾视角来自于尾翼，基本相当于整个飞机的上帝视角，起降的时候看着这个视角非常舒适，但谁也没想到这颗摄像头会记录那么多的骚操作。看后面的图吧。

小桌板，折叠的设计。大小靠谱，收起状态下还有一个可以拉开的杯座，我觉得应该普及一下。

小桌板

21:31 菜航为了让乘客深度体验A359真是煞费苦心，留了近1个小时的“体验时间”（划去），终于从01/19跑道起飞了。跟大蟑螂说个再见吧。

广州白云“大蟑螂”

A359的噪音水平确实低得出色，但是对于带了降噪耳机的我，好像没什么影响。机上广播响起，提醒乘客空中没有客舱服务，有事自己按铃²。飞行时间确实很短，在空中一小时整，平飞的时间也就刚刚20分钟。

21:56 机组终于记起来了他们忘掉的彩虹灯。确实很炫啊，虽然效果有点杀马特。

超炫的彩虹灯！

22:32 在长沙黄花机场落地了，但后来才知道「超值」的旅途才刚刚开始。飞机很快被牵引到了212号停机位³，靠航站楼。想来长沙也没有那么多宽体机要接。

22:43 等了十几分钟，下飞机的队伍都没有动的迹象，此时机上广播提示下飞机还早，可以先在飞机上再坐一会。还好到处都是空座，随便找了个坐下，开始摆弄PTV，调到了机尾视角，开始欣赏廊桥接到飞机上的过程。

22:58 终于等来了廊桥，但只接上了公务舱。过了十分钟，高贵的公务舱看来都下飞机了，廊桥缩了回去，再也没接上来。

23:08 右舷来了个云梯车，上来几个人不知道在聊什么。此时PTV地图已经切换成去内罗毕的下一程了。

23:16 实在憋得受不了了，做个厕评。与许多窄体机在机尾的厕所相比当然是宽敞了不少，也算是比较干净。

厕所图，点击展开

厕所

23:20 云梯车没走，廊桥倒是来了——这次只有经济舱的廊桥。随着最后一个阻碍被清除，终于可以下飞机了。空乘道歉态度很好，但毕竟也不是他们造成的，还是有些郁闷。好消息是国内旅客不用过海关，毕竟也没出境。

接廊桥（已加速）

一个小时的空中时间，硬是把乘客“挽留”在飞机上三个小时，此之谓真正的「超值」所在。虽然这次像是临时换机，但黄花也不是没接过A359，不知道为什么这次如此手忙脚乱。

无论如何，还得谢谢南航呢，B787已经是目前黄花机场接到的最大客机之一，再略一施展换机大法，确实是长沙不出境就能体验到旗舰机型的少有选择了。

国航的几架B747-400过于老旧，而且可能9月就要退役了。 ↩︎
后来才发现这个“铃”是PTV上的一个按钮。 ↩︎
因为黄花T2国内区只有它配备了带两个分叉的廊桥。 ↩︎

RivaTuner Statistics Server 游戏悬浮窗入门

Mon, 22 Jul 2024 00:00:00 +0000

RivaTuner Statistics Server（下称RTSS）能够根据用户设定的悬浮窗样式，在特定应用/游戏中显示实时性能数据。它并不像游戏加加等程序一样是个开箱即用的工具，因此仍然需要进行一些摸索。

初始设置

安装环节在此略过，本文需要RTSS和HWiNFO64。

打开RTSS后，如果出现"xxx cannot be hooked right now"，可以暂时忽视。打开主界面后，需要先把 “Show OSD” 和 “OSD support” 两个开关打开。

RTSS 主界面

导入现有悬浮窗样式

现在打开游戏并不会显示任何悬浮窗，因为并没有自定义样式。为了方便，可以先从网上下一个，比如这个，或是其他的ovx文件。

在RTSS主界面点击 Setup，找到 Plugins，将 OverlayEditor 的勾勾上，然后双击它，就进入了编辑悬浮窗样式的界面。

点击左上角的 Layouts，点击 Import，选择刚刚下载的ovx，你下载的样式就被导入进来了。然后保存即可。

悬浮窗编辑器

悬浮窗编辑器上已经显示了样式预览，你也可以打开游戏试一试。当前买家秀和卖家秀基本差不多，但似乎部分数据是空的，比如CPU温度、频率和功耗等。可能因硬件而异，仅供参考。

添加并替换HWiNFO64数据源

上述的数据源均是来自于RTSS自己的测量，因此对新硬件的支持可能较差。可以从HWiNFO64中获取硬件数据，更准确，数据也更多。

先打开HWiNFO64，在启动画面上可勾选 “仅传感器”（Sensors Only），然后点击设置，勾选 “共享内存支持”（Shared Memory Support） ¹，以允许RTSS读取数据。然后，启动HWiNFO64。

回到上图中的悬浮窗编辑器，点击 Data sources，点击 Edit，即可进入数据源列表窗口。它们名称前的图标代指的是来源应用程序，如小飞机就是Afterburner，因为我没开（也不必开）所以全部显示N/A。

在数据源列表下方点击 Add，添加新的数据源。Data provider选择HWiNFO64，然后选择上面缺失的CPU温度（CPU Package）和功耗（CPU Package Power）点击OK，这样就导入了两个缺失的数据源。

找到上面显示N/A的缺失数据源中对应CPU温度和功耗的名称（CPU power和CPU temperature），分别双击上面添加的CPU Package和CPU Package Power打开编辑窗口，在 Overlay data source properties 里改为上面对应的名字，这样RTSS就会认为是不同的数据源提供的同一个数据。

点击OK，CPU温度和功耗应该都正常显示了。但还有一个CPU频率上文故意没有添加，可能是因为该CPU中有两种不同规模的核心，所以一起统计频率是不合适的。

添加数据源

使用HWiNFO64自定义传感器设计数据源

本章的目标是自定义一个数据源，从而在HWiNFO64和RTSS中分别显示P核和E核的平均频率。RTSS本身并不支持通过运算得到新的数据源，所以需要在HWiNFO64中定义。当然也可以通过简单的算术运算，得到其他的结果。在此之前建议将HWiNFO64的语言设为英语²。

自定义传感器需要编辑注册表，虽然我也不知道为什么非要这么做。以如下文件为例，该文件新建了一个叫做CoreUltraExtended的传感器，有Avg P-core Clock和Avg E-core Clock两个频率传感器指标，分别将平均P-core频率和平均E-core频率求和然后求平均。

如果你也使用酷睿Ultra 7 155H，可以将下面内容另存为 .reg 格式，直接导入；其他操作可以参考教程，对照下列步骤操作，还是看不懂的话可以让GPT解释。

reg

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\HWiNFO64\Sensors\Custom\CoreUltraExtended]

[HKEY_CURRENT_USER\Software\HWiNFO64\Sensors\Custom\CoreUltraExtended\Clock0]
"Name"="Avg P-core Clock"
"Value"="\"P-core 8 Clock\" + \"P-core 9 Clock\" + \"P-core 10 Clock\" + \"P-core 11 Clock\" + \"P-core 12 Clock\" + \"P-core 13 Clock\" / 6"

[HKEY_CURRENT_USER\Software\HWiNFO64\Sensors\Custom\CoreUltraExtended\Clock1]
"Name"="Avg E-core Clock"
"Value"="\"E-core 0 Clock\" + \"E-core 1 Clock\" + \"E-core 2 Clock\" + \"E-core 3 Clock\" + \"E-core 4 Clock\" + \"E-core 5 Clock\" + \"E-core 6 Clock\" + \"E-core 7 Clock\" +  / 8"

编辑完成后，注册表大概是这个样子。

注册表预览

现在打开HWiNFO64传感器界面，应该有了新的选项；进入刚刚的添加数据源处，应该也可以看到了。把上述新增的数据源添加进来，不用改名。

悬浮窗里每个数据，对应的都是一个层（layer）双击悬浮窗编辑器里那个空的CPU频率显示（MHz），进入层属性界面。

层属性界面

Hypertext 一栏中为该层的格式化文本，其中两个百分号包裹着的是数据源的名称，换行使用 \n 转义。通过改为上图的文本，可以实现两种核心频率的分别显示。

该选项标注的12小时限制并非12小时后必须重新开启一次，事实上重新打开HWiNFO64时会自动重启计时。但是如果HWiNFO64一直开着，那么RTSS会在12小时后自动断开连接。 ↩︎
这是一个可能的bug，调整语言后可能无法获取值： https://www.hwinfo.com/forum/threads/custom-user-sensors-in-hwinfo.5817/post-46045 ↩︎

iPad 7 面向生产力的大学四年摸索

Wed, 17 Jul 2024 00:00:00 +0000

iPad 7，不像mini、Air和Pro，连个系列名也没有，也昭示了它位于最丐iPad的系列命运。在2019年发布的它并未惯例升级A11处理器，造成性能多落后了一年，但也仍然不输小米平板4 Plus；内存升级到了3GB，闪存却仍然空过了64GB档，这为之后的别扭埋下了伏笔。幸运中带点不幸的是，我进入大学前获得的，正是32GB闪存的丐中丐，当然还有经典的插菊花Apple Pencil。

生产力，是想买平板的人常用于说服自己的理由，而对于一个砖头游戏本用户来说，确实需要平板在宿舍外生产些什么东西。四年以来，在各路网友的呼声下，平板的生产力功能也频繁推陈出新，但毕竟苹果日常佛系，变着法地利用平板仍然需要一些小巧思，从有限的性能里一点一点抠玩法。

手写笔记：写字难看者与狗不得入内

由于有大量的公式，一些工科基础课（高数、线代、大物等）使用纯文本的方式记笔记并不是很方便，由此要在平板上记此类笔记，不免出现了两种方向：一种是用软件把公式渲染出来，另一种则是把公式直接写出来。刚上大一的我自然是不懂LaTeX的，所以自然是怀着别人能我也能的想法，选择了手写笔记。

在平板上写写画画，确实是非常好的体验，不仅不用记公式符号，也能更方便地添加一些图示；在电子版课本上来回索引跳转，无损勾画，也是纸质方案难以望其项背的方面。更棒的是，拿起笔就继承了高中刷题的写字速度，理论上效率确实比用得不多的键盘强。这些各位只需走进店里试一下就能体会到。

然而，或许有不少人对平板的书写环境并没有一个足够高的预期，也包括我在内。作为一个高中时代写字就不太好看的人，挪到了平板上，因为缺少了纸张阻尼感，更是难以适应在屏幕上划拉。再加上各种因素的影响，记出来的笔记自然也是一个惨不忍睹龙飞凤舞。

惨不忍睹的线代笔记

当然根据每个人学习方法的不同，记笔记的方式自然也会不一样。但对于我能跟上老师速度的方式，已经无法保证笔记质量了，复习的时候大半精力都花在理解笔记上面了，只能抱宋浩的大腿。所以说笔记这东西最终还是得落实到看上，不想复习的笔记从记下来那一刻起就没用了。至于那些当堂用 LaTeX 记笔记的大神，落手就是各种snippet，抬手就打出一篇排版整洁的笔记，我当然只有羡慕的份儿。坦白地说，一直到毕业我也没这能力。

在线VS Code：算力与延迟的双重桎梏

作为一个计算机类的大学生，敲代码自然是十分重要的一环。就像视频编解码能offload到显卡上，TCP协议栈处理能offload到网卡上，外出编写代码能不能offload到平板上呢？

答案是能也不能：VS Code（code-server）的前端可以跑在浏览器上，而服务端则需要一台Linux主机。由于当时技术与知识所限，并不懂NAT穿越之类的技术，所以不得不租了一台远在美西的1C1G服务器。再搭配上一块K380键盘，功能上倒是跟电脑上的VS Code没有太大差距，但很容易猜到，如此远如此弱的服务端，带来的只能是等几秒才蹦出来的代码补全，代码稍一多也会卡。

code-server 的截图

半屏写代码，半屏查Stack Overflow，应该也是很常用的场景吧。然而开两个浏览器进行分屏的情况下，平板已经出现了明显的卡顿，杀后台也变得严重了起来，再开一个QQ用来水群更是几乎不可能的事情。再加上之前提到的服务端问题，于是这个办法也基本宣告放弃了。

至于iSH的方案我也考虑过，在iPad上运行接近完整的Alpine环境很有吸引力，但无奈平板性能有限，实在是不堪重负。

远程桌面：我电脑怎么关了？

有了NAT穿越的工具（如Tailscale）后，能够以极高的成功率在不同NAT后的设备之间进行直连，端到端延迟仅有40ms级别，我便得以借用其自带的远程桌面协议，在iPad上利用对我而言生产力远胜于iPadOS的系统——Windows。

正好手上来了一些VS Code搞不定的重活儿，于是我曾在极度愤怒的情况下，上着选修课，用平板和远程Android Studio大战1小时40分钟（雾）。既能拥有完整的Windows桌面，延迟又可以接受，性能也不再成为掣肘（平板当好一个视频播放器就行了），帮大忙了。事实上我那砖头游戏本在这之后基本成为了台式机，买了个架子竖放在桌子上，屏幕键盘鼠标全都外接。

这么好的方案那肯定有它的缺点对吧，那就是宿主机睡眠就连不上了。直到现在我还是不清楚Wake on WLAN怎么玩，所以只好提前估计需要唤醒的时间，然后在这之前保持唤醒；或者直接使用人力唤醒法，麻烦舍友摇一摇鼠标（雾）。3:2比例的10寸屏，在分屏时能显示的内容也过于少了。至于预想到最薄弱的环节，NAT打洞，成功率还真很令人满意，绕香港的场景还是比较少。

远程桌面，俨然一台小电脑

类Markdown笔记：首先手要快，然后忘了

手写彻底失败了，但笔记还是要记的。类Notion的笔记有很多，它们使用类似Markdown的语法，算是兼顾了排版速度和美观吧。作为一个思源笔记的用户，虽然它有完善的iPadOS端，我甚至买了它的同步服务，但我仍然只敢用Docker部署的网页端，只因32GB闪存实在是不舍得塞下数百MB的笔记数据了。

要是让我再记一次高数线代，大二大三的我大概还是跟不上；但对于计系和编译原理等专业课，则基本能够跟上敲笔记了。版式敲下来就是对的，整理的环节也更加简单，复习也就更有欲望看了。

编译原理笔记节选

随航：警惕平板便携屏化

又过了一段时间，机缘巧合用了好一段时间13寸的MacBook，便携性很强，对平板的需求并不是很大了。远程桌面偶尔还在用，但大部分事情都已经可以让macOS完成了。PC系统确实不一样，就我个人而言“生产力”起码比iPad高一个数量级。

那偶尔也有13寸屏不够用的时候，就可以用起来随航功能，直接把平板变为一个无线外接便携屏。延迟不高，耗电可以接受，其余真没什么好说的，毕竟完全不是在平板上干活了。 ~~或许可以叫做屏堕~~

结语

不是说开发平板的生产力吗，怎么依赖平板的越来越少了？先别急着骂我天天用平板NTR，咱得讲究一个论迹不论心对吧。虽然有越来越多的东西不再依赖于Pencil等苹果产品，甚至只需要一个浏览器就能跑起来，但这台平板最宝贵的仍然是它的形态。在四年的本科生涯中，它与我的游戏本起到了很好的互补作用。即使后来有了轻薄本，我也仍然喜欢那个拎起个挎包就能装着走的平板，感觉确实不一样。

如果有了更好的硬件，这台平板就能为我做更多事情了吗？我觉得也不太能。平板仍然最多是轻度生产力工具，苹果使出浑身解数也暂时没有动摇先前的发展道路，即使算上UTM虚拟机，也仅仅是一个力大砖飞的方案。

你问我平板现在用来干什么？带走看视频，偶尔填个电子版文件，没了。

《飙酷车神：轰鸣盛典》：嘉年华不是一日建成的

Wed, 05 Jun 2024 00:00:00 +0000

相信许多接触过一些赛车游戏的玩家，都觉得《飙酷车神：轰鸣盛典》（以下简称TCMF）的玩法有点眼熟，怎么，育碧也在办嘉年华？

全程联网，联了个寂寞

我从未见过三代一贯全程联网的赛车游戏，更别说稳定性越做越烂的了。我相信应该不会有人对一个经常性连不上，且连上几十分钟断一次的游戏满意，更何况我使用的还是CN2线路，大概算是中美之间民用最好的线路了。

全程联网这个事情之前就喷过一次，此次就不再赘述了。即使连上，路上也全是AI车，根本看不到活人。这个问题已经成为我眼中这款游戏最大的减分项了。更何况育碧也有黑历史，比如初代《飙酷车神》关服后，玩家就再也没法玩了，连个离线补丁都没有。

赛季活动真没几个人

地平线的另一个联网玩法是共享调校和涂装（也就是抄作业）。TCMF只有后者，可允许的涂装层数很少，而且加载很慢。更别说地平线也不用处于多人游戏也能抄作业。

与极限竞速不同的是，每周活动计分都会有排名。随便打了两个赛事，排名就来到了13841，这游戏怕是真没几个活人打了。线上联机比赛也N久匹配不到人，这下全程联网的意义就更加不明确了。

是嘉年华，更是文化大杂烩

既然有了《轰鸣盛典》副标题，那么玩法上势必与前两作大有不同。

与地平线的赛事摊大饼、故事线独立不同，TCMF的赛事完全附属于17个剧情线中。也算是RAC特色的是，剧情的质量比较一般，但确实覆盖了许多不同的赛车文化，比如JDM、美式肌肉，甚至还有方程式赛车，这下把隔壁极限竞速正作也给打包过来了（不是）。

赛事的质量可圈可点，氮气车道、P房换胎等独特机制也为赛事平添了乐趣，赛道周围契合主题的装潢也各有特色。语音不出戏就是赢，补充背景的角度上还是很好的。比地平线精心准备的四五个表演赛当然是差的，但胜在每场剧情赛事都会做一些特别设计。每个列表开始前还会播一段真人视频，但一个小槽点是视频分辨率极低，肉眼感觉像一块一块的马赛克。

丢失了全美大地图很遗憾，但地图大小还算可以接受的，比赛的长度反而相对更长了，七八分钟的赛事比比皆是。地貌也还算全，又走上了其他RAC的缝合怪老路，所幸质量还可以，基本能够随心所欲的越野，但可惜也塞了很多不可破坏的物体，比如护栏（极品飞车18似曾相识）。

总之，在办“嘉年华”这个事情上，我认为已经强于极限竞速地平线了。

车是核心，还好没丢掉

要跟地平线叫板，（不止是）车单当然要大。虽然同一个车型搞多个版本充数的行为比隔壁有过之而无不及，但育碧这次也是诚意满满地塞进了超过600种载具，个人对缺少992GT3耿耿于怀，但比NFS连丰田都没谈下来还是好了很多，品牌广度和深度都有了。

本作的车内视角是一大亮点。NFS系列模型细致但很多没有车内视角，车单也较小；FH系列车单大且有车内视角，但祖传模型精度堪忧，不忍直视。非常欣喜地看到，TCMF在这两方面同时做到了差强人意，除了车单比较大外，车内外的模型也尚可。

车内视角（McLaren Senna GTR）

作为一个娱乐向赛车游戏，手感也是十分核心的一环。相比于地平线和NFS Payback等几个较容易操控的作品来说更难，但并没有NFS Unbound那么反人类。要更注重刹车时机，推头和转向过度的惩罚也更严重。漂移风格并非傻瓜式的break to drift，而是需要一定的调校和技巧，前者在无法抄作业的情况下会显得有些门槛，日本剧情的漂移赛中手感也有些劝退。

蛮有细节，但只有一点

育碧在游戏里塞了不少细节，还没在其他游戏里看到过。比如车内视角，以五六十的速度慢慢开，车手会把左手搭在窗沿上，不操纵打方向的时候，车手也会左打右打维持车子平衡。手柄震动也相对比较细腻，虽然缺失了地平线5作为亲儿子的特色扳机振动，但是打滑、换挡、过草地等都有不同的震动反馈。

也有些细节没处理好，与上面一对比令人匪夷所思。电动车起步也有燃油车一样的引擎声和手柄振动，Motorsport赛事的轮胎消耗也似乎跟驾驶的激烈程度没有什么关系，只跟走多远有关。

画质总体上还行，但赛道有一种塑料感，尤其是稍微离远一点的时候。无需怀疑画质，我开的最高。

不只是赛「车」游戏？

到现在为止，本文提到的都是TCMF作为赛车游戏的一面。在陆地交通工具之外，本作也确实保留了前两代的载具切换，还可以开飞机或者开船。确实能开，但是能和车一样好玩吗？答案是有点难。

作为一个手柄玩家，飞机的手感还算可以理解，而且能看得出来，育碧已经很努力让开飞机变得简单了。滑行几十米就能起飞，几乎垂直往上飞却不会失速，甚至撞到地上还能拉起来继续飞，简直可以称为育碧耐摔王，~~甚至可以用它俯冲攻击珍珠港军舰~~。即使是观光任务送的飞机，也能达到250左右的巡航速度，在快速旅行点较少的前期，飞机是一个很好的点对点旅行的选择。

飞机赛事倒是蛮用心的，检查点给得比较大，而且只有一个人飞，不会出现好几架飞机钻一个检查点到处撞的情况。

游戏还把按压右摇杆分配给了快捷载具切换功能，在陆地、空中、水面各选定一种载具中切换。然而，这种切换并没有限制载具的位置，所以也可以无缝从飞机切换到车辆，就像下面这样进行一个炫酷的组合技——

这就是我们热血沸腾的组合技口牙

空-陆转换还好，在水里就没有这么幸运了。车会直接沉入水底，然后过几秒才能回到陆地上，船则更惨，在陆地上动弹不得。

甚至可以在水面上切换到车辆

至于船，则没有飞机打磨得这么好了。小船又灵活又快，当水里灵活的狗就能苟赢；大船笨重，转向不灵敏，数条船穿过一个小检查点玩家又撞不动别人，属实折磨。

《看门狗：军团》：老游戏，新思路

Sat, 25 May 2024 00:00:00 +0000

《看门狗：军团》（Watch Dogs: Legion）在网上评价似乎不咋样，不过我玩起来还是基本满意的。最可惜的地方还是欠打磨，如果育碧再像2077一样打磨三年，或许口碑会比现在好得多。然而没有如果，《看门狗》系列已经没了¹。

游戏时间17小时，已通关主线和部分支线。

狗味一脉相承

说它祖传也好，发扬光大也罢，看门狗系列历经三次迭代，也确实继承下来了几个黑客小玩法，比如接水管（连电路）游戏，扔蜘蛛机器人，或是随便找个大街上的物体黑入什么的。坦白来讲，本作真没加多少黑客玩法，接水管游戏是1里就有的，黑入车辆等也在2中已经出现了。即使是与实景融合的接水管和蜘蛛机器人，1代的Bad Blood DLC也已初具端倪。

那么军团的新东西，就是把这些东西由半生不熟做到令人爱不释手。比如任务《心智游戏》中的接线环节，坐落在整座楼中，使用无人机连线也已成为家常便饭。

接水管（连电路）游戏

再比如任务“在野兽的肚子里”中的无人机穿越服务器集群玩法，其实主要打动我的是这个建模，虽然这个玩法已经屡见不鲜了。

无人机穿越服务器集群

还有飙车！实话说，任务场景烘托下，虽然开车手感仍然比较奇怪，但是比2077的飙车好玩。主线最后也有一段在随机黑入干扰下的飙车戏，算是致敬狗1的大结局吧。

飙车

把“群像”塞进育碧式RPG

群像是本作的最大亮点，确实是几乎每个人都可招募，也都有自己独特的能力。或者不如说，本作中随机的人就是由不同的能力组合而成的。每个人都有自己的配音，而且似乎对话都很完整，也没有AI合成味儿，很难想象育碧的巨大工作量。一个人的死亡/重伤或被逮捕也不止会造成回到上一个存档点，而且需要换人；重伤或被逮捕的探员则需要经过现实中一定长度的时间才能继续操控。

游戏本身就具有多种玩法，刺客流、黑客流、狂战士流，具有不同能力的角色也算是玩法的加强。比如战斗方面，穿制服的阿尔比恩员工，或者能召唤载人载货无人机的角色，都能让出任务方便很多；支援方面，能降低入狱时间的投资人，提高医治速度的医生，招来也确实有用；即使是一群该溜子，也有乞讨技能能讨钱，或者因醉酒而提高近战伤害；甚至可以组一群老奶奶帮，虽然操控起来可能有点挑战性就是了……

除了能力之外，游戏还会为每个人生成简历。但这个简历看起来不太尊重史实……06年出生的人怎么参加脱欧公投呢？

简历

但不得不否认的是，这个群像带来的并不全是积极的作用。整个游戏的剧情仍然像是将DedSec作为一个人来看待，而并不是一个团队。在跟人对话（甚至团队简报）中，只是跟当前操控角色对话，并没有和队伍成员商量的情节；只有在几处小队语音中，队友被抓住/暴露位置时，才会感觉到这真的是一个团队。整个主线中，也只有最终战动用了超过一位探员。

而与上面团队感缺失相反的是，对每个人本身故事描写的缺失。每个人本来既有故事又有能力，一招到DedSec里，就直接融入大集体了。不过以现在的技术水平，确实很难给每个人都做一个任务。总之，如果把团队中的角色看作能换技能组换皮肤的同一个角色，就容易释然了。

地图方面，虽然对于一款旅游模拟器的期望来说，算是有点小了，但设计也彰显了育碧过人的工业实力，就已有的这片地来看质量还可以。有了无处不在的货运无人机后，载具丰富度再上一层。虽然不可否认通关方式还是那么几种，但工业化的自由也是自由，你说对吧。

本作的storytelling也维持了育碧一如既往的参差不齐。游戏有5条故事线，坦白说斯凯·拉森的那条线是真的给我造成心灵污染了，虽然基本见不到血，但是处处都透着恐怖，毛骨悚然。具体的我就不剧透了。解放每个行政区的任务也各有特色，上文提到的飙车、接线，也只是其中两种。但免不了地，大部分支线任务就显得重复度有点高了，收到线报，ctOS重建，然后去布鲁姆、阿尔比恩或其他什么地方干掉个人或者偷资料，哦大家又可以反抗了。

但不得不说斯凯的花园还是很好看的

相比本作，2077在任务的安排上就不太一样了。其主线剧情相对单薄一些，而大量的支线占了很高比例，每一个系列的支线都刻画了一个或一群人的形象。虽然从始至终能操纵的只有V一个人，但得益于剧情的深度和多样性，但就人物的刻画来说，我觉得是远胜于本作的。

任务还有个蛋疼的地方是指引不清晰，大概是育碧员工认为这已经是理所应当的了。比如任务“信息过载”，驾驶无人机引爆电池，取到电池只给了一个最终目的地，让人一头雾水不知道往哪走。还比如皮卡迪利圆环的阻碍宣传任务，完全想不到用货运无人机把挡着通风口的木箱移开……或许是我自己的问题？

情怀倒也算一种佐料

众所周知《看门狗》和《刺客信条》系列属于同一个世界观，那在前者中加一点刺客风的东西或许也是可以的吧？于是我们可以看到——

喜欢狗1/2？狗哥（艾登·皮尔斯，初作主角）整上，扳手也整上！扳手还好，狗哥是真老了，光看脸差点对不上号。本作缺失的大停电通用技能，在艾登身上补回来了，但作用范围削弱了；而扳手的技能则是召唤货运无人机，满伦敦飞比开车都方便，实乃速通必备之选择。

狗哥+信仰之跃

喜欢刺客信条？信仰之跃整上，“同步”玩法也整上，跃下甚至有鹰叫，只是没有稻草堆了；再来一个弗莱姐弟（《刺客信条：枭雄》的双主角）的后代作为可操控角色，可惜是个黑妹。获取刺客装备甚至有专属地图专属任务（见下图）和三位前代刺客的雕像，布置了很多刺客信条式跑酷，但手感实在不咋地，远不如枭雄的跑酷行云流水。

《刺客信条：枭雄》

但是——上面这些喜欢吗？都是季票里的内容哦。嗯，不愧是育碧，卖情怀再赚一笔钱，但在这游戏里看到这些元素还是蛮新奇的。

https://www.reddit.com/r/watch_dogs/comments/1cb4bfa/watch_dogs_franchise_dead_following_latest_flop/ ↩︎

ThinkBook 14+ 2024 的 TGX 外接显卡指南详解

Fri, 10 May 2024 00:00:00 +0000

TGX接口是联想在ThinkBook 14+/16+ 2024酷睿版上引入的高速接口，其在现有OCuLink基础上增加了热插拔功能。下文中会混用TGX和OCuLink两种描述，当使用TGX的时候，特指联想的这套方案；而使用OCuLink的时候，也适用其他厂商的通用方案。即便如此，本文仍然较多针对ThinkBook的热插拔方案，其他机型酌情参考。

使用显卡坞为开源宇宙EG01M（V410母板）和EXPGDC OCuP4V2；显卡为铭瑄RTX 4060Ti 8G小瑷珈（双风扇）；笔记本为ThinkBook 14+ 2024 Ultra 7，性能挡位为“极致性能”。任一设备不同都极有可能出现不同的表现，仅供参考。

理论性能测试

OCuLink本身并没有类似雷电那样的转换，因此理论上带宽没有任何损耗；但通常使用场景下需要很长的延长线，所以延迟会较高，信号也很容易出问题，且PCIe 4.0 x4喂不饱许多高端显卡，所以实际体验仍会不及理想状态。但在信号质量良好的情况下，不同的显卡坞之间损耗差别不会很大。

下列测试如未提及均为离屏，没有画面回传开销，所以默认无需分开测内外屏。

GPU-Z 信息

一些3DMark跑分：

Time Spy 综合12587分，显卡13134分，CPU 10187分；
Steel Nomad DX12 2930分，领先同显卡平均水平1.63%；
Speed Way 3167分，落后同显卡平均水平0.93%；
Time Spy Extreme 综合5925分，显卡6177分，CPU 4816分。
PCI Express带宽跑分：5.99 Gbps（接外屏，混合输出）。

笔记本架高的情况下，CPU全程温度不低，而4060Ti温度完全上不去，看来双风扇真的完全够。查阅3DMark数据库得知，上述跑分基本持平于同样显卡的台式机，而比同显卡核心（4070 Laptop）的轻薄（全能）本/游戏本有着5~15% 的领先幅度。

游戏性能测试

下列测试是分开测得，结果仅供参考。当接外接显示器时，有接在显卡上（不经过核显）和接在笔记本上（经过核显）两种方案，类似于部分游戏本内屏的“独显直连”和“混合输出”方案。为了便于理解，套用该称呼进行测试。

外屏接在独显上时，必须由独显负责渲染。虽然此时不会给核显造成压力，游戏帧数可能更高，也无需重复插拔笔记本上的显示输出接口，但热拔时为了稳妥，需将所有使用独显渲染的应用移至核显，此时使用混合输出就较为方便。另外运行在独显上的应用也会占用显存，对于吃显存的程序比较不友好，在核显上运行可以将部分显存压力转移至内存。

需要注意的是，以下游戏帧率数据并非主要用于对比损耗（事实上很多项目画质都不一样），主要是展示一个实际使用的预期。

内屏

内屏的分辨率为3072*1920，比一般人配的2K外接显示器渲染压力更大，也会给核显带来更大的压力。默认均以满分辨率运行。

《原神》¹ 4.8版本最高画质，1.5倍渲染，须弥城跑图基本稳定60 FPS，有所跳动。

《原神》，内屏

《原神》，内屏（帧生成时间图）

《崩坏：星穹铁道》¹，最高画质，2.0倍渲染²，「黄金的时刻」跑图，平均38.1 FPS，1% Low 28 FPS，0.1% Low 15.1 FPS。调整到1.4倍渲染后，帧率表现就正常很多了，属于能够流畅游玩的水平。

《崩坏：星穹铁道》，内屏

《崩坏：星穹铁道》，内屏（帧生成时间）

《飙酷车神：轰鸣盛典》，最高预设，自带基准测试平均46 FPS。

《飙酷车神：轰鸣盛典》，内屏

《看门狗：军团》，预设“高”+光线追踪“适量”+DLSS “质量”，自带基准测试，平均49.3 FPS，1% Low 36.9 FPS，0.1% Low 16.4 FPS。值得注意的是，基准测试报告已经提及了CPU瓶颈。

《看门狗：军团》，内屏

《看门狗：军团》，内屏（跑分）

《极限竞速：地平线5》，预设“极端”，开启NVIDIA DLAA，自带基准测试，平均59.9 FPS，1% Low 48.7 FPS。用MSAA替换DLAA，帧数类似。FH5确实是优化比较好的游戏，只不过吃显存有点太多了。

《极限竞速：地平线 5》，内屏（跑分）

《黑神话：悟空》（性能测试工具），超采样清晰度100%，光追关闭，其他均为高，平均帧率31.8 FPS，1% Low 25.8 FPS。将超采样清晰度设为预设推荐的37%，平均帧率71 FPS，有几次明显感知的卡顿；小核负载较高，怀疑存在调度问题。

《黑神话：悟空》，内屏，DLAA（跑分）

《黑神话：悟空》，内屏，超采样 37%（跑分）

外屏，混合输出

外屏的分辨率为4K，使用雷电4接口连接显示器。

《原神》¹，5.0版本最高画质（仅供参考，5.0版本提升了画质），1.5倍渲染，须弥城跑图平均52.6 FPS，1% Low 20.6 FPS。并未爆显存，但出现了非常明显的帧数波动。在将渲染倍数调整至1.0倍之后，流畅度可以接受，基本稳定在60 FPS。

《原神》，外屏混合输出

《原神》，外屏混合输出（帧生成时间图）

《极限竞速：地平线5》 由于显存原因，应该难以使用内屏的画质完成测试，因此降低了部分画质，基本能够流畅运行，效果见下。

《极限竞速：地平线 5》，外屏混合输出（跑分）

《黑神话：悟空》 （正式版游戏）也换了画质，使用的是我一般玩的时候使用的画质。一般赶路时还算流畅，打怪时可掉到50帧左右；显存占用较为极限，在跑分结果页就可看出，在火焰山翠云殿等复杂场景下由于爆显存，帧率会暴降至30左右。在DLSS性能档，会出现较多升采样带来的远景颗粒感，主体则相对不会太糊，相对而言可以接受。

《黑神话：悟空》，外屏混合输出（跑分）

《看门狗：军团》 在分辨率提升到4K时，仍然是一个非常吃CPU的游戏。使用推荐画质（见下面第二张），平均帧率仅能达到43 FPS；而开启了DLSS质量档后，帧率基本稳定在60 FPS，但似乎爆了两次显存，帧数降至20 FPS左右（见上面第一张）。

《看门狗：军团》，外屏混合输出（跑分）

《飙酷车神：轰鸣盛典》，与上面画质相同，平均帧率42.3 FPS，1% Low 36 FPS。少见一些小卡顿。显存占用怎么还更低了……？

《飙酷车神：轰鸣盛典》，外屏混合输出（跑分）

《飙酷车神：轰鸣盛典》，外屏混合输出（帧生成时间）

《崩坏：星穹铁道》，上述画质不变，在使用，在2.6版本更新「折纸大学学院」地图后，出现了剧烈的卡顿，在中央广场上平均帧率只有约30左右。同时，显卡占用率仅有三分之二，CPU功耗却居高不下，在45~50W左右。怀疑是CPU瓶颈造成的。

外屏，独显直连

懒了，可能不测了

方案

这一段主要聊聊现有OCuLink显卡坞的产品。

品牌

联想为自己的TGX接口研制了专用的显卡坞，具有定制的协议，所以这也是目前只有联想笔记本能做到热插拔的原因。联想官方TGX显卡坞相对来说比较精致，用料也足一些，确实能够配得上1000块钱，只不过对大部分人来说应该还是贵了。理论上应该是最稳定的，售后大概也不好意思不理，但仍有报告蓝屏的现象。仅支持N卡和带TGX接口的ThinkBook机型。传闻称其热插拔的秘密在于主动线。

开源宇宙（开原宇宙、开猿宇宙、GZOSMETA）³ 主业为GPU服务器（我怀疑就是矿机），显卡坞是个副业，但是宣传比较卖力，销量和知名度相对也较高。光淘宝就有三个官方店，其中包含一个官方二手回收店（目前不知道是否良心），客服人手似乎较紧缺。型号相同的显卡坞可能有多种规格（母版、静音电源风扇等），买二手前需先问清楚。在618前后做到了TGX接口N卡热插拔，A卡比较玄学（可能由于信号原因）。有一个售后群，进去摸底比较方便。由于不太乐意加独立信号增强芯片，成本确实低了（体现在618折扣上），但线必须焊在母版上不能插拔，而且长度有限制。玄派的显卡坞也是其贴牌产品。

EXP GDC 知名度不太高，之前在国际市场摸爬滚打比较多。在联想TGX显卡坞量产开售前做到了TGX接口热插拔。部分产品用信号增强芯片，做到了可换线，以及可选1m线 （实测50cm够用）。热插比较考验手法，但失败重插即可，目前没遇到过蓝屏。客服响应还不错（毕竟没有那么多人买）。

天钡主业是做迷你主机，有一款AG01，顺便也上了TGX热插拔。其余的不了解，不评论。

诺方恒科 （同时经营淘宝店“DIY玩家世界”）是这些厂商中支持热插拔最便宜的一个（转接板仅170元），但产品也较为狂野（低情商：简陋），就一块板子，明说了没有技术支持。其余不了解，不评论。

有些其他的OCuLink显卡坞厂商，未做TGX热插拔，对于TB14+ 2024用户来说，我认为没有购买价值。但是现存的OCuLink显卡坞也可以使用。

形态

较为早期的显卡坞，有许多是在母版上面安装电源和显卡，开放式无机箱的方案，如开源宇宙GK01ATX、EXPGDC OCuP4V2等。电源必须自己配，是好处也是坏处，因为RTX40系显卡的功耗不那么高，高质量的低功率电源却难以找到；由于是开放式设计，理线和噪音也需要多考量。我为了带4060 Ti买了个全汉MS450，虽然这玩意是有名的刚过及格线，但好在低负载风扇声音非常小⁴，而且是全模组电源，我认为是TDP 450W以下显卡的性价比与体验最佳平衡点。开源宇宙、EXP GDC和诺方恒科均有该形态的产品。理论上PCIe可能与5GHz WiFi的频段互相干扰，ThinkBook产品经理指的可能就是这件事。

有的厂商会单独卖个壳，把母版、电源和显卡一起包起来，也有的厂商选择一块儿卖。多点儿电磁屏蔽效果，美观和便携性也强一些。散热倒也不用担心，外接显卡的散热基本是最好做的了。

开源宇宙喜欢设计很多形态，如EG01M将一个长城CRPS电源放置在母版和显卡下方，有效地节省了桌面空间，该形态也被天钡学去。EXP GDC还设计了一个使用笔记本现有电源或氮化镓充电器的方案（OCuP4GaN），最高330W，价格比较高，我觉得不值得。

显卡搭配

首先讨论范围限定于NVIDIA和AMD显卡。其他小厂主要是驱动仍然不够稳定完善，无论是新购还是已有，个人都不建议尝试。在这两家中，外接AMD相比于NVIDIA稳定性又更差，尤其是数个GRE特供卡。A卡要实现开源宇宙显卡坞的热插拔，不光需要外接显示器（或欺骗器，否则显卡不工作），而且还有运气的成分在；而联想原厂TGX显卡坞则完全没有提到A卡支持。本节后续将主要以N卡作为例子，可以自动带入对应等级的A卡。

不支持PCIe 4.0的老型号也不建议购买。即使实际性能可能较强，它们也只能运行在PCIe 3.0 x4（甚至更前代）的带宽上⁵，即32GT/s（约4GB/s），相比上限PCIe 4.0 x4的64GT/s低了一半。在台式机上，与PCIe 3.0 x16相比，x4会带来平均约8% 的损失，且损失随分辨率降低而升高（以2080Ti为例⁶）。类似的带宽瓶颈还存在于RTX 4080或更高性能的型号上。个人观察来说，有较多购买RTX 4070/4070S/4070Ti的用户进行外接，网络上也可以找到很多搭配这些型号的测试，这些型号损耗一般在10% 以内。

性能不太高的显卡，新购外接也要斟酌一下。RTX 4060移动端和桌面端规格完全相同，在散热较良好的16寸笔记本内，独显型号和核显外接，游戏性能没有本质差距，反而因信号不佳，更容易出问题；而在捉襟见肘的14寸空间内，伴随着天选Air的发布，独显本TDP的分配也更为充裕了。因此对于该等级的显卡，更应考虑CPU的性能需求，而非仅仅游戏性能。至于更低规格的卡，则外接的必要性更低。

当然，上面围绕着新购的场景说了这么多，并不完全适用自己有卡的场景。哪怕是自己有A卡或者老型号，在有适合笔记本的情况下，也可以组来试一试，许多显卡坞厂商的退货政策非常宽松。

我适合用TGX外接显卡吗？

个人意见，不建议任何【对PC硬件没有充足了解】或【对稳定性有更高要求】者，现阶段购买使用OCuLink（含TGX）显卡坞。例如，即使是使用联想原厂显卡坞，也仍然有一些小问题，而且不一定是显卡坞造成的；开源宇宙虽然经过长时间迭代，售后群内也仍然出现零星的不认卡、蓝屏等问题。

另外除了稳定性和上手难度问题外，综合与类似方案（独显轻薄本、传统游戏本、轻薄本+台式机、雷电显卡坞）的比较，我认为符合如下条件的人群可以尝试一下：

在乎显卡的性能释放/升级空间。14寸配的独显基本都4060封顶，而显卡坞大多为开放式设计，散热条件极佳，也可以换更高端的卡。雷电显卡坞损耗很大，无法实现线性的性能增长。需求较低时（低于60级别卡），无需外接。
不那么在乎CPU性能。酷睿Ultra的表现大家有目共睹，与游戏本/台式机的标压CPU有较大差距，而且没有更换升级空间。不过分离显卡确实可以给CPU多分点功耗。
需要较强的便携性，而且懒得同步资料。前一句针对的是游戏本，后一句针对的是轻薄本+台式机。只是受限于CPU性能释放，带OCuLink的本不会太轻薄。
不需要任何地点都有较强的性能。显卡坞不适合也不便于频繁运输，就像台式机一样。独显轻薄本的便携优势仍然十分明显。
需要性价比，但不追求极致的性价比（仅计新购）。4070的游戏本都干到6500价位了，但OCuLink方案仍比雷电扩展坞和顶级独显轻薄本便宜。
不太在乎噪音。ThinkBook 14+ 的散热并不算很出色，且轻薄本风道设计导致恼人的高频噪音明显占比较台式机与游戏本大。
不在意买N卡。这倒也是稳定性的一环，A卡玄学问题还是有点多，更不要提什么I卡什么摩尔线程了。

总结

虽然OCuLink外接显卡并不是什么新东西，但由于破坏性开孔等原因，一直是小众的玩具。直到联想在机身上自带了TGX，并实现了热插拔，才真正使其接近实用。未来联想会不会推广此方案、其他厂商是否有动力实现还是未知数，但起码目前，TGX已经从玩具到实用迈出了最大的一步。

然而还是可以看到，本代ThinkBook 14+ 的方案仍然有一些不该有的问题。除了原厂也无法解决的稳定性问题外，还有CPU日常高居100度以上的高温以及随之而来的频繁撞墙&噪音，这显然不是令人满意的表现。

希望之后的产品能够安心做好CPU的散热，为主板加强保护，以及更多厂商参与到类似TGX的热插拔OCuLink机型上来。如果联想的方案经过不断的改善，成为了事实标准，那么生态对玩家来说也会好很多。

值得注意的是，米哈游的游戏在使用外接显卡时，常出现一些不同寻常的卡顿，期间帧率降到个位数，声音明显卡顿，输入延迟以秒计，持续数秒的样子。其他厂商的游戏（包括同样使用Unity引擎的《城市：天际线2》）未出现该种情况。至于是不是显卡PCIe带宽瓶颈，还有待排查。 ↩︎ ↩︎ ↩︎
实际游玩时2.0倍渲染和1.4倍渲染几乎没有区别。1.4倍渲染时即可达到稳定60 FPS。 ↩︎
由于商标问题，这四个名字皆有使用。产品设计并不开源。 ↩︎
MS450在温度不太高的时候可以停转风扇，但由于显卡待机时也会有发热，通过背板将热量传递给电源，所以风扇会持续低转速旋转，噪音几乎无感知。 ↩︎
把PCIe类比成水管：RTX 2080 Ti具有16条直径为8的水管，即使接上显卡坞上4条直径为16的水管，也只能看作4条直径为8的水管来用。 ↩︎
均为游戏测试；见 https://www.techpowerup.com/review/nvidia-geforce-rtx-2080-ti-pci-express-scaling ↩︎

安装 Arch Linux 「未曾设想的道路」

Thu, 02 May 2024 10:06:00 +0800

TL;DR：使用EndeavourOS的LiveCD可以与官方ISO一样安装Arch Linux，还能享受Gparted、浏览器、文字编辑器等图形界面软件的便利。

在数次尝试中，使用Arch Linux官方LiveCD的tty界面安装系统总是令我感觉十分不便，或许我还是需要一个带图形界面的安装器，但又不愿意抛弃命令行安装方法。然而，虽然Arch Linux并没有提供图形化LiveCD，但是与其共享同一个软件库的EndeavourOS有啊！LiveCD里带的工具也算比较全乎。

理论存在，开始实践。

分区

分区反倒是我觉得最困难的。

这一步要先考虑好将内核镜像装到EFI分区还是系统分区 /boot里面（对应 EFI 分区的挂载点）。前者会多花至少100MB空间，但不管怎么样，都应该先保证EFI分区空间足够。联想给了一个仅260MB的EFI分区（/dev/nvme1n1p1），而且后面跟着的就是MSR和Windows系统分区，不敢动，所以选择后者，又不是不能用.jpg。

然后可以先将Arch的系统分区分出来了。我分了一个Btrfs分区（/dev/nvme0n1p2），有两个子卷 @ 和 @home，分别挂载到 / 和 /home。分区操作很容易使用Gparted搞定，然后在终端中输入：

sudo btrfs subvolume create /mnt/@
sudo btrfs subvolume create /mnt/@home
sudo umount -R /mnt
sudo mount -o subvol=@ /dev/nvme1n1p2 /mnt
sudo mount --mkdir -o subvol=@home /dev/nvme1n1p2 /mnt/home
sudo mount /dev/nvme1n1p1 /mnt/efi

这时候带一个桌面环境的LiveCD的优势又体现出来了：可以一边用Gparted看分区，一边在终端里操作。

安装

然后就是正常的安装流程了。换完源之后进入root账户，然后：

1
2

pacstrap -K /mnt base linux linux-firmware nano intel-ucode btrfs-progs networkmanager iwd man-db man-pages # 每人需要的包不同
genfstab -U /mnt >> /mnt/etc/fstab

建议在生成完fstab之后检查一下，确定btrfs的子卷挂载点是对的。然后就是chroot进入新系统，设置时区和硬件时间：

1
2
3

arch-chroot /mnt
ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime
hwclock --systohc

以及本地化、主机名、密码等等，参考Arch Wiki就行了，不要忘了。也可以先enable一下NetworkManager和iwd的service。

然后是引导器，我使用rEFInd，先按照Wiki中的步骤安装即可，会自动添加Btrfs驱动。注意其chroot环境下会添加LiveCD的分区信息（而非新系统的），所以不如全图图掉，从 Arch Wiki 示例上换个新的 /boot/refind_linux.conf（chroot路径），以下配置已加入Btrfs子卷配置。

plaintext

1
2
3

"Boot using default options"     "root=PARTUUID=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX rw rootflags=subvol=@ add_efi_memmap initrd=@\boot\intel-ucode.img initrd=@\boot\amd-ucode.img initrd=@\boot\initramfs-%v.img"
"Boot using fallback initramfs"  "root=PARTUUID=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX rw rootflags=subvol=@ add_efi_memmap initrd=@\boot\intel-ucode.img initrd=@\boot\amd-ucode.img initrd=@\boot\initramfs-%v-fallback.img"
"Boot to terminal"               "root=PARTUUID=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX rw rootflags=subvol=@ add_efi_memmap initrd=@\boot\intel-ucode.img initrd=@\boot\amd-ucode.img initrd=@\boot\initramfs-%v.img systemd.unit=multi-user.target"

这时候图形界面的另一个优点就体现出来了，可以直接从Arch Wiki里方便地复制内容。这里的PARTUUID可以用 blkid 查看，输入Btrfs分区的UUID即可（子卷的你也找不到啊）。另外不要忘了针对性地更改 /efi/EFI/refind/refind.conf（chroot路径），以检测Arch Linux initramfs和Btrfs子卷。

确定步骤都正确走完了的话，就可以重启了。rEFInd会自动把自己设为默认的。

后续工作

重新启动后当然是tty了，用NetworkManager连上网之后，就可以装些别的了。我装了这些：

`1`	`sudo pacman -S gnome sudo vi adobe-source-han-sans-otc-fonts`

仅供参考，有需要的自己装就行。

ThinkBook 14+ 2024 体验：主流轻薄本的舍与得

Sat, 13 Apr 2024 12:33:00 +0800

配置为Ultra 7核显版，默认为最新BIOS版本

一笔带过的开箱

想看开箱建议直接去看开箱视频，B站一搜一大把的。包装比较简陋，就是一个盒子装着一个笔记本，中间填上一些泡沫塑料而已。

值得特别注意的是C面凸起问题。看起来确实是个普遍问题，但是我的机器是3月15号生产，用尺子比着还算比较微弱。但仍然建议检查一下，毕竟发货日期看起来比较随机。

C 面并无明显凸起

另外，该机器附带的Windows版本仍然能够通过 oobe\bypassnro 跳过联网验证。

不会犯错的外观

主流轻薄本的全（hou）能（zhong）趋势显然已经不可阻挡了。毕竟小尺寸高性能轻薄本确实难做，或许是为了塞下独显，正好趁着换模具的当口，联想选择了直接扩大尺寸。所以正如你看到的，ThinkBook 14+ 2024是一台 14.5寸轻薄本。

外观还是老样子，ThinkBook几百年一脉相承的外观，百看不厌的拼色A面。A/C/D面使用金属材质，目测是冲压成型，表面喷砂。边缘做了倒角，但我个人还是挺喜欢Mac割手的凌厉感觉的（）。屏幕部分的外框并不是全金属覆盖，而是B面的塑料和A面的金属拼接，略有点失望，但毕竟主流价位轻薄本不能要求太多。

另外还有一些小小的降低品质感的地方，比如C壳高出D壳的高度不一致，比如转轴两侧的缝隙不一样大，比如机身刚性略显不足，比如转轴手感和稳定性都一般，还有冲压的精致度不及CNC（怀念牢米），等等。总的来说，个人认为这个质感适合5000块钱的锐龙版，撑不起7000块钱，更别提接近万元的顶配版了。

出人意料的是，表面的金属——或者说内部的加强部件——的强度，疑似也有点太低了。在经过6个月的使用后，不知什么原因，A面和屏幕已经出现了弯曲，呈现向外凸起。即使是塑料壳的R7000，在半年内也并未出现过形变。当我用尺子抵住机身左端，右端的尺子与机身之间已经出现了3mm左右的间隙。

A 面弯曲

不够完美的硬件性能

联想做极限性能释放，你还有什么疑问么？这台机子的独显版整机性能释放达95W，实际散热能力100W左右（但因为不稳定，被联想砍了一刀），核显版的散热能力，理论上自然也不在话下。垫起机身，性能模式下，CPU单烤75W左右，Cinebench R23多核一轮16120分，连跑十分钟15784分，结束时键盘面仅温热，个人感觉三十五六度的样子。Geekbench 6单核2269，多核13150（链接）。

Cinebench R23 跑分

对于一台2024年给到75W的中高端CPU来说，这个成绩不甚理想，因为Ultra 7 155H仅有16核心22线程，即6P+8E+2L。真到拼性能的时候，十个连超线程都没有的小规模核心根本没有什么实力，主要还是靠6个性能核心。更别提大小核调度了，万一线程放置出了什么问题，性能又要打折扣了。这是Intel其一大罪。2020年的Ryzen 7 4800H仅需65W，R23多核就能跑到9000分，极限性能四年没有翻倍，我还是蛮失望的。

更让人失望的是，15W下其Cinebench R23多核得分仅有5251分，甚至不及同功耗下 4800H 的 6360 分。为什么我会突然测起15W呢？因为触发了一个奇怪的bug，即使在极客模式下CPU功耗也被限制在15W，所以某种程度上得感谢Intel或者联想自揭老底，没有这个bug我还不知道低功耗下分数这么低。

实际工作负载下，这颗CPU的表现（搭配软件）依然不尽如人意。进行一些高负载（如WSL2下的ns-3仿真）工作的时候，负载都会调度到P-Core上，这当然很好；但是这些P-Core非常热（如下图）。我用了四年的Zen 2都没有这么热，Intel搞的什么飞机？

高负载温度

而即使是没那么高负载的工作，比如Steam挂机下载时，或许是该任务被分配到了两个P-Core上，导致这两个核心的平均频率高达恐怖的4.5GHz，平均温度也达到了75度（高于其他P-Core十度以上），最高温度甚至达到了104度，造成了风扇转速急速拉高。而仅两个核心产生的热量很快就被大开的风扇带走，于是核心的温度又降了下来。此时负载并没有走而风扇却停了，便周而复始，若隐若现的噪音非常令人烦躁。起码在我的认知中，Steam下载造成的风扇转速不应被人听到。

真特么扯淡，我的评价是不如AMD。当然也不是没有解决办法，只要把电源模式调成智能模式，虽然仍然经常有核心跑高频，但是噪音和高温便神奇地几乎消失了。但智能模式也不完全智能，平常频率就龟缩在2GHz，比如跑游戏的时候性能明显不足，还是要手动调到性能模式。

硬盘是一块海力士HFS001TEJ4X112N，1TB PCIe 4.0 SSD，说真的我觉得4.0和3.0体验上真的很可能没有太大区别，我甚至真的加了一块Gen 3的SSD（虽然插槽支持Gen 5）。跑分见图。

CrystalDiskMark 跑分

7467 MT/s的高频内存对于核显本是一个大优点，但作为一个常开WSL2的人，32GB的内存基本也就满足日常使用。不知道为什么，Intel的这个核显会占用巨多的内存，而且显存分配上限为16GB，在我写到这里的时候已经吃掉4.9GB了，而我并没有开什么游戏，游戏时核显甚至能吃掉7GB内存。不知道16GB的版本会不会也这样，如果是的话那早该标配24GB了。内存跑分见下图（开了Hyper-V），但这140ns多的内存延迟是跟 AnandTech 的结果基本相仿的，LPDDR5 7467MT/s也不能成为充足的理由，这延迟真是节节高呀。

实际上，在7467 MT/s下，内存控制器以Gear 4模式运行，此模式下延迟天然偏高；其能够切换为5600 MT/s的Gear 2等不同模式。Chips and Cheese有一篇更详尽的报道。

无线网卡为AX211，有线网卡也是少见的Intel卡，为1GbE的I219-V。虽然1000Base-T的规格考虑未来几年确实有点落后了，但作为一个轻薄本，带有线网口已经不错了不是吗。

因为自己有显卡坞，所以核显游戏只试了试原神和星穹铁道。我认为这样的核显性能已经足够应付出行时的轻度游戏需求了，但随时想打3A大作自然是不可能的。

原神：2K分辨率、最高画质、开启FSR2、1.0倍渲染，平均30帧上下，也就将将能玩。整机功耗70W左右。原生（3K）分辨率，在中画质下，也差不多平均30帧。
星穹铁道：2K分辨率、高画质、渲染1.4倍，黄金的时刻跑图20-30帧，战斗30-40帧。整机功耗65W左右。

令人失望的固件

当一些人口口声声吹着技术积淀的时候，联想却在ThinkBook 14+ 上表现得不像是全球PC市场的老霸主。至于锅该扣在微软头上还是联想头上，我也不知道，反正电源和散热等子系统相关的闹心bug有点多。

首先便是现代待机下风扇周期性狂转的问题。如果插着电源进入现代待机时后台有一点点负载，那么风扇就会一会低速转，一会全速转，后者的噪音远超性能模式满载（毕竟性能模式也没完全发挥）；试探出风口温度，也并未达到一个非常高的程度。从BIOS版本NJCN53WW开始，风扇策略似乎有了一些改观，转速反复横跳的现象减少了很多，噪音平顺了许多。

如果合盖时机不对，或者凑巧运气不好，风扇就会停转，整机变得非常烫手，然后CPU降到一个极低的频率。这个场景还是挺常见的，回到住处我习惯把笔记本外接外设和显卡，然后合盖使用。

作为一台2024年的轻薄本，这台电脑理所应当地支持s0ix电源模式，在Windows中显示为Connected Standby。常见的现代待机睡死发热或耗电问题，在NJCN53WW之前并未出现过；而在该版本中出现了合盖拿出发热的问题，查看电池报告显示，在背包里的四个小时，根本没有进入现代待机。

性能挡位也不知什么时候会消失，按Fn+Q没有反应，打开联想百应，性能调节直接消失了。

更别提下了大功夫做的热插拔TGX外接显卡，实际用起来各种53错误、黑屏、蓝屏等，不过这不是本文要介绍的内容，就不赘述了。

不能被量化的外设体验

此处的外设主要包含键盘、触控板、摄像头等；而“不能被量化”，指的是并不能像核显单元数量、CPU性能释放等参数一样可以横向比较，毕竟手感之类的东西，也是玄学嘛。

压感触控板是一种整块都可以识别按压手势，并通过振动马达模拟按下手感的触控板，也是我选择这个本的最大理由之一。作为一个前MacBook Pro用户，不得不承认我的手已经被苹果的触控板惯坏了，手势灵活，触感舒适，指哪打哪，效率极高。之后有一次机缘巧合试过小米笔记本Pro 14的压感触控板后，也留下了很深刻的印象，就有一种“这才是触控板该有的样子”的感觉。

触控板，对比 MacBook Pro 13（左）

但是同为压感触控板，当我摸到ThinkBook 14+ 的压感触控板后却略显失望。好消息是它当然碾压非压感触控板，毕竟点按还要抬起来实在太不方便了；它的尺寸也够大，甚至大于MacBook Pro 13，不会很轻易滑到边缘。但是坏消息是它的手感是弱于前两者的。如果将MacBook Pro 13的触控板体验设为标杆，纯硬件来说，小米笔记本Pro 14只是振动马达略显松散，保留了Mac的绝大部分体验；华为MateBook X Pro则是。而ThinkBook 14+ 除了按压震感松散之外，触发力度不可调且较大，需要略用力按下，用起来会累一些；磨砂质感也很奇怪，有点过于细了，甚至手感有点趋近于光面玻璃，在有手汗的情况下也不够顺畅。防误触并不完全安逸，仍然有些时候手掌碰到触控板，鼠标会移动……当然我还要重申，它的体验依然远远好于非压感触控板，只是我个人对压感触控板的期望值过高了。

如果算上软件，坦白说差距已经不如我想象中大了。Windows Precision驱动帮了大忙，但是该卡的地方还是卡，手势远远做不到macOS那样跟手。当然这个是微软全责，而且是作为Windows用户完全不可避免的。差距最大的是重按手势，macOS中搭配方便的全局系统字典，非常好用；在Windows下则根本没有这一回事。

键盘手感相比我的20款拯救者再上一层楼，声音大幅降低，键程仍然处于舒适水准，但手感略软了一点。键盘布局也充分体现了设计者的善意，方向键接近全高，两边伴有PgUp和PgDn，属于是一个拼音输入法使用者才能做出的功能了。在自动模式下，键盘背光的开关也会参考亮度传感器的数值了，在环境够亮的时候不会打开背光。整块键盘唯一明显让我不满的地方，是微软强推的Copilot键。这台电脑好巧不巧，赶上了微软强推Copilot键，却没赶上微软放松要求，于是成为了……光荣的牺牲品。幸亏 PowerToys 可以将其重映射为右 Ctrl，拯救了我这个「Ctrl+Enter发送」党。

摄像头，画质我不关心，但Windows内置了一个背景模糊的功能，效果还行。虽然有用于Windows Hello的红外摄像头，但是识别速度并不够快，开盖后仍需3-5秒才能进桌面，有时候还要卡一下。

指纹识别速度也不咋快的样子，与手机的电容/近两年的屏下指纹相比有差距。而且可能是副作用，电源键也似乎按不下去了。

扬声器，不要抱太大期望，个人感觉音量大一点的时候就容易失真，对音质有要求的还是外接吧。

软件，唉，微软

在我从开箱到激活的这段时间里，电脑里出现了包括但不限于以下我不希望存在的软件：

联想电脑管家
联想应用商店
OfficePLUS
微软电脑管家
Intel Unison

联想百应看起来算是控制台+售后服务一类的软件，但是整整22个选项全收在电脑管家-智能设置-更多设置里，点进去还有四个tab分别容纳这些选项。联想可能是觉得调整性能模式是不常用的功能？但不管怎么说，有色域选择、触控板手势，甚至感知人脸自动锁定，都是锦上添花的功能。

还有一个有意思的自带应用是联想智会，这玩意自带了一个人走开还能保持显示画面的功能……产品鬼才。

“暂时离开”

Windows越来越像一坨屎了，这是绝大部分非Mac用户不得不吃下去的一坨屎，恭喜微软在比烂大赛中赢得第一名。

14999元机同款的屏幕

这14999块钱的笔记本，还真存在，不过毕竟是高贵的ThinkPad还是独显本，虽然疑似国内团队作品，但价格上也免不了品牌buff。250 PPI的屏幕以微弱优势领先MacBook Pro 13，毫无疑问属于Retina水准。Windows下默认缩放200%，即使在HiDPI debuff之下，除了完全没优化的软件以外，精细度基本无可挑剔。

实际430nits的亮度还算可以，相比果子那确实差了不少，但在Windows阵营也算不上差。有自动亮度传感器，Windows下调得也还行，不比Mac差，但可能比手机平均水平差一点。

本人没有色准写轮眼，粗看一眼水平还行，但前提是开启了Windows设置里的自动色彩管理功能。值得注意的是Windows默认刷新率也为60Hz，这两个设置藏在一起，比较深，很容易被忽略。

没有玻璃覆盖的雾面屏，虽然乍一看确实质感不咋地，但是考虑到不少镜面玻璃覆盖屏幕的旗舰级轻薄本都并没有比肩Mac的抗反射涂层，那确实还不如没有，可以理解。实际也确实如此，这个机器的屏幕平常使用基本不会有太多反光，当然你要是阳光直射那Mac也没办法。

标杆级拓展性与拆机

嘿，你说这，ThinkBook可就不困了啊，3个USB-A（1个隐藏式，2.0速率）、2个USB-C（一个支持充电、10Gbps，另一个为雷电4）、TGX接口（官方从未说过这个是OCuLink，但确实兼容）、HDMI、micro-SD读卡器（可惜不是标准SD卡）、千兆伸缩式网口，基本不会焦虑了。但可惜的是USB-C都在左边。USB-A接口比较紧，插拔需要一点力气；隐藏式接口如果插进了鼠标接收器，就有点难拔出来了，务必注意。

支持充电的USB-C同样也支持显示器一线连，视频传输和基本的USB Hub工作均正常。但考虑到BIOS的性能释放策略较为简陋，个人建议将一线连的显示器插到雷电4上，然后单独插原装充电器用于供电；具体性能释放数据见下节。

这次还是我第一次拆轻薄本。拧松两边的六颗螺丝（取不下来，好评），用吸盘吸住背面右下角并抬起来，就可以从右下角划开卡扣、拆下后盖了。

拆机

看起来所谓的内吹散热，就是在风扇侧边开了个口，同时用自然风直接给主板散热。提升幅度暂且不论，但D壳确实凉快了不少。也不得不说在14.5寸的机器里同时塞下独显、大电池、双2280硬盘位，网卡也不叠叠乐，即使内存焊死，也足以看出主板设计的水平和产品经理的诚意了。

不过仔细观察大概也能猜出接口排布的原因：雷电4和TGX之类的高速的接口都在左边，因为右侧那块就是主板的一部分；而低速接口就放在主板左侧的小板上，仔细观察它们是通过排线相连的。采用1Gbps而非2.5Gbps网口可能也是这个考量。不得不感叹ThinkBook X在两边小板上做雷电4的开创性。

还算令人满意的移动体验

轻薄本嘛，首先肯定要方便带出去。但是这台14.5英寸、1.55kg的“轻薄本”早已经给携带体验减了不少分。

但1.55kg的机身也不是白加的，比如拥有了84Wh的来自ATL的大电池。使用VS Code写毕业论文，约2小时耗不到一半的电，平均6个月下来，满电能用4个半小时，有明显可见的流畅度损耗，但称不上卡。更轻度的工作下，甚至能撑6小时。得益于外接显示器全都是连到集显上的（包括独显版），外接时也并不会大幅提高整机功耗。对于大学生上课使用，没意外（指课表排布）的话能撑满一上午或者一下午。附送100W的充电器，在联想百应里还能开启快充，再苟一下午基本没问题。

离电跑分差距不大，也算是圆了Intel的饼，但实际操作明显不如电源接通时顺畅，如NTQQ切换群聊有明显的卡顿感，猜想提频不积极。上述动作场景平均整机功耗15W左右，也算是一个不太离谱的数字吧。再加上一点静止场景，6-7小时续航问题还真不大。

屏幕、键盘、触控板等方面在之前说过了，不再赘述。

随机附赠的充电器是100W三脚PD，不会像两脚插（如拯救者C135）一样金属壳摸起来酥酥麻麻，充小米12S差不多是正常PD头雨露均沾的20W。使用非原装充电器时，性能释放如下：

100W（酷态科10号移动电源USB-C）/135W（联想C135）：性能释放和充电功率与官方100W无异
90W（AOC U24P10R反向供电）/65W（小米AD651P）/61W（苹果A1947）：CPU PL2约为60W，PL1（即持续性能释放）约为35W
联想C135 + 3A C2C线（无E-marker）：开机无法供电，关机可达到60W左右
33W（ZMI HA715）：无20V输出，不充电

使用原装100W充电器，30% 电量，静止下（系统总功率约25W），电池充电速度（非充电器功率）约为42W，使用快速充电功率约为50W；换用拯救者C135充电器，快速充电开启时充电速度约为65W，关闭时约为55W。

结语

我对ThinkBook 14+ 的期待是当年当代主流轻薄本的标杆，但2024年的ThinkBook并未满足我六边形战士的幻想。纸面上容易宣传的部分，比如屏幕分辨率、处理器性能释放瓦数、接口和内部扩展性等，保证了在斗蛐蛐时立于不败之地；过去一些部分高端本才有的配置，如压感触控板、红外人脸、指纹识别和一点AI功能，权当锦上添花；但诸如质感、噪音和温度表现，以及触控板手感，似乎都与真正的高端本有着不可逾越的鸿沟。

对于一台主流价位轻薄本，我完全理解这样的取舍：在决定基础使用体验的方面优先下功夫甚至略微过度，这能够优先满足绝大部分人的需求（包括斗蛐蛐需求）；逐渐下放一些甜点特性，起码换代不至于只换CPU；同时长期保持与当代甚至上代高端轻薄本的差距，不失为一种良性循环。然而ThinkBook 14+ Ultra 7版本售价已经达到了6999元，与真正的主流价位轻薄本的价格差距，比与中高端轻薄本的价格差距还要大。毕竟去年的Yoga Air 14S也仅需7999元，实际摸起来，给人的主观感受远强于ThinkBook 14+。或许这也是ThinkBook的取舍，同一套模具覆盖5000-10000元造成的取舍。

我认为真正拉开ThinkBook 14+ 和其他轻薄本的差距的，是TGX接口，它使得核显轻薄本也有了外接强大独显的能力；以及强大的内外部扩展性，这么多接口确实同价位罕见。

我的理解是高配版ThinkBook 14+ 的定位仍然是为性能党/参数党准备的大杯版主流轻薄本，而不是质感越级、兼顾性能的中高端轻薄本。虽然这两种选择并无对错，但许多地方仍然是上手之后才能感受到的；而这种参数领先的笔记本，宣传上无疑更讨喜。

另外还想聊一句TB14+ 的锐龙版：如你所见Intel的Meteor Lake在Zen 4+ 前已经毫无还手之力了，如果搭配同样的好屏幕好触控板，即使因为PCIe通道问题没有TGX，锐龙版也会成为今年的轻薄本标杆。可惜这俩全都没有，那么~~是联想产品规划问题呢，还是Intel从中作梗呢？~~ 破案了，就是ThinkBook产品经理觉得AMD用户不愿意加钱。

附录1：Linux支持情况

使用Arch Linux，GNOME 46桌面环境。如有依赖其他工具均会说明。

外设支持

触摸板开箱不可用，但可以安装第三方 DKMS 解决（或 AUR）。与Windows体验略有差距。

喇叭开箱不可用，需要装 sof-firmware。

亮度传感器直接可用，能够自动调节屏幕亮度，但是可能不如Windows下省心，不如不开。

指纹可用，装个 fprintd 就行。

摄像头直接可用，Howdy可以用，但是似乎只能用普通摄像头，红外摄像头不行。

Fn组合键可用。

性能

安装 power-profiles-daemon 可以切换性能模式。但Linux本身功耗足够低，即使不手动调节，风扇也不会突然狂转。

在停服前，再次一瞥《飙酷车神》

Sun, 24 Mar 2024 00:00:00 +0000

我好像记不得什么时候玩过《飙酷车神》了，但“多亏了”它全程联网的机制，它在发售10年后的2024年3月31日马上就要停服了。在这个关头玩这款游戏，大概算是一种抢救式游玩。然而本来时间也不多，所以也没法深入游玩了，有点可惜。

90分钟横穿美利坚

它的最大卖点，无疑就是全美的地图了。虽然看到它20 GB的大小，玩家应该对这个营销词汇有一定的认识，但是当驾车上百公里横穿整个美国的时候，才感受到这个地图的庞大——尤其是作为一款2014年的游戏。要知道，同期的《极品飞车：宿敌》只需要7分30秒就能环绕Redview一圈，总长度也只有45 km。

提起美国，城市是不可或缺的一环。游戏中当然连复刻每个州的主要城市都做不到，但还是挑了纽约、洛杉矶、拉斯维加斯等几个主要城市进行了微缩。毕竟育碧的游戏一直可以称为旅游模拟器，玩家也可以在游戏中看到一些熟悉的地标。美中不足的是城市里比如立体停车场之类的设施是不能进的。

Randy’s Donuts

金门大桥

除了城市当然也有不少小村落和旷野，我觉得质量是过关的。可能为了做越野赛之类赛事，一些乡村小道也能和高速公路一样连接各大城市，看起来有些奇怪，但也正常。车也是可以开到路外自由越野的，在如此大的地图面积下做到这点，非常难得。

为了解决地图过大的问题，育碧还依托几个机场和火车站做了快速传送，连带着机场基本都有专属建模，确实挺有意思。

地图优势不仅仅是地域优势，还包括游戏内小地图。它根据不同的缩放倍数甚至有不同的地图样式，可惜几个倍数是预设的，经常倍率过大或者过小……

实景地图

广袤的地图范围还有额外的好处，就是根本不需要刻意缝合各种地貌。近几年的许多RAC为了满足各种玩法和体验，地图设计上缝合了许多截然不同的地貌，比如出了城就是雪山之类总感觉看起来很尴尬。然而毕竟美国是个大国，只需要忠实地做出来就好了；甚至制作组还有闲心放几个游乐场之类的玩意。

那么，代价是什么呢

代价就是画质咯，同样的一款游戏，地图的大小和质量并重的话，预算顶不住，玩家的电脑也顶不住。所以画质（和建模）就会有肉眼可见的降低。比如车辆就给人一种塑料感，Mustang logo都不完整了（最高画质，下同）。

车辆细节

水体也只是能看而已，甚至像贴图一样（但真的会动）。

水上的桥

这个动态模糊（设定档为低），有种屎黄风云（《极品飞车：卧底风云》）的感觉了，一动起来像是一坨翔……

动态模糊

这时又要拉出《极品飞车：宿敌》了。我认为它的画面观感其实是要比《飙酷车神》好很多的，一方面应该是引擎的原因，毕竟寒霜3底子在那里，另一方面是它用了不少鸡贼的视觉效果，整个画面阴沉沉的也没多少人会顾得上细节了。

它的另一个中文名叫《法外之徒》

虽然，正如Skull and Bones中文名变成了《碧海黑帆》一样，即使没有过审压力，也没有选《法外之徒》这个名字。

真实的世界怎么能没有警察呢，育碧甚至为数个大城市和每个大区各订制了一种警察涂装。然而并非NFS中你不招惹它它就不招惹你的警察，即使撞上行人或者街车，警察也会试图通缉。但是，只要警察把赛车手玩家截停，则只需要三秒左右即可逮捕，这与玩家作为警察时需要8秒才能逮捕赛车手形成了鲜明的对比。

等等，玩家作为警察？这特么不是热力追踪？确实，但作为一个没买Calling All Units DLC的玩家，很遗憾只能玩一场拦截赛。甚至还可以装备两个技能，热力追踪无疑了。育婊还把DLC赛事和商店放在地图上，图标一闪一闪的，这点我是有点无语了。

警察技能

我的crew在哪里？

育碧全程联网当然也是有理由的啊，那就是大世界的多人游玩。无缝的大世界漫游体验确实非常好，甚至几乎没有明显的加载时间，毕竟隔壁NFS也只是刚实现而已。一张地图能容许8个人同时在线，比隔壁还要多两个。当代联机RAC所具有的一起漫游跑赛事等也是一应俱全，遥遥领先了属于是。

但大家都知道，土豆厂的服务器懂的都懂，能连上属于三生有幸了。更不用提《极品飞车：宿敌》和《极限竞速：地平线3/4/5》都只是可选联机，后者甚至可以无缝切换联机和AI街车的状态。如此巨大的地图里散落八个人，绝大部分时候也只是自己跑而已，这个数字即使乘以十，对这个地图来说也不嫌多，只能说可惜当时技术所限吧。

关于停服，Ivory Tower给出的理由是服务器限制和许可要求。前一个倒是合理也不合理，毕竟早就鬼服了，留几个土豆也没几个成本；后一个理由那确实存在，极限竞速系列也经常都会定时下架，比如现在想买地平线3已经买不到了。然而就算这样，买了的还可以继续离线玩，只不过没有更新了。既然如此，就看看同样是全程联网的《极品飞车（2015）》怎么搞，会不会搞个离线补丁，不过EA的服务器再烂也比育碧的好点儿。

和「LSP」一起写代码：VS Code + Clangd 编写 C/C++

Tue, 27 Feb 2024 23:19:00 +0800

微软出品的VS Code官方C/C++ 插件当然很好，似乎在C/C++ 用户中也是用得较为广泛的，调试功能很好用。然而在稍大一点的项目中，有时会出现找不到代码索引的问题，以及代码补全、提示不够智能等，在一定程度上Clangd就能够解决这个问题。

Clangd是LLVM社区的一个项目，是一个基于 ~~LSP~~ Language Server Protocol的C/C++ 语言服务器（类似于rust-analyzer、gopls等），与编辑器插件和其他工具结合使用，能够提供错误提示、代码补全、重构、语法高亮等功能。

对比

以下部分选取之前的课程实验uCore代码，对Clangd 15.0.0和微软C/C++ 插件的对应部分功能进行比较。

Clangd：能够正确找到符号对应的源文件

C/C++：未找到符号定义，仅有返回值提示

Clangd：有较完整的补全列表

C/C++：无法补全

Clangd：识别到格式错误，并提供修改建议

C/C++：未识别到格式错误

注：C/C++ 插件也能够读取 compile_commands.json，但索引很慢，且对于JSON中没有覆盖到的源文件，并不能推测符号位置，并不是完全不能找到定义。然而即使找到，提示功能也逊于Clangd。

安装

首先你需要安装Clang，macOS的Xcode命令行工具自带，Linux可以通过包管理器安装（也可以只安装clang-tools），Windows则可以使用 llvm-mingw 中的Clang。个人建议有条件的话使用一个较新的版本，特性会有显著的差异。

关于 Windows 下安装 llvm-mingw

从上述GitHub页面的releases中选择一个版本，下载assets中适合你电脑处理器的版本压缩包（如 llvm-mingw-yyyymmdd-ucrt-x86_64.zip）
将该压缩包所有内容解压到电脑上你喜欢的位置
将含有数百个exe那个文件夹加入到环境变量中（通常路径含有 bin）
打开你的终端，如果运行 clang -v 显示与刚刚下载所匹配的版本，则安装完成

在Windows和macOS下，Clang默认能够模拟GCC命令，因此无需再安装GCC。

然后你当然需要VS Code，以及clangd插件，但没有必要卸载官方C/C++ 插件。但如果确实安装了，需要在VS Code的设置（文件-首选项-设置或Code-首选项-设置）中禁用其IntelliSense代码补全（C_Cpp.intelliSenseEngine 设置为 disabled）。

解析、索引文件

Clangd并不是强在可以完全自动找出索引，而是可以通过方便的方式生成索引。很多简单的项目可以直接使用类似 clang main.c 之类的一条命令编译，此时Clangd也可以正常找到引用的所有文件和符号，下面这一段也就暂时没用了。

然而复杂的项目则不然。就拿阿里巴巴前两年一篇HPCC论文的代码来说，ns-3本身就是一个十分复杂的项目，仿真程序的引用也弯弯绕绕，也总不能把头文件全部装到系统目录中。虽然有较为方便的编译运行方式，但Clangd就不能自动处理所有引用了。因此下面介绍了几种办法，供各位参考。

给Clangd传入参数

就像GCC/Clang一样，可以将 -I 等参数传入Clangd，来指定它寻找头文件的范围。VS Code可以对每个工作区设定单独的Clangd参数（clangd.arguments），这样每个项目的配置都可以不同了。

虽然小项目手动传命令确实不麻烦，但小项目也用不着手动索引呀。所以这个办法其实不是特别方便。

使用Bear生成 `compile_commands.json`

compile_commands.json 记录了每个源文件的编译命令。例如HPCC代码的（该JSON仅供参考，不同版本生成工具格式有所改变）：

json

[
    {
        "command": "c++ -c -O0 -ggdb -g3 -std=gnu++11 -Wno-error=deprecated-declarations -fstrict-aliasing -Wstrict-aliasing -fPIC -pthread -Isimulation/build -Isimulation -I/usr/include/libxml2 -DNS3_ASSERT_ENABLE -DNS3_LOG_ENABLE -DHAVE_PACKET_H=1 -DHAVE_SQLITE3=1 -DHAVE_IF_TUN_H=1 -o src/wimax/model/ss-scheduler.cc.1.o simulation/src/wimax/model/ss-scheduler.cc",
        "directory": "simulation/build",
        "file": "simulation/src/wimax/model/ss-scheduler.cc"
    },
    {
        "command": "c++ -c -O0 -ggdb -g3 -std=gnu++11 -Wno-error=deprecated-declarations -fstrict-aliasing -Wstrict-aliasing -fPIC -pthread -Isimulation/build -Isimulation -I/usr/include/libxml2 -DNS3_ASSERT_ENABLE -DNS3_LOG_ENABLE -DHAVE_PACKET_H=1 -DHAVE_SQLITE3=1 -DHAVE_IF_TUN_H=1 -o src/wimax/model/wimax-mac-queue.cc.1.o simulation/src/wimax/model/wimax-mac-queue.cc",
        "directory": "simulation/build",
        "file": "simulation/src/wimax/model/wimax-mac-queue.cc"
    },
    {
        "command": "c++ -c -O0 -ggdb -g3 -std=gnu++11 -Wno-error=deprecated-declarations -fstrict-aliasing -Wstrict-aliasing -fPIC -pthread -Isimulation/build -Isimulation -I/usr/include/libxml2 -DNS3_ASSERT_ENABLE -DNS3_LOG_ENABLE -DHAVE_PACKET_H=1 -DHAVE_SQLITE3=1 -DHAVE_IF_TUN_H=1 -o src/wimax/model/bs-scheduler-simple.cc.1.o simulation/src/wimax/model/bs-scheduler-simple.cc",
        "directory": "simulation/build",
        "file": "simulation/src/wimax/model/bs-scheduler-simple.cc"
    },
    ......
]

正因为Clangd同时也可以识别Clang的参数，所以通过提供编译命令，Clangd可以自动获取其引用的源代码所在的目录，从而处理引用，以及一些其他的功效。这个文件一般也没人手搓，太麻烦了。

虽然C/C++ 生态的构建系统千变万化，但是仍然可以用 Bear 截取编译命令。不同版本Bear使用方式不同，需要预先注意：

shell

# 较老版本
bear <compile_command>
# 较新版本
bear -- <compile_command>

这样跑过一次编译之后，就在当前目录生成 compile_commands.json 文件了。

使用CMake生成 `compile_commands.json`

如果整个项目使用CMake来构建，可以添加这个参数来生成它：

bash

`1`	`cmake -DCMAKE_EXPORT_COMPILE_COMMANDS=1`

CMake会将该文件存放至编译产物的目录中。如果其所处目录并不是在 build/ 中，那么需要手动将其移到项目根目录中。

ns-3 入门 5：追踪

Tue, 20 Feb 2024 10:52:00 +0800

根据官方教程 Tracing 一章写成。原示例代码¹和文中代码均以GPLv2发布。

大家都知道仿真的目的是得到有价值的输出以进行分析，但对特定的分析目的来说，不同的输出方式可能分析效率不同。比如使用日志输出，其粒度仅为源代码文件和日志等级，对于更细的控制则略显不足，且日志输出的稳定性不作保证，可能随着更新而更改；而输出pcap可以记录每个数据包的细节，使用Wireshark筛选也更加直观简易，但不能体现仿真过程中的逻辑控制，如之前提到的Wi-Fi STA节点的移动轨迹。如果遇到并非自己代码中想要输出的内容，情况就更复杂了。比如开发者在教程中举了一个例子：为TCP socket添加一点输出，而这需要更改ns-3本身（在 tcp-socket-base.cc 中）。虽然加输出确实很简单，但1) 更新ns-3版本时很麻烦，2) 仍需进行进一步日志筛选，3) 要重新编译ns-3。

所以，使用ns-3的追踪工具是更好的选择，因为它可以只输出感兴趣的数据源，免去筛选的麻烦，并且直接从ns-3内部获取数据（而不用改ns-3的代码）。

基本上，追踪接收器就是一个回调，是一个函数指针。将追踪源和接收器相连的操作，就是把接收器对应的回调传入对应追踪源的回调列表中。当追踪源执行的时候，它就依次执行每个接收器对应的回调。另外，被追踪的值采用值语义²传递，这使得它触发的时候是什么样，追踪出来就是什么样。

在不使用回调的情况下，若A要通过B的函数进行通信，A就必须依赖B。由于追踪接收器有很多，又不能逐个添加依赖，所以通过依赖的办法缺乏灵活性。

简单的示例代码

开发者给出了 fourth.cc¹ 作为入门代码示例。略过头文件部分，代码首先定义了一个 Object 的子类，添加了一个追踪源数据，并实现了 GetTypeId 方法：

cpp

class MyObject : public Object
{
  public:
    /**
     * Register this type.
     * \return The TypeId.
     */
    static TypeId GetTypeId()
    {
        static TypeId tid = TypeId("MyObject")
                                .SetParent<Object>()
                                .SetGroupName("Tutorial")
                                .AddConstructor<MyObject>()
                                .AddTraceSource("MyInteger",
                                                "An integer value to trace.",
                                                MakeTraceSourceAccessor(&MyObject::m_myInt),
                                                "ns3::TracedValueCallback::Int32");
        return tid;
    }
    MyObject()
    {
    }
    TracedValue<int32_t> m_myInt; //!< The traced value.
};

如果真的按照官方教程去走，一定会晕头转向，因为官方教程的路线根本没提到ns-3的对象模型。

ns-3提供了三个基类，Object、ObjectBase 和 SimpleRefCount。SimpleRefCount 具有ns-3智能指针（Ptr）的引用计数，ObjectBase 具有类型（即 GetTypeId 这一堆）和属性信息以及对象聚合（目前没用到）。Object 具有以上两者的所有特性，如 NetDevice 和 TcpSocketState 全部是它的子类。

TypeId 是 Object 的子类可选包含的一个属性，用于存放该类的元数据，如：

标识这个类的唯一字符串（MyObject），用于进行运行时类型推导

父类（Object），用于进行向上/向下类型转换

可用的构造函数，用于在不知道对象具体类型的情况下创建对象

可公开访问属性（attribute）列表，需要同时提供访问方法和边界检查

除了以上四条之外，可以看到 AddTraceSource 方法，用于添加一个追踪源。它的用法有点像 AddAttribute，不同的是1) 由于是内部编辑，所以不需要像attribute一样做边界检查；2) 有一个回调函数，用于在触发时执行。

m_myint 就是被追踪的数据，而 TracedValue 类型用于除了包装 int32_t 之外，还具备在值变化时触发回调的功能，并要求回调函数有且仅有两个 int32_t 参数，分别是旧值和新值。至于 MakeTraceSourceAccessor，则用于连接追踪源和追踪接收器，反正加上就行了。

对应的，IntTrace 函数中就是 MyInteger 追踪源对应的接收回调，没有返回值，有且仅有两个 int32_t 参数，代码简单易懂：

cpp

void
IntTrace(int32_t oldValue, int32_t newValue)
{
    std::cout << "Traced " << oldValue << " to " << newValue << std::endl;
}

最后在 main 函数中，就是创建对象和连接的过程了。

cpp

int
main(int argc, char* argv[])
{
    Ptr<MyObject> myObject = CreateObject<MyObject>();
    myObject->TraceConnectWithoutContext("MyInteger", MakeCallback(&IntTrace));

    myObject->m_myInt = 1234;

    return 0;
}

对于 Object 的子类，应该使用 CreateObject() 函数创建对象实例，对应的也会返回一个 Ptr。而对于 SimpleRefCount 的子类，则使用 Create()。

此处连接使用的并不是示例代码3（third.cc）中使用的 Config::Connect() 搭配绝对路径识别符，而是直接使用 MyObject 的 TraceConnectWithoutContext() 成员函数，这样在第一个参数中就只需要写该类下追踪源的名字而非完整路径了。MakeCallback 的作用这里不再赘述。

此处与示例代码3中另一个显著的不同是后者使用带context的追踪，TraceConnect() 成员函数中第二个参数为 std::string 类型，用来描述上下文（如对象路径），其会作为第一个参数传入回调，而此处使用的 TraceConnectWithoutContext() 就没有。也就是说，如果使用带context的追踪，那么回调函数应该改为 void IntTrace(std::string context, int32_t oldValue, int32_t newValue)。Config::Connect() 和 Config::ConnectWithoutContext() 则都不需要额外传入上下文信息。

使用 `Config` 子系统

虽然这种 TraceConnect() 很实用，但据开发者声称，一般来说都会使用所谓的配置路径选择追踪源，就像之前在示例代码3中一样。也就是说，以下两个部分的代码是等效的：

cpp

// 使用 Config::Connect
std::ostringstream oss;
oss << "/NodeList/" << wifiStaNodes.Get(nWifi - 1)->GetId()
    << "/$ns3::MobilityModel/CourseChange";
Config::Connect(oss.str(), MakeCallback(&CourseChange););

// 使用 TraceConnect
wifiStaNodes.Get(nWifi - 1)->GetObject<MobilityModel>()
    ->TraceConnect("CourseChange", MakeCallback(&CourseChange));

ns-3 入门 4：构建拓扑

Wed, 14 Feb 2024 16:29:00 +0800

根据官方教程 Building Topologies 一章写成。原示例代码¹²和文中代码均以GPLv2发布。

总线拓扑

第二篇示例代码¹描述了一个简单的例子，默认共有5个节点，$n_0$ 和 $n_1$ 通过点对点链路相连，网段为10.1.1.0/24；$n_1$ 到 $n_{i+1}$ 共 ${i+1}$ 个节点（$i$ 为 nCsma 参数的值，默认为3）通过共享介质的CSMA网络连接（有点类似Ethernet），使用10.1.2.0/24网段。其中 $n_1$ 同时连接了两个网络。之后在 $n_0$ 上设置示例代码1一样的echo client，在 $n_{i+1}$ 上设置对应的echo server。

代码大多跟之前的第一个示例没什么不同，只是有了更多的节点和设备。然而还是有一些需要注意的地方：

一个节点可以同时属于多个 NodeContainer，如 $n_1$，这样就方便在同一个节点上设置多个设备了。
NodeContainer.Create 函数会在当前container的基础上增加指定数量的节点，而非用指定数量初始化。
由于不在同一个网段内，两个网段自然是不互通的，于是需要使用 Ipv4StaticRoutingHelper::PopulateRoutingTables() 让所有节点都能充当路由器的功能，并填充路由表。类似于Linux的 sysctl -w net.ipv4.ip_forward=1。
对于 CsmaChannel 之类可以同时连接多个设备的信道，可以在某一节点上启用混杂（promiscuous）模式（如代码113行），这样就可以监听到所有经过该信道的数据包了。

程序一共录制了三个pcap文件。可以看到，在 second-0-0.pcap 和 second-1-0.pcap 中，只有基于点对点协议的UDP包，但在 second-2-0.pcap 中，不光变成了网段不同、基于Ethernet的UDP包，还出现了ARP包，以进行IP到MAC地址的查找。

为了更高的可自定义度，EnablePcap 不仅可以接受网络设备指针（nd: Ptr<NetDevice>），也可以接受节点 ID（nodeid: uint32_t）和设备ID（deviceid: uint32_t）。换而言之，以下两行代码是等效的：

cpp

1
2

csma.EnablePcap("second",csmaDevices.Get(1),true);
csma.EnablePcap("second",csmaNodes.Get(1)->GetId(),0,true);

Get 中输入的参数为节点在该容器中的索引，而非节点ID。节点ID是全局共享、递增的。

模型、属性和现实

在官方教程的对应章节中，主要是想提醒使用者须清楚认识到建模并不一定能涵盖真实情况的所有方面。比如上一节中 CsmaChannel 相对于真实Ethernet³ 来说并没有碰撞检测特性，而这是很容易被使用者忽略的。

另外作者还提到了不同网络标准中的不同属性。比如Ethernet的常见最大包大小为1518字节，而由于Ethernet II（DIX）标准的封装方式比IEEE 802.2（LLC/SNAP）的协议开销少8个字节⁴，所以前者允许的最大MTU可以高一点。在ns-3的 CsmaNetDevice 中，MTU和封装方式是两个单独的属性，若采用了后者的封装方式而忘了更改默认为1500的MTU，虽然模拟能够正常运行，但可能会偏离实际情况。

这里不是说MTU=1500同时采用LLC/SNAP一定是错的，现代部分网络甚至允许MTU=9000的Jumbo Frame，最终一切还是要看具体情况。

构建无线拓扑

这一段的示例代码²在第二篇代码中增加了一个无线网络，并连接到 $n_0$，Wi-Fi使用802.11a标准（有点远古），网段为10.1.3.0/24。随附示例代码中描述拓扑的字符画：

cpp

// Default Network Topology
//
//   Wifi 10.1.3.0
//                 AP
//  *    *    *    *
//  |    |    |    |    10.1.1.0
// n5   n6   n7   n0 -------------- n1   n2   n3   n4
//                   point-to-point  |    |    |    |
//                                   ================
//                                     LAN 10.1.2.0

在上面总线拓扑的基础上，又添加了 YansWifiChannel，相对来说更复杂一点，但从始至终都是围着链路层和物理层工作。

$n_0$ 作为AP，其他节点作为STA，分到两个 NodeContainer 中。
使用 YansWifiPhyHelper 来设置物理层属性，如频率、速率等。它承担了类似 CsmaHelper 的功能，只不过不能直接包办建立起信道和安装网络设备了。
通过 WifiMacHelper 区分AP和STA，并设置同一个SSID来确保连接同一个网络。
AP和STA的网络设备也有所不同，所以也包含在两个 NetDeviceContainer 中，但可以使用同一个 WifiHelper（用于安装网络设备）。
通过 MobilityHelper 模拟STA节点走来走去，而AP节点则固定在原地。
用同一个 Ipv4AddressHelper 在同一次 Setbase 之后多次 Assign 来保证AP和STA在同一个网段内（相当于使用固定IP，不考虑复杂的DHCP）。

在STA节点的链路层设置中（WifiMacHelper），可以看到设置了 ActiveProbing 属性，这使得STA节点会一直搜寻AP，导致仿真永远不会结束。因此，还需要在开始前手动设置10s结束仿真。

并不需要对Wi-Fi网络启用混杂模式，因为Wi-Fi网络的数据包都是广播的，所以所有节点都能收到。换而言之，混杂模式是自动开启的。

如果加上 --trace 参数，会记录下来4个文件，其中 third-0-1.pcap 对应的是Wi-Fi的流量。使用工具读取，可以看到相比Ethernet，Wi-Fi的通信更加复杂，还有beacon frame之类的控制信息。

记录STA移动轨迹

之前在介绍跟踪时，并未明确跟踪接收器的设计办法，使用的也是helper自带的连接方式。而在这个示例代码中，为了追踪某个STA的移动轨迹并打印到日志中，需要自行设计跟踪接收器（其实就是一个函数），并设置回调。这里的跟踪接收器也只是个函数而已：

cpp

void
CourseChange(std::string context, Ptr<const MobilityModel> model)
{
  Vector position = model->GetPosition();
  NS_LOG_UNCOND(context <<
              " x = " << position.x << ", y = " << position.y);
}

其实功能非常简单，就是当调用这个函数的时候，打印出对应的事件名（context），以及STA节点的位置。为了让节点位置变化时调用这个函数，需要在 Simulator::Run() 之前设置回调：

cpp

std::ostringstream oss;
oss << "/NodeList/" << wifiStaNodes.Get(nWifi - 1)->GetId()
    << "/$ns3::MobilityModel/CourseChange";
auto cb = MakeCallback(&CourseChange);
Config::Connect(oss.str(), cb);

Config::Connect() 的第一个参数就是事件名，也就是跟踪源的路径，这里仅指定了一个STA。第二个参数就是一个回调对象。

MakeCallback 的作用是将函数指针包装成一个 Callback 对象。Callback 类是一个模板类，有一个强制参数（对应返回值，void也算一个）和至多五个可选参数（对应参数列表）。MakeCallback 会根据函数指针的类型自动推断参数列表。这样，就可以直接使用类似 ret = cb(arg1, arg2, ...) 的方法来调用回调了。如果需要设置对象的成员函数回调，或者希望预先设定某几个参数，可以参考手册的对应部分。

这样，当STA位置变化时，就会在日志中打印当前位置，如：

plaintext

/NodeList/7/$ns3::MobilityModel/CourseChange x = 10, y = 0
/NodeList/7/$ns3::MobilityModel/CourseChange x = 9.36083, y = -0.769065
/NodeList/7/$ns3::MobilityModel/CourseChange x = 9.62346, y = 0.195831
/NodeList/7/$ns3::MobilityModel/CourseChange x = 9.42533, y = 1.17601
/NodeList/7/$ns3::MobilityModel/CourseChange x = 8.4854, y = 0.834616
/NodeList/7/$ns3::MobilityModel/CourseChange x = 7.79244, y = 1.55559
/NodeList/7/$ns3::MobilityModel/CourseChange x = 7.85546, y = 2.55361

ns-3中的队列

和很多人理解的不同，数据包并不是排一个队就能直接发出去了，而在实际情况中，有多层队列，排完这个再排下一个，用来处理不同的事情。在ns-3中虽然并没有实际操作系统中那么复杂，但也“将IP层或流量控制层与设备层分开”，前者，即所谓的流量控制层，处理QoS和AQM；而后者在 NetDevice 中，处理设备层的队列，与连接类型有关（Ethernet，Wi-Fi等）。如果设备层的队列并没有被填满，那么流量控制层队列基本等效于透明，毕竟这时并没有控制流量的必要。

官方教程中有 [不同队列类型详解]。在分配IP地址时，流量控制层默认启用 pfifo_fast 队列（容量为1000个包）并可以自行指定，而设备层队列由设备自身决定，不同的网络设备有不同的队列类型。

若要自行指定流量控制层的队列，有两种办法。如果还未安装网络设备，可以借助网络设备的helper实现：

cpp

1
2
3

PointToPointHelper p2p;
p2p.SetQueue("ns3::DropTailQueue", "MaxSize", StringValue("50p"));
NetDeviceContainer devices = p2p.Install(nodes);

如果已经安装了网络设备，可以使用 TrafficControlHelper 来设置根队列：

cpp

1
2
3

TrafficControlHelper tch;
tch.SetRootQueueDisc("ns3::CoDelQueueDisc", "MaxSize", StringValue("1000p"));
tch.Install(devices);

https://gitlab.com/nsnam/ns-3-dev/-/blob/2209a5abd18be77c6c865c837368b4e459ae7c8e/examples/tutorial/second.cc ↩︎ ↩︎
https://gitlab.com/nsnam/ns-3-dev/-/blob/5649b4801cc3e06b8d0edc9ea1b18510594dfd35/examples/tutorial/third.cc ↩︎ ↩︎
早期的共享介质Ethernet标准使用CSMA/CD，而非CSMA。 ↩︎
https://en.wikipedia.org/wiki/Ethernet_frame#Types ↩︎

ns-3 入门 3：日志、命令参数和跟踪

Sat, 03 Feb 2024 12:18:00 +0800

根据官方教程 Tweaking 一章写成。

日志

ns-3自带一个日志系统。用日志系统记录输出和错误等是常见的做法，但由于追踪系统的存在（可以使用tcpdump或者Wireshark看），日志系统还是用来记录错误和调试信息为主。

前面讲到ns-3的日志系统粒度为模块，可以对某个模块启用、禁用、设置级别等。

日志级别

日志系统有以下几个级别：

LOG_ERROR：错误
LOG_WARN：警告
LOG_DEBUG：临时的调试信息
LOG_INFO：程序运行进度等信息
LOG_FUNCTION：函数调用信息
LOG_LOGIC：函数内部的逻辑执行
LOG_ALL：包含以上所有

LOG_FUNCTION 等级会在每个函数执行时打印信息，比如下面这样。

log

UdpEchoClientApplication:UdpEchoClient(0xef90d0)
UdpEchoClientApplication:SetDataSize(0xef90d0, 1024)
UdpEchoClientApplication:StartApplication(0xef90d0)
UdpEchoClientApplication:ScheduleTransmit(0xef90d0, +0ns)
UdpEchoClientApplication:Send(0xef90d0)

需要注意以上每种日志级别仅包含其本身。若要包含上级日志，则可使用对应的 LOG_LEVEL。如 LOG_LEVEL_DEBUG 是 LOG_ERROR、LOG_WARN、LOG_DEBUG 三者的并集，皆会打印。

另外还有一种 LOG_UNCOND 级别，会打印任何日志条目，无视等级。

设置级别

有两种办法对模块日志级别进行设置：环境变量和代码。环境变量设置不需要重新编译，所以比较方便。官方教程提到可以用环境变量“提高日志记录级别”，实际测试发现最终输出的日志范围是对两者取并集（包括下文的日志前缀部分）。

如果使用代码，需要使用 LogComponentEnable 函数，若要设置多个模块的日志级别，多次调用该函数即可。比如将 UdpEchoClientApplication 的日志级别设为 INFO：

cpp

`1`	`LogComponentEnable("UdpEchoClientApplication", LOG_LEVEL_INFO);`

如果只想要启用某个模块的自定义等级日志，可以使用并运算：

cpp

`1`	`LogComponentEnable("UdpEchoClientApplication", LogLevel(LOG_INFO \| LOG_FUNCTION));`

而控制日志级别的环境变量是 NS_LOG，虽然只有一个变量，但使用和PATH类似的表示方法，也可以控制多个模块的级别，其值的格式为 Component1=level_1:Component2=level_2。比如：

bash

`1`	`export NS_LOG="UdpEchoClientApplication=level_all:UdpEchoServerApplication=level_all"`

环境变量表示的并运算会更加直观些：

bash

`1`	`export NS_LOG="UdpEchoClientApplication=level_info\|level_function"`

如果需要设置所有模块的日志级别，可以将 * 作为 Component 的值。需注意该选项会导致大量输出。

日志前缀

回想第一个示例代码的输出，前面的日志输出的几乎都只有内容。比如之前那个示例程序，在启用所有日志等级时，输出是这样的：

log

UdpEchoServerApplication:UdpEchoServer(0x55fd771b1b10)
UdpEchoClientApplication:UdpEchoClient(0x55fd771d9570)
UdpEchoClientApplication:SetDataSize(0x55fd771d9570, 1024)
UdpEchoServerApplication:StartApplication(0x55fd771b1b10)
UdpEchoClientApplication:StartApplication(0x55fd771d9570)
UdpEchoClientApplication:ScheduleTransmit(0x55fd771d9570, +0ns)
UdpEchoClientApplication:Send(0x55fd771d9570)
At time +2s client sent 1024 bytes to 10.1.1.2 port 9
UdpEchoServerApplication:HandleRead(0x55fd771b1b10, 0x55fd771e5e70)
At time +2.00369s server received 1024 bytes from 10.1.1.1 port 49153
Echoing packet
......

日志前缀内容可以和日志输出等级一起设定，目前有如下几个选项¹：

PREFIX_FUNC：函数名（格式为 ComponentName:FunctionName）
PREFIX_TIME：仿真已进行的时长
PREFIX_NODE：节点编号（就是之前关键抽象中的那个节点）
PREFIX_LEVEL：日志等级

也可以用 PREFIX_ALL 一次性打开所有前缀。以使用代码的方式为例，可以这样设置：

cpp

    LogComponentEnable("UdpEchoClientApplication",
                       LogLevel(ns3::LOG_LEVEL_ALL | ns3::LOG_PREFIX_ALL));
    LogComponentEnable("UdpEchoServerApplication",
                       LogLevel(ns3::LOG_LEVEL_ALL | ns3::LOG_PREFIX_ALL));

输出便成了这样：

log

+0.000000000s -1 UdpEchoServerApplication:UdpEchoServer(0x55b8911fcb10)
+0.000000000s -1 UdpEchoClientApplication:UdpEchoClient(0x55b891224570)
+0.000000000s -1 UdpEchoClientApplication:SetDataSize(0x55b891224570, 1024)
+1.000000000s 1 UdpEchoServerApplication:StartApplication(0x55b8911fcb10)
+2.000000000s 0 UdpEchoClientApplication:StartApplication(0x55b891224570)
+2.000000000s 0 UdpEchoClientApplication:ScheduleTransmit(0x55b891224570, +0ns)
+2.000000000s 0 UdpEchoClientApplication:Send(0x55b891224570)
+2.000000000s 0 UdpEchoClientApplication:Send(): [INFO ] At time +2s client sent 1024 bytes to 10.1.1.2 port 9
+2.003686400s 1 UdpEchoServerApplication:HandleRead(0x55b8911fcb10, 0x55b891230e70)
+2.003686400s 1 UdpEchoServerApplication:HandleRead(): [INFO ] At time +2.00369s server received 1024 bytes from 10.1.1.1 port 49153
+2.003686400s 1 UdpEchoServerApplication:HandleRead(): [LOGIC] Echoing packet
......

记录日志

要将某个源文件划入某个模块，可以使用这个宏：

cpp

`1`	`NS_LOG_COMPONENT_DEFINE("ComponentName");`

对于 LOG_FUNCTION 级别的日志，可以使用 NS_LOG_FUNCTION(this)（静态函数使用 NS_LOG_FUNCTION_NOARGS()），它会在函数开始时打印函数名和参数，函数结束时打印函数名和返回值。而对于其他级别的日志，可以使用 NS_LOG_<LEVEL>，如：

cpp

1
2

NS_LOG_INFO("This is an info message");
NS_LOG_DEBUG("This is a debug message");

命令参数

ns-3也有一个自带的命令行参数解析器，从而避免手动解析或使用第三方库的麻烦。在 main 函数传入了 argc 和 argv 的情况下，可以使用 CommandLine 类来解析命令行参数：

cpp

1
2

CommandLine cmd;
cmd.Parse(argc, argv);

要使用 ns3 工具运行时加入命令行参数，可以用下面两种等效的方式：

bash

1
2

./ns3 run examples/tutorial/first.cc -- --PrintHelp
./ns3 run "examples/tutorial/first.cc --PrintHelp"

当然直接加参数也问题不大，会提示更正的。

自带参数

这个参数解析器自带了一些参数，可以通过 --PrintHelp 查看（竟然不是 --help，奇怪）。比如 --PrintAttributes=<TypeId> 可以查看某一类型附带的参数，以及各自的默认值。比如在第一个示例代码中，PointToPointChannel 的默认参数为：

bash

$ ./ns3 run examples/tutorial/first.cc -- --PrintAttributes=ns3::PointToPointChannel
Attributes for TypeId ns3::PointToPointChannel
    --ns3::PointToPointChannel::Delay=[+0ns]
        Propagation delay through the channel
Attributes defined in parent class ns3::Channel
    --ns3::Channel::Id=[0]
        The id (unique integer) of this Channel.

这个和我们在文档中看到的是一致的，默认增加0ns的延迟，但在代码中增加了2ms，覆盖了默认值。但--PrintHelp 并没有提到的是，也可以用命令行参数改变这些默认值。比如，在删除代码中设置链路延迟的部分之后，可以使用以下参数将其值改为100ms：

bash

`1`	`./ns3 run examples/tutorial/first.cc -- --ns3::PointToPointChannel::Delay=100ms`

上面“改变默认值”可以理解为：对于一个属性值，设定的优先级为代码设定值>命令行参数设定值>默认值。更高的优先级会完全覆盖低优先级的值。

自定义参数

当然也可以引入自定义的参数，通过 cmd.AddValue 添加。比如在第一个示例代码中，添加一个 --nPackets 参数，用于设置发送的数据包数量：

cpp

1
2

uint32_t nPackets = 1;
cmd.AddValue("nPackets", "Number of packets to send", nPackets);

然后在后面设置 MaxPackets attribute时传入 nPackets 即可。这样也可以避开命令行参数优先级的问题。

跟踪

模拟的全部目的是生成输出以供进一步研究，而ns-3跟踪系统是实现这一目标的主要机制。

—— ns-3文档

ns-3的跟踪功能，我划分为三个部分：

跟踪源 (trace source)：在仿真的某些阶段触发，并发送某些内部数据（如数据包内容）
跟踪接收器 (trace sink)：接收跟踪源发出的数据
前两者之间的连接

将跟踪源和跟踪接收器分开，可以在不改变跟踪源的情况下，更改接收方式（如新增一个接收器）。在这篇开发者给出的教程中，将会使用一些自带的跟踪源和接收器；后面开发者还写了一篇更加详细的教程，以介绍更加复杂的跟踪用法。

ASCII跟踪

ns-3自带一个ASCII跟踪的helper以帮助设置，在前面第一个示例代码中，可以像这样修改：

cpp

1
2
3

AsciiTraceHelper ascii;
pointToPoint.EnableAsciiAll(ascii.CreateFileStream("myfirst.tr"));
Simulator::Run();

然后重新运行一遍，你就会在shell的工作目录中看到一个 myfirst.tr 文件。里面有6行一长串数据，我们拿出第一行，进行一下换行拆分：

plaintext

+ 
2 
/NodeList/0/DeviceList/0/$ns3::PointToPointNetDevice/TxQueue/Enqueue 
ns3::PppHeader (Point-to-Point Protocol: IP (0x0021)) 
ns3::Ipv4Header (tos 0x0 DSCP Default ECN Not-ECT ttl 64 id 0 protocol 17 offset (bytes) 0 flags [none] length: 1052 10.1.1.1 > 10.1.1.2) 
ns3::UdpHeader (length: 1032 49153 > 9) 
Payload (size=1024)

第一行的 + 代表入队操作。每条跟踪数据的第一个字符会有四种可能：

+：设备队列上入队
-：设备队列上出队
d：丢包（dropped），可能是因为队列满了
r：从外部接收

第二行的 2 代表模拟进行时刻。第三行描述了该行为的发起者，即节点0上的设备0发送队列进行入队，也就是节点0准备发送数据了。后面的几行可以参照Internet的分层模型，分别是链路层的PPP头、网络层的IPv4头、传输层的UDP头和应用层的数据。

PCAP跟踪

PCAP相对上面的ASCII来说就友好多了，毕竟我们可以用Wireshark打开。类似于ASCII跟踪，PCAP跟踪可以这样应用于第一个示例代码：

cpp

1
2

pointToPoint.EnablePcapAll("myfirst");
Simulator::Run();

这次会在shell的工作目录下，对每个节点和网络设备生成一个 pcap 文件。tcpdump的用法这里就不介绍了，Wireshark则可以直接打开，就像用它抓的包一样。

https://www.nsnam.org/docs/doxygen/d7/d2e/namespacens3.html#aa6464a4d69551a9cc968e17a65f39bdb ↩︎

ns-3 入门 2：概念与第一个示例

Sat, 27 Jan 2024 22:57:00 +0800

本文根据官方教程 Conceptual Overview 一章写成。在这章中，教程通过一个代码示例，演示了ns-3的几大基本概念及其基本使用方法。但是个人觉得顺序比较难懂，所以对其进行了一定程度的重新组织。

下文中代码经过一点点修改，原代码见¹，代码均以GPLv2发布。

概念

节点 Node

计算机网络可以抽象为一个图，而一个节点就是其中的一个网络设备。该抽象不考虑网络设备的内部结构与功能，所以路由器（3层）、交换机（2层）、计算机均抽象为节点。因此，节点本身没有任何功能，也不能直接连接任何信道，仅代表一个能收发数据的事物，功能需要作为应用实现，信道通过设备连接。

节点使用 ns3::Node 类表示，并由 ns3::NodeContainer 类管理。要创建指定数量的节点，可以用 Create 实例方法。以下代码创建了两个节点，并将其存储在 nodes 中：

cpp

1
2

NodeContainer nodes;
nodes.Create(2);

要使用下标访问 NodeContainer 中的节点，可以用 Get 实例方法。以下代码访问了第一个节点（下标从0开始）：

cpp

`1`	`Ptr<Node> node = nodes.Get(0);`

上述代码中的 Ptr<T> 是ns-3提供的智能指针，能够自动解引用，效果类似于 std::shared_ptr<T>。类型 T 必须支持 Ref() 和 Unref() 方法。关于ns-3的内存管理机制，请看这一段。

为了使光秃秃的节点具备一些基本的网络通信功能（实际上属于应用），可以使用 ns3::InternetStackHelper 安装网络栈（包含TCP、UDP、IP等）。一个helper可以一次安装一整个 NodeContainer，如以下代码将 nodes 中的所有节点安装网络栈：

cpp

1
2

InternetStackHelper stack;
stack.Install(nodes);

由于并没有变量上的依赖关系，缺少网络栈并不会造成编译失败，但以示例代码为例，缺少网络栈会导致运行时创建更上层的应用失败，从而直接抛出SIGABRT。

网络设备 Net Device

正如电脑要上网就得插网卡（NIC）一样，节点要连接在一起，网络设备是不可或缺的。ns-3中的网络设备抽象包含了网卡的硬件功能和驱动程序功能，每个节点可以连接多个网络设备，用于连接多个不同的信道。

网络设备使用 ns3::NetDevice 类表示，并使用 ns3::NetDeviceContainer 进行管理。同样正如网卡分为有线和无线网卡一样，实际使用时多选择其子类，如以太网使用的 ns3::CsmaNetDevice 类，以及Wi-Fi使用的 ns3::WifiNetDevice 类。在该篇示例代码中，由helper总揽网络设备和信道的创建，此处按下不表。

给网络设备分配IPv4地址后，可以将其看作一个接口。使用 ns3::Ipv4AddressHelper 类，可以为一个网络设备分配一个IPv4地址。以下代码设置了IP地址分配范围和掩码，并将其按顺序分配给一个 NetDeviceContainer 中的设备，返回的是一个接口容器 ns3::Ipv4InterfaceContainer：

cpp

1
2
3

Ipv4AddressHelper address;
address.SetBase("10.1.1.0", "255.255.255.0");
Ipv4InterfaceContainer interfaces = address.Assign(devices);

此处使用了多个隐式转换，从 const char* 即字符串描述的地址到 Ipv4Address 和 Ipv4Mask。如果不希望从10.1.1.1开始分配，可以使用第三个参数 base，如 “0.0.0.3” 表示从10.1.1.3开始分配²。

信道 Channel

信道代表节点之间的连接，比如RJ45双绞线，比如Wi-Fi，都可以抽象为信道。

信道使用 ns3::Channel 类表示，并由 ns3::ChannelContainer 类管理。同样，信道也有多种类型，如以太网使用的 ns3::CsmaChannel 类，Wi-Fi使用的 ns3::WifiChannel 类。但是在本篇示例代码中，并没有明确地使用 Channel，而是借助了网络设备和信道的紧密联系，由helper类统一创建。比如在下面的代码中，新建了一个点对点信道，设置两端网络设备传输速率为5 Mbps，信道延迟2 ms，并将其安装到一个 NodeContainer 中，最终返回创建完成的网络设备 NetDeviceContainer：

cpp

PointToPointHelper pointToPoint;
pointToPoint.SetDeviceAttribute("DataRate", StringValue("5Mbps"));
pointToPoint.SetChannelAttribute("Delay", StringValue("2ms"));
auto devices = pointToPoint.Install(nodes);

属性（attribute）相比于普通的成员变量，具有更多的控制，如可以设置默认值（包括编译期和运行期）、边界检查等。关于更多属性信息，请看这一段。

点对点信道限制输入的 NodeContainer 必须有且仅有两个节点，否则运行时会抛出异常。

这里设置的网络设备属性和信道属性，应该参考具体的网络设备³和信道类⁴的文档。

信道的延迟，就是propagation delay。

应用 Application

节点的实际功能均由应用实现。这是一个庞大的概念，不仅仅包含应用层的内容，也同时包含了传输层、网络层等内容。它描述了某个节点的行为。

应用使用 ns3::Application 类表示，并由 ApplicationContainer 类管理。该container的具体创建由具体的应用程序实现。使用 Start 和 Stop 实例方法，可以控制应用的开始结束时间，仿真程序在所有应用运行结束之前不会主动停止：

cpp

1
2
3

ApplicationContainer serverApps = xxx;
serverApps.Start(Seconds(1.0));
serverApps.Stop(Seconds(10.0));

在示例代码中，具体使用了 ns3::UdpEchoClientApplication 和 ns3::UdpEchoServerApplication 类，作用应该不言而喻。UdpEchoServerApplication 使用 ns3::UdpEchoServerHelper 类创建，如以下代码在第二个节点上安装，设置端口为9，并在1-10s运行：

cpp

UdpEchoServerHelper echoServer(9);
ApplicationContainer serverApps = echoServer.Install(nodes.Get(1));
serverApps.Start(Seconds(1.0));
serverApps.Stop(Seconds(10.0));

这里包含一个隐式转换。nodes.Get(1) 返回的是 Ptr<Node>，而 Install 方法接受的是 NodeContainer，但是 Ptr<Node> 可以隐式转换为 NodeContainer。

负责主动发送数据的 UdpEchoClientApplication 与上文的helper类似，但有更多的参数可供自定义。如以下代码，将第二个节点的端口9作为目标，设置发送间隔为1s、包大小为1024B、发送总数为1⁵，安装到第一个节点上，并在2-10s运行：

cpp

UdpEchoClientHelper echoClient(interfaces.GetAddress(1), 9);
echoClient.SetAttribute("MaxPackets", UintegerValue(1));
echoClient.SetAttribute("Interval", TimeValue(Seconds(1.0)));
echoClient.SetAttribute("PacketSize", UintegerValue(1024));
ApplicationContainer clientApps = echoClient.Install(nodes.Get(0));
clientApps.Start(Seconds(2.0));
clientApps.Stop(Seconds(10.0));

代码示例

使用ns-3编写的仿真器程序是声明式而非命令式的，这有点类似于前端工程中兴起的类似概念。

头文件

ns-3提供了一些大粒度的头文件，可以一定程度上免去繁琐的找头文件过程。下面头文件的内容，基本就是示例代码中用到的模块。

cpp

#include "ns3/core-module.h"
#include "ns3/network-module.h"
#include "ns3/internet-module.h"
#include "ns3/point-to-point-module.h"
#include "ns3/applications-module.h"

日志

ns-3的日志是可以按照模块自定义的，当然这也需要自行为代码划分模块。如示例代码中的这一行macro就是将当前源文件划分到 FirstScriptExample 模块：

cpp

`1`	`ns3::NS_LOG_COMPONENT_DEFINE("FirstScriptExample");`

如果需要控制日志的详细程度，可以使用（如将 UdpEchoClientApplication 的日志级别设为 INFO）

cpp

`1`	`ns3::LogComponentEnable("UdpEchoClientApplication", LOG_LEVEL_INFO);`

命名空间

正如上文提到的，本代码示例中使用的类几乎均在 ns3 命名空间下。

模拟器

当上文模拟器所需执行的行为全部描述完毕后，就需要调用模拟器进行模拟了。这个示例代码的模拟是有穷尽的，所以可以等待模拟自行结束，然后直接销毁：

cpp

1
2

Simulator::Run();
Simulator::Destroy();

但是，如果模拟永远不会结束，或是希望自定义一个结束时间，则需要在 Run() 之前调用 Stop()，如以下代码将模拟时间限制在10s：

cpp

1
2
3

Simulator::Stop(Seconds(10.0));
Simulator::Run();
Simulator::Destroy();

编译

教程中提到的 ./ns3 build 大概率是错的，个人猜测是之前 ./waf 直接查找替换后的产物⁶。现在不必将文件移至 scratch/ 中，如本例子可以直接执行：

bash

`1`	`./ns3 run examples/tutorial/first.cc`

ns-3 入门 1：介绍与安装

Fri, 26 Jan 2024 22:57:00 +0800

根据官方教程 Getting Started 一章写成。

介绍

ns-3是一个离散网络事件模拟器。不难理解这个描述：比如改变拥塞窗口大小，发出数据包，都是离散事件。将这些离散事件按发生时间顺序模拟，就能得到这个系统在一段时间内的运行过程。因为计算机网络（也有其他一些类似系统）的运行过程是离散的，而不像往水池里倒水那样连续的，所以这种模拟方法是合理的。

ns-3本质上是一组库，可以在C++（或Python，但之后忽略）程序中导入，也就是自己写代码把ns-3提供的工具串成一个完整的模拟程序。通过手动导入头文件和链接库，当然也可以直接利用ns-3编译出需要的程序，但ns-3也提供了 ns3 命令行工具，以构建并运行模拟源代码。

下载

ns-3的分发形式是源代码，无论发行版是否有打包，都推荐使用源代码安装。以下仅以Linux为例，Windows用户自觉去装WSL2。

如果你使用Ubuntu，则可以参考官方文档的对应部分¹先按需安装好依赖；如果你和我一样使用的是Arch Linux，那么有一个 PROTECTED_0 AUR 包。但个人不建议你直接装它，因为上文提到的 ns3 命令行工具会留在源代码目录里，无法直接引用。所以可以利用AUR装依赖。Arch Linux的cppyy（用于写Python仿真程序）已更新至3.x，ns-3还没跟上支持，如有需要请注意。

然后从官网下载最新源码包，解压，进入里面的 ns-3.xx 目录。下文均基于3.40版本，此处暂时不提另外两种使用Bake和Git的方法。

编译

官方在文档里给了三种编译方式：

使用 build.py：比较简单，但不太自由
使用CMake：能自定义编译的模块，以及一些额外的选项
使用Bake：好处就是可以包揽从下载到安装

个人需要在之后将ns-3安装至系统目录，而其限定只能用第二种方法，所以下面只写第二种。

ns3 命令行工具也可以作为CMake的一个wrapper。在 ns-allinone-3.xx/ns-3.xx 目录中，运行以下命令：

bash

1
2
3

./ns3 clean
./ns3 configure --enable-tests --enable-examples --prefix=/usr/local
./ns3 build

其中 configure 的前两个参数是一起编译测试和示例，--prefix 指定之后的安装路径。完整的参数列表可以使用 ./ns3 configure --help 查看。

还需要注意configure完成后显示的build profile。如果在之后使用时需要使用GDB调试，则需确保其为 debug （加入 -d debug参数并重新编译），如不需调试，则可以使用默认的 optimized。

只要不是缺少非必需的依赖，编译都会正常进行。CMake也会输出各个模块是否会被编译，以及不被编译的原因（如果有；如缺少依赖，或用户指定不编译）。官方文档中有示例的编译输出，可以结合来看。

编译完成后，可以运行测试：

bash

`1`	`./test.py`

到这里编译过程就结束了。由于 ns3 命令行工具的存在，写程序时不需要太关注库和头文件的位置，同时为了防止多个ns-3版本共存冲突，开发者声称大部分人并不需要安装了：

Most users do not install ns-3 libraries to typical system library directories; they instead just leave the libraries in the build directory, and the ns3 Python program will find these libraries.

安装

虽然 ns3 命令行工具能够帮助构建系统找到头文件和链接库，但麻烦的是IDE并不这么认为（clangd自定义就比较麻烦），所以我决定将其安装到系统目录中。前面提到我添加了 --prefix=/usr/local，在这一步ns-3的头文件和链接库就会被分别安装到 /usr/local/include/ns3 和 /usr/local/lib。

根据文档，安装也需使用 ns3 命令行。但是 ns3 命令行工具会故意阻止以root权限执行，确有需要的可以编辑其约1400行处，删掉对 refuse_run_as_root() 的调用²。但也有副作用，比如之后每次构建运行仿真程序都要输入密码。在此希望读者也能够对自己的目的和行为有明确的认知。

然后，执行 ./ns3 install 即可将ns-3的头文件和链接库安装至prefix指定的位置。

如果只是为了IDE识别，当然也有另外一种方法，仅把头文件复制到系统目录中。头文件就在 build/include/ns3 目录中。

安装完成后，下一篇将顺着官方教程的脉络，认识一个仿真程序的示例。

Advent of Code 2023

Sat, 02 Dec 2023 16:23:17 +0800

头一回听说这个玩意，看起来还挺有意思的，国际上挺火，也不是特别难，有空就写一点，顺便学习一下Rust，~~以防入门第四次失败~~。

Day 1

Part 1

题意很简单，找到每一行第一个和最后一个数字，将其组成一个两位数，然后相加。样例也很人畜无害（很有OI的风格）：

plaintext

1abc2
pqr3stu8vwx
a1b2c3d4e5f
treb7uchet

比如第一行找出1和2，就是12，2、3行同理，第4行则是两个7，最后相加得到12 + 38 + 15 + 77 = 142。

只是这样的话当然（看起来）很简单了，特别是当Rust提供了 str 的 find 和 rfind 之后。

对每行：

分别记录每一行首末数字的位置，初始化为0和 len(str)+1，以及其对应的数字
遍历0-9的每个数字，顺便更新上述四个变量
最后将两个对应的数字拼起来，加进去

在上述第二步中，一开始筛选条件为“若本位数字下标大于最后一位下标，则更新”（即 number_last_match > last_index），然而当有且仅有第一位为数字时，不会更新。改为大于等于即可。这样例确实有股OI味儿，得学会自己出~

rust

pub fn part_one(input: &str) -> Option<u32> {
    // separate input into lines
    let lines = input.lines();
    let mut sum = 0;
    let numbers = ["0", "1", "2", "3", "4", "5", "6", "7", "8", "9"];
    for line in lines {
        let mut first_number = 0;
        let mut first_index: usize = line.len() + 1;
        let mut last_number = 0;
        let mut last_index: usize = 0;

        for i in 0..10 {
            if let Some(number_first_match) = line.find(numbers[i]) {
                if number_first_match < first_index {
                    first_number = i;
                    first_index = number_first_match;
                }
            }
            if let Some(number_last_match) = line.rfind(numbers[i]) {
                if number_last_match >= last_index { // If the only number is at [0], use this to record it
                    last_number = i;
                    last_index = number_last_match;
                }
            }
        }
        sum += first_number * 10 + last_number;
    }
    Some(sum as u32)
}

Part 2

其实就是在P1数字的基础上加上表示数字的单词。一听到要匹配多种字符串，啪的一下很快啊，拿出了正则表达式。只需要十个正则表达式，全部正着反着匹配一遍就行了……真的如此吗？

然而实际上，Rust的 regex crate使用的是自动机匹配，虽然比PCRE效率高，但它并不原生支持反向匹配；得把字符串和表达式都反过来，再匹配一遍，显然很不优雅。

突然想起，还有一个相比没那么丑陋、Part 1用过的方案摆在眼前：匹配两次不就行了吗？

rust

pub fn part_two(input: &str) -> Option<u32> {
        // separate input into lines
        let lines = input.lines();
        let mut sum = 0;
        let numbers = ["0", "1", "2", "3", "4", "5", "6", "7", "8", "9"];
        let word_numbers = [
            "zero", "one", "two", "three", "four", "five", "six", "seven", "eight", "nine",
        ];
        for line in lines {
            let mut first_number = 0;
            let mut first_index: usize = line.len() + 1;
            let mut last_number = 0;
            let mut last_index: usize = 0;

            for i in 0..10 {
                if let Some(word_first_match) = line.find(word_numbers[i]) {
                    if word_first_match < first_index {
                        first_number = i;
                        first_index = word_first_match;
                    }
                }
                if let Some(word_last_match) = line.rfind(word_numbers[i]) {
                    if word_last_match >= last_index {
                        last_number = i;
                        last_index = word_last_match;
                    }
                }
                if let Some(number_first_match) = line.find(numbers[i]) {
                    if number_first_match < first_index {
                        first_number = i;
                        first_index = number_first_match;
                    }
                }
                if let Some(number_last_match) = line.rfind(numbers[i]) {
                    if number_last_match >= last_index {
                        last_number = i;
                        last_index = number_last_match;
                    }
                }
            }
            sum += first_number * 10 + last_number;
        }
        Some(sum as u32)
}

Day 2

Part 1

每行代表一次game，每次game进行多次随机抽取，共有12个红色、13个绿色、14个蓝色，问有哪几次game中，所有抽取都符合实际情况，也就是每次抽取的每种颜色都不超过实际数量。

plaintext

Game 1: 3 blue, 4 red; 1 red, 2 green, 6 blue; 2 green
Game 2: 1 blue, 2 green; 3 green, 4 blue, 1 red; 1 green, 1 blue
Game 3: 8 green, 6 blue, 20 red; 5 blue, 4 red, 13 green; 5 green, 1 red
Game 4: 1 green, 3 red, 6 blue; 3 green, 6 red; 3 green, 15 blue, 14 red
Game 5: 6 red, 1 blue, 3 green; 2 blue, 1 red, 2 green

split，全都可以split，第一次分行，第二次用 : 把 “Game X: " 截掉，第三次用 ; 分隔抽数，第四次用 , 分隔颜色，第五次用 `` 分隔数量和颜色。match一下即可。

rust

pub fn part_one(input: &str) -> Option<u32> {
    let mut id_sum: u32 = 0;
    'game: for (index, game) in input.lines().enumerate() {
        // split "Game X: yyyyyyyyy"
        let content = game.split(": ").collect::<Vec<&str>>()[1];
        // split "X blue, Y red; XX green, YY yellow"
        let gotchas = content.split("; ").collect::<Vec<&str>>();
        let (mut red, mut green, mut blue) = (0, 0, 0);
        // Per gotcha: maximum 12 red, 13 green, 14 blue
        for gotcha in gotchas {
            let colors = gotcha.split(", ").collect::<Vec<&str>>();
            for color in colors {
                // color: "X blue/green/red"
                let color = color.split(" ").collect::<Vec<&str>>();
                let count = color[0].parse::<u32>().unwrap();
                match color[1] {
                    "blue" => blue = count,
                    "green" => green = count,
                    "red" => red = count,
                    _ => panic!("Unknown color: {}", color[1]),
                }
            }
            if red > 12 || green > 13 || blue > 14 {
                // this game is invalid, skip to next game
                continue 'game;
            }
        }
        id_sum += (index + 1) as u32;
    }
    Some(id_sum)
}

Part 2

Part 2求出对每次game，在能满足抽出数量的情况下，三种颜色各自的数量最小值。将这三个值相乘，再将每次game的乘积相加得到结果。

其实也一样，初始化一个最小值，然后对每一抽更新一下最小值。

rust

pub fn part_two(input: &str) -> Option<u32> {
    let mut id_sum: u32 = 0;
    for game in input.lines() {
        // split "Game X: yyyyyyyyy"
        let content = game.split(": ").collect::<Vec<&str>>()[1];
        // split "X blue, Y red; XX green, YY yellow"
        let gotchas = content.split("; ").collect::<Vec<&str>>();
        let (mut red, mut green, mut blue) = (0, 0, 0);
        // Get the maximum of each color
        for gotcha in gotchas {
            let colors = gotcha.split(", ").collect::<Vec<&str>>();
            for color in colors {
                // color: "X blue/green/red"
                let color = color.split(" ").collect::<Vec<&str>>();
                let count = color[0].parse::<u32>().unwrap();
                match color[1] {
                    "blue" => blue = cmp::max(blue, count),
                    "green" => green = cmp::max(green, count),
                    "red" => red = cmp::max(red, count),
                    _ => panic!("Unknown color: {}", color[1]),
                }
            }
        }
        let color_pow = red * green * blue;
        id_sum += color_pow;
    }
    Some(id_sum)
}

Day 3

Part 1

给定一个字符矩阵，找出其中周围有符号（非数字、非 . ）的数字，并将其相加。

也蛮简单的，就是一个要注意“周围”指的是八个方向，一个是如果在某行的最后仍然在记录数字，则将其截断。

第一个好理解，样例已经告诉我们了：

plaintext

467..114..
...*......
..35..633.
......#...
617*......
.....+.58.
..592.....
......755.
...$.*....
.664.598..

这里467也算是周围有符号的数字。至于第二个问题，比如把它改成这样：

plaintext

467..114..
...*......
..35..633.
......#...
617*......
.....+.588
11592.....
......755.
...$.*....
.664.598..

由于代码的逻辑是遇到一个数字就记下来、遇到符号就停止，所以在 588 后不会停止，变成 58811592。不幸的是，并没有发现输入数据中有这种问题（苦笑）。

rust

pub fn part_one(input: &str) -> Option<u32> {
    // convert lines into a char matrix
    let lines = input.lines();
    let mut sum = 0;
    let mut matrix: Vec<Vec<char>> = Vec::new();
    for line in lines {
        matrix.push(line.chars().collect());
    }

    let mut curr = 0; // current number
    let mut is_part_number = false; // current number adjacent to a symbol
                                    // iterate through the matrix
    for (x, line) in matrix.iter().enumerate() {
        for (y, ch) in line.iter().enumerate() {
            if *ch >= '0' && *ch <= '9' {
                // ch is a number
                curr = curr * 10 + (*ch as u32 - '0' as u32);
                if !is_part_number {
                    // check char in 8 directions
                    if x > 0 && is_symbol(matrix[x - 1][y]) {
                        is_part_number = true;
                    } else if y > 0 && is_symbol(matrix[x][y - 1]) {
                        is_part_number = true;
                    } else if x < matrix.len() - 1 && is_symbol(matrix[x + 1][y]) {
                        is_part_number = true;
                    } else if y < matrix[x].len() - 1 && is_symbol(matrix[x][y + 1]) {
                        is_part_number = true;
                    } else if x > 0 && y > 0 && is_symbol(matrix[x - 1][y - 1]) {
                        is_part_number = true;
                    } else if x > 0 && y < matrix[x].len() - 1 && is_symbol(matrix[x - 1][y + 1]) {
                        is_part_number = true;
                    } else if x < matrix.len() - 1 && y > 0 && is_symbol(matrix[x + 1][y - 1]) {
                        is_part_number = true;
                    } else if x < matrix.len() - 1
                        && y < matrix[x].len() - 1
                        && is_symbol(matrix[x + 1][y + 1])
                    {
                        is_part_number = true;
                    }
                }
            } else {
                // ch is a letter
                if curr != 0 {
                    if is_part_number {
                        sum += curr;
                        println!("Add {}", curr)
                    }
                    curr = 0;
                    is_part_number = false;
                }
            }
        }
        // at the end of each line (including last), add the number
        if curr != 0 {
            if is_part_number {
                sum += curr;
                println!("Add {}", curr)
            }
            curr = 0;
            is_part_number = false;
        }
    }
    Some(sum)
}

fn is_symbol(char: char) -> bool {
    (char < '0' || char > '9') && char != '.'
}

pub fn part_one(input: &str) -> Option<u32> {
    // convert lines into a char matrix
    let lines = input.lines();
    let mut sum = 0;
    let mut matrix: Vec<Vec<char>> = Vec::new();
    for line in lines {
        matrix.push(line.chars().collect());
    }

    let mut curr = 0; // current number
    let mut is_part_number = false; // current number adjacent to a symbol
                                    // iterate through the matrix
    for (x, line) in matrix.iter().enumerate() {
        for (y, ch) in line.iter().enumerate() {
            if *ch >= '0' && *ch <= '9' {
                // ch is a number
                curr = curr * 10 + (*ch as u32 - '0' as u32);
                if !is_part_number {
                    // check char in 8 directions
                    if x > 0 && is_symbol(matrix[x - 1][y]) {
                        is_part_number = true;
                    } else if y > 0 && is_symbol(matrix[x][y - 1]) {
                        is_part_number = true;
                    } else if x < matrix.len() - 1 && is_symbol(matrix[x + 1][y]) {
                        is_part_number = true;
                    } else if y < matrix[x].len() - 1 && is_symbol(matrix[x][y + 1]) {
                        is_part_number = true;
                    } else if x > 0 && y > 0 && is_symbol(matrix[x - 1][y - 1]) {
                        is_part_number = true;
                    } else if x > 0 && y < matrix[x].len() - 1 && is_symbol(matrix[x - 1][y + 1]) {
                        is_part_number = true;
                    } else if x < matrix.len() - 1 && y > 0 && is_symbol(matrix[x + 1][y - 1]) {
                        is_part_number = true;
                    } else if x < matrix.len() - 1
                        && y < matrix[x].len() - 1
                        && is_symbol(matrix[x + 1][y + 1])
                    {
                        is_part_number = true;
                    }
                }
            } else {
                // ch is a letter
                if curr != 0 {
                    if is_part_number {
                        sum += curr;
                        println!("Add {}", curr)
                    }
                    curr = 0;
                    is_part_number = false;
                }
            }
        }
        // at the end of each line (including last), add the number
        if curr != 0 {
            if is_part_number {
                sum += curr;
                println!("Add {}", curr)
            }
            curr = 0;
            is_part_number = false;
        }
    }
    Some(sum)
}

fn is_symbol(char: char) -> bool {
    (char < '0' || char > '9') && char != '.'
}

Part 2

找出所有旁边有两串数字的星号，定义其值为这两个数字的乘积，求所有星号的值的和。

想出了两种思路。

第一种是开一个二维数组，为每串数字记录其编号，然后再扫一遍，对每个星号，统计周围8格中不同编号的个数。仍然是这个样例：

plaintext

467..114..
...*......
..35..633.
......#...
617*......
.....+.58.
..592.....
......755.
...$.*....
.664.598..

那么第一行的编号数组就为 [1,1,1,0,0,2,2,2,0,0]（从1开始，无内容算0）。但缺陷是数字的值需要再开个二维数组记录。

第二种是只扫星号，然后对每个星号，统计周围8格中数字的个数。数字只能横放在一行上，这给我们提供了巨大的方便，上中下三行可以分别处理。比如上面样例中第二行的星号，上一行三个位置数字情况为有、无、无，同一行为无、无，下一行为有、有、无，那么得出周围有2个数字，上面一个，下面一个。在确定周围有两个数字之后，即可再根据有数字的位置进行搜索，得到两个数字的值。这种方法可能重复对一个数字求值，但时空复杂度都比第一种低。

下面是第二种思路的做法。

rust

pub fn part_two(input: &str) -> Option<u32> {
    // convert lines into a char matrix
    let lines = input.lines();
    let mut sum = 0;
    let mut matrix: Vec<Vec<char>> = Vec::new();
    for line in lines {
        matrix.push(line.chars().collect());
    }

    for (x, line) in matrix.iter().enumerate() {
        for (y, ch) in line.iter().enumerate() {
            if *ch == '*' {
                // find numbers nearby
                let (
                    mut up_left,
                    mut up,
                    mut up_right,
                    mut left,
                    mut right,
                    mut down_left,
                    mut down,
                    mut down_right,
                ) = (false, false, false, false, false, false, false, false);
                let mut pow = 1;
                if x > 0 {
                    if y > 0 {
                        if is_digit(matrix[x - 1][y - 1]) {
                            up_left = true;
                        }
                    }
                    if is_digit(matrix[x - 1][y]) {
                        up = true;
                    }
                    if y < matrix[x].len() - 1 {
                        if is_digit(matrix[x - 1][y + 1]) {
                            up_right = true;
                        }
                    }
                }
                if y>0 && is_digit(matrix[x][y - 1]) {
                    left = true;
                }
                if y < matrix[x].len() - 1 && is_digit(matrix[x][y + 1]) {
                    right = true;
                }
                if x < matrix.len() - 1 {
                    if y > 0 {
                        if is_digit(matrix[x + 1][y - 1]) {
                            down_left = true;
                        }
                    }
                    if is_digit(matrix[x + 1][y]) {
                        down = true;
                    }
                    if y < matrix[x].len() - 1 {
                        if is_digit(matrix[x + 1][y + 1]) {
                            down_right = true;
                        }
                    }
                }
                // get number count
                let mut count = 0;
                match (up_left, up, up_right) {
                    (false, false, true) | (true, false, false) | (false, true, false) => {
                        count += 1
                    }
                    (true, true, false) | (false, true, true) => {
                        count += 1;
                        up = false; // to prevent calculating value twice
                    }
                    (true, false, true) => count += 2,
                    (true, true, true) => {
                        count += 1;
                        up_left = false; // as above
                        up_right = false;
                    }
                    (false, false, false) => {}
                }
                if left {
                    count += 1;
                }
                if right {
                    count += 1;
                }
                match (down_left, down, down_right) {
                    (false, false, true) | (true, false, false) | (false, true, false) => {
                        count += 1
                    }
                    (true, true, false) | (false, true, true) => {
                        count += 1;
                        down = false;
                    }
                    (true, false, true) => count += 2,
                    (true, true, true) => {
                        count += 1;
                        down_left = false;
                        down_right = false;
                    }
                    (false, false, false) => {}
                }
                println!("({}, {}) has {} numbers", x, y, count);
                if count != 2 {
                    // not a "gear"
                    continue;
                }
                if up_left {
                    pow *= get_value(&matrix[x - 1], y - 1);
                }
                if up {
                    pow *= get_value(&matrix[x - 1], y);
                }
                if up_right {
                    pow *= get_value(&matrix[x - 1], y + 1);
                }
                if left {
                    pow *= get_value(&matrix[x], y - 1);
                }
                if right {
                    pow *= get_value(&matrix[x], y + 1);
                }
                if down_left {
                    pow *= get_value(&matrix[x + 1], y - 1);
                }
                if down {
                    pow *= get_value(&matrix[x + 1], y);
                }
                if down_right {
                    pow *= get_value(&matrix[x + 1], y + 1);
                }
                sum += pow;
                println!("Adding {} at ({}, {})", pow, x, y);
            }
        }
    }
    Some(sum as u32)
}

fn is_digit(char: char) -> bool {
    char >= '0' && char <= '9'
}

// Since the value stays only on one line, we can just use one line.
fn get_value(matrix: &Vec<char>, y: usize) -> i32 {
    let mut start_y = y;
    let mut val = 0;
    while start_y > 0 && is_digit(matrix[start_y - 1]) {
        start_y -= 1;
    }
    while start_y < matrix.len() && is_digit(matrix[start_y]) {
        val = val * 10 + (matrix[start_y] as i32 - '0' as i32);
        start_y += 1;
    }
    val
}

pub fn part_two(input: &str) -> Option<u32> {
    // convert lines into a char matrix
    let lines = input.lines();
    let mut sum = 0;
    let mut matrix: Vec<Vec<char>> = Vec::new();
    for line in lines {
        matrix.push(line.chars().collect());
    }

    for (x, line) in matrix.iter().enumerate() {
        for (y, ch) in line.iter().enumerate() {
            if *ch == '*' {
                // find numbers nearby
                let (
                    mut up_left,
                    mut up,
                    mut up_right,
                    mut left,
                    mut right,
                    mut down_left,
                    mut down,
                    mut down_right,
                ) = (false, false, false, false, false, false, false, false);
                let mut pow = 1;
                if x > 0 {
                    if y > 0 {
                        if is_digit(matrix[x - 1][y - 1]) {
                            up_left = true;
                        }
                    }
                    if is_digit(matrix[x - 1][y]) {
                        up = true;
                    }
                    if y < matrix[x].len() - 1 {
                        if is_digit(matrix[x - 1][y + 1]) {
                            up_right = true;
                        }
                    }
                }
                if y>0 && is_digit(matrix[x][y - 1]) {
                    left = true;
                }
                if y < matrix[x].len() - 1 && is_digit(matrix[x][y + 1]) {
                    right = true;
                }
                if x < matrix.len() - 1 {
                    if y > 0 {
                        if is_digit(matrix[x + 1][y - 1]) {
                            down_left = true;
                        }
                    }
                    if is_digit(matrix[x + 1][y]) {
                        down = true;
                    }
                    if y < matrix[x].len() - 1 {
                        if is_digit(matrix[x + 1][y + 1]) {
                            down_right = true;
                        }
                    }
                }
                // get number count
                let mut count = 0;
                match (up_left, up, up_right) {
                    (false, false, true) | (true, false, false) | (false, true, false) => {
                        count += 1
                    }
                    (true, true, false) | (false, true, true) => {
                        count += 1;
                        up = false; // to prevent calculating value twice
                    }
                    (true, false, true) => count += 2,
                    (true, true, true) => {
                        count += 1;
                        up_left = false; // as above
                        up_right = false;
                    }
                    (false, false, false) => {}
                }
                if left {
                    count += 1;
                }
                if right {
                    count += 1;
                }
                match (down_left, down, down_right) {
                    (false, false, true) | (true, false, false) | (false, true, false) => {
                        count += 1
                    }
                    (true, true, false) | (false, true, true) => {
                        count += 1;
                        down = false;
                    }
                    (true, false, true) => count += 2,
                    (true, true, true) => {
                        count += 1;
                        down_left = false;
                        down_right = false;
                    }
                    (false, false, false) => {}
                }
                println!("({}, {}) has {} numbers", x, y, count);
                if count != 2 {
                    // not a "gear"
                    continue;
                }
                if up_left {
                    pow *= get_value(&matrix[x - 1], y - 1);
                }
                if up {
                    pow *= get_value(&matrix[x - 1], y);
                }
                if up_right {
                    pow *= get_value(&matrix[x - 1], y + 1);
                }
                if left {
                    pow *= get_value(&matrix[x], y - 1);
                }
                if right {
                    pow *= get_value(&matrix[x], y + 1);
                }
                if down_left {
                    pow *= get_value(&matrix[x + 1], y - 1);
                }
                if down {
                    pow *= get_value(&matrix[x + 1], y);
                }
                if down_right {
                    pow *= get_value(&matrix[x + 1], y + 1);
                }
                sum += pow;
                println!("Adding {} at ({}, {})", pow, x, y);
            }
        }
    }
    Some(sum as u32)
}

fn is_digit(char: char) -> bool {
    char >= '0' && char <= '9'
}

// Since the value stays only on one line, we can just use one line.
fn get_value(matrix: &Vec<char>, y: usize) -> i32 {
    let mut start_y = y;
    let mut val = 0;
    while start_y > 0 && is_digit(matrix[start_y - 1]) {
        start_y -= 1;
    }
    while start_y < matrix.len() && is_digit(matrix[start_y]) {
        val = val * 10 + (matrix[start_y] as i32 - '0' as i32);
        start_y += 1;
    }
    val
}

写完才发现这八个位置各一个变量实在不优雅，但能用，应该可以改为 [[bool;3];3]。实际操作中，如果上面一行有多于两位连着的数字（即属于同一串数字），那么只能留一位为true，否则会重复计算。

令人欣慰的是，只需要在 get_value 里借用一下 matrix 即可不转移所有权，从而避免了一个Rust新手与编译器旷日持久的战斗。

Day 4

Part 1

非常简单，长话短说就是刮刮乐，买了几张刮刮乐，要求出每张刮刮乐的中奖情况。

这里要特别感谢 itertools，由于输入数据中不一定只用一个空格分隔，能把多个空格当一个分隔符的 split_whitespace() 真的很好用。

rust

pub fn part_one(input: &str) -> Option<u32> {
    let lines = input.lines();
    let mut sum: u32 = 0;
    for line in lines{
        let mut win = 0;
        // process strings
        let content = line.split(": ").collect_vec()[1]; // cut "Card X: "
        let result = content.split(" | ").collect_vec();
        let winning_numbers = result[0];
        let own_numbers = result[1];
        let winning_set: HashSet<u32> = winning_numbers
            .split_whitespace()
            .map(|x| x.parse::<u32>().unwrap())
            .collect();
        let own_numbers: Vec<u32> = own_numbers
            .split_whitespace()
            .map(|x| x.parse::<u32>().unwrap())
            .collect();
        for number in own_numbers.iter() {
            if winning_set.contains(number) {
                win += 1;
            }
        }
        if win > 0 {
            sum += 2_u32.pow(win - 1);
        }
    }
    Some(sum)
}

Part 2

需要注意的是每一个编号的刮刮乐初始都有一张。

嘿嘿，用Copilot写函数式的代码真快乐。太华丽了。

rust

pub fn part_two(input: &str) -> Option<u32> {
    let lines = input.lines().collect_vec();
    let mut sum = 0; // cards scratched in total
    let mut cards_count = vec![1; lines.len()]; // every card has 1 copy
    let contents: Vec<&str> = lines
        .iter()
        .map(|x| x.split(": ").collect_vec()[1])
        .collect_vec();
    let results = contents
        .iter()
        .map(|x| x.split(" | ").collect_vec())
        .collect_vec();
    let winning_sets: Vec<HashSet<u32>> = results
        .iter()
        .map(|x| x[0])
        .map(|x| {
            x.split_whitespace()
                .map(|y| y.parse::<u32>().unwrap()) // Numbers that gets point for each card
                .collect()
        })
        .collect_vec();
    let own_numbers: Vec<Vec<u32>> = results
        .iter()
        .map(|x| x[1])
        .map(|x| {
            x.split_whitespace()
                .map(|y| y.parse::<u32>().unwrap()) // Numbers that gets point for each card
                .collect()
        })
        .collect_vec();
    for index in 0..cards_count.len() {
        println!("Has {} of card {}", cards_count[index], index);
        if cards_count[index] == 0 {
            break;
        }
        sum += cards_count[index];
        let winning_set = &winning_sets[index];
        let own_numbers = &own_numbers[index];
        let mut win = 0;
        print!("Intersect numbers: ");
        for number in own_numbers.iter() {
            if winning_set.contains(number) {
                win += 1;
                print!("{} ", number);
            }
        }
        println!("Win {} cards", win,);
        for i in 0..win {
            cards_count[index + 1 + i] += cards_count[index];
            println!(
                "Add {} copies of card {}",
                cards_count[index],
                index + 2 + i
            )
        }
    }
    Some(sum)
}

Day 5

Part 1

简单来说，就是给定映射关系，对每个数做7次映射，然后求出离得最近的两个结果。每个映射关系都是一个区间，这个条件让我残存的一丢丢算法竞赛思维立即想到了线段树。它确实很适合区间操作，但考虑到AoC并没有时空复杂度限制，写个暴力也能过。更重要的是，我不会。

倒是可以用二分，这个确实会，给区间排个序就行，但一旦有了写暴力的心思，就懒得钻研算法了……

但是，这道题真的是溢出狂魔啊……数据全都是 u32 的情况下，如果不改变数据格式，经常出现加溢出。一般有两种情况。

rust

// old
soil = mapping.dst_start + *seed - mapping.src_start;
// new
soil = mapping
    .dst_start
    .wrapping_add(*seed)
    .wrapping_sub(mapping.src_start);

第一种是像上面这段代码出现的，dst_start 和 *seed 相加后容易溢出，将减法提前也一样会溢出，从而panic。既然结果的 soil 肯定不会溢出，那么直接放任它溢出就可以了。

rust

// old
if soil >= mapping.src_start
    && soil < mapping.src_start + mapping.length
// new
if soil >= mapping.src_start
    && soil
        < mapping
            .src_start
            .checked_add(mapping.length)
            .unwrap_or(u32::MAX)

区间开头不溢出，长度也不溢出，诶，加起来它就溢出了。反正被映射的数字都属于 u32 集合，遇到超出的时候，直接用 u32::MAX 代替就行了。或者直接用 saturating_add。

rust

#[derive(Debug, PartialEq, Clone, Copy, Eq, PartialOrd, Ord)]
struct Mapping {
    dst_start: u32,
    src_start: u32,
    length: u32,
}

pub fn part_one(input: &str) -> Option<u32> {
    let items = input.split("\n\n").collect::<Vec<_>>();
    let seeds = items[0]
        .strip_prefix("seeds: ")
        .unwrap()
        .split_whitespace()
        .map(|s| s.parse::<u32>().unwrap())
        .collect::<Vec<_>>();
    let process_mapping = |x: &str| -> Vec<Mapping> {
        x.lines()
            .skip(1)
            .map(|line| {
                let mut parts = line.split_whitespace();
                let dst_start = parts.next().unwrap().parse::<u32>().unwrap();
                let src_start = parts.next().unwrap().parse::<u32>().unwrap();
                let length = parts.next().unwrap().parse::<u32>().unwrap();
                Mapping {
                    dst_start,
                    src_start,
                    length,
                }
            })
            .collect::<Vec<_>>()
    };
    let seed_to_soil = process_mapping(items[1]);
    let soil_to_fertilizer = process_mapping(items[2]);
    let fertilizer_to_water = process_mapping(items[3]);
    let water_to_light = process_mapping(items[4]);
    let light_to_temperature = process_mapping(items[5]);
    let temperature_to_humidity = process_mapping(items[6]);
    let humidity_to_location = process_mapping(items[7]);

    let mut locations: Vec<u32> = vec![0; seeds.len()];
    for (index, seed) in seeds.iter().enumerate() {
        let mut soil = 0;
        let mut mapped = false;
        for mapping in seed_to_soil.iter() {
            if *seed >= mapping.src_start
                && *seed
                    < mapping
                        .src_start
                        .checked_add(mapping.length)
                        .unwrap_or(u32::MAX)
            {
                soil = mapping
                    .dst_start
                    .wrapping_add(*seed)
                    .wrapping_sub(mapping.src_start);
                mapped = true;
                break;
            }
        }
        // if not mapped, use the src number
        if !mapped {
            soil = *seed;
        }

        let mut fertilizer = 0;
        mapped = false;
        for mapping in soil_to_fertilizer.iter() {
            if soil >= mapping.src_start
                && soil
                    < mapping
                        .src_start
                        .checked_add(mapping.length)
                        .unwrap_or(u32::MAX)
            {
                fertilizer = mapping
                    .dst_start
                    .wrapping_add(soil)
                    .wrapping_sub(mapping.src_start);
                mapped = true;
                break;
            }
        }
        if !mapped {
            fertilizer = soil;
        }

        // highly repetitive part omitted

        locations[index] = location;
        println!("Seed {}, soil {}, fertilizer {}, water {}, light {}, temperature {}, humidity {}, location {}", seed, soil, fertilizer, water, light, temperature, humidity, location);
    }
    // sort locations
    locations.sort();
    Some(locations[0])
}

#[derive(Debug, PartialEq, Clone, Copy, Eq, PartialOrd, Ord)]
struct Mapping {
    dst_start: u32,
    src_start: u32,
    length: u32,
}

pub fn part_one(input: &str) -> Option<u32> {
    let items = input.split("\n\n").collect::<Vec<_>>();
    let seeds = items[0]
        .strip_prefix("seeds: ")
        .unwrap()
        .split_whitespace()
        .map(|s| s.parse::<u32>().unwrap())
        .collect::<Vec<_>>();
    let process_mapping = |x: &str| -> Vec<Mapping> {
        x.lines()
            .skip(1)
            .map(|line| {
                let mut parts = line.split_whitespace();
                let dst_start = parts.next().unwrap().parse::<u32>().unwrap();
                let src_start = parts.next().unwrap().parse::<u32>().unwrap();
                let length = parts.next().unwrap().parse::<u32>().unwrap();
                Mapping {
                    dst_start,
                    src_start,
                    length,
                }
            })
            .collect::<Vec<_>>()
    };
    let seed_to_soil = process_mapping(items[1]);
    let soil_to_fertilizer = process_mapping(items[2]);
    let fertilizer_to_water = process_mapping(items[3]);
    let water_to_light = process_mapping(items[4]);
    let light_to_temperature = process_mapping(items[5]);
    let temperature_to_humidity = process_mapping(items[6]);
    let humidity_to_location = process_mapping(items[7]);

    let mut locations: Vec<u32> = vec![0; seeds.len()];
    for (index, seed) in seeds.iter().enumerate() {
        let mut soil = 0;
        let mut mapped = false;
        for mapping in seed_to_soil.iter() {
            if *seed >= mapping.src_start
                && *seed
                    < mapping
                        .src_start
                        .checked_add(mapping.length)
                        .unwrap_or(u32::MAX)
            {
                soil = mapping
                    .dst_start
                    .wrapping_add(*seed)
                    .wrapping_sub(mapping.src_start);
                mapped = true;
                break;
            }
        }
        // if not mapped, use the src number
        if !mapped {
            soil = *seed;
        }

        let mut fertilizer = 0;
        mapped = false;
        for mapping in soil_to_fertilizer.iter() {
            if soil >= mapping.src_start
                && soil
                    < mapping
                        .src_start
                        .checked_add(mapping.length)
                        .unwrap_or(u32::MAX)
            {
                fertilizer = mapping
                    .dst_start
                    .wrapping_add(soil)
                    .wrapping_sub(mapping.src_start);
                mapped = true;
                break;
            }
        }
        if !mapped {
            fertilizer = soil;
        }

        // highly repetitive part omitted

        locations[index] = location;
        println!("Seed {}, soil {}, fertilizer {}, water {}, light {}, temperature {}, humidity {}, location {}", seed, soil, fertilizer, water, light, temperature, humidity, location);
    }
    // sort locations
    locations.sort();
    Some(locations[0])
}

Part 2

题面意思改动很小，只是把第一行穷举的种子改为了数个区间的格式。样例的数据量不大，但实际输入动辄20亿。诚然，AoC没有时空复杂度限制，但应该没人好意思写一个20亿次外层循环的暴力吧？~~虽然暴力跑比想正解快多了~~

由于第一问没有搞那些花活，第二问就不强上高级算法了。将计就计，直接以区间作为单位进行映射。其核心思想就是根据映射范围切割区间，分别进行映射。~~怎么有种编译原理实验的感觉呢~~ 至于切割和映射的过程，个人建议对着样例画张图，能够极大地便于调试。在此奉上我画的图：

D5P2 样例解析

有了上一问的经验，此处并没有直接存储映射前后的差值，即使这样代码更简洁，因为 i32 相比 u32 天生就少了一半儿的能够表示的绝对值。相反，跟上一问一样使用 wrapping_add 和 wrapping_sub 放任溢出。

为了程序的简洁性，还使用了更多lambda表达式，读起来可能困难一点，但行数确实少了很多。

rust

pub fn part_two(input: &str) -> Option<u32> {
    let items = input.split("\n\n").collect::<Vec<_>>();
    let seeds = items[0]
        .strip_prefix("seeds: ")
        .unwrap()
        .split_whitespace()
        .map(|s| s.parse::<u32>().unwrap())
        .collect::<Vec<_>>()
        .chunks(2)
        .map(|x| (x[0], x[0] + x[1]))
        .collect::<Vec<_>>();
    let process_mapping = |x: &str| -> Vec<Mapping> {
        let mut result = x
            .lines()
            .skip(1)
            .map(|line| {
                let mut parts = line.split_whitespace();
                let dst_start = parts.next().unwrap().parse::<u32>().unwrap();
                let src_start = parts.next().unwrap().parse::<u32>().unwrap();
                let length = parts.next().unwrap().parse::<u32>().unwrap();
                Mapping {
                    dst_start,
                    src_start,
                    length,
                }
            })
            .collect::<Vec<_>>();
        result.sort_by(|a, b| a.src_start.cmp(&b.src_start));
        result
    };
    let seed_to_soil = process_mapping(items[1]);
    let soil_to_fertilizer = process_mapping(items[2]);
    let fertilizer_to_water = process_mapping(items[3]);
    let water_to_light = process_mapping(items[4]);
    let light_to_temperature = process_mapping(items[5]);
    let temperature_to_humidity = process_mapping(items[6]);
    let humidity_to_location = process_mapping(items[7]);

    let mut min_position = u32::MAX;

    let transform_ranges =
        |original_ranges: Vec<(u32, u32)>, mappings: &Vec<Mapping>| -> Vec<(u32, u32)> {
            let mut result = vec![];
            'range: for range in original_ranges.iter() {
                let mut range_start = range.0; // "cut" the range from start
                let range_end = range.1; // include start, exclude end
                for mapping in mappings.iter() {
                    let mapping_start = mapping.src_start;
                    let mapping_end = mapping
                        .src_start
                        .checked_add(mapping.length)
                        .unwrap_or(u32::MAX);
                    if range_start < mapping_start {
                        // remove the part before the mapping, use original range start
                        if range_end < mapping_start {
                            // current range has ended
                            result.push((range_start, range_end));
                            break;
                        } else {
                            // current range has some overlap with current mapping
                            result.push((range_start, mapping_start));
                            range_start = mapping_start;
                        }
                    }
                    if range_start >= mapping_end {
                        continue;
                    }
                    // now it at least has some overlap
                    let new_start = cmp::max(range_start, mapping_start)
                        .wrapping_sub(mapping.src_start)
                        .wrapping_add(mapping.dst_start);
                    let new_end = cmp::min(range_end, mapping_end)
                        .wrapping_sub(mapping.src_start)
                        .wrapping_add(mapping.dst_start);
                    result.push((new_start, new_end));
                    if range_end <= mapping_end {
                        // current range has ended
                        continue 'range;
                    } else {
                        // current range has some left
                        range_start = mapping_end;
                    }
                }
                // if still has some left, add it
                if range_start < range_end {
                    result.push((range_start, range_end));
                }
            }
            result
        };
    for seed in seeds.iter() {
        let seed_ranges = vec![(seed.0, seed.1)];
        let soil_ranges = transform_ranges(seed_ranges, &seed_to_soil);
        let fertilizer_ranges = transform_ranges(soil_ranges, &soil_to_fertilizer);
        let water_ranges = transform_ranges(fertilizer_ranges, &fertilizer_to_water);
        let light_ranges = transform_ranges(water_ranges, &water_to_light);
        let temperature_ranges = transform_ranges(light_ranges, &light_to_temperature);
        let humidity_ranges = transform_ranges(temperature_ranges, &temperature_to_humidity);
        let location_ranges = transform_ranges(humidity_ranges, &humidity_to_location);
        for location_range in location_ranges.iter() {
            if location_range.0 < min_position {
                min_position = location_range.0;
            }
        }
    }

    Some(min_position)
}

pub fn part_two(input: &str) -> Option<u32> {
    let items = input.split("\n\n").collect::<Vec<_>>();
    let seeds = items[0]
        .strip_prefix("seeds: ")
        .unwrap()
        .split_whitespace()
        .map(|s| s.parse::<u32>().unwrap())
        .collect::<Vec<_>>()
        .chunks(2)
        .map(|x| (x[0], x[0] + x[1]))
        .collect::<Vec<_>>();
    let process_mapping = |x: &str| -> Vec<Mapping> {
        let mut result = x
            .lines()
            .skip(1)
            .map(|line| {
                let mut parts = line.split_whitespace();
                let dst_start = parts.next().unwrap().parse::<u32>().unwrap();
                let src_start = parts.next().unwrap().parse::<u32>().unwrap();
                let length = parts.next().unwrap().parse::<u32>().unwrap();
                Mapping {
                    dst_start,
                    src_start,
                    length,
                }
            })
            .collect::<Vec<_>>();
        result.sort_by(|a, b| a.src_start.cmp(&b.src_start));
        result
    };
    let seed_to_soil = process_mapping(items[1]);
    let soil_to_fertilizer = process_mapping(items[2]);
    let fertilizer_to_water = process_mapping(items[3]);
    let water_to_light = process_mapping(items[4]);
    let light_to_temperature = process_mapping(items[5]);
    let temperature_to_humidity = process_mapping(items[6]);
    let humidity_to_location = process_mapping(items[7]);

    let mut min_position = u32::MAX;

    let transform_ranges =
        |original_ranges: Vec<(u32, u32)>, mappings: &Vec<Mapping>| -> Vec<(u32, u32)> {
            let mut result = vec![];
            'range: for range in original_ranges.iter() {
                let mut range_start = range.0; // "cut" the range from start
                let range_end = range.1; // include start, exclude end
                for mapping in mappings.iter() {
                    let mapping_start = mapping.src_start;
                    let mapping_end = mapping
                        .src_start
                        .checked_add(mapping.length)
                        .unwrap_or(u32::MAX);
                    if range_start < mapping_start {
                        // remove the part before the mapping, use original range start
                        if range_end < mapping_start {
                            // current range has ended
                            result.push((range_start, range_end));
                            break;
                        } else {
                            // current range has some overlap with current mapping
                            result.push((range_start, mapping_start));
                            range_start = mapping_start;
                        }
                    }
                    if range_start >= mapping_end {
                        continue;
                    }
                    // now it at least has some overlap
                    let new_start = cmp::max(range_start, mapping_start)
                        .wrapping_sub(mapping.src_start)
                        .wrapping_add(mapping.dst_start);
                    let new_end = cmp::min(range_end, mapping_end)
                        .wrapping_sub(mapping.src_start)
                        .wrapping_add(mapping.dst_start);
                    result.push((new_start, new_end));
                    if range_end <= mapping_end {
                        // current range has ended
                        continue 'range;
                    } else {
                        // current range has some left
                        range_start = mapping_end;
                    }
                }
                // if still has some left, add it
                if range_start < range_end {
                    result.push((range_start, range_end));
                }
            }
            result
        };
    for seed in seeds.iter() {
        let seed_ranges = vec![(seed.0, seed.1)];
        let soil_ranges = transform_ranges(seed_ranges, &seed_to_soil);
        let fertilizer_ranges = transform_ranges(soil_ranges, &soil_to_fertilizer);
        let water_ranges = transform_ranges(fertilizer_ranges, &fertilizer_to_water);
        let light_ranges = transform_ranges(water_ranges, &water_to_light);
        let temperature_ranges = transform_ranges(light_ranges, &light_to_temperature);
        let humidity_ranges = transform_ranges(temperature_ranges, &temperature_to_humidity);
        let location_ranges = transform_ranges(humidity_ranges, &humidity_to_location);
        for location_range in location_ranges.iter() {
            if location_range.0 < min_position {
                min_position = location_range.0;
            }
        }
    }

    Some(min_position)
}

Day 6

Part 1

船需要先原地蓄力，然后匀速运动，蓄力越久运动越快，时间取值均为离散值。求在给定时间下，有哪几种能够运动超过给定距离的可能，返回其数量。

初中数学题。设蓄力时间为 $x\ ms$，时间限制为 $t\ ms$，则匀速运动的时长为 $x-t\ ms$，匀速运动的距离为 $x(x-t)\ mm$。若给定距离为 $d$，则整道题就变成了求 $x(t-x) \ge d$ 的整数解，即 $\frac{t+\sqrt{t^2-4d}}{2}$ 和 $\frac{t-\sqrt{t^2-4d}}{2}$。

特别需要关注的是，题意为“超过”而非“不低于”，所以当两个根为整数的时候，这两个数不能算。我也不知道我是怎么写出如此抽象的代码的。

rust

pub fn part_one(input: &str) -> Option<u32> {
    let lines = input.lines().collect_vec();
    let times: Vec<u32> = lines[0]
        .split_whitespace()
        .filter_map(|x| x.parse().ok())
        .collect();
    let distances: Vec<u32> = lines[1]
        .split_whitespace()
        .filter_map(|x| x.parse().ok())
        .collect();
    let mut prod = 1;

    for (t, d) in times.iter().zip(distances.iter()) {
        let t = *t as f64;
        let d = *d as f64;
        let delta = ((t * t) - (4.0 * d)).sqrt();
        let x1 = (t + delta) / 2.0;
        let x2 = (t - delta) / 2.0;
        let count = if x1 == x1.floor() {
            x1 as u32 - 1
        } else {
            x1.floor() as u32
        } - if x2 == x2.ceil() {
            x2 as u32 + 1
        } else {
            x2.ceil() as u32
        } + 1;
        prod *= count;
    }
    Some(prod)
}

Part 2

从未见过Part 2比Part 1更简单的，但现在有了。之前需要解好几个方程，现在解一个就可以了。f64 直接秒杀。

rust

pub fn part_two(input: &str) -> Option<u32> {
    let lines = input.lines().collect_vec();
    let pattern = Regex::new(r"[^0-9]+").unwrap();
    let time = pattern.replace_all(lines[0], "").parse::<f64>().unwrap();
    let distance = pattern.replace_all(lines[1], "").parse::<f64>().unwrap();
    let delta = ((time * time) - (4.0 * distance)).sqrt();
    let x1 = (time + delta) / 2.0;
    let x2 = (time - delta) / 2.0;
    let count = if x1 == x1.floor() {
        x1 as u32 - 1
    } else {
        x1.floor() as u32
    } - if x2 == x2.ceil() {
        x2 as u32 + 1
    } else {
        x2.ceil() as u32
    } + 1;
    Some(count)
}

Day 7

Part 1

题面的意思很容易看出来，就是将所有的手牌按指定的排序规则进行排序。

这下是来学Rust排序的了。之前很多人说Rust的duck-typing（即trait机制）很麻烦，我不以为意，直到我为了排序一个结构体写了四个 impl，以及N个 derive。

为牌的各种排列组合分别写判断条件不用想就知道很麻烦，所以直接为不同的排列赋上不同的权重，将其加和得到该手牌的总权重，排序起来会很方便。

所幸实际输入也很简单，过了样例便没有被卡住。

rust

#[derive(Debug)]
struct Hand {
    hand: Vec<Card>,
    bid: u32,
}

#[derive(Debug, PartialEq, Eq, PartialOrd, Ord, Hash, Copy, Clone)]
enum Card {
    A = 14,
    K = 13,
    Q = 12,
    J = 11,
    T = 10,
    Nine = 9,
    Eight = 8,
    Seven = 7,
    Six = 6,
    Five = 5,
    Four = 4,
    Three = 3,
    Two = 2,
}

impl Ord for Hand {
    fn cmp(&self, other: &Self) -> Ordering {
        // how many of each card
        let self_dict = self.hand.iter().fold(HashMap::new(), |mut acc, card| {
            *acc.entry(card).or_insert(0) += 1;
            acc
        });
        let other_dict = other.hand.iter().fold(HashMap::new(), |mut acc, card| {
            *acc.entry(card).or_insert(0) += 1;
            acc
        });
        // Weight: 5 -> 30, 4 -> 20, 3 -> 10, 2 -> 5, 1 -> 1
        let self_weight = self_dict
            .iter()
            .map(|(_, count)| match count {
                5 => 30,
                4 => 20,
                3 => 10,
                2 => 5,
                1 => 1,
                _ => panic!("Invalid card count"),
            })
            .sum::<u32>();
        let other_weight = other_dict
            .iter()
            .map(|(_, count)| match count {
                5 => 30,
                4 => 20,
                3 => 10,
                2 => 5,
                1 => 1,
                _ => panic!("Invalid card count"),
            })
            .sum::<u32>();
        if self_weight > other_weight {
            return Ordering::Greater;
        } else if self_weight < other_weight {
            return Ordering::Less;
        } else {
            // compare `Card`s in descending order
            for (self_card, other_card) in self.hand.iter().zip(other.hand.iter()) {
                if self_card > other_card {
                    return Ordering::Greater;
                } else if self_card < other_card {
                    return Ordering::Less;
                }
            }
        }
        Ordering::Equal
    }
}

impl PartialOrd for Hand {
    fn partial_cmp(&self, other: &Self) -> Option<Ordering> {
        Some(self.cmp(other))
    }
}

impl PartialEq for Hand {
    fn eq(&self, other: &Self) -> bool {
        self.bid == other.bid
    }
}

impl Eq for Hand {}

pub fn part_one(input: &str) -> Option<u32> {
    let mut hands: Vec<Hand> = input
        .lines()
        .map(|line| {
            let mut parts = line.split_whitespace();
            let hand = parts
                .next()
                .unwrap()
                .chars()
                .map(|c| match c {
                    'A' => Card::A,
                    'K' => Card::K,
                    'Q' => Card::Q,
                    'J' => Card::J,
                    'T' => Card::T,
                    '9' => Card::Nine,
                    '8' => Card::Eight,
                    '7' => Card::Seven,
                    '6' => Card::Six,
                    '5' => Card::Five,
                    '4' => Card::Four,
                    '3' => Card::Three,
                    '2' => Card::Two,
                    _ => panic!("Invalid card"),
                })
                .collect::<Vec<_>>();
            let bid = parts.next().unwrap().parse().unwrap();
            Hand { hand, bid }
        })
        .collect();
    hands.sort();

    let mut winnings: u32 = 0;
    for i in 1..=hands.len() {
        winnings += hands[i - 1].bid * i as u32;
    }
    Some(winnings)
}

#[derive(Debug)]
struct Hand {
    hand: Vec<Card>,
    bid: u32,
}

#[derive(Debug, PartialEq, Eq, PartialOrd, Ord, Hash, Copy, Clone)]
enum Card {
    A = 14,
    K = 13,
    Q = 12,
    J = 11,
    T = 10,
    Nine = 9,
    Eight = 8,
    Seven = 7,
    Six = 6,
    Five = 5,
    Four = 4,
    Three = 3,
    Two = 2,
}

impl Ord for Hand {
    fn cmp(&self, other: &Self) -> Ordering {
        // how many of each card
        let self_dict = self.hand.iter().fold(HashMap::new(), |mut acc, card| {
            *acc.entry(card).or_insert(0) += 1;
            acc
        });
        let other_dict = other.hand.iter().fold(HashMap::new(), |mut acc, card| {
            *acc.entry(card).or_insert(0) += 1;
            acc
        });
        // Weight: 5 -> 30, 4 -> 20, 3 -> 10, 2 -> 5, 1 -> 1
        let self_weight = self_dict
            .iter()
            .map(|(_, count)| match count {
                5 => 30,
                4 => 20,
                3 => 10,
                2 => 5,
                1 => 1,
                _ => panic!("Invalid card count"),
            })
            .sum::<u32>();
        let other_weight = other_dict
            .iter()
            .map(|(_, count)| match count {
                5 => 30,
                4 => 20,
                3 => 10,
                2 => 5,
                1 => 1,
                _ => panic!("Invalid card count"),
            })
            .sum::<u32>();
        if self_weight > other_weight {
            return Ordering::Greater;
        } else if self_weight < other_weight {
            return Ordering::Less;
        } else {
            // compare `Card`s in descending order
            for (self_card, other_card) in self.hand.iter().zip(other.hand.iter()) {
                if self_card > other_card {
                    return Ordering::Greater;
                } else if self_card < other_card {
                    return Ordering::Less;
                }
            }
        }
        Ordering::Equal
    }
}

impl PartialOrd for Hand {
    fn partial_cmp(&self, other: &Self) -> Option<Ordering> {
        Some(self.cmp(other))
    }
}

impl PartialEq for Hand {
    fn eq(&self, other: &Self) -> bool {
        self.bid == other.bid
    }
}

impl Eq for Hand {}

pub fn part_one(input: &str) -> Option<u32> {
    let mut hands: Vec<Hand> = input
        .lines()
        .map(|line| {
            let mut parts = line.split_whitespace();
            let hand = parts
                .next()
                .unwrap()
                .chars()
                .map(|c| match c {
                    'A' => Card::A,
                    'K' => Card::K,
                    'Q' => Card::Q,
                    'J' => Card::J,
                    'T' => Card::T,
                    '9' => Card::Nine,
                    '8' => Card::Eight,
                    '7' => Card::Seven,
                    '6' => Card::Six,
                    '5' => Card::Five,
                    '4' => Card::Four,
                    '3' => Card::Three,
                    '2' => Card::Two,
                    _ => panic!("Invalid card"),
                })
                .collect::<Vec<_>>();
            let bid = parts.next().unwrap().parse().unwrap();
            Hand { hand, bid }
        })
        .collect();
    hands.sort();

    let mut winnings: u32 = 0;
    for i in 1..=hands.len() {
        winnings += hands[i - 1].bid * i as u32;
    }
    Some(winnings)
}

Part 2

大悲，排序规则改了，卡的价值也改了。上面这一坨东西都要重写一遍了，唯独程序逻辑本身不用改，乐。

易证明结论，在讨论牌型时，将J全部当作除J外数量最多的牌即可。这一点体现在 merge_j 中。其他地方跟Part 1基本没有区别。

~~弃了，过了样例没过正经输入，先晾在这儿吧。~~ 当我一筹莫展之时，我在一篇帖子中看到有人提到 JJJJJ 的特例。的确，在之前错误代码 merge_j 的逻辑中，如果只有J没有其他卡，则这个牌组中一张卡都没有。输出也可以验证 JJJJJ 位列最后一位。

rust

    dict.remove(&Card2::J);
    if let Some(max_card) = max_card {
        *dict.entry(max_card).or_insert(0) += j_count;
    }

此时应该在 else 分支中插入五张J。不得不说Copilot比我想得更远，将 max_card 定义为了 Option<&&Card2>，从而包含了不存在其他卡的情况…

rust

#[derive(Debug, PartialEq, Eq, PartialOrd, Ord, Hash, Copy, Clone)]
enum Card2 {
    A = 14,
    K = 13,
    Q = 12,
    J = 1,
    T = 10,
    Nine = 9,
    Eight = 8,
    Seven = 7,
    Six = 6,
    Five = 5,
    Four = 4,
    Three = 3,
    Two = 2,
}

#[derive(Debug)]
struct Hand2 {
    hand: Vec<Card2>,
    bid: u32,
}

impl PartialOrd for Hand2 {
    fn partial_cmp(&self, other: &Self) -> Option<Ordering> {
        Some(self.cmp(other))
    }
}

impl PartialEq for Hand2 {
    fn eq(&self, other: &Self) -> bool {
        self.bid == other.bid
    }
}

impl Eq for Hand2 {}

fn merge_j(dict: &mut HashMap<&Card2, i32>) {
    // get the number of j and card with largest count
    let mut j_count = 0;
    let mut max_count = 0;
    let mut max_card = None;
    let dict_clone = dict.clone();
    for (card, count) in dict_clone.iter() {
        if card == &&Card2::J {
            j_count = *count;
        } else if *count > max_count {
            max_count = *count;
            max_card = Some(card);
        }
    }
    dict.remove(&Card2::J);
    if let Some(max_card) = max_card {
        *dict.entry(max_card).or_insert(0) += j_count;
    } else {
        dict.insert(&Card2::J, j_count);
    }
}

impl Ord for Hand2 {
    fn cmp(&self, other: &Self) -> Ordering {
        let mut self_dict = self.hand.iter().fold(HashMap::new(), |mut acc, card| {
            *acc.entry(card).or_insert(0) += 1;
            acc
        });
        let mut other_dict = other.hand.iter().fold(HashMap::new(), |mut acc, card| {
            *acc.entry(card).or_insert(0) += 1;
            acc
        });
        merge_j(&mut self_dict);
        merge_j(&mut other_dict);
        let self_weight = self_dict
            .iter()
            .map(|(_, count)| match count {
                5 => 30,
                4 => 20,
                3 => 10,
                2 => 5,
                1 => 1,
                _ => panic!("Invalid card count"),
            })
            .sum::<u32>();
        let other_weight = other_dict
            .iter()
            .map(|(_, count)| match count {
                5 => 30,
                4 => 20,
                3 => 10,
                2 => 5,
                1 => 1,
                _ => panic!("Invalid card count"),
            })
            .sum::<u32>();
        if self_weight > other_weight {
            return Ordering::Greater;
        } else if self_weight < other_weight {
            return Ordering::Less;
        } else {
            // compare `Card`s in descending order
            for (self_card, other_card) in self.hand.iter().zip(other.hand.iter()) {
                if self_card > other_card {
                    return Ordering::Greater;
                } else if self_card < other_card {
                    return Ordering::Less;
                }
            }
        }
        Ordering::Equal
    }
}

pub fn part_two(input: &str) -> Option<u32> {
    let mut hands: Vec<Hand2> = input
        .lines()
        .map(|line| {
            let mut parts = line.split_whitespace();
            let hand = parts
                .next()
                .unwrap()
                .chars()
                .map(|c| match c {
                    'A' => Card2::A,
                    'K' => Card2::K,
                    'Q' => Card2::Q,
                    'J' => Card2::J,
                    'T' => Card2::T,
                    '9' => Card2::Nine,
                    '8' => Card2::Eight,
                    '7' => Card2::Seven,
                    '6' => Card2::Six,
                    '5' => Card2::Five,
                    '4' => Card2::Four,
                    '3' => Card2::Three,
                    '2' => Card2::Two,
                    _ => panic!("Invalid card"),
                })
                .collect::<Vec<_>>();
            let bid = parts.next().unwrap().parse().unwrap();
            Hand2 { hand, bid }
        })
        .collect();
    hands.sort();

    let mut winnings: u32 = 0;
    for i in 1..=hands.len() {
        winnings += hands[i - 1].bid * i as u32;
        println!("#{}: {:?}", i, hands[i - 1]);
    }
    Some(winnings)
}

#[derive(Debug, PartialEq, Eq, PartialOrd, Ord, Hash, Copy, Clone)]
enum Card2 {
    A = 14,
    K = 13,
    Q = 12,
    J = 1,
    T = 10,
    Nine = 9,
    Eight = 8,
    Seven = 7,
    Six = 6,
    Five = 5,
    Four = 4,
    Three = 3,
    Two = 2,
}

#[derive(Debug)]
struct Hand2 {
    hand: Vec<Card2>,
    bid: u32,
}

impl PartialOrd for Hand2 {
    fn partial_cmp(&self, other: &Self) -> Option<Ordering> {
        Some(self.cmp(other))
    }
}

impl PartialEq for Hand2 {
    fn eq(&self, other: &Self) -> bool {
        self.bid == other.bid
    }
}

impl Eq for Hand2 {}

fn merge_j(dict: &mut HashMap<&Card2, i32>) {
    // get the number of j and card with largest count
    let mut j_count = 0;
    let mut max_count = 0;
    let mut max_card = None;
    let dict_clone = dict.clone();
    for (card, count) in dict_clone.iter() {
        if card == &&Card2::J {
            j_count = *count;
        } else if *count > max_count {
            max_count = *count;
            max_card = Some(card);
        }
    }
    dict.remove(&Card2::J);
    if let Some(max_card) = max_card {
        *dict.entry(max_card).or_insert(0) += j_count;
    } else {
        dict.insert(&Card2::J, j_count);
    }
}

impl Ord for Hand2 {
    fn cmp(&self, other: &Self) -> Ordering {
        let mut self_dict = self.hand.iter().fold(HashMap::new(), |mut acc, card| {
            *acc.entry(card).or_insert(0) += 1;
            acc
        });
        let mut other_dict = other.hand.iter().fold(HashMap::new(), |mut acc, card| {
            *acc.entry(card).or_insert(0) += 1;
            acc
        });
        merge_j(&mut self_dict);
        merge_j(&mut other_dict);
        let self_weight = self_dict
            .iter()
            .map(|(_, count)| match count {
                5 => 30,
                4 => 20,
                3 => 10,
                2 => 5,
                1 => 1,
                _ => panic!("Invalid card count"),
            })
            .sum::<u32>();
        let other_weight = other_dict
            .iter()
            .map(|(_, count)| match count {
                5 => 30,
                4 => 20,
                3 => 10,
                2 => 5,
                1 => 1,
                _ => panic!("Invalid card count"),
            })
            .sum::<u32>();
        if self_weight > other_weight {
            return Ordering::Greater;
        } else if self_weight < other_weight {
            return Ordering::Less;
        } else {
            // compare `Card`s in descending order
            for (self_card, other_card) in self.hand.iter().zip(other.hand.iter()) {
                if self_card > other_card {
                    return Ordering::Greater;
                } else if self_card < other_card {
                    return Ordering::Less;
                }
            }
        }
        Ordering::Equal
    }
}

pub fn part_two(input: &str) -> Option<u32> {
    let mut hands: Vec<Hand2> = input
        .lines()
        .map(|line| {
            let mut parts = line.split_whitespace();
            let hand = parts
                .next()
                .unwrap()
                .chars()
                .map(|c| match c {
                    'A' => Card2::A,
                    'K' => Card2::K,
                    'Q' => Card2::Q,
                    'J' => Card2::J,
                    'T' => Card2::T,
                    '9' => Card2::Nine,
                    '8' => Card2::Eight,
                    '7' => Card2::Seven,
                    '6' => Card2::Six,
                    '5' => Card2::Five,
                    '4' => Card2::Four,
                    '3' => Card2::Three,
                    '2' => Card2::Two,
                    _ => panic!("Invalid card"),
                })
                .collect::<Vec<_>>();
            let bid = parts.next().unwrap().parse().unwrap();
            Hand2 { hand, bid }
        })
        .collect();
    hands.sort();

    let mut winnings: u32 = 0;
    for i in 1..=hands.len() {
        winnings += hands[i - 1].bid * i as u32;
        println!("#{}: {:?}", i, hands[i - 1]);
    }
    Some(winnings)
}

Day 8

Part 1

迷你模拟题，给定一个可以重复走的方向序列和一张有向图，求从AAA到ZZZ所需的步数。甚至不需要自己找最短路径。

rust

pub fn part_one(input: &str) -> Option<u32> {
    let mut steps: u32 = 0;
    let mut curr_pos = "AAA";
    let lines = input.lines().collect::<Vec<_>>();
    let seq = lines[0];
    let mut direction = HashMap::<&str, (&str, &str)>::new();
    for line in lines[2..].iter() {
        // AAA = (BBB,CCC)
        let mut line = line.split(" = ");
        let key = line.next().unwrap();
        let mut line = line.next().unwrap().split(", ");
        let left = line.next().unwrap();
        let right = line.next().unwrap();
        direction.insert(key, (&left[1..], &right[0..3]));
    }
    while curr_pos != "ZZZ" {
        let index: usize = steps as usize % seq.len();
        curr_pos = match seq.chars().nth(index).unwrap() {
            'R' => direction.get(curr_pos).unwrap().1,
            'L' => direction.get(curr_pos).unwrap().0,
            _ => curr_pos,
        };
        steps += 1;
    }
    Some(steps)
}

Part 2

我曾经以为P2就是大号的P1，用一样的思路解决就行，直到程序跑了45分钟都没出结果，我才意识到这个P2可能有点儿太大了。

// TODO

Day 9

这道题我觉得我思路挺怪的，虽然没什么问题，也能过测试，但就是不对。观察下面的样例：

plaintext

1   3   6  10  15  21  28
  2   3   4   5   6   7
    1   1   1   1   1
      0   0   0   0

题目要求得出数列的下一个数。相邻的数减上几轮全都会变为0，大胆猜测原数列为一个多项式函数。于是想到直接将原方程求出来即可。样例中的差分法可以很方便地求出次数，然后用一些第三方库（如 polyfit_rs）求出各个系数，代入求出 $f(len(\text{nums}))$即可。

如果这个思路真的可行，那么第二问就很容易了：得出数列的前一个数，直接代入求出 $f(-1)$ 就行了。

可是不对，为什么呢？

rust

fn diff(nums: &Vec<i32>) -> u32 {
    let mut degree: u32 = 0;
    if nums.iter().all(|&x| x == nums[0]) {
        // special case
        return 0;
    }
    let mut diff = nums.clone();
    loop {
        // 0 3 6 9 12 15
        // -> 3 3 3 3 3
        // -> 0 0 0 0
        // then, times = 1; this is y=ax+b
        diff = diff
            .iter()
            .tuple_windows()
            .map(|(a, b)| b - a)
            .collect_vec();
        degree += 1;
        // if all diff is same, return times
        if diff.iter().all(|&x| x == diff[0]) {
            return degree;
        }
    }
}

pub fn part_one(input: &str) -> Option<i64> {
    let lines = input.lines().collect::<Vec<_>>();
    let mut sum = 0;
    for line in lines {
        let nums = line
            .split_whitespace()
            .map(|n| n.parse::<i32>().unwrap())
            .collect_vec();
        let degree = diff(&nums);
        let x_values = (0..nums.len()).map(|x| x as f64).collect_vec();
        let y_values = nums.iter().map(|&x| x as f64).collect_vec();
        let coefficients = polyfit_rs::polyfit(&x_values, &y_values, degree as usize).unwrap();
        let mut next = 0.0;
        // next = f(len(nums))
        for i in 0..degree as usize + 1 {
            next += coefficients[i] * (nums.len() as f64).powi(i as i32);
        }
        println!("{}", next.round() as i64);
        sum += next.round() as i64;
    }
    Some(sum)
}

Day 10

Part 1

给出的一张图描述了管道的连接情况，其中有个S点在管道的环路中，求出从某个点出发沿主（含S的）环路最远的距离。基本就是相当于要我们把环路找出来。

样例不得不使用ASCII字符代替Unicode制表符，毕竟很多语言对Unicode字符串的支持都挺……一般的。但我们看样例的时候可以进行一点儿替换：F -> ┌、7->┐、J->┘、L->└。

在我最初的实现中，直接使用一个DFS，从S点周围的管道出发，寻找能连上的管道。注意：

检查周围节点能否连上时，不仅要检查其管道是否指向本节点，而且还要检查本节点的管道是否指向它；
由于上面的原因，不要直接从S开始DFS，因为S点没有管道，自然连不上其他节点。

上面这个方法并没有修改地图本身（主要是S点）。但在第二部分中，有一个完全闭合的管道环路做起来会更舒服，所以我更新了第一部分的实现，找到S点后，依据四周的管道连接情况，将S修改为真正的管道。

rust

static LEFT_CONNECT: [char; 3] = ['-', 'L', 'F'];
static RIGHT_CONNECT: [char; 3] = ['-', 'J', '7'];
static TOP_CONNECT: [char; 3] = ['|', 'F', '7'];
static BOTTOM_CONNECT: [char; 3] = ['|', 'J', 'L'];

fn dfs(map: &Vec<Vec<char>>, map_dist: &mut Vec<Vec<Option<u32>>>, x: usize, y: usize) {
    let curr = map[x as usize][y as usize];
    let curr_dist = map_dist[x as usize][y as usize];
    if curr_dist.is_none() {
        return;
    }

    if x > 0 && TOP_CONNECT.contains(&map[x - 1][y]) && BOTTOM_CONNECT.contains(&curr) {
        let new_dist = curr_dist.unwrap() + 1;
        if map_dist[x - 1][y].is_none() || map_dist[x - 1][y].unwrap() > new_dist {
            map_dist[x - 1][y] = Some(new_dist);
            dfs(map, map_dist, x - 1, y);
        }
    }
    if x < map.len() - 1 && BOTTOM_CONNECT.contains(&map[x + 1][y]) && TOP_CONNECT.contains(&curr) {
        let new_dist = curr_dist.unwrap() + 1;
        if map_dist[x + 1][y].is_none() || map_dist[x + 1][y].unwrap() > new_dist {
            map_dist[x + 1][y] = Some(new_dist);
            dfs(map, map_dist, x + 1, y);
        }
    }
    if y > 0 && LEFT_CONNECT.contains(&map[x][y - 1]) && RIGHT_CONNECT.contains(&curr) {
        let new_dist = curr_dist.unwrap() + 1;
        if map_dist[x][y - 1].is_none() || map_dist[x][y - 1].unwrap() > new_dist {
            map_dist[x][y - 1] = Some(new_dist);
            dfs(map, map_dist, x, y - 1);
        }
    }
    if y < map[x].len() - 1
        && RIGHT_CONNECT.contains(&map[x][y + 1])
        && LEFT_CONNECT.contains(&curr)
    {
        let new_dist = curr_dist.unwrap() + 1;
        if map_dist[x][y + 1].is_none() || map_dist[x][y + 1].unwrap() > new_dist {
            map_dist[x][y + 1] = Some(new_dist);
            dfs(map, map_dist, x, y + 1);
        }
    }
}

pub fn part_one(input: &str) -> Option<u32> {
    let mut max_dist = 0;
    // array of array of chars
    let mut map = input
        .lines()
        .map(|line| line.chars().collect::<Vec<_>>())
        .collect::<Vec<_>>();
    let mut map_dist = vec![vec![None; map[0].len()]; map.len()];
    for x in 0..map.len() {
        for y in 0..map[x].len() {
            if map[x][y] != 'S' {
                continue;
            }
            let (mut up, mut down, mut left, mut right) = (false, false, false, false);
            if x > 0 && TOP_CONNECT.contains(&map[x - 1][y]) {
                up = true;
            }
            if x < map.len() - 1 && BOTTOM_CONNECT.contains(&map[x + 1][y]) {
                down = true;
            }
            if y > 0 && LEFT_CONNECT.contains(&map[x][y - 1]) {
                left = true;
            }
            if y < map[x].len() - 1 && RIGHT_CONNECT.contains(&map[x][y + 1]) {
                right = true;
            }
            map_dist[x][y] = Some(0);
            match (up, down, left, right) {
                (true, true, false, false) => map[x][y] = '|',
                (false, false, true, true) => map[x][y] = '-',
                (true, false, true, false) => map[x][y] = 'J',
                (false, true, false, true) => map[x][y] = 'F',
                (true, false, false, true) => map[x][y] = 'L',
                (false, true, true, false) => map[x][y] = '7',
                _ => (),
            }
            dfs(&map, &mut map_dist, x, y)
        }
    }
    for row in map_dist {
        for col in row {
            if let Some(dist) = col {
                max_dist = max_dist.max(dist);
            }
        }
    }
    Some(max_dist)
}

static LEFT_CONNECT: [char; 3] = ['-', 'L', 'F'];
static RIGHT_CONNECT: [char; 3] = ['-', 'J', '7'];
static TOP_CONNECT: [char; 3] = ['|', 'F', '7'];
static BOTTOM_CONNECT: [char; 3] = ['|', 'J', 'L'];

fn dfs(map: &Vec<Vec<char>>, map_dist: &mut Vec<Vec<Option<u32>>>, x: usize, y: usize) {
    let curr = map[x as usize][y as usize];
    let curr_dist = map_dist[x as usize][y as usize];
    if curr_dist.is_none() {
        return;
    }

    if x > 0 && TOP_CONNECT.contains(&map[x - 1][y]) && BOTTOM_CONNECT.contains(&curr) {
        let new_dist = curr_dist.unwrap() + 1;
        if map_dist[x - 1][y].is_none() || map_dist[x - 1][y].unwrap() > new_dist {
            map_dist[x - 1][y] = Some(new_dist);
            dfs(map, map_dist, x - 1, y);
        }
    }
    if x < map.len() - 1 && BOTTOM_CONNECT.contains(&map[x + 1][y]) && TOP_CONNECT.contains(&curr) {
        let new_dist = curr_dist.unwrap() + 1;
        if map_dist[x + 1][y].is_none() || map_dist[x + 1][y].unwrap() > new_dist {
            map_dist[x + 1][y] = Some(new_dist);
            dfs(map, map_dist, x + 1, y);
        }
    }
    if y > 0 && LEFT_CONNECT.contains(&map[x][y - 1]) && RIGHT_CONNECT.contains(&curr) {
        let new_dist = curr_dist.unwrap() + 1;
        if map_dist[x][y - 1].is_none() || map_dist[x][y - 1].unwrap() > new_dist {
            map_dist[x][y - 1] = Some(new_dist);
            dfs(map, map_dist, x, y - 1);
        }
    }
    if y < map[x].len() - 1
        && RIGHT_CONNECT.contains(&map[x][y + 1])
        && LEFT_CONNECT.contains(&curr)
    {
        let new_dist = curr_dist.unwrap() + 1;
        if map_dist[x][y + 1].is_none() || map_dist[x][y + 1].unwrap() > new_dist {
            map_dist[x][y + 1] = Some(new_dist);
            dfs(map, map_dist, x, y + 1);
        }
    }
}

pub fn part_one(input: &str) -> Option<u32> {
    let mut max_dist = 0;
    // array of array of chars
    let mut map = input
        .lines()
        .map(|line| line.chars().collect::<Vec<_>>())
        .collect::<Vec<_>>();
    let mut map_dist = vec![vec![None; map[0].len()]; map.len()];
    for x in 0..map.len() {
        for y in 0..map[x].len() {
            if map[x][y] != 'S' {
                continue;
            }
            let (mut up, mut down, mut left, mut right) = (false, false, false, false);
            if x > 0 && TOP_CONNECT.contains(&map[x - 1][y]) {
                up = true;
            }
            if x < map.len() - 1 && BOTTOM_CONNECT.contains(&map[x + 1][y]) {
                down = true;
            }
            if y > 0 && LEFT_CONNECT.contains(&map[x][y - 1]) {
                left = true;
            }
            if y < map[x].len() - 1 && RIGHT_CONNECT.contains(&map[x][y + 1]) {
                right = true;
            }
            map_dist[x][y] = Some(0);
            match (up, down, left, right) {
                (true, true, false, false) => map[x][y] = '|',
                (false, false, true, true) => map[x][y] = '-',
                (true, false, true, false) => map[x][y] = 'J',
                (false, true, false, true) => map[x][y] = 'F',
                (true, false, false, true) => map[x][y] = 'L',
                (false, true, true, false) => map[x][y] = '7',
                _ => (),
            }
            dfs(&map, &mut map_dist, x, y)
        }
    }
    for row in map_dist {
        for col in row {
            if let Some(dist) = col {
                max_dist = max_dist.max(dist);
            }
        }
    }
    Some(max_dist)
}

Part 2

我们在第一部分找出了S点连接的主管道，第二部分则要求我们求出主管道包含的面积。由于第一问写下的DFS函数已经记录了主管道上所有点到S的距离，所以只要跑一遍，主管道范围的边界就确定了。

下一步就是数有哪些字符在主管道范围内了。本身的想法是按行遍历，完全忽略横向边界，维护一个bool变量判定是否在边界内，穿越一次边界就将其反转；又想了想，在一个字符内除了 | 跨越一整个边界外，那些弯弯折折的管道都只跨越上半/下半边界。CHANGE_<UP/DOWN>_HALF 就是记录这些字符的数组。当且仅当当前字符不属于主管道，且字符的上下半都在边界内时，计数器加一。

很抽象是吧，或许看到下面的图你会明白点。

plaintext

.┌----┐┌┐┌┐┌┐┌-┐....
.|┌--┐||||||||┌┘....
.||.┌┘||||||||└┐....
┌┘└┐└┐└┘└┘||└┘.└-┐..
└--┘.└┐...└┘S┐┌-┐└┐.
....┌-┘..┌┐┌┘|└┐└┐└┐
....└┐.┌┐||└┐|.└┐└┐|
.....|┌┘└┘|┌┘|┌┐|.└┘
....┌┘└-┐.||.||||...
....└---┘.└┘.└┘└┘...

rust

static CHANGE_UP_HALF: [char; 3] = ['|', 'J', 'L'];
static CHANGE_DOWN_HALF: [char; 3] = ['|', 'F', '7'];

pub fn part_two(input: &str) -> Option<u32> {
    // array of array of chars
    let mut map = input
        .lines()
        .map(|line| line.chars().collect::<Vec<_>>())
        .collect::<Vec<_>>();
    let mut map_dist = vec![vec![None; map[0].len()]; map.len()];
    for x in 0..map.len() {
        for y in 0..map[x].len() {
            if map[x][y] != 'S' {
                continue;
            }
            let (mut up, mut down, mut left, mut right) = (false, false, false, false);
            if x > 0 && TOP_CONNECT.contains(&map[x - 1][y]) {
                up = true;
            }
            if x < map.len() - 1 && BOTTOM_CONNECT.contains(&map[x + 1][y]) {
                down = true;
            }
            if y > 0 && LEFT_CONNECT.contains(&map[x][y - 1]) {
                left = true;
            }
            if y < map[x].len() - 1 && RIGHT_CONNECT.contains(&map[x][y + 1]) {
                right = true;
            }
            map_dist[x][y] = Some(0);
            match (up, down, left, right) {
                (true, true, false, false) => map[x][y] = '|',
                (false, false, true, true) => map[x][y] = '-',
                (true, false, true, false) => map[x][y] = 'J',
                (false, true, false, true) => map[x][y] = 'F',
                (true, false, false, true) => map[x][y] = 'L',
                (false, true, true, false) => map[x][y] = '7',
                _ => (),
            }
            dfs(&map, &mut map_dist, x, y)
        }
    }

    let mut count = 0;
    for x in 0..map.len() {
        let (mut up_half, mut down_half) = (false, false);
        for y in 0..map[x].len() {
            if map_dist[x][y].is_some() && CHANGE_UP_HALF.contains(&map[x][y]) {
                up_half = !up_half;
            }
            if map_dist[x][y].is_some() && CHANGE_DOWN_HALF.contains(&map[x][y]) {
                down_half = !down_half;
            }
            if up_half && down_half && map_dist[x][y].is_none() {
                count += 1;
            }
        }
    }
    Some(count)
}

static CHANGE_UP_HALF: [char; 3] = ['|', 'J', 'L'];
static CHANGE_DOWN_HALF: [char; 3] = ['|', 'F', '7'];

pub fn part_two(input: &str) -> Option<u32> {
    // array of array of chars
    let mut map = input
        .lines()
        .map(|line| line.chars().collect::<Vec<_>>())
        .collect::<Vec<_>>();
    let mut map_dist = vec![vec![None; map[0].len()]; map.len()];
    for x in 0..map.len() {
        for y in 0..map[x].len() {
            if map[x][y] != 'S' {
                continue;
            }
            let (mut up, mut down, mut left, mut right) = (false, false, false, false);
            if x > 0 && TOP_CONNECT.contains(&map[x - 1][y]) {
                up = true;
            }
            if x < map.len() - 1 && BOTTOM_CONNECT.contains(&map[x + 1][y]) {
                down = true;
            }
            if y > 0 && LEFT_CONNECT.contains(&map[x][y - 1]) {
                left = true;
            }
            if y < map[x].len() - 1 && RIGHT_CONNECT.contains(&map[x][y + 1]) {
                right = true;
            }
            map_dist[x][y] = Some(0);
            match (up, down, left, right) {
                (true, true, false, false) => map[x][y] = '|',
                (false, false, true, true) => map[x][y] = '-',
                (true, false, true, false) => map[x][y] = 'J',
                (false, true, false, true) => map[x][y] = 'F',
                (true, false, false, true) => map[x][y] = 'L',
                (false, true, true, false) => map[x][y] = '7',
                _ => (),
            }
            dfs(&map, &mut map_dist, x, y)
        }
    }

    let mut count = 0;
    for x in 0..map.len() {
        let (mut up_half, mut down_half) = (false, false);
        for y in 0..map[x].len() {
            if map_dist[x][y].is_some() && CHANGE_UP_HALF.contains(&map[x][y]) {
                up_half = !up_half;
            }
            if map_dist[x][y].is_some() && CHANGE_DOWN_HALF.contains(&map[x][y]) {
                down_half = !down_half;
            }
            if up_half && down_half && map_dist[x][y].is_none() {
                count += 1;
            }
        }
    }
    Some(count)
}

《城市：天际线 2》：未来可期，但不是现在

Fri, 10 Nov 2023 23:21:00 +0800

刁民模拟器、堵车模拟器、比较温和的P社战犯模拟器游戏系列《城市：天际线》在打磨了七年DLC后，终于有了它的第二部作品。但相比2015年发售时仅需88人民币¹的价格，预售218人民币、发售后甚至涨到248元的价格属实有点差异过大了。诚然，就本体来说，天际线2在AI、经济、建筑等方面都有了长足的进步，但单单作为本体来讲，个人觉得不值得一部《战神》的价格（50 USD）。

阅前注意：以下内容为首发阶段体验。 作者使用 ~~低配电脑（Ryzen 7 4800H、32GB、GTX 1650）~~ 已换成U7 155H和4060 Ti游玩，~~并使用破解版游戏~~已补票，体验仅供参考；体验仅限2023年11月版本，无DLC，未提及时版本为1.0.12F1，不代表后期体验。

先夸一夸吧。大量机制都沿袭了前作的逻辑，仍然很让人上瘾。车道线分流，很好，一条路终于可以优雅地分成好几条了。铺电线和水管也简单了好多，终于跟着路走而不是需要自己铺了，甚至能进口，懒人福音。建筑物扩展也挺有意思，有点儿《模拟城市5》的感觉了。城市有数十万人口后，市民不乘地铁的bug也没有了。地形编辑工具也没那么多破事儿了，地面一抹就平，虽然相比前作没那么“真实”了，但真的能极大程度提高游玩体验。这些都是让人很难回到前作的提升。

相比前作，天际线2的车辆很少凭空消失了，NPC再也不会从裤裆里凭空掏出一辆车。这个地方或许是路边，或许是自己建的停车场，也或许是……堵在路上。前作在彻底堵死的路段部分车辆会消失，而在2中则几乎绝迹。但十分抽象的是，有轨电车似乎很喜欢玩消失，眼睁睁看到它们离站台只剩一个路口，啪，消失了。于是站台等车的几千人（是的，几千人）就只能干等着。

车辆的行为也有点儿抽象，路口有了左转专用道，但没有左转单独红绿灯；即使有右转专用道，右转车也要等红绿灯；路口从来没有实线，导致许多车不到拐弯不变道。

官方自豪地宣称，当原来的路线堵车时，车辆会选择其他路线了。这倒是确实，于是大家都不走大路了，就嗯在小路里转 ~~，堪称高德地图植入广告了~~ 。禁止左转的地方偏左转，公交车道非要开进去，高速上偶尔还会出现不知道哪来的一辆车创飞数辆车，把整条路都堵了，警车都过不来。确实是生机勃勃的城市呢，可惜没有交警不能罚款，不然我估计连税都不用收了，不过貌似市民也没有驾照这回事。

《公交车道》

一次离奇事故

同样的问题也出现在行人上，路口没有人行道的地方就嗯横穿，车还不得不让。说到人行道啊，这一代的天桥就是更抽象的东西了。托坡道的福，天桥要占用的空间比路口本身大上数倍，几乎不具备实用性，即使降低到允许最低的高度6.25m也是如此。下面是我修的唯一一个人行天桥，自从我发现它占空间大还没人走之后，我就再也没修过了。顺便说一下，与某些人设想的不同，行人的行为似乎跟教育水平没啥关系。

没卵用的天桥

公共交通建筑也还是有缺憾，地铁站天生不带多线换乘，只能在远处再修一个站，然后让线路强行下穿（不搞站内换乘，太有伦敦味儿了）。

可能有些人会争论，前作的车辆行为也很抽象，凭空消失更多，地铁站也没有换乘，balabala。但前作开箱支持mod，而二代……还没有。车辆凭空消失问题，车道通行规则问题，TMPE能解决；地铁站换乘问题，有各种资产mod；天桥问题，可以移除“坡度过陡”提示；甚至地图过小，还可以解锁81格地图，建几个卫星城都行（我做到过100万人）。我在前作的创意工坊里订阅了80个mod；二代的mod系统，则不知道什么时候才能出现。

教育和工业/办公区也是相对于一代改变不小的部分。我实在是搞不懂为什么小学的需求会那么大，一个30万人的城市里竟然有8万人要上小学，而只有数千人要上中学。每建一所小学，1500人的容量都会在两小时内被占满。综合性大学供不应求，但建了大学却没人上，难道游戏里的大学也分双一流和四非？

奇怪的教育需求

单单是满足小学的需求外加几个研究设施，教育花费就已经跃升到了第一名，把建筑铲一大半建小学自然也不现实。再加上工业和办公需求被分开了，前作中把所有人都赶进办公区的减少污染取巧办法也就不管用了。

至于多受诟病的性能问题反而并没有很严重，符合我对我电脑性能的期望，也可能是因为CO（Colossal Orders，即制作工作室，下同）为玩家打了预防针。最低画质，满屏狗牙，主菜单还有70多帧，游戏内CPU能够几乎全部占满，在设置性能不足时“CPU优先用于模拟”（是的，提供了这个选择，很好）的情况下，4800H在大约20万人的时候差不多能维持3倍模拟速度。对于30万人的城市，一般能维持在10-15帧，目测最高模拟速度仅为1~1.5倍；而在人流量巨大的地铁站旁边的路口，会降到3帧以内，所幸拉远点就好了。

最低画质下的画面质量

《城市：天际线2》现阶段确实令人着迷，也是我后期很大概率会补票的游戏。我相信CO会持续不断地优化它 ~~（也会持续不断推出坑钱DLC）~~ ，但以现在的质量，我可能暂时不会买，也不会再玩很多了。

2024/03/17补充：

这游戏有了非官方的Mod方案，也有了些比如允许车辆在红灯右转，增加小学容量，解锁所有格子，以及更改寻路违法代价等。然而，这些Mod仍然不稳定，并没有Harmony之类冲突解决方案，管理起来也麻烦，非官方的API也会在升级的时候break掉，于是游戏就会在毫无准备的情况下直接闪退，玩家完全没有头绪。然而一旦玩过这些Mod之后就完全无法忍受原版游戏的诸多问题了，于是我的选择是等Paradox Mods实装，看开发组嘴里能吐出什么象牙来。

另外我算是知道了为什么市民不乘地铁了，这b游戏在人口十万之前，大部分人仍然会出门，而当人口越来越多，街道上却异常的空，因为大部分上学上班的都呆家里了，不出门。然而购物的人却还是正常出门，于是满大街都是购物的人，不禁让人怀疑这经济是不是好过头了。末了逛完又不知为啥要把宠物狗扔在街上，于是整条路上狗都比人多。

理论上，每周一开发者都会在Steam上发Word of the Week，也就是工作周报。然而本该3月4日发布15期周报报道美术团队的周报没了，合着你们根本没有美术团队呗？其他好几期也遮遮掩掩，看似在深入游戏系统，实际上大部分都是打太极。Steam近期评价已经为多半差评（29% 好评）了，真是罪有应得。规模相当的《幻兽帕鲁》开发商Pocketpair还大大方方承认自己做的是个半成品呢，修起bug来也比CO快，CO社还要反过来抱怨“toxic”的社区环境，你特么不配，我呸。

预计三月底之前官方的Paradox Mods就要发布beta了，观察一下，且看它能把这款差点暴死的游戏救到什么程度。

2024/04/01补充：

前几天CO兑现了它的承诺，Paradox Mods挂着一个大大的“Beta”如期而至。个人不介意没有创意工坊，毕竟如果真的能福利主机和Epic玩家，那也是个好事儿。许多代码mod已经渐渐往官方平台上开始搬运了，甚至还有启用成就的mod（那解锁DLC……？）。单单说这次更新来说，我的评价是非常正面的，超出我的预期。

然而即使这样，也不得不提它目前的一些缺陷。这次只支持了地图和代码（机制和数值）mod，离在游戏里部署CR400AF-Z很遗憾还有点距离。模组稳定性也堪忧，目前没有1代的Harmony那样的机制，遇到过一次黑屏，一次HUD消失，不知道以后会不会还有类似的bug。许多mod作者也坚守Thunderstore和P社赌气，我的评价是开发商全责好吧。

这款游戏应该还是会成为综合最好的城市建造模拟游戏，只是还需要很久，比我半年前预想的更久。且看CO如何推动历史的行程了。

2024/07/05补充：

果然这游戏的有意思玩法还是得靠Mod社区。虽然现在还没有官方的资产解决方案，但代码Mod已经开始欣欣向荣了。前述的Mod不兼容现象和站队分庭抗礼现象也基本消失了。前面提到的问题，大多也已经在一次次更新中被官方解决了，或是由Mod解决。还多亏了经济2.0，人一多也不会市中心空心化了，我们的游戏真是欣欣向荣呢。

这里要特别提到无碰撞Mod，搭配可以到处设站台的Mod，可以自己修地铁站，自己修出入口，各种越行线和节点换乘，比官方的地铁站高到不知哪里去了。修天桥也不再是空谈，就是坡度有点阴间。

当然我并不是说这款游戏已经值得买了；相反的是，大概再过三个月，到资产Mod开放再来决定也不迟，最迟应该也不会迟过12月初的秋促。毕竟我的差评还留在商店页面上呢。

2026/01/10补充：

好家伙又一年半过去了，在刚过去的12月里，开发者新增了资产Mod的支持，还有自行车、火车地铁车厂、港口等一系列免费或是收费的新机制新建筑。闪退和崩溃大大减少，现在的性能问题基本要么是自己性能不够要么更大概率是模组问题。更好的消息是Colossal Orders嗝屁了，地理距离几百米开外的新工作室变为P社直属，让游戏的开发不光要靠工作室奋斗，还要看P社的行程。

目前最大的问题是数值的崩坏，摩天大楼DLC一栋办公楼能提供300多个车位、7000多个学院制大学的名额，或是多于一个分拣中心的邮件处理效率，甚至更暴力的全程矿脉+100%；而供应链DLC的建筑常常能够增加15%全城工业效率，这下工业区招不满人的问题彻底解决了。更别提几十万人之后无需求无迁入的鬼城问题了，不知道CO是不是见识了北美城市的空心化进程，但好像他们对低密度房屋也没需求。

至于新的工作室还会不会把加号打成减号，我们拭目以待。

https://steamdb.info/app/255710/ ↩︎

USTC Hackergame 2023 个人 Writeup

Sat, 04 Nov 2023 12:00:00 +0800

HG虐我千百遍，我待HG如初恋。

*小菜鸡一个，写不了几道题，单纯记录一下。所有题目版权归USTCLUG所有。

Hackergame启动

初见题目，还以为是把相似度POST到服务器上，正准备curl一把梭，直到我点了一下提交。

好家伙，地址栏出现了一个param，原来是个GET，直接把 similarity 改为114514，结束战斗。

感觉发现规律了，签到题经常出现改改地址栏就能解决的题目……

猫咪小测

今年的猫咪问答变简单了，感觉难度是逐年递减的亚子。再也没有20/21两年的压迫感了。

想要借阅世界图书出版公司出版的《A Classical Introduction To Modern Number Theory 2nd ed.》，应当前往中国科学技术大学西区图书馆的哪一层？

Google到中科大图书馆网站，搜索馆藏，很容易找到在西区外文书库。回到网站首页找到馆藏分布，得外文书库在第 12 层。

今年arXiv网站的天体物理版块上有人发表了一篇关于「可观测宇宙中的鸡的密度上限」的论文，请问论文中作者计算出的鸡密度函数的上限为10的多少次方每立方秒差距？

在arxiv.org的advanced search上选择天体物理（astro-ph），搜索“density of chicken”，只有一个候选结果。

我也不知道什么叫每立方秒差距，但abstract有一句：

We find the most restrictive upper limit from the domains considered to be $10^{23}\ pc^{−3}$, which ruffles the feathers of long-standing astrophysics theory.

看来这abstract还真是简明扼要，答案就是 23。

为了支持TCP BBR拥塞控制算法，在编译Linux内核时应该配置好哪一条内核选项？

Google “linux tcp bbr option”，得到答案为 CONFIG_TCP_CONG_BBR。

这个题目问GPT也能得到很好的效果。

🥒🥒🥒：「我……从没觉得写类型标注有意思过」。在一篇论文中，作者给出了能够让Python的类型检查器MyPY mypy陷入死循环的代码，并证明Python的类型检查和停机问题一样困难。请问这篇论文发表在今年的哪个学术会议上？

不知道有没有人注意到“发表在今年的哪个学术会议上”这个很别扭的讲法，但题目从来没说是今年写的论文。在Google Scholar搜索“python type”，筛选今年的文章，然后……逐篇枚举。于是找到了答案Python Type Hints Are Turing Complete，发表在 ECOOP 2023上。

题目的迷惑性还是很大的，一方面Google Scholars并不能搜到ECOOP上的内容（而是标注为drops.dagstuhl.de），另一方面仅靠标题和abstract并不能很容易对应题目的意思，甚至这篇文章也不是今年写的（2022年就挂在了arXiv上）。

更深更暗

简单划了一下，看样子是个无限往下滑的网页，网页的长度会越来越长。直接打开开发者模式，搜索flag，解决。

是我眼花了吗？我刚刚有一瞬间好像在残骸上看到了一个flag？

~~或许也可以找一台足够低配的电脑，一直往下滑，生成跟不上滑动会卡，就能看到潜水艇字符画了~~

旅行照片3.0

看样子旅行照片会比去年难一点儿，但不至于像21年一样没什么头绪。难点反而加在了日语上面。拜托组委会下次能不能找个英语系国家的地点……

1、你还记得与学长见面这天是哪一天吗？（格式：yyyy-mm-dd）

2、在学校该展厅展示的所有同种金色奖牌的得主中，出生最晚者获奖时所在的研究所缩写是什么？

直接找到“学长”脖子上挂的牌子，STATPHYS 28，得到地址为东京大学附近，23年8月7-11日左右。打开Google Maps，在东京大学附近找喷泉和博物馆，很容易找到上野公園和東京国立博物館（实际上附近博物馆很多）。

上野公園

打开街景一看，完全一样有没有。这条信息先放下。

搜索奖牌上的名字M. Kosiba（小柴昌俊），得到他确实在东京大学任职过。MMII指2002年，他在2002年获得了帕诺夫斯基实验粒子物理学奖，以及诺贝尔物理学奖，查了一下，奖牌是诺奖的样式。

Google搜索 “tokyo university nobel prize”（~~typo应该为university of tokyo~~），找到了东京大学理学部的 Science Gallery，确实是个展厅。在这个展厅中展出了三个诺贝尔物理学奖奖牌，分别为：

小柴昌俊，2002，出生于1926/09/19
梶田隆章，2015，出生于1959/03/09
真锅淑郎，2021，出生于1931/09/21

经过一点对最小的梶田隆章的搜索：

He became director of the Center for Cosmic Neutrinos at the Institute for Cosmic Ray Research (ICRR) in 1999. As of 2017, he is a Principal Investigator at the Institute for the Physics and Mathematics of the Universe in Tokyo, and Director of ICRR.

得到他在2015年位于 ICRR。回到题目，第一个问题直接在日期范围内进行暴力枚举，得到 2023-08-10。

3、帐篷中活动招募志愿者时用于收集报名信息的在线问卷的编号（以字母S开头后接数字）是多少？

4、学长购买自己的博物馆门票时，花费了多少日元？

Google筛选含有“上野公園大噴水”、2023年8月1-10日的网站，用日期反推这一日发生的活动，得到在举行“全国梅酒まつりin東京2023”，而且似乎确实在帐篷里，15时开始也符合信息。搜索“全国梅酒まつりin東京2023ボランティア”（2023年东京全国梅酒节志愿者），很容易找到招募志愿者的网站（ボランティアSTAFF大募集！！第６回「全国梅酒まつりin東京2023」），得到问卷编号 S495584522。

根据“马路对面的喷泉”这一信息，确定了博物馆指的是东京国立博物馆（Tokyo National Museum）。答案是 0，不知道为什么。

5、学长当天晚上需要在哪栋标志性建筑物的附近集合呢？（请用简体中文回答，四个汉字）

6、进站时，你在JR上野站中央检票口外看到「ボタン＆カフリンクス」活动正在销售动物周边商品，该活动张贴的粉色背景海报上是什么动物（记作A，两个汉字）？在出站处附近建筑的屋顶广告牌上，每小时都会顽皮出现的那只3D动物是什么品种？（记作B，三个汉字）？（格式：A-B）

在STATPHYS 28网站上并没有找到10日晚上有什么活动，但on-site plenary and special session都在Yasuda Auditorium（安田讲堂）。蒙对了。

搜索“ボタン＆カフリンクスJR上野”，点进第一个结果，是熊猫（如下图）。

摊位的照片（图源上面的网站）

马里奥世界指的显然是Nintendo Tokyo，谷歌地图指示在渋谷駅（涩谷站）下车，按照“渋谷駅3D看板”搜索，很容易得到秋田犬。

赛博井字棋

众所周知，只要两边水平够高都不是那么菜，那么井字棋就只能下平局。但是，如果能“吃掉”别人的棋子呢……？

通过分析网络请求很容易看出，每次点击棋盘上没下的位置，都会发送一个形如 {"x":"0","y":"0"} 的JSON到服务器上，而服务器会返回一个描述棋盘的二维数组，还会有一个Set-Cookie。看起来每个棋盘状态都会有一个对应的Cookie。比如：

bash

$ curl -v -XPOST -H 'Cookie: session=eyJib2FyZCI6W1sxLDAsMF0sWzAsLTEsMF0sWzAsMCwtMV1dLCJ0b2tlbiI6Im1hc2tlZCJ9.ZTz-wA.fN5F9EKrWxW87_WtN-noABlu2_U; HttpOnly; Path=/' -H "Content-type: application/json" -d '{"x":"1","y":"1"}' 'http://202.38.93.111:10077/'
Note: Unnecessary use of -X or --request, POST is already inferred.
*   Trying 202.38.93.111:10077...
* Connected to 202.38.93.111 (202.38.93.111) port 10077
> POST / HTTP/1.1
> Host: 202.38.93.111:10077
> User-Agent: curl/8.4.0
> Accept: */*
> Cookie: session=eyJib2FyZCI6W1sxLDAsMF0sWzAsLTEsMF0sWzAsMCwtMV1dLCJ0b2tlbiI6Im1hc2tlZCJ9.ZTz-wA.fN5F9EKrWxW87_WtN-noABlu2_U; HttpOnly; Path=/
> Content-type: application/json
> Content-Length: 17
>
< HTTP/1.1 200 OK
< Server: nginx/1.23.2
< Date: Sat, 28 Oct 2023 12:33:57 GMT
< Content-Type: application/json
< Content-Length: 38
< Connection: keep-alive
< Vary: Cookie
< Set-Cookie: session=eyJib2FyZCI6W1sxLDAsMF0sWzAsLTEsMF0sWzAsMCwtMV1dLCJ0b2tlbiI6Im1hc2tlZCJ9.ZTz_tQ.cxnMFfNUi4gSU6CECDbO8E4evjw; HttpOnly; Path=/
<
{"board":[[1,0,0],[0,-1,0],[0,0,-1]]}

既然点击浏览器中已经有棋子的位置没有反应，那么就可以使用curl模拟请求，像上面这样。只需要在浏览器中随便点击一个棋子，然后复制Set-Cookie值，再把请求体设为刚刚电脑选择的位置，就可以吃掉电脑的棋子了。终于有三个棋子连起来的时候，服务器的response里面就会带flag。

PS：状态信息似乎并不存在于服务器中，而是直接编码于cookie中。在session的值中，英文句号之前的位置就是base64编码的棋盘状态和做题者的token（上面的token我都处理啦，不要解码了）。

组委会模拟器

这道题的核心在于如何快速找到对应的元素并模拟点击。靠人手点肯定不行的，但丰富的 ~~刷网课~~ 冲浪经验告诉我，可以使用用户脚本来自动扫描符合正则的元素。把它加载到对应的插件上（比如Violentmonkey），就可以自动运行了。

我一行代码都没写，全靠GPT。对于写简单的代码，GPT已经完全可用了。附上完整对话

javascript

// ==UserScript==
// @name        Hackergame Auto Withdraw
// @namespace   Violentmonkey Scripts
// @match       http://202.38.93.111:10021/
// @grant       none
// @version     1.0
// @author      cyp0633 (with GPT-3)
// @description 2023/10/30 16:06:16
// ==/UserScript==


(function() {
    'use strict';

    // Regular expression to match "hack[...]" with any text inside "[...]"
    const regex = /hack\[[^\]]+\]/;

    // Function to detect and click on elements matching the regular expression
    function autoClickHackContent() {
        const elements = document.querySelectorAll('*'); // Select all elements on the page (you can narrow this down if needed)

        for (const element of elements) {
            if (regex.test(element.textContent)) {
                element.click();
            }
        }
    }

    // Run the detection function every 1 second
    setInterval(autoClickHackContent, 1000);
})();

这段代码每秒钟遍历一次网页上的元素，遇到匹配flag正则的内容就点击它。在MBP13 2020上，使用Firefox，速度完全可以跟上撤回消息。

《赛博朋克 2077》：欢迎来到黑暗未来

Sun, 01 Oct 2023 22:46:00 +0800

写下这篇文章是在2023年下旬，距离2077的发售日2020年12月10日，已经过去了差不多三年。如果说发售时一款游戏的评价取决于开发商的野心，那么它真正完善时的评价则取决于开发商的良心——于是，波兰蠢驴在三年中发布了无数的Bugfix，以及一个大型资料片《往日之影》。正好借着降价，我买了同捆包补票，体验一下带有狗镇的二周目，顺便简单写点儿东西。

游戏稳定性。 这款游戏最受诟病的地方，毫无疑问是无穷无尽、源源不断的bug，直到推出《往日之影》后，修复仍然是2.01更新的主要内容。但好在游玩了几天2.0版本之后，已经不再有“『黑』梦”这么离奇的bug，最干扰正常游玩的闪退问题也在2.01版本中被修复。但仍然有少数影响游玩的问题，比如在进行“好车不怕晚”任务时，车进入车库后直接下车，则无法上车把车停进预期位置；通过侧门离开车库，却发现院门和车库侧门都已无法打开，角色被困在院子里，无奈只能读档。此外还有不止一次遇到的敌人尸体悬浮bug（见下图），只能说修了一个又冒出来一个，bug仍然是这款游戏的主要缺点。

敌人的尸体悬浮

世界观。 好了，主要缺点讲完了，其灵魂则是富有生机而又死气沉沉的夜之城。如此一个看不到希望的吃人社会，在CDPR的描绘下像是真实摆在面前一样。我必须承认夜之城地图并不大，但承载的却是一个崭新而庞大的赛博朋克世界观。而如此规模的世界观，则承载于回味悠长的主线和支线任务、巨量额外剧情文本，甚至动画《边缘行者》之上。精彩的支线任务我首推《猎杀(The Hunt)》，然后是德拉曼线《机械与人格(Human Nature)》（~~滴滴，你个王八蛋~~）以及《向法律宣战(I Fought The Law)》。每个都令人回味十足，《猎杀》通关之余甚至会带来强烈的精神污染；赛博精神病关卡虽然流程都是同样的套路，但人们疯掉的理由各不相同。

主线故事。 让我们抛掉CDPR画的饼，丢下所谓的分支剧情，起码本体的主线剧情在刻画人物和世界的方面还是很成功的，我会给一个好评。然而比起《往日之影》，本体的剧情就要逊色不少，当你打通《往日之影》时，一定会像我一样赞叹。

本地化。 本地化又是一个值得称道的方面。少见的地道脏话且不论，我也能感受到CV们投入了情感的演绎。除了配音，各种文本的翻译也恰如其分。整款游戏玩下来，就本地化方面，我完全感受不到是一个外国团队做的游戏。狗镇的台词更上一层楼，加入了更多口语化表达，甚至neta了一个张家辉梗，只能说团队里有人是懂的：

你知道我这七年是怎么过的吗？

画面。 画质我大概没啥权利评判，毕竟我是1650顶着FSR 2.1玩中画质的极低配玩家，但相比来说，三年内优化提高了不少。

最后附上我在Steam上写的评价：

同样是玩2077，可以选择10小时快速过主线剧情打通，也可以选择花50（+往日之影目前20）小时，边在夜之城遨游边体验剧情。

体验上完全是两款游戏，前者很平庸，而后者完全能值回300块钱票价。为什么不试试后者呢？

我最终还是放弃了自己托管邮箱——转为了 Fastmail

Sun, 01 Oct 2023 22:46:00 +0800

不可否认的是，maddy 是一款非常优秀、令人舒适的邮件服务器软件，关于安装，我写过一篇文章¹。在使用它的接近两年内，除了升级，我完全没有动过它，就连升级时也基本是无痛的。如果谁仍然想要自建一个邮件服务器，我还是会推荐maddy。五美元一月的Vultr托管邮件也十分稳定，25端口也只需要开个工单就能开通，同时Maddy占内存极小，跑点儿其他的也不亏。一切都按预期正常工作着，但还是有一些放弃自己托管的理由：

有时会当成spam，这个得怪收件人信箱，但确实是个普遍问题²；
没有一个好用的webmail，之前用的Rainloop总感觉差那么点意思，而且独立的webmail总要多占一份空间；
担心downtime，所以非常要紧的服务一直都用Gmail ~~（实际上downtime比我梯子挂掉的时间还少）~~ ；
每个月得花 $5，虽然不多，但是也不少（手上其他服务器不给开25端口）；
~~大四闲得慌。~~

Maddy作为部署简单、功能全面的邮件服务器可以说是先行者了，现在也涌现了许多很好的自托管服务，比如 mox 解决了webmail的问题。当然这篇文章写出来不是为了推荐自托管服务的，这个话题可能也不是由我来讨论了。

之所以想到放弃，缘于前两天看到了一个 V 站的帖子，然后看到了最低19美元一年的 Migadu，学生开工单享受半价优惠。这家从文档到服务都非常实诚，只按照使用量（收发量、邮件存储）计费，（几乎）不限制域名和邮箱数量，每个邮箱有自己的收发件箱，ToS里全都是“只有best effort服务，但是真的best effort"，域名数和使用空间等限制都是软限制，稍微超出一点儿也不打紧，甚至还在文档里diss了友商所谓的“加密”³。当然最重要的原因是我可以省下每年60美元的服务器，一年就能省下350块钱。

但Micro套餐内仅有5GB空间和每天20封邮件，虽然都是软限制，可以偶尔超过，但考虑到我博客的评论系统有回复自动发邮件提醒，万一评论区两个人对起线来……如果是Migadu，我可能只能选择90美元一年的Mini套餐了。这两个之间差价有点儿大，于是看向了Fastmail。Standard套餐50美元一年，还是能省下70多块钱；空间和发信量的痛点也都解决了，虽然是统一的信箱但是也不影响使用，也能使用不同的地址进行收发。如果不想用自己的域名了，还可以再添加一些Fastmail提供的后缀结尾的邮箱（甚至有 @fastmail.cn）。

如果抛开套餐用量比较两家的服务，我认为它们走了两条不同的路：Migadu为本就是tech-savvy的用户服务，将尽可能多的技术细节提供给用户，只做最纯粹的电子邮件，推荐的也是开源邮件客户端和开源迁移方案；而Fastmail更多的面向普通用户，可以直接导入Gmail等服务，针对每个IMAP客户端有应用专用密码，甚至连域名都可以在它那里买。

整理一个表格，对比Fastmail和Migadu套餐的区别：

套餐	Fastmail	Migadu
年付价格 (USD)	50	19 (Micro) / 90 (Mini)
每天收/发限制	/	200/20 (Micro) / 1000/100 (Mini)
存储空间	30GB	5GB (Micro) / 30GB (Mini)
多地址/域名处理	单个域名；可添加邮箱地址，共用一个信箱	无限邮箱，无限域名，各有单独信箱
其他服务	日历、联系人、记事本	日历、联系人（beta）

如果Migadu能够以50美元一年以下的价格提供一个存储&发信多一点儿的套餐，我决策时一定会选择它；然而没有，所以还是投奔了Fastmail。

如果只有中国手机号，Fastmail的注册会卡在手机验证码的一关，开工单就能解决；如果使用其他人的referral，也需要在工单里说明，客服会手动加上首年10% 的优惠。Fastmail和Migadu两者应该是都不支持支付宝和微信的，但支持PayPal（中国版支持不明）和Stripe（理论上支持银联卡）。

Fastmail有一个迁移向导，输入原来的IMAP服务器、账户名称和密码，就能把信箱搬过来了，功能倒是很像IMAPSync，只不过在它的服务器上运行。效果不错，迁移也很快，非常舒服。

不得不说，国内的访问体验确实有点慢，远比不上国内的服务 ~~（废话）~~ ，但相对之前自建的速度其实快多了。说真的，只要不被墙就很好了。

尴尬的是，迁过来的消息总共只用了0.1GB；又翻了翻一直以来用的QQ邮箱和Gmail，分别用了146MB和420MB，这么看的话5GB的空间还是长期够用的。又转念一想，我博客这个鸟不拉屎的地方也基本没人发评论，每天20封其实也够用了。意识到这个问题后，再次反思放弃自托管的五个理由，发现只有最后一个最真切。别说了，几年前那股折腾劲儿又上来了。

最后，如果你也想找个邮件托管商，我推荐Migadu的Micro套餐，完全够用；如果你订了Fastmail，可以使用我的 referral 注册，你享受首年10% 优惠，我也可以每月得到约0.5美元的余额。

Armbian + R2S 番外篇：透明代理

Sun, 17 Sep 2023 20:46:00 +0800

透明代理这个东西说起来很容易理解，就是设备感知不到有的流量被代理，却有开了代理的效果。这个东西对于学习境外内容的体验提升很大，因为部分应用并不遵循系统代理设置，或设置很麻烦。避免将代理配置文件存放在电脑上，也可以防止电脑上的应用窃取代理信息。

透明代理本身在中文互联网已经是聊烂了的话题，但使用Nftables实现的透明代理很少，在主路由上实现透明代理的更少。我的网络拓扑大概是：外部网络 - R2S - 无线AP - 其他设备。本文将基于这个拓扑，实现在R2S上使用Nftables实现透明代理。

这个东西作为上篇文章的一个小节显得有点喧宾夺主了，所以就单独写一篇文章吧。

前置知识

只需要基础的计网知识，以及初步了解Nftables（起码能看懂规则）。

另外丢掉那张老旧的（you know what）Netfilter数据包流向图吧，由于Nftables的链是可以自由添加、自定义优先级的，现在它应该是这样¹：

Netfilter 数据包流向图

思路

要达到的效果是这样的：

DHCP服务器将默认DNS服务器指向本机的Telescope DNS，由其负责解析²，直连DoH
局域网内通信不经过代理工具，包括DHCP等特殊服务
其他来自局域网内的TCP/UDP流量都经过代理工具，由代理工具分流
不代理路由本身流量，暂时没需求

也就是说流量会经过Nftables和代理工具两次分流。对于较为固定、不高于三层的分流规则，交给Nftables效率更高；而对于按站点分流之类的规则，则交给代理工具，更灵活。

对于第一条，局域网内机器发送数据包的路径为：

局域网内客户端发出DNS请求
Nftables prerouting 对目的为局域网内的请求进行直连，不代理
Telescope DNS接收到请求（此处设未缓存）
Telescope DNS向上游发出请求，不带任何meta mark
Nftables postrouting 进行NAT
远程DNS服务器收到请求，返回结果
Nftables prerouting 对来自局域网外的请求直连
Telescope DNS收到上游回复
Telescope DNS将结果返回给客户端
Nftables postrouting 进行NAT
客户端收到回复

对内网的包：

局域网内客户端发出请求
Nftables prerouting 对目的为局域网内的请求进行直连，不代理
进入 forward 链，转发给目标机器或/同时被本机处理

对分流决定代理的正常TCP/UDP流量：

局域网内客户端发出请求
Nftables prerouting 对于来自局域网、目标为外网的请求，进行 tproxy
代理工具接收并封装请求，并发送到代理服务器，带有meta mark 2
Nftables postrouting 进行NAT
代理服务器处理代理请求，返回结果
Nftables prerouting 对于来自外网的请求，不代理（直接发往代理工具）
代理工具接收并解封装请求，将结果返回给客户端
Nftables postrouting 进行NAT
客户端收到回复

对于决定不分流的正常TCP/UDP流量，其实也和上面相似，只不过代理工具直接将请求发往目标服务器，目标服务器也直接把结果返回给代理工具。

实现

类似于 Xray TProxy 透明代理之类的本机透明代理方案很多，一般也适用于旁路由。核心的规则其实就两条，也就是在 prerouting 的链上加入（tproxy 仅支持 prerouting）：

perl

1
2

ip protocol tcp tproxy to 127.0.0.1:12345 meta mark set 1
ip protocol udp tproxy to 127.0.0.1:12345 meta mark set 1

然而就以上面链接中这篇教程的配置为例，它包含如下三行规则，通过跳过目的为本地IP的代理，同时避免了远程服务器发回的流量被重新代理和局域网内主机间流量被代理的问题：

perl

1
2
3

ip daddr $RESERVED_IP return
ip daddr 192.168.0.0/16 tcp dport != 53 return
ip daddr 192.168.0.0/16 udp dport != 53 return

第二个问题很好理解。而这些规则能解决第一个问题，主要原因在于主路由已经做好了NAT，看起来已经是从远程主机IP发往代理客户端主机IP的流量了，也就是有了目的IP在上述范围内的特征。同样的方法却不能套到主路由上，因为NAT一般在 postrouting 阶段去做，而 tproxy 一般在 prerouting 阶段进行³。此时，网络层的目的IP仍然是本机的外网IP，而非192.168.0.1这样的局域网IP。

然而，出于某些原因，我们并不能在 postrouting 阶段等待NAT完成后再更改目的IP⁴，也就是说这个阶段已经不能把数据包拐到代理上面了。考虑到 tproxy 的作用阶段，实际上在 prerouting 中同时进行Nftables阶段的分流和 tproxy 更为合适。相应的，为了识别远程服务器发回流量，我们要添加一条规则，也就是源IP不在内网IP段中，则不代理。

另外不管是上面的教程还是Linux kernel文档³，都指出 tproxy 应搭配自定义IP route使用，以让透明代理的包正确地传输到本地。在进行透明代理的同时为数据包附上meta mark 1，这样就可以被以下两条命令定义的路由规则捕获，然后被传输到本地：

bash

1
2

ip rule add fwmark 1 lookup 100 # 对于带标记 1 的包，使用编号为 100 的路由表（100 没有什么特殊含义）
ip route add local 0.0.0.0/0 dev lo table 100 # 对于路由表 100，经过 lo 设备发送到 0.0.0.0

实验表明去掉这两条规则后，无法正确进行透明代理。由于 tproxy 并不会修改数据包本身的内容，所以我猜测该数据包可能会按照默认策略路由，不会进入本地回环为代理工具所接收。

接下来就该配置代理软件了。我个人建议使用Xray-core，需要添加入站：

json

{
  "inbounds": [
    {
      "tag": "all-in",
      "port": 12345,
      "listen": "127.0.0.1",
      "protocol": "dokodemo-door",
      "settings": {
        "network": "tcp,udp",
        "followRedirect": true
      },
      "sniffing": {
        "enabled": true,
        "destOverride": [
          "http",
          "tls"
        ]
      },
      "streamSettings": {
        "sockopt": {
          "tproxy": "tproxy"
        }
      }
    },
  ]
}

并且建议为每个出站都设定meta mark不为1：

json

{
  "outbounds": [
    {
      "streamSettings":{        
        "sockopt": {
          "mark": 2
        },
      },
    },
  ]
}

在添加了上面的规则后，发现连不上新设备了，查找DHCP服务器的日志也并未发现端倪。发现由于DHCP的Discover目标为广播IP，并未被排除代理，所以被代理工具截留。我使用的workaround为添加一条规则，对目标为udp/67端口的数据包不代理，DHCP恢复正常。

宿舍的网络竟然有外界可以直接访问的公网IP（震惊），所以个人还加了 filter 表，用于防止外界白嫖代理。这个看一下下面的配置文件就明白，我不多讲。

配置

如果你希望使用此配置文件，请根据你路由器的接口分配、网段分配、代理工具等情况进行修改。另外也不要忘了添加 ip 路由规则。

perl

#!/usr/sbin/nft -f

flush ruleset

define RESERVED_IP = {
    192.168.0.0/24,
    0.0.0.0/8,
}

define WANLINK = lan0
define LANLINK = eth0

table ip nat {
    chain postrouting {
        type nat hook postrouting priority 100; policy accept;
        oifname $WANLINK masquerade
    }
}

table ip filter {
    chain input {
        type filter hook input priority 0; policy accept;
        # only accept local/LAN traffic to tproxy
        ip saddr != $RESERVED_IP tcp dport 12345 drop
    }
}

table ip xray {
    chain prerouting {
        type filter hook prerouting priority mangle; policy accept;
        # source not from LAN (e.g. server reply), don't proxy
        ip saddr != $RESERVED_IP return
        # dest loopback or local traffic, don't proxy
        ip daddr $RESERVED_IP return
        # allow dhcp traffic (daddr may be 255.255.255.0)
        udp dport 67 return
        # tproxy traffic
        ip protocol {tcp,udp} tproxy to 127.0.0.1:12345 meta mark set 1
    }
}

IPv6

本节参考⁵

IPv6透明代理的实现与上面相似，甚至可以不用建新表，而是修改 xray 表即可。

IPv6对应的路径设置如下：

bash

1
2

ip -6 rule add fwmark 1 table 106
ip -6 route add local ::/0 dev lo table 106

这里我直接将修改后的 xray 表列在下面：

perl

table inet xray {
    chain prerouting {
        type filter hook prerouting priority filter; policy accept;
        ip daddr { 127.0.0.0/8, 224.0.0.0/4, 255.255.255.255 } return
        ip6 daddr 2408::/16 return
        meta l4proto tcp ip daddr 192.168.0.0/16 return
        ip daddr 192.168.0.0/16 udp dport != 53 return
        ip6 daddr { ::1, fe80::/10 } return
        meta l4proto tcp ip6 daddr fd00::/8 return
        ip6 daddr fd00::/8 udp dport != 53 return

        # tailscale
        udp sport 41641 return
        udp dport 41641 return
        udp dport 3478 return
        udp sport 3478 return

        meta mark 2 return
        meta l4proto { tcp, udp } meta mark set 1 tproxy ip to 127.0.0.1:12345 accept
        meta l4proto { tcp, udp } meta mark set 1 tproxy ip6 to [::1]:12345 accept
    }

    chain divert {
        type filter hook prerouting priority mangle; policy accept;
        meta l4proto tcp socket transparent 1 meta mark set 1 accept
    }
}

如果你的代理工具只监听了IPv4地址，那么需要同时监听IPv6 [::1]:12345。

优化

Nftables数据包追踪

在编写Nftables配置的时候，经常可能有疑问，这个数据包到哪里去了。可以使用 nft monitor trace 监视特定数据包的流向和规则判定过程，详细使用方法见 ⁶。

米家设备无法连网

如果开启透明代理的情况下，发现米家设备无法联网（或者无法绑定到App），而关闭透明代理又恢复，那么可能是因为米家设备需要连接域名 mijia cloud（是的你没看错，中间一个空格），代理工具嗅探到了这个域名并尝试解析以分流，但其无法正常处理⁷，于是走默认。可以通过查看代理工具的日志来验证这个情况，Xray-core和Clash都可能会有这个问题。

解决方法是跳过这个域名的嗅探分流，如Xray-core加上这一段：

json

{
  "inbounds": [
    {
      "sniffing": {
        "domainsExcluded": [
          "mijia cloud"
        ]
      }
    }
  ]
}

干出这个事的小米工程师真该拉出去祭天。

境内流量完全直连

上述的配置会令境内外流量均经过代理工具，最直接的问题就是访问速度变慢。但可能也有些其他后果。

曾遇到一个非常玄学的问题，如国服原神“连接超时”，国服星穹铁道错误“1001_1”等。即使设置了正确的分流规则和DNS解析，也可能无法登录。抓包发现有许多和米哈游的TCP连接被reset掉，暂时不知道根本原因。

个人的解决办法是使用Nftables进行国内IP分流，具体可见这篇文章。实测使用该措施后，由于不需要回到用户态过代理软件，日常上网也会快一点。不过若依赖于特定代理软件的附加功能，如Xray-core的Full Cone NAT，则对于绕过的流量，也会一并失去这些功能。

此处附一个适用于IPv4和IPv6的转换脚本，将APNIC的数据转换为nftables格式，并输出到标准输出：

python

import re

# Function to calculate subnet mask from number of IPs
def get_cidr_from_size(size):
    import math
    return 32 - int(math.log2(size))

def parse_ip_ranges(file_path):
    v4_list = []
    v6_list = []

    # Regular expressions for extracting IPv4 and IPv6 ranges
    ipv4_regex = r'apnic\|CN\|ipv4\|([0-9]+\.[0-9]+\.[0-9]+\.[0-9]+)\|(\d+)\|'
    ipv6_regex = r'apnic\|CN\|ipv6\|([0-9a-fA-F:]+)\|(\d+)\|'

    with open(file_path, 'r') as file:
        for line in file:
            # Check for IPv4
            match_v4 = re.search(ipv4_regex, line)
            if match_v4:
                ip = match_v4.group(1)
                size = int(match_v4.group(2))
                # Calculate CIDR from the size
                cidr = get_cidr_from_size(size)
                subnet = f"{ip}/{cidr},"
                v4_list.append(subnet)

            # Check for IPv6
            match_v6 = re.search(ipv6_regex, line)
            if match_v6:
                ip = match_v6.group(1)
                prefix_length = int(match_v6.group(2))
                # Construct the subnet
                subnet = f"{ip}/{prefix_length},"
                v6_list.append(subnet)

    return v4_list, v6_list


def generate_nftables_rule(file_path):
    v4_list, v6_list = parse_ip_ranges(file_path)

    # Format the output in nftables style
    v4_rules = "define chnroute_list_v4 = {\n" + "\n    ".join(v4_list) + "\n}"
    v6_rules = "define chnroute_list_v6 = {\n" + "\n    ".join(v6_list) + "\n}"

    return v4_rules, v6_rules


if __name__ == "__main__":
    file_path = 'delegated-apnic-latest'  # Replace with your actual file path

    v4_rules, v6_rules = generate_nftables_rule(file_path)

    # Print the results
    print(v4_rules)
    print(v6_rules)

https://thermalcircle.de/doku.php?id=blog:linux:nftables_packet_flow_netfilter_hooks_detail 另外这也是一篇极佳的Nftables入门文章，推荐阅读。 ↩︎
或许有人担心这会影响Xray-core的域名分流，但其域名分流是依靠sniffing头中的SNI实现的，即使Xray-core得不到解析前的域名，也不会受到影响。 ↩︎
https://www.kernel.org/doc/Documentation/networking/tproxy.txt ↩︎ ↩︎
https://serverfault.com/a/125913 ↩︎
https://xtls.github.io/document/level-2/tproxy_ipv4_and_ipv6.html ↩︎
https://wiki.nftables.org/wiki-nftables/index.php/Ruleset_debug/tracing ↩︎
https://github.com/XTLS/Xray-core/issues/293 ↩︎

启用 AMD P-State EPP 调频驱动

Tue, 12 Sep 2023 23:05:00 +0800

Arch Linux的Linux 6.5内核终于在前几天进入了 core 软件库，其中一个重要的特性就是默认启用了P-State EPP (Active) 调频驱动¹。调频驱动不同于调速器，前者与特定的CPU有关；而后者与电源方案有关，如 powersave 就是一直运行在最低频率。

amd-pstate 是AMD CPU性能调频驱动，它在Linux内核中的现代AMD APU和CPU系列上引入了新的CPU频率控制机制。新机制基于协作处理器性能控制 (CPPC)，它提供比传统ACPI硬件P-state更精细的频率管理。当前的AMD CPU/APU平台使用ACPI P-State驱动程序来管理CPU频率和时钟，仅在3个P-state下进行切换。CPPC取代了ACPI P-state控制，并为Linux内核提供了灵活、低延迟的接口，以直接向硬件传达性能提示。

amd_pstate CPPC有3种操作模式：自主（active）模式、非自主（passive）模式和引导自主（guided）模式。通过不同的内核参数可以选择active/passive/guided模式。

在自主模式下，平台会忽略所需的性能级别请求，并仅考虑设置为最小、最大和能量性能首选项寄存器的值。

在非自主模式下，平台直接通过所需性能寄存器从操作系统获取所需的性能水平。

在引导自主模式下，平台根据当前工作负载并在操作系统通过最小和最大性能寄存器设置的限制内自主设置操作性能级别。

amd_pstate=active 是低级固件控制模式，由amd_pstate_epp驱动程序实现，并在命令行中将amd_pstate=active传递给内核。在此模式下，如果软件想要偏向CPPC固件的性能 (0x0) 或能效 (0xff)，amd_pstate_epp驱动程序会向硬件提供提示。然后CPPC功耗算法将计算运行时工作负载，并根据电源和热量、核心电压和其他一些硬件条件调整实时核心频率。²

简而言之，相比默认的 acpi_cpufreq，P-State能够让CPU从操作系统处直接获得性能需求hint，并进行更细粒度的频率控制。P-State EPP（active模式）响应更快，并能自定义hint，达到类似于调速器的效果。

P-State EPP支持Zen 2或更新的AMD CPU。本人使用的是联想R7000 2020，AMD Ryzen 7 4800H，也算是喝到了一大口汤吧。

启用CPPC

P-State EPP依赖于CPPC（Collaborative Processor Performance Control），所以首先要在BIOS中启用CPPC。请自查BIOS内是否有此选项，如果没有，需要使用 Smokeless_UMAF 访问BIOS中的隐藏选项，步骤如下。本文作者与插件作者不对任何损坏负责。

下载仓库中的 UMAF_BETA.zip，解压到一个空的FAT32格式的U盘中
用此U盘引导启动
进入Device Manager - AMD CBS - NBIO - SMU³

在这里应该就可以看到CPPC选项。即使已经显示Auto或者Default，也需要手动Enable。设置完成后按保存重启即可。

启用P-State EPP

可以直接运行上图中的 cpupower 工具来查看当前的调频驱动。如果你和我一样已经在运行Linux 6.5，那么可能什么都不用做了。

不同内核版本对P-State EPP的支持如下：

6.5起，默认启用P-State EPP¹
6.4起，支持Guided Autonomous模式⁴
6.3起，支持EPP，但默认不启用⁵⁶
5.17起，支持P-State

如果在使用6.3或6.4，开启EPP的方法就是添加内核参数，amd_pstate=[active|passive|guided]。关于如何修改内核参数，可参见 ArchWiki: kernel parameters。

其他优化

可以使用 auto-epp 来自动传递EPP hint，以在离电情况下功耗更低，或接入电源时性能释放更强。

在启用EPP的情况下，也可以直接将调速器设为 powersave，完全靠调频驱动进行调频⁷。

体验

在启用P-State EPP调频驱动后，CPU各内核的频率能够在适当的时候（如浏览网页等场景）降低至400 MHz（见下图的频率范围），在有需求时也能快速拉起频率。相比于之前最低频率仅能低至1.3GHz，此举有望能大幅降低低负载的package功耗。

启用 P-State EPP 后的效果

在进行简单的浏览网页和编写代码时，使用 balance_performance hint，流畅度完全没有问题。笔记本离电时使用 power hint，提频更消极，跑不满笔记本的高刷新率，但功耗更低；使用独显混合模式，续航大约4小时，遥遥领先于Windows，比同样60Wh电池的MBP13 2020（Intel）更强；若关闭独显，可能对续航有更大的提升。

此外也有网友称出现了重启的问题，反正我没遇到。

Armbian，更适合 R2S 软路由的系统

Fri, 14 Jul 2023 14:54:00 +0800

OpenWrt的困境

人们安装OpenWrt，是因为他们觉得它比路由器或者嵌入式设备的原厂固件更好用。

——《使用 OpenWrt 的理由》

不错，作为一个路由器系统来说OpenWrt确实实现了相对官方固件更好的可玩性。实际用久了自然会发现OpenWrt作为一个Linux来说是非常难用的，这点突出体现在其包管理上。官方软件源各种残缺，第三方软件源也充斥着野包，让我想起了用CentOS的时候。开发者倾向于为传统大发行版打包，相比较而言极少看到过opkg。OpenWrt官方甚至不建议升级软件包 ¹，因为包管理器并没有能力升级OpenWrt本身……这对Tailscale和Xray-core等需要经常更新的软件来说很致命。

整个OpenWrt给人的印象也是能省则省，因为它需要照顾到大量低性能的设备，甚至低至8MB Flash、32M RAM的设备；前文提到的包管理器区别是因为opkg不支持ABI兼容性监测；对于普通的Linux发行版也有诸多其他不同。而对于R2S这种1GB RAM的设备来说，倒没必要这么节省。更何况即使在Armbian上，日常占用RAM也仅有300MB，这里面还有100MB以上是Xray-core的缓存。

我并没有说OpenWrt不适合路由器使用，它的大部分配置都能点几下就完成设置，也有更多的中文资料，还有很多开箱即用的网络优化，在社区活跃开发者的帮助下，它十分适合路由器使用。但若是想要跳出插件开发者设定的笼子，尝试稍高级一点的玩法，OpenWrt就会显得各种别扭。而Armbian基于Debian或者Ubuntu，都是许多Linux用户再熟悉不过的发行版，因此使用Armbian不是找罪受，反而能够利用已有的其他Linux使用习惯和资料，是一个偷懒的选择。

因此，本文希望为读者提供另一种软路由的思路，让R2S兼有传统主路由的功能，又有更熟悉的Linux发行版体验。

我的网络拓扑大概如下（无线路由器连接的各个设备仅为示意）。R2S作为主路由使用，~~Redmi AC2100~~ （已升级为小米AX3000）作为AP，不存在旁路由。

网络拓扑

安装Armbian

安装Armbian的第一步就像OpenWrt一样，从官方网站下载对应的img（本文使用基于Ubuntu的Jammy），然后用你的工具烧录进SD卡。将R2S接入电源，指示灯应该闪烁。

初始设置需要将其WAN或LAN口接到另一台 已经启用DHCP 的路由器上，想办法找到其IP地址（比如进管理员后台），然后使用SSH登录，初始用户名和密码分别为 root 和 1234。注意其此时不能作为一个开箱即用的路由器，也就是说不能直接接入电脑。

登入后有一个初始引导，跟着做就行了，没什么好说的。然后这就是一个标准的Linux系统了，基本可以直接遵循其他Linux的操作方法。但国内许多用户会到手换源，由于Armbian是基于其他发行版做的，所以换源不完全一样。其软件源有两个位置，均需要更改：

/etc/apt/sources.list 与你安装的版本所基于的发行版有关，如Armbian Jammy基于Ubuntu Jammy，就换对应的源（如清华源，注意Ubuntu使用Ports源）；
/etc/apt/sources.list.d/armbian.list 是Armbian专属软件源，也要换（仍然如清华源）。

配置路由器功能

OpenWRT说白了也是个Linux，作为一个路由器所需要的功能也有许多方案可以通过后期手动安装实现。

顺着走到这一步，执行 ip l，一台R2S的显示应该类似于下面这样：

plaintext

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DEFAULT group default qlen 1000
    link/ether aa:aa:aa:aa:aa:aa brd ff:ff:ff:ff:ff:ff
4: lan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether aa:aa:aa:aa:aa:aa brd ff:ff:ff:ff:ff:ff

此处我把外部网络（相对，如上层路由器）插到了 lan0 上，局域网设备则均连接至 eth0，相当于许多OpenWRT包所做的反转WAN和LAN口。如无特别说明，后面的操作均按照这个来。

R2S的LAN是USB 3.0转接的网卡，而WAN是PCIe网卡。进行高速传输时，USB造成的中断会大量消耗性能，所以对于内网流量，将其扔给性能更高的WAN口。R2S在小包较多时速度明显下降，也是基于同样的原因。

DNS

DNS用于将主机名解析为IP地址。由于传统DNS查询是明文的，可以被中间人任意截留修改，部分运营商会进行DNS污染，以达到加广告或封锁境外网站的目的。因此，使用DoH（DHS-over-HTTPS）和DoT（DNS-over-TLS），并对国内和国外域名进行分流，就有其意义。

下文介绍了几种DNS转发器的的配置方案。其中，EasyMosdns自带了较完善的方案，而TelescopeDNS的配置文件较为简明，都能有效对抗DNS污染。

TelescopeDNS

此处使用 Telescope DNS 负责监听53端口，为局域网内设备进行解析，并根据条件将其发送至不同的DNS服务器。

虽然我有透明代理的需求，但是本着解耦的原则（说白了就是怕Xray-core挂掉全都上不了网），还是由单独的DNS转发器处理局域网查询吧。

Armbian默认使用systemd-resolved解析DNS并占用25端口，由于其仅能监听本机请求而不能接受局域网内其他机器的请求[^7]，需要将其禁用。此外需要将 /etc/resolv.conf 指向127.0.0.1以将本机的DNS查询转发至Telescope DNS。

以下是我的配置文件，读者可以参考。

toml

listen = "192.168.0.1:53"
disable_qtypes = ["AAAA"] # 禁用 IPv6 解析

[cache]
size = 4096

[hosts] # 为 DoH 域名指定 IP 地址，防止回环解析（指解析所必需的 DoH 域名本身也需要解析）
"doh.pub" = "1.12.12.12"
"cloudflare-dns.com" = "1.0.0.1"

[groups]
  [groups.clean] # 境内域名
  doh = ["https://doh.pub/dns-query"] # 腾讯 DNSPod DoH
  dns = ["114.114.114.114"]
  concurrent = true
  no_cookie = true # DNSPod 可能需要
  redirector = "oversea_ip2dirty" # 按照下方同名 redirector 设置重定向

  [groups.dirty] # 境外域名
  dns = ["208.67.222.222:5353", "176.103.130.130:5353"]
  doh = ["https://cloudflare-dns.com/dns-query"] # Cloudflare DoH
  gfwlist_file = "/etc/ts-dns/gfwlist.txt"

[redirectors]
  [redirectors.oversea_ip2dirty]
  # 解析后如发现ip地址不匹配cnip，则重定向到dirty组解析
  type = "mismatch_cidr"
  rules_file = "/etc/ts-dns/cnip.txt"
  dst_group = "dirty"

为了让本机的DNS解析通过本机的服务器，需要更改默认的DNS解析器。

EasyMosdns

Mosdns以强大的功能而闻名，但对于不想花时间配置的人来说，使用别人配好的方案也能十分舒适，比如 EasyMosdns。

因为它和Mosdns都没有被大部分发行版打包，所以在Armbian上，需要先手动安装对应版本的Mosdns，然后将上述repo内的文件丢进对应目录。至于Systemd单元等文件，可以参见 AUR。

默认监听53端口，可以在 /etc/mosdns/config.yaml 中设置。

dnsmasq 整合

确实dnsmasq可以当DNS转发器啊，但因为它对DNS污染抗性比较差，所以我肯定不会单独用它的。不过可以把它套娃，在本机上做两层转发。

如果你希望做两层转发，那么需要将嵌套的转发器监听端口改一下，比如5353，将这个地址改为dnsmasq的上游DNS，并且把dnsmasq的cache size设为0（否则第一次查询大概率失败）；如果你希望把dnsmasq的DNS禁掉，那么这三个设置都不用动，然后给dnsmasq加个 -p0 启动参数就可以了。

DHCP

DHCP用于为局域网内的设备分配各自的IP地址，同时也会传递网关、默认DNS等信息。在我的网络拓扑中，由软路由充当DHCP服务器，其他设备则仅需自带的DHCP客户端。

一般来说Linux的网络连接由systemd-networkd或NetworkManager之类的东西管理（包含DHCP客户端），而在基于Ubuntu的系统上有个好东西叫做Netplan，用于在前述两者等一系列工具之上再构建一层抽象，以求简化其配置。

该机型Armbian的Netplan配置文件位于 /etc/netplan/armbian-default.yaml。未经修改的文件类似于：

yaml

1
2
3

network:
  version: 2
  renderer: NetworkManager

要将软路由作为DHCP服务器，需要先将对应接口的DHCP客户端关掉（路由器一般当然不能从局域网其他主机取得IP地址了），然后再为其单独安排一个IP地址。再次提醒，我计划把局域网设备插在 eth0：

yaml

network:
  version: 2
  renderer: NetworkManager
  ethernets:
    eth0:
      dhcp4: false # 这个 false 是关掉 DHCP 客户端
      addresses: [192.168.0.1/24] # 网段自定，后面对应修改

保存后不要忘了使用 sudo netplan try 测试配置文件是不是写对了，没问题的话就确认。

至于DHCP服务器，我起初选择了 coredhcp。其并不支持SLAAC宣告，故对IPv6环境并不友好；而dnsmasq虽然看起来麻烦，但实际上只需要动几个配置项就行了，而且对IPv6比较友好。

照例是配置文件：

yaml

server4:
    listen:
        - "%eth0" # 只监听 eth0 接口的请求
    plugins:
        - lease_time: 3600s
        - server_id: 192.168.0.1 # 填路由器 IP 就行
        - dns: 192.168.0.1 # 重要，设置为路由器 IP 以指向路由器上的 DNS
        - router: 192.168.0.1 # 网关，主路由兼具代理功能，所以这里也是路由器 IP
        - netmask: 255.255.255.0 # 子网掩码
        - range: /etc/coredhcp/leases.txt 192.168.0.2 192.168.0.254 12h # 分配地址文件，起始地址，结束地址，租约时间

NAT

NAT对局域网内IP和端口号二元组与外网IP和端口号二元组之间建立联系，并进行转换。此处使用的工具是 nftables。依托其强大的规则体系，我们可以自由选择转发暴露的端口，以及内外能访问的服务等。

nftables 官方文档 ² 给了我们一个很好的基础配置，我也知道其他高级用途也需要依托 nftables，此处按下不表。但要做到NAT，只需要用一张 nat 表的 masquerade 规则。

perl

#!/usr/sbin/nft -f

flush ruleset

define WANLINK = lan0

table ip nat {
        chain  prerouting {
                type nat hook prerouting priority -100;
        }
        chain postrouting {
                type nat hook postrouting priority 100; policy accept;
                oif $WANLINK masquerade
        }
}

要暂时应用Nftables规则，可以使用 sudo nft -f <filename>，永久应用则需要将其保存到 /etc/nftables.conf，并设置权限755。

启用IP转发

只有启用代理转发，流量才能进入Netfilter的 forward 链，从而不经本地用户程序而向外转发。

在 /etc/sysctl.d/ 下新建一个文件，名字随意（如 98-ip-forwarding.conf），内容为：

plaintext

1
2

net.ipv4.ip_forward=1
net.ipv6.conf.all.forwarding=1

然后运行 sudo sysctl -p 使其生效。这样，软路由就有了将不属于它的包转发出去的能力。

PPPoE

安装 pppoeconf，然后运行它就可以了。它的底层是 pppd，所以修改配置也需要到 /etc/ppp/ 里面修改。

使用PPPoE上网后，会生成一个 ppp0 虚拟网卡，它充当了WAN口的作用；使用原来的WAN接口是无法直接联网的。使用透明代理等需要指定接口的应用时请务必注意。

进阶应用

按照上面的步骤配置完毕后，如无意外，软路由本身和接入其的设备应该已经可以上网了。然后是一些相比OpenWrt，Armbian没有out-of-box支持的。

透明代理

请阅读 Armbian + R2S 番外篇：透明代理一文。

另外，如果使用Tailscale，实测透明代理可能会与Tailscale规则冲突（实测23/8/26有此现象），从而导致上不了网的严重问题，所幸1.48.0开始Tailscale增加了Nftables支持，将其启用似乎可以解决这个问题。在 /etc/default/tailscaled中加入 TS_DEBUG_FIREWALL_MODE=nftables 即可³。

基本防火墙

将这些规则加入之前的 nftables 配置，可以对内外网进行基本的隔离。修改自 ⁴。

perl

table inet filter {
        chain inbound {
                type filter hook input priority 0; policy drop;
                ct state vmap { established : accept, related : accept, invalid : accept } counter
                ip protocol icmp icmp type { destination-unreachable, echo-reply, echo-request, source-quench, time-exceeded } limit rate 5/second accept
                tcp dport 22 accept
                iifname vmap { lo: accept, $WANLINK : jump inbound_world, $LANLINK : jump inbound_private }
        }
        chain inbound_world {
                ip saddr { $RESERVED_IP } drop
        }
        chain inbound_private {
                ip protocol . th dport vmap { tcp . 22 : accept, udp . 53 : accept, tcp . 53 : accept, udp . 67 : accept }
        }
        chain forward {
                type filter hook forward priority 0; policy accept;
        }
}

UPnP / NAT-PMP

UPnP和NAT-PMP本质上是类似的东西，类似于一个自动的路由器端口映射。可以使用 MiniUPnPd 来实现。

Ubuntu和Debian已经打包了 miniupnpd 和 miniupnpd-nftables 两个包，安装时会自动进入向导，分别填入内网接口（eth0）和外网接口（lan0），并选择启用即可。

Full Cone NAT

Nftables的NAT行为 masquerade 是Symmetric NAT。打游戏的应该会需要Full Cone NAT，可以参考一下这个实现。需要编译对应的 libnftnl、nftables 和 nft，以及内核模块。

如果你使用Xray-core透明代理，那么它已经帮你用神奇的方式实现了Full Cone NAT⁵。但在实现透明代理时，需要将所有流量转发至Xray-core进行分流，以防不同分流规则下NAT行为出现不同。

另外还可以使用 einat-ebpf，使用时需禁用上述NAT Nftables规则中的 MASQUERADE 链，实测Armbian内核支持该程序eBPF所需的内核选项，性能良好，较为易用，无需重新编译内核模块或使用第三方代理工具。

MSS Clamping

我不只一次见网友说自己搭的软路由访问某些网站非常慢，而换回硬路由就正常。这是因为多数家用路由器默认对IPv4下的TCP开启了MSS (maximum segment size) Clamping。

《开启 IPv6 后网速变得很慢？可能是 PMTU 黑洞的问题》

简而言之就是家用硬路由会自动帮你设置MSS，而软路由不会，造成被路径上丢包只能重传。进行MSS Clamping后，终于能跑满300M宽带了。

在Nftables中添加以下内容：

perl

table inet filter {
    chain forward {
        type filter hook forward priority 0; policy accept;
        tcp flags syn tcp option maxseg size set rt mtu
    }
}

IPv6

以网上资料的细碎程度，IPv6其实也是一个进阶应用；但是感觉对自己来说，即使没有全局梯也不能没有IPv6，所以就挺拧巴的，这也是我把它放在最后的原因。如果你对IPv6没有那么熟悉，我强烈建议你展开下面的内容看点更拧巴的现象和我的理解，防止配完黑人问号。

常用的路由器 IPv6 部署方案解析

IPv6的情况与IPv4不同，路由器较少使用DHCPv6来为局域网设备分配IP地址（而且支持也像屎一样 [^13]），更常用的叫做无状态地址自动配置（SLAAC，StateLess Address Auto Configuration），一般来说路由器会选择LAN上前缀的一个 /64地址块，向局域网内进行宣告，然后各个主机通过某种方式，自己在这个 /64里选择一个地址（并非一个设备直接分走一个 /64，所以运营商只给 /60而不是 /56并没有什么问题；感谢 V2EX @dalaoshu 的纠正）。因为一个 /64实在是太巨大了，所以一般也不会冲突。

诶，看起来拧巴的事情来了：本人使用的长沙联通宽带，光猫已改为桥接路由器拨号；而对于PPPoE，协议本身会给路由器 ppp0 指定一个 /64的地址 [^14]。不知细心的你是否发现了，我们没说过 ppp0 在委托的那个子网里面——事实上也确实不在。当执行 ip -6 addr 时，就会得到以下看起来十分抽象实际上却又合理的输出（节选）：

bash

$ ip -6 addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 2408:aaaa:450:3650:4c43:81ff:fe4d:9cac/60 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::4c43:81ff:fe4d:9cac/64 scope link
       valid_lft forever preferred_lft forever
6: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 state UNKNOWN qlen 3
    inet6 2408:bbbb:451:50b6:7a88:efdb:db94:4b77/64 scope global temporary dynamic
       valid_lft 259001sec preferred_lft 85804sec
    inet6 2408:bbbb:451:50b6:4e43:81ff:fe4d:9cac/64 scope global dynamic mngtmpaddr
       valid_lft 259001sec preferred_lft 172601sec
    inet6 fe80::4e43:81ff:fe4d:9cac peer fe80::16eb:8ff:feb2:b27d/128 scope link
       valid_lft forever preferred_lft forever

说它抽象吧，是因为在我的直觉里，似乎IPv6不会分配私有IP，所以大家都是平等的设备，也理所应当属于一个子网；说它合理吧，是既然IP转发启用了，那么路由器就可以将其送达该有的目的地，路径也并不需要跟着网段走。事实上，WAN口的 /64是通过PPPoE的SLAAC获得的，这与LAN口的DHCPv6-PD获得的前缀来源不同，所以才会出现两个地址不在同一网段的情况。

其实类比IPv4也是很好理解的：运营商给一个普通路由器的WAN口分配了一个公网IP；同时路由器通过DHCP将内网的私有地址分配给各个主机，LAN口也获得了一个该网段下的私有地址。IPv6情况其实差不多，只是上面的私有地址段变成了通过DHCPv6-PD获得的公网地址段，通过某个公网地址能够直接路由到特定的主机，无需经过NAT而已；子网内的DHCPv4也变成了SLAAC，不过结果上没区别，都是主机获得了自己的IP。

评论区有人提到了IPv6的一些奇怪情况；此外关于PD和SLAAC，也可以多阅读这篇文章作为参考。

好的，逼叨完了，结果很明了了：我们需要配置的有

一个能进行DHCPv6-PD的客户端，
一个能进行SLAAC宣告的程序，和
让路由器本身获得IPv6。

第一个事好说，用得很广泛的是 wide-dhcpv6-client$^包$。安装后编辑 /etc/wide-dhcpv6/dhcp6c.conf。以下给出一个示例，它从运营商请求一个非临时的前缀，然后将这个前缀委托给 eth0，让 eth0 获得一个 /64地址。

perl

interface ppp0 { # 通过 ppp0 进行 DHCPv6
    send ia-pd 0; # 发送 Prefix Delegation 消息
    send ia-na 0; # 请求非临时地址（non-temporary address）
    script "/etc/wide-dhcpv6/dhcp6c-script";
};

id-assoc pd 0 { # PD 0 的配置
    prefix-interface eth0 { # 将前缀委托给 eth0
        sla-id 0; # SLA ID，即网段编号
        sla-len 0; # SLA 长度，即用掉整个 PD
    };
};

id-assoc na 0 {}; # NA 0 的配置，留空就行

这是一个很基础的配置，如果想整更多花活，建议读 manual。

重启一下服务，如果看到 eth0（或自己定义的LAN）上有了一个大于 /64的非私有IP，那么就是成功了，不出意外的话route也会为你配好；否则可以自行使用 dhcp6c -Df -c /path/to/conf <interface> 进行debug。

现在连上设备并不能用SLAAC，因为我们还没有配置路由宣告。如果你已经使用 dnsmasq 作为DHCP服务器，那么宣告非常简单：仅需要在配置文件中加类似下面这一行。

plaintext

`1`	`dhcp-range=::1000,::1fff,constructor:eth0,slaac,ra-names`

我来详细解释一下：

即使向运营商申请了非临时前缀，也可能变，所以前缀不能写死，要自动从接口获取
constructor:eth0 指的是分配给 eth0 的IP段
::1000,::1fff 指的是所有IPv6地址，当然不能给IPv4做SLAAC不是嘛
slaac 指的是选择外部分配的前缀，而非 fe80 开头的内网IP段
ra-names 代表进行SLAAC宣告，不进行DHCPv6，并将主机添加到DNS

第三个事情看起来很玄学。在远古的Linux内核中，当开启IPv6 forwarding的时候，即使 net.ipv6.conf.all.accept_ra 不为0，其也会自作主张地停止进行SLAAC，导致路由器WAN（eth0）接口无法获取IPv6地址；而在不那么老的内核上，将其设为2，就可以同时开启IPv6 forwarding和进行SLAAC⁶。

这样，局域网下的设备就可以通过IPv6上网了，没有邪道DHCPv6。

同步 iCloud （云上贵州）日历

Mon, 10 Jul 2023 21:52:50 +0800

作为一个Android + Apple + Windows用户，寻找跨平台数据同步方案一直是一大难题，日历也不例外。纵观全局，日历同步服务倒也不少，比如Google、Outlook和iCloud等，但Google国内根本连不上，Outlook托微软的尿性也不稳定，我这次又懒得自己部署一个，此时iCloud就成为了一个好选择。

iCloud使用的也是通用的CalDAV协议，然而iCloud并没有一个开放的CalDAV配置指引，甚至连服务器都不给。手动配置也不难，要配置一个CalDAV客户端，一般需要服务器地址、用户名和密码。用户名就是你的iCloud邮箱地址，即xxx@icloud.com。

macOS 上并不支持授权 CalDAV

客户端支持情况

有的日历客户端需要手动配置服务器地址，但有的不用。但除了iOS和macOS系统自带的日历客户端，其他大部分都需要获取App专用密码。

以下是我使用过的几个客户端，以及它们对手动配置服务器地址的需求情况：

iOS、macOS等苹果第一方客户端：当然不需要
MIUI日历：不需要（不含HyperOS）
Windows日历：不需要
Thunderbird：需要*

* 可以使用TbSync插件同步国际版iCloud，但不适用于云上贵州

如下图，需要手动填入“位置”的即为需要获取服务器地址。

Thunderbird 创建新日历

获取密码

众所周知，仅凭Apple ID和其密码当然过不了二步验证，验证码都没地方输。好在可以创建App专用密码。

在 Apple ID 管理页面的下方找到 “App专用密码”，创建一个，然后暂存下来，这个密码之后不会再出现。每个专用密码都等效，所以建议对每个应用使用不同的专用密码。

App 专用密码

获取服务器地址

方法一：分析请求

苹果没有给服务器地址，但网络上有现成的获取方法，如这个。但是已经过去了五年，在云上贵州的环境中又有点不同。长话短说，就是把icloud.com换成icloud.com.cn，然后自己摸索起来应该也不难。

仿照那个教程的获取方法，iCloud云上贵州的CalDAV服务器地址格式为：

text

`1`	`https://<server-id>-caldav.icloud.com.cn/<user-id>/calendars/<calendar-id>/`

其中：

<server-id> 是数字和字母混合的字符串，我的是4位；
<user-id> 是一串数字，我的是11位；
<calendar-id> 是一个用 - 分隔的、全部大写的UUID。

需要注意，一个CalDAV地址对应一个日历，如果有多个日历必须在下面的步骤中重复操作。

现在打开你的iCloud网页版，打开浏览器的开发者选项-网络，然后在日历页面双击任意一个事件，进入详情。

在开发者选项中过滤“XHR”请求，然后找到传输这个事件详细信息的GET请求，例如下图：

找到这个请求URL，它大概是以下格式：

text

https://<server-id>-calendarws.icloud.com.cn/ca/eventdetail/<calendar-id>/<event-id>?clientBuildNumber=<some-random-text>&clientId=<some-random-text>&clientMasteringNumber=<some-random-text>&clientVersion=<some-random-text>&dsid=<user-id>&lang=<some-random-text>&requestID=<some-random-text>&usertz=<some-random-text>

或许你得到的request param会有所不同，但只要能找出你链接中的对应位置，提取出上面提到的三个ID就行了。如果发现提取不出来，请评论。

将上面三个ID填入上面的CalDAV服务器地址中，就可以得到你的CalDAV服务器地址了。

方法二：MIUI日历

更新：HyperOS的日历已经去掉iCloud登录功能。

如果你恰好有一台小米手机，那么可以直接在MIUI日历中添加iCloud日历，MIUI会自动获取服务器地址，也能正确处理云上贵州链接。在日历详细信息页面，你就可以提取出对应的日历地址。

MIUI 日历可以正确提取链接

方法三：工具提取

可以试一下以下的工具（未经验证）：

midnightmonster/icloud-calendar-urls（需要macOS环境）
muhlba91/icloud-caldav-urls

鉴定网络热门野鸡大学（以长沙天工网络学院为例）

Wed, 28 Jun 2023 22:32:53 +0800

先回答一个最重要的问题：长沙天工网络学院是野鸡大学吗？是。

本来我应该接触不到这种破事的，但它蹭上湖大了，那正义的我不能坐视不管（狗头）。

本文所有内容均来自公开信息；所有提到的学校官网页面均通过 Archive.org 保存，任何链接失效都可以查看存档版本。

大专毕业证书，可考全日制本科，6000块钱底薪，还有985合作办学，谁听了不迷糊啊。还不用高考，一遍笔试一遍面试就行了，简直天上掉馅饼好吧。大部分人看到这个应该会毫不犹豫点击退出，但考虑到能考出这个分的人（ ~~还有我这种闲着没事的~~）真有可能点进去，这里就来扒一扒它。

真的有湖南大学的资源吗？

不好说，或者说以其宣传来看，没有。

首先看师资。我可以负责任地说，在教师风采页面上，没有一个熟悉的湖大信息院教授名字。

唯一一位明确标注“曾任职湖南大学”的员工，在网络上搜索并没有出现其任何资料，至于他担任了什么职位，我们不得而知，但这种情况一般不是核心职工。何况这照片看起来就像是卖保险的……

然后看校园。从官网联系我们页面找到地址，光看地图，你说它是在湖大北校吧，党校后街似乎是条开放道路；你说它不是吧，它确实挨着。

同在一栋楼上的还有什么呢？

湖南商务进修学院，一所“民办非学历教育高等学校”，拿不到学历，还曾经违规办学被通报批评；
长沙春秋进修大学，这个性质一样，但有前科的，更牛逼：早在财经学院合并到湖大前，这所学校就冒充财院招生。

这个地理位置，跟曾冒充招生的学校设在一栋楼，很难不怀疑其动机。

还有这个校园简介。尼玛，这是湖大南校区的图，远处那个是真信息院，跟你们隔一个岳麓山，莫挨老子。

课程靠谱吗？

以大学（专科）的标准，不靠谱。

根据教育部普通高等学校高职专科专业简介和《教育部关于印发〈职业教育专业目录（2021年）〉的通知》，没有其专业方向中所谓的“Java软件开发”“大数据人工智能开发”“全链路UI设计”“新媒体运营”“大数据网络安全与运维”专业。

是大学吗？

打开学校官网人才招聘网页，阅读2023年2月17日的公告概要：

天工网络软件学院是湖南硅谷创新技术有限公司旗下IT产业学院。主管单位为长沙市高新区人社局，湖南硅谷IT成立于2011年，11年专注与国内高校本科、专科IT人才培养，与省内一流高校建立紧密校..

不由教育部门主管的“IT产业学院”，自爆了，不是大学。

再去天眼查，查查这个公司，发现它就是个开培训班的，和我们的猜测基本吻合。入职甚至不需要本科学历。教这批学生的人，还真不一定有学生水平高。

职工只有“课程助理”，令人深思。

就业是否有保障？

一个连就业信息页面都要蹭省里新闻的机构，你觉得有什么就业可言吗。既然招生简章有那么多签约的优秀校友，还在招生简章里言之凿凿地有签约保证，那么不应该一点合作企业的信息都没有呀？

至于为什么这么多找到工作的，那当然，开个培训班要是学生都找不到工作那就别开了。

毕业证哪来的？是否可以考本科？

上面这些问题都回答完了，不会真有人硬着头皮想去吧。没有正经大学老师，没有正经大学专业，没有正经大学校园，这种机构开出来的毕业证，你敢要吗？

西安，西安

Thu, 15 Jun 2023 21:43:40 +0800

“西安是一座古朴的大都市……”

此话真不假，古朴和大都市都无需质疑。有的城市没啥历史文化却非要硬凹，有的城市空有文化资源却利用不起来；这两类都多到没必要举例子，但西安是国内少数称得上既有文化又会开发的城市之一，甚至一些刻意的开发都不会让人觉得突兀。

12月中旬正值淡季，人比较少，酒店和景点也便宜，景点参观得也自由多了。强烈推荐各位淡季来。

暂时无图，后期补

景点

许多景点都有持本科学生证门票半价政策，幸亏我本科毕业前出来玩了这一趟。

兵马俑 & 秦始皇陵

它竟然不在西安城区啊，在临潼。不过只要走2小时，来回甚至比西电新校区还方便（笑）。

感觉兵马俑离我心目中的那个有差距，去之前以为规模巨大，然而之后发现最大的只有一号坑。即便如此也十分震撼了。人少，观看体验极佳。

秦始皇陵……真正的陵寝并不开放游览，只是坐观光车转一圈看看陪葬品罢了。倒是有个铜车马博物馆，做得挺用心的，可惜一进去就没信号。

西安城墙

全国知名的古城也没几个，帝都的城墙早拆了变成二环路了，全国旅游比西安强的城墙没西安完整，比西安城墙还完整的……怕不是没有。从这个意义上，它就是独一无二的。而且这城墙还能上去，在永宁门城楼上望钟楼，还是个挺知名的机位。即使不拍照，散散步骑骑车也是非常好的。

大雁塔 & 长安不夜城

这烂怂大雁塔¹确实没啥好看的，可能是去得有点晚的原因，大慈恩寺转了一圈没找到门进去，大雁塔也只能拍个远景，从这个意义上体验还不如小雁塔。

长安灯具不夜城的灯具确实挺震撼的，想必旅游旺季熙熙攘攘的样子那确实很壮观。附近的银泰等商场依靠本地客流还能维持一些，但卖小吃的地摊就有点儿惨了。规模巨大的太平洋影院也在疫情影响下鬼了，令人唏嘘。

银泰百货的小蔚来展厅竟然有EP9，真是意外之喜了。

全街最丑风格最不搭的建筑：华为体验，没有之一。实在不会copy苹果就不要copy。

碑林博物馆

藏品过于重量级了，信息量很大，是一个值得沉下心逛一逛的地方。

曲江池

鹅、鸭和鸟都不少，喜欢的话值得看。

小雁塔 & 西安博物院

小雁塔虽然也在维护，但起码能凑近了看，园子还是蛮有味道的。

西安博物院是临时想看省博但约不上的平替（这么个淡季竟然全约满了），事实证明这个平替除了规模略小之外，做得也不错。

交通

西安的司机虽然还是有点儿西北的狂野，但起码比长沙文明多了，乱窜的情况很少。可惜道路规划实在拖后腿，真能堵。

公交做得挺不错的，许多需要倒地铁的地方都有公交直达，此时相比地铁，我更有意愿坐公交。市区还有大量的公交车道，极大地保障了公交车的速度。

机场修在隔壁地级市我是没想到的（at成都），不过还好14号线很快，100km/h不成问题。即使离市区多了10km，仍然比长沙市区去机场要方便。

地铁对游客来说还算四通八达，但通不通和顺不顺是两回事儿。钟楼站1和2号线的换乘简直是灾难。

但还有一种西安特色交通方式：黑车。不同于其他城市的黑车，西安的黑车真是多到一种令人发指的地步，去了几乎每个景点都有被拦下来问要不要坐车。

饮食

西安被称为碳水之都是有原因的。

许多地方都有地方特色打出了名堂的饮料，长沙有茶颜，青岛有~~崂山白花蛇草水~~青啤，在西安就是冰峰。五天炫了三瓶玻璃瓶冰峰，令人欣慰的是跟易拉罐装的差不太多。

说到茶颜了，那不得不说山寨茶颜西安分颜——茶话弄。顶上的奶沫端出来就是一大坨，越来越多，喝完奶茶还剩半杯奶沫不化，太恐怖了，真不敢再喝。

biang biang面，臊子面，肉夹馍，凉皮，自然不用再说，在这方面西安就是绝对的权威。大概连吃一个月的面也不会腻掉。

https://www.bilibili.com/video/av22006345/ ↩︎

写一个 WordPress 评论转换工具

Thu, 15 Jun 2023 21:43:40 +0800

在把博客迁出WordPress的时候难免要一块儿把评论迁出来。怪了，全网常用的评论系统，Valine，Twikoo，怎么就没有WordPress导入呢？另一个评论系统，Artalk，倒是有个Artransfer工具，通过WordPress全部的导出文件解析评论，导出Artrans格式。但sadly, it simply didn’t work. 它也并不能很好地处理重定向。

那总不能把评论一个一个输到Twikoo里面吧，那未免太不优雅了。何况即使五分钟手工能干成的事情，也要花两个小时去自动化完成（狗头）。

导出方法

WordPress备份文件的组织形式我觉得挺麻的，幸好还有另一种获取评论的方式，即REST API。该接口虽然是公开的，但是在进行认证之后，可以读取到评论的全部信息，包括发送者邮箱、IP和user-agent等。而在以前使用的全部资料导出方式中，根本没办法导出UA。

读出来某条评论大概是这个样子：

json

    {
        "id": 123, // 评论 ID
        "post": 2345, // 文章 ID，即代表 /archives/2345 的那篇文章
        "parent": 0, // 父评论 ID，0 代表没有父评论
        "author": 0, // 作者 ID，0 代表未登录用户
        "author_name": "AuthorName", // 作者名
        "author_email": "author@example.com", // 作者邮箱
        "author_url": "https:\/\/example.com", // 作者网站
        "author_ip": "1.1.1.1", // 发送 IP
        "author_user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:89.0) Gecko/20100101 Firefox/89.0", // 发送者浏览器 UA
        "date": "2000-00-00T00:00:00", // 本地和 GMT 发送时间
        "date_gmt": "2000-00-00T00:00:00",
        "content": {
            "rendered": "content", // HTML 评论内容
            "raw": "" // 纯文字评论内容
        },
        "link": "", // 评论链接，指向对应文章的对应评论
        "status": "approved", // 是否过审
        "type": "comment", // 好像只有 comment
        "author_avatar_urls": { // 三种尺寸的头像链接。很难想象 WordPress 会直接预存三种链接，虽然都是 Gravatar 的
            "24": "",
            "48": "",
            "96": ""
        },
        "meta": [], // 用于存放一些额外的 metadata
        "_links": { // 相关 API endpoint
            "self": [
                {
                    "href": "https:\/\/example.com\/wp-json\/wp\/v2\/comments\/123"
                }
            ],
            "collection": [
                {
                    "href": "https:\/\/example.com\/wp-json\/wp\/v2\/comments"
                }
            ],
            "children": [
                {
                    "embeddable": true,
                    "href": "https:\/\/example.com\/wp-json\/wp\/v2\/comments?parent=123"
                }
            ]
        }
    },

详细解析见 WordPress REST API Handbook。

要获取完整内容，需要在WordPress后台-用户-个人资料中生成一个“应用程序密码”（或使用其他认证方式），然后在请求中加入对应的认证信息，并将 context 设为 edit。比如使用cURL：

bash

`1`	`curl --user "username:password" -X GET https://example.com/wp-json/wp/v2/comments?context=edit`

输出格式

作为一个Twikoo用户，为什么不输出为Twikoo JSON呢，是因为不想用吗？

想啊，很想啊，但只有Artalk的 Artran 有现成的格式定义，而且数据定义也相对简单，起码比逆向Twikoo JSON简单得多。

json

{
    "id": "123", 
    "rid": "233", 
    "content": "Hello Artalk", 
    "ua": "Artalk/6.6", 
    "ip": "233.233.233.233",
    "created_at": "2021-10-28 20:50:15 +0800 +0800", 
    "updated_at": "2021-10-28 20:50:15 +0800 +0800", 
    "is_collapsed": "false", 
    "is_pending": "false", 
    "vote_up": "666", 
    "vote_down": "0", 
    "nick": "qwqcode", 
    "email": "qwqcode@github.com", 
    "link": "https://qwqaq.com", 
    "password": "", 
    "badge_name": "管理员", 
    "badge_color": "#FF716D", 
    "page_key": "https://artalk.js.org/guide/transfer.html", 
    "page_title": "数据迁移", 
    "page_admin_only": "false", 
    "site_name": "Artalk",
    "site_urls": "http://localhost:3000/demo/,https://artalk.js.org"
}

文档示例，简单易懂，对吧？唯一需要解释的就是 rid，即父评论ID。在不存在父评论的时候，可以直接设为0。

实际上只含有下面的这些字段的话，也能用：id、rid、content、ua、ip、is_collapsed、created_at、updated_at、nick、email、link、page_key。在不太复杂的情况下，page_key 可以仅写作 /guide/transfer.html。

链接重定向

如果迁移前后的评论系统附属网站permalink的格式不一样，那么评论的 page_key 也要做相应的修改。个人迁移前后的博客站点暂时是同时开放的，而迁移后Hugo也可以方便地设立重定向页面。

举个例子吧，假设原页面为old.example.com/archives/2345，对应新页面为new.example.com/post/new-post，则Hugo设立alias之后会在new.example.com/archives/2345生成一个重定向页面，内容为：

html

<!DOCTYPE html>
<html lang="zh-cn">
  <head>
    <title>https://new.example.com/post/new-post/</title>
    <link rel="canonical" href="https://new.example.com/post/new-post/">
    <meta name="robots" content="noindex">
    <meta charset="utf-8">
    <meta http-equiv="refresh" content="0; url=https://new.example.com/post/new-post/">
  </head>
</html>

假设我们在之前的WordPress REST API中已经获取到旧WordPress网站中某条评论的 post 字段值为2345，那么只需要访问new.example.com/archives/2345，运用正则表达式提取refresh URL即可提取到新的 page_key，即 /post/new-post。

代码实现

见 GitHub repo。

后记

写完程序之后，我变成了一个Artalk用户。

逃离 WordPress

Sat, 10 Jun 2023 20:08:14 +0800

迁移博客或许是每一个Blogger的宿命。

动机

如你所见，这是一个Hugo站点。而在这个域名中，曾经运行着WordPress。

你或许知道我的博客本来是WordPress的，而WordPress虽然大而全，但作为一个博客来说确实有点太重了。这倒不是“我可以不用你不能没有”的问题，而是不用就要关掉的问题，留着就会有各种漏洞，虽然网站没啥真正有价值的东西，但怪烦的。基于维护性和可移植性的优势，我早就想用静态网站生成器代替WP了（这个在两周年的文章中有提到），但苦于重定向做起来怪麻烦的，便一直拖着没有做。

那为什么下定决心了呢？还是因为WordPress的可维护性。当初我将网站从Vultr迁到腾讯云，一部分也是因为承载的网站越来越多，天天干爆内存，然后每次 mariadbd 就会当炮灰被杀掉。腾讯云轻量香港确实爽，2G RAM随便造……了一年。就在前两天，这个现象又出现了。很快，服务器的硬盘也不知道怎么回事就满了（不是swap的锅），这次死的又是 mariadbd。

之所以迁移起来困难，一直没干，一方面是因为目录结构不同，需要逐个手动重定向；而另一方面是WordPress上还有很多条评论，我不想丢掉。和这两者比起来，把文章扒下来转成Markdown反而成了相对容易的工作。

托管、生成器和主题

虽然静态网站可以直接用Caddy去serve，但本着 ~~“用自己的不如用别人的”~~ 尽量减少故障的原则，选择一般人使用的第三方托管方案，而这意味着又要经历常见的服务商选择问题了。老实说，Netlify、Vercel和GitHub Pages用户群都挺多，体验也都不错；微软的新服务Azure Static Web App也还可以，甚至有香港数据中心，但它是依托GitHub Actions的，build起来有点慢，最重要的原因是Azure那令人发指的控制台。看起来Netlify在中国大陆的速度比Vercel快一点，又没有GH Pages被墙得那么多，试了试几种网络环境发现没有什么访问问题，所以就选了Netlify。

没有选择Azure还有一个重要的原因。头抬起，这是Azure的控制面板，可看到为粗糙的边缘，请坐和放宽：

至于网站生成器的选择，老实说，考虑到我稀烂的前端水平，我的选择有点跟着主题走，顶多对主题进行一点魔改。做出这个决定时，有hexo-theme-icarus和hugo-theme-stack两个选择摆在我面前，最终因为我对Go的喜爱（以及前者带有jQuery）而选择了后者。

加载首页只需要200KB出头，相比之前去掉图片还有2MB，很香啊！还能细粒度控制KaTeX加载，这么久终于体会到了抠流量的快感（误）。

Hugo的主题有一个好，就是不用学PHP就可以魔改，我 ~~大概可能也许~~ 有能力按照自己的需求改一改吧。

当前进度：

选择托管平台：Netlify
选择生成器：Hugo
选择主题：hugo-theme-stack
魔改主题

文章

Markdown导出WordPress文章这件事，有人做过解决方案了，导出的Markdown有front matter，看起来交给Hugo基本没有什么阻碍。但是实际操作起来坑还是很多的，光是把文章导出再导入，就花了我三天时间 ~~（一边摸鱼）~~。

其一是图片的存储必须要整个移走，之前WordPress历经了三种存储图片方式，分别是WordPress自带图片存储、Cloudreve + OneDrive存储，最后是阿里云对象存储。自己铲屎山的时候才意识到，这三种方式实质上混杂在文章之中，而且由于WordPress问题，内部图片也是通过指向网站的链接管理的，也就是说WordPress存储的图片还要分IP+端口、域名+端口和域名访问。一不做二不休，干脆直接换个存储桶吧，路径正好也跟页面的slug对应，折腾起来也会容易很多。顺便推荐一波Cyberduck，比阿里的OSS Browser好用多了。

其二是各种复杂样式问题，包括但不限于分栏、复杂表格等，不可否认用WordPress的可视化编辑器确实很方便，但如文字颜色等属性是基于自定义CSS class实现的，

当前进度：

导出WordPress文章
导入文章
设定分类
设定标签
i18n
友链

评论是博客重要的内容，我的计划是写个小工具，从WordPress的REST API导出评论，然后导入第三方评论工具。这个事情会在所有文章都搬过来之后去做。

基于上面好线路服务器资源紧缺的现状，我挑选评论系统时将资源消耗放在了较重要的地位，也就自然盯上了无Node.js后端的Commento和Remark42。然而前者需要PostgreSQL，后者文档不太明白不说，还需要额外的注册登录才能评论，这与之前填入基本信息即可评论的初衷不符，于是转向了Twikoo。其使用Docker自行搭建的情况下，仅占用了70MB内存，文章详情页也仅需多加载150KB左右，算下来还是比较节省资源的。

果然，用的人多是有原因的……

当然也不是用的人少就一定不好用，毕竟我最后还是反复横跳到了Artalk。可选的多站点支持，50KB额外开销，Go后端，完善的文档……该给的确实都给了。折腾这么多，现在应该能安心了吧。

如果你对我做的转换工具感兴趣，可以查看下方链接。

当前进度：

部署新评论系统：Artalk
写转换工具：https://github.com/cyp0633/WP2Artran
导出，再导入

重定向

把评论都搬过来后，WordPress站点基本就没有值得留意的东西了，这个时候就可以把WordPress的permalink重定向到Hugo来了。

最后发现RSS倒是做了重定向，但是某些固定页面没做，就直接把DNS改了。之前那些页面就寄掉了。还好筛选过，也没有太大损失。

当前进度：

设置文章重定向：Hugo aliases已经做好了
设置RSS、友链等固定链接重定向

后记熟悉Netlify的读者应该知道，同一个站点可以分配多个domain。在上面的一切都做完之后，我将新博客放在了 <next.cyp0633.icu>，让它跟旧博客共存了一段时间。再确认运行正常之后，我将 <cyp0633.icu> 也指向了新博客，就此宣告了旧站的结局。然而Google搜索认为 <next.cyp0633.icu> 是规范网址，换言之不再索引 <cyp0633.icu>。可以在 netlify.toml 中添加如下的重定向规则，以直接将 <next.cyp0633.icu> 重定向到 <cyp0633.icu>：

toml

[[redirects]]
  from = "https://next.cyp0633.icu/*"
  to = "https://cyp0633.icu/:splat"
  status = 301
  force = true

用 Rust uutils 替换 Windows PowerShell 内置 cmdlet

Sat, 20 May 2023 00:00:00 +0000

更新：适用于Linux的Windows子系统（WSL2）已更新 2.0 版本，一定程度上解决了之前占用端口等弊病。再加上之前更新的许多实用功能，个人已经使用WSL2的zsh基本代替了Windows下的PowerShell，故本文的意义不再像以前那么大。

uutils是一个用Rust重写的GNU Coreutils，也就是Linux上的 cp、mv、touch 等程序的一个实现。虽然在Windows的PowerShell中执行这些命令也能得到类似于Linux的结果，但实际上是一个PowerShell内置cmdlet的alias，在某些情况下的兼容性并不是那么好。本文探索一种用uutils的命令替代PowerShell内置cmdlet的方法，以让Windows的命令行体验更加Unix化（虽然还是没那么Unix就是了）。

uutils/coreutils

安装uutils

可以使用预编译的二进制安装，也可以使用源代码编译安装。由于后面添加自动补全还需要源代码，所以我选择后者。

如果不需要shell自动补全，那么可以直接从上面GitHub仓库的releases下载对应的压缩包（coreutils-version-x86_64-pc-windows-{msvc|gnu}.zip），将解压后的coreutils.exe放在任何一个PATH下的目录下即可。至于如何添加PATH，此处不再赘述，很容易搜到。

默认编译或下载到的是multi-call binary，即调用方式为 coreutils.exe <command>，本文也按照这个情况书写。也可以编译为分离的二进制文件，具体请参考上面的GitHub Readme。

编译源代码需要先安装 Rust 工具链，未安装的请移步教程。

在你认为合适的位置，使用以下命令将其安装到Rust存放二进制文件的地方：

powershell

1
2
3

git clone https://github.com/uutils/coreutils
cd coreutils
cargo install --path . --features windows

编译出的二进制文件一般在 %HomePath%/.cargo/bin里面，应该是默认添加到PATH的。安装完成后可以开一个新的PowerShell，运行 coreutils 以验证是否安装完成。

为PowerShell添加自动补全

自动补全的主要用处大概是输入参数的时候能够按tab补全，如 ls --di 按下tab可以补全为 ls --directory。

有点类似于Bash的. bashrc初始化脚本，PowerShell的自定义设置由profile管理。用户profile的路径内置于PowerShell的 $profile环境变量，可以直接在PowerShell中运行 notepad $profile 来编辑。

但自动补全文本量很大，可以将每个命令的补全各自写入一个文件，然后在profile中引用。对于把补全文件放在同一个文件夹内的情况，可以在profile中添加以下内容：

powershell

$completionsPath = "C:\path\to\completions"  # Replace with the path to your completions directory

# Get all completion script files in the specified directory
$completionScripts = Get-ChildItem -Path $completionsPath -Filter "*.ps1" -File

# Load each completion script
foreach ($script in $completionScripts) {
    . $script.FullName
}

这样就可以加载C:\path\to\completions（自己定义）里的补全预设了。

然后回到coreutils的源代码文件夹中，用PowerShell执行以下命令：

powershell

1
2
3

foreach($cmd in'b2sum','b3sum','base32','base64','basename','basenc','cat','cksum','comm','cp','csplit','cut','date','dd','df','dir','dircolors','dirname','du','echo','env','expand','expr','factor','false','fmt','fold','hashsum','head','join','link','ln','ls','md5sum','mkdir','mktemp','more','mv','nl','numfmt','od','paste','pr','printenv','printf','ptx','pwd','readlink','realpath','relpath','rm','rmdir','seq','sha1sum','sha224sum','sha256sum','sha3-224sum','sha3-256sum','sha3-384sum','sha3-512sum','sha384sum','sha3sum','sha512sum','shake128sum','shake256sum','shred','shuf','sleep','sort','split','sum','tac','tail','tee','test','touch','tr','true','truncate','tsort','unexpand','uniq','unlink','vdir','wc','yes') {
    cargo run completion $cmd powershell > "C:\path\to\completions\$cmd.ps1"
}

这样就可以把自动补全输出到你自定义的补全预设目录（还是别忘了替换路径）。

取代PowerShell自带cmdlet alias

现在每次都要先输一个 coreutils 命令才能调用，既不方便也没法用自动补全，干脆直接把命令映射过来。

直接 Set-Alias 是不成功的，因为PowerShell自带alias。在profile中再添加以下内容：

powershell

foreach($cmd in'b2sum','b3sum','base32','base64','basename','basenc','cat','cksum','comm','cp','csplit','cut','date','dd','df','dir','dircolors','dirname','du','echo','env','expand','expr','factor','false','fmt','fold','hashsum','head','join','link','ln','ls','md5sum','mkdir','mktemp','more','mv','nl','numfmt','od','paste','pr','printenv','printf','ptx','pwd','readlink','realpath','relpath','rm','rmdir','seq','sha1sum','sha224sum','sha256sum','sha3-224sum','sha3-256sum','sha3-384sum','sha3-512sum','sha384sum','sha3sum','sha512sum','shake128sum','shake256sum','shred','shuf','split','sum','tac','tail','test','touch','tr','true','truncate','tsort','unexpand','uniq','unlink','vdir','wc','yes') {
    Remove-Alias $cmd -ErrorAction SilentlyContinue
    Set-Item function:$cmd -Value {coreutils $cmd $args}.GetNewClosure()
}

（修改自这个 Gist）

因为 sleep、tee 和 sort 不允许修改，所以只好删掉了。

如果没有意外的话，再打开一个PowerShell，就可以使用新的uutils了。

参考资料：

HNU 软件编译原理实验 4（Go 实现）

Sat, 06 May 2023 00:00:00 +0000

编译器、解释器、虚拟机，或许只在杨氏编译原理里面是同义词。

代码已上传至GitHub，为防止篇幅过长，没有内置所有代码，仅对个人认为值得讲述的地方进行说明，可以对比阅读。

cyp0633/compiler-lab

TINY语言编译器的部分到了中间代码生成部分就结束了，生成的是下面这样的TM虚拟机机器码，剩下的部分一直到运行，都由虚拟机来完成。

text

  0:     LD  6,0(0) 
  1:     ST  0,0(0) 
  2:     IN  0,0,0 
  3:     ST  0,0(5) 
  4:    LDC  0,0(0) 
  5:     ST  0,0(6)

在实验三中完成了词法分析器，实验四包括了语义分析和中间代码生成，至于指导书没提的语法分析，当然只能自己加上了。

TINY编译器的C代码中，大致流程为：词法分析（scan.c）-> 语法分析（parse.c）-> 语义分析（analyze.c）-> 中间代码生成（code.c、cgen.c）。另外还有符号表管理（symtab.c）。本文的之后部分中，将其改写 + 优化为Go代码进行解释。

该编译器不含有独立的错误处理模块，错误处理在各模块中解决。

语法分析

该编译器的语法分析输出是一个语法树，树节点用以下的结构描述。

type treeNode struct {
    child   [3]*treeNode // 子节点
    sibling *treeNode    // 兄弟节点
    lineNo  int          // 行号
    op      tokenType    // 操作符
    val     int          // 值
    attr    string       // 属性
    stmt    stmtKind     // 语句类型
    expr    exprKind     // 表达式类型
    typ     exprType     // 表达式数值类型
    node    nodeKind     // 节点类型
}

命名很乱是吧，我也是这么想的。

节点类型 nodeKind 分为表达式节点和语句节点，前者对应一个表达式（如1+1），后者对应一整个或一行语句（如 write i）
语句类型 stmtKind 分为赋值、循环、条件分支、读、写几种
表达式类型 exprKind 是当前表达式节点的类型，分为运算符、常量、标识符变量
表达式值类型 exprType 分为整型表达式、布尔表达式和没有值的表达式（真的存在吗）

由于Go孱弱的类型系统，既没有泛型多态有没有类似Rust的Trait（巧了，C也没有），所以每个节点存储完整的信息，不会因表达式或是语句节点而使用不同的结构体。

对于一个 treeNode，同一个节点的某个child的sibling和其他child并不是并列的关系。对于某个语句节点，sibling指向的是下一个语句，例如：

text

1
2

fact := fact * x; 
x := x - 1;

第二句作为一个赋值语句节点，就是第一句的sibling。而child可以视为语句中的 “槽位”，如：

text

1
2
3

if 0 < x then
    fact := 1;
end

上面的 if-then-end 语句有两个槽，分别存放 0 < x 表达式节点和 fact := 1 语句节点，也就是这个条件分支语句节点的两个child。因为槽最多的就是 if-then-else-end，有三个，所以child最大也仅需要三个。

Parse 函数用来启动语法分析，返回语法树根节点。它调用 stmtSequence() 函数，期望其返回时分析完整个源代码，如果最后识别到的token不为eof，则文件中含有错误。

func Parse() (t *treeNode) {
    currToken= GetToken()
    t = stmtSequence()
    if currToken != eofToken {
        syntaxError("Code ends before file\n")
    }
    return
}

stmtSequence 函数用来识别位于同一作用域（如同一if-clause，也就是Python中同一缩进等级）的一串语句，当找到eof、end、else 和 until 这几个代表结束的词语时结束。

t为nil这一个分支我也没看懂为什么在这里。

func stmtSequence() *treeNode {
    t := statement()
    p := t
    for currToken != eofToken && currToken != endToken && currToken != elseToken && currToken != untilToken {
        match(semicolonToken)
        q := statement()
        if q != nil {
            if t == nil {
                p = q
                t = p
            } else {
                p.sibling = q
                p = q
            }
        }
    }
    return t
}

statement 函数好理解，一次识别单个语句，根据识别出的token类型进入不同的识别函数。代码略。

各种不同语句的识别函数分为if、repeat、赋值语句、read和write，此处只以 ifStatement 为例，其他看看代码应该就明白了。if节点的三个域分别存放expression（条件检验表达式）、then-statement（符合执行的语句串）和else-statement（不符合执行的语句串）。

// if 语句的匹配
//
// if <expression> then <stmtSequence> [else <stmtSequence>] end
func ifStatement() *treeNode {
    t := newStatementNode(ifStmt)
    match(ifToken)
    t.child[0] = expression()
    match(thenToken)
    t.child[1] = stmtSequence()
    if currToken == elseToken {
        match(elseToken)
        t.child[2] = stmtSequence()
    }
    match(endToken)
    return t
}

语句的匹配在上面就结束了，而表达式的匹配需要考虑优先级问题。在这个编译器程序中，分为三个优先级：< 和 = 优先级最低，+ 和 - 优先级次之，* 和 / 更高，数字、标识符和括号则设为同一最高优先级。在形式化语言表示中，使用不同的符号（Expression、Term、Factor）区分不同的计算优先级。产生式有：

$Expression \to simpleExpression\ |\ simpleExpression \lt simpleExpression\ |\ simpleExpression \lt \simpleExpression$

$simpleExpression \to Term\ |\ Term+Term\ |\ Term-Term$

$Term \to Factor\ |\ Factor \times Factor\ |\ Factor / Factor$

仅贴出Expression的代码，其他类似。

// 表达式的匹配：处理 < 和 = 运算符
// 优先级最低
func expression() *treeNode {
    t := simpleExpression()
    if currToken == ltToken || currToken == eqToken {
        p := newExpressionNode(opExpr)
        p.child[0] = t
        p.op = currToken
        t = p
        match(currToken)
        t.child[1] = simpleExpression()
    }
    return t
}

数字和标识符的处理（factor）如下：

// 表达式的匹配：处理数字、标识符和括号
func factor() (t *treeNode) {
    switch currToken {
    case numToken:
        t = newExpressionNode(constExpr)
        if currToken == numToken {
            var err error
            t.val, err = strconv.Atoi(tokenString)
            if err != nil {
                syntaxError("unexpected token -> %s"+ currToken.String())
            }
            match(numToken)
        }
    case idToken:
        t = newExpressionNode(idExpr)
        if currToken == idToken {
            t.attr = tokenString
        }
        match(idToken)
    case lparenToken:
        match(lparenToken)
        t = expression()
        match(rparenToken)
    default:
        syntaxError("unexpected token -> %s"+ currToken.String())
        currToken = GetToken()
    }
    return
}

符号表

原来的C版本编译器说白了也就是个自定义哈希函数的哈希表，是一个数组实现，封装了查找和插入，所以既然Go本身就有无序的字典 map，当然就用上了。

符号表项的键为符号名，值为内存地址（从0起）和出现的行数列表 的引用。

var symtab map[string]*struct {
    refLines []int // 引用行号列表
    memLoc   int   // 内存位置
} = make(map[string]*struct {
    refLines []int
    memLoc   int
})

在原来的符号表实现中，新符号的地址是由词法分析器决定的（而且是简单的递增），此处由符号表模块自行管理。

查找很简单，判断是否存在罢了。

// 查找符号表
// 返回内存位置和是否找到
func lookupSymtab(name string) (location int, ok bool) {
    if item, ok := symtab[name]; ok {
        return item.memLoc, true
    }
    return 0, false
}

插入分两种情况，如果已经存在，则仅更新行数列表；否则，还要分配一个空间。要改变map中某个元素的值，需要将其取出、修改值，然后重新设立对应关系，所以在上面的定义中使用了引用，得以在不修改引用地址的情况下增加引用行列表。

func insertSymtab(name string, lineNo int) {
    if item, ok := symtab[name]; ok {
        item.refLines = append(item.refLines, lineNo)
    } else {
        symtab[name] = &struct {
            refLines []int
            memLoc   int
        }{[]int{lineNo}, memLoc}
        memLoc++
    }
}

语义分析

语义分析主要干两件事，类型检查和插入符号表。

定义了一个统一的DFS函数，通过传入不同的函数，执行前序和后序遍历的操作。类型检查需要后序遍历，插入符号表则需要前序遍历（看起来TINY是 lexical scoping）。

func traverse(t *treeNode, preProc func(*treeNode), postProc func(*treeNode)) {
    if t == nil {
        return
    }
    if preProc != nil {
        preProc(t)
    }
    for i := 0; i < 3; i++ {
        traverse(t.child[i], preProc, postProc)
    }
    if postProc != nil {
        postProc(t)
    }
    traverse(t.sibling, preProc, postProc)
}

构建符号表需要对每个出现变量的地方都进行一次插入操作。因为在之前的符号表操作中已经做到了根据已经插入与否区分不同的行为，所以此处可以省去判断是否已经存在。

// 将某个语法树节点的信息插入符号表
func insertNode(t *treeNode) {
    switch t.node {
    case stmtNode: // 对于语句，只有赋值和读语句需要插入符号表
        if t.stmt == assignStmt || t.stmt == readStmt {
            insertSymtab(t.attr, t.lineNo)
        }
    case exprNode: // 对于表达式，其中的标识符都要记在符号表中
        if t.expr == idExpr {
            insertSymtab(t.attr, t.lineNo)
        }
    }
}

// 遍历，构建符号表
func BuildSymtab(t *treeNode) {
    traverse(t, insertNode, nil)
}

类型检查的思想就是，赋值语句和写语句后面要匹配integer类型，if和repeat则要匹配bool类型。

// 对 t 做类型检查，反正就 bool 和 integer 两种类型
func checkNode(t *treeNode) {
    switch t.node {
    case exprNode:
        switch t.expr {
        case opExpr: // 运算符表达式，两个 child 类型均为 integer
            if t.child[0].typ != intExpr || t.child[1].typ != intExpr {
                typeError(t,"Op applied to non-integer")
            }
            if t.op == eqToken || t.op == ltToken { // 返回的是比较结果
                t.typ = boolExpr
            } else { // 返回的是计算结果
                t.typ = intExpr
            }
        default: // const 或 id，直接返回类型
            t.typ = intExpr
        }
    case stmtNode:
        switch t.stmt {
        case ifStmt: // if 语句，条件表达式类型为 bool
            if t.child[0].typ != boolExpr {
                typeError(t.child[0], "If test is not Boolean")
            }
        case assignStmt: // 赋值语句，表达式类型为 integer
            if t.child[0].typ != intExpr {
                typeError(t.child[0], "Assignment of non-integer value")
            }
        case writeStmt: // 写语句，表达式类型为 integer
            if t.child[0].typ != intExpr {
                typeError(t.child[0], "Write of non-integer value")
            }
        case repeatStmt: // repeat 语句，条件表达式类型为 bool
            if t.child[1].typ != boolExpr {
                typeError(t.child[1], "Repeat test is not Boolean")
            }
        }
    }
}

// 对整个语法树做类型检查
// 在进行完毕类型推导后，再做节点类型检查
func TypeCheck(t *treeNode) {
    traverse(t, nil, checkNode)
}

代码生成

生成代码已经是这个编译器做的最后一步了，没有优化，没有中间代码。TM虚拟机读取的还不完全是三地址码，更别提LLVM IR那样高阶的东西了，而是有点类似于真实计算机的寄存器 + 内存的组合。寄存器有累加AC1和AC2、程序计数器PC，以及GP和MP寄存器。

在 codegen.go 中，使用 CodeGen() 初始化程序运行环境，调用 cGen 对AST根节点生成代码，然后挂起虚拟机。在 cGen 中，根据当前节点的类型调用 genStmt 或 genExp 生成语句或表达式，然后再对其兄弟节点调用 cGen，生成下一条语句对应的代码。

语句

对于 repeat <statement> until <expression>，先执行statement，再判断expression，判断结果会存放在AC1寄存器中。当AC1为0时代表条件成立，执行条件跳转指令，到statement之前，再次执行。

    case repeatStmt:
        emitComment("-> repeat")
        p1 := t.child[0]
        p2 := t.child[1]
        // 保存循环前的位置
        savedLoc1 := emitSkip(0)
        emitComment("repeat: jump after body comes back here")
        // 执行语句
        cGen(p1)
        // 判断条件
        cGen(p2)
        // 如果符合，跳转到 savedLoc1，即循环前
        emitAbsRM("JEQ", ACCUMULATOR1, savedLoc1)
        emitComment("<- repeat")

对于 if 语句，依次填入的指令为：

判断 expr
若不符合，跳转到 stmt2
执行 stmt1
跳转到 stmt2 结束
执行 stmt2

    case ifStmt:
        // if <expr> then <stmt1> else <stmt2> end
        // 或 if <expr> then <stmt1> end
        emitComment("-> if")
        p1 := t.child[0]
        p2 := t.child[1]
        p3 := t.child[2]
        // 生成条件表达式的代码
        cGen(p1)
        // 空一个跳转 stmt1 末尾的位置
        savedLoc1 := emitSkip(1)
        emitComment("if: jump to else belongs here")
        // 生成 stmt1 的代码
        cGen(p2)
        // 空一个指令，供跳转到 stmt2 结束
        savedLoc2 := emitSkip(1)
        emitComment("if: jump to end belongs here")
        // 获得 stmt2 的开始位置
        currLoc := emitSkip(0)
        // 回到 expr 判断结束处，写入条件跳转语句
        emitBackup(savedLoc1)
        emitAbsRM("JEQ", ACCUMULATOR1, currLoc)
        emitComment("if: jmp to else")
        // 回到 stmt2 开始处
        emitRestore()
        // 生成 stmt2 语句的代码
        cGen(p3)
        // 获得 stmt2 结束后的位置
        currLoc = emitSkip(0)
        // 回到 stmt1 结束处，无条件跳转到 stmt2 结束处
        emitBackup(savedLoc2)
        emitAbsRM("LDA", PROGRAM_COUNTER, currLoc)
        emitComment("if: jmp to end")
        // 回到 stmt2 结束处
        emitRestore()
        emitComment("<- if")

对于 assign 语句，就是计算表达式的值，查符号表得到内存地址，然后将值存进去：

    case assignStmt:
        // <id> := <expr>
        emitComment("-> assign")
        // 计算表达式的值，存入 ACCUMULATOR1
        cGen(t.child[0])
        // 找到 id 的内存偏移
        loc, _ := lookupSymtab(t.attr)
        // 将表达式的值存入 id 的内存偏移
        emitRM("ST", ACCUMULATOR1, loc, GLOBAL_POINTER)
        emitComment("<- assign")

read 和 write 语句也会使用AC1作为中转，不同的是 write 计算表达式的值时会隐式地存入AC1，表现倒是相同的：

    case readStmt:
        // read <id>
        emitComment("-> read")
        // 读取输入，存入 ACCUMULATOR1
        emitRO("IN", ACCUMULATOR1, 0, 0)
        loc, _ := lookupSymtab(t.attr)
        // 将输入的值存入 id 的内存偏移
        emitRM("ST", ACCUMULATOR1, loc, GLOBAL_POINTER)
        emitComment("<- read")
    case writeStmt:
        emitComment("-> write")
        // 计算表达式的值，存入 ACCUMULATOR1
        cGen(t.child[0])
        // 将 ACCUMULATOR1 的值输出
        emitRO("OUT", ACCUMULATOR1, 0, 0)
        emitComment("<- write")

表达式

此处每个表达式的结果最后都会存放在AC1寄存器中，这是一个约定用法。

常量表达式最简单，直接使用加载常量的指令，把值存入AC1：

    case constExpr:
        emitComment("-> Const")
        // 将常量存入 ACCUMULATOR1
        emitRM("LDC", ACCUMULATOR1, t.val, 0)
        emitComment("load const")
        emitComment("<- Const")

加载一个变量也只需根据指针将其从内存中读出：

    case idExpr:
        emitComment("-> Id")
        // 找到 id 的内存偏移
        loc, _ := lookupSymtab(t.attr)
        // 将该地址对应的值存入 ACCUMULATOR1
        emitRM("LD", ACCUMULATOR1, loc, GLOBAL_POINTER)
        emitComment("load id value")
        emitComment("<- Id")

在计算一个带运算符（算术运算和比较）的表达式的值时，需要先求出左右子表达式的值。tmpOffset 的设置是为了让嵌套执行此处代码时，每一个 genExpr 的 tmpOffset 值都是不同的，从而在多层 opExpr 下能够将左子表达式的临时值存放在不同的位置；否则每次执行都会向同一个位置（即MP）读写内容，从而覆盖外层求出的结果。

    case opExpr:
        emitComment("-> Op")
        // 求左子表达式的值，存入 ACCUMULATOR1
        cGen(t.child[0])
        // 将 ACCUMULATOR1 的值存入内存偏移 tmpOffset
        emitRM("ST", ACCUMULATOR1, tmpOffset, MEMORY_POINTER)
        // 将 tmpOffset 加 1，即指向下一个内存偏移（当然后面存的不能重合了）
        tmpOffset--
        emitComment("op: push left")
        // 求右子表达式的值，存入 ACCUMULATOR1
        cGen(t.child[1])
        tmpOffset++
        // 将左子表达式的值存入 ACCUMULATOR2
        emitRM("LD", ACCUMULATOR2, tmpOffset, MEMORY_POINTER)
        emitComment("op: load left")

算术表达式的求解很简单，惟需注意上面执行完毕后左边对应AC2，右边对应AC1：

        switch t.op {
        case plusToken:
            // AC1 = AC2 + AC1
            emitRO("ADD", ACCUMULATOR1, ACCUMULATOR2, ACCUMULATOR1)
            emitComment("op +")
        case minusToken:
            // AC1 = AC2 - AC1
            emitRO("SUB", ACCUMULATOR1, ACCUMULATOR2, ACCUMULATOR1)
            emitComment("op -")
        case timesToken:
            // AC1 = AC2 * AC1
            emitRO("MUL", ACCUMULATOR1, ACCUMULATOR2, ACCUMULATOR1)
            emitComment("op *")
        case overToken:
            // AC1 = AC2 / AC1
            emitRO("DIV", ACCUMULATOR1, ACCUMULATOR2, ACCUMULATOR1)
            emitComment("op /")

小于运算符的情况，如果AC1<AC2，则AC1=0；否则AC1=1。

        case ltToken:
            // AC1 = AC2 - AC1
            emitRO("SUB", ACCUMULATOR1, ACCUMULATOR2, ACCUMULATOR1)
            emitComment("op <")
            // 若 AC1<AC2（新 AC1<0），则往后跳两个指令
            emitRM("JLT", ACCUMULATOR1, 2, PROGRAM_COUNTER)
            emitComment("br if true")
            // 若 AC1>=AC2，则 AC1=0
            emitRM("LDC", ACCUMULATOR1, 0, ACCUMULATOR1)
            emitComment("false case")
            // 无条件跳一条指令
            emitRM("LDA", PROGRAM_COUNTER, 1, PROGRAM_COUNTER)
            emitComment("unconditional jmp")
            // 若 AC1<AC2，则 AC1=1
            emitRM("LDC", ACCUMULATOR1, 1, ACCUMULATOR1)
            emitComment("true case")

等于的情况类似，仅当AC1=AC2时AC1=0：

        case eqToken:
            emitRO("SUB", ACCUMULATOR1, ACCUMULATOR2, ACCUMULATOR1)
            emitComment("op ==")
            emitRM("JEQ", ACCUMULATOR1, 2, PROGRAM_COUNTER)
            emitComment("br if true")
            emitRM("LDC", ACCUMULATOR1, 0, ACCUMULATOR1)
            emitComment("false case")
            emitRM("LDA", PROGRAM_COUNTER, 1, PROGRAM_COUNTER)
            emitComment("unconditional jmp")
            emitRM("LDC", ACCUMULATOR1, 1, ACCUMULATOR1)
            emitComment("true case")

HNU 软件编译原理实验 3（Go 实现）

Tue, 25 Apr 2023 00:00:00 +0000

虽然课程从头到尾没提到过TINY语言，但实验三全都围绕着TINY构造。

代码已上传至GitHub，为防止篇幅过长，没有内置所有代码，仅对个人认为值得讲述的地方进行说明，可以对比阅读。

cyp0633/compiler-lab

TINY语言

TINY语言是《编译原理及实践》（Compiler Construction: Principles and Practice，之后简称CCPP）中用于演示的语言，杨某人课程中心实验包中也有其中译本PDF文档（虽然翻得不咋样）。

在该书的1.7.1节中，提到了TINY语言的特性：

没有过程，没有函数声明
所有变量都是整型，通过一个赋值定义
只有 if 语句和 repeat 控制语句
if 语句可选 else 分支，必须用 end 表示结束
有输入输出语句
表达式只有算术（加、减、乘、整除）和布尔表达式（仅有 < 和 =）
注释由花括号包裹

示例程序：

pascal

{ Sample program
  in TINY language -
  computes factorial
} 
read x; {input an integer} 
if 0 <x then { don't compute if x <= 0} 
  fact := 1; 
  repeat 
    fact := fact * x; 
    x := x - 1 
  until x = 0; 
  write fact {output factorial of x} 
end

该书同时提供了TINY语言编译器的源代码，见此网站。

词法分析器

TINY语言的词法，书中已有明确的DFA描述。

TINY词法分析器包含于 scan.c 和 scan.h 中，可以直接参考实现。这个词法分析器由语法分析器调用，并不会一次把源文件扫完，而是调用一次获取一个token。这和下图中的配合方式有点像。

词法分析器中有三个函数：

getNextChar：读取下一个字符。它维护了一个 lineBuf，即当前正在读取的代码行，在当前行读完的时候，会自动读下一行。
ungetNextChar：撤销上个 “读取下一个字符” 操作。注意到上图的DFA中有几条 [other] 边，这类似于状态转换图中的星号，代表这条边只会 “peek” 而不会真正读进来。
GetToken：读取下一个token，然后返回类型。

在原来的代码中有一个线性查找保留词表的函数，但似乎可以直接用map替代掉。话说C++ STL不是有map吗？

var reservedWords = map[string]tokenType{
    "if":     ifToken,
    "then":   thenToken,
    "else":   elseToken,
    "end":    endToken,
    "repeat": repeatToken,
    "until":  untilToken,
    "read":   readToken,
    "write":  writeToken,
}

对于源文件的读入方式，我选择了使用 bufio.Scanner。这玩意可比 io.Reader 好用多了。

`getNextChar`

// getNextChar 从 lineBuf 中读取一个字符，
// 如果 lineBuf 为空则从输入流中读取一行
func getNextChar() (byte, error) {
    // 本行已经读取完毕
    if linePos >= len(lineBuf) {
        lineNo++
        ok := sourceScanner.Scan()
        if !ok { // 文件末尾
            err := sourceScanner.Err()
            if err == nil {
                // EOF 的话不会返回 err
                eof = true
                return 0, io.EOF
            } else {
                // 真的出现错误了
                lineBuf = ""
                linePos = 0
                return 0, err
            }
        }
        lineBuf = sourceScanner.Text()
        linePos = 1
        return lineBuf[0], nil
    } else {
        linePos++
        return lineBuf[linePos-1], nil
    }
}

这个Scanner的默认分隔符就是换行，如果读取到末尾，会返回一个false，然后没有err（想不通为什么不是 io.EOF）。

eof 的作用后面说。

`ungetNextToken`

// ungetNextChar 将 lineBuf 中的一个字符退回
func ungetNextChar() {
    if !eof {
        linePos--
    }
}

不加eof判断的话 GetToken 会一直读最后一个字母，停不下来。

`GetToken`

这个函数是一个完整的状态机实现，包含的状态如上面DFA所示，每次走到DONE就代表识别完成了一个token。代码太长了就不放在文章里了。

值得注意的是状态里面没有保留字，因为这个词法分析器会先将非数字开头的字符串作为变量名，然后检查是否匹配保留字，并据此返回词类型。

有一个 tokenString 变量，顾名思义。只有变量名和数字等才需要记录，而对于注释之类的对语义完全没有作用的东西可以直接忽略掉。

This content is licensed under a Creative Commons Attribution-ShareAlike 4.0 International license.

HNU 软件编译原理实验 2（Go 实现）

Wed, 12 Apr 2023 00:00:00 +0000

做这次实验有点难受，我不知道该怪罪Go的类型系统还是杨某人的面向对象结构。

代码已上传至GitHub，为防止篇幅过长，没有内置所有代码，仅对个人认为值得讲述的地方进行说明，可以对比阅读。

cyp0633/compiler-lab

数据结构

产生式

Production 结构体与其说是产生式，不如说是产生式的右部，而直到LR(0) 项目中才记录了左部信息。

有两个特殊的文法符，$\epsilon$ 和 $#$，为了让它们在每一处都有相同的地址以方便比较，直接将定义写死在了代码里。

// epsilon 不属于非终结符，也不属于终结符！！！
// 看起来要用好多次，就先定义好了
var epsilonSymbol = GrammarSymbol{
    Name: "epsilon",
    Type: Null,
}

var endSymbol = TerminalSymbol{
    GrammarSymbol: GrammarSymbol{
        Name: "#",
        Type: Terminal,
    },
}

由于Go没有继承没有多态，只有嵌入以让一个结构体拥有另一个结构体的完整成员，那也无法使用一个 GrammarSymbol 指针指向终结符或非终结符。因此，在希望存储更多类型时，只能用一个 interface{} 解决。果然是著名的万物皆是interface。比如：

type NonTerminalSymbol struct {
    GrammarSymbol
    ProductionTable      []*Production               // 非终结符的产生式表
    NumOfProduction      int                         // 产生式数量
    FirstSet             map[interface{}]bool        // 该非终结符的 First 函数值
    FollowSet            map[interface{}]bool        // 该非终结符的 Follow 函数值
    DependentSetInFollow map[*NonTerminalSymbol]bool // 该非终结符的 Follow 函数中依赖的非终结符
}

而这里就带来了一个问题：interface{} 完全没有类型检查，可以放指针，也可以放结构体本身。这就要求类型检查覆盖到不正常的情况，算了，大道至简嘛——

go的教徒还住着毛坯房，毕竟大道至简

V2EX 网友

不过可以规定，此处的 interface{} 里存的全都是指针，并且代码实现保证同一个语法符仅存一份（即不会存在对象相同但指针不同）。

follow 依赖的非终结符完全没用过，倒不是说没用，而是觉得没必要。后面直接算的是所有非终结符的 follow。

LL(1)

LL(1) 分析表并没有使用预定义的cell，毕竟通过遍历一个slice查表的操作未免太不优雅了。

var LL1AnalysisTable = map[struct {
    *NonTerminalSymbol
    string
}]*Production{}

这里嵌入了一个匿名结构体，key的两个scope分别为非终结符和向前看的下一个语法符，value为对应的产生式。

LR(0)

和上面同理，既然项目集的本质是一个集合，就没必要使用数组这么傻的东西。

type ItemSet struct {
    // 状态序号
    ID int
    // LR(0) 项目表（其实是个集合）
    ItemTable map[LR0Item]struct{}
}

同时也直接砍掉了那几个cell，对LR(0) 分析表可以直接使用map映射。如下是 $\text{ACTION}$ 表的定义，用了两个匿名结构体。$\text{GOTO}$ 表定义同理。

// LR Action 表
// 由状态 ID 和终结符名称，到动作类型和编号的映射
var ActionTable map[struct {
    // 当前栈顶状态序号
    StateID int
    // 待读入的终结符名称
    TerminalSymbolName string
}]struct {
    // 动作类型
    Type ActionCategory
    // 动作编号，如归约的产生式编号和移进的下个状态
    ActionID int
}

同样能使用map优化的还有自动机的边表。一般的查询都是根据起始状态和驱动符查找到达状态的，使用map会快很多。

// LR(0) 自动机
var DFA struct {
    // 开始项集
    StartItemSet *ItemSet
    // map 优化的变迁边表
    // 通常查询更快，极端情况下也不会更慢
    EdgeSet map[TransitionKey]*ItemSet
}

方法

产生式

定义了终结符、非终结符和产生式的 First 函数。对于终结符，可以直接返回包含自己的集合。而对于非终结符，

不要忘了如果 First 已经计算完成，就不要再算一次了，毕竟值都存储到了对应的数据结构中。

而在 Follow 函数中，关于是否有新的加入，个人使用的是比较插入前后map长度变化，不过先检查key是否存在似乎更快点。

在这里引入了一个库：github.com/google/go-cmp/cmp，它能够提供比 reflect.DeepEqual 更好的比较。如果是两个指针，前者会比较指向的内容，而后者只比较地址。如计算产生式的 First 函数时：

    // 只有 epsilon，就直接返回
    if p.BodySize == 1 && cmp.Equal(p.BodySymbol[0], &epsilonSymbol) {
        return map[interface{}]bool{&epsilonSymbol: true}
    }

由于每次添加 $\epsilon$ 时都是引用了同一个实例，所以这么比较没什么问题。只是听说Go的反射挺慢的，这个怕不是会更慢……

说到反射那当然还是要用的，因为又回到了没有多态的问题。不像其他语言，基类指针可以访问基类的内容，Go仅凭一个 interface{} 根本无法获取它的真正类型。于是，如 Follow 初始化时添加非终结符的操作：

    // 初始化 FOLLOW 集合
    for _, A := range GrammarSymbolTable {
        // 如果不是非终结符，跳过
        if reflect.TypeOf(A) != reflect.TypeOf(RootSymbol) {
            continue
        }
        A.(*NonTerminalSymbol).FollowSet = make(map[interface{}]bool)
    }

使用反射就可以轻松判断真实类型了，当然也可以像是在非终结符 First 函数中，寻找 $\epsilon$ 产生式的代码这样：

    // 寻找 epsilon 的产生式（仅含 epsilon）
    for _, p := range nt.ProductionTable {
        if p.BodySize == 1 {
            symbol, ok := p.BodySymbol[0].(*GrammarSymbol)
            if ok && symbol.Type == Null { // 为什么不能放到一个 if 里啊！！！
                // 如果存在将 epsilon 加入该非终结符的 First 函数值
                nt.FirstSet[&epsilonSymbol] = true
            }
        }
    }

（现在我们知道，当然是可以放在一个if里的，用反射就优雅多了）

在求产生式的非终结符时，需要求某产生式右部某一部分的 First 函数。此处选择构造一个产生式求 First，然后一切交给GC，应该不会存在重复计算过多的问题。

                    // 先看成 A \Rightarrow \alpha B \beta，求 FIRST(\beta)
                    // 将 \beta 部分组合成一个产生式
                    tempProduction := Production{
                        BodySymbol: production.BodySymbol[index+1:],
                        BodySize:   len(production.BodySymbol[index+1:]),
                    }
                    betaFirst := tempProduction.First()

LL(1)

检测左递归使用的是DFS方法，每一层对某个特定非终结符的所有产生式进行搜索，在搜索路径上维护一个map，记录非终结符的出现与否（毕竟只有非终结符才有左递归这回事），思想比较像递归子程序法。如果当前非终结符已经处于那个map中，就代表有左递归。这样能同时检测直接和间接的左递归。

// 对所有非终结符检测左递归
func CheckLeftRecursion() (ret bool) {
    return checkLeftRecursion(make(map[string]bool), RootSymbol)
}

// 使用 DFS 检测左递归，rec 用于记录已经检测过的非终结符
func checkLeftRecursion(rec map[string]bool, curr *NonTerminalSymbol) bool {
    // 如果已经检测过，返回
    if rec[curr.Name] {
        return true
    }
    // 否则加入 map
    rec[curr.Name] = true

    for _, production := range curr.ProductionTable {
        // 长度为 0，返回
        if len(production.BodySymbol) == 0 {
            continue
        }
        // 是非终结符
        if symbol, ok := production.BodySymbol[0].(*NonTerminalSymbol); ok {
            if checkLeftRecursion(rec, symbol) {
                return true
            }
        }
    }
    return false
}

消除左递归其实就是套课本上的算法了，没有什么好说的。

检测左因子就是对某个非终结符的所有产生式首语法符进行查重，重点在 “有没有”，而提取左因子面临着一个取舍，在同一次提取中，无法既对尽量多的产生式进行提取，又提取出尽量长的公因子。在这篇博客中介绍了一种通过树实现的算法，不需要考虑取舍也不需要进行多次提取。

多好的算法啊，可惜有点复杂，我还是老老实实多次提取吧（然而还是100多行）。基本思想：

循环提取，直到检测不到左因子
先检测开头的因子是否有重复，确定首公因子之后再尝试延长公因子。如对于1123、114和514，先确定提取开头的1，然后延长到11
倾向于提取更多产生式的左因子（而不是提取更长的左因子），包括每次选择包含产生式最多的公因子进行提取（如123、145、245、255、244中提取2，因为有2的多于有1的），以及延长时遇到无法延长的产生式时直接放弃（如1123、1134、11156、11145只会延长到11，而不会放弃前两个来提取111）

另外还要注意新产生式为空时epsilon的问题。新非终结符的产生式和被移除的产生式序号一一对应，也可以重复利用。实在看不懂就看代码吧……

LL(1) 分析表的构造也是课本上就有的算法了，实现起来难度也不高。

LR(0)

LR(0) 写起来真的让我血压高，穷举变迁时已经得到了从哪个状态来、借由某个驱动符、到哪个状态去的信息，但却要再写一个求解DFA，再求一次变迁…… 真的不优雅，想了好久如何把它变得快一点，然后失败了。

求解变迁时常用的是直接调Goto函数，而这里由于是对某个项目集所有的项目求对应的变迁，所以不需要两层循环，直接一层循环即可。这里提前新建一个map newItemSets，对每个驱动符映射到其GOTO状态对应的项目集，对每个非归约项目直接把点后移之后加入新项目集就行了，遍历完成后，核心项就都有了。

    // 遍历项目集中的每个项目
    // 此处并不需要驱动符一层项目再一层，省点时间
    for item := range itemSet.ItemTable {
        // 如果已经是归约 / 接受项目（A \to \cdot \alpha），则不需要变迁
        if item.DotPosition == len(item.Production.BodySymbol) {
            continue
        }
        // 取出该驱动符对应的项目集
        itemSet := newItemSets[item.Production.BodySymbol[item.DotPosition]].ItemTable
        // 将项目 item 的点后移一位
        // 新的项目！
        item1 := LR0Item{
            NonTerminalSymbol: item.NonTerminalSymbol,
            Production:        item.Production,
            DotPosition:       item.DotPosition + 1,
            Type:              CoreItem, // 一定是核心项啦
        }
        // 将新项目加入项目集
        itemSet[item1] = struct{}{}
    }

至于求解DFA嘛，其实也就大差不差了，我甚至复制了一大段代码。

在SLR(1) 的检查之中，可以使用一个map（set）存放归约项集的各个左部（即 $A \to \alpha \cdot$ 的 $A$），一个map存放移进项集对应的驱动终结符集（即 $A \to \alpha \cdot a \beta$ 的 $a$），更方便计算交集。

接下来是构造LR分析表，我也不知道杨某人这句话是什么意思，那就先填个LR(0) 吧。

四个if-else让人血压挺高的，你问我为什么不用switch？因为case里面不能声明局部变量，所以 case symbol, ok := item.Production.BodySymbol[item.DotPosition].(*TerminalSymbol); ok 这样的判断就写不出来，着实不太方便。

        for item := range itemSet.ItemTable {
            // 判断项目类型
            // 为什么不用一个 switch？因为特么的 go 不支持 switch 里做声明
            if item.NonTerminalSymbol == RootSymbol && item.DotPosition == len(item.Production.BodySymbol) {
                // 接受项目 S' \to S \cdot
                // ACTION[i,#] = accept
                // code...
            } else if item.DotPosition == len(item.Production.BodySymbol) {
                // 归约项目 A \to \alpha \cdot
                // 对所有非终结符 a 或 #，ACTION[i,a] = reduce j
                // code...
            } else if symbol, ok := item.Production.BodySymbol[item.DotPosition].(*TerminalSymbol); ok {
                // 移进项目 A \to \alpha \cdot a \beta
                // action[i,a] = shift j
                // code...
            } else if symbol, ok := item.Production.BodySymbol[item.DotPosition].(*NonTerminalSymbol); ok {
                // 待约项目 A \to \alpha \cdot B
                // goto[i,B] = j
                // code...
            }
        }

This content is licensed under a Creative Commons Attribution-ShareAlike 4.0 International license.

cyp0633's Blog

1013

Pixel Watch 2：最终还是只能成为大号手环吗

手腕上的一颗鹅卵石

谷歌全家桶来了也是毛坯房

Fitbit之魂

手表究竟是个什么角色？

不用买网关，ESP32蓝牙代理解决Home Assistant BLE问题

购买

刷写

配置

1012

终端Agent是更趁手的通用Agent

为什么是本地agent？

为什么是终端？

为什么不是OpenClaw？

1011

1010

《无限试驾：太阳王冠》：小作坊别出来骗钱

《赛车计划 3》：早该下架的史级烂作

1009

Cumulus Linux 5.1 & NVUE 使用笔记

用户管理

声明式配置管理

排除连接问题

屏蔽了一些爬虫

阿里云阴兵过境

刷爆对象存储，但是细水长流

超级分布式Gitea爬虫

表层特征过滤和速率限制

JS challenge

Gitea限制用户访问

自己写一层gateway

深层特征辨别

验证Cookie

Meta连爬6天

中国互联网上，到底还能用什么获取信息

OPPO Enco Free 4：技能树全点歪了的耳机

音质、调音与主观听感

主动噪音控制

App与互联

佩戴与操控

续航与充电

总结

在 Linux 上使用微软套件的最好办法，就是没有办法

WPS Office：又不是不能用

Office Online：六边形战士，但六边都不长

虚拟机：堕落的混乱邪恶派

WinApps：想法很美好，但没有Wayland

总结

索尼 WH-CN720N：我就知道会缺点什么

设备连接与App体验

音质与调音

降噪与通透

佩戴舒适度

总结

1007

记导出 Android 版 NTQQ 聊天记录

导出数据库1

解密数据库2

导出聊天记录

1006

1005

1004

1002

test

小米 15：「锐利」当道的「圆滑」异类

CMF（色材工艺）

性能

HyperOS 2

传统体验

AI

影像

显示

通信

电池

其他外围配置

结语

「超值」的宽体机体验：南航 CZ6043 A359

RivaTuner Statistics Server 游戏悬浮窗入门

导出数据库¹

解密数据库²

使用Bear生成 `compile_commands.json`

使用CMake生成 `compile_commands.json`

使用 `Config` 子系统