首先我正确配置了mipush服务，QQ也正常注册，也使用机型模块伪装对QQ伪装成了小米设备，刚开始能正常推送，后来突然不推送了，删除/data/data QQ里的mipush配置文件重新注册也不起作用

今天下午无意间打开momo才发现，自己的shamiko被关了，直接一个大大的「已发现su」糊脸上，把shamiko打开后重启，结果QQ的mipush推送又好了，太神秘了，不知道有没有遇到过同样情况的

为什么说是只有QQ会检测到root就不推送呢，因为闲鱼等app他是可以正常推送的，我甚至没有针对他们进行小米机型伪造，QQ检测真的是

0. 引

经常玩手游的三星用户，在折腾性能优化的时候估计听到过一个说法去应用商店更新下图形驱动。乍一看有点离谱，驱动这种东西为什么是在应用商店更新？结果一看还真是个apk，是不是感觉草台班子？本文将把时间线拨回2020年，以Galaxy S20为起点，带你了解三星这个神秘的图形驱动APK化

1. 为什么是 Galaxy S20？

2020 年发布的 Galaxy S20 系列是安卓阵营的一个重要分水岭。这要归功于当时三个底层技术的一拍即合

首先是硬件方面，在 2019 年底发布的骁龙 865 处理器上，高通首次宣布支持可更新的 GPU 驱动。S20 正是首批搭载骁龙 865 的旗舰机

其次就是软件方面，Google在 Android 10 中引入了 Project Mainline，其核心目的就是系统组件模块化，允许通过应用商店更新核心组件。而Samsung作为Android的老大哥，也是第一时间跟进了这个

到了 2020 年底，Samsung 真的在 Google Play 商店和自家的 Galaxy Store 上架了名为 Samsung Game Driver 的独立 APK 应用，这就标志着 GPU 驱动作为 App 存在的正式落地

2. 神秘的双版本

如果你回去看当年的上架记录，会发现一个很有意思的现象，三星上架了两个版本的apk，这其实不难理解

1. Samsung Game Driver - Adreno，是专门给搭载骁龙处理器的 S20/Note20 系列用的
2. Samsung Game Driver - Mali，这就是专门给搭载猎户座 Exynos 处理器的 S20/Note20 系列用的

当时这个驱动更新并不是提升全局性能，而是有高度针对性的。Samsung 明确写着：本次更新优化了《使命召唤手游》等游戏

也就是说，如果某个热门大作突然发布，出现了图形错误或者负优化，三星不需要去搞系统OTA，只需找高通等厂商写个补丁，打一个几十MB的apk发在商店，玩家一更新，重进游戏就好

3. APK 怎么能变底层驱动？

背后的核心机制叫做 Updatable Graphics Drivers，在 AOSP 源码里主要涉及 frameworks/native/libs/graphicsenv 和 frameworks/native/opengl/libs/EGL/Loader.cpp

我们分四个部分来讲

3.1 发现机制

系统怎么知道这个 APK 是驱动？不是随便装个 APK 就能冒充的

1. 元数据声明 三星发布的 Samsung Game Driver.apk，在其 AndroidManifest.xml 里必须包含特定的 <meta-data> 标签：

//示例
    <meta-data android:name="android.graphics.driver.build_time" value="Chongxi & CEPATO" />
    <meta-data android:name="com.android.graphics.driver.library" value="libGLESv2_adreno.so" />

这个 com.android.graphics.driver.library 是关键，它让系统知道他是货真价实的库

1. Game Driver Service：
   Android 系统启动时，GraphicsEnvironment会扫描所有已安装的应用。它会寻找包名符合规则（如 com.samsung.gamedriver.sm8250）且带有上述元数据的 App

一旦找到，它会把这个 APK 的路径（/data/app/~~.../base.apk!/lib/arm64-v8a/）缓存到系统服务里，标记为 Available Driver Provider

3.2 注入

当你在启动codm时，进程刚Zygote Fork，加载图形库的流程如下：

游戏进程首先加载的是系统的 /system/lib64/libEGL.so 和 /system/lib64/libvulkan.so

这只是个Wrapper/Stub，里面全是空函数或者转发逻辑，真正的驱动还没加载

在 AOSP 源码的 Loader.cpp 中，有一个关键函数 Loader::openDriver。它会向 GraphicsEnvironment 发起查询：

这个叫血战孤儿院的，有没有被指定使用‘Game Driver’？

如果确实启用了，Linker 会创建一个独立的 Native Namespace

• 一般情况下 Linker 去 /vendor/lib64/egl 找 libGLESv2_adreno.so
• 现在系统会调用 android_create_namespace，并把 LD_LIBRARY_PATH 强行指向 解压目录/data/app/...

这意味着，游戏进程在这个独立的命名空间里，它以为它加载的是系统库，实际上 Linker 给它塞的是 APK 里的 .so

3.3 握握手

APK 只能更新用户层面(UMD)，也就是运行在 User Space 的 OpenGL/Vulkan 实现库。但硬件是运行在 Kernel Space 的，也就是内核KMD

在这台手机上

• KMD: 是编译进 boot.img 里的 kgsl 模块。它暴露的设备节点通常是 /dev/kgsl-3d0
• UMD: 就是 APK 里那几个 .so

怎么通讯？IOCTL

当你用 APK 更新了驱动，新的UMD会打开 /dev/kgsl-3d0，通过 ioctl 系统调用发送命令流给内核

:::warn 这里有个大问题就是 ABI稳定性 :::

APK 里的新驱动（UMD）必须得向下兼容老旧的内核驱动（KMD）
如果高通在新的 UMD 里用了一个新的 ioctl 命令，但你的内核是 3 年前的，根本不认识这个指令，驱动初始化就会失败

这就是为什么三星/高通不能无限制地给S20这个机子推送最新的驱动 APK。APK 里的 UMD 版本，必须跟你的内核 KMD 版本握手成功才能跑

3.4 SELinux

Android 的 SELinux 极其严格。普通app是没有权限去加载另一个 App私有目录下的 .so 文件的

为了让这个 APK 驱动能跑，Google 在 Android 10 的 SELinux 策略里开了一个白名单

• 定义了一个新的域 gamedriver_file
• 允许 appdomain（普通应用进程）对标记为 gamedriver_file 的文件执行 map 和 execute 操作

所以，那个驱动 APK 安装后，系统会自动给它的 .so 文件打上特殊的 SELinux 标签，否则 Linker 加载时会被直接Permission Denied

这就是为什么说 S20 的模块化是教科书级别的

它在不刷机、不Root、不修改系统分区的前提下，通过 Linker Namespace 和 SELinux 策略，实现了核心渲染逻辑的热替换。这在以前绝对做不到

4. 现在如何了

既然这个功能这么强，为什么现在好像很少听到大家天天去下「图形驱动 APK」了？

其实它没有消失，而是变得更无感、更模块化了：

• Google 后来把很多原本需要单独下 APK 的驱动级更新，整合进了系统后台默默进行的「Google Play 系统更新」中
• Samsung 后来把更多的游戏调度、底层适配策略，做进了另一个引发过巨大争议的模块化应用GOS

GOS 也是一个可以通过应用商店随时热更新的 APK，它不仅能调配驱动参数，还能控制 CPU/GPU 的温控墙和频率

5. 小结

Samsung 可以说是把系统软件模块化做到极致的厂商，Android 老大哥这名号不是白来的，感兴趣的话以后也可以讲讲Samsung的One UI还有哪些趣事。这里是Chongxi，我们下期再见

3/2 下午4:30更新 本blog会持续更新进展 :::

:::tip 现在是晚上九点，目前经测试基本恢复，给机台拔电重启后。在net充值记录查看有没有退款信息，若有就是没问题了 :::

0. 案例提供

当天包夜到维护时间关机，七点再开机时机台报错8106，8103是刚打完一把就报错，因为是窝里一直开的3倍票

非常感谢QQ昵称红咸给出的案例

1. SEGA ALL.Net 计费机制

SEGA 应该有一套营收统计系统。玩家的投币等行为会让机台都会生成一条计费日志

为了防止机厅老板跑路把日本人当日本人整，这些数据不是存在普通的硬盘里，而是硬写入到机台的加密区域中

由于其存储空间有限，因此，机台在连网时，或者定时维护时，会将账单上报给 ALL.Net。服务器确认收到后，机台才会清空加密狗里的记录，腾出空间给新的一天使用

2. 8106 和 8103 代表什么

2.1 8106 预警

首先，系统允许手动开启/关闭预警。当存储达到设定阈值时，且机台开启了ALL.NET警告，机台就会提示8106 ALL.Net 系统警告

为什么可以关？
这就像汽车的油量低提示灯，机修人员可以通过后台把灯拔掉，但这并不会阻止油被耗尽，可以说是掩耳盗铃

2.2 8103 炸机

当他存储彻底满了或达到限制的阈值，机台就会触发 8103 ALL.Net 系统错误
可能日本人想的是，既然无法记录新的账单，为了防止营收流失，必须拒绝一切游玩请求。所以机台会锁死，无法投币，导致机器无法正常游玩

3. 为什么现在出现案例了？

国服舞萌DX采用的是类似半买断的机制，本来不需要像日服那样AA，但SEGA的游戏底层代码并没有阉割掉这套记账逻辑，它依然在默默记账，为什么这次会出现这案例，个人猜测可能是服务器原因导致的

本身最近几次服务器动刀就是屎山上缝缝补补，可能运营方调整服务器的时候不小心干掉了相关代码逻辑，导致机台上传账单不处理/服务器无法正常接收或下发清空配置，这样账单数据一直压在存储里无法正常清除

4. 为什么现在是音游窝先给的案例，而不是商业机厅

为什么你先给的是音游窝的案例啊，万一窝里偷偷动了什么呢。商业机厅目前没案例那就是没事

咋说呢，一般商业机厅，一天可能也就投几百个币，即使几天传不上去，可能还能撑一撑。但包时机台的特点是：玩家开倍票不需要花钱，然后就使劲ALL三倍。更何况很多音游窝都是24h，本身就比一般商业机厅压力大，这就导致目前音游窝的机台最先撞到了物理上限这堵墙，就有了我们今天的案例分析

5. 解决办法

8106可以在net充值记录中关闭all net警告，8103无解

:::caution 如果你所在机厅的机台出现此问题，一定要让机厅相关人员提供报错时机台照片等信息给售后 :::

6. 现状

如果上面再不修复服务端账单的接收/清空机制，或者下发补丁给机台阉割相关无用代码。那么随着时间的推移，哪怕是投币量不大的普通机厅，早晚也会被填满，一起跟着爆

三星可以说是锁区比较严重的手机厂商了，国区三星被限制了许多功能，比如三星健康的Health Connect。即使您给三星健康Health Connect的读写权限，国区三星健康也不会主动写入。本文将手把手教你开启国区三星健康的开发者模式，将地区代码更改为US以启用Health Connect

0.2 什么是Health Connect

Health Connect 是 Google 和 Samsung 联手推出的安卓健康数据共享方案，旨在让不同的健身 App 能够互通有无，实现一处记录、全平台同步的无缝体验

0.3 前置

• 三星健康app - *本文测试时版本号6.30.7.004
• Health Connect应用 如果您的Android版本为14及以上，系统内置。否则您需要在Google Play下载

1. 开启开发者模式

1. 打开Samsung健康app，点击主页菜单，进入设置
2. 找到最下方关于三星健康，连续点击版本号，此时会激活开发者菜单
3. 点击Developer Mode(Samsung Health Data SDK)，将Developer Mode for Data Read的选项勾选为ON(到这里还没结束!!)

1. 打开任意文件管理器，在/storage/emulated/0/Download/目录下创建SamsungHealth文件夹，随后在其中创建FeatureManagerOn，FeatureListOn，CscManagerOn文件夹。创建后其目录呈如下：

/storage/emulated/0/Download/
└── SamsungHealth/
    ├── FeatureListOn/
    ├── FeatureManagerOn/
    └── CscManagerOn/

:::warn 注意文件夹名称大小写 :::

到这里就启用了开发者模式以及相关特性，回到三星健康的关于页面，如果呈下图状则说明成功

2. 更改三星健康地区

:::warn 接下来的每一步务必严格按照教程执行 :::

回到关于页面，点击Set Feature进入开发者特性菜单

2.1 更改 CSC & MCC

点开Common选项，将CSC Country Code更改为US，然后找到下方的MCC Configuration，更改为310(US)

2.2 更改 HA 服务器

点击Analytics选项，将**[HA] Server**更改为DEV

2.3 启用 DataPlatform 开发者模式

点击Data Platform，找到Developer Mode和Data SDK Developer mode，勾选为on

• 接下来就可以退出该页面，此时三星健康会要求你强行停止一次app，按照要求即可

• 再次进入三星健康时，会重新要求同意隐私协议等，务必选择同意

• 随后打开设置，即可看见健康连接的选项，进入授予权限即可

如果要在人类历史上评选出一款最完美 最冠冕堂皇的开脱工具，我会毫不犹豫地拿出「己所不欲，勿施于人」这句至圣名言

从古至今，这八个字一直被奉为道德修养的最高境界。但在现代语境下，尤其是在充斥着主观情绪的互联网讨论中，它不再是约束自己内心的道德明镜，而是变成了一面反弹一切客观事实并试图让对方闭嘴的万能盾牌

只要你掌握了这句话，你就可以完美地逃避任何你不喜欢的事物 拒绝任何客观的评价。这里就提供一个现实案例

0.2 案例还原

事情的起因很简单，我在某群里发了一张图，内容是我正在使用 Cloudflare Pages 服务

群友 A

为什么不用 Edgeone Page？

我：

答案是没必要。我不用国内云服务，我不在乎国内用户（国内用户体量小），我也没有在 L3/L4 层需要防御的东西

（随后，我将这段对话转述给了第三方）

路人：

己所不欲，勿施于人，因为你的受众不在国内，所以它对你是没用的。而对有国内受众的人来说，它是有用的。

我：

按最佳实践来说，Edgeone 也完全没必要。Blog 作为内容载体，有需要在 L3/L4 代理的吗？很明显，对于我这种静态页面，传统 CDN 完全可以应付非要套一堆有的没的，那不是在写 Blog，是拼赛博积木来的。

1. 逻辑分析

这句话之所以能成为逃避一切的工具，是因为它在逻辑操作上具有极强的隐蔽性。使用者在说出这句话的瞬间，已经完成了三重逻辑偷换：

1.1. 偷换主语

• 原逻辑：我所不欲，我勿施于人（我讨厌被迟到，所以我绝不迟到）
• 开脱逻辑：你所不欲，你勿施于我（你也不喜欢别人指出你的缺点吧？所以你别来指责我的缺点）

这就瞬间把道德要求从自己身上剥离，变成了勒索对方的绞索

1.2 偷换客体

• 原逻辑中的「不欲」，指的是不道德/不公正的伤害行为（如欺骗/背叛）
• 开脱逻辑中的「不欲」，被扩大化为一切让人不爽的事物

对方指出你的工作失误，这是客观事实。但你可以用谁都不喜欢被批评（主观情绪）来抵消这个事实。它用主观的爽不爽，掩盖了客观的对不对

1.3 诉诸虚伪

这句话的潜台词是：你自己也是人，你也有弱点，你也会痛，凭什么要求我？

它利用了「没有人是完美的」这一事实，直接取消了对方表达批评/建议/要求的资格

2. 心理学分析

作为开脱工具，这句话在心理防御上堪称大师级，它能极大地保护使用者的自恋，免受外界信息的冲击

2.1 道德高地

当你拒绝别人的意见时，如果说「我不想听」或者「我就喜欢这样」，显得很自私、很无赖。
但当你抛出「己所不欲，勿施于人」时，你瞬间就站在了圣人的肩膀上。你用一种极其高尚 充满古典道德光辉的句式，完成了最彻底的拒绝。
这种道德高地让批评者哑口无言

2.2 构建受害者叙事

这句话中的「施」字非常微妙。当你对别人说「勿施于人」时，你暗中构建了一个剧本：对方是强权者、施暴者，而你是被动承受的受害者

哪怕对方只是委婉地建议你少抽点烟，只要你用出这句话，对方立刻就变成了把意志强加于人的畜生。这就巧妙地逃避了问题本身，把问题变成了对方的态度问题

2.3 认知闭合

人面对挑战自己既有观念的事物时，会产生认知失调。这句话就是一个完美的STOP。它不需要你进行任何理性的反驳，不需要你摆事实讲道理，只需要抛出这八个字，就物理隔绝了所有需要消耗脑力去反思的信息

3. 话语权

在人际交往和辩论中，这句话是一个黑洞，任何有意义的表达都会被它吸进去并粉碎

3.1 取消评价体系

如果每个人都只能对别人说别人欲（喜欢）听的话，那么世界上就不存在批评、纠正、警告。
法官不能判刑，医生不能下病危通知书，父母不能管教孩子。这句话作为开脱工具的终极表现，就是消解了一切是非对错的标准，只剩下情绪价值

3.2 消灭多样性与异见

为什么我说「你可以用这句话逃避任何别人表达的事物」？因为别人的表达，只要不符合你的心意，你就可以认为对方在「施」

比如别人向你分享一本书，一种不同的生活方式，你不想了解，你就可以说「己所不欲勿施于人，别给我洗脑」
它实际上变成了拒绝接受任何新事物、新观念的挡箭牌，让一个人彻底困在自己的信息茧房里

3.3 绝对相对主义

它把人与人之间的互动，切割成了互不相干的孤岛。潜台词是：「你的事我不管，我的事你也别管」
这就逃避了人作为社会动物必须承担的互相协作、互相监督的责任

4. 案例分析

接下来我们回到开头的实际案例，看看这句名言是如何被用来强行中止理性讨论并完成主客观偷换的

4.1 核心偷换

这个案例中最致命的逻辑谬误，就是主客观偷换

我评估不用 Edgeone 的核心论点包含了客观的技术判断： 一个存放静态页面的 Blog，传统的 CDN（如 Cloudflare Pages）在最佳实践上已经完全足够。Edgeone 提供的 L3/L4 防护功能，对于一个内容载体来说是架构上的过度设计

• 这是一个基于技术最佳实践、成本收益比、系统架构合理性的客观探讨

而路人直接无视了我关于L3/L4 防护、静态页面的技术讨论，把你的决定唯一归结为：因为你不在乎国内受众（你的主观处境），所以你不喜欢/不需要（你的主观情绪）
他抛出「己所不欲勿施于人」，潜台词是：「这仅仅是因为你个人用不上罢了，对别人还是有用的，你不要把你的主观喜好当成客观真理去否定它」

为什么说主客观偷换？他利用这句话，把我关于「技术最佳实践」的客观评判，瓦解成了「反正你用不上所以你才说它不好」的主观偏见。这就彻底抹杀了讨论技术合理性的空间

4.2 虚空锁敌

其次就是这句话的防御机制启动得非常虚空锁敌，这也体现了为什么这句话是怎么被无脑滥用的

我们回顾下起因，这是 A 主动问你「为什么不用 Edgeone Page」
我是在回答问题，陈述自己的技术选型理由
我仅仅是在表达「我为什么不用」，根本没有说「你们都不准用」或者「用 Edgeone 的都是低能」。我没有向任何人施加任何东西
但路人抛出「己所不欲勿施于人」，立刻就给我扣了个大帽子：你在用自己的标准绑架别人

你看，这句话的开脱威力就在这里：只要你表达了一个带有否定性质的观点（我不喜欢/我不用），对方就可以用这句话把你打成一个 试图把个人意志强加给别人 的独裁者

4.3 万能和稀泥

我们常说技术讨论要有极客精神，而「己所不欲勿施于人」在很多时候是极客精神的死敌

按照他的的逻辑：对你没用，对有国内受众的人有用
这句话听起来无比正确、无比包容，但实际上是一句毫无营养的废话。如果顺着这个逻辑：

• A 问：为什么不用拖拉机去上班？
• 你答：因为没必要，速度太慢，我开车去
• 路人：己所不欲勿施于人，你不需要下地干农活，但对农民是有用的

完全忽略了具体场景下的合适度，脱离了现实场景
即使有人需要国内受众，对于一个写 Blog 的静态页面，Edgeone 的 L3/L4 防护依然是没必要的，依然是大炮轰蚊子，甚至蚊子在哪都不知道

这个案例中，路人营造了一种万物皆有理，存在即合理的假象，和了一手好稀泥，把原本可以深入探讨的「CDN与高防节点的合理使用场景」，变成了一碗毫无意义的互相尊重主观差异的鸡汤

5. 正本清源

现在我们就要讨论一下「己所不欲，勿施于人」这句话的原本意思了。

:::tip[原义] 「己所不欲，勿施于人」出自《论语》（在《颜渊》和《卫灵公》两篇中都有出现），它是孔子儒家思想中最核心的概念之一——「恕」道 :::

如果我们剥离掉后人强加给它的防御属性，还原到两千五百多年前孔子说出这句话的语境中，它的原义其实极其高尚，甚至是对人性要求极高的一种自我修行

5.1. 推己及人

在《论语·卫灵公》中，子贡问孔子：「有没有一个字，可以让我终身奉行？」
孔子回答：「那就是恕吧！己所不欲，勿施于人」

这里的恕，在古汉语中是「如心」的意思，也就是「将心比心」
孔子的原义是：你要把自己的感受，当作理解他人感受的尺子。

因为人类的情感是相通的，你感到痛苦、屈辱、厌恶的事情，别人大概率也会感到痛苦、屈辱、厌恶。因此，在你对别人做出某个行为之前，先在心里演练一遍：如果别人对我这样做，我受得了吗？如果受不了，那就立刻停止你的行为

这其实是人类文明史上最早最精炼的同理心教育

5.2. 向内求

正如我们前面探讨的，这句话被当作开脱工具时，主语被偷换成了「别人」。但在孔子的原义里，这句话的主谓宾构成了自我约束机制

• 己所不欲：我首先要觉察自己的内心，知道什么是恶的、痛的
• 勿施于人：这是一种绝对的自我命令。重点在勿字，意思是我绝对不能去干这件事

孔子是把这句话作为君子的标准提出来的。君子是要求自己的，小人才去要求别人。所以，这句话在原义上，绝不是一把刺向别人的长矛

5.3 银律

在世界伦理学史上，「己所不欲，勿施于人」被称为道德的银律
与之相对的，是基督教中《马太福音》的金律：「你们愿意人怎样待你们，你们也要怎样待人」（己所欲，施于人）

对比之下，你会发现孔子的原义中蕴含着极深的边界感和克制：
孔子没有鼓励我们「己所欲，施于人」（因为你喜欢的东西，别人未必喜欢，强加给别人也是一种灾难，比如逼婚）
孔子只划定了一条消极的道德底线：『不欲」的东西，绝对不给别人
它承认了人与人之间的差异，强调不伤害是人际交往的第一原则

5.4 忠道结合

只看「己所不欲勿施于人」，会觉得儒家好像很被动很消极。但其实这句话在孔子的体系里只占了一半

孔子的核心思想是忠恕之道

• 消极底线是恕：己所不欲，勿施于人（我不想要的，我不塞给你）
• 积极追求是忠：己欲立而立人，己欲达而达人（我想要站得住脚、想要通达成功，我也去帮助别人站得住脚、通达成功）

把这两句放在一起，才是它完整的原义：不把痛苦转嫁给别人，同时把成长的力量分享给别人

看完原义，我们就能更强烈地感受到，我所说的开脱现象是多么讽刺：

• 孔子的原义，是为了打破人的自我中心，让人看到他人的痛苦，从而限制自己的行为（这是一种无私）
• 被异化后，是为了加固人的自我中心，让人只看重自己的感受，从而拒绝外界的指正（这变成了一种极度的自私）

这八个字本身是极其伟大和深刻的。但语言的悲哀就在于此：当最高尚的道德箴言，落入趋利避害、逃避责任的人性弱点中时，它不仅会失去原本的光芒，反而会变成保护自私的最强装甲，那么接下来，我们不妨设想下，如果每个人都以这种态度互相攻击，社会会变成什么样子

6. 推演

• A： 为什么不用 Edgeone Page？
• 我：答案是没必要，我不在乎国内用户，而且纯静态博客没必要在 L3/L4 防护上浪费时间，套一堆有的没的那是拼赛博积木
• 路人：己所不欲，勿施于人。你的受众不在国内，你不需要，对你是没用的，但对有国内受众的人是有用的
• 我：己所不欲，勿施于人。我极其厌恶这种过度设计，你凭什么要求我承认它对别人有用？
• A：己所不欲，勿施于人。我只是好心提个建议问一句。如果你向别人提问，你也不想被当成低能吧？
• 路人：己所不欲，勿施于人。各位肯定不喜欢这种充满攻击性和戾气的沟通环境。
• 我：己所不欲，勿施于人。我讨厌的就是讨论技术问题时被别人道德绑架，不看客观事实只谈主观情绪
• 管理：别吵。己所不欲，勿施于人。我不想看你们在这儿嗷嗷叫。既然我不想看，那就勿施于我（全体禁言）

推演完我们可以总结出，如果一个环境普遍盛行这种道德绑架式的逻辑，会产生三个极其可怕的后果：

1. 何谈事实？ 我原本在讨论 L3/L4 代理对于静态页面的冗余性。这是一个可以被量化，被验证的技术命题 但当这句话进场后，再也没有人关心技术了
   Edgeone 好不好用，CDN 怎么配置不再重要，所有人的焦点都变成了：你的态度让我不爽，你没照顾我的情绪，你在否定我的价值。客观世界被主观情绪彻底淹没

2. 一起套受害者叙事 每个人都在强调自己的不欲：

• 路人：我不欲看到绝对的评判
• 我：我不欲看到垃圾的架构
• A：我不欲被当成小白嘲讽 因为每个人的不欲不同，所以每个人都觉得自己是受害者，都在指责对方是施加者。这就形成了一个死循环：只要我不开心，就是你在对我施
  沟通变成了比惨和比拼谁的道德更高尚

1. 语言通胀 当任何一句话都可以被解读为强加于人时，人类就失去了交流的可能 你指出一个错误，是施于人；你分享一个经验，是施于人；甚至你为了自保而反驳，也是施于人。最终的结局就是社会陷入绝对的虚无主义

7. 如何应对

我认为人的感性占比是比理性大的，面对这种按闹分配的逻辑，我们应该做到足够理性，不被对方用情绪与道德泥潭绑架，而是拉回到客观事实与逻辑上的较量。我们刚才的案例中其实我已经演示了这种做法

当对方用「你喜不喜欢/你需不需要」来掩盖「事物本身对不对/好不好」时，你要做的就是立刻切割

欲（欲望/喜好）是主观的，但我们现在讨论的是客观规律/技术规范/事实

:::tip[eg] 我不用 Edgeone，不是因为我dislike，而是从技术架构（客观）来看，纯静态博客套 L3/L4 防护就是脱裤子放屁（过度设计）。这和受众在哪里无关，这是技术常识 :::

我们遇到这种万能开脱工具，人很容易因为对方占据了道德高地而产生短暂的语塞或自我怀疑，不用害怕，当他抛出「己所不欲勿施于人」，本质上是在对你叫停
他发现自己在客观逻辑的战场上打不过你了（他根本不懂技术/客观事实），所以他试图在道德上遏制你来杀死比赛

8. 结

经过这一番解构，我们终于看清了这句千古名言在现代语境下是如何被异化为帽子工厂和万能盾牌的

真正的「己所不欲，勿施于人」，是孔子交给君子的一面镜子，用来照向自己，以此克制私欲，修身养性
而被滥用的「己所不欲，勿施于人」，是懦夫的一把消音器，用来指向别人，以此逃避现实，拒绝真相

当客观的技术讨论、严谨的逻辑辨析，统统都要给廉价的所谓「主观感受」让路时，我们失去的不仅仅是一个更优的方案，而是整个社会纠错与进化的能力

所以，下次当你再听到有人试图用这句话来终结事实讨论时，请不要怀疑自己，更不要退缩。识破对方的道德陷阱，用逻辑驳回他

因为在这个充斥着情绪泡沫的世界里，捍卫客观逻辑，才是对他人的智商和时间最大的尊重，**这，或许才是我们作为计算机行业从事者眼中真正的「己所不欲，勿施于人」

1. 为什么现在机台还是偶尔断网

直入主题，各位可能遇到过这种情况，机台莫名其妙断网，成绩也没存上，打开舞萌状态查询网站一看服务器还活着。为什么呢？其实就是机台吞cookie了

2. 什么是吞cookie？

简单来说，停服维护后，服务器新增了一个cookie(也称作饼干)作为账号验证的辅助手段。上机的时候服务器会给机台一个cookie，下机的时候要带着这个cookie一起才能成功登出。但是，有些时候因为服务器的某种原因(bug?)导致没有成功下发cookie，但是这时候账号已经登入了，这就是吞cookie，由于没有cookie，自然也没办法登出账号，所以你就小黑屋了。

:::tip[如果你还是听不懂] 我们把cookie当作地铁车票，你一般进站要车票对吧，出站也要同样的票才能出去。

吞cookie的情况就是，进站的时候没票过了闸机，出站的时候没票出不去，你的舞萌账号被困地铁站了(进小黑屋了) :::

如果是因为吞cookie导致的断网，直接要求机厅相关人员重启机子最简单有效，你也可以在允许的情况下扣滴蜡熊后面的开关重启

这个其实算bug，按理该日本人修

3. 为什么「稳定性更新」后仍不稳定

原因是多方面的，事实上，在经过停服维护后，国服的账号校验机制比国际服安全多了。本质上1.53是针对账号进行的升级优化。

吞cookie原因在哪我们无从得知，毕竟舞萌架构是运行了许多年的老屎山，日本人能给你改成这样其实还行了。本来就是插着一堆管子的肺癌晚期老头，你非要给人家动手术，人家死手术台上咋办

4. 关于华立购买服务器防护措施

事实。华立确实买了腾讯云的Edgeone服务来防护恶意流量攻击，你偶尔打开公众号的时候可能会弹出来个edgeone的字样不让你访问，这种情况其实就是你被误认为恶意程序了

通俗来讲，华立雇了几个硬汉(意味深)来看着服务器大门，但是你被硬汉误认为是小偷，不让你进

这种其实也没办法，并不能一刀切归咎于腾讯云或者华立，本身就是一个难以解决的技术性问题

5. 为什么最近公众号老是炸

这个确实原因不明，我的建议是等官方消息(但按华立作风应该是装死 猜的)

6. 什么是舞萌小黑屋

舞萌账号每一次登入都要严格对应一个登出，而正常游玩情况下只有过了结算之后才会一次性上传所有成绩并执行登出操作，如果没有成功登出，此时账号就会被占用无法正常游玩，机台会提示一个十五分钟的弹窗，故称为小黑屋

7. 关于舞萌解黑屋以及为什么现在解不了

我可以负责任的说，截至到目前，没有任何办法解开小黑屋，此前已有的解黑屋手段全部失效。
之前服务器登出账号，只需要知道你登入的时间即可，现在需要cookie等信息验证

:::tip[打个比方] 原来解小黑屋，是在出站的时候挨个猜你进站的时间，猜对了就出去了

现在地铁出站需要额外检票，但是你票他没给你发啊，这就困里面变小黑屋了 :::

8. 结

看完本文，您也大概对近期舞萌的各种问题有了大致的了解。作为玩家，不知道啥问题就断网了生气骂人很正常嘛，本文也是为了解决您的疑惑才写的，有疑问也可以在评论区再提。不过咱还是希望各位平时多关注下自己，毕竟只是个游戏，娱乐用的，不必把他的地位放在主要生活之上。

当然，也祝各位新年快乐，工作顺利，学业有成，身体健康开开心心总归是第一位

9. 附

这里顺便也声明一下吧，本人(Chongxi)并没有与任何第三方组织合作过，同时咱也没有任何商业行为。无论是写blog还是做工具，我仅仅只是一位稍微懂点计算机技术想给社区为爱发电而已，大家总归都是热爱这个游戏的，没必要因为这些而吵架吧

咱的舞萌服务器状态工具：华立服务器死了吗?

0. 引

0.1 Only screen is real

我们常把互联网比作冰山，在冰山之下，数以万计的交换机/服务器/数据库在轰隆作响

而对于屏幕前的用户，某个拿着手机坐在地铁里的人，或者坐在办公桌前盯着显示器的白领而言，只有屏幕上的像素点是真实的

如果那个"commit"按钮点下去没有反应；如果那个列表滑动起来一卡一卡；如果那个页面在加载时白屏
那么，无论后端的架构多么优雅，算法多么精准，对于用户来说，这就是一个 垃圾软件

在很长一段时间里，前端被戏称为切图仔
在软件开发的鄙视链中，前端曾经往往处于底端
后端工程师认为前端只是写写 HTML 标签、描描样式，不需要懂内存管理，不需要懂并发控制，甚至不需要懂真正的编程语言。

然而，这三十年的历史证明了这种偏见的荒谬。前端开发正在经历计算机科学史上最剧烈，最残酷的演变。我们从最初仅仅是为了展示一篇物理论文，演变到现在要在浏览器这个沙盒里运行 Photoshop、3D 游戏、甚至是 IDE

本篇blog要讲的，不是 API 的流水账，而是这三十年来前端的「三国演义」

观前提醒：本文是以我的个人视角叙述，难免有误，还请各位谅解/多多指出错误。

0.2 原罪

要理解前端这三十年为什么这么闹腾，为什么框架层出不穷，为什么工具链复杂到让人头秃，我们必须回到原点，去审视 Web 诞生的初衷

WWW 在 1990 年诞生时，Tim Berners-Lee 爵士的设计目标非常纯粹：为了让科学家们方便地共享文档

请记住文档这两个字。这是前端所有痛苦和复杂的根源，也是我认为的原罪

• HTML 是用来描述文档结构的
• HTTP 是无状态的协议，以此请求文档，拿完就走，不保持连接
• 浏览器 只是一个文档阅读器

随着商业化的爆发，人类越来越想要更多。我们要的不再是一张静态的纸，我们要的是一个App

• 我们要在这个文档阅读器里做Chat
• 我们要在这里做交易所
• 我们要在这里协同编辑 Excel
• 我们要在这里看 HDR 视频

这就好比要求你在 Microsoft Word 里开发一个 Minecraft

前端这三十年在做的事情，本质上就是：
利用一系列原本为静态文档设计的简陋技术，通过各种奇技淫巧，强行构建出媲美原生操作系统软件的动态应用

• 因为 HTTP 无状态，所以我们发明了 Cookie 和 Session，后来又搞出了 JWT
• 因为 HTML 每次点击都要刷新整页，体验太差，所以我们发明了 AJAX，强行把网页变成了 SPA
• 因为 DOM 操作太慢，所以我们发明了 Virtual DOM，在内存里算好了再去碰真实的 DOM
• 因为 JavaScript 诞生时没有模块系统，所以我们发明了 CommonJS, AMD, UMD, 最终逼出了 ES Modules

前端的演进史，就是一部与浏览器的对抗史。我们在对抗浏览器的限制，对抗网络的延迟，对抗设备的碎片化

0.3 轮回

在读本Blog时，你会发现一个非常有趣的现象：技术的轮回

• Web 1.0：网页是服务端渲染的。PHP/JSP 在服务器把 HTML 拼好，浏览器直接展示。那是静态的极致
• Web 2.0：为了交互体验，我们把逻辑全搬到了浏览器。浏览器成了客户端，服务器只吐 JSON 数据。这是动态的极致
• Now：为了首屏速度和 SEO，我们发现客户端渲染太慢了。于是，Next.js 和 Nuxt 又出现了

人类绕了一圈，似乎回到了原点？

不

当年的静态，是因为我们做不到动态
现在的静态，是因为我们掌握了动态之后，为了极致体验而做出的主动选择

0.4 谁是前端？

在 2000 年，只要会写 <table> 布局和 <font> 标签，你就是前端（那时候其实叫网页设计师）
在 2010 年，只要你会用 jQuery 的 $('#id').click()，你就是前端 现在，你需要会Ts，即时编译，HTTP/3，服务端容器化等等

前端的边界在无限扩张。
向上，我们在侵蚀后端的领地推出Serverless（尽管现在不尽人意）
向下，我们在通过 WebAssembly 调用 C++/Rust 的能力
向外，我们在通过 React Native / Flutter 构建原生App

但无论技术栈如何变迁，有一点我希望阅读本文的前端开发者记住：

我们是离用户最近的人

1. 最初的起点

1.1 蒂姆·伯纳斯-李的拼图

一切的起点，并不宏大。没有风险投资，没有 IPO，甚至没有想改变世界

1989 年，蒂姆·伯纳斯-李（Tim Berners-Lee）在 CERN 工作时，面临着一个非常具体的痛点：物理学家们的论文和数据太难找了。它们分散在不同的计算机上，格式各异，如果你想引用别人的研究，只能手动去查

于是，他提出了一个构想：World Wide Web

为了实现这个构想，他拿出了三块拼图，这三块拼图至今仍是互联网的基石：

1. HTML：一种简单的标记语言，用来描述文档的结构（标题、段落、列表）。这里你要注意的是，它只负责结构，不负责好看
2. HTTP：一种无状态的传输协议。你请求一个文档，服务器给你，然后连接断开。这种阅后即焚的特性决定了 Web 最初只是一个图书馆，而不是「操作系统」
3. URL：给世界上的每一个文档分配一个唯一的地址

1990 年圣诞节，他在那台 NeXT 电脑上写出了世界上第一个浏览器和第一个服务器

那时的网页长什么样？
Only text 只有白纸黑字和蓝色的超链接。图片还需要弹出一个新窗口才能看

这时候的前端开发，和写word没什么区别。你只需要掌握 <h1>、<p>、<a> 这几个标签就够了。这是一个Read-Only的时代

1.2 Table 与 Spacer GIF

随着 Mosaic 浏览器的发布（第一个广泛流行的图形化浏览器），图片终于可以和文字混排了。商业公司开始入驻互联网，设计师们带着平面设计的思维来了

炸了

设计师说：我要在这个角落放个 Logo，在大标题下面分三栏排版，右边还要有一个Guide
工程师看着简陋的 HTML 说：把哥们当日本人整呢

当时的 HTML 只有文档流。没有 Float，没有 Position，更没有 Flexbox

怎么办？聪明或者说被逼无奈的开发者们发现了一个漏洞：HTML 里有一个用来展示数据的标签<table>，也就是表格

如果你把边框设为 0 (border="0")，表格线不就看不见了吗？
如果你在表格里套表格，不就可以切分出复杂的版块了吗？

于是，表格布局时代开始了

• 切图仔诞生：设计师在 Photoshop 里把一张精美的网页设计图切成几十个小豆腐块，然后前端工程师用一个巨大的 <table> 把它们拼回去
• 嵌套地狱：为了实现一个圆角框，你可能需要一个 3x3 的表格，四个角放圆角图片，中间放内容。如果内容里还有布局，那就再套一个表格。代码看起来像是一个巨大的迷宫
• Spacer GIF：这是那个时代最伟大的「黑客技术」
  • 表格单元格有时会塌陷，或者你想要精确的 10px 间距，怎么办？
  • 你制作一个 1x1 像素的透明 GIF 图片
  • 然后写上 <img src="spacer.gif" width="10" height="1">
  • 你看不到它，但它撑开了空间

这是前端工程史上第一次大规模的为了目的不择手段。虽然代码语义极差，维护极其困难（改一个字可能导致整个表格崩塌），但它让网页第一次有了设计感

1.3 JavaScript 的急就章

1995 年，Netscape 正处于第一次浏览器大战的风口浪尖。他们面临一个巨大的压力：让网页动起来

当时的痛点非常低级：表单验证
那是拨号上网的年代，网速慢得令人发指。用户在网页上填完一个长长的注册表单，点击提交，数据传到服务器，服务器发现用户名为空，再把页面传回来告诉用户报错。这一来一回，可能要几十秒甚至一分钟。用户直接炸了

网景觉得，必须有一种脚本语言，能直接在浏览器里检查表单，不需要经过服务器

这个任务交给了 Brendan Eich

• BOSS的需求：一定要像 Java（Java 当时如日中天，网景想蹭热度
• Brendan 的私心：他其实想把 Scheme 或者 Self 搬进浏览器。他喜欢函数式编程
• 结果：为了赶在 Netscape Navigator 2.0 发布前上线，他只用了 10 天

这门语言最初叫 Mocha，后来改名 LiveScript，最后在发布前夕，为了营销，改名为 JavaScript

这就是后来无数人吐槽 JS 的根源：

• 它名字里有 Java，但跟 Java 没有任何关系
• 它的语法像 Java，骨子里却是函数式语言
• 它的设计充满了仓促的妥协：
  • null 和 undefined 同时存在，甚至 typeof null === 'object' 这种著名的 Bug 被保留至今
  • 自动分号插入带来的莫名其妙的报错
  • 极其宽松的类型转换（[] + [] = ""）

它被设计为一个玩具语言，仅仅用来做一些鼠标滑过图片变色、弹出 alert 对话框、检查输入框不为空的小把戏

当时的专业程序员 （比如写Java的） 对 JavaScript 是嗤之以鼻的。他们认为这不是编程，这是脚本片段

但潘多拉盒子已经打开了

哪怕它再简陋，它赋予了浏览器逻辑计算的能力
有了逻辑，网页就不再只是文档，它开始向app进化

那时的前端，就在这一堆乱七八糟的表格标签、透明图片占位符、以及几行简陋的脚本验证代码中，跌跌撞撞地开启了 Web 的商业化时代

而就在不远的前方，一个名叫 Microsoft 的巨头马上就要睡醒了

2. 第一次浏览器大战

2.1 巨头的坠机

1996 年，Netscape Navigator 占据了近 80% 的市场份额。那时的浏览器是收费软件（或者说是共享软件），它是通往互联网的唯一大门

但比尔·盖茨醒了。他发出了那封著名的《互联网浪潮》备忘录，微软这艘航母开始全速掉头

微软采用了经典的Embrace, Extend, Extinguish战略：

1. 拥抱：微软买下了 Spyglass Mosaic 的授权，改造出了 Internet Explorer
2. 扩展：为了差异化竞争，双方开始疯狂地往 HTML 里塞私货
   • Netscape 发明了 <layer> 标签和 <blink>（闪烁文本，我认为是史上最烦人的标签）
   • 微软发明了 <iframe > 和 <marquee>（滚动字幕）
   • Netscape 用 document.layers 操作元素，微软用 document.all
   • 结果开发者必须写大量的 if (document.all) { ... } else { ... }。这就是浏览器嗅探代码的鼻祖
3. 毁灭：微软祭出了核武器：免费捆绑。IE 被预装在 Windows 95/98 里。网景唯一的收入来源断了

1998 年，网景惨败，被 AOL 收购。但在临死前，他们做出了一个改变历史的决定：开源（噔 噔 咚）

他们把 Netscape 混乱的代码全部扔给了社区，成立了 Mozilla。这颗种子在地下埋藏了许多年，终长成名为 Firefox 的大树

2.2 IE6：帝国的荣光与坠机

2001 年 8 月，Windows XP 发布，随之而来的是 Internet Explorer 6.0

我们需要客观地评价这位昔日的王者。在 2026 年回看 IE6，它是落后、各种 Bug、不安全的代名词。但在 2001 年，IE6 是当时世界上最先进的浏览器，没有之一（毕竟不能拿现在的眼光审视过去）

• 它是最好的 CSS 渲染器：相比之前的版本，它对 CSS1 的支持已经算不错了（虽然有著名的盒模型 Bug）
• 它是最快的 JS 引擎：那时候的 V8 还在娘胎里
• 它带来了 AJAX 的火种：ActiveXObject("Microsoft.XMLHTTP") 正是随 IE5/6 引入的

IE6 迅速占据了 95% 的市场份额。微软赢了，于是他们解散了浏览器团队（笑死）
Web 的时间停止了

从 2001 年到 2006 年，整整五年，浏览器技术没有任何实质性的进步。这五年我称为Web 的黑暗中世纪

对于前端（这时候开始有专职的前端了），这五年是与 Bug 搏斗的五年：

• 盒模型 Bug：标准说 width 是内容宽度，IE6 说 width 是包含边框的宽度。于是我们学会了 CSS Hack：_width: 200px;（只有 IE6 认识下划线开头的属性）
• PNG 透明问题：IE6 不支持 PNG-24 的半透明，看到的都是灰色背景。我们被迫写滤镜代码 (AlphaImageLoader) 或者继续用 GIF
• 双倍边距 Bug：浮动元素的 margin 会莫名其妙加倍。解决办法？display: inline

我们不再是构建者，而是修东西的。前端开发的门槛变成了一门玄学，你必须背诵几十个 IE6 的怪癖才能写出一个正常的页面

2.3 DHTML 与 Flash

在 HTML/CSS 停滞不前、标准分裂的年代，人类对动态交互的渴望并没有消失。这种渴望在两个方向上找到了出口

2.3.1 DHTML

DHTML (Dynamic HTML) 不是一个标准，而是一个营销词汇
它指的是：利用 JS 修改 CSS 属性，让静态的 HTML 动起来

那是特效的年代

• 网页上会有跟随鼠标飘动的文字轨迹
• 导航菜单展开时会有弹跳效果
• 状态栏会有跑马灯文字

大部分前端并不会写 JS，他们是脚本搬运工。他们去 DynamicDrive.com 这样的网站，复制一段几百行的 JS 代码，粘贴到网页里，然后改改参数。JS 在当时被视为一种装饰品，一种让网页看起来很酷（或者很杀马特）的玩具

2.3.2 Flash

既然 HTML 这么烂，不同浏览器渲染还不一致，那为什么不跳出浏览器呢？

Macromedia Flash（后被 Adobe 收购）横空出世
它实际上是一个浏览器里的虚拟机

• 一致性：不管你是 IE 还是 Netscape，只要装了 Flash 插件，效果完全一样。这是对兼容性地狱最有力的反击
• 多媒体：它能播放视频、音频（当时 HTML 做不到）
• 矢量绘图：它能做无损缩放的动画（当时没 SVG 的事情）
• 强大的语言：ActionScript。当 JS 还在处理表单验证时，ActionScript 2.0/3.0 已经是完全面向对象的语言了，有类、继承、接口

在那个年代，最顶级的前端工程师其实是 Flash Developer。他们做出了开心农场，做出了视频网站（土豆/优酷的早期播放器），做出了极其华丽的企业官网

Flash 是 Web 2.0 真正的前奏
它证明了网页可以不仅仅是文档，而可以是游戏、电影和复杂的应用
但它是一个黑盒子。搜索引擎看不懂它，移动设备（后来的 iPhone）跑不动它

就在这看似无解的僵局中，Web 正在酝酿一场真正的革命
而在遥远的CA，Google 正在悄悄重写 Gmail 的代码，准备用 IE6 那个被遗忘的 XMLHTTP 接口，给世界一点小小的震撼

3. 网页开始呼吸

3.1 Gmail 的震撼

2004 年愚人节，Google 发布了 Gmail。当时所有人以为这是个笑话，因为它提供了 1GB 的免费存储空间（当时主流邮箱只有 2MB）

但真正让极客们震惊的不是容量，而是体验

在此之前，网页交互的模式是同步的：

1. 用户点击下一页
2. 浏览器白屏
3. 服务器生成新的 HTML
4. 浏览器重新渲染整个页面

而在 Gmail 里，当你点击邮件标题时，网页没有刷新。列表保留在左边，邮件内容瞬间出现在右边。
这种体验太像原生app了，以至于很多人怀疑 Google 用了 Flash 或者 Java Applet

并没有 他们用的是纯正的、原生的、被微软遗忘在角落里的技术 XMLHTTP

• 这项技术是微软在 1999 年为了 Outlook Web Access 开发的，随 IE5 发布。但微软自己没重视它，把它当成一个不起眼的 ActiveX 控件
• Jesse James Garrett 的命名：2005 年，这位 UX 设计师写了一篇著名的文章，将这种“无需刷新页面就能与服务器通信”的技术统称为 AJAX (Asynchronous JavaScript and XML)

从此，网页有了后台线程
它可以在你不注意的时候，悄悄去服务器拿数据。网页开始呼吸了

3.2 JSON 一种偶然的标准

AJAX 中的 “X” 代表 XML。在当时，数据交换的标准格式确实是 XML
但是，在 JavaScript 里解析 XML 简直是灾难。你得写一堆 getElementsByTagName，代码冗长且慢

这时候，一位名叫 Douglas Crockford 的雅虎架构师站了出来
他发现 JavaScript 有一种原生的数据表示法——对象字面量

// XML
<user><name>Chongxi</name><age>23</age></user>

// JSON
{ "name": "Chongxi", "age": 23 }

Crockford 甚至没有发明它，他只是发现了它。他把这种格式命名为 JSON

• 它天生就是 JS 对象，解析极其简单（早期直接用 eval()，虽然不安全）
• 它比 XML 轻量得多（少了那么多尖括号，节省带宽）

这是 Web 历史上最四两拨千斤的胜利
由于前端开发者的极力推崇，后端工程师发现生成 JSON 也比生成 XML 容易。于是，AJAX 里的 “X” 名存实亡，JSON 统治了世界

3.3 Firebug

在 2006 年之前，调试 JS 的唯一工具是： alert('Here 1'); alert('Variable x is: ' + x);

开发者像瞎子一样摸索。如果代码出错了，IE 只会左下角报一个黄色感叹号，告诉你缺少对象，行号永远是不准的

2006 年 1 月，Joe Hewitt 发布了 Firefox 的插件 Firebug

• 它能审查元素：鼠标指哪，高亮哪。上帝啊，我们可以直接在浏览器里改 CSS 看效果了
• 它有控制台 (Console)：console.log() 终于取代了 alert()
• 它能断点调试
• 它能抓包

Firebug 是前端工程化的第一块基石 它让前端开发从玄学瞎猜变成了科学观测

4. Write Less, Do More

4.1 救世主

虽然有了 AJAX，有了 Firebug，但前端开发依然极其痛苦 痛点在于：碎片化

• 要获取一个元素：
  • 标准浏览器：document.getElementById
  • 如果要按 Class 获取：IE6 不支持 getElementsByClassName。你得自己写循环去遍历 DOM
• 要绑定事件：
  • 标准：addEventListener
  • IE：attachEvent
• 要获取计算后的样式：
  • 标准：getComputedStyle
  • IE：currentStyle

每个前端工程师的电脑里都有一个 utils.js，里面存着几百行用来处理兼容性的脏代码

2006 年 8 月，John Resig 在 BarCamp NYC 上发布了 jQuery
它的核心理念极其简单粗暴：把所有浏览器差异藏在 $ 符号后面

4.2 链式调用的艺术

jQuery 发明了一种极具表现力的 API 风格——链式调用

以前的代码：

var div = document.getElementById('CEPATO');
div.style.color = 'red';
div.style.display = 'block';
div.onclick = function() { alert('clicked'); };

jQuery 的代码：

$('#CEPATO').css('color', 'red').show().click(function() {
    alert('clicked');
});

• Sizzle 引擎：这是 jQuery 的核心。它让 JS 可以像 CSS 一样选择元素（div > ul.list li:first-child）。这在当时是黑科技
• 隐式迭代：$('.item').hide() 会自动隐藏页面上所有的 .item，不需要写 for 循环

jQuery 迅速成为了事实标准。甚至微软后来都在 Visual Studio 里内置了 jQuery 的智能提示

4.3 copycat 黄金时代

jQuery 的另一个伟大之处在于它的插件机制 ($.fn.extend)
这开启了前端最早的组件化雏形

• Lightbox：点击图片，背景变暗，图片放大
• Carousel：轮播图
• Datepicker：日期选择器

无数不懂 JS 原理的切图仔，靠着下载 jQuery 插件 + 改 CSS，就能拼凑出一个交互丰富的网站
jQuery 极大地降低了前端门槛，但也埋下了祸根： 大量的面条代码和滥用的 DOM 操作，导致页面性能越来越差

5. 引擎的军备竞赛

5.1 Speed

随着 AJAX 和 jQuery 的普及，网页里的 JS 代码量指数级增长
从几百行，变成了几千行，甚至几万行…然后

浏览器跑不动了

当时的 JS 引擎都是解释执行的：读一行，跑一行。效率极低
Web 应用想取代桌面软件，最大的瓶颈就是慢

5.2 Google 的阳谋

2008 年 9 月，Google 发布了一本漫画书，介绍了一款新浏览器：Chrome
与之同来的，是一个全新的 JS 引擎：V8

V8 做了一件惊天动地的事：JIT
它不解释代码，它是把 JavaScript 直接编译成机器码运行

• V8 刚发布时，JS 执行速度比 IE 快了不知道多少倍
• 多进程：一个标签页崩了，不会导致整个浏览器崩溃。这也是 Chrome 的首创

V8 的出现改变了一切

• 它证明了 JS 可以跑得飞快
• 它让 JS 有能力处理极其复杂的逻辑（不仅仅是表单验证）
• 既然 V8 这么快，而且它是独立的 C++ 库，那为什么不能把它拿出来，在服务器上跑 JS 呢？（而一年后，Node.js 诞生了）

5.3 WebKit

与此同时，Apple 开源的 WebKit 内核（源自 KHTML）开始崛起。Safari 和早期的 Chrome 都使用了 WebKit
它是移动互联网的基石。第一代 iPhone 发布时，乔布斯不支持 Flash，只支持 Web 标准
这意味着，即将到来的移动 Web 浪潮，将是 WebKit 的天下…吗？

至此，前端已经拥有了：

1. 交互能力
2. 数据标准
3. 开发工具
4. 标准库
5. 高性能引擎

万事俱备
但随着代码量的膨胀，我们即将迎来一场巨大的危机
我们有了枪炮，但还缺乏战术。我们写得出炫酷的特效，但维护不了庞大的系统

接下来咱就要讲工程化与架构革命，Node.js 登场，前端终于要开始像正经的软件工程师那样思考了

6. Nodejs

如果说前二十年，前端还是在浏览器这个沙盒里带着镣铐跳舞，那么从 2010 年开始，前端工程师通过一次惊天动地泣鬼神的越狱，彻底改变了游戏规则

6.1 Ryan Dahl 的疯狂实验

2009 年的 JSConf EU 大会上，一个名叫 Ryan Dahl 的年轻人做了一场演示

他做了一件看似违背祖宗的事情：他把 Google Chrome 里的 V8 引擎抠了出来，给它装上了文件系统和网络模块，让它跑在了服务器上

这就好比把法拉利的引擎拆下来，装在了一台拖拉机上

这个项目叫 Node.js

起初，大家以为它是后端技术的革命（非阻塞 I/O，高并发）
但很快，前端工程师们发现了一个惊天秘密：补兑，既然服务器能跑 JS，那是不是意味着，我们可以用 JS 来写…

在此之前，如果你想压缩一个 JS 文件，你得用 Java 写的 YUI Compressor
如果你想预处理 CSS，你得用 Ruby 写的 Sass
前端开发者的工具链掌握在别人手里

Node.js 的出现，让前端拥有了造轮子的权利

6.2 npm

2010 年，Isaac Z. Schlueter 发布了 npm

在这之前，如果我们想用 jQuery，得去官网下载 jquery.js，放到项目文件夹里，然后在 HTML 里写 <script src="jquery.js">。如果 jQuery 依赖了别的库，你根本不知道，直到报错

npm 改变了一切： npm install jquery

这不仅是一个下载工具，它引入了语义化版本控制 和 依赖树
前端代码不再是散落在各处的碎片，而是变成了一个有组织、可复用的模块体系

6.3 自动化构建：Grunt 与 Gulp

既然有了 Node.js (运行时) 和 npm (包管理)，前端工程师开始编写自动化脚本

• Grunt：基于配置的构建工具。你需要写一个巨大的 JSON 对象，告诉它先把 A 文件和 B 文件合并，然后压缩，然后重命名
• Gulp：基于流的构建工具。代码写起来像管道一样流畅：

  src('src/*.js')
    .pipe(babel())
    .pipe(uglify())
    .pipe(dest('dist/'));
  

这是前端工程化的开端
我们不再手动刷新浏览器，不再手动压缩图片
前端开发从手工进化到了流水线

7. MVC 混战与移动大迁徙

7.1 乔布斯的判决书与 HTML5 的上位

2010 年 4 月，Steve Jobs 发表了著名的公开信Thoughts on Flash
他列举了 Flash 的六大罪状（耗电、触摸屏支持差、封闭等），并宣布 iPhone/iPad 将永远不支持 Flash

这一刻，Web 的命运被改写了
移动互联网的大门轰然打开，而唯一的通行证是 HTML5

于是，所有的企业都需要开发移动版网页
但手机的 CPU 和网络比电脑差得多，屏幕也小得多
简单的 jQuery 特效在手机上卡顿无比。我们需要更高效、更像原生 App 的网页

7.2 意大利面条代码危机

随着需求越来越复杂（比如做一个网页版的 Excel 或 Trello），前端代码量突破了 10 万行
jQuery 的弊端彻底暴露：它把状态藏在了 DOM 里

想象一下，你要做一个购物车

• 用 jQuery：你需要从 span.total-price 里读出文本，转换成数字，加 1，再写回 span
• 如果页面上还有三个地方要显示总价呢？你得手动更新三个地方
• 如果漏了一个怎么办？Bug 就来了

这种面多加水，水多加面的代码，错综复杂，被称为意大利面条代码
一旦项目变大，维护它简直是地狱

7.3 寻找秩序

为了解决这个问题，前端开始向后端偷师，引入了经典的软件架构模式：MVC
核心思想是：数据（Model）是源头，视图（View）只是数据的投影

7.3.1 第一代探索者：Backbone.js

Backbone 非常轻量。它给了你 Model、Collection、View 三个基类

• 它告诉你：把数据存在 Model 里，不要存在 DOM 里
• 当 Model 变了，Model 会触发一个 change 事件
• View 监听到事件，手动去更新 DOM（还是用 jQuery）
• 它建立了秩序，但写起来还是很累，很多胶水

7.3.2 AngularJS (v1

2009 年发布，2012 年爆火。AngularJS 带来了两个震撼世界的概念：

1. 双向数据绑定：

   <input ng-model="username">
   <h1>Hello, {{ username }}</h1>
   

   你在输入框里打字，下面的 <h1> 里的文字实时跟着变
   不需要写任何 JS 事件监听代码 这在当时简直是魔法

2. 依赖注入： 你想要用 $http 服务？只需要在函数参数里写上它，Angular 就自动给你送进来

AngularJS 让 HTML 变成了一种模版语言。它让开发效率提升了 10 倍
一时间，全世界都在用 Angular 重写项目。前端工程师觉得自己终于是在开发软件，而不是在写脚本了

7.4 AMD vs CMD

在 Node.js 和框架爆发的同时，还有一个基础问题没解决：JavaScript 语言本身没有模块系统（直到 ES6）

我怎么在一个 JS 文件里引用另一个 JS 文件？ <script> 标签不仅丑，而且依赖顺序很难管理（jquery.js 必须在 plugin.js 之前）

于是，民间标准诞生了：

• CommonJS：Node.js 用的标准 (require/module.exports)。是同步加载的，适合服务器，不适合浏览器（网络请求要等）
• AMD (RequireJS)：异步模块定义。define(['dep1'], function(dep1) { ... })。它是浏览器端的霸主
• CMD (SeaJS)：淘宝玉伯提出的标准，更符合 CommonJS 的书写习惯（就近依赖）

这不仅是技术之争，也是社区话语权之争

至此，我们完成了工业化的初步积累

1. 我们有了构建工具，开始像正规军一样开发
2. 我们有了MVC 框架，开始分离数据和视图
3. 我们有了移动端市场，地位空前提升

但是，AngularJS 的双向绑定在大规模应用中出现了严重的性能问题
而 FaceBook 的工程师们，正在为一个叫做 Instagram 的应用头疼。他们觉得 MVC 模式在前端也是错的
他们提出了一个更激进的想法：如果视图只是一个函数呢？

8. React 与 范式转移

8.1 JSX 的离经叛道

2013 年，当 Facebook 的工程师 Jordan Walke 开源 React 时，整个社区的反应是愤怒的
甚至有人说：这是把我们过去十年的努力全毁了

Why? 因为 JSX
在过去，最佳实践是关注点分离：HTML 归 HTML（模版），JS 归 JS（逻辑）
React 却说：不，我们要把 HTML 写在 JS 里

React 的核心洞察是：UI 渲染逻辑（事件处理、状态变化）和 UI 展示逻辑（DOM 结构）本质上是紧密耦合的。硬把它们分在不同文件里，只是物理分离，而不是逻辑分离

JSX 不是模版，它是 JavaScript 的语法糖。这意味着你拥有一门图灵完备语言的所有能力（变量、if/else、循环、函数）来描述界面，而不是只能用蹩脚的模版语法（ng-repeat, v-if）

这是一场思维革命：我们不再编写页面，我们在编写组件

8.2 Virtual DOM

React 被骂得最惨的时候，是它的性能拯救了它。 当时 Facebook 遇到了一个难题：在极其复杂的 Feed 流里，如何高效更新消息？
如果是 jQuery，你要手动找哪个 DOM 变了；如果是 Angular 1，它会疯狂地进行脏检查（Dirty Checking），导致页面卡顿

React 提出了 Virtual DOM：

1. 快照：每次状态变了，我都在内存里生成一棵新的虚拟 DOM 树（纯 JS 对象）
2. 对比：我用高效的算法（O(n)）对比新旧两棵树，找出哪怕一个属性的变化
3. 修补：我只把变化的这一点点应用到真实的浏览器 DOM 上

这是数学的胜利
React 甚至不需要知道浏览器的存在。它把渲染抽象成了一个函数：UI = f(State)
只要状态变了，UI 就自动变。开发者再也不用碰 document.getElementById 了。手动操作 DOM 成为历史

8.3 Redux 的苦行僧

React 只解决了 View，那数据怎么办？
Facebook 提出了 Flux 架构，后来Dan Abramov 把它简化为 Redux

Redux 是极其繁琐的：Action, Reducer, Store, Dispatch。改一个字段要写四个文件
为什么我们要这么折磨自己？

因为在大型应用里，可预测性比便捷性更重要

• 单向数据流：数据只能从上往下流
• 纯函数：Reducer 必须是纯函数，同样的输入永远得到同样的输出
• 倒带：因为状态是不可变的，你可以随时回退到之前的状态

Redux 治好了 MVC 时代的状态管理混乱症，虽然代价是大量的样板代码

9. Vue 的渐进式哲学

9.1 尤雨溪的减法

就在 React 试图用函数式编程教育世界的时候，一个 Google 的前员工尤雨溪在想：有没有一种办法，既能有 Angular 的模版便利性，又有 React 的虚拟 DOM 性能？

2014-2015 年，Vue.js 开始爆发
它的核心哲学是渐进式

• 你想用 CDN 引入写个小挂件？没问题，像 jQuery 一样用
• 你想写个单页应用？没问题，上 Vue Router 和 Vuex
• 你想搞大型工程？没问题，上 Vue CLI

Vue 没有强迫你学会 JSX，它保留了 HTML 模版。这让无数从 HTML/CSS/jQuery 时代过来的开发者感到了温暖。在大中华区，Vue 成为了绝对的统治

叠甲：用「大中华区」表述单纯是因为个人习惯，不喜勿喷

9.2 响应式魔法 Object.defineProperty

Vue 2.0 最迷人的地方在于它的响应式系统 它利用了 ES5 的 Object.defineProperty（Getters/Setters）

• 当你把一个对象传给 Vue 的 data 时，Vue 会遍历它的所有属性，把它们变成 Getter/Setter
• 当组件渲染时，读了哪个属性，Vue 就记下来这个组件依赖这个属性
• 当属性变了（Setter 被调用），Vue 通知所有依赖它的组件更新

这比 Angular 1 的脏检查高效，比 React 的手动 setState 自动化。它是魔法，但对于大多数开发者来说，这是一种幸福的魔法

10. 构建的巴别塔

10.1 Webpack 炼金术

在这个时期，前端工程师最痛恨的文件大概是 webpack.config.js
随着 SPA的普及，一个项目可能有几百个 JS 文件、几十个 CSS 文件、几百张图片

Webpack 站出来说：在我眼里，Everything is a module

• JS 是模块，CSS 也是模块（import './style.css'），图片也是模块（import img from './logo.png'）
• Loader：它是一个转换器，把 Sass 转成 CSS，把 ES6 转成 ES5，把图片转成 Base64
• Plugin：它是一个大管家，负责压缩代码、分割代码（Code Splitting）、注入环境变量

Webpack 极其强大，也极其复杂。它甚至催生了一个新工种 Webpack 配置工程师
但也正是 Webpack，让前端终于有了工业级的构建流水线。我们终于可以做 Tree Shaking（摇树优化，用于去掉没用的代码），做按需加载

10.2 让我们活在未来

2015 年 6 月，ES6 (ECMAScript 2015) 正式发布
这是 JavaScript 诞生以来最大的更新：class, module, arrow function, promise, const/let
JS 终于像一门正经语言了

但是，浏览器（尤其是万恶的 IE）不支持啊
Babel（原名 6to5）出现了

它是一个编译器。它把 ES6 代码读进去，转换成等价的 ES5 代码吐出来
这意味着：前端开发者不再受限于用户的浏览器版本
我们可以使用 2026 年的语法标准写代码，通过 Babel 跑在 2010 年的浏览器上

这是前端自信心的极大提升：我们掌控了语言的发展权

10.3 TypeScript 的浪子回头

到了 2018 年左右，随着项目规模突破百万行代码，弱类型的 JS 成了最大的隐患
“Cannot read property ‘x’ of undefined” 是所有线上事故的罪魁祸首

Microsoft 的 TypeScript 终于熬出头了

• 它是 JS 的超集
• 它带来了静态类型检查
• 它带来了极其强大的 IDE 智能提示

起初，大家嫌弃写类型麻烦（把Ts写成anyScript 但当你在重构一个 5 年前的老组件，IDE 精准地告诉你哪里报错时，你会跪下来感谢 TypeScript
无 Ts，不前端逐渐成为了行业共识

至此，现代前端的四大支柱确立了：

1. 组件化框架
2. 类型系统
3. 构建工具
4. 现代语法

我们建立了一座宏伟的巴别塔
但是，这座塔越来越重了
node_modules 文件夹变成了黑洞（没那么轻）。一次 npm install 要 5 分钟，一次 npm run build 要 3 分钟（没那么快）
SPA 的首屏加载越来越慢，SEO 依然是痛点

历史的钟摆，即将再次摆动
为了追求极致的速度，我们将开始反思：我们是不是把太多东西塞进浏览器了？

11. 静态复兴

11.1 SPA 的代价

在 2016-2019 年，如果你不做 SPA，你都不好意思说自己是前端
但是，当全世界都用 React 写网页时，问题暴露了：

1. TTFB：用户打开网页，必须先下载几兆的 JS bundle，浏览器解析完，才能渲染出第一行字。在 3G 网络下，这意味着 5-10 秒的白屏
2. SEO 归零：Google 的爬虫虽然能执行 JS，但Bing或者百度的爬虫经常抓瞎。对于新闻、电商网站来说，搜不到等于死

CSR的神话破灭了

11.2 Next.js 与 Nuxt

Vercel（Next.js 背后的公司）站了出来
他们的思路很简单：既然浏览器渲染慢，那我们回服务器渲染不就行了？

• 同构渲染：
  • 用户第一次访问：服务器跑 React 代码，生成 HTML 字符串，直接返回
  • 用户后续点击：浏览器接管，变成 SPA

这听起来很像 1998 年的 PHP/JSP，但区别在于：前后端是一套代码（全是 JS/TS）。前端工程师拿回了渲染的主导权，同时兼顾了性能

11.3 静态生成

对于博客、文档、营销页，内容几百年不换一次，为什么要每次请求都算一遍？
Gatsby 和 Next.js 推广了 SSG

• 构建时：在开发者电脑上，React 把 1000 篇博客编译成 1000 个 .html
• 分发：扔到 CDN 上
• 访问：用户访问时，就是从离他最近的 CDN 节点拿一个静态文件。这是物理定律允许的最快速度

我们绕了一圈，回到了 Web 1.0 的静态文件模式，但生产这些文件的，是 Web 4.0 的自动化流水线

12. 水合与欺骗的艺术

12.1 恐怖谷效应

SSR 和 SSG 带来了一个新问题：“注水
当服务器返回 HTML 时，网页看起来画好了，按钮也在那儿
用户急不可耐地去点按钮：没反应

为什么？因为 JS 还没下载完，事件监听器还没挂载上去。
这段时间被称为恐怖谷。用户以为它是活的，其实它是死的

这是现代前端最大的痛点：为了让用户早点看到内容，我们不仅发了 HTML，还得再发一份一模一样的 JS 去激活它。数据发了两遍

12.2 岛屿架构

2021 年，Astro 提出了一个灵魂拷问：
我的blog文章是静态的，为什么我要加载 React 库来渲染它？

Astro 的方案是 0 JS

• 整个页面是纯 HTML
• 只有那个评论区组件和点赞按钮是 React 组件
• 浏览器只加载那两个小岛的 JS

这是对 React 全家桶的反叛。它标志着前端开始追求细粒度的加载。我们不再把一头大象塞进冰箱，我们只放进去几根香蕉

这也是我个人是非常喜欢Astro的原因之一

12.3 边缘计算

现在的后端，不再仅仅只是机房里的一台服务器，而是遍布全球的 Edge Functions
Vercel / Cloudflare Workers 允许前端工程师写一段 JS 代码，部署到全球 200 个城市

用户的请求会被路由到离他最近的节点，那里有一个微型的 V8 环境在等他
前端工程师的边界，已经拓展到了网络的最边缘

13. 工具链的降维打击

13.1 Vite 闪击前端

2020 年，尤雨溪（又是他）发布了 Vite
当时 Webpack 的痛点是：启动一个大项目开发服务器，需要等 30 秒甚至 1 分钟。因为 Webpack 要把所有文件打包一遍

Vite：现在的浏览器已经支持 import 了，为什么还要打包？

• No-Bundle 开发：Vite 启动时几乎不做事。你请求哪个文件，它就编译哪个文件。启动时间：300ms
• 这种体验上的巨大差异，让 Vite 像病毒一样迅速吞噬了 Webpack 的市场份额

13.2 Rust 与 Go 的入侵

Vite 的底层使用了 esbuild（用 Go 写的）
Next.js 的底层使用了 SWC / Turbopack（用 Rust 写的）

前端工具链正在经历一场降维打击。

• 以前：用 JS 写 JS 的编译器（Babel, Terser）。慢，单线程
• 现在：用系统级语言（Rust/Go）写 JS 的编译器。快，多核并行
• 结果构建速度提升了 10 倍到 100 倍

这标志着前端基建的门槛被极大地拔高了。以前你会写 JS 就能造轮子，现在你得懂 Rust 和内存管理

13.3 CSS 的原子化：Tailwind CSS

在样式领域，一场审美审丑的战争结束了 Tailwind CSS 赢了

它看起来很像 1999 年的内联样式：<div class="flex items-center justify-between p-4 bg-blue-500">
很多人第一次看觉得丑爆了
但用久了就感觉爆赞了：

• 不用想类名：再也不用纠结 container-inner-wrapper 这种名字了
• 没有死代码：CSS 文件不再无限膨胀
• 设计系统：颜色、间距都是标准化的

它改变了前端写样式的肌肉记忆

14. 前端已死，前端万岁

14.1 全栈的回归

React 推出了 RSC
你可以在 React 组件里直接写 SQL 查询数据库：

// This runs on Server
async function UserList() {
  const users = await db.query('SELECT * FROM users');
  return <div>{users.map(u => <p>{u.name}</p>)}</div>;
}

前后端的界限彻底模糊了（但这也导致了更逆天的问题出现
前端工程师不再是切图仔，也不再是API 消费者
我们正在变成产品工程师。我们一个人就能构建一个完整的、高性能的应用

14.2 AI

23 年，ChatGPT 等各家LLM来了。 写一个居中布局？写一个正则验证？写一个复杂的 Reducer？
AI 一秒钟就生成

前端开发的门槛到底是变低了还是变高了？

• 低级代码 的门槛消失了。AI 会比你写得快，被AI取代的人也是这些
• 系统架构 的门槛变高了。你需要懂 SSR、Hydration、Database、Security等乱七八糟的东西，才能指挥 AI 把它拼成一个好的产品

14.3 下一个三十年

回顾这三十年：
从 1990 年的 <table> 布局，到 2025 年的 Rust 编译器驱动的 Edge SSR

• 我们曾为了动，把一切搬到浏览器
• 我们现在为了快，把一切搬回服务器

历史不是简单的圆圈，而是螺旋上升的塔
我们回到了服务器，但我们带回了组件化、声明式编程和极致的工程化体系

Web 依然年轻
只要人类还需要通过屏幕与数字世界交互，前端工程师的使命就永远不会结束

15. 结

至此，我们过了一遍属于前端的三国演义
我们从从蒂姆·伯纳斯-李的草稿纸开始，一直讲到现在
这就是无数开发者与浏览器搏斗、妥协、并最终驯服它的过程

同时我们也明白了
为什么要学这么多乱七八糟的工具？
因为我们是在一堆原本用来擦屁股的纸上，通过几十年的叠Buff，硬生生盖出了一座摩天大楼

得益于web技术的发展，让移动设备也能和生产力扯上关系了，本文会向您演示如何只使用iPad在codespaces上从0搭建Hexo blog

0.1 准备食材

• 一台有良好网络环境的iPad
• GitHub账号

0.2 什么是codespace

GitHub Codespaces 是GitHub提供的一种基于云的开发环境，允许您直接在浏览器中使用完整的vsc体验，无需在本地安装任何开发工具。这意味着我们可以在任意联网且可使用浏览器的环境中完成开发工作，不依赖本地物理设备，非常适合iPad等移动设备使用

1. 基本工作

1.1 在GitHub登录并创建repo

打开GitHub，登录您的账号，点击右上角的+，选择New repository，填写仓库名称（例如：hexo-blog），类型建议选私密repo，勾选add a README file，点击Create repository完成创建。

1.2 创建Codespace

在刚创建的repo页面，点击Code按钮，选择Codespaces选项卡，点击Create codespace on main，等待codespace创建完成。随后会在浏览器中打开VSCode，在此页面我们可以进行blog搭建工作。

1.3 安装Hexo

在codespace的终端中，输入以下命令安装pnpm：

npm install -g pnpm

随后安装Hexo：

pnpm install hexo-cli

1.4 初始化Hexo

在终端中，输入以下命令初始化Hexo：

pnpm dlx hexo init tmp

由于hexo是在子目录tmp中创建的，我们需要进入该目录，将初始化产物迁移出来

cd tmp
mv * .[^.]* ..
cd ..
rm -rf tmp

这样tmp的临时目录就成功迁移出来了

pnpm默认不允许脚本，我们需要使用以下命令允许构建

pnpm approve-builds

输入后，会出现命令行选项，我们输入a，再输入y并回车，允许所有脚本构建，会自动完成其余构建

1.5 启动hexo

在终端中，输入以下命令启动hexo：

pnpm hexo s

随后会自动启动开发服务器，我们点击在浏览器中打开，即可在新标签页中预览hexo blog，按ctrl+c可以停止服务器

1.6 进行初次commit

打开终端，输入以下命令进行初次commit：

git add .
git commit -m "Initial commit"  
git push -u origin

之后的提交也可以通过左侧的Source Control图标进行推送

:::tip 为什么要提交commit？
在codespaces中，约等于一个临时环境，commit的操作就像您点了一次保存，同时该保存会记录在git历史中，随时可以查看/回滚 :::

2. 使用hexo

2.1 创建新的blog文章

在终端中，输入以下命令创建新的blog文章：

pnpm hexo new "文章标题"

随后会在source/_posts目录下生成一个新的markdown文件，打开此文件编辑即可

2.2 更换主题

您可以在hexo的主题库中选择喜欢的主题，按照主题的安装说明进行安装和配置，这里以hexo redefine主题为例：

git submodule add https://github.com/EvanNotFound/hexo-theme-redefine themes/redefine

随后打开_config.yml，找到theme字段，修改为redefine，保存即可

2.3 配置

打开_config.yml， 这里可以定义最基本的信息，如站点标题、描述、作者信息等，您可以根据需要进行修改，主题配置一般需要额外配置，请参考您使用的主题的README进行配置

3. 部署到cloudflare pages

为什么选择cloudflare？

Cloudflare 是一家提供网络安全和内容分发网络（CDN）服务的公司。它的主要功能包括保护网站免受DDoS攻击、加速网站加载速度、提供SSL证书以及优化网站性能。Cloudflare通过其全球分布的服务器网络，能够有效地缓存和分发内容，从而提高用户访问网站的速度和安全性。

而cloudflare pape则是cloudflare提供的静态网站托管服务，支持直接从GitHub仓库部署，并发布到全球cdn，无需付费，非常适合个人blog使用

3.1 登录cloudflare dashboard

打开Cloudflare Dashboard，登录账号，打开左侧面板，点击计算和AI，点击创建新的应用程序，选择从git仓库部署，选择刚才创建的hexo-blog仓库即可

3.2 构建配置

• 框架预设：（留空）
• 构建命令：pnpm hexo generate
• 输出目录：public

点击保存并部署站点，稍等片刻即可完成部署

3.3 访问站点

cloudflare默认会给出一个 dev域名访问，您也可以CNAME绑定自己的域名

4. 结

至此，我们只使用iPad完成了hexo blog的搭建，不得不说，codespace确实为移动生产力提供了出路。希望本文能帮助到您，顺便也给后续文章挖坑，如果想看，以后可以出一个专门讲各种blog框架的纵向对比

0. 引

maimai Score Hub是GitHub@bakapiano提供的一个网页版查分器，和大多数通过代理或科技sync分数不同，此查分器使用maimai的好友功能拉取成绩，目前来看也许是非侵入性sync导入最方便的，同时此查分器也支持水鱼/落雪的导入

官网链接maimai Score Hub

1. 使用教程

1.1 注册

此查分器使用好友代码注册

打开 舞萌|中二 微信公众号，打开maimaiNET，点击好友，你的好友代码，复制这串数字即可并粘贴至查分器登录即可。网页会要求你同意好友请求，在公众号中同意即可

1.2 导入分数

只需要点击查分器主页的更新数据并在公众号中同意好友请求即可

1.3 同步至水鱼查分器

打开水鱼查分器，点击编辑个人资料，复制成绩导入token粘贴至maimai Score Hub的水鱼token一栏，点击更新即可

1.4 同步至落雪查分器

打开落雪咖啡屋，点击下方的复制个人API密钥，填写到maimai Score Hub的落雪token一栏，点击更新即可

:::tip 落雪查分器需要在账号设置中开启允许写入任何数据才可同步 :::

1.5 成绩查询

在侧边栏打开乐曲成绩即可

2. 附

如果您有更多简单且不需要登录帐号的查分方案，欢迎提供，本blog会补充更新

CEPATO

由于舞萌DX 1.53版本更新推送更改了大量接口校验，很多已有的同步实现失效，而把二维码交给别人同步并不算特别安全，故有了此篇文章

相关内容:

• 舞萌国服1.53补丁更新内容速览
• 如何使用水鱼/落雪查分器备份舞萌DX成绩
• bakapiano查分器使用教程

目录

• 水鱼查分器
• 落雪查分器

1. 水鱼查分器

水鱼查分器相比落雪要略麻烦些(不提供二维码的情况下)

前置前提:水鱼账号

水鱼查分器官网

1.1 Windows/MacOS 代理同步

参考水鱼的官方doc：代理软件导入

1.2 iOS/iPad 代理同步

1. 确保已安装 Shadowrocket App :::warning 该软件需要外区Apple ID购买/下载，推荐使用共享账号登录AppStore(不是iCloud!!!否则会锁机子!!!)并下载，这里给出一个账号共享网站，

该网站不属于CEPATO & Chongxi名下，我们不对此网站的内容负责，您也可以在底部的评论区提供其他共享账号 ::: 2. 打开Shadowrocket，选中配置，按下图步骤进行证书安装

1. 打开设置，按步骤信任证书

1. 打开水鱼查分器官网，点击火箭图标，复制模块URL，按下图步骤导入

1. 启动代理

1. 打开舞萌NET公众号，按箭头顺序依次加载乐曲即可完成同步

1.3 使用union从落雪sync到水鱼

比较抽象的一个方案，也算是曲线救国了

1. 同时拥有水鱼/落雪账号，且落雪账号已同步

2. 登录union站点

3. 在右上角菜单中选中用户选项，填入落雪查分器token和水鱼账号

落雪查分器密钥可以在账号详情，个人API密钥中获取

1. 右上角菜单中选择工具选项，点击更新成绩，选择落雪传水鱼

既然这样为什么不用落雪呢

1.4 使用科技功能的bot上传

此方式需要提供SGWCMAID，也就是你的二维码，不推荐，自1.53更新后二维码就是唯一凭证，凡是要求二维码的功能均有风险，本文不会给出相关途径，自行选择您认为可靠的科技工具上传

2. 落雪查分器

落雪相对简单的多，只需要配置代理即可

确保你有一个落雪账号

2.1 使用落雪提供的代理同步

1. 登录落雪查分器官网，点击左上角菜单，选中同步游戏数据

2. 您可以手动在系统设置的WLAN设定中设置HTTP代理，这里主要演示使用代理工具配置

:::tip[Android]

• 安装Clash Meta，您可以在Atlas Storage下载安装程序或GitHub Repo

• 复制https://maimai.lxns.net/api/v0/proxy-config/clash，打开clash meta，点击配置文件按钮，如图所示添加代理配置

:::

:::tip[iOS/iPadOS]

• 安装Shadowrocket或其他支持的代理工具

• 点击底栏的配置，点击右上角加号粘贴链接

• 直接启动即可 :::

1. 页面内显示代理配置成功后，复制sync链接，打开微信，找到文件传输助手或其他可信会话，发送并点击链接，完成同步

3. 附

如果您是开发者，可以参考bakapiano的通过好友来拉取成绩的方式来进行非侵入性的sync，不过可能麻烦些，这里只是稍微给个hint，如果您有更多非侵入性的sync方式，可以在下方留言，本文会补充更新

最近114514的meme币很出圈啊，本文不构成投资建议，旨在祛魅发币，撕开web3金融神话

如果您不了解web3，可以阅读前文什么是web3？从状态机到去中心化金融，带你认识 最清晰的Web3本质

1. 什么是发币

在 Web3 世界，发币不是印钞票，而是写代码。最通用的标准是 ERC-20

1.1 发币是怎样的

发币其实就是写一个 Class 类，这个类实现了 IERC20 接口。只要你的代码里包含以下核心逻辑，区块链就承认你发的是“币”：

• totalSupply(): 告诉大家总共有多少币
• balanceOf(address): 查某人有多少币
• transfer(to, amount): A 转给 B 多少币
• approve() & transferFrom(): 授权别人（比如交易所）动你的币

1.2 核心数据结构

整个合约的心脏，其实只是这行代码：

mapping(address => uint256) private _balances;

这是一个哈希表

• Key：钱包地址，比如 0x123...
• Value：余额数字，比如 114514

发币就是定义了一个不可篡改的 Excel 表格，表头是地址，内容是余额

1.3. 编译

你写的 Solidity 代码区块链是看不懂的，它需要被翻译成机器语言

1.3.1 Bytecode

代码会被编译器（如 solc）转换成一长串 6080604052348015610010... 的十六进制字符。这才是真正跑在以太坊虚拟机EVM里的东西

1.3.2. ABI 应用二进制接口

这是一个 JSON 文件，相当于README。它告诉钱包和交易所：这个合约有个函数叫 transfer，需要传入两个参数，一个是地址，一个是数量

1.4 部署

1.4.1. 发起特殊交易

在主网发币，本质上是你向区块链的 0x0空地址发送了一笔交易

• **Payload：就是上面生成的 Bytecode
• Gas Fee：矿工费，我更喜欢称其为燃料。在主网上，这一步需要消耗真金白银（ETH/SOL）。因为你要占用全球节点的存储空间，你需要为此付费

1.4.2. 链上确认

矿工/验证者打包你的交易，将其写入区块
一旦写入，EVM 会执行你的 Constructor，通常做两件事：

• Mint：把 1145140000... 个币，直接写入你（部署者）的地址下面
• 生成地址：根据你的钱包地址和交易计数，计算出一个全新的合约地址

此时，你的币已经诞生了。它安静地躺在区块链的某个区块里，但它的价值依然是0，因为它还不在任何人的钱包里，也不在任何交易所里

1.5 开源验证

因为链上只有 Bytecode（乱码），别人不敢买。大家怕你写了后门，所以需要来源验证

1.5.1 Etherscan

你把你的源代码上传到区块浏览器Etherscan
Etherscan 会把你的源码现场编译一遍，如果生成的 Bytecode 和链上的一模一样，就会打上一个绿色的勾

验证通过意味着你要向全世界明牌，当然，可审查不等于安全，很多复杂的割韭菜逻辑（如隐藏的费率、黑名单机制）即便开源了，普通韭菜也看不懂

2. 炼金术

在传统的股票市场，你要卖股票，必须有人在对面挂单买
但在 Web3 的去中心化交易所，没有挂单员，只有一个数学公式和一个池子

2.1 自动做市商 AMM

这是 DeFi 去中心化金融 最伟大的发明，也是最暴力的收割工具。核心公式只有一个：

$$ x \times y = k $$

• $x$：池子里 CEPATO币 的数量。
• $y$：池子里 ETH（真钱）的数量。
• $k$：恒定常数（在没人加减流动性时，保持不变）

简单讲一下
当你用 ETH 来买CEPATO币时：

1. 池子里的 ETH ($y$) 变多
2. 为了保持 $k$ 不变，池子里的CEPATO币 ($x$) 必须 变少
3. 变少的那些CEPATO币去哪了？跑到你的钱包里了
4. 因为池子里币少了、钱多了，剩下的币均价自然就涨了

2.2 庄家视角

作为发币者，你是第一个建立这个池子的人。这意味着，你是上帝，你可以随意定义初始价格。

1. 进入发币平台：连接钱包，选择“创建交易对”
2. 注入资产：
   • 资产 A：放入 1,000,000 个 CEPATO Coin（空气）
   • 资产 B：放入 1 个 ETH（真金白银）
3. 定价诞生
   • 此时，通过除法，初始价格被物理锁定为：1 ETH = 1,000,000 个 CEPATO Coin
   • 或者说：1 个 CEPATO Coin = 0.000001 ETH

市值的诞生不需要审计，不需要路演，不需要财报。只需要我愿意拿出 1 个 ETH 陪这堆代码玩，它就有了市值

2.3. LP Token 金库的钥匙（也是跑路的工具）

当你把币和钱放进发币平台后，平台会给你一张收据，叫做 LP Token (Liquidity Provider Token)

这个 LP Token 至关重要，它代表了你对这个池子的所有权

• 合规玩法： 为了让韭菜放心，庄家通常会把这个 LP Token 打入黑洞地址或者锁在第三方平台。这意味着我把金库钥匙销毁了，池子里的钱我取不出来，大家放心冲

• 收割玩法 庄家把 LP Token 留在自己钱包里

  1. 等韭菜们疯狂买入，把 1 个 ETH 冲到了 100 个 ETH
  2. 此时池子里有：少量的 CEPATO 币 + 100 个 ETH
  3. 庄家拿着 LP Token 去 平台 点击 移除流动性
  4. 庄家拿走了池子里所有的 ETH，跑了。散户手里的币瞬间没法卖了（因为池子里没钱了），币价瞬间归零

2.4. 滑点与价格冲击

这是 AMM 机制的副作用，也是大户收割散户的数学武器

• 一个池子很小，只有 1 ETH
• 有个土豪突然拿 0.5 ETH 来买币
• 他这一笔交易就抽干了池子一半的流动性。根据 $x \times y = k$，价格会呈指数级暴涨
• 土豪虽然把价格拉高了，但他自己买入的成本也极高，买在了山顶

小池子（土狗盘）就像一个小水坑，扔点小资金就能暴涨暴跌这也就是为什么土狗币动不动就“百倍”、“归零”的数学原因

但是，你以为作为庄家，手里拿着 LP 钥匙，就可以安稳地坐庄割韭菜了吗？
太天真了
接下来，欢迎来到 Web3 的黑暗森林

3. 普通人就是韭菜

你向银行发起转账，只有你和银行知道
区块链是全透明的玻璃房，你发起一笔交易，在它被确认之前，全世界都看得到

这就诞生了 Web3 特有的物种，MEV 机器人，俗称科学家

3.1 队列

当你在 MetaMask 点确认交易时，你的交易并不会立刻写入区块，而是先飞到一个公共候机厅，叫 Mempool

• 矿工从 Mempool 里挑交易打包进区块。挑谁？谁给的燃料高，谁先上车
• 机器人 24 小时监控 Mempool。一旦发现有一条大肥鱼正在排队，它们就会利用Gas 竞价机制实施攻击

3.2. 攻击演示

3.2.1 抢跑

假设你发现 CEPATO币 很有前途，决定花 10 ETH 重仓买入

1. 机器人在 Mempool 里扫描到了你的这笔大额买单。它迅速计算出：这笔买单一旦成交，会把币价拉高 5%
2. 机器人立刻发出自己的买单，买入同样的币，但是它的 Gas Fee 比你多给 1 美元
3. 矿工一看机器人给钱多，就把机器人的交易排在你的前面。
4. *结局：
   • Block N：机器人买入 -> 价格拉高 5%
   • Block N+1：你进场了 -> 你被迫以高出 5% 的价格接盘
   • 获利：机器人反手卖出，无风险套利这 5% 的差价

这就好比你在食堂排队买最后一份红烧肉，你刚刷完卡，一个机器人突然冲过来多给阿姨 5 块钱把肉抢走了，然后转身加价卖给你

3.2.2 三明治攻击

这是抢跑的进阶版，也是两头吃

假设你要买入大量 CEPATO币，并且你设置了 10% 的滑点（意味着你允许成交价最差比当前差 10%）

机器人的操作流程如下：

1. 第一口： 机器人检测到你的滑点容忍度，发起一笔巨额买单，Gas 费拉满，强行插队在你前面买入
   • 币价瞬间暴涨，刚好卡在你设置的 10% 滑点极限
2. 中间层： 轮到你的交易执行。因为价格还在你的接受范围内（虽然是最高点），你的交易成交了
   • 你的大额买入，把本来已经暴涨的价格，又往上推了一截
3. 第三口： 机器人发起一笔卖单，Gas 费设置得比你稍低一点，紧跟在你后面卖出
   • 机器人在最低点买入，在被你推高的最高点卖出

你的这笔交易，实际上是被包在了两笔机器人交易中间。你买入的每一分钱溢价，都成了机器人的利润。 这就是为什么散户在链上交易经常觉得买完就跌

3.3.3 Honeypot

如果说上面的攻击是来自外部的强盗，那 Honeypot 就是项目方（你自己）设下的陷阱

// 这是一个简化的貔貅逻辑
function _beforeTokenTransfer(address from, address to, uint256 amount) internal virtual {
    // 如果是卖出操作（to 是 Uniswap 池子地址）
    if (to == uniswapPair) {
        // 只有庄家（owner）能卖，其他人报错
        require(from == owner, "弱智，你被骗了");
    }
}

散户看着 K 线图一路狂飙（因为只能买不能卖），账户余额变成了几百万美元，兴奋地去点卖出，结果钱包弹出红色的 Transfer Failed

3.3.4 撤池子

前文讲过加池子后会得到一个 LP Token
只要这个凭证还在庄家手里，庄家就是这所银行的行长

• 收割流程：
  1. 庄家发币，加了 1 ETH 的池子
  2. 大家疯狂冲，池子里现在有 100 ETH
  3. 庄家在深夜打开 Uniswap，点击 移除流动性
  4. 结局：
     • 庄家拿走了池子里那 100 个 ETH
     • 散户手里剩下一堆 CEPATO Coin
     • 这时候散户的币还在，也没被锁，但是没有任何地方可以兑换了。价格瞬间归零（除数变成了 0）

有些庄家会说：我把 LP Token 锁在第三方平台了，我很安全
事实上，他可能锁了 1 个月。一个月后自动解锁，刚好是项目热度下降、韭菜最放松警惕的时候，他再撤池子

3.3.5 权限后门

• 币价涨到了 100 块一个，总量 100 万个
• 庄家调用合约里隐藏的 mint() 函数（只有 Owner 能调用），给自己凭空印了 1 亿个币
• 砸盘： 庄家拿着这 1 亿个 0 成本的币，去池子里一次性卖出 池子里的钱被掏空，币价瞬间变成 0.0000001

4. 结

所谓 Web3 的“代币经济学”，在剥离了那些高大上的术语后，剩下的大多是博傻游戏

1. 发币：只需要 5 分钟，Ctrl+C 一段代码，成本为 0
2. 价值：只要有人信，空气就能换 ETH
3. 环境：外部有 MEV 机器人 24 小时猎杀，内部有庄家随时准备撤池子跑路

• 如果你是技术人员：去测试网玩玩，去写写 Solidity，研究一下 AMM 的数学公式，你会惊叹于去中心化账本的精妙设计。这确实是计算机科学的进步
• 如果你是赌徒：请记住，在主网，你面对的不是运气，而是不对称的代码特权和毫秒级的算法收割

在这个黑暗森林里，只有一种人能稳赚不赔：
那就是卖铲子的人，以及那个在测试网发币图一乐的我们

4.1

下期预告，如何在测试网中发币

0. 为什么有此次更改

首先，舞萌本身安全架构就没考虑过国服的环境，谁能想到有人能给人家机台的硬盘拆出来

其次，舞萌国服外挂泛滥不是一天两天了，而这次主要导火索就是ttnk公布玩家数据库和炸号脚本，在此之前曾有多次大规模的全服扫号和黑屋。ttnk事件后，国服进行了五天的停服维护，追加了国服特供的安全补丁，而今天下发的1.53则是对原有基础上的升级

1. 第一次补丁追加

1.1 更换二维码服务的URL

http://wq.sys-allnet.cn/qrcode/req/原地址更换为了https://wq.wahlap.net/qrcode/req/

由HTTP升级到了HTTPS，阻止了二维码劫持

:::CAUTION
这次只更改了二维码服务的URL，并没有针对游戏服务器等进行变动，更改游戏服务器需要下发机台程序，不是说改就能改的，造谣所谓游戏服务器URL更替的非蠢即蠢 :::

1.2 token强校验 LEVEL ALPHA

在User ID Login前强制要求使用二维码获取UID，同时必须使用 开罗尔物质 进行签名，且UID Login和Logout必须使用相同签名

这意味着通过user ID直接登入的方式直接失效，恶意外挂无法直接登入您的账号，目前只影响上传

2. 1.53追加补丁

2.1 token强校验 LEVEL BETA

本次1.53推送后，强制要求几乎所有操作都要二维码token校验，包括preview(获取玩家基本信息)，针对建立全服数据库的恶意脚本进行专项打击

2.2 修复0010

解决了恶意外挂发放滚木收藏品导致机台崩溃的问题，目前已知的所有方法均被修复

2.3 更换方法

针对目前已知的脚本中泄露的 开罗尔网络 服务器通信实现方法进行修改，1.53下发后他们全 部 木 大

3. 账号修复指南

官方申诉入口

如果您的账号被恶意脚本炸了，塞了异常数据，推荐通过官方问卷解决，速度很快，爆赞

4. 结

这两次更新后，会直接干掉100.4999%的恶意外挂，同时杀掉90%的脚本小子，以及咸鱼的科技hdd倒卖哥，对于普通玩家来说好事好事都是好事，脚本小子好似喵

更新应用时间未知，大概2weeks吧，这段时间日本人应该一直在忙着加校验，机台乐曲数据更新应用何时未知，不过也可以原谅下了，至少这次防护比国际服都严了

5. 辟谣

关于下图内容的所谓SEGA官方采用熊谷凌的方案为假，这是某群聊在玩梗反串，本次更新修补的所有实现均和熊谷凌提出的方案无任何关系，望各位明辨。相信聊天记录不如信我是秦始皇，毕竟咱不会骗你

0. 引

三星S20怎么说呢，也是老钉子户了，主要是这部机子实在过于完美(除了充电慢)，目前没见过有哪个比他握持手感更好的机子了，而对于我这种不玩手游的人来说，12+256也基本能接受，毕竟照片视频什么的都是在nas里存，本身app也占不了多少存储。唯一的缺点也就系统跟不上，OneUI5.1虽然够养老了，但对于五年前的这台机子来说，负载还是有点吃不消(?)，于是便有了这次刷入类原生的尝试

Chongxi之前是使用类原生大概一两年的情况，本身也挺喜欢类原生这种清淡的毛胚房的，如果你不太适应类原生，酌情刷入，同时由于gsi的特殊性，你可能会遇到一些神秘的bug，本文使用的版本经Chongxi目前是没什么问题的，包括指纹IMEI蓝牙NFC啊什么的都是能正常用的说

0.1 食材准备

• 一台 Samsung S20
• (可选) Treble Info & DSU Sideloader
• Evolution X 9.7 - 2024-12-25 ROM
• S20 TWRP KiT (内含TWRP本体以及各种校验bypass工具)
• (可选) Kernel SU NEXT 内核 x1q
• odin & 三星USB驱动

您可以通过Atlas速递一键获取本文所需的所有内容

:::caution 在开始前，请确保您的手机已解锁bootloader并下载了所有所需软件，且您具备一定的基本刷机知识，同时了解刷机可能带来的风险，本文仅作为经验分享，不承担您自己操作带来的一切后果，请知悉 :::

1. 刷入TWRP

• 确保安装了Odin和Samsung USB驱动，并将手机关机，插入电源线，同时按住**音量+和音量-**进入Download模式
• 打开Odin，手机在Download模式下连接电脑，取消勾选左侧的Auto Reboot，AP槽位选择TWRP，USERDATA选择vbmeta禁用器，用来跳过vbm校验，否则无法刷入第三方rec

• 刷入成功后，同时按住音量-和电源键七秒退出Download模式，在显示第一屏开机页面后立刻同时按住音量+和电源，看到TWRP的LOGO后即可松开

2. 格式化data并重启至Fastboot

• 进入TWRP，点击清除，选中data，输入yes后格式化
• 点击重启，选择重启到fastboot，成功后您会看到TWRP的页面，但是上面确实在跑fastboot，而不是我们平时所见到的Android小机器人或者fastboot LOGO

3. 通过fastboot刷入gsi

• 确保您已安装了adb驱动并添加了全局变量，打开终端或PowerShell，输入

fastboot devices

如果显示了您的设备，则可以进行下一步刷机。否则您可能需要排除驱动/数据线/手机/接口等问题

• 接下来输入以下命令并回车

fastboot flash system "D:/S20/evolution.img"
// 请根据您的实际目录自行调整

• 显示[ok]后即为完成，此时我们输入fastboot reboot即可重启手机，耐心等待进入系统即可

4. <可选> 刷入Kernel SU NEXT

Chongxi这里只找到了适用于sdm-x1q的ksun内核，故以此为演示，因为G9810非GKI内核，而Chongxi并没有编译内核的相关经验。如果您是相关领域大牛，欢迎在discussion中附上您的ksu内核链接

• 按照相同步骤重启进Download模式

• AP槽位选择kSUN内核，USERDATA依旧选择vbm禁用器，点击刷入即可

• 重启，安装ksun管理器，然后enjoy~

5. 结

理论上来讲，刷gsi适用于全部Android机型，但又不适用，很看运气的一个东西

此次刷入的这个gsi又刚好无任何恶性bug，有一些自动亮度一类的问题都可以通过自带的Phh Settings进行修补，非常接近定制ROM的体验了

6. 买家秀

1. 给裸奔的白皇帝穿防弹背心

你是不是忘了大家是怎么把舞萌服务器底裤扒下来的？

现在的现状是：传输层的 AES Key 和 IV 被全世界知道。ttnk 知道，你也知道，路边的科技脚本小子都知道，所有流量在攻击者眼里都是明文透明的

你的天才方案是什么？ 你建议在透明的玻璃房里，把 UserID 锁进一个带密码的 Feistel 小盒子里

但是
攻击者手里拿着 AES 钥匙，他不需要破解你的 Feistel
他只需要截获一次合法的包，拿到那个被你混淆过的 0xDEADBEEF，然后构造一个 JSON： { "userId": "0xDEADBEEF", "score": 114514 }再用手里的 AES Key 加密发出去

服务器会乖乖解密 AES，然后把你那个量子加密的 ID 逆运算回去，最后把脏数据写进数据库
除了浪费服务器 CPU 跑 10 轮 SHA-256，你防住了个寂寞

大门都不关，你给卧室装了个视网膜扫描锁，然后把视网膜数据贴在客厅墙上

2. 你是想让服务器午夜定时炸服？

“利用当日的日期… 生成 tweak… 每天变一次。”

写出这句话的时候自己笑了没
你知不知道舞萌的 AimeDB 和 TitleServer 是分离的？

举个例子 玩家在 23:59:59 连上 AimeDB，拿到了用昨天的密钥加密的数据
然后在 00:00:01 连上 TitleServer，服务器切到了今天的密钥

然后直接炸，解密失败，或者解密出一个完全不相干的 ID ，直接把数据库写出一堆乱码

你是嫌服务器炸得不够快，特意设计了一个零点虫？ 在分离的架构里搞这种强时间依赖的密钥同步，除了没考虑过上下文的 AI，没人敢这么设计。哪怕差 1 毫秒，玩家的数据就火葬场了

3. 舞萌客户端是你家后院的 Python 脚本吗？

“机台侧无需进行任何解密，可以直接…用于请求。”

你以为 SEGA 的机台代码是 JS 写的？var id = anything？
那是跑在 Windows 上的屎山代码

那些代码里大概率写死了 int32，甚至还有各种 assert(id > 0) 的校验 猜测，本人没逆向过app，有误欢迎大手子指出 你那个 Feistel 算法算出来的结果，是个伪随机数

• 如果是负数怎么办？
• 如果溢出了怎么办？
• 如果正好撞上了客户端内部保留的 Debug ID 怎么办？

结果就是机台当场崩溃0010
你说“无需变更”，是因为你根本不懂强类型语言和遗留代码。你只管 AI 生成代码爽不爽，不管机台死不死

4. 溢出屏幕的AI味

master_key, tweak, PRF16, current_round… 这一套变量命名，哥们你是改都不改
这就是你在 ChatGPT 对话框里输入：“怎么设计世界上最强加密算法” 之后，它吐给你的标准教科书伪代码

你连改都不改一下，直接贴进给 SEGA 的信里？
你把《现代密码学导论》的课后习题答案 当成 企业级解决方案？
SEGA 的工程师如果看到这段代码，估计会以为是哪个刚学 Python 的小孩在发癫

你连装逼都懒得自己动脑子，全靠 GPT 给你代笔

5. 叙利亚自爆卡车之自己暴露智力水平

劫持我的 5G 流量？给我手机注入 CA 证书？

你是不是黑客帝国看多了
开源科技的那破py脚本就是恶意客户端
谁有闲工夫去劫持你那破手机？攻击者是直接写了个 Python 脚本，用他手里那把硬编码的 AES 万能钥匙，堂而皇之地走进舞萌的服务器大门
HTTPS 是用来防止路人甲偷看信件内容的，不是用来防止写信人自己往信里下毒的
你连这个最基本的端点安全概念都搞不明白，还敢自称“后端开发者”？你开发的是哪个粪坑的后端？

6. 你能不能把你那破“Feistel算法”忘掉

为什么 AES key 知道 IV 知道 = 流量透明

这是我在26年前听到最蠢的笑话
你的意思是，一个自称「米其林大厨」提问我，为什么水烧开了会烫手？
AES Key 都泄露成公共厕所了，传输层就是个透明的玻璃管
你还搁那给里面的 UserID 搞 Feistel 加密？
攻击者需要破解你的 Feistel？ 他用得着吗？
他直接抓一个合法的加密 ID，然后把它塞进一个写满了垃圾数据的新 JSON Body 里，再用你那把公开的 AES Key 重新加密一下发出去
服务器收到后会怎么样？服务器会像个傻逼一样先解开 AES，然后把你那个狗屁不通的 Feistel 逆向解出来，最后开开心心地把垃圾数据写进数据库
你这套操作除了浪费服务器的 CPU 算力，还有任何一丝一毫的用处吗？用加密算法搞行为艺术

任何一个稍微懂一点密码学的人，都不会问出“为什么知道了对称密钥就能解密”这种问题
这只能说明，你写的那些关于 Feistel、HMAC 的东西，百分之一万是你根本看不懂的、从 AI 那里抄来的垃圾

7. 自己承认自己就是GPT传话筒

算法一开始是我手写，后来因为有问题用 ChatGPT 改了…”

这话你自己说出来不觉得丢人吗？

• “手写有问题” -> 证明你连个基础的密码学轮子都搓不明白
• “用 ChatGPT 改了” -> 证明这个方案的核心逻辑是你抄 AI 的
• “变量名没改” -> 证明你连抄都抄不明白，AI 吐给你什么屎，你就往上端什么屎

你把一堆从教科书里抄来的、连你自己都跑不通的垃圾伪代码，当成拯救世界的灵丹妙药？ SEGA 的工程师如果看到这段代码，会直接把你拉进招聘黑名单，因为他们知道，雇一个只会让 AI 写代码的蠢货，比服务器被攻击还可怕

既然你渴望转发，那就成全你，让大家都认识认识这位连《计算机网络：自顶向下方法》的intro都看不懂的自命不凡的蠢货，欢迎你对我的技术批判指出疏漏，乐意奉陪

8. 结

哥们真不想捶你，但你拿着 vibe 出来的产物到处跳脸开大就是对绝大多数负责人的计科从业者的侮辱

你就是一个拿着从垃圾堆里捡来的钥匙，进屋偷了点东西，然后就开始幻想要教屋主怎么装修的脚本小子

你的方案，既不懂传输层安全，也不懂分布一致性，更不懂兼容性

它唯一的用处，就是证明了 2025 年的 AI 技术还是没法治好人类的脑萎缩。 别混计算机科学了，去拧螺丝吧，那个不需要逻辑，只需要力气

另外，感谢各位并肩作战的同志，谢谢你们一路以来的支持与陪伴以及对游戏环境的重视，预祝各位新年快乐～

一个为 NoneBot2 框架设计的插件，用于通过聊天指令上报 maimai 服务器状态

::github{repo=“ChongxiSama/nonebot-plugin-maimaimonitor”}

功能

• [x] 状态上报: 通过简单的聊天指令（如 /report 断网）上报服务器状态
• [x] 数据聚合: 自动缓存用户上报数据，每 30 秒打包发送至后端 API
• [x] 自定义命令别名: 允许用户在配置中定义简洁的命令别名 映射到复杂的报告指令
• [ ] 直接抓取页面并渲染

安装

你可以通过 NoneBot 的脚手架工具 nb-cli 安装：

nb plugin install nonebot-plugin-maimaimonitor

或者通过 pip 安装：

pip install nonebot-plugin-maimaimonitor

配置

插件的配置项通过 NoneBot 的统一配置方式进行管理，你需要在你的 NoneBot 项目根目录下的 .env 文件中设置

获取凭证

为了向后端 API 发送数据，你需要一个 ClientID 和 PRIVATE_KEY。请联系 email:qwq@chongxi.us 获取。ClientID由您提供，建议为数字

请妥善保管你的 PRIVATE_KEY，不要泄露给任何人。

环境变量

.env 配置文件示例

# .env 文件 (位于你的 NoneBot 项目根目录)

# --- NoneBot Plugin Maimai Monitor 插件核心配置 ---
MAIMAI_BOT_CLIENT_ID="YOUR_BOT_CLIENT_ID"
MAIMAI_BOT_PRIVATE_KEY="YOUR_BOT_PRIVATE_KEY"
MAIMAI_BOT_DISPLAY_NAME="qwqbot"
MAIMAI_WORKER_URL="https://maiapi.chongxi.us"

# --- 自定义命令别名配置 (使用单行 JSON 字符串) ---
# 左边是用户输入的新命令，右边是它映射的内部报告指令参数字符串。
# 右边的字符串会被插件解析，并作为 /report 命令的参数部分。
COMMAND_ALIASES="{ \
    \"ctk\": \"被发票\", \
    \"清票\": \"被发票\", \
    \"服务器炸了\": \"断网\", \
    \"打不开公众号\": \"NET打不开\", \
    \"变游客了\": \"无法登录\", \
    \"黑屋了\": \"小黑屋\", \
    \"被发舞神了\": \"其他扫号行为\", \
    \"罚站300秒\": \"罚站 300\", \
    \"罚站一小时\": \"罚站 3600\", \
    \"帮助\": \"help\" \
}"

使用

在你的 NoneBot 项目 bot.py 文件中加载插件：

# bot.py
import nonebot

# ... 其他初始化代码 ...

nonebot.load_plugin("nonebot_plugin_maimaimonitor")

# ... nonebot.run() ...

插件加载成功后，你可以在与机器人聊天的任何地方发送以下指令：

• /report help 或 /上报 帮助: 查看全部可用的上报类型和帮助信息
• 使用自定义命令别名: 例如，如果你在 COMMAND_ALIASES 中配置了 "ctk": "被发票"，那么直接发送 ctk 即可触发 /report 被发票 的功能

部分命令示例:

• /report 断网 或 配置的别名（如 炸了）: 上报一次机台网络断开事件
• /report 罚站 [秒数] 或 配置的别名（如 罚站五分钟）: 上报玩家罚站时长，例如 /report 罚站 300 表示罚站 5 分钟

主动 Dashboard 渲染

未来将会支持直接将前端渲染为SVG并转化为图片，当前仍需要截取 https://mai.chongxi.us/?share=true&dark=auto

share 为 bot 特殊优化的页面，dark 用于切换深色模式，auto 会自动根据时间切换。

1.

Kohad晚上做了一个噩梦 惊醒后冷汗直流
妻子问：怎么了？梦见舞萌停服了吗？ Kohad喘着气说：比那个更可怕 我梦见我们发布了一个新版本 直到正式上线的那一秒 居然没有任何人理科 妻子：那不是好事吗？说明保密工作成功了
Kohad绝望地说：不！这意味着根本没人再关心这游戏了！拆包的人都懒得拆了！

2.

有人问：舞萌国服的反作弊系统真的存在吗？
答：原则上是存在的 但这就好比地平线上的太阳 你看着它很亮 但你往它那跑 永远也跑不到它跟前 而且最重要的是 它对那些戴着墨镜的人来说 根本就不刺眼

3.

国服玩家提问：听说在新的版本中 将彻底根除外挂脚本的问题 这是真的吗
kohad：原则上是的 经过深入研究 我们决定采取最彻底的解决方案：我们将不再维护服务器 如果连不上网 脚本自然也就无法上传成绩了 这是反作弊斗争的伟大胜利

4.

著名的物理学家和Kohad探讨时间旅行的可能性
物理学家：理论上 没有任何信息能比光速更快
Kohad笑了：那您一定没见过我们的拆包大佬 在我们的公告发出之前（t=0）他们已经发布了资（t=-3days）这证明了在舞萌 因果律是不存在的 结果总是走在原因前面
物理学家：那有什么东西是比光速慢的吗？
Kohad指了指旁边的机房：有 我们的国服更新速度

5.

在一次党史课上 老师问学生：谁能解释一下 什么是SEGA的前瞻直播
学生答：这是一种集体主义的仪式 在这个仪式中 官方假装他们手里拿着绝密文件 而观众假装他们还没有在三天前的群文件里看过这些图片 双方通过这种心照不宣的虚伪 共同维护了社区的稳定与和谐
老师：坐下 满昏

6.

日服玩家问：舞萌国服的服务器真的那么烂吗？听说经常罚站
国服玩家答：不 那不是服务器在卡 那是服务器在思考
日服玩家：waht
国服玩家：它在思考 既然反正都有人会用脚本直接修改数据库 那它辛辛苦苦处理你的成绩到底还有什么意义

7.

SEGA内部讨论：理科和官方资讯到底有什么区别？
Kohad深沉地回答：原则上是一样的 区别仅在于时间 理科是我们还没来得及否认的真理 而官方资讯是我们已经无法否认的历史

8.

在国际街机运营商大会上 日本代表吹嘘道：我们的服务器延迟只有64ms
美国代表说：我们的服务器从不丢包
华立代表站起来 自豪地说：你们的那些都是飞舞 我们的服务器拥有人工智能般的自由意志
众人：何意味
华立代表：当玩家打出了一个发挥超常的成绩时 我们的服务器会自主决定断开连接 以此来维护数据库的纯洁性 虽然它目前还分不清哪个是大手子哪个是脚本 但这种宁可错杀一千 不可放过一个的精神 难道不值得敬佩吗？

9.

Kohad愤怒地召开紧急会议：谁能告诉我 为什么新版本的PV还没做完 网上就已经有高清资源了？到底是谁leak出去的？
有人小声嘀咕：我觉得不是泄露
Kohad：何意味
那人说：因为我们的外包美工发现 与其发给审核部门层层审批卡半个月 不如直接发到tg给小团体看 玩家的反馈修改意见比你们快多了

10.

老资历给新入坑的wmc传授：在舞萌国服 有三件事你绝对不能相信
小资历：哪三件？
老资历：第一 服务器维护完成
第二 外挂零容忍
第三 Kohad说 这是一个惊喜
小资历：为什么第三个也不能信？ 老资历：因为当他在直播里说这句话的时候 你的群友早就把惊喜拆包发给你了

11.

上帝问Kohad：你有罪 你让玩家在断网中痛苦 在剧透中麻木 你有什么想辩解的吗
Kohad指着下面那群依然在排队投币的玩家说：主啊 请看 尽管服务器像土豆 尽管脚本满天飞 尽管毫无秘密可言 他们依然在充钱 依然在排队 上帝困惑：这说明了什么？
Kohad笑：这说明 这不叫烂 这叫对玩家忠诚度的极限压测 而我 通过了测试

12.

中情局抓获了一名潜伏在舞萌玩家群里的Sega staff 试图让他招供服务器的真实承载量
特工对他进行了种种酷刑 他都咬紧牙关 一言不发
最后 特工没办法 把一台舞萌推到他面前 说：如果你不说 我就让你连打十把白潘 但是我给你重装成国服 必须用微信二维码登录
staff当场崩溃大哭：我说！我都说！别让我扫那个二维码！被挂扫号之后永远都登不上了！

13. 宫崎英高版本

终于有一天 服务器奇迹般地顺畅了一整天 没有断网 没有罚站 二维码秒刷
玩家们感动得热泪盈眶 纷纷在群里发表情包
Kohad站在高处看着这一幕：
看 这就是我的设计意图
如果天天都顺畅他们会觉得理所当然
但在经历了364天的阴暗 潮湿和绝望后 这仅有的一天顺畅 就会让他们像索拉尔一样 发自内心地赞美太阳 只有巨大的痛苦 才能衬托出那微不足道的快乐是多么耀眼

14.

如果您有更好的内容，欢迎联系qwq@chongxi.us投稿，过审后将会在第二个合订集收录，感谢支持

你们是怎么做到让一个街机音游变成网络攻防的

首先是硬性要求，你需要之前在这两个查分器上同步过数据，这个我觉得大多数都可以满足这个条件

:::red[注意] 不要相信来路不明的小众bot

如果你的查分器账号在退勤后同步过，那么现在你完全不需要再次同步

如果你有一两个成绩没同步，没关系，如果你号被搞了可以在恢复备份的时候手动传上去，如果没被毁那很幸运了，恭喜

20日凌晨一点补充，后续会随时同步本文更新，留言反馈可以联系邮箱：qwq@chongxi.us

纠正错误内容：
如果你的水鱼登不上去，没关系，期间只要你不把分数同步水鱼查分器，你的号就是干净的，除非挂哥去把水鱼服务器也攻击掉

不要恐慌，坐和放宽，大不了直接睡觉（，第二天早上备份水鱼也不迟，期间别同步分数到水鱼，你的水鱼账号就是安全的，你的成绩也是安全的

如果你实在不放心，可以点击个人资料里的token旁边的刷新按钮，这样所有原来已绑定的bot都无法访问你的水鱼账号，这个取决于你个人了，理论上会安全点，就是bot需要重新绑定

*12/20 01:14补充 :::

:::yellow[how to do]

1. 如果我发现我的游玩记录已经被扫了怎么办
   首先，不要同步水鱼成绩，直接点开水鱼官网备份数据，这里的备份大概率是干净的，如果你没有同步

2. 水鱼页面打不开
   因为跑去备份的人多，而且可能有人在攻击水鱼服务器，这个暂时不清楚，我建议期间不要同步水鱼成绩，丢一两个成绩没传无所谓，坐和放宽等一会，兴许就能进去了

3. 如果我非要点二维码同步查分器咋办
   也不是不行，但是风险极高，你可以在点二维码前，先备份一次数据，这能保证你至少有一个安全的备份可以回退，然后再点二维码同步查分器，既满足了你的反骨需求也能保证你有一个能用的备份 :::

:::blue[备份能干嘛] 这里需要区分一下游戏账号数据和查分器数据

• 游戏账号数据就是，你每次上机之后，在舞萌net里看到的游玩成绩，上机用的是舞萌net游戏账号，而不是查分器账号
• 查分器数据就是，你把账号数据手动同步到查分器，用于bot等提供查分等功能，你可以把查分器里的乐曲数据近似看成是你的账号里的乐曲数据，但是数据更新需要你每次手动同步，虽然会有滞后性，但是也保证了你的游戏账号被毁之后可以通过水鱼备份恢复
• 备份则是将你的查分器数据复制一份，存到你的手机/电脑里，假如你的账号被毁了，就可以通过这个备份来恢复你的账号原有成绩 :::

为了不影响观感，剩余不必要的补充内容会在文末写

关于发票的事情之前有讲，参考这个文章,在文末写了关于被发票的解决方案

1. 水鱼查分器

登录水鱼查分器，直接点击下方的导出为 CSV按钮，选择UTF-8，导出，浏览器会自动下载。使用文本编辑器打开即可查看你的成绩。

2. 落雪查分器

登录落雪咖啡屋，点开左侧菜单，选择成绩管理，点击备份成绩，选择导出，浏览器会自动开始下载，用文本编辑器即可打开。

3. 部分需要关注的地方

1. 单纯不获取二维码目前貌似已经无法阻拦扫号，备份成绩是目前最有效的最坏方案

2. 我不推荐您使用各种来路不明的小众bot，这里只给出了主流的两家查分器原因就在这里，他们本身就易用且积累了一定的权威可信度，国服备份数据首选这两家主流查分器绝对是最优选择

3. 关于0010，如果你的账号里被挂哥发了机台不存在的东西，就会爆炸，比如提前给你发了下个版本的旅行伙伴，你上机的时候机台并没有那个版本的资源，就会爆炸，大多数情况下是这样，也有其他情况

4. 待补充，我会根据广大舞萌群里的常见的提问对本文进行补充

4. 引流

如果你对部分原理感兴趣，不妨看一下我之前写的文章，直达链接，这里简单讲了一下关于二维码的相关问题，上次的扫号日志请看mai 纪事：9 月大规模科技扫号和国服万花筒事件

说好的不会再管mai圈的事呢

首先介绍一下本期主角，Chongxi之前购入过一台玩客云小主机，并给他刷了Ubuntu armv7，当作一个轻量的服务器来使用，在上面跑跑AdguardHome这种小玩意。在爆改的过程中，因为配置文件错误，导致主机的网卡死了，无法进行ssh连接，由于所处环境没有实体键盘以及HDMI显示器用，主机也没有reset按钮，使这台主机成了半残废的状态。

0.1 食材准备

首先介绍下救砖工具：

• 一台root过的Android手机
• USB数据线 所需软件：
• USB Gadget Tool
• Android HID Keyword

所需文件均已给出其GitHub链接，您也可以通过Atlas快递站一键下载所需文件。

1. 原理讲解

其实非常简单，就是拿Android设备模拟成键盘，输入到主机中。至于无HDMI可视化是如何判断命令输出的？答案是，IO灯
对，你没听错，大多数人可能听说过靠主板IO灯来debug，很少听说过靠IO灯来判断输入输出并拯救ubuntu主机吧，当你输入操作和主机输出时，IO灯会闪烁，本文就是靠IO灯来诊断的

既然知道了原理，那么接下来救砖就一定很简单了…吧？

1.1 拦路虎

首先，绝对不是你想的「把数据线一接，然后打开Gboard就能输入」这么简单。
USB协议有严格的主从关系，你插上主机后，大概率是被主机作为要被调试的设备，而不是反过去调试主机。
再者就是BadUSB风险，这里简单过一下基本知识 :::blue[BadUSB] BadUSB是最经典的攻击手段之一，USB协议有一个信任漏洞，主机会无条件信任设备对自己身份的声明，你说你是键盘他就会相信，没有额外的校验过程。一个简单的BadUSB攻击过程如下

1. 将攻击设备插入主机
2. 攻击设备向主机声明他是U盘，主机信任并加载
3. 攻击设备主动断开连接，并以HID的声明重新连接，主机并不会校验他到底是不是键盘，会直接加载驱动，无任何防备接受一切来自此设备的输入
4. 攻击设备开始向主机注入命令（如启动powershell下载木马），而在主机看来，这可能是一个打字飞快的人类，所以不会有任何阻拦 :::

:::yellow[这和你的android手机又有什么关系？] 如果你的android设备有完整的USB Gadget权限，他就能变成OURWORLD里最强大最隐蔽的BadUSB，谁会怀疑一个毫无威胁的正在充电的手机呢？ 你可以使用Termux写攻击脚本来对目标设备注入，对方以为你在充电，实则模拟成键盘，甚至USB网卡劫持流量来发起中间人攻击，NetHunter就是一个专门为Android设备定制的渗透用rom，可以随意控制手机USB接口，伪装成各种设备

OEM厂商 Google Android社区都明白，对于这么巨大的安全隐患，做决策就非常简单了，直接砍掉
因为对于普通消费者来说，他们用USB传输顶多就是互传照片文件和网络共享，直接干掉Gadget无疑是OEM厂商的必然选择，风险实在过于严重 ::: 那么，我是如何让Android设备成功模拟成HID对Ubuntu进行输入的呢

2. 实现原理

Talk is cheap, show me the code.

我们直接来看 Linux 内核的官方configfs.txt来解释，为什么用户空间程序能够控制内核级别的硬件行为

2.1 内核提供蓝图 而不是成品

Where sysfs is a filesystem-based view of kernel objects, configfs is a filesystem-based manager of kernel objects

也就是说，sysfs 是让你看内核已经创建好的东西（比如你的 CPU 温度），而 configfs 是让你要求内核为你创建新的东西。 当 Android 内核被编译时，开启了 CONFIG_USB_GADGET 和 CONFIG_USB_HID 选项后，内核并不会立刻创建一个USB键盘设备。它只是在 /config/usb_gadget/ 目录下，准备好了基础工具，等着你来超级拼装

2.2 mkdir

A configfs config_item is created via an explicit userspace operation: mkdir(2).

你在 configfs 里每创建一个目录，就等于在调用一个内核函数

比如

mkdir /config/usb_gadget/g1

• 这个命令执行时，configfs会通知USB Gadget：用户想创建一个新的 Gadget 实例 g1
• 内核模块后在内存里分配了一块空间，用来描述这个即将被创建的USB设备

2.3 目录与文件

The item's attributes will also appear at this time.

mkdir 成功后，内核会立刻在这个新目录里，为你生成一堆配置文件，这些文件就是这个新对象的可配置属性

比如我们 mkdir g1 之后，ls /config/usb_gadget/g1 可能会看到类似这样的东西：

idVendor     # 厂商ID
idProduct    # 产品ID
strings/     # 各种字符串描述，比如厂商名
functions/   # 定义了这个 Gadget 能扮演什么设备
configs/     # 具体的USB配置绑定
UDC          # 把配置好的 Gadget 绑定到物理 USB 控制器上

2.4 写入配置

write(2) can store new values.

也就是你用 echo 往这些属性文件里写东西，就等于在设置内核里那个对象的参数

比如让它模拟成键盘

mkdir /config/usb_gadget/g1/functions/hid.usb0
    
# 配置参数
echo "..." > /config/usb_gadget/g1/functions/hid.usb0/report_desc
    
# 创建一个USB配置，绑定键盘功能
mkdir /config/usb_gadget/g1/configs/c.1
ln -s /config/usb_gadget/g1/functions/hid.usb0 /config/usb_gadget/g1/configs/c.1

2.5 激活

[configfs handles] the filesystem representation... allowing the subsystem to ignore all but the basic show/store interaction.

内核模块本身不关心你是怎么创建和配置的，它只在最后一步，等待激活

例

# 找到你手机的 USB 控制器名称 (比如 a12345.dwc3)，然后把它写入 UDC 文件
echo "a12345.dwc3" > /config/usb_gadget/g1/UDC

当 UDC 文件被写入时，内核的 USB Gadget 模块会收到一个Commit信号
它会读取你刚才在 g1 目录下做的所有配置，把它们组装成一个完整的 USB 设备描述符
然后，它会命令物理 USB 控制器断开当前的连接，并以键盘身份重新连接到主机

这样，就完成了 Android设备模拟成键盘输入设备的操作。

3. 我是如何救砖的

1. 确保你的android手机已root，安装前文的两个开源工具，在Gadget Tool中授予su权限，并勾选启用HID Keyboard，便完成了Android设备模拟成键盘的操作

2. 使用数据线将Android设备接入ubuntu主机，此时手机会被识别成输入设备，当你按下HID Keyboard提供的软键盘时，是能够看到IO灯闪烁的，接下来的诊断完全是靠IO灯判断的

3. 尝试输入密码并等待十秒，建议直接使用root账号，可以省去sudo的麻烦，这种情况在乎用户组安全没啥必要，随后执行ls观察IO灯是否剧烈闪烁，如果剧烈闪烁则说明ls成功提供了输出，为了稳妥起见，这里决定reboot一下，主机重启，说明我们登录操作没问题

4. Chongxi这里是提前准备过一个恢复脚本，防止这种铸币情况，主要功能是恢复原来的网卡备份的内容。再次通过io灯判断输入，直接执行恢复命令，主机重启，打开openwrt，发现ubuntu对应的LAN口开始有正常流量通信，ssh可以正常连接，救砖成功

4. 结

本文确实已经超出了普通Linux桌面版使用的范畴，可以说是纯粹的炫技，需要你的设备内核支持且已root，可以说是天时地利人和都很考验的一种解决方案

对于Linux玩家来说，没有绝对的死局，只有你还未发现的后门，这就是卓越的开放性

Web3这个词已经被市场营销号嚼烂了。本文旨在向你系统拆解下被营销号包裹的Web3本质。我们抹去黄金之上的泡沫，带你认识计算机科学历史上最激进的一次架构迁移：将信任从中心化的人类机构，转移到去中心化的数学协议之上

1 节点如何互联

Web3 没有中心服务器，只有对等节点。
问题是：在没有 DNS 服务器的情况下，我的电脑怎么知道你在哪里？

1.1 节点发现协议 Discovery Protocol

这完全不同于 HTTP。它使用的是基于 Kademlia 算法的 DHT分布式哈希表

• Enode ID: 每个节点的身份证

  • 格式：enode://<128位公钥>@<IP地址>:<端口>
  • 当你启动一个 Geth 客户端，它会生成这个唯一的 URL

• 引导节点 (Bootnodes):

  • 这是代码里写死的种子节点列表
  • 新节点上线时，先去，质询 Bootnodes 在线节点
  • Bootnodes 返回一堆它知道的 IP。你的节点再去连这些 IP，像病毒扩散一样Gossip找到整个网络

1.2 通信协议 RLPx

一旦找到了对方，怎么发数据？不可能是http 以太坊使用的是 RLPx (Recursive Length Prefix Transport Protocol)

• 握手 (Handshake):

  1. A 发送 Auth 消息（用对方公钥加密的 ECDH 密钥交换）
  2. B 返回 Ack
  3. 建立加密通道（TCP 长连接）

• 多路复用 (Multiplexing):

  • 在这个 TCP 连接里，同时跑着不同的子协议：
  • eth/66: 交换区块头、交易数据
  • snap/1: 快速同步快照数据

2. 数据结构

区块链并不是一个巨大的 Excel 如果用 Excel，当你只修改一行数据，整个文件的哈希值都会变，你需要重算 1TB 数据的哈希，这很显然不显示

Web3 使用的是 Merkle Patricia Trie (MPT) 默克尔压缩前缀树

2.1 什么是树

这是一种结合了哈希树Merkle Tree和前缀树Radix Trie的变态结构

• Key: 账户地址的哈希（Keccak256(Address)）
• Value: 账户内容的 RLP 编码（[Nonce, Balance, StorageRoot, CodeHash]）

2.2 节点的四种形态

在数据库底层，MPT 树由四种节点拼凑而成：

1. Leaf Node (叶子节点): [Key, Value]。这是真正存数据的地方（比如你的余额）

2. Extension Node (扩展节点): [Shared Key, Next Node Hash]

   • 如果一堆地址都是 0xabc... 开头，我们不需要存一万次 0xabc，只存一次，下面挂一个指针。这叫路径压缩

3. Branch Node (分支节点): 一个长度为 17 的数组

   • 前 16 个对应十六进制的 0-f
   • 决定了路径是往 0 走还是往 f 走

4. Null Node: 空节点

2.3 状态更新

当你修改余额时：

1. 我们不复制整棵树。
2. 我们只修改受影响的叶子节点
3. 然后重新计算这条路径上所有父节点的 Hash，直到根节点
4. 旧的节点依然存在（这就实现了历史回溯），但生成了一个新的 Root Hash
5. 这个新的 Root Hash 被放进了新的区块头里

3.EVM 的微观执行

EVM 是如何把字节码变成转账的？

3.1 内存模型详解

EVM 运行时有三块区域，性质完全不同：

1. Stack (堆栈):

   • 结构: LIFO (后进先出)，最大深度 1024
   • 作用: 所有的计算（加减乘除）都在这里发生
   • 指令: ADD 从栈顶拿两个数，相加，结果推回栈顶
   • 特性: 几乎免费（Gas 极低），但随着函数结束消失

2. Memory (内存):

   • 结构: 线性字节数组
   • 作用: 临时存放字符串、数组、返回值
   • 成本: 它是按平方计费的，你申请的内存越大，Gas 呈指数级上涨（防止你把节点的 RAM 撑爆）
   • 特性: 交易结束后数据清零

3. Storage (存储):

   • 结构: 键值对映射 (Key-Value Map)
   • 作用: 永久写入区块链状态（MPT 树）
   • 指令: SSTORE (写), SLOAD (读)
   • 成本: 天价。写一个非零值会需要 20000 Gas
   • 特性: 永久保存，全网同步

3.2 具体指令的执行流

假设代码是 a = b + c。在 EVM 字节码里是这样的：

1. PUSH1 0x05 (把数值 5 推入栈) -> Stack: [5]
2. PUSH1 0x03 (把数值 3 推入栈) -> Stack: [3, 5]
3. ADD (加法操作)
   • CPU 弹出 3 和 5。
   • 计算 3+5=8。
   • 把 8 推入栈。
   • Stack: [8]
4. PUSH1 0x00 (准备存到 Slot 0) -> Stack: [0, 8]
5. SSTORE (存储指令)
   • CPU 弹出 0 (Key) 和 8 (Value)。
   • 物理动作: 在 LevelDB 里写入 MPT_Update(Key=0, Value=8)。
   • 扣费: 扣除用户 20000 点Gas

4. 交易层

一笔交易在网线上传输时，不是 JSON，而是一串被序列化的二进制流

4.1 Recursive Length Prefix)

这是以太坊发明的一种极简序列化格式。
如果是一个字节，直接存。如果是一串字节，前面加一个前缀表示长度，这极致压缩了空间

4.2 交易结构

一笔 Raw Transaction 包含以下字段（按顺序 RLP 编码）：

1. nonce: 计数器（防重放）
2. gasPrice: 你愿意为每单位 Gas 出多少钱
3. gasLimit: 你最多愿意花多少 Gas
4. to: 目标地址（如果是空，表示创建新合约）
5. value: 转账金额（Wei）
6. data: 这就是智能合约的函数调用数据（比如 0xa9059cbb...）
7. v, r, s: ECDSA 数字签名

4.3 签名原理

当你点击 发送交易 时，你的钱包在做什么？

1. 哈希: 计算 h = Keccak256(RLP(nonce, gasPrice, ... data))
2. 签名: 使用你的私钥 $d_A$ 和随机数 $k$，根据椭圆曲线公式计算出 $(r, s)$
3. 打包: 把 v, r, s 附在交易末尾

节点端验证: 节点收到交易，不需要知道你的私钥。它通过 v, r, s 和 h，利用椭圆曲线逆运算，可以算出一个公钥 $Q$ 如果 Address(Q) == From_Address，则签名有效，交易合法

5. 共识层

为什么几万个节点能达成一致？

5.1 验证者工作流

现在可不再是挖矿算Hash，而是在场证明Attestation

1. 质押 Staking: 你必须把 32 ETH 锁进存款合约。这笔钱是你的人质
2. 随机抽签 Randao: 系统每 12 秒随机选出一个 提议者 Proposer 又称矿工
3. 提议: 被选中的人打包交易，广播新区块
4. 见证 Attestation: 其他几千个验证者组成委员会，对这个区块进行签名投票，同意这个块合法

5.2 惩罚机制

• 双签 Double Signing: 如果你在同一个高度签署了两个不同的区块（试图让区块链分叉）
  • 你的 32 ETH 会被瞬间扣除 1 ETH 甚至更多，并被踢出网络
• 离线惩罚 Inactivity Leak: 如果你掉线了，未能参与投票
  • 你的余额会像漏水一样慢慢减少，直到你修好服务器或钱被扣光

6. 智能合约

在此之前，我们补一些技术术语

1. 预言机 Oracle

• 区块链是封闭的，它不知道现在 ETH 的美元价格是多少，也不知道今天气温多少
• 这就产生了一个把现实世界数据（价格、天气）写入区块链的桥梁服务
• 在杠杆中，它是裁判。它说降价了，合约会就执行清算

2. Gas

• 为什么我在链上点一下就要花几十块钱？
• 因为执行智能合约需要消耗全网节点的算力。Gas 就是你付给矿工的计算服务费
• 代码越复杂（循环越多、存数据越多），Gas 越贵

3. DApp 去中心化应用

• 定义：Frontend (网页/APP) + Smart Contract (后端)
• 你看到的漂亮网页（比如 Uniswap 的界面）只是一个壳，它负责把你的点击转化为交易指令发送给区块链

4. DAO 去中心化自治组织

• Aave 借贷协议里的 利息 是谁定的？
• 是持有治理代币Token的人投票决定的，这就像公司的股东大会，但是投票权是根据你手里币的多少来由代码自动统计的

6.1 定义

这玩意既不智能，也不合约

在计算机科学中，智能合约的准确定义是：

存储在区块链上的、地址唯一的、不可篡改的、确定性执行的字节码

• 它没有 AI，不会思考。它只是一个死板的 If-This-Then-That的脚本
• 它没有法律效力（目前大多数国家），它更像是一个自动贩卖机的机械装置，算不上合约

6.2 贩卖机模型

这是理解智能合约最经典的教科书模型（由尼克·萨博提出）：

1. 传统交易（Web2/柜台）：你把钱给售货员 $\to$ 售货员确认金额 $\to$ 售货员拿可乐给你 $\to$ 找零。
   • 风险：售货员可能拿钱跑路，可能算错账，可能不想卖给你
2. 智能合约（Web3/贩卖机）：你把钱投入机器槽口 $\to$ 齿轮转动 $\to$ 此时如果金额足够，可乐必须掉下来
   • 没有中间人。一旦你投币，结果是物理/数学上确定的

6.3 代码解析

我们用最通用的语言 Solidity（以太坊的编程语言，长得像 JavaScript/C++）写一个最简单的存钱罐合约

// 1. 声明版本
pragma solidity ^0.8.0;

// 2. 定义合约（就像定义一个 Class 类）
contract PiggyBank {

    // --- 状态变量 (写在区块链硬盘上的数据) ---
    address public owner;  // 存钱罐的主人是谁？
    uint256 public balance; // 里面有多少钱？(uint256 是正整数)

    // --- 构造函数 (部署时只运行一次) ---
    constructor() {
        owner = msg.sender; // 谁把这个合约部署上链，谁就是主人
        balance = 0;
    }

    // --- 函数：存钱 ---
    // payable 关键字表示这个函数能接收真金白银(ETH)
    function deposit() public payable {
        balance += msg.value; // 余额增加
    }

    // --- 函数：取钱 ---
    function withdraw(uint256 amount) public {
        // A. 身份验证
        require(msg.sender == owner, "你是所有者吗你就整，滚出去");

        // B. 余额检查
        require(amount <= balance, "bro没钱了");

        // C. 转账操作
        balance -= amount;
        payable(msg.sender).transfer(amount);
    }
}

1. 部署： 当你把这段代码通过钱包发送到区块链时，它会被编译成字节码 (Bytecode)（一堆机器才看得懂的 60806040...），并分配到一个以 0x 开头的合约地址

   • 从此，这段代码无法修改，无法删除

2. 调用： 当你在这个合约上点击 存钱 按钮时，其实是向这个合约地址发送了一笔交易

   • EVM会被唤醒
   • 它加载这个合约的代码
   • 它执行 deposit 函数
   • 它修改 balance 变量的状态
   • 全网所有节点同步更新这个变量

3. 不可篡改： 注意 withdraw 函数里的 require(msg.sender == owner)

   • 在现实银行，如果有人拿着枪指着柜员，柜员可以把你的钱转走
   • 在智能合约里，如果私钥签名不对，莱斯特来了也转不走这笔钱。代码逻辑是绝对的铁律

7. DeFi 去中心化金融

7.1 Web3杠杆

• 传统金融（信用贷）： 你想借100万炒股。券商/银行看你的工资流水、房产证、信用分。如果觉得你靠谱，就借给你

  • 这基于人的信用

• Web3 金融（抵押贷）： 区块链不知道你是谁，也没法法院起诉你。它怎么敢借钱给你？ 答案是：超额抵押 噔 噔 咚

7.2 杠杆运作

假设你手上有 1 个 ETH（价值 $3000），你看好 ETH 会涨到 $5000，你想加杠杆赚更多

第一步：抵押 你把 1 个 ETH 存入 Aave 的智能合约

• 你的资产：$3000 (ETH)
• 合约给你一个健康因子

第二步：借贷 合约允许你借出相当于抵押物价值 80% 的稳定币（USDC） 你借出 2400 USDC

• 现在你手里有：1 ETH (在合约里) + 2400 USDC (在钱包里)
• 注意： 这时候还没有杠杆

第三步：循环 这才是真正的杠杆 你拿着借来的 2400 USDC，去交易所再买入 0.8 个 ETH 然后，你把这 0.8 个 ETH 再次存入 合约

• 现在合约里有：1.8 ETH
• 合约发现你抵押物变多了，允许你再借 0.8 ETH 对应的 80% 资金，如此循环

最终
你本金只有 $3000，但你控制了价值 $5000 甚至更多的 ETH

• ETH 涨 10%：你赚的是 $5000 的 10%，而不是 $3000 的 10%。这就是杠杆

7.3 清 算

既然是借钱，合约必须保证借款人的本金不亏损。 合约里写死了一行代码：清算阈值

假设 ETH 价格暴跌 你的 1.8 ETH 贬值了，价值快要低于你借出来的 USDC 总额了 一旦触碰设定的数学红线：

1. 预言机 告诉合约：现在 ETH 跌到 $2000 了
2. 合约触发 Liquidate 函数
3. 合约自动拍卖你抵押的 ETH，用来偿还你借的 USDC
4. 如果还有渣子会退给你

在这个过程中，没有催收电话，没有宽限期，只有代码被执行，你的本金可能会一瞬间蒸发

7.4 超额抵押

这里我们深入讲解传统借贷和web3

• 传统银行：

  • 你什么都不用押，凭工资条借了 10 万块
  • 你跑路了： 银行亏 10 万。银行报警，法院查封你财产，上征信黑名单
  • 你要知道的是，银行在害怕你跑路

• Web3 协议：

  • 你要借 80 块钱（USDC），你必须先往智能合约里存入价值 100 块钱的比特币（BTC）
  • 你拿着 80 块钱跑路了
  • 结果协议手里扣着你价值 100 块的比特币。协议把你的比特币卖了，扣除借给你的 80 块，甚至还赚了
  • 协议压根不在乎你跑不跑路，他们甚至希望你跑路

在去中心化世界，没有警察和法院，代码只相信扣在手里的资产

7.4.0 为什么要在Web3借贷

• 这时候估计会有人要骂，我有那一百块为什么不直接花掉？我还借他干嘛？

如果用 Web2 的逻辑（找银行贷款买房），Web3 的超额抵押简直是脑子有病

但我要告诉你的是

你把 Web3 的借贷当成了消费贷或救济贷
目前的 DeFi 借贷本质上是金融杠杆工具和资产管理工具

真正去借这种钱的人，只有以下四种。每一类都非常精明，并不是因为他穷

7.4.1 赌徒

这是 DeFi 借贷最大的用途（占 80% 以上）。他们借钱不是为了花，而是为了买更多同一种资产

你看好比特币（BTC）要大涨。你手里有价值 10 万的 BTC

• 不借钱： BTC 涨 10%，你赚 1 万
• 去 Aave 借钱：
  1. 把 10 万 BTC 抵押进去
  2. 借出 8 万 USDT（稳定币）
  3. 转身去交易所，把这 8 万 USDT 再买成 BTC
  4. 现在你手里实际控制了 18 万 的 BTC（虽然有 10 万抵押着）
• 结果： BTC 涨 10%，你赚 1.8 万。你的收益放大了 1.8 倍

这根本不是借钱过日子，这是融资炒股。他们愿意抵押，是因为他们坚信手里的抵押物会升值，不想卖掉它，但又想要更多的资金来扩大收益

7.4.2 空头

如果你觉得某个币要跌，你怎么赚钱？在现货市场你只能低买高卖，但在借贷协议里你可以做空

你觉得 A 马上要归零了

1. 你抵押 1000 USDC（真金白银）
2. 借出 100 个 A（价值 800 USDC）
3. 立刻去交易所把这 100 个 A 卖掉，换回 800 USDC
   • 现在你手里有：1000 抵押 + 800 现金 = 1800 资产
   • 你欠协议：100 个 A
4. 等待 A 暴跌 50%
5. 你花 400 USDC 就能买回 100 个 A
6. 把这 100 个币还给协议
7. 你当初卖了 800，现在买回来只花了 400，净赚 400 USDC

借贷协议是做空机制的基础设施。没有借贷，就没有做空

7.4.3 屯币

这是富人的游戏规则。在美国或很多国家，卖出资产是要交巨额资本利得税的，但借款不用交税

你是一个以太坊早期投资者，手里有 1000 个 ETH（假设价值 300 万美元）你需要 10 万美元去买辆保时捷

• 方案 A（卖币）： 你卖掉 33 个 ETH

  • 税务局：你当年成本才几块钱，现在卖这么贵，交 20%-40% 的税
  • 后果：你亏了巨额税款，而且你永远失去了这 33 个 ETH（以后涨了跟你没关系）

• 方案 B（抵押）： 你抵押 ETH，借出 10 万 USDT 提现去买车

  • 税务局：这是债务，不是收入，不用交税
  • 后果：你开上了保时捷，而且那 1000 个 ETH 还在你名下。只要 ETH 不暴跌，你以后慢慢还利息就行；如果 ETH 暴涨，你更是赚翻了

这就是著名的富人策略：Buy, Borrow, Die (买入资产，抵押借款消费，带着债务离世)。DeFi 让普通人也能用这个策略

7.4.4 农民

这时候，借钱是为了赚别处的利息

• Aave 上的借款利息是 3%
• Uniswap 上某个资金池的挖矿回报率是 10%
• 操作： 你抵押资产，以 3% 的成本借钱，去赚 10% 的收益
• 结果： 无风险或低风险 套取 7% 的利差

7.4.5 事实很残酷

或许要有人问

• 如果真把这当作救济债，没有足够的价值去抵押怎么办

答案极其残酷：目前的 DeFi 救不了他们

• CeFi/银行： 靠信用放贷 银行借你钱，是因为看了你的工资流水、工作证明、征信报告。银行相信你未来能赚钱，所以即便你现在没钱，也敢借给你。这叫信用贷

• DeFi： 靠资产放贷 区块链不知道你是谁，不知道你是不是在那家大公司上班，也没法在你赖账时把你送进监狱 所以，区块链完全不相信人性。它只相信扣在手里的钱

Web3 正拼命想解决这个问题。现在的热门方向叫 RWA (现实资产上链) 和 DID (去中心化身份)

• 如果未来能把你的房产证做成 NFT 抵押？（RWA）
• 如果未来链上能形成一套链上芝麻信用分？（Soulbound Token / DID）

只有到了那一天，DeFi 才能真正服务那些 没钱但有信用 的普通人。 现在的 DeFi，本质上是一个服务于资本（资产持有者）和交易员的超级赌场及资金流转工具，而不是慈善机构或普惠银行。

7.5 谁来清算？

• 假设你抵押了 100 块的 BTC，借了 80 块出来。突然 BTC 暴跌，跌到 81 块了，马上就要资不抵债了（跌破 80），谁来卖掉你的债？

并没有人坐在电脑前盯着你的账户 执行清算的是一群机器人，我们称之为 清算人

流程如下：

1. 触发： 智能合约里写死了一条规则：如果（抵押物价值 < 借款金额 * 1.05），允许任何人调用 liquidate() 函数

2. 巡逻： 全世界有成千上万个 24 小时运行的脚本，它们时刻监听着链上的每一个借贷账户

3. 发现： 当你的 BTC 价值跌到红线那一瞬间，这几千个机器人会像鲨鱼闻到血腥味一样，争先恐后地向智能合约发送交易，试图触发 liquidate 函数

4. 处决：

   • 机器人帮你是还一部分欠款（比如还 40 块）
   • 作为回报，合约会把你的 BTC 以打折价（比如 5% - 10% 的折扣）卖给这个机器人

5. 结局：

   • 协议收回了欠款
   • 机器人赚到了差价（比如它花 40 块帮你还债，拿走了价值 44 块的 BTC）
   • 你的 BTC 被低价强制卖掉了，你亏大了

清算你的没有官方，而是为了赚取那 5% 罚金的第三方套利机器人。这是一种基于贪婪的自我维护系统

7.6 闪电贷

在 Web3 里，只有一种情况你可以不抵押一分钱就借走几个亿。这叫闪电贷 这也是很多黑客攻击的手法

但它有一个极其硬核的物理限制：原子性 Atomicity

你写一个智能合约，包含三步逻辑：

1. 向 Aave 借 1 亿美元（无抵押）
2. 拿这 1 亿去炒作、套利、搬砖（随便你干什么）
3. 在同一笔交易结束前，必须连本带利把钱还回去

如果你在第 2 步亏了钱，导致第 3 步还不上钱，会发生什么？ EVM会判定这笔交易失败，整个过程回滚

就像时间倒流一样： 在区块链的历史上，你从来没有借过这笔钱，这 1 亿美元从来没有离开过金库。你只需要支付一点点 Gas 费，证明你曾经 试图 这么做过

所以，即使是闪电贷，你也无法卷款跑路，因为如果你不还钱，这笔借款在物理时间轴上就不存在

8. 自动化做市商

在 Web3，为了节省昂贵的存储费（存几万个挂单在链上太贵了），我们发明了 $x \times y = k$

8.1 恒定乘积公式 CPMM

这是一个极其优雅的数学模型，它不需要任何做市商挂单，只要有资金池就能交易

• 模型: 一个池子里有两种资产，A (数量 $x$) 和 B (数量 $y$)
• 铁律: 在交易前后，两个池子的数量乘积 $k$ 必须保持不变（忽略手续费） $$ x_{\text{old}} \times y_{\text{old}} = k = x_{\text{new}} \times y_{\text{new}} $$

8.2 交互推导

假设池子里有：

• ETH ($x$): 10 个
• USDC ($y$): 30,000 个
• 当前价格: 3000 USDC/ETH
• $k = 10 \times 30,000 = 300,000$

你想用 USDC 买 1 个 ETH

1. 你给合约发了若干 USDC（设为 $\Delta y$）
2. 你想拿走 1 个 ETH ($\Delta x = 1$)
3. 计算:
   • 池子剩下的 ETH 必须是: $x_{\text{new}} = 10 - 1 = 9$
   • 为了维持 $k=300,000$，池子里的 USDC 必须变成: $$ y_{\text{new}} = \frac{300,000}{9} = 33,333.33 $$
   • 所以，你必须投入的 USDC ($\Delta y$) 是: $$ \Delta y = y_{\text{new}} - y_{\text{old}} = 33,333.33 - 30,000 = 3,333.33 $$

• 虽然初始价格是 3000，但你买这 1 个 ETH 实际上花了 3333.33
• 滑点 Slippage: 这一单把价格从 3000 推高到了 3333。买得越多，单价越贵。这就是供需曲线的自动调节

8.3 无常损失 Impermanent Loss

这是作为流动性提供者 LP 必须懂的数学陷阱

• 当你把 ETH/USDC 存入池子做市，如果 ETH 暴涨，你的 ETH 会被套利者买走（因为池子里便宜），你会满手全是贬值的 USDC
• 自动卖出上涨资产，买入下跌资产。这是一种做空波动率的策略

9. Oracle预言机实现

智能合约最大的缺陷是 它是瞎子 EVM 是确定性的，无法进行 HTTP 请求（比如 GET binance.com/price），因为不同节点在不同时间请求，结果可能不同，共识就会崩溃

Chainlink 是如何把现实世界带入区块链的？

9.1 架构设计

1. 链上部分: 一个简单的存储合约

   contract PriceFeed {
       int256 public price;
       function updatePrice(int256 _price) public { ... }
   }
   

2. 链下部分 Oracle Nodes: 几百个独立运行的服务器，监听交易所 API

9.2 数据上链流程

1. 聚合 Aggregation: 21 个节点分别从币安、Coinbase 获取 ETH 价格
   • 节点 A: 3001
   • 节点 B: 3002
   • 节点 C: 2999
   • …
2. 共识: 它们在链下（Off-chain P2P 网络）对数据进行签名，取中位数。中位数能过滤掉个别恶意报价
3. 写入: 一个指定的节点把这一包带有 21 个签名的最终数据，发送给链上合约
4. 验证: 链上合约验证签名数量是否达标，然后更新 price 变量

这就是为什么 DeFi 借贷协议依赖 Chainlink。如果 Chainlink 被黑，所有借贷协议都会因为价格错误而发生连环清算

10. 扩容

以太坊 L1 太贵太慢（TPS ~15）。我们需要在不牺牲安全性的前提下扩容，因此发明了Rollups (打包)

核心思想是 在链下执行计算，在链上存结果和证据

10.1 乐观汇总

代表：Arbitrum, Optimism。

• 工作原理:
  1. L2 节点在链下飞快地跑交易
  2. 每隔几分钟，把几千笔交易压缩，计算出一个新的 State Root
  3. 把这个 Root 发布到以太坊 L1
  4. 乐观假设: L1 默认认为这个 Root 是对的，直接接受
• 欺诈证明 (Fraud Proof):
  • 如果在 7天挑战期 内，有人发现这个 Root 是错的（比如 L2 节点私自改了余额）
  • 挑战者提交一段数学证据给 L1
  • L1 重新执行那一笔交易。如果发现确实错了，L2 节点被罚没押金，回滚状态
• 代价: 提现需要等待 7 天，也就是挑战时间，可以理解为冷静期

10.2 零知识汇总

代表有：zkSync, Starknet

• 工作原理:
  1. L2 节点打包交易
  2. 数学魔法: 生成一个 零知识证明 (SNARK/STARK)。这个证明用密码学保证了：我刚刚执行的这 1000 笔交易，其状态变化确实导致了新的 Root，绝无作假
  3. 把 Root + 证明 提交给 L1
  4. L1 的验证合约校验这个证明。如果通过，立即确认状态
• 优势: 它是数学真理，不需要等待 7 天
• 劣势: 生成证明极其消耗 CPU 算力

11. 黑暗森林

在 Web3，黑客攻击不是绕过防火墙，而是合法地调用你的代码

11.1 重入攻击 Reentrancy Attack

这是 The DAO 事件（导致以太坊分叉）的罪魁祸首

漏洞代码示例:

function withdraw() public {
    uint bal = balances[msg.sender];
    require(bal > 0);
    
    // 1. 转账 
    (bool success, ) = msg.sender.call{value: bal}("");
    
    // 2. 扣余额 
    balances[msg.sender] = 0;
}

攻击原理:

1. 黑客写了一个恶意合约
2. 黑客调用 withdraw()
3. 目标合约执行到 msg.sender.call（转账）时，会触发恶意合约的 fallback 函数
4. 恶意合约的 fallback 函数里写了一行代码：再次调用目标合约的 withdraw()
5. 此时，目标合约的第 2 步（余额归零）还没执行，所以 bal > 0 依然成立
6. 结果: 像递归一样，黑客把钱提了一次又一次，直到把池子提空，最后才执行余额归零

如何防御？: checks-effects-interactions 模式（先扣款，再转账）

11.2 抢跑与三明治攻击 MEV

内存池 是完全公开的。矿工/验证者就像拥有上帝视角

你发了一笔交易：用 1000 USDC 买 ETH。这笔大单会把 ETH 价格推高 1%

攻击者 (Searcher Bot) 监测到了这笔交易：

1. 抢跑 (Front-run): 机器人发一笔交易买入 ETH，并将 Gas 费设得比你高。矿工会先打包它的交易。
   • 结果机器人把你买入前的价格抬高了
2. 你的交易执行: 你以更高的价格买入了 ETH（你亏了）。价格进一步拉高
3. 夹尾 (Back-run): 机器人紧跟着你的交易卖出 ETH
   • 结果机器人低买高卖，吃掉了你的滑点

这就是 Maximal Extractable Value。这是区块链这种公开透明账本的必然副作用

12. NFT

大概你也会认为 NFT 就是 买一张图片，这是最大的误解 你花几十万买个猴子头像，你买到的根本不是那张图片

12.1 核心原理

想象一下，你花钱买了一颗星星的命名权

• 你得到星星了吗？ 没有，星星还在天上，谁都能看，谁都能拍照
• 那你买到了什么？ 你买到了一张纸，上面写着：坐标 ~ 的这颗星星，现在归Chongxi
• 谁承认这张纸？ 假如有一本全人类公认的、绝对无法涂改的天文学大账本（区块链），全世界只有这一本账本

NFT 就是这本大账本上的一行字：

编号 #8888 的东西，属于 #你的钱包地址

至于这个 #8888 是一张图片、一首歌，还是一把游戏里的屠龙刀，区块链其实根本不在乎。它只在乎确权

12.2 为什么比特币不是 NFT？

• 比特币（同质化）= 钞票 你手里的一百块钱，和我手里的一百块钱，是一模一样的。咱俩换一下，毫无影响。这就叫同质化

• NFT（非同质化）= 房产证 你手里的是 1排1座 的票，我手里是 最后一排厕所门口 的票 虽然都是票，但价值完全不一样，不能随便换。这就叫非同质化

所以在区块链上，比特币只记录 你有几个币
而 NFT 必须记录 你拥有的是哪一个编号

12.3. 最大的谎言

NFT 最荒诞、也最技术性的地方

因为区块链简直是寸土寸金。要在以太坊链上存一张普通的 1MB 高清大图，光存进去的手续费可能就要几万甚至几十万人民币，哪怕是土豪项目方也存不起

那怎么办？存链接

你的 NFT 上，其实只写了一行像网址一样的东西：

TokenURI：https://…/oiiaoii.jpg

残酷的是：

• 你花了 100 万买的 NFT，在区块链上只是一行代码，这行代码指向了某台服务器上的一张图
• 如果项目方没钱续费服务器了，或者项目方跑路把服务器关了，你的 NFT 还在链上，但那个网址打不开了
• 结果你花 100 万买的房产证，变成了一张白纸

解决办法 现在的良心项目，会把图片存在 IPFS（一种去中心化硬盘） IPFS 的特点是：只要世界上还有一台电脑存着这张图，链接就永远有效。这就相当于把 房产证 指向了一个永远不会倒闭的图书馆

12.4 何为拥有

很多人最不服气的地方便是：这图片我也能下载，我也能设成头像，凭什么要花 100 万？

• 你去卢浮宫，可以对着《蒙娜丽莎》拍照，可以把照片洗出来挂家里，甚至画得比真迹还清楚
• 但是，当你拿着照片去苏富比拍卖行，没人会理你
• 只有那个持有真品证书的人，才能把画卖出天价

在 Web3 的世界里，所有人的钱包都是透明的 你有没有这个 NFT，大家在链上一查就知道

• 你下载图片设头像 大家查你的钱包，发现里面是空的，纯装
• 你买了 NFT 设头像 大家查你的钱包，发现真的有记录，我去碰到老资历了

NFT 的价值，不在于 看 ，而在于 被全网验证的炫耀权

12.5 授权机制

你在交易平台卖 NFT 时，你会发现你不需要把 NFT 转给平台 那平台怎么能在你睡觉的时候，自动把你的 NFT 卖给别人呢？

这里用到了一个类似 房屋中介 的机制：

1. 授权： 你第一次上架时，钱包会弹窗让你点确认。 这一步其实是在链上签了一份委托书：

   我授权 Opensea 这个中介，可以随时动用我钱包里的这张名为 #8888 的房产证

2. 签名： 你填个价格：10 ETH 这一步其实是你写了一张条子：

   谁给我 10 ETH，中介就把房产证给他 这张条子没上链，只是贴在了 Opensea 的服务器上（为了省手续费）

3. 成交： 买家来了，看中了。买家把 10 ETH 给 Opensea 的智能合约 合约拿着你的委托书，直接把 NFT 从你的钱包里抓出来，塞给买家，同时把钱给你

为什么很多人点个链接 NFT 就没了？ 因为骗子做的钓鱼网站，伪装成抽奖页面，弹出的那个确认框，其实是最高权限委托书 你一旦点了确认，骗子就有权搬空你所有的 NFT，根本不需要知道你的密码

13. 真相

只谈颠覆不谈风险是骗子，只谈愿景不谈现状是忽悠

目前的 Web3，极其撕裂。一方面是天才的数学和精妙的架构，另一方面是遍地的骗局和低效的重复建设

全世界都在修路（造公链），修了一万条高速公路，但路上跑的只有几辆玩具车（应用），而且这几辆车上坐的全是想在路上捡钱的赌徒

为什么会这样？这是激励机制的错配造成的

• 发公链太赚钱了：

  • 如果你开发一个 App（比如去中心化的YouTube），你需要累死累活运营用户，变现极难

  • 但如果你开发一条公链（Layer 1 / Layer 2），你发一个币，讲一个 我是更快的以太坊的故事，资本就会疯狂涌入

  • 导致工程师们不去解决真实世界的痛点，而在疯狂内卷 TPS（每秒交易量）。现在的公链性能早就过剩了，缺的是人用

  • 以太坊、Solana、Aptos、Sui……每一条链都是一个独立的国家。用户资产跨链极难，体验极差。这就像你用微信还要分 Android版 和 iOS版，而且两边账号数据还不互通

• 真正的DApp并未爆发：

  • 目前的 去中心化应用 只有三类还在活跃：借贷（DeFi）、赌博（GameFi）、炒图（NFT）
  • 并没有出现像 Uber、Wechat 这样真正改变普通人生活的消费级应用

如果你要入行或投资，必须直面这四个死神

A. 不可挽回的技术死亡 在 Web2，微信崩了可以修，支付宝被黑了数据可以回滚 在 Web3，Code is Law 是一把双刃剑

• 你把钱转错地址了？永久消失
• 你把私钥弄丢了？无人能救
• 智能合约有 Bug 被黑客掏空了？那是 合法的 代码执行，没人赔你
  • 对普通用户来说，这种自我主权带来的心理负担太重了。很多人根本接不住这种自由

B. 庞氏与泡沫

Web3 目前 90% 的代币经济模型（Tokenomics）本质上是庞氏（Ponzi）。

• Play-to-Earn： 钱从哪来？从后进场的玩家手里来。一旦没新人进场，币价瞬间归零（如 Axie Infinity）
• 高收益挖矿： 承诺年化 100% 的收益？那是用印出来的通胀币给你的
• 空气币： 没有现金流，没有盈利能力，市值全靠共识（也就是情绪）。情绪一崩，价值归零

C. 监管铁拳 最大的灰犀牛

• 反洗钱 (AML)： 只要监管层掐断 法币出入金通道（让银行不给交易所转账），Web3 就会变成局域网里的自嗨，流动性枯竭
• 证券认定： 如果美国 SEC 认定大部分代币是 证券，那么所有的交易所都要持牌，大部分项目方都要坐牢或交巨额罚款

D. 中心化的伪装

很多号称“去中心化”的项目，其实控制权在 3 个人的多签钱包里。

• 服务器在 AWS 上
• 前端在 Cloudflare 上
• 甚至节点都是项目方自己跑的
• 一旦出事，这比银行还危险，因为银行受监管，他们不受监管

14. 泡沫下的黄金

既然全是问题，为什么还要研究它？为什么全世界最顶尖的精英，华尔街和硅谷最聪明的大脑还在往里冲？

因为泡沫之下，物理层面的变革已经发生了。就像 2000 年互联网泡沫破裂，Pet.com 死了，但互联网留下了

14.1. 支付革命

这是目前 Web3 唯一真正的大规模应用

• 在阿根廷、土耳其、尼日利亚等通胀严重的国家，普通人把积蓄换成 USDT/USDC 存在手机里
• 这并不是为了炒币，而是为了生存。它让一个没有美国银行账户的非洲人，拥有了持有美元资产的权利。这在人类历史上是第一次
• 现在汇款要几天，收几高手续费；用链上转账，几秒钟，几分钱，全天候。银行的 SWIFT 体系注定会被淘汰

14.2 资产代币化

别再炒你那破图片了，未来炒的是现实世界，把美债、房地产、股票映射到链上

*   你可以在周日凌晨 3 点，把你的 100 块钱美债卖掉，换成一杯咖啡
*   你可以买 0.0001 份纽约的一栋大楼的收租权。

• 逻辑： 并不是为了去中心化，而是为了流动性和全球化。黑石（BlackRock）等巨头正在入场，这才是万亿级的市场

14.3 数据主权与数字身份

这是对抗 AI 时代唯一的武器

• 在 AI 时代，怎么证明 我是人？怎么证明 这个作品是我画的，不是 AI 生成的？
• Web3 的解法： 你的私钥签名是无法伪造的数字指纹
• 你的社交关系、你的医疗数据、你的创作内容，不再存在腾讯或 Google 的服务器里，而是加密存在 IPFS 上，钥匙在你手里。任何 App 想用数据，必须经你授权（甚至要付费！）

14.4 无摩擦的全球协作

• 虽然现在的 DAO 很乱，但代码级公司的形态是先进的
• 没有财务部门（链上自动记账），没有跨国转账障碍，根据贡献（代码提交量/投票）自动发工资。这对于开源社区和全球化组织是降维打击

15. 结

我作为个人开发者对Web3的看法

在 Web2，我们相信服务器管理员是善良的 Don't be evil 在 Web3，我们假设环境是恶意的，但依靠密码学和博弈论，系统依然能正确运转 Can't be evil

目前的 Web3 目前处于 1995 年的互联网 和 1840 年的淘金热 的叠加态

• 它混乱、野蛮、充满骗子和强盗
• 但它脚下确实埋着石油和黄金，而且铁轨已经铺好

不要做那个在路边鼓掌的人，也不要做那个在赌场里红眼的赌徒

要做那个卖铲子、修铁路、或者在荒原上盖起第一家真正超市的engineer

最近，Gboard悄悄推送了一项更新：无视任何条件的 Autofill 这一功能的行为逻辑类似于剪贴板，你可以直接从键盘候选栏点击填充按钮，强制将密码或其他字段填入当前的输入框

在此之前，非Chromium内核浏览器（如Firefox Android）无法正常唤起Google Autofill。即便长按输入框，当网页请求密码字段时，往往也无法在系统菜单里直接调出密码管理器。这意味着许多深度依赖 Google Passwords 的用户被迫留守Chrome，或者转向 Bitwarden等第三方管理器，体验极其割裂

而这次更新之后，Google Autofill在Firefox Android上终于可以完美使用了。Chongxi也终于能摆脱Chrome Android这个功能简陋的浏览器了

本文主要分享一下我迁移到Firefox Android后总结的配置经验与插件推荐

0.1 Why Firefox?

Firefox是目前Android平台上为数不多的非Chromium 内核浏览器。在Chrome逐渐垄断Web标准的今天，使用 Gecko内核的Firefox不仅是为了支持Other World，更是因为它切实提供了比较不错的功能，比如强劲的隐私防护，拓展插件支持等

1. Firefox 基础配置

下文提供配置示例，具体解释见后文的Note

1.1 常规设置

• 密码：建议将Firefox内置的保存密码设为OFF（如果你要使用Google Autofill）
• 付款方式：同样的，建议OFF，交由第三者接管

记得在Android系统设置中，将自动填充服务指向你需要的App

1.2 隐私与安全

• HTTPS-ONLY：强烈建议开启，并选择对所有标签页启用
• 基于 HTTPS 的 DNS (DoH)：建议开启，除非你在其他地方使用了DoH
• 增强型跟踪防护：选择 自定义，并勾选如下配置：
  • Cookie: 隔离跨站 Cookie
  • 跟踪性内容: 所有标签页
  • 加密货币挖矿程序
  • 已知的数字指纹跟踪程序
  • 重定向跟踪器
  • 存疑的数字指纹跟踪程序: 所有标签页
  • 要求网站不共享和不出售我的数据

:::blue[配置解释] HTTPS-ONLY 模式

HTTP是明文传输，账号密码、邮件内容都在裸奔 2025年了，仍不支持HTTPS的网站本身安全性就存疑 强制开启后，浏览器会在网站不支持HTTPS时发出警告，防止被悄悄降级劫持

基于 HTTPS 的 DNS (DoH)

传统DNS查询是明文的，运营商或攻击者可以轻易看到你在访问chongxi.us DoH把DNS查询封装进 HTTPS 流量，防止DNS污染与劫持（如被运营商插入广告、跳转钓鱼站） 如果你在 Android 系统设置中已经配置了私人DNS，这里可以选择关闭，避免双重解析带来的延迟

隔离跨站Cookie

Firefox的看家本领。它把每个网站的Cookie关在独立的沙箱里 比如，Facebook的Cookie只能在facebook.com读取，无法在你访问x.com时通过第三方Cookie追踪你。这能大幅减少跨站广告追踪，且不影响单一网站的登录状态

数字指纹与跟踪器拦截

指纹跟踪：通过你的屏幕分辨率、电池电量、字体列表等生成唯一ID，清空 Cookie 也无法消除 重定向跟踪：阻止链接跳转时的中间商记录，Firefox会尝试直接访问目标 挖矿拦截：干掉那些利用你手机挖矿的恶意js脚本 :::

2. 必装拓展及配置指南

Firefox Android的精髓之一，这里推荐了一些优质插件

2.1 uBlock Origin

Android端最高效的广告与内容拦截器。

• 不同于Adblock Plus等商业软件，uBO 开源、免费、内存占用极低

:::blue[setup]

1. 设置 -> 防止 WebRTC 泄露本地 IP 地址 & 我是高级用户 启用
2. 规则列表 -> (如下图设置) 如果你有别的语言浏览需求，可以在区域里启用对应语言规则

1. 如果有些网站无法工作，可以对其添加白名单 :::

2.2 LocalCDN

去中心化的资源加载插件

• 现代网页大量引用Google、Cloudflare等的公共库。这意味着你没访问Google，Google也能通过请求知晓你的IP
• LocalCDN 会拦截这些请求，直接用本地内置的文件代替，达到切断跨站追踪，省流加速的效果

:::blue[setup] 基础 -> 禁用链接预读取 & 清除被允许的请求中的元数据 开启即可 :::

2.3 Clear URLs

当你复制bilibili等链接给朋友时，链接往往长得吓人（比如带?utm_source=...）

• 此插件会清洗 URL 中的营销参数
• 安装即用，无需额外配置。它会在后台默默把链接里的小尾巴追踪参数切掉，还你一个干净的地址

2.4 Random User-Agent

主要用于对抗浏览器指纹和某些国内网站的歧视

• 通过伪造 User-Agent，让网站以为你是Chrome，或者无法通过UA特征锁定你。

:::blue[setup]

1. 选择要伪装的浏览器，如Chrome
2. 勾选将当前操作系统与生成的用户代理同步
3. 不建议伪装成Desktop Windows，网页会变成电脑版，在手机上操作体验极差 :::

2.5 沉浸式翻译

目前体验最好的网页双语对照翻译工具

没啥好配置的，开箱即用

3. 结

虽然Firefox在Android上的js跑分偶尔不如V8引擎那么激进，但为了那一份属于数据主权以及高度的可玩性，这极小的性能代价是完全值得的，Chrome有多简陋是有目共睹的

SEO，也就是Search Engine Optimization，它是一整套技术策略，目的是让搜索引擎更容易理解和索引你的网站，最终为用户提供更好的搜索结果

SEO是一个长期的过程，需要根据搜索引擎的规则和算法来不断调整和优化

本篇与《现代搜索引擎深度解析：从原理、算法到高效检索实践》是互补的关系，强烈建议您了解前作，>点击跳转

1. 抓取 Crawling

抓取是搜索引擎认识一个网站的第一步，爬虫程序会通过链接逐一访问网页并获取网页内容
你的网站页面必须能够被抓取，才能被搜索引擎索引并显示在搜索结果中

1.1 抓取队列 & URL发现

搜索引擎依赖一个叫做Crawl Frontier(抓取队列)的系统。
抓取队列是一个管理URL的列表，爬虫会依照队列中的URL来抓取页面。
URL的发现主要有四种方式：

• 内部链接Internal Links：爬虫通过已经抓取的页面中的<a>标签来发现新页面。比如你的 Arch Linux安装指南 中有链接指向 GRUB引导配置详解 ，爬虫会通过这个链接发现后一个页面
• 外部链接Backlinks：其他网站指向你网站的链接也是一个重要的发现途径。例如，如果一个音游社区在盘点作曲家xi的文章中，链接到你的 xi在舞萌DX中的曲目有哪些，那这就是一个外部链接 关于外链的SEO参见PageRank讲解
• 站点地图Sitemap：站长提供一个sitemap.xml，列出网站的所有重要页面。搜索引擎可以通过这个文件快速知道你站点下的内容物并索引
• 历史数据和预测History & Prediction：基于之前的抓取数据，搜索引擎会预测新的URL。例如，假设你的URL结构是/chongxi/1/，那么爬虫可能会推测到可能存在/chongxi/2/，并继续抓取

1.2 抓取策略：BFS & 优先级 & 自适应调度

面对海量的URL，爬虫需要有效管理抓取顺序 以下内容可能你已经在上一篇搜索引擎详解看过了，这里就简单讲讲，当复习了

• 广度优先搜索BFS：最基础的抓取策略。它从起始页面开始，优先抓取离当前页面较近的页面（链接层级少）

• 优先级调度Priority Scheduling：现代爬虫会根据多种信号动态调整优先级，例如：

  1.PageRank：如果你的舞萌DX入坑指南被很多高质量网站链接，爬虫可能认为这个页面更重要，会优先抓取和更新它，但是PageRank早已成为过去时，更替为了更先进的权威评估，详见3.3

  2.更新频率：比如一个实时更新舞萌DX出勤记录的页面，可能会被更频繁地抓取

  3.用户需求：如果OpenWrt新版本编译成为热门搜索，相关的教程页面可能被优先抓取

1.3 抓取预算 Crawl Budget

抓取预算Crawl Budget是指搜索引擎对网站进行抓取的时间和资源限制。它由两部分组成：

1. 抓取率限制Crawl Rate Limit：指搜索引擎对你服务器的抓取频率限制。如果你的网站服务器响应很快，没有大量的404或5xx错误，爬虫就会抓取得更频繁
2. 抓取需求Crawl Demand：指搜索引擎认为一个页面的抓取价值。例如，如果你的页面很有价值，或者页面内容经常更新如频繁更新的舞萌DX曲目列表，爬虫会更频繁地抓取它

1.4 抓取控制协议的层级与逻辑

站长可以通过多种方式来控制爬虫

• robots.txt 文件：位于网站的根目录下，告诉爬虫哪些路径不可以访问 配置示例：

User-agent: *
Disallow: /tmp/

• <meta name="robots">：页面级别的控制，放在HTML的<head>部分 配置示例：

<meta name="robots" content="noindex">

表示此页面可抓取，但不要在搜索结果中显示

• X-Robots-Tag：通过HTTP响应头控制抓取和索引，适用于非HTML文件（如PDF、图片等）

2.索引 Indexing

索引是搜索引擎将网页内容转换成可查询、可检索的结构化数据的过程

2.1 文本预处理流水线

抓取到的网页内容会经过一系列处理：

1. 内容提取：剥离广告、侧边栏、页脚等模板化内容，专注于核心正文
2. 分词Tokenization：将文章内容分解成一个个单独的词元token。例如，中文小米路由器刷openwrt会被分割为小米,路由器,刷入,openwrt
3. 标准化：包括转小写、词形还原（如"running"到"run"）、去除停用词（如"的",“了”）

2.2 核心数据结构 I：倒排索引 Inverted Index

倒排索引是搜索引擎的核心数据结构之一，它建立词元 → 包含该词元的文档ID列表的映射，允许快速查找

:::blue[EXAMPLE] 假设你的blog上有以下三篇文章：

• 文章1 ID: 1：标题 在Arch Linux上优化Steam Proton性能的终极指南
• 文章2 ID: 2：标题 Arch Linux安装与配置i3wm
• 文章3 ID: 3：标题 推荐几款能在Linux上流畅运行的Steam独立游戏

经过文本预处理分词、标准化后，搜索引擎会为一些关键的词元Token建立如下的倒排索引表Posting List：

现在，我们来看当用户进行不同搜索时，倒排索引是如何工作的：

场景一：简单查询

当用户搜索Arch时，搜索引擎直接访问arch的倒排列表，瞬间返回 [文档1, 文档2]

场景二：布尔查询

当用户搜索Arch Linux Steam时，搜索引擎会执行以下高效的交集运算： 1. 取出arch的列表：[1, 2] 2. 取出linux的列表：[1, 2, 3] 3. 取出steam的列表：[1, 3]

接下来，对这些已排序的列表进行合并求交集操作：

- [1, 2] AND [1, 2, 3]  => [1, 2]

 *然后用上一步的结果继续求交集*
 
- [1, 2] AND [1, 3] => [1]

至此，搜索引擎在数毫秒内就精确地锁定了唯一相关的文章1，而完全不需要去扫描那数以亿计的、与查询无关的文档 :::

2.3 核心数据结构 II：向量索引 Vector Index & 语义空间

现代搜索引擎引入了向量索引，以理解查询的语义。通过深度学习技术，将每个词或文档转换为一个高维的向量

:::blue[EXAMPLE] 你的两篇文章 OpenWrt如何搭建家庭云存储 和 如何用OpenWrt搭VPN服务器，虽然关键词不完全相同，但内容主题相关。
通过向量索引，搜索引擎能将它们的语义关系转化为向量空间中的距离，知道它们都属于OpenWrt高级配置这个主题。因此，当用户搜索OpenWrt VPN，搜索引擎也可能推荐OpenWrt家庭云存储的文章 :::

2.4 内容去重与规范化

互联网充满了重复内容，搜索引擎采用如 SimHash 等去重算法来识别相似内容，并只索引一个权威版本

:::blue[EXAMPLE]

• 文章A：如何在 OpenWRT 上安装 OpenClash 服务
• 文章B：OpenWrt OpenClash 安装配置指南

如果内容高度相似，搜索引擎会认为它们是重复内容。此时，rel="canonical"标签就起到了作用，它可以明确告诉搜索引擎哪一篇是主要的版本，其他重复内容的权重会被归并到主版本中 :::

3.排序算法与信号解构 Ranking Algorithms & Signals

排序是搜索引擎将从索引库中召回的成千上万个相关文档，按优先级展示给用户的过程。这个过程涉及多个阶段的筛选与打分

3.1 排序的多阶段漏斗模型

以下内容在前文已提及，这里作简单概述

排序过程可以看作一个漏斗模型，逐步筛选和精化结果：

1. 召回 Recall：通过倒排索引和向量索引，从亿万文档中找到几千个最相关的候选文档
2. 初排 Coarse Ranking：使用计算开销较低的算法（如 BM25）对候选文档进行初步评分，筛选出几百个最有潜力的结果
3. 精排 Fine-grained Ranking：使用复杂的机器学习模型，综合数百个信号对候选文档进行进一步的精准排序
4. 重排 Re-ranking：在精排基础上，根据用户的个性化需求、时效性等因素对结果进行最后的微调

3.2 初排核心算法：BM25

BM25 是搜索引擎常用的一种初排算法，它基于概率模型来估算文档与查询之间的相关性，是TF-IDF的改进版

:::blue[EXAMPLE] 查询：OpenWrt 配置代理服务

• 文档A：如何在 OpenWrt 上配置代理服务，1500字，关键词"OpenWrt"、"代理服务"出现了10次

• 文档B：OpenWrt 基础设置指南，篇幅8000字，也提到了"代理服务"几次，但更多篇幅在讲DHCP、DNS等

BM25如何评分：

1. 词频 (TF)：文档A中关键词频率更高，得分会更高。
2. 文档长度：BM25会惩罚过长的文档。文档B虽然也包含关键词，但因为它篇幅太长，主题不够集中，其分数会因此被拉低，避免了长文档因包含更多杂乱关键词而获得不公平的优势
3. 词频饱和度：文档A即使把"代理服务"重复100次，其得分也不会无限增长，有效防止了关键词堆砌 :::

3.3 链接权威性模型：PageRank的暴死 & 现代权威模型

PageRank是Google早期的革命性算法，它第一次将互联网上杂乱无章的链接，变成了一张巨大的、可计算的信任投票网络

一个网页的权威性，部分继承自链接到它的其他网页的权威性。一个链接，就是一张推荐票

:::blue[EXAMPLE] 假设你写了一篇关于 曲师xi的BMS时代名曲考据 的文章

• 情况一：这篇文章只发布在你的个人博客上
• 情况二：这篇文章被BEMANI WIKI以及一些资深乐评的blog引用

从传统PageRank的视角来看：在情况二中，每一个指向你文章的链接都是一张信任票。来自BEMANI WIKI这个专家的权重，远高于100个普通论坛签名链接的权重。因此，情况二的文章会被赋予高得多的PageRank值，被认为是更权威、更值得信赖的资源 :::

:::red[你说的对但是] 那个0-10分的公开PageRank评分，早在2013年底就已停止更新，并于2016年被Google正式死刑宣判!

为何暴死？

它的公开性和简单性，催生了一个巨大的、扭曲的链接交易市场。黑帽SEO们不再专注于创造高质量内容，而是痴迷于购买和交换高PR值的链接，试图操纵这个投票系统

这就像一场选举中，出现了大规模的贿选和假票，导致选举结果不再可信。公开的PageRank，从一个衡量权威的指标，异化成了一个可被直接攻击和利用的漏洞，污染了整个搜索生态

为了维护搜索结果的公正性，Google不得不亲手处决了这个曾经的王牌算法的公开形态(好似喵) :::

PageRank转世的现代权威模型

PR已死，但通过链接分析来计算权威性这个核心思想，非但没有消失，反而以一种更复杂、更智能、更无法被轻易操纵的形式，融入了现代搜索引擎数百个排名信号的汪洋大海之中

我们可以将现代的权威模型，理解为PageRank-ADVANCED。它不再只关心谁投了票，更关心：

1. 投票的上下文相关性 Topical Relevance 现代模型如何思考：一个链接的价值，很大程度上取决于它所在的页面的主题

:::blue[EXAMPLE] 一个来自 Arch Linux中文维基 页面上指向你 Arch Linux安装指南 的链接，其价值远高于一个来自 美食博客大全 的链接，即使后者的传统意义上PR值可能更高

因为前者可以告诉Google：一个Linux领域的权威，推荐了另一个Linux领域的资源
这是一个高度相关的且专业的背书 :::

1. 链接周围的环境 Surrounding Context 现代模型如何思考：链接周围的文本，这个链接是编辑精心放置在正文中的，还是藏在网站页脚的一堆链接？

:::blue[EXAMPLE] 高价值： 在一篇评测OpenWrt路由器的文章正文中，作者写道：关于旁路由的详细配置，我强烈推荐大家参考不良林上的这篇 OpenWrt旁路由超详细配置指南（链接），他把所有坑都讲清楚了这不是接广

低价值： 在你朋友博客的页脚友链区域，有一个简单的锚文本链接Chongxi的blog

前者的上下文清晰地解释了为什么要推荐你，这是一个强烈的编辑推荐信号 :::

1. 链接的用户行为 User Behavior 现代模型如何思考：这个链接，真有人看吗？用户点击后，是长时间停留，还是立刻返回

:::blue[EXAMPLE] Google可以通过Chrome浏览器、Android系统等多种渠道，获取匿名的用户行为数据。如果一个指向你《舞萌DX定数表》的链接被大量用户点击，并且用户在你页面上平均停留了5分钟，这就在事实上验证了这个链接的真实价值 :::

今天的链接权威性，综合了相关性、上下文、编辑价值和用户真实反馈的复杂评分。它远比PageRank更难被操纵，但也因此，对那些真正创造高质量、专业内容的创作者更加公平，希望各位看到这段后，不再去试图以各种途径来和SEO斗智斗勇，酒香不怕巷子深，把内容质量写好才是第一位

3.4 现代排序核心：学习排序 Learning to Rank

LTR是现代搜索引擎精排阶段的关键技术。它把排序问题转化为机器学习问题，依靠大量特征和训练模型来决定页面排名。
常见的LTR模型有基于树的模型（如Gradient Boosting Decision Trees, GBDT）和神经网络模型

:::blue[EXAMPLE] 查询：Arch Linux 安装后要做什么

LTR模型会考量哪些特征（简单举例）：

1. BM25得分：衡量页面内容和查询的字面匹配度
2. 外链特征：页面是否有来自Arch Linux官方论坛、知名技术博客的外部链接？这些链接的锚文本是什么？
3. 用户行为信号：当这篇文章出现在搜索结果中时，它的历史点击率是多少？用户点击进来后，平均停留了多长时间？是很快就返回(Pogo-sticking），还是看完了再走(Long Click)
4. 内容质量特征：文章是否详细、有深度？是否提供了清晰的代码示例？是否图文并茂？是否体现了作者的真实经验E-E-A-T？ :::

工作机制： LTR模型通过学习海量的查询-文档-用户反馈数据，自动为这数百个特征分配权重，最终输出一个综合相关性分数
它能理解，对于这个查询，用户可能更看重提供具体解决方案这个特征，而不是外链数量

3.5 神经重排 Neural Re-ranking

这是最先进的技术之一，使用深度学习模型（如Transformer, BERT）来进行更精细的语义匹配，超越了简单的关键词匹配

:::blue[EXAMPLE] 查询：舞萌DX怎么快速提升Rating

神经重排如何理解： 传统方法：可能会寻找包含"舞萌DX"、“快速”、“提升”、"Rating"这些词的文章

神经模型：它能理解这个查询的深层意图是"寻找高效的上分技巧"
因此，它不仅会返回标题匹配的文章，还会高度评价一篇标题为 舞萌水歌吃分推荐 的文章，即使这篇文章里压根没出现"快速提升"这四个字。因为它从语义层面理解了"水歌吃分"就是对"快速提升Rating"这个问题的绝佳答案 :::

4. 排名算法

除了上述模型，还有一些经典算法族系值得了解，它们共同构成了搜索引擎的算法核武库

4.1 经典算法：BM25 & TF-IDF

已在3.2节详细介绍，TF-IDF是BM25的基础，核心思想是通过词频和逆文档频率来评估词语重要性

4.2 HITS

Hyperlink-Induced Topic Search与PageRank不同，HITS是查询相关的。它将页面分为两类：

• 汇聚点Hub：一个高质量的Hub页面，是链接到多个相关权威页面的资源列表页
• 权威点Authority：一个高质量的Authority页面，是被多个相关Hub页面链接的官方或最终内容页

:::blue[EXAMPLE] 查询：OpenWrt 固件下载
权威页：OpenWrt官方固件下载页面
Hub页 (Hub)：一篇 OpenWrt从入门到精通 的博客文章，其中一部分列出并链接了官方固件下载页、LEDE固件下载页、以及几个知名的第三方编译固件的GitHub页面，那么此文章就是一个高质量的Hub页 :::

4.3 LTR

已在3.4节作为现代排序核心详细介绍

4.4 深度学习

已在3.5节作为语义匹配前沿技术详细介绍，其核心是利用BERT等模型进行深层语义理解

5. 结果展示

一个好的搜索结果展示能极大提升点击率

5.1 标题

:::blue[EXAMPLE] 差：OpenWrt

爆赞：[2025] OpenWrt路由器超详细配置指南 :::

5.2 摘要

摘要是显示在标题下方的简短描述。搜索引擎会自动抓取它认为最相关的部分。

5.3 URL 和面包屑导航 Breadcrumb Navigation

清晰的URL结构和面包屑导航能帮助用户和搜索引擎理解页面在网站中的位置

:::blue[EXAMPLE]

• URL：.../guides/openwrt/openclash/
• 面包屑：首页 > 指南 > OpenWrt > OpenClash配置教程

建议使用BreadcrumbList Schema.org结构化数据来标记你的面包屑导航，有机会让它直接显示在搜索结果中。 json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [{ "@type": "ListItem", "position": 1, "name": "指南", "item": "/guides" },{ "@type": "ListItem", "position": 2, "name": "OpenWrt", "item": "/guides/openwrt" }] } :::

6. 技术性SEO

技术性SEO旨在优化网站的技术结构，确保搜索引擎能够顺利地抓取、渲染和索引，优化用户体验

6.1 抓取与索引优化指南

6.1.1 robots.txt 审计

定期审计robots.txt文件，确保没有误阻止重要内容的抓取。

:::blue[EXAMPLE] 假设你的网站是用React或Vue构建的SPA应用，JS文件至关重要。如果你在robots.txt中错误地加入了Disallow: /assets/js/，那么爬虫将无法加载和渲染你的页面，导致只能看到一个空白页 :::

6.1.2 noindex 标签的精确使用

对低质量页面（如搜索结果页、重复内容页、标签聚合页等）使用noindex，可以集中抓取预算和页面权重 :::blue[EXAMPLE] 你的博客可能有很多标签页，比如/tags/openwrt。如果这个页面只是简单地列出相关文章的标题，而没有独特的原创内容，它就属于低质量页面。
为这类页面添加<meta name="robots" content="noindex, follow">，意味着告诉Google：别索引这个列表页，但你可以顺着它上面的链接去抓取那些有价值的文章 :::

6.1.3 站点地图的维护

确保站点地图是动态生成的，并且只包含你希望被抓取的规范化URL :::blue[EXAMPLE] 当你发布一篇 浅谈xi的World Fragment专辑 后，你的站点地图生成脚本应能自动将这个新URL加入sitemap.xml，并更新<lastmod>时间。
然后，你可以通过Google Search Console的站点地图功能，主动通知Google有新的内容需要抓取 :::

6.1.4 监控抓取统计报告

在Google Search Console中定期查看设置 > 抓取统计信息报告，关注404错误和5xx服务器错误 :::blue[EXAMPLE] 如果你在报告中发现服务器连接错误的提醒，这表明你的服务器可能存在性能问题或炸了。你应立即排查服务器问题，因为持续的报错会导致Google降低对你网站的抓取频率 :::

6.2 网站性能优化 Core Web Vitals

Largest Contentful Paint / LCP

衡量页面主要可见内容加载的时间。 :::blue[EXAMPLE] 你的Arch Linux教程文章中，通常最大的元素是顶部的头图或截图。你需要确保这张图片被压缩，并且没有被其他CSS或JS文件阻塞加载。可以考虑为这张关键图片使用<link rel="preload">来提升加载优先级
可以考虑把图片压缩为Webp/avif来显著降低大小以优化加载速度 :::

INP / Interaction to Next Paint

测量用户与页面交互的响应时间。

INP已于2024年3月正式取代FID

:::blue[EXAMPLE] 你的网站有一个复杂的、用JavaScript实现的曲目搜索筛选器。当用户点击一个筛选按钮时，如果JS需要进行大量计算导致页面卡顿超过200毫秒，INP指标就会变差
优化方法包括：将长任务拆分成小块、对筛选逻辑进行算法优化(视你的实际情况而定) :::

CLS / Cumulative Layout Shift

测量页面内容的视觉稳定性 :::blue[EXAMPLE] 你的文章页面在加载过程中，顶部加载一个广告横幅，但是他的加载速度比正文慢。当广告加载出来时，会将下方的正文内容推下去，导致用户正在阅读的文字位置发生跳动。
这就是典型的CLS问题。解决方案是：在广告位容器上预先设置明确的width和height属性，即使广告还没加载，也先占好位置 :::

6.3 结构化数据 Schema Markup

通过使用Schema.org标准，可以帮助搜索引擎更好地理解你的网页内容

• 基础部署：为文章、博客、组织信息等添加标记
• 争取富媒体摘要

:::blue[EXAMPLE] 在 OpenWrt配置指南 文末，有FAQ部分 json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [{ "@type": "Question", "name": "旁路由模式下如何避免DHCP冲突？", "acceptedAnswer": { "@type": "Answer", "text": "核心是关闭旁路由的DHCP功能，并将其网关指向主路由..." } }] }

部署后，搜索结果下方有可能直接出现这个问答，吸引用户点击 :::

6.4 精通 nofollow, sponsored, ugc

引流当然重要，但同样重要的是，我们也需要一个阀门来精确控制我们网站的权重如何流出，以及如何向搜索引擎表明我们与其他网站链接的性质
这就是rel属性中nofollow、sponsored和ugc这三个值的用武之地

6.4.1 Link Relationship Attributes

最初只有rel="nofollow"主要是为了解决博客评论区的垃圾链接泛滥问题。站长们用它来告诉搜索引擎：“不要追踪这个链接，不要将我的页面权重传递给它，我不对这个链接的内容背书”

然而，一个简单的nofollow无法区分链接的动机。因此，在2019年，Google引入了两个更具体的属性，将nofollow的职责细分了：

• rel="sponsored"：明确用于标记付费链接，如广告、赞助商内容
• rel="ugc"：明确用于标记用户生成内容 User Generated Content，如博客评论、论坛帖子
• rel="nofollow"：现在作为一种通用的、当你不想为某个链接背书，但它又不属于sponsored或ugc类别时的备用选项

Google现在将这三个属性视为提示而非指令
这意味着，在某些情况下（比如为了更好地发现内容），Google可能会选择追踪一个nofollow链接，但它仍然不会传递排名权重 PageRank

:::blue[防止评论区被滥用，防止外链污染] 你的 Arch Linux安装指南 下方开放了评论区。很快，一些垃圾账号开始发布评论，内容是"非常好文章！看看我的"，并附上了指向低质量、甚至博彩网站的链接

如果你不加处理，你的高质量页面就相当于在投票给这些垃圾网站。这不仅会稀释你自身的页面权重，还可能因为链接到不良邻居而受到搜索引擎的惩罚，这就是外链污染

这里可能会有不仔细看的人会问啊：啊Chongxi你不是说PageRank被弃用了吗。对，传统意义上的PageRank确实弃用了，但是他的思想被传承下来了，这种投票机制依旧存在，不过算法更加严格

解决方案
为所有评论区用户提交的链接，自动添加rel="ugc" html <!-- 用户在评论中留下的链接 --> <a href="http://spam-site.xice.cx" rel="ugc">非常好文章！看看我的</a> 这通常由你的后端或CMS系统（如WordPress）在渲染用户评论时自动完成。你需要确保你的系统有这个功能。对于自己开发博客的你来说，就是在处理用户输入的Markdown或HTML并将其渲染到前端时，用一个过滤器给所有的<a>标签加上rel="ugc"

ugc和nofollow可以组合使用： 为了兼容其他可能不完全理解ugc的搜索引擎，最佳实践是同时使用两者： html <a href="http://spam-site.xice.cx" rel="ugc nofollow">非常好文章，即使是我也感到心潮澎湃</a> :::

:::blue[建立商业诚信，标明付费链接] 一家知名的路由器硬件厂商联系你，希望在你的 出厂OpenWrt硬件推荐 一文中，付费购买一个指向他们最新款路由器的链接

根据Google的网站管理员指南，任何以影响搜索排名为目的的付费链接，都必须明确声明。如果你收了钱，却让这个链接看起来像一个自然的编辑推荐链接（即没有rel属性的"dofollow"链接），一旦被Google发现，你的网站可能会受到严厉的**手动操作惩罚 **，导致排名暴跌甚至从搜索结果中消失

解决方案：为这个付费链接添加rel="sponsored" html <a href="http://yoanshen.com/ganshenme" rel="sponsored">点击购买最新最热路由器</a> 这不仅仅是一个SEO技术问题，而是一个商业诚信问题。明确标记付费合作，既遵守了搜索引擎的规则，也维护了你和读者之间的信任 :::

:::blue[精细化你的内部链接策略]

观前提醒，这个比较有争议性

你的博客侧边栏有一个登录/注册页面的链接。这个链接会出现在你网站的每一个页面上

一些SEO专家过去认为，像"登录"、“关于我们”、"隐私政策"这类对排名没有帮助的页面，不应该从你的高质量文章中获得权重。因此，他们会给这些内部链接加上rel="nofollow"，试图将权重雕刻或引导到更重要的产品或文章页面

```html
<!-- 传统做法，现在已不推荐 -->
<a href="/login" rel="nofollow">登录</a>
```

这种做法现在已经过时且无效了，Google已经明确表示，当一个页面上的链接被加上nofollow后，它对应的PageRank会直接蒸发，而不会被重新分配给该页面上其他"dofollow"的链接

正确做法：

• 不要对内部链接使用nofollow来试图控制权重流向。这只会浪费你本应在站内循环的权重
• 对于那些你认为不重要、不希望被索引的内部页面（如登录页、复杂的筛选结果页），正确的做法是使用robots.txt阻止抓取，或者使用<meta name="robots" content="noindex">来阻止索引 :::

何时使用，如何选择

7.内容优化 Content Optimization

7.1 关键词研究与主题建模

7.1.1 从关键词转向主题

围绕一个核心主题，构建支柱页面 + 集群内容的网状结构

7.1.2 分析搜索意图

通过查看SERP，分析用户搜索某个词时，是想找教程（信息型），还是想找官方网站（导航型）

7.2 E-E-A-T

E-E-A-T代表

Experience - 经验
Expertise - 专业性
Authoritativeness - 权威性
Trustworthiness - 可信度

7.2.1 作者身份展示 E-T

在文章旁或文末提供作者简介，链接到作者的GitHub、技术博客或社交媒体，展示其在相关领域的经验

7.2.2 经验具象化 E

:::blue[EXAMPLE] 写一篇关于 评价舞萌DX中xi的Glorious Crown 的文章。与其只用文字描述，不如：

1. 嵌入你自己录制在视频网站上的手元视频链接
2. 贴上你自己的成绩图
3. 分享一个别人没提过的冷知识：“其实这首曲目在maimai中标的BPM不对，准确应该是225.555555555，这也解释了为什么这首曲目DX分比较难抓，因为BPM不准确导致了偏移，个人猜测可能是xi作曲时编曲器BPM有误差” :::

7.2.3 权威性与可信度的构建 A-T

引用权威来源：在你的Arch Linux教程中提到某个配置时，链接到Arch Wiki的对应页面
专家审阅：如果你的OpenWrt教程请了另一位网络领域大肘子审阅勘误，可以在文章开头注明：“本文由xx指导以确保技术准确性”

8.权威性建设

权威性的核心是通过外部链接Backlinks来提高网站的信誉度

8.1 现代链接建设策略

8.1.1 创作可链接资产 Linkable Assets：

:::blue[EXAMPLE] 你可以创建一个在线工具：“舞萌DX Rating 计算器”，用户输入相关信息来计算单曲Rating，这种实用工具是天然的链接磁石 :::

8.1.2 数字公关 Digital PR

:::blue[EXAMPLE] 你写了一篇关于 Samsung One UI8使用评测，包含详尽的测试数据。你可以将这篇报告主动发给一些知名的科技媒体或极客，他们很可能会引用你的数据和文章 :::

修复死链

:::blue[EXAMPLE] 你要把blog从Astro迁移到Hexo，但是迁移后发现根目录不对且搜索引擎仍引用旧链接，用户在搜索引擎中访问变成404。你需要设定301重定向把旧的链接301至新的，否则可能会因为大面积的404瘫痪导致SEO评分降低 :::

8.2 站外声誉与品牌信号建设

8.2.1 建立品牌实体

确保你的品牌（你的博客名或你的名字）在主流知识平台和行业目录中有清晰、一致的条目

8.2.2 管理第三方评价

如果你的内容涉及到工具或服务，鼓励用户在相关平台发表积极评价

8.2.3 参与行业社群

在Reddit的r/openwrt或r/archlinux子版块，或者在V2EX等技术社区，积极回答他人问题，并在适当的时候附上你文章的链接作为参考 记住：先贡献价值，再推广内容

9. JavaScript SEO

对于现代前端框架的学习，JS SEO是必修课。一个在用户浏览器里看起来华丽的SPA，在搜索引擎爬虫眼里可能只是一个空白的<div>，我们需要学会确保我们的华丽能被机器正确理解

9.1 CSR & SSR & SSG

首先，我们要理解Google爬虫Googlebot是如何处理JavaScript的。它有一个叫做网页渲染服务Web Rendering Service 的组件，本质上是一个无头浏览器。抓取流程分为两波：

1. 第一波：Googlebot抓取你的原始HTML，如果内容都在HTML里，它会立刻被送去索引
2. 第二波：如果页面需要JS来生成内容，这个页面会被放入一个渲染队列。几天甚至几周后，WRS才会执行JS，渲染出最终的DOM，然后将渲染后的HTML送去索引

9.1.1 客户端渲染 Client-Side Rendering

服务器只返回一个几乎空白的HTML壳子和一个巨大的JS包。浏览器（或WRS）下载并执行JS，然后通过API请求数据，最终将内容渲染到页面上。这是create-react-app或vue-cli默认的模式

:::yellow[特性]

1. 索引延迟：你的内容需要排队等待第二波渲染，收录速度可能极慢。对于新闻或时效性强的内内容是致命的
2. 渲染失败风险：如果你的JS代码有bug、网络请求超时、或者过于复杂导致WRS执行超时，渲染就会失败。结果就是，Google索引的是一个空白或不完整的页面
3. 抓取预算消耗：渲染需要巨大的计算资源，这会消耗你的抓取预算。Google可能不愿意为一个需要复杂渲染的小网站投入太多资源 :::

9.1.2 服务端渲染 Server-Side Rendering

用户的请求到达服务器后，服务器在后端执行React/Vue代码，获取数据，生成完整的HTML，然后将这个HTML返回给浏览器。浏览器接收到的是已经包含所有内容的页面。Next.js, Nuxt.js等框架的核心功能就是SSR

:::yellow[特性]

1. 即时索引：Googlebot在第一波抓取时，就能拿到包含所有内容的完整HTML，无需等待渲染，索引速度极快
2. 高可靠性：避免了客户端环境的各种不确定性
3. 更好的性能指标：通常有更快的FCP和LCP，对用户体验和Core Web Vitals友好 :::

9.1.3 静态站点生成 Static Site Generation

在构建时，就预先为每个页面生成一个纯HTML文件。服务器要做的只是一个简单的文件服务。Gatsby, Astro, 以及Next.js/Nuxt.js的静态导出模式都属于SSG

:::yellow[特性] 拥有SSR的所有优点，并且性能是三者中最好的，服务器响应极快

适用：博客、文档、作品集、营销网站等内容不频繁变动的网站。对于你的博客来说，SSG是技术和SEO上的最优解。 :::

9.2 动态渲染 Dynamic Rendering

在服务器层面，通过识别请求的User-Agent，来决定返回什么内容

• 如果User-Agent是普通用户浏览器，返回常规的CSR应用
• 如果User-Agent是Googlebot或其他爬虫，服务器会通过一个中间件（如Rendertron），将你的JS应用渲染成静态HTML，然后返回这个HTML给爬虫

:::yellow[为何弃用] 这曾经是Google推荐的方案，但现在已被视为一种过渡手段。它增加了系统复杂度和维护成本，并且有被误判为伪装（即给爬虫和用户看不同内容）的风险

除非你有一个无法重构的庞大CSR遗留项目，否则应该优先考虑SSR或SSG :::

9.3 JS SEO调试工具

如何确定Google到底看到了什么？不要猜，要用工具验证

1. Google Search Console - 网址检查 (URL Inspection Tool) :::blue[操作过程] 在GSC顶部输入你要检查的URL，然后点击"测试实际网址 (Test Live URL)"

测试完成后，点击"查看测试的网页 (View Tested Page)"。你会看到三个标签页：

• HTML：这是Googlebot抓取到的原始HTML
• 屏幕截图 (Screenshot)：这是WRS渲染后的页面截图，是你网站的原始面貌。如果这里是空白或者内容不全，说明你的JS渲染出了严重问题
• 更多信息 (More Info)：这里会显示页面资源（JS/CSS）是否加载失败、JS控制台有无错误等信息，是排查渲染失败的直接线索 :::

1. Chrome浏览器 - 移动设备友好性测试 (Mobile-Friendly Test) 这是一个公开的工具，即使不是站长也能用。它的底层渲染引擎和Googlebot是相同的。你可以在这里快速预览Google眼中的页面样子

9.4 编写对爬虫友好的JS代码

即使你选择了CSR，也可以通过一些最佳实践来降低渲染失败的风险

9.4.1 避免#号路由

传统的Hash路由（如xice.cx/#/page）中的#及之后的内容不会被发送到服务器，Googlebot可能不会很好地处理它。请始终使用History API的URL（如xice.cx/page），这也是所有现代前端框架的默认设置

9.4.2 提供真正的<a href="...">链接

不要用<div>或<span>加上onClick事件来模拟页面跳转。爬虫只能识别标准的<a>标签和href属性来发现新链接 ```jsx // ×××××错误××××× <span onClick={() => navigate(‘/openwrt-guide’)}>OpenWrt 指南

// ×××××爆赞×××××
<a href="/openwrt-guide" onClick={handleNavigate}>OpenWrt 指南</a>
```

9.4.3 小心处理内容注入

不要在用户滚动或点击后才加载核心内容。确保页面的主要内容在onLoad事件后是可用的

9.4.4 处理好API错误

如果你的页面内容依赖API获取，确保当API请求失败时，你的代码能优雅地处理错误，而不是直接崩溃导致整个页面渲染失败。可以考虑在服务器端或构建时就获取关键数据，减少客户端API依赖

10.图片与视频SEO

在像blog这种以文本为核心的SEO世界里，图片和视频往往被忽视。然而，对于像舞萌DX手元这样的视觉内容，或者需要大量截图的风景图集，富媒体本身就是内容的核心，也是Google图片搜索和视频搜索这两个巨大流量池的入口

10.1. 图片SEO

搜索引擎不是人类，它无法真正看到一张图片的内容（虽然AI识图技术在进步，但远未到完全依赖的程度）它依赖你提供的元数据来理解图片

10.1.1 文件名 (File Name)

• 反例：IMG_8888.jpg, screenshot-1.png
• 爆赞：maimai-dx-Xaleid_ScopiX-sssp-rank.webp

文件名是搜索引擎对图片内容的第一个，也是最直接的线索。使用简短、描述性强、用连字符-分隔的英文单词。它应该清晰地说明这张图片是什么

10.1.2 Alt文本

alt属性是<img>标签中最重要的SEO元素。它的首要目的是为了可访问性 (Accessibility)
当图片加载失败或用户使用屏幕阅读器时，alt文本会被显示或朗读出来。搜索引擎则将其作为理解图片内容的核心依据

• 反例：

• 不写alt属性。
• <img src="..." alt="图片">
• 关键词堆砌：<img src="..." alt="舞萌DX maimai DX 谱面 XaleidscopiX xi">

• 爆赞：

• <img src="..." alt="一名玩家正在游玩舞萌DX的谱面《Xaleid_ScopiX》并达成SSS+评价的结算画面">

用一句话，向一个看不见图片的人，清晰地描述这张图片的内容和上下文。 它应该自然地包含关键词，但绝不是堆砌

10.1.3. 图片尺寸与性能

巨大的图片是拖慢LCP的元凶

:::blue[EXAMPLE]

1. 响应式图片 Responsive Images
   使用<picture>标签或<img>的srcset和sizes属性，为不同屏幕尺寸和分辨率的设备提供不同大小的图片

   <img srcset="openwrt-config-small.jpg 480w,
                openwrt-config-large.jpg 1080w"
        sizes="(max-width: 600px) 480px,
               1080px"
        src="openwto-config-large.jpg"
        alt="OpenWrt防火墙配置的后台截图">
   

这能确保手机用户不会被迫下载桌面端的大图，极大提升移动端加载速度

1. 新一代图片格式
   尽可能使用WebP或AVIF格式。它们在同等视觉质量下，文件体积通常比JPEG或PNG小30%以上

2. 懒加载
   对于非首屏的图片，使用原生的loading="lazy"属性。

   <img src="arch-linux-step-10.jpg" loading="lazy" alt="...">
   

这能让浏览器只在图片即将进入视口时才开始加载，极大提升初始页面加载速度 :::

10.1.4. 图片站点地图 Image Sitemaps

如果图片是你网站的核心内容（比如一个摄影作品集），或者你的图片是通过JavaScript加载的，创建一个独立的图片站点地图可以帮助Google更好地发现和索引它们

在sitemap.xml中，为每个URL条目加入<image:image>标签，提供图片的URL、标题、说明等信息

10.2 视频SEO

视频结果在搜索页面上通常占据巨大空间，非常吸引眼球。优化得当的视频，是获取高点击率的利器

10.2.1 视频托管

1. YouTube
   YouTube本身就是巨大的流量来源，上传到YouTube的视频，在Google搜索中天然有更高的展示权重，无需担心带宽和播放体验
2. bilibili等视频平台
   更适合中国大陆的用户群体，无需担心带宽和播放体验
3. 自托管： 完全控制，无广告，可以自定义播放器，但你需要自己处理视频托管、CDN分发、播放器兼容性，并且失去了YouTube/bilibili等带来的巨大流量和Google的排名优势

10.2.2. 视频结构化数据

这是视频SEO的核心。通过在你的网页上部署VideoObject Schema，你可以明确地告诉Google关于这个嵌入视频的一切

:::blue[EXAMPLE]

• name: 视频标题（应具描述性，包含关键词）

• description: 视频描述（详细介绍视频内容）

• thumbnailUrl: 视频封面图的URL（一张吸引人的封面图至关重要）

• uploadDate: 上传日期。

  • duration: 视频时长（ISO 8601格式，如PT1M30S表示1分30秒）

• contentUrl: 视频文件本身的URL（如果自托管）

• embedUrl: 视频的嵌入播放器URL（如YouTube的嵌入URL）

  {
    "@context": "https://schema.org",
    "@type": "VideoObject",
    "name": "【maimai外部出力】PANDORA PARAODXXX 101%",
    "description": "这是一位玩家游玩maimai时录制的PANDORA PARADOXXX 101%理论值的手元视频，提供了手元参考",
    "thumbnailUrl": "https://cdn.chongxi.us/thumbnails/pandora101.jpg",
    "uploadDate": "1919-08-10T11:45:14+08:00",
    "duration": "PT2M28S",
    "embedUrl": "https://www.youtube.com/embed/qwq"
  }
  

:::

10.2.3. Key Moments / Video Chapters

Key Moments 是Google在视频搜索结果中展示的、带有时间戳的章节导航。它能让用户直接跳转到视频中最感兴趣的部分，极大提升用户体验和点击率

:::blue[EXAMPLE]

1. 在你的YouTube视频的描述区，按照时间戳 + 章节标题的格式，写下你的视频章节

2. 必须从00:00开始

3. 至少需要3个时间戳

   ```
   (0:00) intro
   (0:52) 天苍苍野茫茫风吹草低见牛羊
   (1:13) 我有玉米症
   (2:12) 登神长阶
   ```
   

当用户在Google搜索相关内容时，你的视频结果下方可能会直接出现像登神长阶等可点击的章节链接 :::

10.2.4. 视频站点地图 Video Sitemaps

与图片站点地图类似，如果你网站上有大量视频内容，创建一个视频站点地图可以帮助Google更全面地发现它们

11.品牌信号与实体

目前为止，我们所有的优化都还局限于字符串匹配的范畴
但搜索引擎的终极目标，是理解Things，而非Strings.
它致力于构建一个庞大的、关于真实世界万事万物的数据库，这就是知识图谱

11.1 什么是实体

• 字符串：“曲师xi”

• 实体：一个ID（比如/m/114_514），这个ID关联着一系列属性和关系：

- 名称: xi
- 职业: 作曲家
- 国籍: 日本
- 所属: Diverse System
- 代表作: Freedom Dive, Ascention to Heaven

- 参加过: BOF
- 作品被收录于: iidx,sdvx,maimai...

当Google能像这样理解xi时，它就能回答更复杂的用户查询，比如"xi有哪些被iidx收录的曲子？"。

我们的目标，就是帮助Google为你或你的互联网资产，也建立起这样一个实体档案

11.2 如何构建你的品牌实体

11.2.1 用Schema.org定义你自己

这是最直接、最可控的一步。通过结构化数据，你是在向Google提交一份关于你自己的实体声明

:::blue[EXAMPLE] 你应该在你的核心页面（如首页、关于我页面）部署这个Schema，而不是每一篇文章

    ```json
    {
      "@context": "https://schema.org",
      "@type": "Person",
      "name": "Chongxi", // 你的名字或网名
      "url": "/about", // 指向你"关于我"页面的URL
      "sameAs": [ // 这是关键！用它来关联你在全网的其他身份
        "https://github.com/ChongxiSama",
        "https://twitter.com/@CEPATO",
        "https://space.bilibili.com/500042199"
      ],
      "description": "一位兴趣爱好十分广泛的个人开发者",
      "knowsAbout": [ // 声明你的专业领域
        "Linux",
        "Web dev",
        "Web3",
        "Network Engineering"
      ]
    }
    ```

• sameAs属性至关重要。它像一个外键关联，帮助Google将你在不同平台上的身份碎片，整合到同一个实体之下
• 确保name在你所有的网络身份中保持高度一致 :::

11.2.2 外部验证

Google不会只听你的一面之词。它需要从它已经信任的、中立的第三方数据源中，找到关于你的信息来交叉验证

1. 寻找种子站点 Seed Sites
   Google构建知识图谱的初始数据，很大一部分来自像Wikipedia、Wikidata、DBpedia这类大型、结构化的知识库

:::blue[EXAMPLE] Wikipedia
如果你（或你的项目）的成就和知名度，已经达到了维基百科的关注度指引标准（例如，被多个独立的、可靠来源广泛报道），那么创建一个维基百科条目，是构建实体的最强信号。这是一个非常高的门槛，但威力巨大

行业权威目录
在你的领域内，是否存在公认的权威数据库或社区？

对于xi，他在各Wiki上的条目，就是强力的实体验证来源 对于一个开源项目，它在GitHub上的Repo、在SourceForge上的页面，就是它的证明 对于一个技术博主，你在Stack Overflow上的高声望个人资料、你在GitHub上贡献的项目，都是外部验证信号 你该怎么做：去这些你所在领域的权威第三方平台上，创建并完善你的个人资料或项目页面，确保信息（特别是你的名字/品牌名）与你网站上声明的一致 :::

11.2.3 全网强化

当你的实体被初步建立后，Google会开始在全网范围内寻找关于你的对话

11.2.3.1 无链接品牌提及

当一个网站或论坛上，有人提到了你的名字或博客名（比如"我昨天看了Chongxi那个三星手机用Surfing打不了电话的解决方案，很有帮助"），即使没有附带任何链接，Google的自然语言处理模型也能识别出这是在讨论你的实体

:::blue[BLUE] Google会分析提及你实体时的上下文和情感

• 积极上下文：如果你的名字经常和"推荐"、“感谢”、“解决了我的问题”、"好文"等词语一起出现
• 消极上下文：如果经常和"过时了"、“有错误”、"不推荐"等词语一起出现

这些信号会被汇总，作为评估你实体声望和影响力的依据

你可以： 鼓励讨论：在你的文章末尾，不要只说"欢迎评论"，可以说"如果你在配置中遇到任何问题，欢迎在下面的评论区或去V2EX/Reddit上带着我的blog URL提问 积极参与社群：以你的名义，去相关的技术社区贡献有价值的回答。你的每一次高质量的发言，都是在全网范围内强化你的个人品牌实体 监控你的品牌提及：使用Google Alerts或其他品牌监控工具，追踪全网提到你名字的地方。这不仅能帮你了解大家对你的看法，还能发现一些潜在的链接建设机会（比如，你可以联系提到你但没链接的站长，礼貌地请求加上链接） :::

传统的SEO让你思考如何让我的网页排名更高？
现在则让你思考一个更宏大的问题：如何让Google和全世界都认识到，我是Arch Linux这个领域里一个值得信赖的、权威的知识来源？
当你成功地将自己打造成一个实体后，你会发现你的排名会变得异常稳固，并且开始能在一些你甚至没有专门优化的相关查询上获得排名。因为Google不再是推荐你的一篇文章，而是在推荐你

12. 国际化SEO

国际化SEO是一套技术规范，旨在帮助你向搜索引擎清晰地说明：我的网站为哪些国家和/或语言的用户提供了内容，以及这些不同版本之间的对应关系是什么

做对这件事，可以避免内容因语言不同而被视为重复，并确保正确的语言版本出现在对应国家/地区的搜索结果中。做错则可能导致流量混乱，甚至排名受损

12.1 URL结构的选择

你迈向全球的第一步，也是最重要的架构决策。你有三种主要方式来组织你的多语言内容，每种方式都有其明确的技术优劣和信号强度

:::yellow[ccTLDs] 结构：chongxi.jp (日文), chongxi.us (英文)

优点：

• 最强的地理定位信号：.jp这个域名本身就在强烈地告诉Google和用户：“这个网站是专门为日本市场服务的。” 这对于获取本地排名极具优势
• 服务器地理位置灵活：你可以将.jp的服务器放在东京，.de的服务器放在法兰克福，为本地用户提供最快的访问速度

缺点：

• 成本高昂：需要注册和管理多个域名。
• 权威性分散：每个域名都是一个独立的网站，你需要为.jp和.de分别建立外链和权威性，它们之间不会自动继承

适用场景：拥有充足预算和本地运营团队的大型跨国品牌。对于个人博客，这通常不是首选 :::

:::yellow[Subdirectories/Subfolders] 结构：chongxi.us/ja/ (日文), chongxi.us/en/ (英文)

优点：

• 权威性集中：所有语言版本都在同一个主域名下，它们共享并共同贡献于chongxi.us这个域名的整体权威性。你为英文版获取的外链，其权重也会流向日文版，反之亦然。这是最大的优势。
• 维护成本低：只需管理一个网站、一个主机账户、一个SSL证书
• 设置简单：在技术上最容易实现。

缺点：

• 地理定位信号相对较弱（但可以通过GSC设置来弥补）

适用场景：对于绝大多数网站，这是最被推荐、也是最强大的方案 :::

:::yellow[Subdomains] 结构：ja.chongxi.us, en.chongxi.us

介于前两者之间。Google官方表示，他们现在能很好地处理子域名的权重传递，但SEO行业普遍认为，其权威性集中的效果仍然略逊于子目录

适用场景：当不同语言版本的网站在内容、设计甚至功能上有巨大差异，需要技术上完全隔离开时，可以考虑。例如，一个主站是电商，而日文站是一个纯内容博客 :::

12.2 核心技术实现

hreflang 是一个HTML <link> 标签属性，它的作用是向Google精确地声明：这个页面的德语版本在这里，日语版本在那里，而这个版本是默认的英文版

:::yellow[特性]

1. 解决重复内容问题：
   避免Google将你的《Arch Linux Installation Guide》的英文版和日文翻译版视为内容抄袭
2. 提供正确的搜索结果：
   确保日本用户在google.co.jp上搜索时，能看到你的日文版文章，而不是英文版 :::

:::red[实现规则] 以下实现极其严格，错一不可

1. 相互引用 Reciprocal：
   如果页面A链接到页面B，那么页面B也必须链接回页面A
2. 自引用 Self-referential：
   每个页面都必须有一个指向自己的hreflang标签
3. 包含x-default：
   你应该指定一个默认或后备版本，当用户的语言或地区与你提供的任何版本都不匹配时，他们会被导向这个版本 :::

:::blue[EXAMPLE] 假设文章有三个版本：

• 英文版 (默认): /en/music/xi
• 日文版: /ja/music/xi
• 简体中文版: /zh-hans/music/xi

那么，在这三个页面的HTML <head>区域，都必须包含完全相同的以下代码块：

```html
<link rel="alternate" hreflang="en" href="/en/music/xi" />
<link rel="alternate" hreflang="ja" href="/ja/music/xi" />
<link rel="alternate" hreflang="zh-Hans" href="/zh-hans/music/xi" />
<link rel="alternate" hreflang="x-default" href="/en/music/xi" />
```

语言和地区代码：

• 必须使用 ISO 639-1 格式表示语言（如 en, ja, zh）
• 可以追加 ISO 3166-1 Alpha 2 格式表示地区（如 en-GB 表示英国英语，en-US 表示美国英语）
• 注意：zh-Hans和 zh-Hant是例外，它们是脚本代码

部署方式：

• HTML <head>：最常用，如上例
• HTTP 响应头：适用于非HTML文件（如PDF）
• XML站点地图：当页面数量巨大时，这是最高效、最推荐的管理方式 :::

12.3 内容与服务器

技术标签只是基础，内容和体验才是决定成败的关键

内容本地化，而非机翻：

• 不要简单地用Google翻译你的 OpenWrt旁路由教程 你需要一个真正懂技术也懂目标语言的人来做本地化

本地化意味着：
将文章中的界面截图换成对应语言的版本、使用当地技术圈的惯用术语、甚至根据当地用户的网络环境（如ISP特点）提供特定的建议

服务器地理位置：

• 虽然CDN在很大程度上解决了全球访问速度问题，但将你的服务器托管在你的主要目标用户所在的地区，仍然是一个积极的排名信号

Google Search Console 地理位置定位：

• 对于使用gTLD（如.com, .net, .org）并采用子目录或子域名方案的网站，你可以在GSC的旧版工具中找到International Targeting去report
• 你可以明确告诉Google：/ja/子目录下的内容，是专门面向日本用户的，这可以弥补gTLD在地理定位信号上的不足

国际化SEO非常精密，它要求你在URL架构上做出战略决策，在技术实现上严格遵守hreflang规范，并在内容层面真正做到为本地用户着想。做好了，你就能真正地放眼全球；做错了，则可能导致一场混乱的SEO灾难，比如Google把你的各个翻译版本当作抄袭内容全给你干掉

13. 本地SEO

Local SEO 是一系列旨在提升你的业务或网站在特定地理区域的搜索结果中可见性的优化策略。对于拥有实体店面、提供区域性服务的企业，或者希望吸引特定城市用户的本地社区博客来说，本地SEO是生死线

它的核心逻辑是：当用户的搜索查询带有明确（如广州 舞萌DX机厅）或隐含（如在广州打开手机搜索 附近的舞萌机厅 ）的本地意图时，搜索引擎的排名算法会引入一组全新的、权重极高的本地排名因素

13.1 本地SEO三大核心

13.1.1 邻近性 Proximity

这是最简单粗暴，也是权重最高的因素
用户搜索时，离他物理位置越近的业务，排名越有优势。这一点我们几乎无法优化，它是物理意义上的定律

13.1.2 相关性 Relevance

你的业务与用户的搜索查询有多匹配。这与我们之前讨论的传统SEO原则类似，但更侧重于本地化的内容和服务，你搜菜馆是绝对不可能弹出舞萌机厅的搜索结果的

13.1.2 知名度/权威性 Prominence

你的业务在本地有多出名、多受好评、多被信任。这部分是我们优化的重点

13.2 Google Business Profile 的深度优化

Google Business Profile（曾用名Google My Business）是本地SEO的绝对核心，是你在Google地图和本地搜索结果包中的官方名片。你必须像对待你的网站一样，精细化地优化它

1. 信息的准确与一致性

• NAP 指的是 Name, Address, Phone 这三个信息，必须在你全网所有的商业信息中，保持100%的、字符级的完全一致

:::blue[EXAMPLE]

• 你的GBP名称、官网联系页、本地行业网站上的公司名，是否完全一样?

  • XX科技 和 XX科技有限公司 在算法眼里就是两个不同的实体

• 地址的写法是否统一？

  • 人民路123号 & 人民路123号

• 电话号码格式是否一致？ :::

NAP的全局一致性，是Google用来验证你业务真实性的核心信号。任何不一致都会让它对你的实体信息产生怀疑

1. GBP分类

• 如果你有一个主要类别和多个次要类别。主要类别应选择最能代表你核心业务的那个

:::blue[EXAMPLE]

• 一个主要卖openwrt路由器技术支持服务的公司，主要类别应是 IT顾问 或 计算机支持与服务
• 一个舞萌DX机厅，主要类别是 游乐中心 或 电玩城

尽可能详细地选择所有与你业务相关的次要类别 :::

1. 评论 评论的数量、星级评分、以及评论内容中出现的关键词，都是强烈的排名信号 :::blue[EXAMPLE]

• 主动索要评论：在服务完成后，通过邮件或短信，礼貌地邀请满意的客户留下评论，并可以直接提供你的GBP评论链接
• 回复每一条评论：无论是好评还是差评，都要专业、及时地回复。这向Google和用户展示了你的积极和负责。在回复中，可以自然地再次提及你的服务或产品名称 :::

1. Google Posts Q&A

• Google Posts：相当于GBP上的一个迷你博客。你可以用它来发布最新活动、产品介绍、优惠信息。帖子有时效性，需要持续更新
• Q&A：用户可以在你的GBP上提问。你应该主动在这里发布一些常见问题并自己回答， preemptively地解决用户疑虑

13.3 站内本地化优化

你需要让你的网站内容也充满本地信号

本地着陆页

• 如果你在多个城市提供服务，你应该为每个城市创建一个独立的、内容独特的着陆页

:::blue[EXAMPLE] chongxi.us/openwrt-support/Tokyo 这个页面上应包含：

• 标题和H1中明确包含城市名（如东京OpenWrt上门配置服务）
• 页面正文中详细描述你在Tokyo地区的服务特色
• 嵌入该地区办公室的Google地图
• 展示来自Tokyo本地客户的评价。
• 提供本地的电话号码 ::: LocalBusiness Schema
• 在你网站的联系页或页脚，部署LocalBusiness Schema，用结构化的方式告诉搜索引擎你的NAP、营业时间等信息

13.4 本地引用

就是指在互联网上任何一个地方，提及了你的业务的NAP信息，即使没有链接到你的网站

来源一般是：本地商会网站、行业协会目录、在线地图（如高德、百度地图）、大众点评等
与GBP一样，保持NAP信息在所有引用来源中的100%一致性

建议高强度自搜你自己的品牌，检查并修正那些不一致的引用信息

14. 对话AI SEO

语音搜索代表了搜索行为的一种演变：从关键词到自然语言问句。用户不再敲 OpenWrt adguardhome dns ，而是直接问智能音箱：嘿Google，怎么在OpenWrt上设置AdGuard Home来过滤DNS？

为语音搜索优化，本质上是更好地回答问题

14.1 理解语音搜索查询的特点

1. 更长、更口语化：语音查询平均更长，通常是完整的问句
2. 意图更明确：通常是寻求一个直接、简洁的答案
3. 本地属性强：大量语音搜索与“附近的…”相关

14.2 精选摘要

精选摘要是出现在Google搜索结果最顶部的、一个直接回答用户问题的特殊信息框。语音助手（如Google Assistant）在回答问题时，通常会直接朗读精选摘要的内容。 因此，赢得精选摘要，就等于赢得了语音搜索

:::blue[EXAMPLE]

1. 识别问题类查询：用GSC或第三方工具，找出你的网站已经排在第一页的、以“如何”、“是什么”、“为什么”开头的查询
2. 提供简洁、直接的答案：在你的文章中，紧跟着问题标题（H2/H3），用一段话（通常在40-60个词之间）直接、清晰地回答这个问题

比如

H2：<h2>什么是OpenWrt的旁路由模式？</h2>
紧随其后的段落：<p>OpenWrt的旁路由模式，指的是在不改变现有主网络结构的前提下，将一台运行OpenWrt系统的设备作为旁路网关接入局域网。它不负责主要的路由和DHCP功能，而是专门处理特定任务，如广告过滤、科学上网或网络加速，实现对全屋设备的透明代理
这个段落的结构和长度，就是精选摘要的完美候选者

1. 使用有序/无序列表：对于步骤或列表类问题，使用<ol>或<ul>标签来组织内容
2. 利用FAQPage Schema：为页面上的问答内容部署FAQPage Schema，可以增加你被选为精选摘要的几率 :::

14.3 让内容更具对话性

写作风格：在写作时，想象你是在直接回答一个朋友的问题。使用更自然、更口语化的语言
内容结构：多使用问答式的结构来组织你的文章

当然，注意受众，如果你的网站不需要对话式AI，那就没必要做此部分优化

15. 监控与优化

15.1 Google Search Console

GSC是Google直接提供给你的免费工具，是所有SEO工作的起点和终点。它告诉你Google如何看待你的网站

15.1.1 GSC基本设置

:::blue[基本设置]

1. 验证你的网站所有权： 登录GSC，添加你的网站域名。Google会提供多种验证方式。对于技术人员，最推荐的是DNS记录验证。你需要登录你的域名提供商（如Cloudflare），添加一条Google提供的TXT记录
   这种方式一次验证，你的域名下所有的子域名和协议（http/https）都会被覆盖，一劳永逸

2. 提交你的Sitemap：

   • 左侧菜单栏 > 索引 > 站点地图 (Sitemaps)
   • 在“添加新的站点地图”输入框中，填入你站点地图的URL（比如/sitemap.xml），然后点击提交
   • 这相当于你主动给Google递上了一份你网站的最新内容清单。当你发布新内容后，只要你的站点地图更新了，就可以来这里重新提交一次（或者等Google自己来抓取）。这会加快新内容的发现速度。提交后，你可以看到Google是否成功处理了你的站点地图，以及发现了多少个URL。如果状态显示“有错误”，你必须点进去查看详情并修复它 :::

15.1.2 解读Performance

这是你最常访问的报告。它告诉你，用户在Google上搜了什么，看到了你几次，点击了你几次，以及你排在第几

:::blue[EXAMPLE]

• 总点击次数 (Total clicks)：用户从Google搜索结果点击进入你网站的次数
• 总展示次数 (Total impressions)：你的网页出现在用户搜索结果屏幕上的次数。只要出现就算，不一定被用户看到或点击
• 平均点击率 (Average CTR)：点击次数 / 展示次数。这是衡量你的搜索结果吸引力的核心指标
• 平均排名 (Average position)：你的网页在搜索结果中的平均位置 :::

:::yellow[实战分析 I]

1. 进入“效果”报告。在下方的表格中，点击“查询 ”标签页。点击筛选器按钮（三条横线），设置排名 小于 10.1（筛选出排在第一页的结果）。然后，点击表格头部的“展示次数”进行降序排列

2. 寻找那些展示次数很高，但CTR明显低于其所在位置应有水平的关键词

排名第1的CTR约25-30%，第3约10-15%，第5约5-8%，第10约1-2%

1. 你发现你的查询“Arch Linux i3wm 配置”每月有20000次展示，平均排名是4.5，但CTR只有2%

这意味着你的内容质量足够好，Google愿意把它排在首页靠前的位置。但是，当用户看到你的搜索结果时，他们没有选择点击你。问题99%出在你的门面上，你的<title>标签和<meta name="description">

4.立即去Google搜索这个词，看看排在你前面和后面的竞争对手的标题是怎么写的。他们是不是用了[终极指南]、[附完整配置文件]、等更吸引人的字眼？

1. 重写你的标题和描述。不要只是Arch Linux i3wm 配置。尝试改成：从零开始的Arch Linux i3wm美化指南 (附Polybar/Rofi/Picom完整配置)

2. 提交URL以供重新索引：修改完代码后，复制这个页面的URL，粘贴到GSC顶部的“检查任何网址”输入框中，回车。在检查结果页面，点击“请求编入索引 (Request Indexing)”。这会告诉Google你更新了页面，主动请求索引

3. 持续追踪：在接下来的一两周内，每天回到这个报告，筛选出这个关键词，观察它的CTR是否有了显著提升 :::

:::yellow[实战分析 II]

1. 在“效果”报告中，设置筛选器排名 大于 10.1 且 排名 小于 30.1

2. 这里列出的，就是所有排在Google第二、三页的关键词。这些就是潜力股

3. 你发现“OpenWrt DNS泄露”这个查询，你排在第18位

4. 这说明Google已经认可了你页面的相关性，但还不足以让它登上首页。你需要给它临门一脚让他飞起来

5. 打开你对应的文章。你是否只讲了基础配置？你能不能补充一节，专门讲如何通过iptables规则来强制接管所有设备的DNS请求，来尝试杜绝DNS泄露？你能不能加入一段关于DoH/DoT的对比和配置方法？

6. 在你网站其他高权重的相关文章里（比如你的《OpenWrt旁路由配置指南》），找到合适的锚文本（比如“防止DNS泄露”），链接到你这篇排在第18位的文章。这相当于用你站内的明星页面给这个潜力页面投了一张信任票

7. 如果可能的话，去相关的技术论坛（如恩山、V2EX），看看有没有人在讨论DNS泄露问题，你可以提供专业的解答，并在签名或回答中自然地附上你的文章链接 :::

15.1.3 解读Indexing

路径：左侧菜单栏 > 索引 > 网页 (Pages)

核心关注： 报告分为“已编入索引”和“未编入索引”两部分。你需要重点关注“未编入索引”的原因 :::blue[EXAMPLE] 你在“未编入索引”的原因列表中，看到“已发现 - 当前未编入索引 (Discovered - currently not indexed)”下面有50个网址

诊断：这是个坏消息。意思是Google的爬虫已经发现了这些URL（通过站点地图或链接），但它认为这些页面的质量太低，以至于连进入它索引库的初审资格都没有。这可能是因为内容太单薄、与其他页面高度重复，或者是新网站权威性太低，Google不愿意分配索引配额给你

你应当

1. 逐个审查这些URL。它们是不是你自动生成的、没有什么实质内容的标签页或归档页？如果是，让它们noindex掉
2. 如果这些是你用心写的好文章，那问题就出在内容质量或网站权威性上。你需要：把文章写得更深入、更有见地，也可以为这些页面从站内和站外获取更多高质量的链接 :::

15.2 Google Analytics 4

GA4告诉你用户进入你的网站后都做了什么。它能帮你判断你的内容是否真的满足了用户需求

:::yellow[实战分析 I] 识别叫好不叫座的内容

1. 路径：报告 > 互动度 > 着陆页 (Landing pages)

2. 这个报告列出了用户进入你网站的第一个页面。默认按“用户数”排序。现在，点击表头的“平均互动时长 (Average engagement time)”进行升序排列

3. 你发现你的《舞萌DX全曲目列表》页面，虽然带来了很多用户（用户数列前茅），但平均互动时长只有15秒

4. 诊断：用户来了，但马上就走了

这通常意味着：

• 你的页面加载太慢
• 页面设计混乱，用户找不到想要的信息
• 内容虽然全面，但呈现方式很差（比如就是一个巨大的、无法搜索和筛选的HTML表格）

1. 优化页面体验：为这个曲目列表加入客户端搜索、排序和筛选功能。让用户可以按难度、按版本、按作曲家（比如xi）快速找到他们想要的曲子

2. 提升加载速度：如果列表包含大量图片（封面），确保它们都经过压缩并使用了懒加载 :::

:::yellow[实战分析 II] 追踪转化，找到你的现金牛

1. 你需要先在GA4中设置“转化 (Conversions)”。转化不一定是指金钱交易。对于博客，一个转化可以定义为“用户成功复制代码块”、“用户下载了你的OpenWrt配置文件”或“用户在教程页面停留超过5分钟”

2. 路径：流量获取 > 流量获取 (Traffic acquisition)

3. 数据解读：查看报告，将主要维度设置为“着陆页 (Landing Page)”，并查看每个着陆页带来的“转化次数”

4. 发现案例：你发现你的《Arch Linux安装后十大必装软件》这篇文章，带来的“复制代码块”转化次数遥遥领先，远超其他文章

5. 诊断：这篇文章精准地抓住了用户的行动意图。用户看完这篇文章后，会立刻动手操作。这是一篇极具价值的行动指南抄作业型内容

6. 围绕这个成功模式，创作更多类似的内容。比如 Arch Linux下最佳的5款终端模拟器配置

7. 流将这篇高转化文章，放在你网站更显眼的位置（如首页推荐），并从其他文章中多链接到它 :::

16. 历史遗留问题说明

16.1 meta name="keywords"

这是一个曾位于HTML <head>区域的元标签，允许网站管理员主动告诉搜索引擎，这个页面与哪些关键词相关

        <meta name="keywords" content="舞萌DX, maimai DX, 谱面, 攻略, xi, 白系">

在搜索引擎的蛮荒时代，算法还无法精准地通过分析页面内容来判断其主题。因此，它需要网站管理员提供这样一份自我介绍

但这个标签的设计存在一个致命缺陷：它完全依赖于网站管理员的诚信。很快，黑帽SEO们开始疯狂地滥用它，在其中堆砌大量热门但不相关的关键词来骗取流量（比如在一个Arch Linux教程页面里加入免费电影下载）

这种行为严重污染了搜索结果，导致用户体验急剧下降。为了自救，搜索引擎被迫进行算法革命，学会了依靠自己的能力去理解内容，而不是轻信网站的自白

这是防君子不防小人的典型案例

:::yellow[死刑宣判] Google在2009年就已公开宣布，在排名算法中完全忽略meta name="keywords"标签

Bing等其他主流搜索引擎也已明确表示，这个标签几乎没有任何价值 :::

• 对于新站长，完全不必要使用这个标签
• 对于老站长，如果你的网站还留有这个标签，也不需要浪费时间去删除它。它无益也基本无害。就让它安靜地躺在那里，作为互联网发展史的一块化石吧

这就是为什么，全篇下来我没有提到meta keyword的任何事情，如果一篇2025年的SEO教程还在教你如何优化meta keywords，你可以释怀地笑了，作者知识体系至少落后了15年

16.2 传统PageRank评分

这是一个曾经在Google工具栏上显示的，从0到10的整数评分，用来表示一个网页的链接权威性

在长达十多年的时间里，PR值是整个SEO行业最直观、最可量化的权威性指标，直接催生了庞大的链接交易市场

为何暴死? (我们在3.3节已经详细拆解了)它的公开性导致了大规模的算法操纵，破坏了搜索生态的公平性

:::yellow[死刑宣判] 2013年，PageRank被隐藏 2016年，被Google彻底移除 :::

任何声称可以查询你网站“PR值”的第三方工具，显示的都是毫无意义的、过时的数据，或者是一个他们自己发明的、与Google无关的指标（如Ahrefs的DR, Moz的DA）

忘掉PR值这个概念吧，不要再问我的网站PR值是多少了
将你的精力投入到获取主题相关、上下文合理、能带来真实流量的高质量链接上，而不是去追求一个早已不存在的虚幻分数，这才是现代的Rank

16.3 其他历史遗留观念

16.3.1 “关键词密度必须达到X%”

过去，一些人认为页面中某个关键词的占比（如2-5%）是影响排名的关键

这是一个极其过时的观念。现代搜索引擎使用BM25和NLP模型，更关注关键词的位置（标题、H1）、上下文、同义词和语义相关性。自然地写作，让关键词和相关主题词合理地出现在它们应该出现的地方即可。刻意追求某个密度，只会让你的文章变得语句不通，反而有害

16.3.2 “域名年龄越老越好”

过去人们普遍认为老域名有排名优势。

Google的John Mueller已多次澄清，域名年龄本身不是一个排名因素。老域名之所以看起来有优势，是因为它们有更长的时间去积累内容和高质量的外链。一个全新的域名，如果能快速地构建出卓越的内容和权威性，完全可以超越一个内容停滞多年的老域名。重要的是域名的历史记录，而非年龄本身

17. SEO anti

17.1 付费外链

骗子话术一般为 “我们手上有数千个高权重网站资源，可以为你发布带有链接的文章” “只需XXX元，即可获得一条来自DA 50+（或其他自创指标）网站的dofollow外链”

解构一下就是

1. Private Blog Network：这是最常见的一种。骗子们会去购买一堆过期但曾经有过一点权重的域名，然后用模板化的程序快速建立大量看起来“正常”的博客。这些博客的存在只有一个目的——出售链接。它们内容质量低下、主题混乱、互相链接，形成一个虚假的“权重网络”

2. 被黑的网站：更恶劣的情况是，他们利用漏洞黑进一些正常的网站，然后在这些网站上偷偷地添加指向客户的链接

3. 低质量的客座博客：他们会在一些允许任何人付费发布文章的低质量新闻源或博客上，发布一篇由AI生成的、语句不通的垃圾文章，并在其中插入你的链接

:::blue[Google如何把它们送上绞刑架] Google的反作弊团队拥有极其复杂的算法和人工审核流程来识别这些非自然链接

1. Link Graph Analysis：Google能分析整个互联网的链接拓扑。PBN网络中的网站，其链接模式通常极不自然（比如，只出链不入链，或者只在特定的小圈子里互相链接），很容易被算法识别为链接农场

2. 锚文本滥用检测：如果一个新网站在短时间内，突然获得了大量指向它的、锚文本完全相同的（比如都是“OpenWrt路由器推荐”）外链，这是一个极其危险的信号。自然的链接，其锚文本应该是多样化的

3. 网站质量评估：Google会评估发布链接的网站本身的质量。一个正常的网站，其内容应该是有主题、有规律更新、有真实用户访问的。而PBN上的网站，通常内容杂乱、更新停滞、没有任何自然流量

4. 人工举报与审核：你的竞争对手，或者任何一个懂SEO的人，都可以通过Google的“举报付费链接”工具，将可疑的链接交易报告给Google

• 一旦Google的算法或人工审核员确认你的网站参与了大规模的链接操纵，你的Google Search Console就会收到一条“不自然的外部链接”手动操作惩罚通知
• 你的网站排名会断崖式下跌，甚至从Google的索引中被彻底移除
• 你需要手动找出所有购买的垃圾链接，联系对方站长请求移除（通常会被忽略或勒索），然后使用GSC的“Disavow Tool（拒绝链接工具）”向Google提交一份你不承认的垃圾链接列表，并写一份Reconsideration Request，请求Google的原谅。整个过程可能持续数月，且不保证成功 :::

各位站长最好也放下投机的念头，酒香不怕巷子深。回顾前文，真正的权威性，来自于创作出值得被链接的“可链接资产”，通过数字公关和社群贡献，让高质量的链接自然地发生。这很难，很慢，但这才是唯一正确的、可持续的道路

17.2 关键词堆砌

骗子话术：“你的页面关键词密度不够，我们需要帮你优化到5%”

如我们在第十六章所述，这是一个石器时代的观念。现代NLP算法会认为这是在降低内容可读性，反而可能给予负面评价

17.3 “提交到XXX个搜索引擎”服务

骗子话术：“我们能把你的网站一次性提交到全球500个搜索引擎”

99.99%的搜索流量来自Google, Bing, 百度等少数几个巨头。这些巨头不需要你手动提交，它们的爬虫会自动发现你的网站。这项服务提交的，是几百个你从未听说过的、毫无流量的垃圾搜索引擎，纯属心理安慰，毫无价值

17.4 购买社交媒体信号

骗子话术：“购买10000个Twitter转发，能提升你的SEO排名”

Google已明确表示，社交媒体上的“点赞”、“分享”数量不是直接的排名因素。虽然广泛的社交分享可能带来间接好处（如品牌曝光、引流，从而可能带来自然外链），但购买虚假的、来自机器人账号的信号是完全无效的，只会被算法轻易识破

18. 结语

本文的目的很简单，让每一个现代站长，都能理解现代搜索引擎和SEO，我一直强调的都是现代。我在各大论坛看到的很多关于SEO的优化都充斥着毫无意义的洗稿，现在已经是2025年了，仍有自称SEO专家还在教堆砌关键词、外链购买等操作，此篇文章就是为了极其锐利地打烂他们所谓专家的脸面

本篇与《现代搜索引擎深度解析：从原理、算法到高效检索实践》是互补的关系，强烈建议您了解前作，>点击跳转

毕竟是个人编写，精力有限，欢迎指出错误。转载请标明出处，感激不尽

相信各位折腾root情况下透明代理模块时，都可能会遇到一个非常棘手的问题：

手机网络数据一切正常，但无法拨打或接听电话，短信收发也出现异常

第一反应可能是信号问题，但通常会发现信号是满格的。这其实是一个由代理软件和系统底层VoLTE服务冲突导致的典型问题。

1. 问题分析

现在的HD通话是这样实现的

在LTE/NR网络下，通话和短信并非通过传统电路，而是依赖于IMS服务，我们熟知的VoLTE就是其最常见的应用

IMS服务本身也是通过IP数据包与运营商的核心网络进行通信的。而Surfing这类透明代理模块，为了实现全局代理，其默认的TUN 模式会在系统层面创建一个虚拟网卡，强制接管设备上几乎所有的网络流量。

当VoLTE/IMS的信令流量也被这个虚拟网卡接管后，这些对延迟和路由极为敏感的数据包被错误地进行了代理、重定向或分流，就会导致IMS服务注册失败或频繁掉线使电话无法正常拨打

不是信号问题，而是VoLTE信令被透明代理劫持了

2. 解决方案

本质上就是让通话相关的核心服务流量，绕过透明代理，直接与运营商网络通信

:::red[注意缩进!] yaml对缩进有非常非常极端的要求，少一个空格多一个空格都会导致整个炸锅，敢多space他就敢跟你爆了 :::

2.1 方案一 Samsung用户优先尝试

这是最简单直接的方法，让代理排除受影响的App

需要排除的包名列表 (主要针对三星 OneUI):

com.qti.qcc                  # 高通IMS/VoLTE 调度核心
com.sec.imsservice           # 三星IMS服务(VoLTE/VoWiFi)
com.sec.epdg                 # VoWiFi ePDG隧道服务
com.samsung.android.messaging        # 系统官方短信
com.samsung.android.dialer           # 拨号器
com.samsung.android.incallui         # 通话界面
com.samsung.android.app.telephonyui  # 通话UI资源
com.samsung.android.smartcallprovider # 来电识别
com.samsung.android.intellivoiceservice # 智能语音降噪
com.android.settings

（注：非三星手机可根据自身情况，尝试排除 com.android.imsservice 等原生IMS服务包名）

2.1.1 操作流程(以surfing为例)

• 使用 MT管理器 等工具，打开 Clash 配置文件，路径通常为：/data/adb/modules/box4magisk/config.yaml。
• 找到 tun: -> exclude-package: 部分（约是137~146行)
• 取消这些包名前面的 # 注释，如下图所示
• 保存配置文件，然后重启

此方法对大部分三星手机有效。如果操作后问题依旧，或者您的手机并非三星也遇到了类似问题，请直接尝试方案二

2.2 方案二：切换至 Tproxy

如果方案一无效，或者您想追求一个更稳定、更彻底的解决方案，那么将代理模式从 TUN 切换到 Tproxy 是最佳选择，这绝对是最通用的方案

2.2.1 为什么是Tproxy？

• TUN 模式是应用层逻辑，可以当作全盘接管，排除法有时不够彻底，不严谨的话，可以理解为VPN那种全盘接管
• Tproxy 模式配合 iptables 在更底层的内核层面工作，可以实现更精确的流量控制。模块通常会预设好规则，从一开始就绕过系统内部和运营商的通信流量，只代理用户App的流量，从根源上避免了冲突
• 更何况，Surfing用的是Mihomo内核，真想玩TUN建议使用sing-box，后者在TUN做的优化更好，可以说是代理业界天花板

2.2.2 具体操作

修改Clash配置文件，启用Tproxy监听

• 打开 /data/adb/modules/box4magisk/config.yaml。
• 关闭TUN

  tun:
    enable: false  #把这里改成false
    # ... 其他设置保持不变
  

• 启用Tproxy 在TUN和DNS模块中间增加以下内容

  tproxy:
    enable: true
    port: 1536 # 注意：此端口号必须与 tproxy-port 和模块脚本使用的端口一致，Surfing默认1536，视你的配置跟随变动，端口在文件顶部的`tproxy-port`
  

• 重启

3. 结

本篇主要是提供具体的解决方案，关于这部分的代理知识后续可以单独分篇来讲（又挖坑）

使用者应对自身行为负全部责任。请确保在使用相关技术时遵守所在国家/地区的法律法规。任何利用本文所述技术从事违法活动的行为，均与本文作者无关。

技术本身并无善恶，关键在于使用者的意图与方式。正如教授化学知识不必为制毒承担责任，传授编程技术不必为编写恶意软件负责，本文仅止于技术探讨的边界。 :::

0. 前言

NekoBox for Android 是一个基于 sing-box 核心的通用代理工具。本文将教你精通Nekobox的使用，高度定制分流规则

0.1 为什么选择Nekobox？

• 搭载目前最先进的 sing-box 核心，支持包括 Reality 在内的所有最新最热协议
• 提供精细到单个应用、单个域名、单个 IP 的流量路由规则
• 完全开源，杜绝任何可能的隐私泄露
  当然，不保证代理服务器是安全的

0.2 SagerNet和Nekobox

SagerNet 是旧时代的多协议代理客户端，已停更归档
NekoBox 是它的现代继承者，目前最强大的Android代理客户端

1. Nekobox基础配置

1.1 下载与安装

下载链接

:::blue[Tips]

• 下载 arm64-v8a 版本的 .apk 文件
• 首次启用需要添加VPN配置(点击允许即可)
• 建议将 App 加入电池优化白名单，防止后台被系统清理 :::

1.2 导入配置

机场用户配置指南

1. 打开左上角侧边栏
2. 点击「分组」
3. 点击页面右上角进入分组设置
4. 分组名随意填写，分组类型更改为订阅，在订阅链接中填写您机场给出的代理订阅URL。

推荐开启最下方的自动更新
selector视情况而定

1. 点击右上角即可保存
2. 返回主页选择节点启用即可

单个节点导入

点击主页右上角，导入配置

• 方法一：从剪贴板导入
  示例配置URL

trojan://114514@xice.cx:1080/?type=tcp&security=tls#%E7%A4%BA%E4%BE%8B

• 方法二：扫描二维码 图例
• 方法三：手动填写各项参数

2. VPN & 仅代理怎么选择？

在Nekobox的设置选项中，您可以看到模式选择，接下来我们简单了解一下他们的工作实现

2.1 VPN 模式

工作原理： 此模式会启用 Android 系统的 VpnService API，创建一个虚拟网络通道。 系统会自动将绝大多数 App 的流量转发到这个通道，从而交由 NekoBox 处理。

:::green[注意] 通常情况下，您只需要选择该模式即可 :::

2.2 仅代理模式

工作原理： 此模式不会创建 VPN 通道。它只会在你的手机上启动一个本地的 SOCKS5 和 HTTP 代理服务器。手机上的 App 不会自动使用这个代理。 以下场景才会用到该模式

1. 局域网共享： 在「设置」中开启“允许来自局域网的连接”，其他设备（如电脑）可以手动设置代理，地址为你手机的局域网 IP，端口在 NekoBox 的代理设置中查看
2. 特定应用手动代理： 某些特殊应用（如 Termux、Firefox）支持手动设置代理服务器，你可以将它们指向 NekoBox 启动的本地代理。
3. 开发者调试时使用

:::red[CAUTION] 除非你明确知道自己要做什么，否则不要选择此模式，这可能会导致你无法正常使用 :::

3. 设置内容配置

3.1 软件设置

• 自动连接：启动时自动连接代理服务器
• 运行模式：本文 2.0 部分提到的两种模式，正常情况下选择VPN即可
• TUN实现：TUN共有三种模式，system,gvisor,mixed。默认gvisor

如果您对TUN运作感兴趣，推荐阅读此文章的TUN部分详解文章链接

• MTU：不建议随意更改，维持默认
• 唤醒锁：开启后会维持开启状态，但是会增加耗电
• 自定义配置：参见Nekobox官方文档(文末附录)

3.2 路由设置

:::yellow[分应用代理]

• 关闭：不启用分应用代理

• 代理：仅代理选中的应用

• 绕过：不代理选中的应用 :::

• 绕过局域网地址：开启后不会代理局域网地址如192.168.1.1，建议开启

• 在核心中绕过LAN：即使TUN捕获到局域网流量，也会在sing-box核心内直接发送到目标局域网地址，不再发往代理出口。强烈建议开启，否则会引起一系列局域网上的诡异问题

:::yellow[流量探测] 流量探测 也就是在握手阶段抓SNI / TLS / HTTP Host以得到真正的域名 因为有些App直接连IP，没有域名，这样分流规则就用不上

• 结果用于路由判断：嗅探出的域名只用于分流规则判断，但不改实际连接目的地。通常情况选择此模式

• 用于目标地址：嗅探出的域名不仅用于分流，还会被重新DNS改变真实连接IP，不推荐选择，除非你知道你在做什么 :::

• 解析目标地址：当你访问的是域名时，核心会重新DNS解析一次，可以解决一部分可能的DNS泄漏。

• IPv6代理：建议直接禁用，否则会出现一系列逆天问题

3.3 DNS设置

• 启用DNS路由：让DNS 查询本身也走代理的路由规则，而不是直接让系统去问本地/运营商/路由器。强烈建议开启
• 启用FakeDNS：也就是Fake-IP，接管所有 DNS请求，对需要代理的域名返回一个FakeIP。App访问这个假IP时，流量被TUN捕获，NekoBox根据FakeIP对应的域名进行路由判断，然后通过代理或直连与真实IP建立连接。强烈建议开启。 剩余未提及的设置项可以参见官方文档

4. 分流示例

4.1 分应用代理

视个人情况选择绕过/代理模式，我们更推荐您在分应用代理中对应用分流

4.2 自定义规则

在添加规则前，请充分了解文档，否则您可能无法访问互联网

Nekobox默认的路由规则直接启用即可，对于普通用户已完全够用。
如果需要自定义单个域名/app/IP的代理，可以如下操作

比如我想让ChatGPT单独走美国分流

应用:ChatGPT
outbound:<选中额外的美区节点>

又或者我想让tgk-wcaime.wahlap.com单独走UsgPASS代理，且不影响主代理

domain:tgk-wcaime.wahlap.com
outbound:<UsgPASS Proxy>

关于DNS，貌似没有最优的解决方案，对于普通用户，维持默认设置即可

5. 结

NekoBox是一款拥有极高上限的代理工具。它的默认设置足以满足日常需求，但其真正的魅力在于其绝佳的分流规则以及对协议的广泛支持。

如果您的设备恰好Root的话，可以了解一下更底层的代理方案: Box4Magisk

附Nekobox官方文档

鉴于 Astro 在博客发展过程中出现的问题日益增多，不得不对其进行底层重构，将框架迁移至 Hexo

Astro 的 Sitemap 问题已经修复了半年多，气笑了

What’s New

1. 完整集成 Gitalk 评论系统
现在，您可以直接使用 GitHub 账户对博客内容进行评论。

2. 文章推荐功能
基于 Nodejieba 实现的文章推荐功能，支持 PC 端和移动端显示不同数量的推荐文章。

3. pangu.js 中英文自动排版
现已支持中英文自动 pangu 排版。关于 pangu.js 的详细信息，请参见 GitHub: pangu.js。

4. 瀑布流照片墙
新增瀑布流样式相册显示功能。

5. Mermaid JS 支持
现在允许直接使用 Mermaid JS 语法绘制图表。

e.g.

graph TD
    A[xice.cx] --> B(content);
    A --> C(category);
    A --> D(tag);
    A --> E(about);

6. MathJax 公式支持 允许使用 MathJax 直接渲染数学公式。

e.g.

在 Minecraft 中，末地要塞的生成逻辑较为复杂，通常会在距世界原点一定距离的环形区域内生成。假设在给定区域内，找到末地要塞的近似概率 $P$ 可以粗略表示为：
$$P \approx 1 - \left(1 - \frac{N_{fortress}}{N_{chunks}}\right)^{N_{attempts}}$$
其中：

• $N_{fortress}$ 为给定区域内末地要塞的平均数量（通常为3个）。
• $N_{chunks}$ 为末地要塞可能生成的总区块数量。
• $N_{attempts}$ 为玩家在给定区域内搜索的尝试次数或探索的区块数量。
  这个公式是一个简化模型，实际生成机制更为复杂，但它提供了一个理解概率的视角。

Fixed

1. 修复了 Sitemap 生成问题。
2. 为旧文章 URL 添加了 301 重定向，现在访问旧 URL 将自动跳转至新文章 URL。
3. 修正了部分文章的元信息。

To Do

1. 优化部分文章内容。
2. 优化博客图片及其他资源元素。

本文旨在系统梳理现代搜索引擎的体系结构、核心算法与信息检索方法，来源于经验及研究总结，难免有疏漏之处，欢迎指出。

本篇与《现代SEO深度解析：原理、算法与实战》是互补的关系，如果您已阅读完本文并对SEO感兴趣，可以了解后文，>点击跳转

0. 基础概念

0.1 搜索引擎定义

搜索引擎（Search Engine）是一类用于从大规模数据集中高效检索信息的系统，它主要由以下模块组成：

1. 抓取（Crawling）：负责发现并下载互联网上的海量网页内容。
2. 索引（Indexing）：将抓取到的内容加工，转换为能被机器快速检索的数据结构。
3. 排序（Ranking）：根据用户提交的查询词，结合其意图，对已索引的候选内容进行重要性或相关性排序。
4. 查询接口（Query Interface）：提供用户输入查询的界面，并把处理后的搜索结果呈现给用户。

0.2 搜索引擎工作流程

现代搜索引擎的典型工作流程可以概括为：

graph TD
    A[源数据：网页、文档、多媒体等] --> B(爬取);
    B --> C{结构解析 + 数据清洗};
    C --> D[建立索引];
    D --> E[建立传统 + 语义/行为模型];
    E --> F[最终给用户展示的搜索结果UI];

0.3 数据类型

搜索引擎需要处理形形色色的数据类型：

• 结构化数据：具有固定字段和严格结构的数据，比如 数据库、API 接口返回、知识库条目。
• 非结构化数据：没有预定义格式的自由文本内容，例如 网站正文、博客文章、新闻报道。
• 半结构化数据：拥有标签或标记来组织数据，但结构不那么严格，例如 JSON、XML、HTML DOM 结构。
• 多模态数据：包含多种媒体形式的数据，如 图像、音频、视频 等。这些数据需要通过 OCR、ASR 等技术识别，并转换为 CLIP 向量等可检索的形式。

1. 抓取 Crawling

抓取是搜索引擎获取信息的第一步，通过自动化程序（也就是爬虫）遍历互联网。

1.1 链接发现机制

• HTML <a> 标签超链接：网页间互相引用的最主要方式。
• <link>、<script>、<img> 等资源标签：这些标签里也可能藏着指向其他资源的 URL。
• 网站提交的 sitemap.xml：站长主动递交的「地图」，告诉爬虫网站有哪些页面。
• 外链引用（Backlinks）：其他网站「推荐」本站的链接，是重要的发现来源。
• 域名暴力遍历 / 词典扩展：通过穷举或组合常见词汇来猜测可能存在的 URL。

1.2 抓取策略 Crawl Strategies

• BFS（广度优先）
  • 特点：先广后深，保证覆盖。
  • 应用：通常用于通用爬虫，确保不会遗漏重要区域。
• DFS（深度优先）
  • 特点：快速深入单域。
  • 应用：适用于专项采集，需要快速获取某个主题或网站深层内容时。
• 优先级队列
  • 策略：根据链接的权重、内容更新频率等因素给链接打分，优先抓取「更重要」的页面。
  • 效果：热门、权威、更新频繁的页面会被优先照顾。

1.3 抓取预算 Crawl Budget

搜索引擎不会无限量地抓取一个网站，它有一个「抓取资源上限」，也就是抓取预算。

• 影响因素：网站服务器的响应速度、页面内容的质量、外部链接的质量、站点大小、内容更新频率。
• 主要影响：直接关系到网站页面被搜索引擎收录的速度以及在搜索结果中的整体可见性。

1.4 抓取控制规则

网站有多种方式来引导搜索引擎爬虫的行为：

• robots.txt
  • 用途：文件通常放在网站根目录，用来禁止或允许爬虫访问网站的特定路径。
  • 示例：Disallow: /private/ （告诉爬虫不要进这个目录）
  • 当然，防君子不防小人
• <meta name="robots">
  • 用途：直接写在 HTML 页面的 <head> 部分，对当前页面进行页面级控制。
  • 示例：<meta name="robots" content="noindex, nofollow">
    • noindex：告诉搜索引擎不要把这个页面收录到索引里。
    • nofollow：告诉搜索引擎不要追踪这个页面上的链接。
• HTTP Header X-Robots-Tag
  • 用途：通过 HTTP 响应头来控制，可以实现更精细的缓存与状态控制。
  • 示例：X-Robots-Tag: noarchive （告诉搜索引擎不要存档这个页面）

禁止抓取 ≠ 禁止索引 ≠ 禁止展示 这三者是不同的概念。比如，robots.txt 禁止了某个页面被抓取，但如果其他网站大量链接到这个页面，搜索引擎可能仍然会知道它的存在，甚至在搜索结果中显示它的标题（但内容无法展示）。这三者逻辑不同，将在 SEO 部分详细展开。

2. 索引 Indexing

索引的最终目的：将爬虫收集到的海量内容，转化为能被搜索引擎快速检索的数据结构。

2.1 文本预处理

原始文本在被建立索引前，要经过一系列的处理：

1. 分词（Tokenization）
   • 英文：相对简单，通常直接按空格、标点符号分割单词。
   • 中文：由于词语之间没有天然的分隔符，需要进行额外的分词算法：
     • 最大正向匹配（MM）：从左向右尝试匹配词典中最长的词。简单但误差可能较高。
     • 最大逆向匹配（RMM）：从右向左匹配，通常认为效果优于正向匹配。
     • HMM（隐马尔科夫模型）：基于统计概率模型，更适合处理大规模词库和复杂语境。
     • BPE/SentencePiece：现代 NLP 的主流做法，将词拆分为子词粒度，能处理未登录词，且支持跨语言。
2. 停用词过滤
   • 去除那些常见但对搜索意义不大的词语，比如中文的的、了、是，英文的and、the、a。
3. 词干提取（Stemming） / 词形还原（Lemmatization）
   • 将词语的不同形式统一到它们的词干或基本形式，例如 reducing → reduced → reduces 都归结为 reduce。这能有效减少索引量，并提高匹配率。

2.2 倒排索引 Inverted Index

倒排索引是搜索引擎最核心的数据结构之一。

• 核心结构：它像一个字典，键是词语 (word)，值是包含这个词语的文档ID列表（[document_id1, document_id2, ...]）。此外，通常还会记录词频、位置等信息。
• 可实现：
  • 快速定位：能够迅速找出所有包含特定关键词的文档。
  • 布尔运算：轻松支持 AND、OR、NOT 等逻辑操作，进行复杂查询。

2.3 向量索引 Vector Index

现代搜索引擎越来越依赖向量索引来实现语义搜索。

• 文本嵌入向量空间：通过学习模型，把文本（无论是单个词、句子还是整个文档）转化成高维的向量。
  • Word2Vec / GloVe：主要用于生成词向量。
  • BERT / RoBERTa / Embedding Models：生成更强大的语义向量，能捕捉文本的深层含义。
• 向量检索使用：这些向量被存储在专门的向量数据库中，支持通过计算向量间的距离来寻找语义相似的内容。
  • 常用工具：FAISS、Milvus、HNSWlib 等。
• 效果：即便用户搜索的关键词与文档中没有精确匹配，只要语义上相关，也能被有效地检索出来，实现真正的语义相似度搜索。

2.4 内容去重 Content Deduplication

搜索引擎需要避免大量重复内容的索引，这会降低搜索质量。内容去重就是解决这个问题的。

• Shingling（固定窗口切片）：将文档切分成多个小片段，对每个片段计算哈希值，通过比较哈希集合的相似度来判断文档是否重复。
• SimHash（局部敏感哈希）：为整个文档生成一个紧凑的哈希值，相似的文档会得到相似的 SimHash 值。
• 目的：避免 SEO 采集站、镜像站等低质量重复内容污染索引质量，确保搜索结果的多样性和权威性。

3. 排序 Ranking

搜索引擎的排序模型，核心目标是衡量候选文档与用户查询之间的相关性，并按最相关程度呈现结果。现代排序体系通常分为多阶段处理，以平衡效率和准确性：

3.1 First-stage Ranking / Recall

• 目的：在海量索引中，快速、高效地筛选出与查询可能相关的少量内容。这一阶段更注重召回率和效率。
• 方法：
  • BM25 / TF-IDF：基于关键词匹配的经典算法，结合词频、逆文档频率和文档长度来计算相关性。
  • 基于倒排索引的快速评分：利用倒排索引迅速定位并对文档进行初步打分。
  • 简单的向量召回：通过向量索引进行最近邻搜索，召回语义上初步相关的文档。

3.2 Re-ranking / Semantic Ranking

• 目的：在初筛结果中，进行更深层次的语义理解和精细化排名优化。这一阶段更注重排序的精准度。
• 方法：
  • LTR 模型：使用机器学习方法，综合大量特征（关键词匹配度、链接质量、用户行为、页面内容质量等）进行排序。
  • Transformer 表示 (Embedding Models)：利用 BERT、RoBERTa 等大型预训练语言模型，将查询和文档编码为语义向量，通过向量相似度进行精细匹配。
  • Reranker 模型：专门设计的深度学习模型，对查询和候选文档对进行交互式匹配，深度评估其语义相关性。

现代搜索引擎的典型排序流程：

graph TD
    A[用户查询] --> B(倒排索引召回);
    B --> C(初排);
    C --> D(语义重排);
    D --> E(返回给用户);

3.3 基于引用的权重模型 PageRank

PageRank 是 Google 早期的核心算法之一，它用于评估网页的重要性和权威性。它的衡量标准不是网页的内容质量本身，而是：

这个页面被谁引用、被引用了多少

也就是说： 被高质量页面引用越多 → 越重要

PageRank 公式

PageRank 的核心思想是将互联网上的链接视为一种「投票」。一个网页的 PageRank 值（$PR(p_i)$）越高，通常意味着它被认为越重要或越权威。

$$ PR(p_i) = \frac{1 - d}{N} + d \cdot \sum_{p_j \in M(p_i)} \frac{PR(p_j)}{L(p_j)} $$

解释：

note

一个页面的重要性，部分取决于引用它的页面的重要性。 引用者越重要，贡献越大；引用越多，贡献越分散。

PageRank 衡量的是 引用来源的质量，而不是 引用数量。

PageRank 在现代搜索引擎中的作用

PageRank 作为 Google 早期排名核心的地位早已过去。Google 在2016年已停止公开更新 PageRank 工具栏，其原始算法在当前搜索引擎中的直接权重已微乎其微。

现代搜索引擎的排名算法极其复杂，通常包含数百甚至数千个信号，远远超出了单一的 PageRank 模型。然而，PageRank 提出的「链接作为投票」的基本理念，其思想和原理仍然被融入到更复杂、更先进的链接分析算法中。

如今搜索排序更多依赖但不限于以下因素：

• 语义匹配：例如利用 Embedding / Transformer 等大模型，深度理解用户查询和内容含义。
• 用户行为反馈：如 CTR/Dwell Time 等，这些指标直接反映用户对搜索结果的满意度。
• 内容质量评估：对内容的深度、权威性、原创性、专业性进行综合评价。
• 站点权威性：通过更复杂的链接分析、品牌提及、专家推荐等评估网站的整体可信度。

总结：PageRank 的核心逻辑已演变为现代复杂链接分析中的辅助因子，其原始形式不再是主导。

note

PageRank 深刻影响了搜索引擎的发展，但作为单一的排名模型，它已成为历史。然而，其「高质量引用等于高价值」的基本理念，依然是现代搜索引擎链接分析的基础之一。 引用质量 > 引用数量

3.4 BM25 文本内容相关性评估

BM25 是一种广泛应用于信息检索领域的关键词匹配评分算法，用于评估文档与查询之间的相关性。它是很多搜索引擎初排阶段的基石。

公式：

$$ \mathrm{BM25}(q, D) = \sum_{t \in q} \mathrm{IDF}(t)\cdot \frac{f(t, D),(k_1 + 1)} {f(t, D) + k_1\left(1 - b + b\cdot\frac{|D|}{\mathrm{avgDL}}\right)} $$

BM25 主要解决了文本匹配中的几个实际问题：

通常位于搜索引擎的初排阶段，对通过倒排索引召回的文档进行初步打分，从而筛选出前 100~1000+候选结果进入下一阶段。

3.5 学习排序 LTR

随着网页质量差异的增大、用户行为数据的积累以及特征工程的成熟，搜索引擎需要一个可学习的排序模型来综合判断文档相关性。这就是 LTR。

典型 LTR 模型：

为什么要用 LTR？

• 超越传统算法：像 BM25 这类算法只看文本特征，看不到复杂的用户行为和页面质量等信息。
• 综合多维特征：LTR 模型能综合利用海量特征，包括：
  • CTR：用户是否点击了这条结果。
  • Dwell Time：用户在页面上停留了多久。
  • Bounce Rate：用户是否快速返回搜索结果页。
  • 历史搜索意图模型：用户过往的搜索偏好和行为模式。

如果用户总是点搜索结果列表中的第 3 条，并且停留很久，那么排序模型就会「学习」到这条结果可能更优质，从而慢慢将其排到第 1 条。

note

搜索引擎的排序，早已不是简单地为「网页写给机器看」来排序， 而是真正地为 「用户用脚投票」 来排序。

3.6 语义重排 Neural Re-ranking

现代搜索，尤其是在处理复杂查询和理解用户深层意图中，已经进入了纯语言理解阶段。语义重排利用深度学习模型来更精确地衡量查询和文档间的语义相关性。

使用模型：

典型流程：

graph TD
    A[用户查询] --> B(倒排召回 / BM25);
    B --> C(粗语义召回 / Embedding);
    C --> D(精语义重排 / Cross-Encoder);
    D --> E(返回给用户);

为什么不直接让大模型排序所有网页？

因为计算成本是指数级差异，不可能直接用最复杂的模型处理所有数据：

4. 正确使用搜索引擎

4.1 关键词

信息检索的本质，是提取核心概念。避免使用口语化的完整句子。

• 反例： 为什么我电脑上网速度很慢应该怎么办
• 正确示例：
  • 分解：wifi slow fix driver
  • 进阶：wifi latency diagnose "network adapter" windows

核心规则：从中文语义出发 → 提炼关键名词 → 优先使用英文技术词（如果问题涉及技术领域）。

4.2 强制精确匹配

使用双引号 " 来强制搜索引擎精确匹配某个词或短语，不拆分、不改写。这能显著减少无关结果，提升精度。

• "舞萌 DX" 评分
• "start dash" maimai
• "openwrt" "ipv6 relay"

4.3 索引范围过滤

使用 site: 指令将搜索范围限定在特定网站，直达专业信息源。

• site:xice.cx openwrt (在我的 blog 上找 OpenWrt 相关内容)
• site:zhihu.com maimai 难度 (在知乎上搜 maimai 难度讨论)
• site:wiki.archlinux.org f2fs (Arch Linux Wiki 中关于 F2FS 的资料)
• site:github.com magisk (在 GitHub 找 magisk 相关项目)

掌握 site:，几乎可以100%命中最有价值的权威技术答案。

4.4 无用结果过滤

在关键词后加上 减号 - 可以排除包含特定词语的结果，有效过滤噪音信息。

• openwrt ipv6 优先级 -贴吧 -抖音 -小红书
• maimai dx 曲目 推荐 -bilibili

当中文搜索结果充斥着低质量或营销信息时，「减法」指令往往比「加法」更重要、更有效。

4.5 文件类型过滤

使用 filetype: 指令直接搜索特定文件类型，如 PPT、PDF、Word 文档等。

• maimai 音频 filetype:ogg (寻找 maimai 的 OGG 格式音频)
• 互联网 基础设施 filetype:pdf (查找互联网基础设施相关的 PDF 文档)
• openwrt 网络 拓扑 filetype:docx (搜索 OpenWrt 网络相关的文档)

通过 filetype:，你绝大多数情况下可以直接找到高质的学术资料。

4.6 时间过滤

当信息具有时效性时（例如软件版本、AI 模型、新闻事件），限定搜索结果的时间范围非常关键。

• openwrt wireguard 教程 2024 (限定搜索 2024 年的 WireGuard 教程)
• archlinux hyprland install 2025 (查找 2025 年的 Arch Linux Hyprland 安装指南)

或者，直接在 Google 搜索结果页面的「工具」中选择「不限时间」→「过去一年 / 过去一月」等选项。

4.7 反查

「反向搜索」可以帮助你找到图片来源、句子出处或相似内容。

• 以图搜图：
  • Google Lens：功能全面，适合各种图片识别。
  • Yandex Images：在动漫、二次元图片识别方面表现尤其强大。
• 以词搜出处 (有意思的句子/梗)：
  • 将句子用双引号精确包围："原文句子" -微博 -抖音 -小红书

4.8 抽象问题 转变为 模式匹配

不要直接搜索具体遇到的「问题」，而是要搜索该问题的「结构」或「解决模式」。这能让你从症状直接触达科学诊断方法。

例如，你想找解决「延迟不稳」的方法，不要搜：

• 网速慢怎么办

而是要转换为技术概念：

• icmp latency waveform

搜索不是「被动地找一个答案」，而是「主动地定位信息」。只要你将问题表达得足够结构化、足够精准，你所寻找的答案永远存在。

5. 常见误区

5.1 用「自然语言倾诉」代替检索

搜索引擎不是 Chat GPT，它更擅长处理结构化的关键词，而不是长篇大论的「倾诉」。

• 反例 为什么我的 WiFi 总是特别卡而且有时候会掉线应该怎么办啊有没有办法解决

这种输入对搜索引擎来说就是噪音，它很难从中准确抽取出核心关键词。

• 正确示例：
  • wifi disconnect random fix / network unstable diagnose
  • WiFi 掉线 诊断 / 家宽 网络抖动 测试

不要跟搜索引擎倾诉，请直接表达「问题核心词」。

5.2 只看第一页，不改关键词

大多数小白搜索失败后，只会抱怨：

「百度/Google根本搜不到有用的信息」

搜索失败，往往不是搜索引擎的问题，而是关键词结构不对。此时，应当改写关键词，而不是盲目翻页。

EXAMPLE

第一次输入	改写
提高maimai分数	maimai 推分
wifi 卡	bufferbloat test
游戏 延迟	udp relay latency diagnose

5.3 不会过滤无效信息

在中文互联网环境下，垃圾、低质量内容泛滥时，减号语法 - 格外重要。

• openwrt ipv6 配置教程
• openwrt ipv6 教程 -知乎 -抖音 -小红书 -CSDN (直接剔除那些信息密度低/重复/营销性强的内容)

5.4 不区分「答案」与「解释」

很多人在搜索时，习惯于搜解释，但真正有价值的往往是HOW TO DO。

5.5 迷信「中文结果永远够用」

在技术、学术或系统问题领域，优先进行英文搜索。因为权威信息源通常原生就是英文的。

• 反例： 游戏服务器 tick 解释
• 正确示例： game server tick rate netcode

信息链路通常是这样的：

论文/标准 → 英文 wiki / docs → 国外论坛 / 博客 → 中文翻译/二创 → 小红书/知乎/CSDN

5.6 将「搜索」当作「找别人替你思考」

搜索引擎的本质不是答案机，它是一个高效的知识映射工具。 你需要先明确自己要找什么类型的信息，再进行检索。

先分类，再检索：

搜索不是「把问题原封不动地交给搜索引擎」，而是「你给出的关键词质量，决定了你所能看到的世界广度和深度」。

6. 搜索引擎的内部工作原理

tips

本章将侧重于可读性和核心流程，不会死磕复杂的算法细节，但会保证整体结构和概念的准确性。

6.1 搜索引擎整体架构

典型的搜索引擎内部架构可以抽象为以下五大核心模块：

graph TD
    A[User Query] --> B(Query Processing)
    B --> C(Index + Ranking System)
    C --> D(Document Storage + Cache)
    D --> E(SERP Rendering)

6.2 爬虫系统

• 爬虫会主动在互联网上发现并下载网页内容。

核心机制

遍历链接：通过页面上的链接，不断发现新的 URL。 遵守 robots.txt 公约：尊重网站设置的抓取规则。 防止无限爬取（循环检测）：避免陷入无限循环或抓取冗余内容。 自适应更新频率：对更热门、更新频繁的页面，会以更高的频率进行抓取。

基本流程： 初始 URL 列表 → 抓取页面 → 抽取新链接 → 加入待抓取队列 → 重复此过程。

爬虫并非无脑抓取所有内容，它会根据权重和重要性优先抓取「更有价值的网页」。

6.3 内容解析与标准化

爬取来的原始网页通常不能直接用于检索，需要经过一系列的规范化处理：

倒排索引的例子：

• "openwrt" → 文档ID：[1, 3, 7, 9, ...]
• "ipv6" → 文档ID：[3, 9, 10, 14, ...]

经过规范标准化处理后，每个关键词都对应一个或多个文档 ID，关键词越小、越精确，搜索速度通常越快。

6.4 排序

搜索引擎的排序模型，是决定搜索结果质量的关键。它通常由两个维度的评分组成：

PageRank 原理简单回顾： 一个网页的 PageRank 价值，大致等于所有指向它的网页的 PageRank 价值之和，再根据这些指向网页的出链数量进行平均分配。

动态排序机制，使得搜索引擎能够不断学习和进化，根据用户的真实反馈来调整排名。

6.5 查询理解

当用户输入一个查询词时，搜索引擎会在内部进行复杂的「查询处理」，以更好地理解用户意图：

1. 拼写纠错：自动修正用户输入中的拼写错误，如 maiami → maimai。
2. 同义词扩展：识别同义词并进行扩展，如 router ⇆ gateway ⇆ CPE。
3. 意图分类：判断用户的搜索意图是想找「教程 / 原理 / 购买 / 图片 / 视频」等。
4. 实体识别：识别出查询中的专有名词或实体，例如识别 舞萌 是一个游戏名称，而不是关于「舞蹈」的视频。

用户输入的原始查询，实际上会被搜索引擎重写成一个更准确、更丰富的内部查询表达。

6.6 排序后的结果呈现

搜索结果页面（SERP, Search Engine Results Page）并不是一个纯粹的链接列表，而是会根据用户意图动态生成布局：

• 技术问题：通常会优先展示来自官方文档、Stack Overflow 等权威网站的结果。
• 百科类查询：倾向于优先展示维基百科、百度百科等知识聚合平台。
• 购买倾向：会集成商品卡片、比价信息，导向电商平台（如京东、淘宝）。
• 地点相关查询：优先展示地图、商家信息。
• 图片/音乐/视频：以媒体网格视图呈现。

搜索引擎不是在简单地「猜你的意图」，而是在进行精密的意图分类路由，将查询导向最适合的展示模板。

6.7 用户反馈闭环 Feedback Loop

现代搜索引擎是一个「活的系统」，它会持续记录和学习用户的行为数据，形成一个反馈闭环，从而不断优化排序结果：

你越是频繁地使用搜索引擎，它就越能提供个性化的搜索结果。

至此，我们已经过完了现代搜索引擎的大体逻辑。这里我们埋个坑，未来可能会出一期手把手教你搭建搜索引擎。至于这有什么用？我们不是已经有 Google/Bing 了？ 是这样，但这样干的确很好玩。

Thanks For Watching.

您可以通过 Telegram 以及我的个人邮箱 qwq@chongxi.us 来联系我，欢迎对本文纠错，不胜感激。

本篇与《现代SEO深度解析：原理、算法与实战》是互补的关系，如果您已阅读完本文并对SEO感兴趣，可以了解后文，>点击跳转

关于/content/posts/目录下的规范

第一级目录为年份，例./2025/。
第二级目录为月份，例./10/。
第三级目录为日，例./26/。
第四级目录存放Markdown文件本体与其引用的媒体文件，例

2025/
- 10/
-- 26/
--- media/
---- example.webp
--- alpha.md

关于Markdown文件的命名，以希腊字母进行命名，如alpha,beta…，主要解决同日多文的问题。

关于Tag的规范

Tag比较细化，一般一篇Blog的tag会包含其主要内容具有概括性的关键词。

EXAMPLE

假设此篇文章主要内容为「三星手机解锁bootloader并刷入magisk提权过程」
那么该文章tag主要为samsung,root,刷机

关于分类的规范

目前主要划分四大类别

• TECH 技术向内容，例：刷机、网安、项目开发等
• LOG 日常向内容，例：风景照、文学作品等
• META 关于blog的内容，例：本篇命名规范
• VOID 杂项/未分类

以上即为目前已制定的规范，过去已Published文章会逐步更进新的规范。后续如果有修订会及时同步。

你好，十一月。
NOV 1 2025

在2021年接触maimai DX之前，我主要摸Beatmania IIDX，关于iidx的事情这里我们不多赘述。
2021年，Chongxi经朋友介绍，被朋友带入坑了maimai DX。

由于当时的事情确实记得不多，就不作多描述

我的第一段maimai DX历程是2021-2022初，当时并没有对maimai更深入了解，仅仅只是享受游戏的层面上。
2022年初，由于学业原因，弃坑maimai DX。

第二段便是今年，DX2025更新后，我终于有了相对比较富裕的时间回坑maimai，由于微信号更换，便开了一个全新的maiNET账号从头开始。

而就在这不到半年时间里，mai圈子此时的混乱程度让我难以接受了。

首先便是DX2025令人忍俊不禁的加载速度，很难想象每次上机都要等四五分钟，而且还变成了常态。
经了解后，一部分原因是拉取rival+高延迟的问题，但更多是人为因素，是因为什么呢，好难猜啊。

今年八月底九月初，mai圈的破事更进一步完善了我对这烂摊子的认知，首先便是全服大断网+扫号发票事件(具体可以看我同Blog下的文章)，之前其实有所听说过DX2023的大断网时代，毕竟没亲身经历过，没什么概念。这次算是非常完美地补全了这个遗憾，也让我见识到了我们mai的高防服务器，狗来了都能往服务器里拉屎，开挂的成本和难易度如此之低。

最让我气笑的是，这次的发票事件，玩家找官方完全不受理，最终变成了用外挂来打击外挂这种极其荒谬的事情，我真不好说啥了。

也非常感激在GitHub上开源maimai科技的各路神人，让我半个月内补全了退坑的三年时间里对mai的深层次了解，没想到我国的舞萌科技开发已发展到这种地步了。

由于罚站时间实在让人无法忍受，这边无奈之下和机厅沟通后安装了科技盒子用于加速网络，我真没啥好说的了，机厅里有一款不用科技就没办法正常游玩的机台。

再接下来便是整个十月份的陆陆续续断网，基本上每周服务器都要炸一次，这土豆服务器真给我看笑了。

再一个便是Leak事件，Circle刚更新就能把FESTA跟着漏出来，甚至官方的KOP7赛事都漏出来一部分PV。
10月21日当晚下发的KOP7先行曲目的opt，22日早就能有人去做铺面确认把内容public出来，比官方规定的30日开启提前了一个多星期，这就是我们SEGA的保密工作啊。

最近这几天更是闹了一波大的，具体事情我就不讲了，没意思，烂圈子碰上烂圈子，都烂完了。

SEGA拖更新进度，服务器外挂问题不作为。华立如无能丈夫。玩家群体也干了。这就是我们国服舞萌，从上游到下游，全烂完了。

自此篇Blog发出时，我已停用属于我的全部bot以及其他相关工具的maimai功能，抱歉带来的不便，也希望能够理解。
我是真不想再蹚这潭浑水了，没意义。
就这样吧。

OCT. 30 2025

note

本文提及的舞萌均为华立科技在中国大陆发行的舞萌DX版本

前情提要

在这周周末(9-6)之前一段时间，华立服务器非常炸，登录状态没有及时登出，导致大多数正常玩家被关小黑屋。

周六(9/6) 上午

• 华立服务器稍有异常，表现在无法正常登出账号被关小黑屋。
• Chongxi勤一上午基本没什么问题，传分登录都正常。

周六 下午

• 下午一点，开始有玩家反馈服务器问题比较严重，依旧表现在小黑屋、无法扫号登入、断网等方面。

• 下午2:37，由于Chongxi所在的机厅使用了神秘转发，这边有玩家反馈只能使用转发服务器的二维码登入，微信公众号二维码无法正常登入。

• 下午2:58，有人开始反馈被异常塞入五倍票，此时已经可以确定有挂哥开始扫号了

• 下午三点，Chongxi这时候来机厅，发现根本无法通过舞萌官方二维码登入账号，只能通过使用的神秘服务器转发缓存登入，如下图

• 约下午四点半，华立服务器应该进行了抢修，此时上传服务已正常，可以正常传分，但是挂哥依旧在全服扫号发票。

note

为什么挂哥要发票？当你的账号存在两张以上补偿票时，成绩异常，将无法上传成绩。

• 晚上八点，这时候来了另外一个事情，国服万花筒。起因是，Chongxi在看海鲜市场，无意发现了一位卖国服钥匙的，顺手把图发到了群里并询问可行性。

• 在通过一段时间摸索后，Chongxi给自己号上发了门和钥匙，并把万花筒模式拍照发给了自己的一个朋友。

• 随后便是出乎意料的大规模传播，不到两个小时后便传遍了大多舞萌群，下面是部分解释。

国服万花筒

• 关于这个被发钥匙的聊天记录，为假，这张图最早就是我顺手发的那张问朋友是否可行的图片。

• 至于国服是否可以开启万花筒，这个各位应该都有答案了。下面那个证伪不攻自破

• 我的那张万花筒可以说是闹的很沸沸扬扬了，我可以说的是，国服目前确实可以发，怎么发不能讲。如果你真的不相信，可以来找我拼机（什

• 这张图相信各位都看过了吧，引起乱传的主要问题可能是因为CCBY(，已严肃更改为2025©xi All Rights Reserved（不是

• 目前挂哥的行为为：全服发票，登号续关小黑屋，使玩家无法正常游玩

周日(9/7) 上午

• 上午十一点，这时有人反馈科技哥发一倍票，很难憋笑，科技哥发id1的行为足以看出其技术力不足。

• 随后开始有人反馈科技哥发送的倍率票日期有问题，科技哥开始给全服玩家塞敏感日期的倍率票，这时候科技哥的动机我就不好评价了

• 这已经不是影响玩家游玩的问题了，科技哥让事态升级叠加了一下奖池。

万花筒 part2

• 这时候QQ传的更广的图为这张，这张图为魔改，并非官服

目前挂哥行为：

• 发票 无法正常传分

• 扫号 使正常玩家无法登入账号 进入小黑屋

• 目前挂哥还没有掌握传分等高级技术。

截至晚上9:01，挂哥终于是消停了，不再有发票的情况了，这件事自此算是完结了…吗？

九月八日 周一

caution

以下内容来源于各群聊聊天记录，缺乏真实性考证，Chongxi不为以下内容真实性负责

• 有人上报被发了白系理论

Chongxi猜测可能是自导自演自娱自乐，自己给自己发了成绩然后一张图全靠编，毕竟前文已经有万花筒这个教训了，当然只是猜测，也有可能确实是真的

• 有反馈被发wec牌子

由于这些事情真实性欠考证，所以暂时一笔带过。有后续会持续更新

扫号解决方案

目前有以下解决办法

• milkbot 可查询票数以及消票 使用请见此文章底部给出的链接
• 奈伊bot 群号:747686616 支持清票查票/解黑屋

欢迎各位向我反馈更多解决方案

在此向致力维护游戏环境的各位致以最高敬意。

为什么没泄漏二维码也能被扫？

挂哥通过User ID登入你的账号，之前有讲，详见此文章。

不被挂哥登号的唯一办法也就不获取二维码了。

tip

本文若无特殊说明，提到的浏览器均指Android平台

OEM厂商定制浏览器

得益于Android的开放，您拿到手机时，系统默认的浏览器往往不是Chrome，而是OEM厂商「精心打造」的定制浏览器。例如小米浏览器，华为浏览器等。

Samsung Internet(三星浏览器)

一众OEM定制浏览器中的顶级。基于Blink内核，采用OneUI设计，风格统一。特点如下：

• 反追踪：可以阻止追踪器，第三方cookie等。
• 反骚扰：向后反重定向，弹出窗口拦截，应用跳转拦截。
• 广告拦截：支持安装第三方广告拦截插件
• 视频助手：极佳的视频播放体验
• 后台播放：使其可以免YouTube Premium在后台播放视频
• 强制深色：极佳的网站强制深色模式
• Samsung Pass：三星自己的自动填充服务，但Google填充无法工作，这也是我放弃他的原因
• 区域限制：国区三星无法使用Google作为搜索引擎，需要改区。

国产厂商OEM浏览器

国内的OEM浏览器就很…难评。高情商来讲就是「本地化适配非常好」。

不管是小米/华为/vivo/OPPO还是其他国产OEM厂商基本都一个样：主页给您塞满新闻小说漫画短视频直播等功能，极其臃肿。

其优点是开箱即用，符合国内用户习惯。

缺点显而易见：隐私政策模糊、广告多、功能臃肿，内核也基本会比Chromium的build慢半截。有些厂商甚至还会往您的浏览器里塞黑名单和白名单，某些网站直接给您偷偷过滤掉不让访问，或者直接把您的浏览记录上传到服务器。

app内置浏览器

许多app都喜欢自己再额外套一个浏览器，这里就需要讲讲Android系统的Webview。

Android Webview：大多数App内置的浏览器功能都依赖于它。它不是一个您能直接打开的 App，而是一个系统组件。

当您在应用里打开一个链接，调用的就是这个WebView。

国产浏览器

这类浏览器在国内拥有巨大的市场份额，比如QQ浏览器。它们大多基于Chromium/WebKit，但进行了大量魔改。比如：深度整合了下载、小说模式、网盘等功能，在一些特定场景比如看小说上体验较好。

缺点非常明显：隐私。他们提供的并非单纯的浏览器体验。而且对现代Web标准的支持有时会落后于Chrome和Firefox。

两座越不过去的大山 Chrome vs. Edge

Google Chrome

Google生态的集大成者，它的优势不仅在Android设备上的极佳Google生态上，几乎可以称得上目前最佳的浏览器，引擎最佳，兼容性广泛等优点使其成为市场占有率最高的浏览器。Chongxi主要是因为Google自动填充服务才用的Chrome。

缺点是资源占用较高，稍微吃性能。手机上的功能真的比较少。在隐私方面，需要对Google抱有足够的信任。

Microsoft Edge

Edge算是和Chrome同根了，使用的也是Chromium内核，继承了其极佳的渲染引擎。

它的最大卖点在于与Windows PC的深度同步整合。如果您主要使用Windows电脑，那么Edge提供的手机PC同步体验丝毫不逊色于Chrome。

我认为edge是给了不想被Google全家桶绑死的用户一个顶级的选择。

缺点的话现在也非常明显，开始向国产流氓看齐了，塞了一堆诸如新闻资讯AI等无关紧要的内容进去，而且Microsoft审美真的很差，相比Chrome真的难看很多。

别具特色的第三选择

Beyond the giants, there’s a world of innovation.

Mozilla Firefox

Android上主流的使用自有引擎GeckoView的浏览器。

优点非常突出：强大的浏览器扩展、严格的跟踪保护、容器标签页隔离工作、个人等不同身份的登录状态，防止跨站跟踪。

如果您比较注重隐私，Firefox绝对是不二之选。

Vivaldi Browser

由前Opera团队打造，并继承了高度可定制。

Chongxi用了一段时间，感觉还是比较不错的，支持Google自动填充，和Chrome操作逻辑非常接近，使得我从Chrome切换过来毫无成本。

Brave Browser

Brave 默认屏蔽所有广告和跟踪器，速度极快。

不过其争议性在于它试图用注意力经济模型来重塑网站盈利方式。无论您是否认同其模式，它的隐私保护和速度都值得一试。

Kiwi Browser

最早实现了在Android上支持桌面版Chrome扩展。但是目前疑似有点死了。

DuckDuckGo

鸭子鸭子跑

如其搜索引擎一样，它的浏览器应用也极度注重隐私，每日自动清除浏览数据，还有一键烧毁按钮，一次性干掉所有记录，也提供应用跟踪保护等功能，体验非常轻快简洁。

via

via是一个纯粹的浏览器，回归浏览网页的本源。

它直接调用Android系统自带的WebView内核来渲染网页。这意味着它不需要打包一个巨大的内核引擎，从而实现了安装包体积的极致控制。

可玩性也比较高，用户脚本/自定义等功能都非常好用，作为一个纯粹的浏览器，他极其出色。

Tor

这是一个比较特殊的浏览器。他的设计目标非常纯粹，尽最大可能隐藏您的网络身份和活动。

您的流量不再直接到达目标网站，而是进入Tor 网络。在这个网络里，您的流量会被自动加密三次，并通过至少三个随机选择的中继节点进行传输，最终才从出口节点到达目的地网站。这意味着目标网站只能看到出口节点的IP地址，而非您的真实IP。

其主要功能是访问以.onion为后缀的隐形服务。也就是暗网。日常使用很不便利，因为流量需要多次中转，速度缓慢。

自动填充

这是一个体验分水岭。Chrome和Edge的自动填充无疑是最无缝的，这避免了手输密码的烦恼，体验极佳。

对于其他浏览器，我强烈建议使用独立的密码管理器如Bitwarden/1Password。它们以 App 扩展的形式，可以为几乎所有浏览器提供强大且统一的自动填充服务，让您不再被浏览器本身绑定。

关于我

主力依旧使用Chrome，因为被Google绑死了。

浏览器的选择非常看重个人习惯，不妨多试几款。

:::yellow[注意] 本文中提到的舞萌DX均为华立科技在中国大陆的代理版本

本文原为:杂谈mai科技相关知识以及第三方工具使用指南，现拆分为多篇文章以区分层次

本文仅作为maimai深层次的相关研究，仅供学习参考交流使用，主要目的是向广大舞萌玩家科普基本常识，教各位如何保护自己的Net账号，并演示你的账号是如何被挂哥毁掉的。本文不支持任何开挂作弊行为。

在此感谢每一位在GitHub等平台公开科技的各路神仙 :::

1. 基本概念

1.1 SGWCMAID

在登录舞萌DX机台时，需要通过「舞萌 | 中二」公众号获取二维码。长按二维码解析后的字符串即为SGWCMAID。

:::red[严重警告] 绝对不要在任何公开场合泄露您的SGWCMAID

请仅向您信任的人员或服务提供SGWCMAID。

如果他人获取了您的SGWCMAID，则意味着对方拥有您的舞萌账号操作权限，可在有效登录时效期内登入您的账号。 :::

1.2 登录时效

SGWCMAID 的页面底部会显示二维码的有效期提示。过期后，二维码无法再用于机台登录，需生成新的二维码。

二维码有效期：约 10 分钟

账号登录时效：约 30 分钟 (2025/08/27测定)

• 当距离上一次二维码获取已超过约 30 分钟时，账号会进入「冻结」状态，任何方式均无法登录

• 该状态会在生成新的二维码后解除

• 这是对账号的一道保护机制，防止攻击者滥用

1.3 User ID

User ID 并不是好友代码，而是舞萌国身份证 账号标识，与SGWCMAID关联

通过SGWCMAID可以获取对应的User ID

拥有User ID的同时，也意味着拥有操作该账号的权限，可用于登录或对你账号进行G键开挂

• 舞萌DX的User ID为顺序计数，开头固定
• 所以User ID可被用作遍历攻击，这就说明了挂哥是如何给你的账号开挂的，他们通过遍历User ID来登入你的账号，如果你的账号恰好在登录时效内且处于未登录状态，那么你就倒霉了，所以说，登录时效是华立最后的底裤，如果没了，任何人的账号都可以随时被登录

1.4 小黑屋

• 舞萌服务器规定的登录会话超时为15分钟
• 登录时必须使用生成时的时间戳，登出也必须使用对应的时间戳
• 如果没有正常登出（如因服务器丢包、高延迟或异常宕机），账号就会进入我们所说的小黑屋，只能等会话超时自动过期/用科技解除
• 这是服务器防止会话滥用的一种保护机制
• 但是由于舞萌服务器延迟较高，实际小黑屋持续时间可能会大于15分钟

:::cyan

1.4.1 格式约定

SGWCMAID由三部分组成：

SGWCMAID + 16位时间戳(格式 YYMMDDHHMMSS) + 64字符校验签名

• 时间戳用于限制二维码有效期
• 64字符部分为不可逆的校验/签名或加密片段

1.4.2 服务器验证流程（已抹去部分关键信息）

1. 本地验证SGWCMAID是否合法

2. 机台或客户端将扫码得到的SGWCMAID发送到服务器的二维码验证接口

3. 服务器解析SGWCMAID：

• 校验时间戳是否在允许的有效期内
• 验证字符校验段是否合法

1. 验证通过后，服务器返回userID以及其他可能的附带信息；否则返回错误码并拒绝登录

1.4.3 session与时效

成功验证后服务器通常会把该次登录转换为短期会话session，该会话的有效期约为30分钟(2025/08/27测定)

会话到期或被显式登出后，需再次使用新的SGWCMAID登录

若超过会话有效期且没有新二维码获取，账号会被置为「冻结」状态，需要获取二维码以解除

1.4.4 为什么不能泄露

SGWCMAID 本质上是一次性登录凭证：持有者在有效期内可被服务器识别并取得对应 userID，从而获得账号操作权限

字符校验虽不可逆，但若泄露仍可直接被服务器接纳（只要时间戳未过期），所以必须严格保密

1.4.5 击碎你的幻想

SGWCMAID 的构成与服务器端验证是不可逆且受时效限制的，因此不能从本地仅靠解码可靠地推算出 userID（必须由服务器返回）

至少目前确实是这样

同一条SGWCMAID在其有效期内可被服务器直接接受，除非获取新的二维码/二维码到期，如果有人比你抢先一步使用此泄漏的SGWCMAID获取到了User ID，那只能祝你好运了。 :::

2. 科技

舞萌的科技多种多样，严格意义上，HDD,Bot,查分器,开挂等都算科技，因为他们都或多或少直接使用非正规渠道获取了服务器信息/程序本体，只是影响好坏的问题

我们先着重讲外挂，这是每个maimai玩家都该担忧的问题

2.1 外挂

目前我们所熟知的外挂有以下作用：

• 传分 往账号中写入指定的乐曲成绩
• 下埋 批量写入(指定难度/版本等)成绩
• 发票 向您的账号中发放「补偿」的2/3/4/5/6倍进度票
• 解歌 解锁被锁定的乐曲(比如紫谱难度)
• 解图 解锁地图(如月面区域)
• 跑图 顾名思义
• 签到 签到集章卡
• 解锁收藏品 包括但不限于 姓名框/称号/头像/搭档/背景板/功能票
• 修改舞里程 DX2025更新的舞里程商店，可用里程购买功能票等道具

:::cyan

2.1.1 概览

本质是：在有效的会话中，直接向服务端写入用户的成绩或收藏品等，这并不是正常游玩流程

拿最常见的传分举例：
一般作弊者会构造并向服务器发包，于数据包中设置目标字段（如 musicId,level,achievement 等）来插入或替换成绩

还有就是小黑屋扫号： 遍历扫号指攻击者通过预测或顺序试探 User ID，配合可被接受的临时凭证或薄弱的登录路径，在大量账号中快速尝试登录的行为

如果某个被测试的账号恰好处于有效登录时效内，攻击者就能直接取得该账号的会话并登入，然后不主动执行logout操作，这就会使该玩家无法正常游玩，更高级的攻击者还会自动续关，使该帐号锁定不止十五分钟，严重可能以小时为单位

舞萌国「社工库」 目前已有攻击者可以通过您的rating，头像，姓名框，背景板，昵称等信息，以查询账号数据库的方式反推出您的User ID并将您的信息建档成库，部分攻击者已在某鱼等平台出售相应服务 :::

:::blue[如何保护自己的账号]

1. 不在不信任的公开场合发送您的二维码/SGWCMAID
2. 不在非出勤时间随意获取二维码
3. 发b50尽可能隐藏掉昵称等不必要信息 :::

2.2 HDD/app

舞萌DX机台运行的游戏程序本体，app是官方机台运行的游戏程序，HDD一般用于在手台等非官方机台上运行，可能还会带有部分mod功能，比如Auto Play

此部分带来的法律风险由用户自己承担

2.3 opt

服务器向机台下发的更新会以.opt形式呈现，其中包含此次下发的更新内容，例如乐曲数据等信息

下发时间 opt下发并通知机台下载此更新的时间
发布时间 机台应用本次更新的时间

机台即使下载好了opt也不会立刻更新，需要满足发布时间才会更新

:::details[cyan::关于国服2025部分杂谈] 在DX2025更新首日，相信各位也看到了Net公众号上的KALEID×SCOPE万花镜提前泄漏的情况，原因是*2372462的作弊者上传了四个门的数据，而服务端没有及时堵门，导致了此情况的发生

热知识： DX2025的机台程序包含到了至Prism的部分数据，比如收藏品以及万花镜模式的相关代码，不过没有乐曲数据，只是单纯要按照SEGA的更新日程逐步开放，如果你有能力给机台下发乐曲数据的opt是可以提前游玩的，这也解释了之前流传的国服宙天等内容是如何实现的 :::

2.4 第三方服务器

目前根据笔者已知有以下第三方服务器：

• 转发服务器：作中转用途，作为中间人代理以加速华立服务器的加载速度
• 纯粹的私服

2.5 第三方查分器/bot

主要用途是帮助玩家了解自己的Best50等游玩成绩，目前主流查分器有落雪查分器与水鱼查分器,bot的话太多难以统计，主要也是此用途

2.6 手台

玩家第三方自制、高度模拟官方机台的机器

3. 备注

关于第三方查分器使用已迁移到新的文章分篇，后续会补

关于挂哥扫号实例请看本博客下的此文章: mai纪事:9月大规模科技扫号和国服万花筒事件

caution

本文内容仅限技术研究学习目的，旨在帮助开发者等深入了解网络代理，流量路由等运作机制。任何不当使用造成的后果均与本文作者无关。严禁用于商业用途。

您必须确保所有操作均遵守您所在国家/地区的法律法规。本文坚决反对并谴责任何使用网络代理技术绕过正当网络管控、访问非法内容或从事任何非法活动的行为。

本文涉及到的操作需要修改Android系统底层，具有潜在风险（如设备变砖，数据丢失，系统不稳定等）。所有操作均基于您自愿选择并自行承担全部风险。本文作者不对任何因遵循本文步骤导致的设备问题或法律纠纷负责。

本文面向具备足够知识背景和风险认知的用户，尝试前请确保您已了解关于root等基本概念。如果您不知道您在做什么，请自觉停止操作。

INTRO

在开始之前，我们简单对比一下常规代理与box4magisk。 CHIZI-0618/box4magisk

CLASH FOR ANDROID

以最常见的Clash for Android为例，他通常通过调用Android系统提供的VPN Service API工作。

当您在CFA（Clash For Android）中启动代理时，应用会向系统申请创建一个虚拟VPN接口，此时会要求用户授权。随后Android会将设备上几乎所有应用程序的流量都重定向到此接口。

CFA本质上其实是个壳，用于更方便与用户交互，本质其实是Clash核心在处理流量。

Clash内核会根据您配置的规则来检查所有经过的流量，根据规则匹配结果，决定该流量走向。

BOX4MAGISK

box4magisk借助magisk/kernelSU/APatch将clash部署在data/adb/，使其深度集成在Android系统的网络栈，实现了更高权限的流量接管。

由于他不依赖VPN Service API，因此完全不占用VPN槽位，通过透明代理，使其能绕过大多数检测。

PRINCIPLE

TRANSPARENT PROXY

Transparent Proxy，也就是透明代理。简单来讲，就是让应用程序无法检测其存在，让应用认为他在直接连接互联网。其劫持实现主要如下

TUN

TUN设备是软件实现的虚拟网络设备。他不像eth0或wlan0那样是真实的硬件。他就像一个虚拟的网线接口，一端插在系统的网络栈，一端插在Clash核心。

其工作原理主要为：

系统根据iptables规则，把所有需要被代理的网络流量发送到TUN设备。Clash内核则从另一端读取这些原始数据包进行处理，随后经过TUN回到系统内核，并出口到目的地。

TUN设备在网络层工作，处理IP数据包使其能够接管所有基于IP的流量。

TUN2SOCKS

众所周知，Clash一般监听在SOCKS5/HTTP端口，守听的是预期符合代理协议的数据。但TUN里给出的数据则是原始网络数据包，压根不是一回事。

而TUN2SOCKS作为其中的桥梁，达到了翻译的效果。他负责读取TUN来的原始数据包，以客户端身份将其打包为标准的SOCKS5协议格式，并将其发送给Clash内核，这样Clash就可以正常处理这些流量了。

• 对于Clash来说，它只是为叫做tun2socks的本地客户的提供代理服务，并不知道其接管的流量来自系统全局。
• 对于应用程序来说，它以为自己是直接连接到互联网，并不知道自己的流量被TUN劫持并转译。

IPTABLES

系统流量默认可不会自己跑进TUN，在Box4magisk中，使用到了iptables让流量走向TUN。

我们先来了解下iptables，这是Linux系统内置的数据包过滤和操作工具，不过在这里，他的核心作用不是防火墙，而是对流量进行路由。

Box4magisk在启动时，会添加一系列规则达到REDIRECT或TProxy到TUN设备的目的。

接下来我们会举一个例子，来更好理解他们协同工作时的流量走向

1. app试图连接xice.cx:443
2. iptables立即截获此TCP请求，根据规则，将流量引至TUN设备
3. TUN会将流量引至tun0
4. tun2socks会从tun0中读取到这个原始TCP请求，并将其打包为SOCKS5协议的CONNET blog.chongxo.us 443发给localhost的Clash端口。
5. Clash接收到该请求后，根据代理规则进行出口。

从远程服务器返回的数据则会以以上方式反向走一遍。

PREREQUISITES

• 一台已获取 Root 权限的 Android 设备
• 获取Magisk模块文件

这里我们使用Surfing作为演示，这是fork自box4magisk的项目，有集成式一体服务、即刷即用的特色。

您也可以选择原始的box4magisk进行配置，后续Chongxi会考虑写关于这个的blog。

GitMetaio/Surfing

LET’S GO

• 在Magisk安装Surfing，此时您无重启设备的必要。
• /data/adb/box_bll/clash/config.yaml中，您可以添加您的远程代理配置URL。 您也可以根据里面的注释自行修改配置，修改后重启您的设备。
• 打开您的浏览器，输入http://127.0.0.1:9090/ui/#/即可打开WebUI控制台，在这里您可以详细设置您的Surfing。
• 关于启停 关闭Magisk模块后即可停止。

Surfing的部署到此完毕。

CONCLUSION

至此，我们通过 Box4Magisk 模块，我们超越了普通应用的限制，将 Clash 深植于系统底层，实现了真正全局、无感的网络代理。

同时，我们也深入理解了其背后的工作原理，让「魔法」变成了可控的「技术」。

center large

这里是Chongxi，期待与您的下一次见面

Thanks For Watching.

Circle to Search 是 Google 和 Samsung 联合推出的一项功能，让用户可以通过在屏幕上的任意位置进行圈选、高亮、涂鸦或点按，来快速搜索文字、图像或视频，而无需切换应用。

关于圈定即搜 更深度的剖析可以去看看 @NNNNNatsu 大佬的文章：

Circle to Search, XOXO：「圈定即搜」功能交互解析与入门指南

MiCTS

正如 title，我们要在任意Android(≥9)设备上启用圈定即搜，需要借助一个LSPosed模块。

parallelcc/MiCTS

PREPARATION

• 已获取root权限的设备，并安装了LSPosed。

LET’S GO

1. 安装MiCTS模块。
2. 打开LSPosed Framework，通常情况下，您可以从通知栏的入口进入。
3. 打开模块选项，找到MiCTS，启用，勾选推荐的作用域。
4. 重启您的设备。
5. 将您的默认助理App更改为Google。一般情况下，您可以点击设置>应用>默认应用程序中找到其选项。
6. 您需要给Google应用取消后台限制，将电池优化更改为无限制，并允许自启动。

接下来您可以长按导航条，若圈定即搜正常触发，那么恭喜，您省去了一半的麻烦。

若未正常触发，那么我们需要额外的操作。

1. 打开 LSPosed 里的MiCTS页面，点击右下角的齿轮图标进入设置。
2. 可供参考的设置如下图，您可能需要授予其root权限。

接下来我们设置其触发方式（如果您无法正常长按导航栏触发）

1. 安装Xposed Edge(Pro) （您需要自行安装）
2. 在LSPosed Framework中启用 Xposed Edge，并重启其作用域。
3. 打开Xposed Edge，如下图设置。

接下来您可以再次尝试长按导航栏，他应该会像预期一样工作。

若您遇到了bug，可以向MiCTS项目提交issue。

这里是 Chongxi，期待与您的下一次见面。

Thanks for watching.

–Chongxi 2025-08-25

目前2025/08/22，这款路由器价格在十元到三十元之间，淘来刷软路由非常合适。

PREPARATION

需要下载的固件 ：123684

需要的工具：termius，winSCP

刷入官改固件

1. 打开MIWIFI后台，在系统维护页面手动上传升级固件miwifi_r3a_all_da132_2.18.40.bin
2. 等待升级完成。

确认 Windows 版本

• Windows 10 至少2004，内部版本至少19041。
• Windows 11

开启与 WSL 相关的 Windows Features

开启 Windows Subsystem Linux 和 Virtual Machine Platform 并重启 Windows。

1. 以管理员运行 PowerShell。
2. 输入

dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

您会得到如下输出

部署映像服务和管理工具
版本: 10.0.26100.1150

映像版本: 10.0.26100.4652

启用一个或多个功能
[==========================100.0%==========================]
操作成功完成。

接下来

Enable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform -NoRestart

Path          :
Online        : True
RestartNeeded : False

您需要重启Windows。

安装WSL

输入

wsl --install

接下来就像正常Ubuntu设定一样，设置账户和密码，密码不显示是正常的。

正在下载: Ubuntu
正在安装: Ubuntu
已成功安装分发。可以通过 “wsl.exe -d Ubuntu” 启动它
正在启动 Ubuntu...
Provisioning the new WSL instance Ubuntu
This might take a while...
Create a default Unix user account: xi
New password:
Retype new password:
passwd: password updated successfully
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.

xi@SKYCHOW:/mnt/c/Users/33960$

Ubuntu环境即部署成功

部署解锁工具

1. 在资源管理器中输入 \\wsl.localhost\Ubuntu 进入Ubuntu文件管理，打开home/<这里的文件夹名称为您的用户名>/
2. 将OpenWRTInvasion-0.0.10.tar.gz和setup_openwrt_invasion.sh移动到该目录。
3. 使用cd /home/xi命令，切换到该目录（自行更改xi为您的用户名）
4. 赋予执行权限

sudo chmod +x setup_openwrt_invasion.sh

1. 输入以下命令

cd OpenWRTInvasion-0.0.10

1. 更改库地址

nano script.sh

由于原镜像失效，我们需要编辑download部分为如下内容

download_file_from_github() {
    # Rationale for using --insecure: https://github.com/acecilia/OpenWRTInvasion/issues/31#issuecomment-690755250
    curl -L "https://gitee.com/juserzhang/OpenWRTInvasion/tree/master/script_tools$1" --insecure --output "$2"
}

然后ctrl x退出

1. 运行

python3 remote_command_execution_vulnerability.py

出现如下输出

Router IP address [press enter for using the default 'miwifi.com']: 192.168.31.1
Enter router admin password: 12345678

输入您的IP和后台密码即可 接下来会出现

There two options to provide the files needed for invasion:
   1. Use a local TCP file server runing on random port to provide files in local directory `script_tools`.
   2. Download needed files from remote github repository. (choose this option only if github is accessable inside router device.)
Which option do you prefer? (default: 1)

我们输入2，回车即可运行

****************
router_ip_address: 192.168.31.1
stok: a80675f22f75d3281445ea2c2638f97e
file provider: remote github repository
****************
start uploading config file...
start exec command...
done! Now you can connect to the router using several options: (user: root, password: root)
* telnet 192.168.31.1
* ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 -c 3des-cbc -o UserKnownHostsFile=/dev/null root@192.168.31.1
* ftp: using a program like cyberduck

出现如上输出，那么恭喜您，这部分步骤成功。

刷入breed

1. 打开termius，通过telnet连接您的路由器，用户和密码均为root
2. 查看并备份分区

cat /proc/mtd

备份分区，留意factory跟BootLoader对应的mtd分区，需要备份的是factory和BootLoader

dd if=/dev/mtd4 of=/tmp/eeprom.bin
dd if=/dev/mtd1 of=/tmp/Bootloader.bin

1. 打开WinSCP，协议选择FTP，主机名为路由器IP，密码和用户名为root。
2. 找到tmp目录，将Bootloader.bin和eeprom.bin复制到PC上。并把breed复制进tmp
3. 回到终端，cd进tmp目录，开始刷入breed

mtd write breed.bin Bootloader

刷入openwrt

1. 确保电脑连接了路由器LAN，拔掉路由器电源。按住复位键，再插入电源，等待指示灯闪烁后，松手。
2. 输入192.168.1.1进入breed后台，这里先查看mac，若mac地址不正常，刷入先前备份的eeprom。
3. 固件选择openwrt，刷入。这里我们使用的是bilibili@小渔学长编译的openwrt固件。

成功

等待片刻，输入10.32.0.1，密码admin，进入openwrt后台，成功。

特别鸣谢

@没了钱咋办 @Lonny_Lee @正在摸鱼的Liaronce @acecilia @hackpascal @小渔学长

这里是 Chongxi，期待与您的下一次见面。

Thanks for watching.

–Chongxi 2025-08-22

相信各位都遇到过这种情况：出于某种原因（比如esim）购买了国行Galaxy Watch，到手后发现无法与自己的港版（或其他版本）手机无法连接，连接时显示如下错误：

此手机不支持该手表。

大多数给出的解决方案基本都是将手机/手表刷为其他版本的系统以进行连接，但是操作难度是比较高的（有一定局限性）

本文将教各位如何跨版本连接三星手表（国港互通）

PREPARATION

• Galaxy Watch（这里以Watch6国行为例）

• Samsung 手机（这里以港版One UI5.1为例）

• Samsung 智能穿戴 App（版本号为2.2.29.20012861）你可以从这里下载

LET’S GO!

1. 将您的Samsung Galaxy Watch设定为待配对状态（对其进行工厂重置）

2. 卸载手机里的Samsung智能穿戴App以及相关组件（比如watch6manager,Wear OS by Google）

3. 安装低版本Samsung智能穿戴（.20012861）

4. 断开一切互联网连接（WLAN/蜂窝移动数据），打开手机的蓝牙界面，点击您的Galaxy Watch进行配对。

5. 通过任意途径安装最新版Samsung智能穿戴，打开后您将会在 已配对的设备 中找到您的Galaxy Watch，直接点按即可进行设置。

TIPS

由于国行Galaxy Watch阉割了Google服务，您可能会在复制Google账号时提示失败，跳过即可。

HOW IT WORKS?

原理非常简单，低版本的wearable是没有配对校验的，我们使用低版本对手表进行配对后，再使用高版本对其进行连接，即可完成手表手机的国港互通。

这里是Chongxi，期待与您的下一次见面。

Thanks for watching.

–Chongxi 2025-08-19

INTRO

众所周知，三星因其独特的Knox熔断机制，使其解锁Bootloader的代价极其昂贵。

• 失去保修：Knox熔断后，会失去原厂保修。
• 无法使用部分功能：某些安全功能，如三星Pay、Knox安全保护等，会无法使用。即使你恢复原厂系统，部分功能仍可能无法恢复。系统应用基本死绝
• 软件更新受限：由于设备被标记为已熔断，系统更新可能会受到限制或失败。（不过你都解bl了还需要OTA吗）

其中最主要的还是系统app基本死绝，三星健康等应用无法使用，这个还是很肉疼的

本文所介绍的Knox Patch便是为了解决这个问题诞生的。

salvogiangri/KnoxPatch

需要下载的内容：

• KnoxPatch-v0.8.0.apk
• KnoxPatch-Enhancer-v0.4.zip

FEATURE

Supported apps ✅ Auto Blocker

➖ Galaxy Wearable (Gear Manager) (Enhancer required)

✅ Samsung Cloud (FMM, Enhanced data protection)

✅ Samsung Flow

✅ Samsung Health

✅ Samsung Health Monitor

➖ Samsung TV Plus (TrickyStore required)

✅ Secure Folder (Enhancer might be required) ✅ Secure Wi-Fi

✅ SmartThings

➖ Smart View (Enhancer required)

✅ Private Share*

❌ Samsung Pass

❌ Samsung Wallet (Pay)

SUPPORTED VERSIONS

One UI 1.x --> One UI 8.x (Android 9 --> 16)

tip

由于集成在 Quick Share 中，运行 One UI 5.1 或更低版本的设备可能需要PIF或类似程序才能使此功能正常工作。

运行 One UI 2.x 或 3.x 且带有FBE 的旧版设备需要在系统分区中安装额外的补丁程序才能修复安全文件夹问题。请从最新版本下载模块 zip 文件并通过自定义 Recovery 安装，这将应用修复安全文件夹所需的补丁程序。该 zip 文件还会创建原始系统文件的备份，再次刷写即可恢复这些文件。

LET’S GO

1. 首先，确保您使用Magisk/Kernel SU/Apatch等su管理器获得了root权限，并安装了LSPosed模块
2. 在Magisk模块中，刷入KnoxPatch-Enhancer-v0.4.zip
3. 在LSPosed中，勾选所有推荐的应用。
4. 重启您的设备，此时您的Knox Patch将生效。您可以正常使用绝大多数系统app了

写在最后

三星手机解锁bootloader代价极大，我们不推荐您解锁bootloader。绝大多数问题都可以使用shizuku和scene可以把不喜欢的系统应用都禁用，任何禁用都不会死机卡界面。

相比之下，vivo的系统用一般的adb工具无效，小米是禁止应用特别容易死机卡界面。

截至目前 OneUI 8已移除了OEM解锁选项，这意味着未来将不会再允许bootloader解锁。刷机的时代终要落幕了。

这里是Chongxi，期待与您的下一次见面。

Thanks for watching.

–Chongxi 2025-08-19

「The Concealing Vol.1」是此社团第一个release，由来自Diversesystem，留声唱片，2088等厂牌/社团的国内共12位一线制作人共同创作的叙事性牛肉饭盛宴

:::blue[曲目列表]

1. The Concealing —Amonova

2. Corrosion —Noir_D

3. Doxa —Project_G

4. 痴生 —Dirty Octopus 苟活者无以苟活

5. LiMiMAL%VOiD —%IiLiUM 苦思者无以苦思

6. Alaya —硝酸生菜 修性者无以修性

7. 朝聖 —Estrella 朝拜者无以朝拜

8. 歸壹 —Sdklmr 窥日者无以窥日

9. 通靈 —Ac7i 贪食者无以贪食

10. Neuropathy —Postt & Z1broad2 嘶鸣者无以嘶鸣

11. 離線 —FliZ :::