Chongxiの咖啡屋

现代人的刻舟求剑

Chongxi — Tue, 11 Aug 2026 00:00:00 GMT

现代人嘲笑古人刻舟求剑，却忘了现在无时无刻有人在刻舟求剑。

古人刻舟求剑，因为没有更好的认知工具。现代人刻舟求剑，是因为信息太多节奏太快，主动放弃了重新思考的成本

所以古人是无知，现代人是主动选择的无知

刻舟求剑的问题不是蠢，是拿静态的记号去追动态的现实

路径依赖是同一件事的另一个方向。刻舟求剑是跟着别人的旧记号找剑：别人走这条路成功了，我也走。大哥学这个专业赚钱了，二哥也被推着去学。路径依赖是被自己刻下的记号锁死，投了几十万的成本不愿意放手

本质都是 用过去的信息指导现在的决策，忽略了时间这个变量

复刻的永远是结果的外壳，不是产生结果的条件

只论中国的游戏大厂便能看到许多经典的例子，原神/国潮搜打撤/非对称竞技等等等，这里就不展开赘述了

路径依赖不只是游戏行业的问题，基本都这样，游戏公司复刻国潮搜打撤，餐饮复刻海底捞... 信息越透明，成功案例越可见，幸存者偏差越严重：你看得到某款游戏的流水，看不到同期失败的同类游戏，模仿冲动越强，成功的条件反而越模糊

失败了怎么归因？归因到执行不力？从来没人问过船是不是动了，因为承认船动了，意味着那个刻记号的决定本身就是错的，这个代价太多人不愿意付

离开那条路的代价，从来不只是经济损失

某行业从事三十年的人，你让他承认可能走偏了，不是在质疑他的判断，是在质疑他这个人存在的意义。三十年已经不只是经验，是他全部的身份认同。所以他的反应不是在讲道理，是在自我保护

砸了四五十万不舍放手，不只是舍不得那笔钱，是舍不得当初说过的豪言，舍不得对他人的承诺，舍不得自我叙事，以及最后还在逞强的赌徒心理

说白了还是人在和自己作对

人不敢承认某件事做错了，不敢承认做出那个决定的自己是错的，事可以改，人格是你以为的你自己，质疑人格等于质疑那个做所有决定的人，那之后你还能相信谁来做下一个决定？

所以大多数人选择保护自己最后的“自尊”

人脑有个机制，会给自己圆一套自洽的故事

这个机制本身没有对错，不能用对错分，它在人类历史上救过无数人的命，让人在最脆弱的时候有个东西撑着，让人在叙事崩塌的时候能快速找到新的支点

人分手了哭完说"他不值得"，那一刻哭的已经不是对方了，是在保护"我是理智的人"这个叙事，是在骗自己说服自己没那么脆弱，需要说服自己不难过的人，才需要这句话撑着

但这个机制会被利用

个人叙事是自己骗自己，宏大叙事是别人骗你，机制完全一样只是尺度不同

邪教找的是叙事刚崩塌最脆弱的人，比如刚经历变故、意义感缺失的人，给一套完整自洽有归属感的新叙事填进那个空洞。进去的人不能直接拿蠢来定义，是在最脆弱的时候遇到了最及时的填充物，人底层机制如此

最厉害的叙事会把质疑本身定义为罪：你不信是因为你信仰不够坚定，你怀疑是因为外部敌人在腐蚀你。Web3也是这套，成功学也是这套

凡是声称自己是唯一真理的，基本都在做同一件事：用确定性换取你的思考权

而科学和这些东西最根本的区别是：科学家给出的是在当下框架下最合理的解释，不是宇宙真理，随时准备被更好的解释取代。这是科学之所以能进步的原因，真正客观的东西不需要宣称自己是真理，1+1=2从来不需要信徒

引用我曾说过的一句话：

人最难受的时刻，不是"我不知道"，而是"我一直以为我知道，现在你告诉我我不知道"

"我不知道"是空的，可以接受新东西。"我一直以为我知道"是满的，装的是脸面、过去的判断、那套脆弱的叙事

接受新的，得先把旧的倒掉，这个过程才是真正的代价。所有的求真，都是以承认自己曾经是傻逼为代价的

你把真相摆在一个人面前，他要接受，就要让自己的叙事碎掉，要在没有旧信仰支撑的地方重新站起来，而大多数人会本能地保护自己，拒绝接受你的真相

而且释怀和想明白的顺序其实经常被搞反，不是想明白了才释怀，是释怀了才能想明白。道理进不去，因为门是用情绪锁上的，能走到释怀这一步的人，往往是某一刻允许自己的叙事碎掉了一次，然后发现碎掉之后自己还在，发现也无所谓

比如说，各位小时候肯定上过学，小学时候的我自己早上迟到一分钟，恨不得天塌下来，而后来发现迟到也不会怎样，让叙事破裂了一次，释怀了，想明白了

那么然后呢

想到最后会发现一个死局

"我看透了"是叙事。"我知道我看透了是叙事"也是叙事。叙事这种东西进去啥都能圆出来，没数值纯机制

所以不存在真正的超脱，只有某种姿势：看见叙事在运作，知道自己也在里面，然后留着那个口子。不执着于答案，才能一直接近真相

人脑的保护机制和叙事生成器是底层代码，动不了。人类社会进化太快了，大脑根本来不及

但用户层可以写，算法可以优化，补丁可以打

知道叙事机制在跑，就在上面加一个监控进程。知道保护机制会触发，就在它触发的时候多等一秒。知道路径依赖会锁死，就在做决定之前先跑一遍条件检查：这个成功案例的条件是什么？那些条件现在还在吗？我自己的条件和他当时的条件匹配吗？

无法改写底层，那就在底层上面加补丁。工具就是工具，一般人拿扳手只能卸个螺丝，八级钳工拿扳手能给车辆大修，有人觉得扳手应该自己飞起来：那是在期待叙事，不是在用工具

承认内核有局限，才能写出真正有用的补丁

知道和做到之间永远有一道缝，这也没办法，但理清楚这些，至少能缩短待在错误里的时间

能做到这已经够用了

舞萌DX错误码0010深度解析及处理方法

Chongxi — Mon, 10 Aug 2026 00:00:00 GMT

什么是0010

ALLS 系统错误 0010 无法预计的游戏程序失败 ，是 SEGA ALLS引导进程 mxsegaboot 监测到游戏主程序 mai2.exe 非正常终止时弹出的错误提示，SEGA给出的解决办法只有 关机重启游戏主程序，本文将深度展开此方面进行深度讲解

错误体系

舞萌机台有两种错误体系

层级	显示	典型错误码
引导层	mxsegaboot	0001/0010
游戏层	游戏程序	0912/3100

触发机制

一句话概括就是，游戏进程没走 Core.Kill 正常通道死了

根据反编译我们可以了解到，ALLS设计了三条合法退出路径：

退出原因	游戏调用	引导层反应
重启	Core.Kill（重启）	正常退出
系统错误/进入test	Core.Kill（系统错误/测试）	正常退出
非正常退出	崩溃	0010

引导层的两条判定通道

mxsegaboot 通过两条独立通道识别异常退出：

退出码异常：游戏进程退出时，引导层读取其退出码。只有特定几个值属于「正常退出」（对应 Core.Kill 的合法值），其余一律判定为异常
进程崩溃标记：mxmaster 框架会记录游戏进程是否发生过崩溃（fault），引导层启动时查询该标记，若非零则判定异常

两者最后判定结果都是渲染0010错误页面

游戏如何触发

主线程异常路径

GameMain.Update() / LateUpdate()
  └─ try/catch → ExceptionHandler()
       ├─ 写崩溃日志（.log + .png，保留最近 4 份）
       ├─ 截图
       └─ 设 GameManager.IsException = true

GameMainObject.Update()
  └─ if (GameManager.IsException)
       ├─ isQuit = true
       └─ Application.Quit()   ## 没有 Core.Kill！→ 触发 0010

关键在于 IsException 分支只调 Application.Quit()，没有 Core.Kill()，而其他三个退出分支（重启 / 系统错误 / 进测试）都有 Core.Kill，这是游戏异常退出 → 引导层判定非正常的直接原因

后台线程

后台线程（如数据加载、触控、串口通信等）若有未捕获的异常，CLR 会直接终止进程，不经过 IsException 路径，同样触发 0010。这类崩溃日志里不会有 .log 诊断更困难

资源 ID 指向不存在的资源

最常见的，也就是我们常说的账号内存在非法的脏数据

游戏的资源管理器（DataManager.cs）在找不到对应 ID 时，几乎全部返回 null，只有Chara相关 Getter 有防御性空对象返回：

Getter	未命中返回值
`GetChara` / `GetCharaAwake`	`new CharaData()`
`GetPartner`	null
`GetMusic`	null
`GetMapData`	null
`GetIcon` / `GetPlate` / `GetTitle` / `GetFrame`	null
`GetLoginBonus` / `GetTicket` / `GetEvent` / 其余全部	null

任何 GetXxx(非法ID).字段 在未判空的情况下，均产生 NullReferenceException → 触发 0010

UserData.cs 中的 CheckDisableCollection（登录时自动重置非法收藏品）只覆盖了部分字段：

字段	防御	风险
EquipIconID / EquipPlateID / EquipFrameID / EquipTitleID	会重置为默认值	低
EquipPartnerID	❌ 无	高
SelectMapID	❌ 无（部分画面有 FindIndex 兜底，不全面）	高

已知崩溃清单

以下场景已经实测+代码分析，账号持有非法 ID 时必然崩溃：

编号	涉及资源	触发场景	崩溃形式
R1	Partner	登录后设置 / 换装界面构建	NullReferenceException
R2	Partner	结算画面	NullReferenceException
R3	Partner	好友对战结果	NullReferenceException
R4	Partner	登录奖励	NullReferenceException
R5	Music	Rival	NullReferenceException
R6	Music	选曲	NullReferenceException
R7	Music	结算 / 相册 / 读卡 / 选曲等多个流程	NullReferenceException
R8	Map	map / chara 等数据处理 20+ 处	NullReferenceException
R9	Map	地图数据同步	IndexOutOfRangeException

R8则是最典型重灾区

触发过程

账号存档中含有客户端不存在的资源 ID
（已下架 / 未更新的超前数据 / 脏数据）
  ↓
对应画面调用 GetXxx(id) 返回 null
  ↓
未判空直接访问字段 → NullReferenceException
  ↓
ExceptionHandler 记录崩溃日志
  ↓
GameManager.IsException = true
  ↓
GameMainObject.Update 检测到 → Application.Quit()
  ↓
引导层判定进程非正常退出 → 弹出 0010

如何解决

现象	判定方向	处理
固定账号崩	资源类（最常见）	修复账号内脏数据 / 避免登录此账号
固定曲 / 固定操作，换账号也崩	游戏文件损坏	重下
完全随机，任意账号均可触发	硬件类（SSD / 内存 / 供电）	查硬件
开机即崩，进不了游戏	可能是底层损害	问售后

做了一个明日方舟-奇象巡展的像素画拼豆工具

Chongxi — Sun, 09 Aug 2026 00:00:00 GMT

明日方舟最近不是更新了个奇象巡展吗，里面有个像素画功能，给了24x24像素的画布，以及四十种颜色，本人在画某些特别复杂的图的时候也确实比较低技术力，怎么画都画不好，然后就有了搓一个自动压缩工具，然后照着提示去挨个画

最终做出来的成品就是：明日方舟-奇象巡演像素画取色工具

Chongxi本身学的就是react啊，很自然的就选了vite+react的底层，然后UI的话，我是自己搓了一套组件，我现在的站群基本上都是用的同一套这种类似于孤星的设计

画布就是很常见的canvas了，至于这四十个颜色值其实是我拿macOS自带的取色工具按sRGB一个个手动扣出来的

后来发现挨个找颜色确实很不方便，于是干脆直接照搬游戏内的颜色布局，选中什么颜色就自动高亮提示了

至于自动化的话，第一我确实没学过OCR，虽然这种有明确网格的确实不难做（大概），但我还是有点懒不太想做（草），第二是各设备太割裂了，你得去想办法给各种设备和平台都做一下，而且每个平台模拟触摸点击的实现都不一样，一个个去做实在太费时间了，但我留了一手，如果有后续想做自动化的，我给了一个导出为json的，里面标记好了画布上每个坐标要涂什么颜色（甚至把这个颜色在第几行第几个都写了），如果有想做自动的可以试试看，本人最近在研究逆向工程，确实没精力再多学几个了（x 下面是成品展示截图

整体看着还是不错的，然后使用这个的话我建议尽量用小图，毕竟24x24太小了，如果是很大的图片会给你压成棍木导致什么都看不出来

舞萌DX国服封禁机制详解

Chongxi — Sat, 08 Aug 2026 00:00:00 GMT

引

在前段时间，舞萌更新DX2026时，有个特殊的搭档liz，也许是因为SEGA/华立在乎kaleidcsope模式的特殊性，也可能是因为过于泛滥，在七月22日，华立对国服非法获取liz搭档的账号全部发了bs1封禁，上一次发生这种官方下场声明发bs大概还是2024的集章卡乐曲latent kingdom，那么相信很多人对国服的封禁机制有一些好奇，甚至有些试图以科技方式修改掉bs1，本文就简单讲下，关于 banState 你想知道的那些事情

什么是 banState

国服账号有一个叫 banState 的字段，也就是封禁状态，由服务器下发

值	名称	效果
`0`	正常	无任何限制
`1`	警告（bs1）	弹警告窗，等 10 秒，可以进游戏，但限制游戏功能
`2`	封禁（bs2）	弹封禁窗，等 10 秒，踢回扫号页面，无法游玩

其他值客户端按正常处理

这个字段由服务器在你扫号时返回，客户端只执行

刷卡时发生了什么

扫号后，机台会向服务器请求一次preview数据，响应里就带着 banState，客户端拿到这个值之后，走一套状态机来决定你号怎么被处理

正常（0）：直接进游戏

警告（bs1）：弹出警告窗口，，等满 600 帧（60fps 下 10 秒）窗口自动关闭，之后放行进选曲界面

封禁（bs2）：弹出封禁窗口，同样等 10 秒。关闭后直接调用 Context.SetState(StateType.ConfirmEntry)，把你踢出去不让玩

bs2 账号的全量数据 GetUserDataApi 照常下载，数据下载不会被拦截，只是下载了你也玩不了

游戏限制

警告和封禁账号进入游戏后（bs2 进不来，但如果以任何方式绕过入口），会触发三类判断，判断条件统一是 BanState != 0，且检查双人 任何一侧被标记，双方都受限

1. 友人对战禁用

if (!IsAnyUserWarningState())
{
    AddVsGhost(...);
    AddMapGhost(...);
    AddBossGhost(...);
    AddReliefGhost(...);
}

如上，友人对战等玩法会直接被禁用

2. kaleidxscope 进度被锁定

万花镜进度会被强制回退到 FoundCenterTower 阶段，CenterTowerCleared 及以上的进度一律不显示：

if (kaleidxScopePhase >= KaleidxScopePhase.CenterTowerCleared && IsEntryBanUser())
{
    kaleidxScopePhase = KaleidxScopePhase.FoundCenterTower;
}

3. LEGEND

UnlockMusicProcess.IsAnyLegend 会检查所有玩家的 BanState，只要有一方非零就返回 false ：不计入 LEGEND 段位，传导作废

纯服务器控制

没有任何手段去更改bs状态，因为这玩意是服务器侧控制的，哪怕通过mitm把传下来的bs状态改成0，也没法彻底改变服务器里的值，纯粹自欺欺人

结

	bs0 正常	bs1 警告	bs2 封禁
进游戏	✅	✅（罚站10s）	❌
友人对战	✅	❌	❌
万花筒进度	正常	锁定	锁定
LEGEND	✅	❌	❌

误封等误解

舞萌开机网络自检底层技术说明，断网如何排查讲解

Chongxi — Fri, 07 Aug 2026 00:00:00 GMT

上文粗略讲了舞萌开机初始化流程，本文深入讲下困扰不少人的机台联网部分

1. 总览

1.1 自检在开机链路中的位置

上篇初始化文章我们讲过 maimai 机台运行两套并行系统：amdaemon（原生后台服务，负责与运营服务器的全部通信）和 Unity 游戏程序（负责游戏）

开机按 6 步推进，网络自检是第 3 步（PowerOnProcess.WaitNetWork）。开机初始化画面逐行显示每项检查的状态：Check 初始化中 / Good 好 / NA 跳过 / Bad 坏

网络自检的目标是确认机台能否与服务器正常通信，前 5 项检查机台自身和局域网，后 4 项检查与服务器的连通与存活

1.2 链路总览

[开机] amdaemon 启动
  └─ ALPB 开机自检驱动
       └─ am::network::Tester 依次执行 9 项网络自检（am::networktest）
            0 IpAddressChecker    ← 本机 IP 有效性
            1 GatewayChecker      ← 网关连通性
            2 DnsLanChecker       ← DNS 配置有效性
            3 HopsChecker         ← 域名解析 + ICMP 路由跳数
            4 LineTypeChecker     ← 线路类型（LAN/WAN）
            5 AllnetAuthChecker   ← ALL.Net 认证 + 下载指令就绪（120s）
            6 AimeChecker         ← CHIME 微信 AIME 服务存活探活
            7 EmoneyChecker       ← 电子钱包（国服废项，NA）
            8 AimePayChecker      ← AimePay（国服废项，NA）
              │ 每项结果经回调上报
              ▼
        amdaemon app 侧 NetworkEventListener
              → 可用性标志（IP / Hops / AllnetAuth 三项）
              ▼ IPC (NamedPipe)
[Unity]  AMDaemon.Network.TestInfo / PowerOnTestInfo
              ▼ 每帧轮询
        PowerOnProcess.WaitNetWork
        （item0 超时 15s / item5 Net 认证 120s）

1.3 9 项速览

item	检查器类名	查什么	主要依赖
0	IpAddressChecker	本机 IP 是否有效（非 APIPA）	本机 / DHCP
1	GatewayChecker	能否 ping 通网关	本机内网
2	DnsLanChecker	系统 DNS 配置数量是否有效	本机内网
3	HopsChecker	目标域名能否解析 + ICMP 逐跳计数	DNS + 目标域名
4	LineTypeChecker	线路类型是否为 LAN	本机网络接口
5	AllnetAuthChecker	ALL.Net 认证 + 下载指令就绪	ALL.Net 服务器（120s）
6	AimeChecker	会员服务器存活	CHIME 服务器
7	EmoneyChecker	Emoney 服务器存活（国服废项）	无
8	AimePayChecker	AimePay 服务器存活（国服废项）	无

2. 机制基础

2.1 三层结构

层	角色	说明
原生引擎层（am::network）	真正执行网络操作	内嵌各引擎检查器（IpAddr / Gateway / DnsLan / LocationRouter 等）
检查器层（am::networktest）	包装与判定	总 Tester 串起 9 个 item 检查器，每项持有对应引擎指针
游戏程序层（Unity C#）	读取与显示	每帧轮询状态字，翻译为 Good / NA / Bad / Check

网络操作的实际执行在 am::network::* 引擎类中完成；am::networktest::* 是包装层，负责驱动引擎并将结果上报给游戏程序

2.2 执行状态机

每个引擎检查器内部维护一个异步步进器（Waiter），生命周期为：

清空 → 入队（挂载检查目标）→ 启动
→ 每轮步进 → 判断是否完成 → 取 OK/NG 标志 → 写出结果

结果码：4 = OK（通过）、5 = NG（失败）、1 = 等待 / 跳过

2.3 item 检查器的核心字段

每个 item 检查器对象内含以下关键字段：

item 编号（0–8）
状态槽：2 = OK，3 = 运行中
引擎结果快照：引擎完成后拷入，供判定逻辑读取
显示状态字：游戏程序每帧读取此字节，决定屏幕上显示什么

2.4 驱动循环

总 Tester 每轮依次遍历 9 个 item：

读当前 item 状态槽，已 OK 则跳过
首轮：拷入引擎结果快照，写状态"运行中"，触发回调
后续：持续步进引擎，直到结果就绪
九项全部完成后，Tester 总状态置为完成

2.5 shouldRun 谓词

每个 item 有一个 shouldRun 函数，决定该项是否需要运行。若返回fake（如无对应配置目标），该项直接跳过，游戏侧显示 NA。国服 item7（Emoney）和 item8（AimePay）均因此固定返回 NA，直接就不显示该检测项目

3. 9 项逐一说明

3.0　IP 地址（IpAddressChecker）

引擎类：am::network::IpAddressChecker

判定逻辑：

读取本机网卡当前 IP 地址，按地址段判定：

169.254.x.x（APIPA）→ NG：这是操作系统在 DHCP 失败或网线断开时自动生成的临时地址，说明机台未获得有效 IP
规定的私有地址段 → OK
网卡无配置（ignore_unconnected 开关触发）→ NA 跳过

超时：游戏程序侧对本项设 15 秒超时，超时直接判 Bad

3.1　网关（GatewayChecker）

引擎类：am::network::GatewayChecker（继承自 GatewayPreChecker）

判定逻辑：

向配置中的网关地址发送 ICMP ping，等待响应：

ping 成功 → OK
ping 失败 → 退避重试，间隔从 60 秒起逐次翻倍，上限约 900 秒（约 4 次重试），全部失败后判 NG

底层使用 ICMP 实现（altr_icmp），也就是说，能 ping 通网关路由器则通过；网关 IP 配错、交换机不通或网线物理断则最终 Bad

3.2　本地 DNS（DnsLanChecker）

引擎类：am::network::DnsLanChecker

判定逻辑：

读取配置中 DNS 服务器的数量，与系统中实际可查到的 DNS 数量对比：

实际数量满足配置要求 → OK
不满足（如 DNS 未下发或配置错误）→ 等待 / NG

底层调用系统 DNS 解析接口（amDnsInit / amDnsResolveNameA/W），配置里写了几个 DNS，系统里就得能查到几个，DNS 没配或 DHCP 没下发则挂

3.3　跳数（HopsChecker）

引擎类：am::network::HopsCounter（实际解析由 NameResolver 驱动）

判定逻辑：

对目标主机名进行 DNS 解析
解析成功后，通过 ICMP 逐跳计数
C# 侧 item3 显示实际跳数

DNS 解析失败 → NG
解析成功 → 显示跳数并 OK

前置依赖 item2（DnsLan）正常，域名能解析就过，同时显示路由跳数；解析不了则 Bad。

3.4　线路类型（LineTypeChecker）

引擎类：am::network::LocationRouterChecker

判定逻辑：

检测当前线路类型：

LAN → OK
WAN → NG，错误信息 Network type error(WAN)

引擎内部通过解析网络地址与子网掩码判断线路归属，底层依赖 NameResolver 解析目标地址

3.5　Net 认证（AllnetAuthChecker）

引擎类：alw_auth（ALL.Net 认证库）

判定逻辑（双条件，两者须同时满足）：

认证通过 ：与 ALL.Net 服务器完成认证握手
下载指令就绪：从服务器取得 netdeliver 下载指令 URI

任一条件不满足 → 保持 Check 状态，引擎持续推进，游戏侧设 120 秒硬超时，超时直接判 Bad

认证链路阶段：DNS 解析 → 认证握手 → 下载指令获取。任一环节与服务端通信异常则卡在 Check 直到超时

item5 Bad 后将阻断后续标题服配置下载流程，机台无法进入游戏画面，所以必须完整跑通 ALL.Net 认证流程才过

3.6　CHIME（AimeChecker）

引擎：Aime 网络客户端（AimeNetworkClient）

判定逻辑：

检测是否正在进行（引擎 state 满足运行中条件）
读取 CHIME 客户端的探活结果区首字：
- 等于 0 → OK
- 非 0（错误码）→ 运行中 / NG

游戏侧对应 Chime.Instance.IsDBAlive，即微信 AIME 服务的数据库存活探活

后续 WaitAime 阶段（Chime.StartDBAliveCheck）会再探一次，两处共用同一探活接口

3.7　Emoney（EmoneyChecker）国服废项

引擎：EmoneyNetworkClient

判定逻辑：结果区首字等于 0 → OK，非 0 → NG（与 AimeChecker 结构相同）。

国服：无配置目标，shouldRun 返回假，固定 NA 跳过。游戏界面无对应显示位（该位置复用为 TitleServer 探活，使用 OperationManager.IsAliveServer）

3.8　AimePay（AimePayChecker）国服废项

引擎：AimePayCheckInSequencer

判定逻辑：结果区首字等于 0 → OK，非 0 → NG

国服：与 Emoney 相同，无配置目标，固定 NA 跳过，游戏页面无显示位

4. 结果回传与屏幕显示

4.1 传递链路

引擎结果（OK / NG）
  → item 结果区快照（引擎完成后拷入）
  → item 显示状态字（游戏程序每帧读取）
  → 网络可用性标志（IP / Hops / AllnetAuth 三项单独上报）
  → IPC（NamedPipe）
  → C# WaitNetWork 逐项翻译为屏幕状态

三项可用性标志（IP、Hops、AllnetAuth）在 amdaemon app 侧单独维护，供后续流程判断网络就绪状态

4.2 游戏翻译规则

条件	显示
未忙且未完成	NA
忙且原生已判 NG	Bad 坏
忙且 item0（IP）超 15 秒	Bad 坏
忙且 item5（Net 认证）超 120 秒	Bad 坏
忙且其他	Check 初始化中（闪烁）
完成且通过	Good 好（item3 额外显示跳数）
完成且跳过	NA
完成且失败	Bad 坏

超时兜底在游戏层（Stopwatch），错误语义在原生层

4.3 游戏显示侧说明

TestModePageNetwork.ItemEnum 共 8 位，对应关系：

item0–5：直接读 Network.TestInfo，对应 IpAddress / Gateway / LocalDns / HopNum / LineType / AllnetAuth
item6（Aime）：读 Chime.Instance.IsDBAlive，即 CHIME 微信 AIME 探活结果
item7（TitleServer）：读 OperationManager.IsAliveServer，与原生 item7 Emoney 无关（国服复用该槽位）

EnumEnum 中无 Emoney / AimePay 对应位

4.4 后续流程依赖

WaitNetWork 任一 Bad 或完成
  → NetWorkReady
  → WaitAime（Chime.StartDBAliveCheck 再探一次）→ AimeReady
  → OperationManager.StartTest()（下载配置）
  → WaitTitleServer（下载成功且标题服存活）
  → Released：进入正常游戏调度

item5（Net 认证）Bad 会在 WaitTitleServer 阶段阻断下载，其余项 Bad 不直接拦截流程但会影响后续功能

4.5　标题服务器（TitleServer）检查说明

title 不算严格意义上的原生网络自检。前文 9 项（item0-8）全部由 amdaemon 原生 am::network / am::networktest 体系执行，归属 WaitNetWork，原生侧没有 title 检查项：标题服务器不在 amdaemon 开机网络自检的枚举里，与 item7 Emoney 也无关

但开机流程确实会检查它。title 检查发生在网络自检之后、进入正常游戏调度之前，由 Unity游戏侧 OperationManager 驱动：

WaitNetWork 完成 → NetWorkReady
  → WaitAime（CHIME 再探一次）→ AimeReady
  → OperationManager.StartTest()（向 title 服务器下载配置）
  → WaitTitleServer（下载成功一次 + 标题服存活）→ Released

判定条件：WasDownloadSuccessOnce && IsAliveServer —— title 配置至少成功下载过一次，且标题服当前存活
谁在检查：Unity 游戏侧（OperationManager），不是原生自检框架
卡住表现：9 项网络自检全 Good 仍停在标题画面 → 大概率卡在 WaitTitleServer
测试菜单：TestModePageNetwork 第 8 位显示 "TitleServer"，读的是 OperationManager.IsAliveServer：复用原生 item7 的显示槽位，与原生自检无直接关系

所以对 title 的定位可以这样理解：严格意义上它是"配置下载 + 存活探活"，不属于原生开机初始化，但因为机台每次启动都会走到这一步、同样会被检查，广义上可以算作开机自检的一环。它不在本文对amd原生 9 项网络自检的判定体系内，是网络自检通过之后的部分

5. 架构类名

5.1 networktest 检查器层

item	类名	vftable 关键槽
0	am::networktest::IpAddressChecker	shouldRun / update
1	am::networktest::GatewayChecker	shouldRun / update
2	am::networktest::DnsLanChecker	shouldRun / update
3	am::networktest::HopsChecker	shouldRun / update
4	am::networktest::LineTypeChecker	shouldRun / update
5	am::networktest::AllnetAuthChecker	shouldRun / update
6	am::networktest::AimeChecker	shouldRun / update
7	am::networktest::EmoneyChecker	shouldRun / update
8	am::networktest::AimePayChecker	shouldRun / update

每项 vftable 含 6 个有效槽：dtor / shouldRun / 通用×2 / 辅助 / update。其中 shouldRun（slot1）决定是否运行，update（slot5）驱动引擎步进并写结果

5.2 am::network 引擎层

引擎类	对应功能
am::network::IpAddressChecker	IP 地址有效性检测
am::network::GatewayChecker（: GatewayPreChecker）	ICMP ping 网关
am::network::DnsLanChecker	DNS 配置数量验证
am::network::HopsCounter / NameResolver	域名解析 + 路由跳数
am::network::LocationRouterChecker	线路类型（LAN/WAN）判定
alw_auth	ALL.Net 认证全链路
AimeNetworkClient	CHIME 客户端探活
EmoneyNetworkClient	Emoney 探活（国服废项）
AimePayCheckInSequencer	AimePay 探活（国服废项）

5.3 底层库分工

库	功能
alw_auth	ALL.Net 认证、下载指令获取
alw_network	网络阶段初始化
alw_dns	DNS 解析（alwDnsExecServer）
altr_icmp	ICMP / ping（网关与跳数底层）
alpb_stream_ssl	SSL 连接
alib_pv2_lite（ALPB）	开机自检状态机驱动

6. 依赖分类与排查

6.1 依赖分类

item	机台断网就挂	服务器没响应就挂	硬超时
0 IP 地址	✅	—	15s
1 网关	✅	—	—
2 本地 DNS	✅	—	—
3 跳数	✅	✅（域名不通）	—
4 线路类型	✅	—	—
5 Net 认证	✅	✅	120s
6 CHIME	✅	✅	—
7 Emoney	—	—	国服废项，NA
8 AimePay	—	—	国服废项，NA

6.2 屏幕状态含义

Check（初始化中闪烁）：引擎还在等待结果。长期 Check 多见于 item5 / item6，需确认服务端连通性
Bad（坏）：该项判定失败。item5 Bad 会阻断后续流程，其余项 Bad 不直接卡流程
NA：该项不参与检测。item7 / item8 国服固定 NA，item0 在 ignore_unconnected 模式下也会 NA

6.3 排查方向

item 0–4 内网失败：建议检查机台本身的网络配置：网线是否连通、DHCP 是否正常下发 IP 和 DNS、网关地址是否配置正确、线路是否接入局域网

item 5（Net 认证）失败或长期初始化中：机台与 ALL.Net 认证服务器之间的连通性问题，建议检查机台是否连接到外网，以及服务器是否在线，可以用isMaiDown 查看服务器在线状态

item 6（CHIME）失败：CHIME 微信 AIME 服务连通性问题。检查 CHIME 服务端状态及机台到服务端的网络路径，建议使用刚才那个网站查看

item 7 / 8：国服废项

6.4 9 项判定标准总表

item	检查器	判定条件	通过/失败
0	IpAddressChecker	本机 IP 非 APIPA（169.254.x.x），属于有效网段	OK / NG
1	GatewayChecker	ICMP ping 网关成功	OK / NG
2	DnsLanChecker	可查到的 DNS 数量满足配置要求	OK / NG
3	HopsChecker	目标域名 DNS 解析成功，ICMP 逐跳完成	OK / NG
4	LineTypeChecker	线路类型为 LAN	OK / NG
5	AllnetAuthChecker	认证通过且下载指令就绪	OK / 超时 Bad
6	AimeChecker	CHIME 探活结果正常	OK / NG
7	EmoneyChecker	国服废项，shouldRun 为 fake	NA
8	AimePayChecker	国服废项，shouldRun 为 fake	NA

附录

华立服务器状态监测: 华立服务器死了吗 - isMaiDown?

舞萌机台开机初始化进程详解

Chongxi — Wed, 05 Aug 2026 00:00:00 GMT

不严谨的说 maimai 机台里跑着两套系统：

amdaemon：一个原生后台服务，负责机台与世嘉服务器的全部通信（联网报到、读卡验证）
Unity 游戏程序

整个过程我们可以分 6 步，双屏上的开机画面会同步显示每一步的进度状态

初始化中 CHECK
好 GOOD
坏 BAD
跳过 NA

1. 通电

机台通电后 Windows10 启动，amdaemon 自动运行，开机阶段做两件网络事：

Allnet：向 NET服务器 发一次 initialize 请求，然后服务器返回游戏服务器地址、地区码、门店 ID
AIME 注册：本地初始化扫码读卡器（Chime.Instance.Init，注册 keychip 身份），开机不发 get_data、不拿 token；get_data 只在玩家刷码时由 amdaemon 发起，token 由读码响应带回

这两步完成后，amdaemon 置位 Core.IsReady，然后游戏程序开始初始化

游戏程序启动

Unity 场景加载，GameMainObject 执行初始化

加载原生 DLL 预加载库
读取机台 ini 配置
建 AmManager（投币、扫码、网络、双触摸屏等子系统的总管理器，此刻只建空壳）
建声音、数据、谱面管理器
生成 AES 密钥表
建局域网组件：Setting、Advertise、DeliveryChecker、Party
注册原生 daemon 异常回调

这一步不做任何网络请求，只建好整个程序的对象结构

2.5 等 amdaemon

每帧检查 Core.IsReady，没就绪就什么都不干，就绪后

调一次 GameMain.LateInitialize：把 PowerOnProcess（开机自检进程）以 priority 50 放进进程调度器，并启动一个后台 PingChecker 线程
从这帧起，每帧固定执行：Core.Execute → GameMain.Update（游戏主逻辑）→ GameMain.LateUpdate

进程调度器机制：进程按优先级排队（数字越小越先跑），状态机为 Start→Update→Released，Released 的进程在晚更新阶段被释放并移除，开机链路完全靠这个调度器接力

AmManager

第 2 步只建了 AmManager 空壳，真正的子系统是在等 amdaemon 就绪后由 AmManager 自己创建的

GameMain.Update 每帧调 AmManager.Execute()，其内部状态机：

WaitAmDaemonReady：等 Core.IsReady。就绪后创建全部子系统:Backup、Credit（投币）、EMoney（国服没有）、Accounting、AimeReader（国服是扫码）、Network（网络测试）、Delivery（下发数据）、双触摸屏驱动 NewTouchPanel[2]。全部建完后置 IsReady=true，切到 Run
Run：每帧逐个执行这些子系统

也就是说：Core.IsReady 触发了两层：外层 GameMainObject.Update 启动开机自检进程，内层 AmManager 把硬件子系统真正建起来，两者独立同时运行

PingChecker

GameMain.LateInitialize 启动的异步后台线程，每小时测一轮服务器延迟：

触发时机：以 Allnet 下发的 Auth.AuthTime 为基准，按它的分钟偏移推算整点起点，同小时只测一次（去重）
一轮测 20 个 Ping 包：包间隔 >10 秒、单个超时 5 秒，失败的记丢包率
结果处理：去掉一个最大值和一个最小值后取平均作为延迟，连同丢包率/最大值写进 Backup（测试模式可查）
测试模式下自动中止，结果只用于网络诊断，不参与开机流程

3. 开机自检

开机画面出现，双屏开始逐项检查：

等 amdaemon：等 Core.IsReady。就绪后做一串硬件准备：初始化输入系统、读取 amdaemon 后的配置、初始化 OperationManager、探测 COM 串口（检查 USB4 集线器插在哪个口：COM20/24/28/32 之一，据此推断 LED 灯带接在哪个串口，比如探测到 COM20 就把灯映射到 COM21/COM23），初始化 LED 控制器，把 JVS 面板灯全部点亮成黑色
资源加载：等谱面/图片/模型资源全部装载完成（assetManager.IsDone 且谱面滑条线程空闲），屏幕显示加载进度。完成后再停留 2 秒
网络自检：逐项测试网络连通，屏幕逐行显示每项的好坏。已知检查项共 8 项：IP 地址、网关、本地 DNS、跳数、线路类型、Net 认证、会员服务器、标题服务器。其中两项有硬超时：网络项 15 秒、Net 认证项120 秒，超时判坏
会员服务器：若认证有效（Auth.IsGood），向会员服务器发起存活检测。服务器可达显示好，否则坏，无效则跳过
标题服务器检查：让 OperationManager 下载游戏配置（GetGame*），只要成功下载过一次（WasDownloadSuccessOnce）且服务器在线，就判好，完成后停留 2 秒

全部通过后进入 Released：把 StartupProcess 加进调度器，释放自己，并把 IsGameProcMode 置为 true（标记进入正式游戏流程）

4. 正式启动

这个进程做硬件 + 局域网的完整自检：

触摸屏：两块屏的驱动都就绪或报错为止，有错误把错误码记录进系统
LED 灯带：两侧 LED 初始化完成，完成后初始化摄像头系统
摄像头：二维码摄像头 + 顶部摄像头就绪，完成后初始化读卡器，有摄像头错误码也记录进系统
数据加载：等数据管理器加载到 100%。完成后依次：配置收藏系统、初始化地图数据、下载谱面（DLMusicScore + DownloadMusicScore）
局域网-配置分发（WaitLinkDelivery）：局域网内配置分发服务器就绪，若是服务端机且无局域网，直接好跳过。重复机号会显示"机台重复"错误
局域网-设置同步（WaitLinkSetting）：同步事件模式、事件曲目数等设置。若局域网内出现重复机号，报错误 3201 并记录
局域网-Party（WaitLinkParty）：加入 Party（Party.Start(机器组ID)）
局域网-LinkAdvertise：初始化 Advertise
Ready：全部完成后停留 2 秒
Released：把 WarningProcess 加进调度器，释放自己，投币器切到正式游戏模式，重跑一次 GameManager 初始化；置 IsInitializeEnd = true（这是游戏主循环开始做错误检测等逻辑的前置条件）

另外：进程启动时会挂一个 priority 51 的"通用消息进程"作为消息管理器（弹窗、计时器等通用 UI 都走它），并再次调用 OperationManager.Initialize()（这个调用是幂等的，重置到检查认证状态）

OperationManager

这台机台的一切标题服业务数据（游戏配置、事件、曲目、用户数据上传下载）都由 OperationManager 管开机期间它跑一个四态状态机，标题画面出现前一般已走完：

CheckAuth（检查认证）：Initialize() 启动，轮询 Core.IsReady && Auth.IsGood（amdaemon Allnet 认证）+ 门店 ID 非 0。认证通过才继续
Download（下载配置）：_dataDownloader.Start() 拉取全部 GetGame* 系列配置（GameSetting/GameEvent/GameRanking 等）。第 3 步标题服务器检查里的 WasDownloadSuccessOnce 就是这一步至少成功过一次
Upload（上传数据）：_dataUploader.Start() 把运营数据（投币记录等）上传
Idle（空闲轮询）：之后每帧检查配置是否有更新，需要时重新下载

标题画面出现后，OperationManager 就停在 Idle：每帧轮询配置更新、跑维护/关门计时器、PingChecker 每小时测速写 Backup

第 3、4 步全程不发起任何业务 API，只有配置下载（GetGame* 系）和 Ping 探测两类网络行为

5. 版权检查

进入版权画面之前先查 5 项，任一不满足就报错误 912 并走系统错误流程（最终退出游戏程序，见第 6 步）：机器名含 "ACA"、显卡是 "GeForce GTX"、CPU 是 "Core(TM) i3-8100"、程序装在 X 盘、错误日志路径在 Y 盘

检查通过后显示版权警告画面。若地区码为 1（日服），播一段版权 logo 动画，播完结束；否则直接结束。整个进程生命周期内这个画面只显示一次（静态标记 OnceDisp）

结束时一次性启动两个常驻进程并释放自己：

CommonProcess（priority 10）：后台 UI 管理器：时间、音量、信息弹窗、计时器都是它
AdvertiseProcess（priority 49）：标题画面

错误码

屏幕报错画面会显示 4 位错误码（Error.Number 补零），开机链路内会出现的错误码全表：

码	名称	含义	触发时机
0912	GraphicBoard_RenderError	显卡/图形板错误	第 5 步户口校验任一失败；或开发机渲染宽度不足
3100	CameraNotFill	摄像头画面缺失	摄像头自检（第 4 步）两摄像头未能全部出画面
3101	CodeReader_InitializeFailed	扫码器初始化失败	二维码摄像头不可用
3102	PhotoCamera_NotFound	拍照摄像头没找到	拍照摄像头不可用
3201	GroupRole_DuplicateParent	局域网内重复机号	第 4 步设置同步/广告分发发现重复机号
3300-3303	TouchPanel_Left/Right_OpenError/InitError	触摸屏打开/初始化失败	第 4 步触摸屏自检
6501	AimeConnectError	AIME 读卡连接错误	原生读卡器（开机不显示，运行中刷卡时报）
6506	AimeFiruUpdateError	AIME 固件更新错误	原生读卡器（运行中）

其余错误码（LED 串口板 0-9、局域网 Party 组网、网络记账 E00-E15 等）属于底层诊断，不在错误屏显示，测试模式里可查

开机中一直初始化意味着什么

一直初始化（闪烁）：还在等待该步骤完成。常见于等 amdaemon、等资源加载、等网络自检、等会员服务器检测、等标题服下载
坏：该项失败。多数自检项坏后会继续往下走，部分会直接系统错误然后退出，比如912
硬超时：网络项 15 秒、Net 认证项 120 秒后强制判 Bad。会员服务器检测与标题服下载则一直等到有结论为止（依赖请求自身的超时配置）
长期卡在初始化：说明该项依赖的服务器/硬件无响应，通常过不了它后续依赖的步骤（例如 Net 认证超时后，标题服务器检查也过不了）

6. 初始化完毕

AdvertiseProcess 负责标题待机：显示 logo → 标题 → 判断榜单：

检测到输入 → 淡出过渡到 EntryProcess（游戏入口），此后投币/刷码 → 确认 → 进入游戏
有demo → 进 AdvDemoProcess（放autoplay的pv），否则重新回到标题画面

机台进入标题待机的那一刻，就是"初始化完毕"：可投币、可读卡、服务器在线、配置已下载。此后 OperationManager 停在 Idle 态（第 4 步详解），每帧检查配置更新、跑维护/关门计时器，PingChecker 每小时发一次测速包更新延迟数据

两个后台服务

从第 2.5 步起，GameMain.Update 每帧还检查两件事：

错误检测：若已初始化完成且系统有错误（且配置允许），强制登出玩家、终止 Party、把 ErrorProcess 加进调度器、置错误模式、关声音关投币
TEST 按钮：按到测试键（且处于游戏或错误模式），强制登出玩家、把 TestModeProcess 加进调度器、记录"进入测试模式"、进入测试子流程

什么时候退出/重启

GameMainObject.Update 每帧还看四个退出标志，任一命中就结束游戏程序：

系统异常 → 直接退出
IsGotoSystemTest（进系统测试）→ Core.Kill(3) 后退出
IsGotoReboot（需要重启）→ 需要自动重启则 Core.Reboot()，否则 Core.Kill(1) 后退出
IsGotoSystemError（系统错误，如第 5 步的 912）→ Core.Kill(2) 后退出

结

以上就是舞萌DX机台开机初始化的整个软件底层行为，如果您对此感兴趣，欢迎follow本blog，将本站添加到收藏夹/订阅rss，后续会更新更多此类文章

为什么喜欢音乐反而不该去学音乐？

Chongxi — Tue, 04 Aug 2026 00:00:00 GMT

喜欢一件事，不代表你需要去搞懂它

有些人有这样的习惯：喜欢写作，就去研究叙事结构；喜欢音乐，就去学乐理和编曲。出发点是热爱，觉得懂得更多就能享受得更深

但结果可能是相反的

一个对音乐一无所知的人，可以被一首曲子听哭，他不需要知道为什么，他感受到的是那首曲子真正想表达的东西

但当你开始学，哪怕只是浅尝，只是业余地了解了一些编曲知识、一些唱法技巧，那么你听音乐时的第一反应就悄悄变了。不再是"这首曲子让我想到什么"，而是"这里的转调处理得很聪明"，"这段弦乐进来得很及时"

你在分析它，而不是感受它

更难受的是，你发现自己卡在了中间

一个孩子看魔术时眼睛发亮，那是真正的魔法。一个学了点魔术原理的业余爱好者，知道了那是机关和手法，但他变不出同样精彩的魔术。他失去了魔法，却没得到新魔法。

就这样悬在两者之间：回不去当初什么都不懂时的震撼，也到不了能用技艺创造震撼的那一步

那点业余知识，没有成为台阶，他把你挡在外面，没有带你进去

这个损失之所以难以察觉，是因为音乐本来是所有艺术形式里最不需要"理解"的一种。它绕过语言，绕过逻辑，直接和情感对话。而专业知识做的事情，恰恰是在这条路上修了一道关卡：所有情感在抵达你之前，都要先经过脑子里那套分析系统，从而导致听一首歌的感觉彻底变味了

所以如果你只是喜欢，不妨就停在喜欢的地方

不懂乐理，不是缺陷，是你还保有的一种能力。那种"不知道为什么就被打动"的状态

这不是等待被纠正的无知，而是一种值得珍惜的东西

从装逼到嘉豪：中国互联网的精神胜利进化史

Chongxi — Wed, 29 Jul 2026 00:00:00 GMT

某中学教室里，一个穿黑色连帽卫衣、戴黑色口罩的男生，对着空气打碟。视频传到网上，他被冠以"嘉豪"之名，没有人知道他真名叫什么，也没有人在乎，重要的是，他有了一顶帽子，而这顶帽子，很快就不够用了

最初，想成为嘉豪是有门槛的：你得穿黑卫衣，得戴黑口罩，得在公共场合做出某些"中二"动作，才够格被叫一声嘉豪。但帽子这种东西，戴着戴着就会变大

很快，有人开发出了"豪意值"系统：普通嘉豪、三角洲嘉豪、红楼嘉豪...从游戏菜鸟到文学爱好者，从健身打卡的到高档餐厅打卡的，全部纳入评级：帽子的尺码从小号扩展到大号，再到所有人都能戴

于是出现了一个奇景：你觉得某人是嘉豪，你批评嘉豪这个词被滥用，你也是嘉豪。总统发表演讲，超级嘉豪。科研人员有了新发现，终极嘉豪，alan walker本人，嘉豪祖师爷

一个能套进所有人的词，本质上什么都没说，而这种词，也不是第一次出现了

嘉豪有一条清晰的家谱：装逼、凡尔赛、显眼包、嘉豪，都是换汤不换药罢了：你做了我没做的事，我给你一个难听的名字，每隔一段时间，旧词被用钝，新词顶上，完成同样的使命

就连装逼这个词现在已经失去了杀伤力，很多人自称装逼，甚至带着几分自豪，词被用烂，语义磨损，最后反而被驯化成了中性词。而嘉豪现在正处于攻击性最强的阶段，再过几年，大概也会步同样的后尘

土壤没变，只是庄稼换了一茬

当你仔细审视便会发现，这套逻辑有一个很大的破绽，只需一个问题就能戳穿它：如果站在那里的是你，你还叫自己嘉豪吗？

一个人在高档餐厅吃饭，你骂他豪。如果那个人是你，你叫自己什么？你叫自己"生活品质"，叫自己"努力的回报"。同一张桌子，同一顿饭，主语换一下，性质就变了

嘉豪从来就不是一个评价行为的词，它是一个评价距离的词，你和那个人之间的距离，以及你无法接受这个距离的心情

这是人类最底层的一条代码，双标：我可以，叫实力。你可以，叫装逼

鲁迅写阿Q，被人打了，心里默念儿子打老子，完成一次心理自救。一百年后，这套机制升级了，更加方便：你不需要挨打，只需要看见一个活得比你用力的人，敲几个字，发出去，胜利到手

所以越频繁地叫别人嘉豪，就越精准地暴露了一件事：那个人让你感受到了压力。这顶帽子是双面的，扣在了别人头上，照出来了自己

至于嘉豪这个词最后是会消失的，就像装逼一样，迟早被用钝，被新词替代。到那时候，没有人记得那个教室里打碟的男生，也没有人记得这顶帽子最初是什么形状

但只要出头就该被按的心理还在，下一个嘉豪就已经在路上了

它不叫嘉豪，但你一眼就能认出它

因为那顶帽子的形状，从来没变过

游蒋介石故居：奉化溪口

Chongxi — Mon, 27 Jul 2026 00:00:00 GMT

引

在很早之前，Chongxi其实已经去过一次蒋介石故居了，不过由于时间过于久远，具体细节已经忘了，那么这次便打算重游一次，刷新下记忆，顺便记录一下

简单介绍

蒋氏故居，在浙江宁波奉化区的溪口镇，是蒋介石和蒋经国父子俩的老家

这可不是简单一栋房子，而是一片建筑群：祖居丰镐房、蒋介石出生的玉泰盐铺、他和宋美龄住过的文昌阁、蒋经国从苏联回来后落脚的小洋房，各有各的故事。整个溪口镇现存二十多处民国史迹，被叫做"民国第一镇"，逛起来信息量很大

有意思的是，1949年解放军进入溪口之前，毛泽东专门下令保护这里。政治对手的故居能完好保存至今，细想很有意思

谁是蒋介石

虽然我觉得都认识，这里还是简单过一下吧

蒋介石（蒋中正），历史上的国民党领袖，早年跟孙中山干革命，后来北伐名义上统一中国，抗日战争时期是中国战区的最高统帅。然后就是跟共产党打内战，打到1949年实在撑不住，带着一批人退到台湾，在那边继续当"总统"直到1975年去世

蒋委员长一生争议极大，说什么的都有，不管怎样，他都是20世纪中国最绕不开的人物之一

观前说明

蒋氏故居分外部和内部，内部并不允许拍摄，且是付费门票制，我认为在这里对内部展开讲不太合适，于是本文就只简单过一遍外围了，外围逛起来其实已经很有感觉了

前往奉化-溪口

Chongxi是从宁波市区出发的，首先乘坐的是地铁2号线，在轻纺城下车换乘奉化公交988路，直接坐到终点站的公交溪口站，随后乘坐奉化公交266路前往蒋氏故居

路上有个小插曲，在经过了两个隧道后，抵达了蒋氏故居游客中心，因为我确实记得不多，然后也没有提前做任何攻略，进去转了一圈发现不对劲，打开地图一看，好家伙，蒋氏故居应该在武陵广场下车，然后就徒步走了过去，大夏天的差点没给我热死在半路上

公交溪口站可以坐 226/Z26 到武陵广场（蒋氏故居）下车

图中拍摄于 蒋氏故居游客中心 正门河边，图中朝向 蒋氏故居 方向

抵达蒋氏故居

在被太阳烘烤了十几分钟后，终于徒步抵达

武山庙

这是蒋氏故居门口右边那栋庙，参观是免费的，原本是溪口镇上任、宋、蒋、单、张五大姓氏共用的祠庙。后来蒋家越来越旺，慢慢就变成以蒋家为主，蒋介石他爸还当过庙首，负责日常管理。蒋介石小时候在这里启蒙读书，后来他儿子蒋经国也是在这里开始念书的，算是蒋家两代人都有渊源的地方

进去之后感觉并没有什么特别的，因为里面被卖文玩的占完了，一楼进去看一圈感觉没什么意思，索性就出来直接进蒋氏故居大门了，免费的地方，往往最先变成卖东西的地方（这句话待会要考

蒋氏故居

图为正门

刚踏进正门，右手边的一个小黑板吸引了我的注意，定睛一看我差点没绷住，赫然四个大字 美岭咖啡 （蒋介石夫人就叫宋美龄

别的就不多说了，懂得都懂，这咖啡卖的可是真贵

文昌阁

和美岭咖啡对面的，也就是正门的左手侧，是文昌阁，原来是清朝建的，溪口文人聚会用的地方。1924年蒋介石回乡扫墓，看它破破烂烂的，出钱修了一遍，修完直接改名"乐亭"，变成他和宋美龄的私人别墅

结果1939年被日军飞机炸平了，现在看到的是1987年照原样重建的

关于内部，由于是付费景点，不太方便展开讲，感兴趣的话有机会可以自己去看看，这里就简单展示下外部的样貌

蒋氏宗祀

顺着正门的路继续深入，则是蒋氏宗祀，是蒋家祭祖/婚丧嫁娶各种大事都在这办的地方。门口牌楼上"忠孝传家"四个字是蒋介石自己题的

祠堂分新旧两进，后面那进是清朝康熙年间的老建筑，前面那进是1930年蒋介石自掏腰包盖的新祠堂，而且盖得比自家故居还大，可见他对宗族这件事相当看重

同样的，付费景点，不方便展开内部，理解～

神秘的麦当劳

再继续深入就很难绷了，一个巨大的M映入眼帘，也就是麦当劳，来都来了，刚好正午天热，便进去补充一下存个档，然后便继续

不得不说，这盖的还不赖

周顺房

继续按逐步深入的顺序，接下来便是周顺房，这个的故事就很有意思了，这是是紧挨着蒋氏故居的一家卖千层饼的小店。1928年蒋介石扩建故居，周边邻居基本都搬走了，就这家不肯动。店主说白了就是"你当总统关我什么事，我就是不搬"，蒋介石还真拿他没辙，只能绕开他建，所以故居有一块墙是凹进去的，就是因为这家店嵌在里面，现在人们都戏称这是中国最牛钉子户

小插曲

蒋氏故居周边的小店铺都很有意思，有卖文玩的、工艺品的、奉化特产千层饼水蜜桃臭豆腐的...我认为最有意思的还得是这两家照相馆

好家伙，里面直接一个师傅在那坐着cos老蒋，旁边人一看还以为自己出幻觉了，几乎每个行人路过这家店的时候无不回头，实在太搞了

然后就是各种千层饼店铺，随手拍了几张

丰镐房

这里就是蒋氏故居的核心了，也就是蒋介石真正住的地方。最早只是祖上传下来的三间破旧楼房，1929年蒋介石当上北伐总司令衣锦还乡，把旧房拆掉大幅扩建，才变成现在这个占地4800平方米的大宅子格局：前厅后堂、两厢四廊，典型的传统大户人家

里面住过不少人：正房是蒋家女眷，东厢房留给宋美龄，但据说她一直没怎么住，等下细说，西厢房是元配毛福梅长住的地方，天井里有两棵桂花树，一金一银，据说是宋美龄亲手种的

1939年日军轰炸溪口，毛福梅刚走出后门躲避，就被倒塌的围墙压死在这里。蒋经国得到消息连夜赶回，写下"以血洗血"四个字立碑为誓

丰镐房小故事

下面是我了解到的小故事，感兴趣可以看一下

宋美龄有房间但没住

丰镐房里专门给宋美龄留了东厢房，但她从来没真正住过。原因其实就是：毛福梅虽然跟蒋介石离婚了，但死活不肯搬走，一直住在西厢房，继续当丰镐房的女主人。宋美龄出身名门，自然不愿意跑去跟前妻住一个屋檐下，蒋介石只好另外给她安排了文昌阁住

蒋介石每天早起偷溜回来吃饭

蒋介石回溪口时，他跟宋美龄住文昌阁，毛福梅住丰镐房，两处就几百米远。宋美龄有晚起的习惯，蒋介石每天一早就悄悄溜回丰镐房，吃毛福梅给他做的艾草团子和家乡菜。等他回来的时候，宋美龄还没起床。手下虽然都看在眼里，但是也不会闲到去打报告

天井里的两棵桂花树

中间天井里种了金桂和银桂各一棵，据说是宋美龄亲手种的，算是她在这栋她不太愿意住的房子里留下的唯一印记

1949年，最后的百日

1949年1月蒋介石宣布下野，灰溜溜回到溪口，在丰镐房一住就是近百天：这是他一生中在这里住得最久的一次。当年除夕全家在报本堂吃年夜饭，4月给蒋经国过了个40岁生日，亲手题了块"寓理帅气"的匾挂上去。然后4月25日父子俩离开溪口，从此再没回来

尾

还有几个地方其实并没有去，因为当时实在太热，就匆忙往回赶了，外围基本上都是些小店铺，开头我就讲了，免费的往往最先变成卖东西的地方

还有一个比较有意思的，在我返回时，又一位cos老蒋的，正在吃东西

~~正在和何应钦瓜分美援的老蒋，可以看到老蒋面对巨额物资时已经笑的合不拢嘴了~~

其实以往有很多老蒋coser，可能今天天热，比以往少很多，~~说明老蒋怕红太阳~~

再往后就是顶着大太阳原路返回了，如果感兴趣的话以后有机会可以自己去看看，也是蛮有意思的，成人票大概一百多块，学生和儿童貌似可以半价，外围不花钱可以免费逛，进入里面参观则需要票

蒋氏故居基本就是这样了

钢铁雄心4 steam正版导入全DLC补丁

Chongxi — Fri, 24 Jul 2026 00:00:00 GMT

本文仅供学习交流分享，请尊重正版

直接步入正题啊。首先你最起码要有钢铁雄心4（下文统称hoi4）本体，dlc资源可以在 p社互助资源站或其他分享站下载，找到正版dlc资源且和你版本相同的压缩包然后下载

Windows 用户安装教程

打开steam里hoi4游戏详情页，点设置，浏览本地文件，随后直接把压缩包内所有资源扔进去即可

MacOS 用户安装教程

由于macos没办法加载Windows的dll补丁，我们需要打开这个github项目：hoi4-dlc-unlock-macos，下载cream_api.ini和libsteam_api.dylib，然后把原本压缩包里的dlc文件夹复制到游戏目录，然后将以上ini和dylib丢进去即可

漫漫长夜全地图及介绍

Chongxi — Thu, 16 Jul 2026 00:00:00 GMT

转载自 Steam 用户 W3stBoy，原帖链接：漫漫长夜全地图及介绍，侵删

地图来源：Whiteberry dissonance 突撅和他的帕夏人民地图汉化：dissonance 图标位置标注：stmSantana 地图简介：dissonance 修改及整理：W3stBoy

地图方位问题

开始之前还是要先说一下地图方位，这个游戏里方位可谓混乱，在游戏里有四种可以判断方位的参考系，但是离谱的是这四个参考系用到同一张地图时得到的结论可能是完全冲突的，这也是制作组建模时没有统筹规划的结果，对于玩家来说极度不友好。大熊岛方位：即以开档选图时出现的那张大熊岛全图做为参照系，按照制图学基本原理上北下南左西右东确定的方位。以这个标准来判断，游戏内的内置木炭图很多都是歪的，所以一般来说只有讨论价值，在实际游戏中则基本不会提及，本版地图所有的指南针都是以此标准放置的。

太阳方位：按照单个地图太阳东升西落为参照系确定方位。不实用，有太阳的时候压根不会迷路，而在雾天和暴风雪这种天气里压根就看不到太阳。最为致命的是无论是大熊岛方位坐标方位都和太阳方位有着某种程度上的冲突。

回音峰方位：以地图上唯二带方位的地名为基准构建的参考系，如果成立的话几乎所有的地图都要旋转180°。所以要么是制作组把所有地图都做反了，要么是制作组打错字了，个人更倾向于后者。左东右西之谜

坐标/小树枝方位：以游戏内单图坐标为参考系确定的方位，通常来说x为左右，y为上下，而从玩家身上扔下来的小树枝则永远垂直于x轴（至v1.94依然生效，其实不止小树枝，其他的物品也有类似的属性，指向各不相同)，也就是通常说的小树枝尖端指北，分叉指南的由来。由于是针对单图，而游戏内木炭图和白莓地图也都是依据坐标制图的，所以这是最适合玩家结合地图确认方位的一个参考系，但问题在于完全按照这个标准制出来的图和制作组给出来的大熊岛全图有非常严重的冲突，尤其体现在神秘湖、怡人山谷、断开的铁路这三张图。所以制作组在做木炭图的时候将怡人山谷和断开的铁路这两张图顺时针转了90°（神秘湖因为不明原因未遭毒手），变成了y为左右，x为上下，以迎合大地图方位，导致了目前这两地图里，小树枝是尖端指右（东），分叉指左（西）。本版地图内皆添加了树枝指向，可能相对于实际游戏体感略有不符，但其实是因为玩家一般选择的参照物本身就不正的缘故。

从玩家身上扔下后永远相互垂直的猎刀于小树枝

大地图与小地图的方位偏差

大熊岛地图总览

游戏内地图总览

拼接版简易地图

简易版地图总览（暂无黑岩地区，具体位置在怡人山谷上方，林狼雪岭左侧）

部分拼接地图过大，需要原图可以给我留言你的邮箱。

注意紫色箭头默认没有绑登山绳，第一次去的时候是走不通的。所以第一次探索水湾推荐从深谷进入，这样你才能探索水湾上层并找到去罐头厂车间的密码纸条。

下面是依据个人游戏经验对这12+4张图进行一定的介绍，默认视角为生存模式非入侵难度，如果要说入侵会另行备注。

神秘湖&图1

神秘湖（Mystery Lake），又称图1，繁中译名神秘之湖，由于是游戏最早发布的地图，萌新永远的家。

地理：位于大熊岛中部，与众多地图相连，算得上是大熊岛的交通枢纽。全图被铁路一分为二，一半主要为林区山地，另一半则主要为湖区河道。神秘湖拥有着数量众多且分布均匀的恒温建筑，非常适合新手。

气候: 拥有整个大熊岛最好的天气，基础气温高，天气没有明显偏向，暴风雪概率适中，很适合生存。

重要资源：非入侵难度下该图会刷新生存者贮藏处（俗称地堡），在九个点中随机一处，所有地堡内均会有一张床和各种不同物资，分为武器、工具、医药、衣物、柴火、食物六种类型，会依据刷新位置不同而变化。

必刷一把猎枪，有湖边小径、湖滨小屋后尸体旁、脱轨车厢内、被摧毁的瞭望台、林地瞭望台、火车桥下六个互斥刷新点（就是所有点位同时只会刷出一把，下同）；另有捕兽者小屋这个独立刷新点（即和其他刷新点没有关联）；另外如果刷新的地堡类型为武器的话，可以在地堡内额外找到两把猎枪。

有三个独立的左轮刷新点，湖景瞭望台的加温山洞、捕兽者小屋桌上以及保险箱内（所有保险箱内的左轮属于独立概率，下同）。另外如果刷新的地堡类型为工具的话，可以在地堡内额外找到一把左轮。（湖景瞭望台加温山洞那把左轮其实严格意义上来说并不是独立刷新，而是模式刷新，但是这个模式涉及到跨图互斥，所以在以单图为章节的时候把它归类为独立刷新比较合理）

无名池塘的猎人塔有概率刷弓，一旁的鹿尸上可能有箭，艾伦洞穴附近的猎人塔也可能刷出箭支。

神秘湖有四个熊洞、均不是加温山洞，随机刷新一头熊（入侵两头）。有两片互斥的驼鹿刷新点（同时最多只会有一片有驼鹿痕迹，但也可能两片都没有痕迹），分别在无名池塘以北的小屋以及火车桥附近。另有一个独立的驼鹿刷点（没有驼鹿痕迹），在捕兽者之家前的空地，可与互斥刷新点刷新的驼鹿同时存在，只不过杀掉之后不会再刷新（无法证伪）。冰面上有四个冰钓小屋，随机一个有门（但不可能是最靠近办公室的那个，有门的冰钓小屋有3°的温度加成）可以钓出两种淡水鱼。沿湖与河道都有大量香蒲可供采集。

由于是森林地图，燃料广泛分布，但煤炭稀少，全图只有到山间小镇的连接洞穴内有少量煤炭刷新点，有一些地点如冰封溪流也能零星捡到，可忽略不计。

通过拆家可以获得一定数量的布料，废金属着实有点少，但是神秘湖离大坝很近，所以不构成问题。

猎刀斧头撬棍之类的工具并不一定会刷在几个主要的房子里，野外冰钓小屋或者一些尸体旁逛逛反而可能有意外收获；非入侵难度下神秘湖基本不会刷新钢锯与重锤，想要这两件工具的话需要去其他图寻找。

标准入侵模式下无法出生在神秘湖，而神秘湖也没有必刷火柴点钢锯点，所以自定义入侵选择神秘湖开局的时候要做好找不到火柴的心理准备。入侵难度下一定会有一根撬棍，在铁路隧道右侧容器旁、无名池塘上方小屋附属建筑门口、伐木场活动房旁、林地瞭望台床底、神秘湖冰面往东第二个冰钓小屋架子上以及艾伦洞穴猎前猎人塔内这六个互斥点中随机刷新。

其他：根据制作组的命名规则，大坝不属于神秘湖。准确来说大坝前的院子属于神秘湖，一旦进入大坝内地图名就切换成了卡特大坝及其周边（蜿蜒河流）。所以在物资这一块并没有和大坝一起讲。

据点推荐：（针对非入侵，高难下可能会有出入，完全主观，没有客观，看看就好，同后面地图）营地办公室评分 5/5 优点：位于地图中心交通方便，双层独栋，白天光效好。内置工作台、双格炉。附近中小型动物资源丰富，湖面大量香蒲，冰钓小屋可以钓鱼。燃料丰富且离回温点不远，沿湖一圈小树枝不计其数。离加温山洞非常近，到湖景瞭望台不过几步路程，清理幽闭非常简单[注4]，一旁甚至附带登山绳，可以使用利用挂绳子消耗精力快速回血。

缺点：容器负载量一般、离大型动物刷新点较远、离煤炭产地较远、到湖景瞭望台的坡度较大容易扭伤。

虽然不是完全没有缺点，但配合神秘湖完美的天气，这就是最适合萌新的据点了。

捕兽者之家评分 4.5/5

优点：内置工作台、双格炉，拥有全地图回血效率最高的床（入侵10小时42%）。门口平地可能刷驼鹿和鹿群，旁边就是熊洞，屋后就有兔子点，陷阱判定区离建筑本体非常近。去山间小镇的山洞门口是可以吃到低温加成的防风生火点[注5]，山洞内还有少量的煤炭刷新。

缺点：位置处于地图边缘，去本图其他位置并不算方便。空间小，容器负载量较低。离加温山洞较远，幽闭不太好处理。目前来说有丢锅bug(至v1.94)，在进出捕兽者之家时身上的锅有可能莫名消失，原理不明。

有人喜欢叫这里猎人小屋，但个人还是推荐用官方译名。全游戏第一个建筑物，地图文件名SafeHouseA，拥有全图唯一的夜晚亮灯特效（室外观察限定），如果附近熊洞刷熊的话是一个可以活得非常惬意的据点。

活动房/大坝/深谷评分 3.5/5

优点：位于神秘湖、怡人山谷、沿海公路的交界位置，可谓枢纽中的枢纽，可以很方便的跨图运用资源。门口有个驼鹿刷点，清理幽闭可以用门口的车（非入侵适用，汽车内避风且有5°的加温，还可叠加睡袋的加成）或是深谷的加温山洞，周围有很多桦树皮点且床回血效率高于普通（入侵10小时36%）。

缺点：空间狭小，容器负载低，没有内置炉，工作台必须要跑到大坝。出门就是狼点，且狼目前有bug，在一定条件下可以穿越大坝的铁丝网。

适合作为中转站/前进基地，入侵血量低的话也可以在这个地方整顿恢复血量，长期居住也不是不可以，但是门口有狼始终是糟心事一件。

(其他地方也不是不可以住，不过个人不太推荐新手去住，所有地图通用)

注释注1：加温山洞。地图上标记为褐色的山洞，在游戏中一般呈现这种形态：这种山洞一般分为两层，但视觉上无明显的界限。外层为防风层，可以无视任何风向（包括往里吹）防风。内层为加温层，拥有风干判定，可以用来晾晒皮和树枝。同时有基础+8°的温度修正，并且随着气候衰变（渐冻世界）同步提升，入侵后期可以达到+28°的温度修正。在加温山洞的任何层活动都可以降低幽闭值，是清理幽闭最廉价快捷的地方。

注2：熊洞是否刷熊可以通过熊洞内是否有骸骨来判断，有骸骨即表明该存档内熊在此位置周期性刷新。

注3：驼鹿&驼鹿痕迹。驼鹿比较罕见，因为不但刷新地点随机，在确定刷新地点后它是否刷新也是随机的，基本相当于摸彩票。而刷新后也很容易就会消失，有时候进房睡一觉就刷没了，所以看到驼鹿最好能马上处理，迟则生变。驼鹿痕迹是驼鹿刷新点的主要标志，一张地图至多只有一处，一旦出现说明该存档内驼鹿会在此位置周期性刷新。但值得注意的是，并不是所有刷新点都有驼鹿痕迹。驼鹿

驼鹿痕迹

注4：幽闭反应。游戏中的一种负面状态，在所有恒温地点（以及登山者棚屋）都会积累幽闭值，到一定程度转化为幽闭风险，幽闭风险积累至100%时触发幽闭反应. 该debuff持续24小时。值得注意的是，如果完全不去室外活动，24小时后该debuff会刷新判定且继续存在。如果在该debuff持续时间内在室外活动的时间不够长，那么24小时后该debuff会转化成相应的幽闭风险值，很容易再次积累爆发。如果要完全清理掉风险，在触发幽闭后最好一直呆在室外，这样在刷新判定时大概率会恢复到正常状态。

注5：低温加成。篝火因为环境温度低而延长燃烧时间的现象，因为一般只能在室外触发所以也叫室外加成，虽然这个说法并不准确。低温加成有两个触发条件。一是篝火与人物处于同一地图；二是人物所处坐标的纯净环境温低于-10度（所谓纯净环境温就是你不跑步不生火不点灯不拿火把和信号棒并且不带冷聚变章时按F所显示那个空气温度）。加成方式为从-10度开始每少1度，篝火的燃料效率提高5%（即每100分钟显示燃料时间可以支撑105分钟游戏时间），到达-30度时达到最大值100%（即每100分钟显示燃料时间可以支撑200分钟游戏时间)。

沿海公路&图2

沿海公路（Coastal Highway），繁中译名滨海公路，通称图2&公路。最宜居的沿海地图，没有之一。

地理：位于大熊岛南部沿海。顾名思义，一段公路将地图分为山区和冰面两部分，公路沿线有大量的恒温庇护所。山区地势北高南低且地形较为复杂，冰面为海水冻结而成，中央有两座小岛，在冰面与海水的交界处分布着大量的薄冰。

气候：依然属于所有地图中最好的那一档，基础气温高，天气没有明显偏向，暴风雪概率适中，很适合生存。

重要资源：必刷两把猎枪，其中一把在返者的哀歌车内、避世者家园尸体旁、野兔岛与避世者家园之间的冰钓小屋内、废弃瞭望台以及铁路瀑布前尸体旁这五个互斥点中随刷新；另一把则刷新在煤渣山矿洞(下层)。

必刷一把左轮，在煤渣山矿洞（下层）的背包；另有匡西特修理站和沿海房屋（野兔岛）这两个独立刷新点。

非入侵难度下，匡西特修理站必刷一把钢锯，煤渣山矿洞（下层）至少会刷一个4L的大油桶。

沿海公路有三个熊洞，均不是加温山洞，固定刷新3头熊。只有一个独立的驼鹿刷新点（没有痕迹），为匡西特修理站附近，杀掉之后不会再刷新（至v.194 无法证伪)。冰面广泛分布狼与鹿，并有九个冰钓小屋，随机两个有门，能钓出两种咸水鱼。香蒲只在深谷入口附近瀑布延伸出来的水系才有分布，咸水区不长这玩意。

海边的薄冰区会概率刷新一些漂泊物，这也当前游戏内唯一可以反复获得一些不可再生资源的方式，俗称赶海捡垃圾。海边能刷出来比较重要的物资有废金属、布料、皮革、青枫苗以及桦树苗。

煤炭资源丰富，拥有煤渣山矿洞这一产煤宝地，其中上层刷满有将近40块，下层刷满为10块左右。

有相当数量的民房，包括窗帘以及沙发在内的家具拆掉之后可以获得大量的布料，匡西特修理站和矿洞内都有铁架子，锯掉后能得到一定数量的废金属。

标准入侵模式下无法出生在沿海公路，而沿海公路也没有必刷火柴点，所以自定义入侵选择沿海公路开局的时候要做好找不到火柴的心理准备。另入侵模式下煤渣山矿洞（上层）会必刷一根强心针。

其他: 冰面地标较少，在暴风雪和起雾时很容易迷失方向，个人建议随身携带小树枝定位，在冰面上只要沿着小树枝尖端所指的方向走就一定能找到公路。

地图上有很多标注为随机坍塌的小屋，经测试后发现非入侵难度下坍塌会在几个模式中随机，并不是每个屋子都有独立的概率，而入侵难度下坍塌的房屋则是固定的。

由于该图没有任何加温山洞（也是唯一一个没有加温山洞的地图），所以清理幽闭主要依靠汽车、冰钓小屋生火钓鱼（入侵）。

有一处不恰当翻译，原文为Log Sort，简中译名 “湖边小镇”有点离谱，繁中译名“圆木整理”也基本属于机翻，个人觉得叫原木仓库/原木存放处比较合理。

图中的两个煤渣山矿洞-废弃矿地其实为同一张地图，但上下层并不互通，进入其中一个后再进入另一个数据统计中的已探索地点不会再增加。其中下层有一台升降机，需要极光夜才能启动，启动后方能探索下层的绝大部分区域。值得注意的是利用电梯才能到达的区域探索完后同样需要电梯返回，这就意味着一旦探索时极光消失电梯失去动力，玩家就会被困在煤渣山矿洞下层，所以建议新手在极光夜探索下层前先备份存档以免被困。上层

下层

据点评价：匡西特修理站评分4/5

优点：位处地图中心，空间较大，内置有工作台和油桶。岸边小镇是全图唯一驼鹿刷新点，后山还有熊洞。门口有车，在低难度可以用来清除幽闭风险，离矿洞较近，收集煤炭还算方便。

缺点：离兔子点有点远。狼窝，开门高概率左右为狼，以避狼为前提来考虑的话这里不是什么好地方。

非常适合新手的据点，除了狼多之外没有缺点。俗称加油站，和山间小镇那个有点撞名，但那一个一般前头一般会带欧卡两个字。

沿海房屋（岸边小镇）评分 4.5/5

简单来说就是匡西特修理站附近的房屋。由于修理站出来两边都有狼点且地形较为复杂，被出门杀也不是不可能，所以找一个靠边角的房子住宿然后利用加油站的设施生存是一种比较保险的办法。个人比较推荐这栋红色的，由于靠边所以能够以比较好的视野清狼，离后山熊洞也近，由于出门安全不少+0.5。

钓鱼营地评分 3.5/5

优点：由3-4栋小屋组成，总空间尚可，有室外工作台。门口的马路是熊的巡逻路线，离冰钓小屋近，冰面常见鹿群。

缺点：单个房子很小，容器也不多，无室内火炉。

小巧的据点，自带一头熊，室外工作台虽然不适合做衣服这种大件，但是补充箭和陷阱也基本够用。

沿海房屋（野兔岛）评分3/5

优点：一室二厅带卫生间的平层，空间尚可，容器较多。地处小岛的最高点，视野开阔，门口就是小树枝刷新点和兔子活动区，配合大量陷阱可以很轻松的满足温饱，更可以充分利用气温较低的垃圾时间获得收益并同时清理幽闭。岛周围三个冰钓小屋，钓鱼很方便，离海岸非常近，适合捡垃圾。

缺点：位置处于地图边缘，去其他位置并不算方便。无室内火炉、工作台，最近的工作台在钓鱼营地，而且是露天的。离大型动物刷新点和矿洞都比较远。

评价比较二元化的据点，对于萌新来说这就是座随处可见的破房子，基本没有价值。但这个据点的价值是随着难度提高而提升的，廉价的幽闭控制手段和方便的捡垃圾环境对于入侵养老来说至关重要。

沿海房屋（避世者的家园）评分 2.5/5

基本同野兔岛，工作台需要到匡西特修理站，离熊点近+0.5，开门能碰狼-1。

注释注8：薄冰是游戏内的一种特殊地形，常见于沿海地图和孤寂沼地。玩家走在薄冰上后会出现红色提示并进入倒计时，倒计时结束后薄冰碎裂，玩家会被判定为落水，随后强制复位到薄冰外区域并赋予温度条清空、扣除10%状态值与衣服潮湿100%等效果。沿海落水会造成全身衣服潮湿，而沼泽落水只会造成内外裤+鞋袜潮湿。另外沼泽落水后会让冰面出现开裂，再次走到开裂点时会无视倒计时直接判定为落水。经不严谨测试，薄冰倒计时通常能维持5秒左右，穿了钉鞋后能延长到6秒左右，但是依然存在一些可以无视倒计时直接判定落水的区域（比如野兔岛下方某地）所以需要多加小心。另外薄冰的判定其实不仅仅局限冰面，在离地有一定高度的地方依然会保持判定，所以想要蹭山越过薄冰的同学最好能尽量把自己拉高。

怡人山谷&图3

怡人山谷（Pleasant Valley），繁中译名欢乐谷，通称图3&杀人山谷。全游戏最大的一张地图。

地理：被官方顺时针转过90°的地图之一。四周为地形较为复杂山地，中间为水系包围的平原，一条公路贯穿全图，横穿的整个平原地区。怡人不怡人不太清楚，总之确实很山谷。

气候：官方钦定“拥有整个大熊岛地区最恶劣的天气”，实际表现为全图概率最高的暴风雪，平均基础温度比神秘湖低个4°左右，风寒也比其他地方高那么一些，总之杀人山谷的外号不是白叫的。

必刷一把猎枪，在长弯车内、三振农庄、焚脊洞穴、迷雾瀑布野餐区、农庄西北破棚子内五个互斥点中随机刷新，另有怡人山谷农庄、迷雾瀑布野餐区洞穴两个独立刷新点，如刷新的地堡类型为武器的话，可以在地堡内额外找到两把猎枪。

必刷两把左轮，一把在信号山坡无线电控制站，另一把在无名池塘、冰船山脊地下室、废弃的生存者贮藏处、迷雾瀑布野餐区洞穴这四个互斥刷点内刷新，另有谷仓（小）这个独立刷新点，如刷新的地堡类型为武工具的话，可以在地堡内额外找到一把左轮。

必刷一把弓，在迷雾瀑布野餐区的恒温洞穴内，两座猎人塔以及谷仓（大）附近的箭靶均有可能刷新箭支。

客机残骸散落有大量行李箱，可以开出很多衣物。非入侵难度下废弃的生存者贮藏处内必刷一把钢锯，想去林狼雪岭锯集装箱的同学路过时可以拿一下。

怡人山谷拥有全图地图最多的七个熊洞，其中六个是加温山洞，只有桦树林中那个例外。随机刷新三头熊（入侵四头）。有两片互斥的驼鹿刷新点，分别在沉思池塘以及谷仓（大）东北的桦树林周边。全图唯一的冰钓小屋在沉思池塘，可以钓出两种淡水鱼。沿河道有大量香蒲可供采集，不过比较分散。

除煤渣山矿洞这个主要产煤区外，迷雾瀑布野餐区洞窟也会刷新少量的煤。小树枝虽然分布不少，但是大多在山区，主要建筑附近较为稀少。

有相当数量的民房，包括窗帘以及沙发在内的家具拆掉之后可以获得大量的布料。信号山坡、废弃地堡、两个地下室、谷仓都有不少铁架，废金属储量会比想象中的多。

在入侵者模式中农庄地下室和乡村商店都会有一盒必刷火柴，谷仓会有一根必刷强心针，农庄地下室必刷一个高级工具箱。

其他：地图上有两个谷仓，所以特意添加了后缀的“大”和“小”以示区别。大小谷仓虽然都是恒温，在不带冷聚变徽章的情况下基础温为-8度，在游戏初期探索时需要注意一下温度条。

有两头熊可能游荡到农庄附近，被称之为农庄熊，但实际上都是从其他地方来的。一头可能来自于长弯附近的熊洞，另一头则可能来自信号山坡下的熊洞。而信号山坡上无线电控制站周围游荡的熊则来自多级瀑布附近的熊洞。

暴风雪概率非常高，入侵难度下体感而论基本隔天一次，如果没有暴风雪寻路技能的话在这张图探索还是很辛苦的，新手选择这张图开局时候建议尽量缩短切图时间以免被困。

索姆斯路口的大部分房屋都是固定的，但有一栋是随机的，依据随机的位置不同，户型也会不同。在这张图上使用小树枝定位时会有指向地图右上角的错觉，主要原因是地图本身就是歪的导致玩家产生的错觉。

在靠近林狼雪岭的入口处有学名为“废弃的生存者贮藏处”这一固定建筑，通称废弃地堡，和通常意义上萌新非常想要找的学名“生存者贮藏处”的地堡其实不是一个东西。经常有人会说怡人山谷会刷两个地堡，但实际上那种随机的物资地堡依然只有一个，这也算是和“入侵也刷枪（不过只刷信号枪）”相并肩的误解性传言了。

索姆斯路口的大部分房屋都是固定的，但有一栋是随机的，依据随机的位置不同，户型也会不同。

在这张图上使用小树枝定位时会有指向地图右上角的错觉，主要原因是地图本身就是歪的导致玩家产生的错觉。

据点推荐：怡人山谷农庄评分4/5

优点：三层大别墅，空间巨大，容器较多。内置工作台、六格炉，还有一条虽然判定是恒温室内但是继承室外光效的走廊（指晚上非暴风雪和雾天可以在走廊做一些需要光才能做的事）。门口为熊的巡逻区域，附近有鹿和兔子，还有辆车可简单清理幽闭。离冰钓小屋虽然不算近，但是相对而言是这张图上是最近的了。

缺点：采光不太好，100%亮度下就算是白天屋内也很黑。燃料刷新点有点远，收集燃料略有不便。怡人山谷天气不好。

某些程度上几乎完美的据点，可惜长在了怡人山谷。

社区会堂评分 3.5/5

优点：空间较大，自带全图最多的容器负载，某柜子甚至继承了剧情中200kg容量的设定。内置6格炉。附近有熊点，兔子和鹿也不远。燃料充裕，周边小树枝不缺，离煤渣山矿洞也很近。

缺点：无工作台，最近的工作台要去煤渣山矿洞或者谷仓，怡人山谷天气不好。

如果上级瀑布熊洞刷熊的话就是非常优秀的据点，由于离煤渣山矿洞非常近，非常适合作为沿海公路的拓展基地。后期在沿海公路养老的时候可以在捡煤的时候顺便做掉这边的熊，这样四舍五入也能算单图就控制了4头熊的资源。

废弃的生存者贮藏处评分 2.5/5

优点：位于林狼雪岭入口，容器较多。内置工作台、外头破屋内有两格炉。离迷雾瀑布野餐区洞穴很近，可以捡点煤。

缺点：空间狭小，光线不好。由于室外炉子内的火起不到防狼的效果且离狼的巡逻路线很近，所以门口烧烤时要格外小心。虽然有个熊洞不算太远，但也不近。怡人山谷天气不好

不太适合常驻的据点，但如果想要把林狼雪岭和灰烬峡谷的资源搬运出来的话，这里是必不可缺的中转站。

注释注9：冷聚变徽章的加成从本质上来说既不是环境温也不是体感温，而是一个热源。你可以理解为自己脑袋上永远顶着一个+2°的篝火，只不过这个篝火除了加温之外其他什么也不能做。

荒芜据点&图4

荒芜据点（Desolation Point），繁中译名苍凉角，通称据点&图4。大图中最小的一张地图。

地理：位于大熊岛最西南角的沿海，与沿海公路类似的陆地-冰面结构，目前只与公路废墟相连。

气候：不好也不坏，基础气温略低于神秘湖，暴风雪和刮风的概率也略大了那么一点，总体来说可以接受。

重要资源：必刷一把猎枪，位于断桥附近的恒温山洞内。

必刷一把左轮，在孤寂灯塔、石制教堂、五号废弃矿地、活动房这四个互斥点中随机刷新。另外希伯利亚加工厂的保险箱内也有独立概率。

西伯利亚加工厂内必刷一把枪（保险箱另算），种类不定，左轮猎枪二选一。有个猎枪点是必须拆箱子才能看到的。

必刷一把弓，位于凯蒂的室外桃园，旁边附带箭支。

非入侵难度下加工厂内必刷重锤、钢锯。

只有一个熊洞，是加温山洞，必刷一头熊。有一个驼鹿点，位于卡特的马车上方桥附近，该点没有驼鹿痕迹，疑似无法重复刷新，但无法证实。

五号废弃矿洞内有大量煤炭刷新点，海边薄冰附近有飘泊物。

维修厂连带旁边的活动房以及矿洞灯塔内可拆出大量的废金属和少许的布料。

入侵难度下希伯利亚加工厂必刷一盒火柴和一根撬棍，孤寂灯塔必刷一根强心针。

其他：瀑布附近的恒温山洞俗称的狼洞，内有概率刷狼，室内狼虽然无视诱饵但依然会被火把信号棒定身，进入时需做好应对。

希伯利亚加工厂内虽然是恒温，但是只有-5°，初期搜索时应注意温度条。其内部较为凌乱，某些物资可能藏得比较恶趣味，要彻底搜刮需要一些耐心。另外这个房子有个很奇怪的bug，就是这张地图成为你打开游戏第一个载入的室内建筑时，它的恒定温度会变成-1°，并能波及到所有存档，在进入别的建筑一次后该bug消失。

里肯号内置锻炉，是全图仅有三个的锻造点之一，由于是室内，长时间锻造时需要注意幽闭风险。

该图虽然是沿海地图，但也是沿海大图中唯一没有冰钓小屋的，可能是怕灯塔员工上班摸鱼吧。

据点推荐：希伯利亚加工厂评分 3.5/5

优点：空间大，内置工作台、油桶（双格炉）。离熊洞和驼鹿点都算比较近，煤矿也就在马路对面。门口有车，可以简单清理幽闭。

缺点：容器较少，光线较为阴暗，出门概率碰狼，离兔子点较远。

还算中规中矩，想要住一段时间也不是不可以，但由于图太小，总体资源不行，所以也不是长久之计。

孤寂灯塔评分 1/5

优点：风景好，气氛足，适合角色扮演。内置壁炉（双格炉）顶楼自带观景台。

缺点：除了上面之外的所有

还真有人喜欢住这，不过从游戏的角度出发，个人是不太推荐。

注释注10：在锻炉可以利用重锤和废金属打造简易刀/斧和箭头，需要炉温150°以上。通常燃料最多只能将炉温提升到80°，要顶到150°需要加入煤炭，一块煤炭可以提升20°的炉温。

林狼雪岭&图5

林狼雪岭（Timberwolf Mountain），繁中译名灰狼山，通称图5&雪岭，是游戏中资源最丰富的地图之一。

地理：位于大熊岛西北部山区，地势大致以中心雪岭巅峰为最高点往四周逐次降低，地形较为复杂，有大量需要登山绳才能跨越的悬崖。

气候：较为恶劣，但比怡人山谷还是好点。该图气温随海拔升高而逐渐降低（非线性）[注11]，通向峰顶的登山绳上下有2°的温度差，而峰顶比水晶湖地区要低4°。如果只论温度最高的水晶湖地区，那么温度要比想象中的好，基础温相对于神秘湖而言只低了3°左右，优于怡人山谷。而暴风雪概率而论，体感上也比怡人山谷好不少。

重要资源：该图上分布有坠机所散落出的集装箱，每个集装箱有两个货柜，每打开一个货柜需要消耗5%的钢锯耐久。集装箱内所包含物资类型固定但是数量和耐久随机，非入侵难度下共会刷新17个集装箱累计34个可打开货柜。而入侵难度下一共只会刷新7个集装箱累计14个可打开货柜。

必刷两把猎枪，其中机尾集装箱必刷一把（这把猎枪和非入侵货柜相关，即你自定义时选择入侵模板打开步枪刷新，依然不会出现这把猎枪；反之如果你选择非入侵模板然后关掉猎枪刷新，会出现那个货柜，但是货柜里不会刷出猎枪），另外一把在地图南部5点、6点、7点、8点四个尸体点位旁互斥刷新。只有峰顶加温山洞这一个独立左轮刷新点。必刷一把信号枪，位于机尾，非入侵伴生有4-8颗子弹，入侵自带8颗。非入侵难度下登山者棚屋和机尾都有必刷钢锯。

林狼雪岭有三个熊洞，只有回音峰那个是加温山洞，必刷三头熊。有两个互斥的驼鹿刷新点，分别在起落架和机翼。只有一个冰钓小屋，位于水晶湖，必定不会有门，可以钓出两种淡水鱼，沿湖一圈有大量香蒲。

燃料广泛分布，洞穴A-B、洞穴C-D以及通往灰烬峡谷的恒温山洞均有少量的煤炭刷新点，但由于单个产量小，位置较偏僻且分散，所以实用性较差。

入侵难度下，登山者棚屋、大山洞各必刷一盒火柴，机尾必刷两盒火柴和一根强心针，但要注意如果机尾火柴没有刷在外头这个点的话，那么肯定实在板条箱里头。

其他：这个图没有任何上锁的柜子，而且后续的灰烬峡谷也没有，所以来探索的时候不需要带撬棍。钢锯破损阈值为25%，即当钢锯耐久处于25%以下时使用就有概率破损。如果在锯货柜的同时钢锯破损，那该货柜就再也无法打开了。所以在锯货柜时需要注意一下钢锯的耐久，不足时可以选择用工具箱+废金属修理或是换一把锯子。下图为非入侵难度下机尾内有钢锯的货柜，先锯这个肯定不会亏。

机尾的某些板条箱内是有物资的，非入侵会有一箱极品桃子、一箱登山绳+废金属、一箱火柴助燃剂。而入侵难度下只剩下一箱登山绳+废金属，火柴助燃剂只有没刷在箱子外头时才会在箱内。

雪岭正常来说只能从右侧登顶，路线如图所示。红色路线没有跳崖和蹭山的部分，虽然绕了点路，但胜在路线简单，并可以顺路收割两处集装箱；蓝色路线从时间上来说是最优的，但需要一些蹭山技巧，也比较容易扭伤。到达僻静山脊后只有紫色一条路线，穿越洞穴后经过登山绳登顶。所有路线均要经过三根登山绳，当然也不是没有可以省绳子的邪道路线，但是其实并不算实用，这里就不展开讲了。登山路径推荐：

据点推荐：登山者棚屋评分4/5

优点：敞亮，晚上甚至可以抬头看星星，内置工作台和壁炉（两格炉）。开门可见水晶湖，湖面上经常能看见狼、鹿、熊一起遛弯其乐融融，一旁的兔子瑟瑟发抖。左右不远就是该图仅有的两个驼鹿点。钓鱼方便，周边小树枝数量非常多，燃料并不缺少。房间内的光线和掉耐久速率为室外判定[注12]。

缺点：不恒温，不恒温，不恒温，重要的事要说三遍。全图唯一非恒温但是会积累幽闭的地点。棚屋自带10°的基础加温，并且会随着衰变逐渐升温，入侵后期最高可以达到30°的加温，配合+5°的床在睡觉时可以达到合计35°的温度加成。即便如此，如果衣服不够好，依然有碰到凌晨暴风雪导致睡觉掉温的风险。所以不恒温就是棚屋最大的缺点，其余空间小、容器少不好捡煤进出不保存只能算是添头。在非入侵难度下这个缺点其实并没有那么致命，但在入侵难度下想住这里，就不得不先考量一下自己的衣服了。

注释注11：该游戏当前所谓海拔降温并不是严格z轴坐标线性降温，而是制作组随手划定的区域，极端一些的可能会出现走一步-5°，退回来+5°的情况。

注12：游戏中的所有食物，在室外和室内掉耐久速率是不一样的。通常来说，放在室外的食物的变质速度会远低于放在室内。只有三种汽水、沙丁鱼罐头、猪肉扁豆、极品桃子和“动起来”能量饮料例外。

孤寂沼地&图6

孤寂沼地（Forlorn Muskeg ），繁中译名伶仃苔沼，通称图6&沼泽。沼泽地里通铁路的加拿大工程奇迹。

地理：标准盆地地形，四面环山中间沼泽，沼泽中有零星陆地和大量的薄冰，一条横贯铁路连接神秘湖与断开的铁路。

气候：基础气温方面相当于神秘湖，但是雾天概率远超所有图，作为一个盆地，这很合理。

重要资源：必刷一把猎枪，在五个互斥点中随机刷新，地点超出个人的文字描述能力范围，只能见图（红圈）。

有三个独立左轮刷新点，分别为老斯彭斯之家二楼床边、保险箱内以及瀑布旁恒温洞穴内的背包中。

必刷一把弓，在四个互斥点中随机刷新，地点超出个人的文字描述能力只能见图（蓝圈）。沼泽的猎枪&弓箭地点：

非入侵模式下必刷一把重锤，在老斯彭斯之家+工人宿舍的三个互斥点中随机。

拥有两个熊洞，均不是加温山洞，必刷两头熊。有三片互斥的驼鹿刷新区，分别在地图的3点、5点、10点钟位置。植物资源丰富，香蒲数量冠绝全图。

虽然是沼泽地图，但是燃料并不缺乏。偷猎营地、老斯彭斯家附近会有一定数量的不可重复刷新的煤炭，瀑布洞穴和去水湾的洞穴内都有少量的煤炭刷新点。

入侵难度下老斯彭斯之家必刷一盒火柴，沼泽山脊必刷一根强心针。

其他：该图有一个可探索地点“废弃营地”，会在四个位置中随机刷新，特征为雪屋+篝火以及一些物资，这个点是会被计入数据统计中的。中心沼泽部分分布有大量薄冰，一般来说在陆地附近的冰面都不会有问题，所以在沼泽中穿行时可以尽量靠着陆地走。如果要一定要过薄冰，请尽量降低负重提高冲刺速度并做好落水的准备。

拥有全大熊岛唯一的室外锻炉，可以吃到低温加成的同时也避免了幽闭的积累，除了睡觉不能熄火以外其余完美，是入侵难度下比较理想的锻造点。

老斯彭斯之家床边的板条箱内有助燃剂，棚子内侧隐藏的保险箱可以直接从后方的一个缺口中打开。另外棚内的狗粮其实并不是刷在箱子里头，而是在箱后。

推荐锻造路线如图所示，红色是路程最短且遇狼概率最低的路线，除了偷猎营地和老斯彭斯之外几乎不会碰到狼，但是需要穿越沼泽中心，在视野不好的时候容易迷路。蓝色路线较为稳妥，全程贴边不存在迷路问题，途径一个恒温山洞一个加温山洞也不怕掉温，缺点就是路程远，路过的狼点多。黄色路线是最远的路线，不推荐从神秘湖出发走这条路，迷路的时候可以用，大多用于从沼泽山脊出发锻造。

据点推荐：洞穴（瀑布附近）评分 2/5

优点：位置好，位于断开的铁路&米尔顿盆地&沼泽的交界点，恒温。沼泽山脊是没有狼的，兔子很多还有少量桦树皮，就算门口不刷驼鹿，去旁边的米尔顿盆地搞几只鹿来烤也没什么大问题。

缺点：别说工作台和容器，甚至连床都没有，洞里更是黑乎乎的。

一般来说是不推荐住没有床的地方，但是顶不住沼泽其他地方太拉跨，这是一个非常好的中继点，无论你是来自米尔顿盆地还是从断开的铁路都可以到这里休整。

洞穴（通往荒凉水湾）评分 2/5

优点：位置好，位于沼泽和荒凉水湾的交界点，恒温且有床。这个洞是全图唯一的室内兔子点，洞内可能会刷新一只兔子，可惜的是陷阱在洞里无效。离狼鹿点也不远，洞两头各有一个驼鹿点，食物不缺，适合作为前进基地。

缺点：没有工作台和容器，洞里白天也是黑乎乎的，出门还见狼。

一般来说是不推荐住这种地方，但无论是将水湾的资源搬出也好还是去水湾罐头厂造子弹和维护工具也好，这里都是别无他选的中继点。

断开的铁路&图7

断开的铁路（Broken Railroad），繁中译名铁路断线，通称图7&断铁。这图之前翻做神秘湖铁路，简直不知所云，后面改成了断开的铁路，依然不如繁中。

地理：被制作组转了90°的地图之二，地形很简单，铁路横穿山区再加上几个水系小盆地，就是不知道为什么会有人在这个破地方建了一个修理厂。

气候：基本相当于复制粘贴了神秘湖，最好的那一档。

重要资源：有一个独立的猎枪刷新点，位于断桥下峡谷中。有两个独立的左轮刷新点，分别在维修厂花盆内和猎人小屋外汽车上。

猎人小屋和加工厂类似，必刷一把枪，类型不定，猎枪左轮二选一。

必刷一把弓，拥有猎人小屋前池塘以及火车头附近尸体这两个互斥刷新点。

维修厂必刷一个4L的油桶和一根登山绳，正好可以绑在一旁通向峡谷的登山点。而猎人小屋同样必刷一根登山绳，正好可以绑在屋后的登山点。

仅有一个熊洞，是加温山洞，必刷一头熊。有两片互斥的驼鹿点，分别位于维修厂到木桥的路上和猎人小屋门口。除了猎人小屋门口的池塘以外，其他水系附近多少附带一些香蒲可供采集。

燃料不算缺，但是不产煤，维修厂内虽然会有零星的一次性煤，但显然与锻造图的身份不相匹配。

维修厂和猎人小屋内均有一定数量的铁架子，可以拆出大量废金属和一些的布料。

标准入侵模式下无法出生在断开的铁路。入侵难度下维修厂&猎人小屋各必刷一盒火柴，断桥下峡谷&猎人小屋各必刷一根针。

其他：山崩可以直接蹭过不用绕路。

维修厂为全图仅有三个的锻造点之一，但整张地图都不一定会刷重锤，如果要来该图锻造记得自带（煤也是）。严重怀疑是由于剧情需要在1.44给维修厂添加锻炉之后制作组没有去调整配套的刷新。极光夜时散落的电线会对玩家造成伤害和烧伤debuff，需要注意。另外维修厂内某些箱子打碎可能会有一些物资，比较重要的就是图二架子上那个，概率出强心针，其他一些零碎不太重要。

断桥下的峡谷一定要绑绳子后再下，正常游戏没有绳子是上不来的，算是经典死法之一了。

据点推荐：维修厂评分3.5/5 优点：空间大，容器较多，内置锻炉工作台和油桶（双格炉），地上还能起篝火。自带一个室外套间，虽然没有加温但也不会积累幽闭，防风防狼，地上同样也能随便起火，离熊洞和驼鹿点也算近。

缺点：著名狼窝，出门一堆狼。离兔子点较远，也没有煤炭可捡，晚上还要防着极光夜电线。

唯一内置锻炉的据点（应该不会有人住里肯号吧），但连煤都不产，图小资源少能干的事就少，门口还一群狼。

猎人小屋评分 4/5

优点：空间大，上下三层，内置六格炉和工作台。出门池塘驼鹿点，背后登山绳下就是熊洞，门口还是兔子窝。

缺点：偏僻，这地图本身已经很角落了，这屋子在角落的角落上，可以说是与世隔绝了，虽然有邪道可以直通出口，但是实际上还是很偏，去哪都不方便。燃料不算好弄，要么得去池塘对面要么得下登山绳。另外这屋子太空旷，老是给人一种阴森的感觉，特别是晚上。

山间小镇&图8

山间小镇（Mountain Town)，繁中译名高山镇，通称图8&米尔顿。剧情的起点，很多萌新第一次接触到的地图。

地理：以小镇为中心展开，东北部为山地，西南为盆地，地形割裂，进出都需要登山绳。许多萌新初次接触的地图。

气候：作为剧情初始图，获得了和神秘湖同样的待遇，基础气温高，天气均衡，暴风雪概率适中。

重要物资：必刷两把猎枪，其中一把在教堂、米尔顿房屋（灰色母亲家）、米尔顿房屋（小山丘独栋）、天堂草地农场四个互斥点中随机刷新；另一把在七个互斥点中随机刷新，描述超出个人能力范围，详情见图。

有两个独立左轮刷新点，分别在米尔顿房屋（灰色母亲家）和坠毁的飞机（山洞背包内）。

只有一个熊洞，不是加温山洞，位于云杉瀑布桥附近，必刷一头熊。拥有两个互斥驼鹿点，分别位活动房到云杉瀑布桥之间的小池塘和米尔顿盆地。全图水系附近均有香蒲发育，累计起来数量非常可观。

燃料方面房子很多家具不缺，短期内不存在问题，但小树枝离定居点普遍较远，长期来看有些许不便。煤炭刷新较为零星分散，只有连接神秘湖和寂静河谷的两个山洞和云衫瀑布桥通往坠毁飞机的恒温洞穴内会刷新。

有大量民房，包括窗帘以及沙发在内的家具拆掉之后可以获得大量的布料和一些废金属。

标准入侵模式下无法出生在山间小镇。入侵难度下米尔顿房屋（灰色母亲家）、野餐区下方加温山洞背包内各必刷一盒火柴；坠毁的飞机必刷一根强心针还有一个4L大油桶。

其他：有两个建筑有进入限制，欧卡加油站进门需要撬棍，天堂草地农场在剧情模式会随着主线剧情自动解锁，但在生存模式下则需要钥匙。钥匙在棚内皮卡驾驶室、拖拉机驾驶室、破屋内尸体上、屋后尸体上四个点中随机刷新。

小镇内的房屋倒塌是随机的，但并不是所有房屋都有独立概率，和沿海公路一样都是保证总量不变的情况下在几个模式内随机。

同样叫“造林地”的点在地图上有三个，各自都会计入统计数据，不要漏探了。

坠毁的飞机有个板条箱打开是可能刷裤子的，入侵甚至有概率刷作战裤。

小镇有着全地图最长和最严实的空气墙，从坠毁的飞机一直到神秘湖入口这一圈都异常严谨，目前除利用bug之外未找到从山间小镇通往神秘湖的不爬绳路线。

地图上有一片未开放地区，即撞坏的监狱运输巴士那个隧道的对面、坠毁的飞机和通往神秘湖的洞穴之间的区域。推测为通向怡人山谷长弯的道路，剧情第三章开场动画中莫里也是在这个区域捡到的女主阿斯特丽德的。坠毁的飞机下方山洞附近的悬崖带有秒杀线，想要从这个地方偷渡是不可能的。坠毁的飞机附近有一条路线可以绕过秒杀线下到此地，可以发现除了地形之外几乎一片空白，也没有任何可探索物资。

据点推荐：米尔顿房屋（灰色母亲之家）评分 3.5/5

优点：全镇最好的房子，双层大空间，容器较多，内置6格炉，兔子点就在街对面，周围房子多，光拆家就很多柴，门口有车可以简单清理幽闭。

缺点：无内置工作台，最近的工作台要去天堂草地农场或是活动房。小镇狼窝出门见狼，屋后的登山绳取消后也变相增加了去驼鹿点和熊点的距离。周围家具劈完后燃料收集会比较花时间。

去掉情怀因素和核能壁炉之后这个据点其实并不是那么好用，但是即便如此这也是镇上最好的房子，如果要把物资搬去神秘湖，灰妈家是不可避的一环。

天堂草地农场评分 3.5/5

优点:空间尚可，内置6格炉，室外有工作台，一旁还有油桶（2格炉），出门就是兔子点，门口有车可以简单清理幽闭。

缺点：门口狼窝，工作台很危险，离大型动物刷新点很远。虽然盆地的驼鹿点在地图上看起来很近，但是由于隔着两段绳子，实际住在农场是无法利用盆地的资源的。

看起来很美其实不咋地的据点，因为室内结构比较紧凑且算是暖色调所以有些人觉得住着很温馨。

活动房评分 4/5

优点：内置工作台，门口有油桶，床回血略高于正常值（入侵10小时36%）。离小池塘驼鹿点和熊洞很近，兔子点也不算远。四周树枝不缺，两个煤炭山洞均在日常巡游范围内，可以获得一定的煤炭补给。离加温山洞很近，可以无压力清理幽闭。

缺点：空间狭小，容器基本没有，虽然开门没狼但是离狼点也不算远，门口烧烤极易引狼。

位于河谷出口不远，可以是探索河谷的前进基地也可以是河谷物资外运的中转站，真要长住其实也不是不可以。

寂静河谷&图9

寂静河谷（Hushed River Valley），繁中译名寂静河谷，目前唯二简繁同名的地图，通称图9&河谷。地形最为复杂的地图，应该没有之一。

地理：位于大熊岛最西北角，整个地图被一条河谷分割，整体地势东高西低，但是河谷自身西高东低，所以地形异常凌乱和难以跨越，主要靠两组共六个寒冰洞窟的入口串联。

气候：处于神秘湖和怡人山谷的中间值，不好也不坏，全图温度均一，没有像雪岭那样搞分层。

重要资源：必刷一把猎枪，在幼熊瀑布、寂静河流中段树干旁、阶梯湖附近加温山洞、寒冰洞窟（北）入口E附近和寒冰洞窟（北）入口D附近这五个互斥点中随机刷新。

必刷一把左轮，在湖畔洞穴、神秘烽火、寒冰洞窟（南）的篝火旁和观瀑之地以南的高台上这四个互斥点中随机刷新。另有两个独立左轮刷新点，寒冰洞窟（北）和峡谷观察点，其中峡谷观察点由于地形贴图错误导致当前版本无法拿到（v1.94)。

必刷一把生存的弓，在观鹿台、地图正12点加温山洞门口，峡谷观察点往南的树干旁这三个互斥点中随机刷新。另有一个独立刷新点，寒冰洞窟（北），旁边一般附带2只或更多的箭。

必刷一把信号枪（入侵不刷），在顶峰洞穴、Lonely Cave、Valley Cave三个加温山洞中互斥刷新，一旁的尸体上会附带一定数量的子弹。

河谷有两个熊洞，均不是加温山洞，必刷两头熊。有两片互斥的驼鹿点，分别在观鹿台下方和巨岩湖。另沉思之地有概率刷现成的驼鹿尸体，该点会在鹿尸、狼尸、驼鹿尸、不刷四种情况中随机。

燃料丰富，小树枝分布广泛。两组寒冰洞窟内都有一定数量的煤炭刷新点，顶峰洞穴、寂静河流中段的加温山洞也会刷新一次性的煤炭。大部分水系附近有香蒲可供采集，总量相当可观。

拥有标志性资源点“神秘烽火”，在两个地点中随机刷新一处，个人习惯依据方位称之为南& 北烽火。烽火附带刷新一个雪屋、一块驼鹿肉、一个背包（内有麦基诺夹克）、一个磨刀石、附近还有一具尸体（内有针线包）。在非入侵模式下，烽火会附带一个现成的驼鹿背包，麦基诺背包内还会多出强心针与放大镜。而在入侵模式下，烽火会仅会多附带一把重锤。

有四个随机的营地点，会随机刷新两处（入侵一处），固定有一个雪屋，一个篝火，一口锅和一些其他的物资，入侵难度下会附带一把钢锯。

拥有独立机制的资源点“隐藏贮藏处”，外形如图，会刷新在河谷各个角落，不同地点的盒子会出不同的物资，从吃的到衣服到弹药一应俱全。但是由于其隐蔽性，无论是全刷新点位也好还是刷新规律也好均不可考，所以没兴趣研究的同学就凑合一下对着地图上点随便找找完事，有兴趣的同学可以试着找出规律。

在入侵难度下河谷有三盒必刷火柴，分别在寂静河流中段加温山洞内，地图12点钟位加温山洞和南寒冰洞窟篝火旁。

其他：神秘烽火并不是永续存在的。在第一次进入该图的一段时间内（大概3-5天）会持续冒烟，过了一段时间再次载入后烽火台会坍塌，并且停止冒烟。所以进入该图后应优先考虑判断烽火位置。另外烽火台虽然看起来在燃烧，但是并不会提供任何温度加成。河谷并不存在上锁的柜子，所以探索时可以不用携带撬棍。但相对的有大量枯死树丛拦路，必须要小斧头&简易小斧才能打开，探索时建议带上，某些地区必须要有斧头开路才能到达。

该地图大部分区域都在两组寒冰洞窟的串联之下，也是全图目前唯二拥有三出口的室内洞穴。入口A、B、C组成南寒冰洞窟，而入口D、E、F组成北寒冰洞窟。如果需要前往通向南北高台的那两个出口的话（C&D），就都必需要在洞内攀爬一小段登山绳，这个消耗相对于外头的长登山绳来说基本上可以忽略不记。南寒冰洞窟内会概率刷新一个篝火，在三个点内随机。该篝火附赠一盒火柴和一个睡袋，还有其他物资若干，如果是入侵难度，还会附带一把钢锯。另外南寒冰洞窟内有概率刷新一只狼，进入时需要做好应对，杀掉之后不会再刷新（无法证伪）。

有两个未翻译的地名，Lonely Cave和Valley Cave，按照制作组的尿性这两个洞大概会被译作孤独洞穴和峡谷洞穴。

据点推荐：全图连一片瓦都没有，不建议当据点。一般来说探索该图是依托于寒冰洞窟的，探索完之后就麻溜的返回山间小镇了。

荒凉水湾&图10

荒凉水湾（Bleak Inlet），繁中译名凄凉入口，通称图10&水湾。目前来看难度最大的地图(之一，毕竟后面还有破碎山道这种大中午掉温的地图），无处不透露着制作组的恶意。

地理：位于大熊岛西南沿海。总体来看分为上下两层，上层是从深谷过来的山地延伸，下层为三角洲区域，在正常游戏里上下两层仅能通过登山绳互通。

气候：基础温低得可以和怡人山谷一较高下，风寒数值为无图能敌，大风出现频率全图最高，夜晚极光频率也是全图之最。也就暴风雪频率比怡人山谷稍低，其他恶劣程度有过之而无不及。

重要资源：有三个独立猎枪刷新点，分别在山间隐秘小道尽头、罐头厂员工宿舍及员工宿舍旁的冰钓小屋。

必刷一把左轮，位于罐头厂车间内（有四个点，都藏得比较阴间）。另有两个独立刷新点，分别在最东边的冰钓小屋内和罐头厂内的保险箱里。

有一个刷弓点，位于沿海公路终点附近的活动房门口，但是当前由于地形bug无法拿到。倒塌灯塔顶部必刷一把信号枪（入侵不刷）。非入侵难度下沉思瞭望台里有可能刷熊皮睡袋，瞭望台开门右转的挂钩上会有登山绳。罐头厂的某些板条箱拆掉会有沙丁鱼罐头。

只有一个熊洞，为加温山洞，必刷一头熊。有两片驼鹿刷新点，分别位于被冲毁的活动房后空地和地图西北角桦树林周边，两个点均无驼鹿痕迹，所以有可能都是独立的，但目前无法证伪。有两个冰钓小屋，均不带门，可以钓出两种咸水鱼。水系很多，但香蒲大多集中在深谷延伸过来的淡水附近，且总量较少。

燃料总体来说较少，最需要燃料的罐头厂附近甚至只能拆板条箱度日，只有通向沼泽的洞穴里有少量煤炭刷新点。说起来你可能不信，这个图连石头都很少。

其他：水湾联通上下层的那个登山点默认是没有登山绳的，所以初次进入水湾如果是在下层，那么在正常游戏中是无法探索上层的。探索水湾时推荐从深谷进入，在沉思瞭望台的登山点上绑好登山绳后，上下层之间就可以互通了。

水湾罐头厂通往车间的路线较为隐蔽，需要在厂房1内爬上一根登山绳后绕相当大的一个圈才能抵达，这途中还会触发一波森林狼的刷新。如果不想绕这个圈可以试着利用岩石储藏处和篝火搭一座便桥。罐头厂车间有进入限制，在必经之路上有一道电子锁，解除需要回音一号无线电塔下无线电控制站内的“通讯报告”。拿到报告后在极光夜点电子锁互动可解除门锁，解除后进入不再需要极光夜。车间内可能会刷新一只普通狼，进入前需做好应对，杀掉之后不会再刷新。极光夜时车间内散乱的电线也可能对玩家造成伤害，需要注意。罐头厂车间内有全图唯一的弹药工作台，可将废铅熔铸成弹头（需要火）、将树桩去除剂+硫粉+木炭合成火药、将火药+弹头+对应弹壳合成子弹。

水湾有全图唯一的的铣床，位于罐头厂车间内。在极光夜时可以修理猎枪、左轮、钢锯、猎刀、简易小刀、小斧头、简易小斧，每次只消耗一片废金属。其中钢锯和刀斧的修理成功率与恢复数值数值与修理技能挂钩[注13]，而猎枪和左轮的修理成功率值和恢复数值固定为50%和40%，疑似bug。当修理技能为100时时，修理钢锯和刀斧的成功率和恢复数值可以达到惊人的100%和99%（0%的工具不能被修理）。

水湾是当前生存模式唯二有森林狼的地图，这也是目前对玩家最具威胁的攻击性动物。不过该狼的行为和应对方式不在此文的讨论范围之内。

据点推荐：小屋（罐头厂工人居住区）评分 2/5

优点：内置壁炉，背靠熊洞，出门有冰钓小屋。临近海边能捡垃圾，不远的倒塌灯塔有全图唯一的室外六格炉。

缺点：空间小，容器少，工作台要跑去罐头厂车间，燃料老大难。水湾天气差，森林狼极度危险。

一般来说光凭这个天气和这个狼，水湾就可以告别长住列表了，硬要找个地方也就这了。森林狼刷新较慢，清掉之后在这还是能活一阵的，就是天气太难受。

洞穴（通往孤寂沼地）评分 2/5

同沼泽那章。

注释注12：游戏中有三个隐藏的技能，分别为磨刀、擦枪、修理。磨刀可以用磨刀石打磨刀斧升级，可以提升磨刀速度和恢复耐久的数值；擦枪通过步枪清理套件清理猎枪左轮升级，可以提升擦枪速度和恢复耐久的数值；修理可以通过简易工具箱&高级工具箱&镗床修理工具升级，可以提高修理的成功率和使用镗床时的耐久恢复的数值。

灰烬峡谷&图11

[]O`OLO_7.png]灰烬峡谷（Ash Canyon)，繁中译名灰烬峡谷，是全图唯二的简繁同译地图，通称图11&峡谷、灰谷。

地理：位于大熊岛最东北角，地形依据海拔分为多层，最底层为水系形成的河谷与大量烧毁的树木，往上逐渐正常。跨层需要登山绳，高层之间通过木质吊桥连接，使得这张图的路线变得非常立体。

气候：基础温略低于林狼雪岭水晶湖，暴风雪概率略高，可以看作一个劣化版雪岭。

重要物资：峡谷独有全图唯一物品高科技背包与鞋底钉，固定刷新于地图最西北角的金矿内。高科技背包可以使最大和最小负重永久增长5kg，并改变背包图标与音效。而鞋底钉可以减少爬登山绳时的耐力消耗、降低走斜坡时的扭伤概率以及延长在薄冰区可动时间（1秒左右）。目前鞋底钉依然无法被修理，属于不可恢复的消耗品（v1.94）。虽然掉耐久非常慢（放置每天0.02%，穿外层每天0.2%）但是穿上时触发摔伤、搏斗、烧伤、森林狼撕咬时都会被扣除一定的耐久，所以最好有需要的时候再穿。（注：现在鞋底钉已可修复）

必刷两把猎枪，一把在高草甸与琵琶鱼巢穴之间，一个小平台的横木上，另一把在金矿内。另有两个独立刷新点，工头休息所和琵琶鱼巢穴。

必刷一把左轮，在自耕农的休憩之所。另有一个独立刷新点，位于开采营地以西瀑布边的尸体手上。

有两个独立的弓刷新点，分别位于绵长瀑布洞穴到狼颚瞭望台路上的篝火旁和金矿后方三段绳第二段下方篝火旁。

概率刷新一把信号枪，位于高柱歇脚处以北小山丘上篝火旁，但是没有子弹。

有一个熊洞，位于矿工愚行，虽然只是一个石走廊但实际算是加温山洞，必刷一头熊。有两片驼鹿点，分别位于苦涩沼泽和金矿后方三段绳下。均无驼鹿痕迹，所以有可能都是独立的，但目前无法证伪。有一个冰钓小屋，位于苦涩沼泽，可以钓出两种淡水鱼。植物资源丰富，有着全图可能最多的桦树枝刷新点，大部分水系附近有香蒲可供采集。

燃料不缺，绵长瀑布洞穴、金矿、通往林狼雪岭的洞穴内都有一定数量的煤炭刷新点。地图西侧从三段绳到高柱歇脚处有大量桦树皮刷新点。

入侵难度下灰烬峡谷必刷三盒火柴，分别在琵琶鱼巢穴、自耕农的休憩之所和金矿内。必刷一根强心针，在狼颚瞭望台去金矿的路旁。

其他：拿背包路线有很多，各有各的好。红色路线最为朴实无华，虽然路程远了点，路上狼多了点，但好在不会迷路。只有绵长瀑布洞穴内一条短登山绳，只需要消耗的少许的精力。蓝色路线需要会蹭上自耕农，注定要一堆扭伤。不过爬上火焰瞭望台之后基本是一马平川，除了路过熊洞需要注意一下之外其他时间是绝对安全的。紫色路线要从奔鹿空地的洞穴进峡谷，成本上来说天然比从回音峡谷进多耗了一条登山绳的精力，但路线上不会碰到任何狼，但是要注意三段绳下的驼鹿点。上三段绳的方法很多，如果不想花费时间中途休息的话建议携带至少两瓶能量饮料或是一根强心针以应对三段登山绳的精力消耗。绿色为红色和紫色的切换路线，这两条后半程是可以互换的，具体选那条看自身喜好。

这个图的狼分布非常集中，只存在由于苦涩沼泽，破碎峡湾，绵长瀑布、琵琶鱼巢穴周边这几个低海拔区域。只要爬过了任何一段登山绳，就再也不会再受到狼的袭扰。

峡谷底部有大片烧焦的树干，周围恒定有一层特殊滤镜，看起来灰蒙蒙的，晴天都不会消散。峡谷有很多随风晃动的木质吊桥，看起来虽然可怕，但它只晃动自身，并不会带着角色坐标移动。安全的通过吊桥方法就是沿着中轴线一直走，除非你自己从绳子的缺口走出去，否则想要掉下去是很难的。另外在吊桥上丢弃物品的选项会被禁止，但是依然可以利用诱饵快捷键把肉扔出去。

有一些不知是剧情废案还是彩蛋的物品在地图上被标成了“有趣的地点”。最有代表性的两个就是“坏掉的步枪”和入侵难度都有概率刷的熊皮大衣。坏掉的步枪只是徒有物品名，点上去是无法互动的，而熊皮大衣倒是可以真捡起来穿身上。

峡谷这个图有一些很奇怪的加温点，这些点虽然看起来虽然不可能有加温，但是确实能吃到和衰变同步的温度加成。最具代表性就是矿工愚行的棚子里层，直接导致了这里成为全图唯一一个有加温的工作台，在这里制作物品既不用担心温度还能清理幽闭风险。

毫无道理的加温点：

加温工作台：（全大熊岛仅此一家）

该图有一个明显的不恰当译名，英文原文为Angler's Den，简中译为琵琶鱼巢穴，繁中译名为垂钓者的巢穴，比简中要靠谱那么一些。

虽然灰烬峡谷和林狼雪岭相连，但如果以回音峡谷直通口做参照的话，地图怎么摆都不对劲。所以要么峡谷顺时针转90°，要么林狼逆时针转90°，总要创死一个。

据点推荐：矿工的愚行评分 4/5

优点：两栋距离非常近的房子，加起来有一定空间，内置壁炉外有油桶，还有独一无二的加温工作台，无论是造衣服补箭和陷阱还是清理幽闭都很方便。离熊洞近，杀熊方便，附近就有兔子和鹿刷新点，整个活动区域都不会刷狼。

缺点：比较偏僻，过于自闭。如果长住把布料废金属搬过来就要费很多功夫，更别提需要定期去水湾修刀或是锻造打刀了。离钓鱼点略远食物也不够提供全天吃饱，柴火虽然不太缺，也并不充裕，要想攒多一点还需要过吊桥收集。天气也不是很理想。

加温工作台+无狼+熊洞旁，算是非常优秀的据点了，可惜的是地图太偏降低了上限。

琵琶鱼的巢穴评分2/5

优点：地图中心，内置工作台、单格炉，出门不远有油桶，离两个驼鹿点都不算太远。

缺点：小、容器少、没窗户晚上连床都找不到。四周环狼，虽然在中心但是去哪里都不算近，配合峡谷这个破天气其实还挺难受的。

属于那种有位置优势的临时据点，可以将上层的物资全集中到这里然后再试图搬出峡谷，长住不推荐。

黑岩地区&图12

监狱内部图

黑岩监狱总体位大熊岛北面，处于山间小镇，怡人山谷，林狼雪岭的包围圈内，目前可通过怡人山谷和林狼雪岭前往该图。其中林狼雪岭的连接口为安德烈峰西北的一个室内洞穴，直接通向泥瓦匠的休息所下方。而怡人山谷的连接口为长弯，在经过两个长连接图守山人山隘南侧和守山人山隘北侧后到达黑岩地图南部的阻断的道路另一侧。

中转通道&DLC地图

废弃机场&DLC地图

污染区&DLC地图

破碎山道&DLC地图

卡特大坝及周边蜿蜒河流（连接图）

卡特大坝及其周边（Carter Hydro Dam & Environs)，连接图，繁中译名卡特水坝及附近区域，这个图一般不会被视作一个整体，大坝部分被经常被误认为是神秘湖建筑，通称大坝；剩下的部分通称为蜿蜒河流。

地理：作为连接图位于神秘湖和怡人山谷之间。由大坝、蜿蜒河流和与怡人山谷的连接洞穴三部分组成。

气候：作为连接图，一般来说路过时继承神秘湖或是怡人山谷的天气。

重要资源：上层一楼的保险箱内可能开出左轮，上层负一楼前往大坝下层的楼梯对面可能刷左轮或是猎枪，大坝下层机轮房的办公桌上可能刷左轮，均为独立刷新点。在大坝下层通往大坝上层的门上会钉有箭支。

卡特大坝是全图最大的废金属产地，将大坝内的椅子和金属架之类的可拆物全部拆掉后可以得到720左右的废金属和80左右的布料，但是同时也要注意极光电线突然通电和幽闭风险的积累。

其他:大坝到蜿蜒河的出入口皆为单行道，出口为安全门，入口为另一侧的破窗。

极光夜会使得供电恢复[注6]，通电的散落线路会对玩家造成伤害并附带烧伤debuff。在剧情模式中可以通过使用电梯和关闭电闸通过一些带电区域，但是生存模式中这二者皆无法起效。生存模式通过极光夜大坝的唯一方式就是利用奔跑硬冲带电的区域，就算在负重最轻的时候冲过三段必经的带电区域所付出的状态值也达到了80%以上，所以极光时最好远离大坝，会带来不幸。

虽然大坝全地图为恒温，但是不同区域之间还是有一定得温度差。比如上层神秘湖入口处为恒定-5，到了机轮室就变成了恒定-8，游戏初期搜索时需要注意一下温度条。

据点推荐：一般和门口的活动房合并讨论，参见神秘湖篇。

注释注6：极光是游戏中的一种天气，只有在晚上才能被触发，在天上闪亮着诡异的光的同时会响起诡异的BGM。极光主要有两个效果，一个是让电器恢复工作，表现为各种灯开始瞎闪、部分电脑可以查阅记录、收音机里可以收到音乐频道、散落的电线会对玩家造成伤害和烧伤debuff；第二个是对动物造成影响，表现为兔子、鹿、驼鹿不再刷新，熊和狼刷上一层绿buff。极光状态的熊和狼生命值提升了50%，并附带额外25%的减伤，包括视野范围，冲锋距离在内的各种属性都获得了加强，也不再畏惧火堆、信号棒、信号枪这些常规应对手段。不过极光生物有个弱点，就是惧怕灯光，被路灯车灯或是手电筒的远光模式照射的极光生物会被定在原地，长时间的照射甚至能吓走极光狼，极光熊虽然不会被吓跑但也正因为这个会傻站在原地一直挨打。

极光夜

极光熊

乌鸦瀑布铁路深谷（连接图）

乌鸦瀑布铁路（Raven Falls Railway Line）又名深谷（Ravine），连接图，繁中译名渡鸦瀑布铁路线&溪谷，一般而通称深谷。经典两段式连接图名，两个名字都可算作正式名称。

地理：位于神秘湖、沿海公路和荒凉水湾之间。火车从铁轨冲出坠入深谷盆地从而截断了整条铁路，想要正常通过需要从一旁的独木桥绕行。

气候：作为连接图，一般来说路过时继承神秘湖或是怡人山谷的天气。

重要资源：深谷盆地的车厢内有信号枪匣，附带信号枪一把，子弹若干（入侵固定有枪，子弹4发，其他难度据说有概率不刷枪，目前无法证伪)。上层未坠崖的车厢内有固定4L大油桶，图中共有两个登山绳刷点，但不一定会刷登山绳。另有大量且集中的桦树皮刷新点。

其他: 全游戏唯一没有狼的地图，只要不到处瞎蹭就很安全。

乌鸦瀑布栈桥中间有一段是破损的，在这摔死也能算是本游的经典死法了，建议减速慢行，小心通过。

通向深谷盆地的登山点默认是没有绳子的，而围绕深谷盆地有一圈不可见的秒杀线，玩家通过秒杀线后会被赋予一个非常高的坠落伤害，基本必死。想不爬绳直接蹭下深谷的同学建议先备份存档或者完全照抄视频攻略的路线[注7]。

深谷盆地的绳子通常是玩家在游戏中第一次碰见的长绳，这种高度的绳子在非满状态的时候是很难一口气爬上去的。建议在爬绳途中尽量凭借中途的岩脊回复耐力，或是干脆利用强心针的锁耐效果直接强上。

据点推荐：一般和大坝门口的活动房合并讨论，确实有些人因为没狼喜欢单住这里，但是个人认为连室内床都没有的地方不配称为据点。

注释注7：该游戏存档位置为 C:\Users\你的用户名\AppData\Local\Hinterland\TheLongDark，win10 steam平台有效，其他操作系统及平台未测试。

古老小岛连接处公路废墟（连接图）

古老小岛连接处(Old Island Connector) 又名公路废墟（Crumbling Highway)，连接图。繁中译名旧岛连接区&破碎公路。经典两段式连接图名，两个名字都可算作正式名称，个人偏向于叫它公路废墟。

地理:位于沿海公路和荒芜据点之间，结构与沿海公路类似，只不过公路被从中截断。

气候：作为连接图，一般来说路过时继承沿海公路或是荒芜据点的天气。

重要资源：三号煤矿厂里有大量的煤炭刷新点，薄冰附近有漂泊物刷新。

其他：该图地形狭窄且复杂，还会刷复数的狼，无论是冰面还是靠山都不算安全，穿越时最好能谨慎慢行，以免拐角撞狼。

据点推荐：无，连个床都没有的地方不配当据点。

守山人山隘南，北侧（连接图）

守山人山隘南侧还算简短的连接图，有房子钓鱼小屋也有狼，没什么岔道，需要注意一下河面的薄冰。

守山人山隘北侧又臭又长的连接图。为第四章一开始麦肯齐逃亡的地方，虽然全程无狼，单总行进距离非常长且中间没有回温点。建筑师之桥下有一个非加温山洞，内有信号枪盒，非入侵会附带子弹，但是入侵就只有一把枪，可以蹭下去，但是正常游戏只能爬绳上来。

远境支路（连接图）

记一次无需实名换绑米哈游通行证手机号

Chongxi — Wed, 15 Jul 2026 00:00:00 GMT

本案例提供了非自己实名更改米哈游通行证手机号的方法

主播也算是米游老资历吧（以前），早在崩坏时期就已经创号了，但当时也确实是意识薄弱，实名信息填的并不是自己的，当时也确实不知道米游不让改实名，这就埋下伏笔了

大概是今年年初，我一位朋友想借我以前的原神号拿去玩（不敢笑，主播在20～21年那时候真是资深原批，不过现在就不是了），然后我登号的时候一拍脑袋，坏了，原来的手机号早就不用了，只用密码又不让登号，便想着去申诉，而答案是实名不是自己的，不允许申诉，这就死锁了

也可能是因为我申诉的次数过多，今天我在检查邮箱时，突然看到一条二次申诉的邮件，如下图

多么好的机会啊，本来也是自己账号，也算个人资产，即使不玩米游了好歹也救一下，于是便把米游社下回来用邮箱密码登录，随后便要求我绑定新的手机号，当然实名还是不让我改，然后就成功换绑了

个人猜测可能是我之前申诉太多导致的账号异常，然后米游就给我风控了，就有了这次案例，也是希望米游都这么多年了，允许下实名信息变更吧

邮储银行万事达借记卡全面指南

Chongxi — Mon, 13 Jul 2026 00:00:00 GMT

自邮储万事达借记卡办下来也一年多了，这里简单讲下我的日常使用体验吧

卡片详情

万事达世界之极借记卡，为新版万事网联，人民币美元双币种，支持自动换汇，卡标为万事达logo，使用人民币存入，境外自动换汇走美元结算

普卡 = 万事达金卡
金桂卡 = 万事达白金卡
富嘉卡 = 万事达世界卡
鼎福卡 = 万事达世界之极卡

邮储内部按客户等级（近三个月在行资产规模）划分

大众客户 <10万
金桂客户 10-50万
富嘉客户 50-600万
鼎福客户 >600万

海外带有万事达标志的场所均可使用此卡（会不会拒付不好说）

本卡为借记卡，需要先存钱再消费

使用体验

境外Google Pay

首先是Google Pay，GPay貌似不验证发卡地区，所以你可以很轻松在美区绑定上该卡走美元进行消费，我看别人有说有3ds验证，但事实上我在支付时钱直接就划卡走了并没有遇到任何二次确认，这个需要注意下，保护好自己的卡号等敏感信息

以下是在dynadot走Google Pay消费了17.66USD的交易记录，可供参考，使用的正是此万事达借记卡

虽然是美元结算，但是在邮储银行内的账单显示的是CNY，暂时不清楚这个是什么逻辑，使用时我更推荐要支付多少钱就存多少，比如这里要支付120CNY我就存了130，防止出现不必要损失

Apple pay

美区App Store无法绑定此卡作为美元支付方式，因为App Store查发卡地区，这卡发卡地区是国内，故无法绑定，会报错

apple pay钱包的话，大概是能绑定的，这方面apple管的很宽松

Samsung Wallet

不支持绑定，国行只允许银联，外版没试过大概率也是不行

Steam

同样的，查发卡地区，无法使用此卡绑定

PayPal

因为本人PayPal是英区，就没尝试，各位有尝试过的可以在评论区留言

建议

只要是查发卡地区的基本上都不行，日常线上消费可以走Google Pay或者PayPal（如果能用），在Google Pay绑定此卡后，如果商户允许Google Pay就优先走这个（比如我那个dynadot的），省事很多

线下支付

这个看情况，港澳地区我在去年刷麦当劳是没问题的，其他地方暂时没试过，有经验的大佬可以补充下

作为人民币储蓄卡使用

没啥问题，完全可以作为普通的银联使用，微信支付宝等都可绑定，但由于不是银联所以无法绑定云闪付，可升级为一类卡。

不过这里要讲个趣事，我在邮储银行网点办业务的时候，网点工作人员没认出这张卡，反复确认不是伪造的假卡后才给我放过去

当然非必要我是不推荐只办理这一张卡作为你的主力使用，国内场景最好有一张完整功能的银联一类户，防止带来不必要的麻烦，毕竟多一个境外支付就多了个风险面，前文说的花多少存多少也是这个道理

申请方式

线上申请点击此链接：邮储万事达借记卡申请，此为邮储银行官方网站，在官网内选择万事有礼，填写个人信息后支付工本费后发卡，拿到卡后需要到邮储银行线下网点柜台进行激活，走正常借记卡申请方式

线下申请的话，我是网申所以不太清楚，有经验的可以评论下

关于满16未满18的用户

这个我帮你们打客服问了，如果你有工作流水证明可以自己去激活，否则需要家长带你去走代办理，手机银行大概率也不行，满18的话自己去就行

结

总的来说还是值得去办一张的，工本费一杯奶茶钱，日常体验尚可，一般场景的境外线上消费是可以满足的，当成普通银联卡在国内用也没有什么特别大的阻碍，视个人情况决定，算是一张不太出色也不算特别垃圾的卡，值得一试

碎碎念下，门槛低可以说是最大的优点，邮储自己可能也考虑过这张卡发卡地区国内的局限性，既然上限锁住天花板不如拉低下限，让试一试的成本变低，觉得够用就一直用，不够用也不会太亏，对银行来说多点用户也不是坏事，借记卡也没有什么坏账的风险，对用户来说门槛低，对银行来说风险低，恐怕这也是这张卡能存在的原因了，双方都没啥大的损失

x402：一个来自27年前的状态码能救活被ai榨干的「人类网站」吗

Chongxi — Fri, 03 Jul 2026 00:00:00 GMT

引

故事要从1999年说起，当时HTTP/1.1定义了一个叫402 Payment Required的状态码，意思是这个资源需要付费才能访问，但当时没人知道怎么在互联网上方便安全地收钱，于是这个状态码便沉没在汪洋大海里，一去便是二十多年

x402实现机制

流程

agent/ai爬虫发起请求你
服务器返回402，并附带一个JSON写上价格，接受的资产类型（比如USDT），结算网络（比如Tron），收款地址
如果愿意支付的话，客户端根据服务器开出的筹码签名
客户端带着签名放进专门的HTTP头里重发请求
服务器验证签名后，发给结算方，没问题就200放行

怎么证明是我付的钱

略微懂现代密码学的估计已经明白了，payload签名后，没人能篡改你的payload，篡改了就会失效，其次签名本身就是证明，你能生成签名就能说明你控制了这个钱包地址，而这个签名又只对应这一笔收款，没法伪造

结算方干啥的

服务器不需要懂区块链也不需要懂节点，只需要外包给facilitator即可，人家一口气负责掉签名验证/付款有效性/是否是重放等攻击/广播上链完成结算。目前Coinbase Developer Platform运营着主要的facilitator，在base chain上做USDC免手续费结算，这也导致不少人质疑x402去中心化的底色，因为依赖单一中心化服务商。我个人是实用导向，不太在乎什么中心化不中心化的，黑猫白猫能抓老鼠都是好猫

x402为什么被刨出来了

这玩意在1999年就被定义了，但在web3金融成熟前传统支付链路都太重，web3现在刚好解决了这个老大难。其次是ai变成了主要访问者，传统互联网是给人设计的，人们遇到付费资源自己去订阅支付，但现在很多时候都是ai在看你的网站，人家不会订阅也不会看广告，而且ai请求已经是人的百万量级了，有需求就有市场，人们需要一种方法去对ai计量，于是Coinbase和Cloudflare一拍即合，共同推动x402基金会成立，把402开放化标准化

timeline

2025/07/01 Cloudflare以私测方式上线Pay Per Crawl，让内容方可以用402向ai爬虫收费，当时是三个策略：完全开放/设定价格/直接全封
2025/09 Coinbase & Cloudflare两大巨头一拍即合，开始推动x402基金会创立
2025 10月底 x402基金会正式宣布成立
2026/7/1 就在最近不久，Cloudflare发布货币化网关，把收费范围从只针对爬虫拓展到任何调用者的按次数收费改为内容是否被引用收费（因为抓取这个指标太烂了，一个页面可能只被抓一次但被成千上万引用，或者被无数抓取但没人用过

案例

Cloudflare数据显示，2025年6月OpenAI的引流比例是1700:1，Anthropic则是73000:1，另外据Cloudflare的数据，只有37%的头部万家网站正确配置了robots.txt，很令人震惊

在DeveloperIO上，一位开发者给自己网站（一个有万条数据的DJ演出数据库）接入了x402，OpenAI的爬虫确实通过x402付了款，但当时只有OpenAi一家爬虫支持，接着就是全面付费墙导致SEO爆炸，最后不得不改成部分免费部分付费

争议

最近看HackerNet基本上是两类典型争议

有人认为这种方式会打消用户付费意愿
有人认为Cloudflare会带来隐私问题，以及能否成为新的AdSense还是变成失败的支付实验

结

我的看法是，对于中小站长，AI公司直接放弃抓取的概率很大，单篇内容边际价值过低，互联网上同质化的教程啊博客啊太过剩了，你不让他爬他换个信源就是了，这种东西又没什么独家复刻的技术门槛，除非你是业内领头而且独家数据源兴许有点谈判的可能性

cloudflare改成引用付费也是承认了这个，真产生了价值才配得上谈条件，决定议价能力的是内容本身是否有替代性，上面那个DJ数据库就因为是全网独家一手数据源，OpenAI才愿意付费，换成像我们这种普通个人blog，大概率连值得付费的门槛都碰不到（笑

本质上是给了内容方一个谈判的筹码，而不是直接变现的来源

舞萌国人口大普查：全服玩家数据分析

Chongxi — Tue, 30 Jun 2026 00:00:00 GMT

观前提醒，本文分析报告基于2026年初的玩家数据，由于数据差半年，分析全服rating并没有太大意义，所有本文主要通过已知数据做一次人口普查，分析和uid相关的内容

非特殊说明，本文数据截止于2026/01/01

概览

我们早些年得知，舞萌UID是1开头的八位顺序数字，UID呈递增，这也是为什么在1.53前能以遍历手段扫全服玩家数据，攻击者直接从10000000开始一个个遍历活人

UID最小的为10103750，也就是说，舞萌国服最老资历大概率就是这位

截止到2026年一月，已记录的玩家总数量达141万人，但在当前版本活跃的玩家仅25万

Rating 为 0的共16417 人，占比1.2%

关于封禁

封禁状态，也称bs，也就是ban state的意思

已记录的bs1数量有24人，占比0.002%
bs2数量有233人，占比0.016%

bs1是警告，每次上机时会弹五秒红框，且无法参加友人对战以及万花镜模式中的棱镜塔后的内容 bs2则是永封

使用默认用户名的数量

使用maimai默认用户名的数量为 277062 人，占比 19.8%
使用舞萌用户名的数量为 7685 人，占比 0.54%

各位喜闻乐见的

该栏目记载了国服的某些黑客往舞萌服务器拉的脏数据

rating是那个敏感日期的数量为 16 人
版本号修改为「天安门」的有 1 人

黑客rating

看看列表中有没有你的荣誉证书

Rating	lastRomVersion
2147483647	1.51.00
1932217053	1.99.00
1145141919	1.51.00
999999999	1.50.00
99999999	1.51.00
5201314	1.66.1
1919810	1.41.00
999999	1.50.00
127684	1.00.00
99999	rnm还钱
99999	1.41.00
99999	1.51.00
99999	9.99.99
99999	1.51.00
99999	1.41.00
99999	1.51.00
99999	9.99.99
99999	1.34.00
99999	1.41.00
99999	1.41.00
99999	9.99.99
99999	1.41.00
99999	1.41.00
99999	1.50.00
97441	1.41.00
92778	1.51.00
77777	1.20.00
66666	1.41.00
29732	1.51.00
23333	1.40.00
23333	1.41.00
23333	1.41.00
23333	1.99.99
18964	9.99.99
18964	9.99.99
17899	1.32.00
17777	1.51.00
17550	1.41.00
17000	1.41.00
-1	1.51.00
-1	1.50.00
-1	1.51.00
-1145	1.50.00
-99999	1.40.00
-2147483647	1.41.00

黑客版本号

lastRomVersion	使用此版本号的账号数量
9.99.99	7
你好	2
电棍笑传	1
爱新觉罗	1
我也想玩国服	1
天安门	1
rnm还钱	1
9.99.00	1
114.02.00	1
1	1

号段分布规律

已知UID是递增，一定程度上可以推出版本和号段的大致分布，根据简单推导可以得出（不保证100%对，可能有误差）

DX初代：101 ~ 104
DX2021：105 ~ 109
DX2022：110 ~ 114
DX2023：115 ~ 120
DX2024：121 ~ 128
DX2025：129 ~ ?

每个版本的玩家数量

通过号段粗略计算，不保证准确性

世代	推算的玩家数量
DX初代	116332
DX2021	216945
DX2022	260117
DX2023	257498
DX2024	345038
DX2025	至少215369

老资历

DX初代一直玩到现在的老资历共 14816 人

杂项

NET 会员

类型	人数	占比
非会员	930,297	65.9%
网络会员	481,002	34.1%

lastROMver分布

可以看全服数据内有多少玩家弃坑

世代	玩家数量	占比
DX 2025	416,001	29.48%
DX 2024	312,693	22.16%
DX 2022	205,070	14.53%
DX 2023	228,952	16.22%
DX 2021	164,610	11.66%
DX 初代	83,962	5.95%
总计	1,411,228	100.00%
因为这个记录的是最后一次游玩的版本，并不能反应每个版本的玩家数量，更像是反映了初代到2024死了多少玩家

全服rating

如果你感兴趣，可以看舞萌国百分一段位次图，目前更新了现在时间DX2026的全服真实rating排行，2025的也有，不过数据是2026年初的，不太有参考性

家中网络「捉奸」记

Chongxi — Fri, 26 Jun 2026 00:00:00 GMT

上回书说到，Chongxi家里莫名其妙被移动公司限速上行到4Mbps，由于Chongxi这几天确实在迁移网盘里的备份，便没对路由器上wan口巨额上传总流量计数起疑心

在和区管沟通后，宽带师傅便到我家上门检查，查光猫和路由器的时候里三圈外三圈什么都没发现，没有nas也没有机顶盒，除了一根光猫和路由互联的网线其他什么都没有，硬是让师傅挠了半天头不知何原因封的宽带

然后师傅就要求进光猫后台看拓补图，一看光猫桥接路由拨号后，将此情况上报给区管，区管超级生气暴怒，说这是违规操作

由于师傅用移动的那个app一直绑定不上光猫（那可不嘛，远控被我删了），区管便让师傅换一个新的，也就是我们上问说的那个PT927G，重新绑定后拍了几个照片，然后依旧是保证书签字，便作罢

然后的事情就是，我只用了三分钟就成功拿到了新光猫的超级密码，又把路由拨号改回去了（详见前文）随后刷新数据发现，好家伙，这才刚接上，wan口怎么就已经跑了10.6GiB的上传呢，下载才8.8GiB，这肯定不对啊，于是火速安装了一个带宽监控的软件包，看看是哪个设备在作祟，一查真相大白，我才刚安装上监控一两分钟，上传就跑了234MiB，是下载的好几倍，一看家里老人的手机上传的，我特么闭着眼就能猜到是某些流媒体平台干的，我家NAT1可不是很好打洞嘛，upnp列表一看168h的霸王条款，那怪不得我家里被封宽带，都是这些平台把人偷偷当pcdn用的，还不如某些pcdn的服务商呢好歹人家给你发点钱，这帮人不仅吸血还给你宽带玩封，太恶心了

一气之下直接安装个qosmate，把上行掐到500KB/s，顺手给upnp关了，这帮吸血鬼厂商属实恶心

中国移动PT927G光猫折腾指南：破解超级密码改桥接

Chongxi — Thu, 25 Jun 2026 00:00:00 GMT

import { Decryptor } from '../../../../../components/Decryptor'; import img1 from './photo/Screenshot_20260625_215217_QQ.webp'; import img2 from './photo/Screenshot_20260625_215154_QQ.webp'; import img3 from './photo/Screenshot_20260625_215726_QQ.webp';

引

我的朋友可能之前听我讲过啊，Chongxi家里的网之前是1000Mbps的下行，500Mbps的上行。就在前几天，Chongxi在往网盘里存东西的时候发现网速极其不对劲，上传居然只有160KB/s，检查了一遍代理软件都是关掉的，于是便重启了一下路由器，结果还是极低的上传，顺手一测速，好家伙，上行直接缩水的连10Mbps都不到，测几次都是4Mbps左右，当即怀疑是运营商限速

后来便是宽带师傅跑到我家里，得知我家是光猫桥接路由PPPoE后超级生气暴怒(其实限速不是这个原因，限速的事情下期讲)，然后顺手给我光猫换掉了，换成了现在的PT927G，然后改成光猫拨号

不让我NAT1这我能忍？等宽带师傅走后，立刻开始破解这个光猫的超级密码改桥接

破解光猫并拿到超级密码

经常折腾光猫的估计都知道，光猫想改拨号一类的设置需要超级密码，而现在基本都缩紧了，找宽带师傅要基本都不给，初始的那些密码早就失效了，所以我们要自己想办法去拿到超级密码

开启Telnet

先进入光猫的后台，用user登录一次，登录密码在盒子背后，成功登录后我们访问 http://192.168.1.1/cgi-bin/abcdidfope94e0934jiewru8ew414.cgi ，看到success就成功了

Telnet获取超级密码

随便找一个客户端就行，我这边比较习惯用Termius，就直接telnet 192.168.1.1，账号密码如下

账号：yhtcAdmin
密码：Cm1@YHfw

成功登录后就可以搞事了

获取密码

这里我们切换到配置目录

cd /var/config

然后直接就能把超级密码掏出来

cat lastgood.xml | grep SUSER_PASSWORD

# 输出: <Value Name="SUSER_PASSWORD" Value="aDm8H%MdA"/>

这里我们成功掏出来是aDm8H%MdA，你那边的光猫超级密码和我的不一样是正常的，接下来直接就能进后台把玩了

账号： CMCCAdmin
密码：你的超级密码

光猫改桥接

关于宽带账号和密码

这里Chongxi是知道自己的PPPoE账号和密码的，所以我跳过了，如果你不知道，就回到光猫的telnet里，在刚才目录输入

cat lastgood.xml | grep ppp

你会看到一个叫pppUser和pppPasswd的两个值，前者是宽带账号（其实光猫后台也能看见），后者是混淆的密码，如果你懒得反混淆可以直接用办宽带的手机号给10086发CZKDMM，他就把新的宽带密码给你了，然后这个操作会重新下发一个光猫的拨号配置

如果你不小心改炸了

可以按刚才说的重置一次宽带密码，这样会自动恢复光猫拨号配置（别问我怎么知道的，曾经炸了一下午重置了无数次密码才发现这样可以恢复）

关于混淆其实就是把明文每一位加上1再翻转过来，你可以直接用我这个组件解密

改桥接

经常折腾光猫的朋友估计都会，把默认的INTERNET_R删了新建INTERNET_B，Chongxi这里也是轻车熟路了

网络 -> 宽带设置，直接把图中这个INTERNET_R删掉，然后新建一个Bridge的，DHCP可以关，然后确保VLAN ID前后一致即可，可以自己对一下图2的配置，除了VLAN你要自己看和你原来的一致，其他的和图一样就行

路由器拨号

有手就行啊，打开我的路由器后台，直接改成PPPoE，一填账号密码。啪，通了，毫无难度啊我说

结

到这就折腾完毕了，如果你某一步改炸了，可以发短信让运营商云控给你恢复，这也是为什么我没教各位删远控，我这边运营商是不会定期查的，如果你那边经常查的话可以考虑删云控，如果你能保证玩不炸的话

至于为什么封宽带，请看家中网络「捉奸」记

最好用的Android邮件客户端推荐

Chongxi — Tue, 23 Jun 2026 00:00:00 GMT

引

依旧分享案例啊，不知道各位有没有用过iOS的系统Mail app，Gmail/Outlook等聚合用起来是非常不错的，那么Android侧有没有呢，在之前也许是没有，因为我手机里同时有Gmail, Outlook, Proton等一堆客户端，管理起来很是难受，后来又用过什么Spark一类的，总感觉差点意思（因为要花钱），那么有没有能对标iOS系统mail app的聚合客户端呢，有的兄弟有的，那就是：

Samsung Mail

Samsung Mail

Samsung的系统app啊，用过三星浏览器的估计就已经知道OneUI的系统app有多好用了，虽然是标的Samsung，但其他Android手机也是可以用的，除了proton因为自己的端对端加密问题不能加，我测试下来Gmail和Outlook都没问题，整个app非常干净0广告也没有高级版什么的，使用下来唯一一个能和iOS Mail碰一碰的

那么问题来了，Gmail和Outlook的客户端也能添加其他邮箱啊，确实是，但是我测试下来Gmail添加outlook会报错，outlook添加gmail会报错，很诡异兄弟，换了几个号还是这个问题，真没招了

至于国内的邮箱，貌似没啥好的办法，只能用自己的客户端，第三方时不时给你干掉了

如何验证对方是不是Chongxi我本人

Chongxi — Sun, 21 Jun 2026 22:34:21 GMT

Ed25519 Public Key MCowBQYDK2VwAyEAAPB9MubdfbA6yF+rEpqVtPYCXE94/nEUh3OofiHx8c0=

Fingerprint: f254c03b0d61f664
Owner: Chongxi <qwq@chongxi.us>
Website: chongxi.us

如果您怀疑对方冒充 Chongxi，可以发给对方一段挑战字符串，例如 VerifyChongxi1782050590，要求对方用私钥签名后返回签名值。

随后使用上方公钥验证签名：

TMPPUB=$(mktemp)
TMPSIG=$(mktemp)
TMPMSG=$(mktemp)

echo "-----BEGIN PUBLIC KEY-----
MCowBQYDK2VwAyEAAPB9MubdfbA6yF+rEpqVtPYCXE94/nEUh3OofiHx8c0=
-----END PUBLIC KEY-----" > $TMPPUB

echo "我签名出的base64放在这" | base64 -d > $TMPSIG

echo -n "你给出的挑战字符串" > $TMPMSG

openssl pkeyutl -verify -pubin -inkey $TMPPUB -rawin -in $TMPMSG -sigfile $TMPSIG

rm -f $TMPPUB $TMPSIG $TMPMSG

若验证通过即可确认对方是本人

假如有一位叫Jackdwh的人认为正在和他聊天的人不是真的Chongxi，那么他可以要求对方验证：你真是Chongxi嘛20260621221640

若对方真是我本人，我签名出7zxngFpM2/uDM1nCIBW+VWwuDnTkfqO7a52UbTX7TmJZ6KeL72SwnvoDFtxZcC2ztHjmaiw+/RCiBVECxfIfCA==

此时Jackdwh打开终端，输入

TMPPUB=$(mktemp)
TMPSIG=$(mktemp)
TMPMSG=$(mktemp)

echo "-----BEGIN PUBLIC KEY-----
MCowBQYDK2VwAyEAAPB9MubdfbA6yF+rEpqVtPYCXE94/nEUh3OofiHx8c0=
-----END PUBLIC KEY-----" > $TMPPUB

echo "7zxngFpM2/uDM1nCIBW+VWwuDnTkfqO7a52UbTX7TmJZ6KeL72SwnvoDFtxZcC2ztHjmaiw+/RCiBVECxfIfCA==" | base64 -d > $TMPSIG

echo -n "你真是Chongxi嘛20260621221640" > $TMPMSG
//由于blog会自动pangu给中英文加空格，实际这里应该是没有空格的

openssl pkeyutl -verify -pubin -inkey $TMPPUB -rawin -in $TMPMSG -sigfile $TMPSIG

rm -f $TMPPUB $TMPSIG $TMPMSG

回车后终端若输出Signature Verified Successfully则确认是我本人

三星S20系列刷入移植OneUI8流程

Chongxi — Sun, 21 Jun 2026 11:31:11 GMT

引

读过我前一篇关于Samsung S20刷类原生的可能都知道，我对S20这个机器可以说是很偏爱，没读过也没关系，本篇我们着重要讲S20系列刷入移植版OneUI 8 Rom的操作方法

这次要刷入的是Astro ROM，基于S23Ultra移植，功能都没什么问题，相机指纹什么的驱动一切都正常

支持型号

只支持骁龙处理器机型！！！

Samsung Galaxy S20 (x1q) Samsung Galaxy S20+ (y2q) Samsung Galaxy S20 Ultra (z3q)

• SM‑G981N, SM‑G9810, SCG01 ,SC-51a • SM‑G986N ,SM-G9860 ,SCG02 ,SC-52a • SM-G988N ,SM-G9880 ,SCG03

准备

一台S20
良好的视力，健全的手和基本的阅读理解能力
三星刷机工具Odin
系统底包(如果你是国行，需要刷一遍港版的系统底包)
移植刷机包
vbmeta_disabled.tar
multidisabler-samsung-3.1-keep_encrypt.zip

以及，你要清楚你在做什么，你需要承担你刷机造成的一切后果，本文仅作为guide，不承担操作者造成一切可能后果的责任

固件下载

由于主播的网盘暂时歇逼，这里用的是白皮的下载地址，如果慢的话自行科学上网一下

TWRP部分

刷入流程

0. 最起码你应该解锁bootloader

1. 刷入底包

我这里是拿自己的S20作为演示，因为是国行机G9810，所以需要先使用Odin刷入港版固件作为底包，这里推荐使用 samfw.com 下载固件

2. 刷入TWRP

先关机，随后按住音量+和音量-，此时将数据线插入电脑，会进入下载(俗称挖煤)模式

此时打开Odin，在选项把Auto Reboot关掉

AP 槽位选 twrp.tar
USERDATA 槽位选 vbmeta disabler.tar 然后直接开始刷机，完成后按住电源和音量-关机，然后快速改成电源和音量+直到启动TWRP

3. 刷入Astro Rom

分为如下小步骤

3.1 格式化

进入TWRP后，点Advanced -> Terminal，输入

multidisabler

然后回车，直到脚本结束，然后重启进Recovery

再进入Wipe，点击格式化Data，然后再重启进一次Recovery

3.2 刷包

直接把包传到手机存储或者adb sideload也行，后者省事，我就是这样刷的，刷完直接重启即可，可能要重启两次

结

这个包他是自带ksu的，Rom作者说是ksu NEXT，但我安装ksun管理器后提示没有在内核找到函数，不知道何意味，用ksu官方分支提示内核版本比管理器大，很诡异

原帖地址: XDA

卖家秀(截图)

使用obisidian和git插件来完美管理静态博客

Chongxi — Sat, 20 Jun 2026 16:31:31 GMT

引

静态blog博主多多少少都会遇到过这种问题：用git push的割裂感太强以及反馈不及时。毕竟静态blog每次都要构建分发，推送一次得等一两分钟，这个没法解决，但是git造成的割裂感这一点倒是有办法解决

通常情况下，我们用vscode或者其他的文本编辑器写markdown，然后还要手动打开终端进行一次git push，多设备写作的话都得配一次git ssh，实在过于闹腾，导致我最近一段时间因为不在家，手机又没配repo，一定程度上降低了我写作的欲望

可能会问，为什么不用GitHub WebUI呢，我只能说长期用下来真的很别扭，偶尔上去改个文字用Web编辑器还好，长期用下来我个人是有点不好接受的

那么回归正题，有没有一个不仅操作简单方便，编辑器功能强大，又能完美搞定git的撕裂感的方案呢，有的兄弟，有的：

使用Obisidian手机版+git插件，完成自动git实时同步

简单介绍下 obisidian是一个很著名的基于markdown的文本编辑器，功能非常强大，且跨平台

操作步骤

1. clone仓库

我个人是比较喜欢直接命令行操作，所以就用termux了，在termux里先安装最基本的git软件包

pkg install -y git openssh

这个命令可以安装最基本的git插件，因为我习惯用ssh auth，这里顺手装openssh了。

clone下来之后，要把repo搬到Android自己的内部共享存储，所以就先初始化下存储权限

termux-setup-storage

然后把blog复制到内部存储里

# 这里记得把文件夹名改成你自己的
cp -r ~/CEPATO-NEXT /storage/emulated/0/Documents/CEPATO-NEXT

复制过去之后，我git status一下，报了fatal: detected dubious ownership in repository的错误，因为Android毕竟是FUSE，git安全考虑拒绝了，我们

git config --global --add safe.directory /storage/emulated/0/Documents/CEPATO-NEXT

然后再git status，结果git报了一堆modified，即使我完全没动过，因为FUSE不保留unix的权限位，git误认为变动，我们

git config core.fileMode false

就解决了。

这里要注意一下，obisidian走的是https，如果你用的是ssh clone，你要给他remote改成https地址

2. 设置obisidian

打开obisidian，vault选刚才的repo，然后在设置找到第三方插件，关掉安全模式，搜索git并安装第一个

接下来我们打开GitHub.com，设置一个token，记得勾选所有repo类，然后复制下来

再打开obisidian，git模块的设置，将token填入，然后设置好用户名和邮箱，这时候基本上就能用了

3. 优化

由于obisidian和Android系统本身会产生一堆配置文件，我建议在.gitignore里屏蔽掉obisidian的以下内容

.obsidian/workspace*
.obsidian/cache
.obsidian/.trash/
.trash/
*.tmp
.thumbnails/

然后关于其他git模块的设置，因人而异，可以自行决策

结

综合下来体验还是非常不错的，obisidian+git的组合非常强力，唯一的缺陷就是这个git插件是js实现，有点慢。关于途中遇到的所有问题几乎都是因为Android不是真正的 Linux 文件系统，以后碰到这种问题优先往这方面考虑能少不少问题

截图

玩客云拆机教程

Chongxi — Fri, 19 Jun 2026 00:00:00 GMT

引

众所周知啊，玩客云刷机要么按reset要么短接，而短接就需要拆机（这不废话吗），估计挺多折腾这玩意的都会感觉很神秘，因为根本看不出要从哪下手，本篇就图文介绍下

拆机步骤

其实挺简单的，主要从背部下手，玩客云背面是双面胶粘起来的一个面板，拆掉之后就是螺丝固定的又一个背板，如下图所示

拆第一层背板的话，如果你有热风枪就可以对着背板加热，吹风机开暖风也行，加热之后一翘就开了

这里就是死掉双面胶背板后的样子，然后卸下螺丝，把背板整下来，就成功拆开了

这时候用手一拿就能把主板掏出来

然后就可以紧张刺激地短接刷机了

母语级英语的本质，不是英语

Chongxi — Sat, 06 Jun 2026 23:02:11 GMT

每隔一段时间，总会有人讨论一个问题：

英语语感是不是天赋？

有人说是，因为有的人学得特别快；有人说不是，因为大量输入就能练出来

但我自始至终觉得，这个问题他又问偏了。真正值得讨论的，不是英语

人对于“英语很好”的理解，是单词量很大，语法很熟，口语流利

but 如果你接触过真正意义上的母语级英语使用者，他们和普通英语学习者最大的区别，往往不是语言能力

而是思维方式

多数人的英语学习过程，本质上是一个翻译过程

看到英文freedom自动转换成自由。看到democracy自动转换到民主

然后认为自己已经理解了

这种方式当然能够交流，也足够应付考试工作甚至大部分阅读

但它有一个隐藏前提：

所有概念都存在一一对应关系

然而现实并非如此

语言从来不是一个单纯的符号系统。它同时也是一个文化长期演化出来的认知.zip

每个词汇背后，都携带着大量历史、社会和文化信息

例如英语里的 freedom，中文通常翻译成“自由”

但如果真的进入英语语境，你会发现它并不是一个孤立词汇

它背后连接着：个人主义/财产权/宗教自由/言论自由/宪政传统

这些概念共同构成了它的语义空间

一个英语母语者在看到 freedom 时，大脑调用的是整个网络

而很多学习者调用的只是“自由”两个汉字

从信息量上说，两者根本不是同一个东西

我会把英语学习者分成两类

第一类处于 Translation

他们的思考路径是：中文概念 → 翻译成英语

英语对于他们来说是一层外壳，底层运行的仍然是中文世界观

第二类则进入了 Native

他们看到英语时，不再寻找中文对应词，而是直接使用英语语义网络进行理解

例如看到：liberal。他们不会问：

这中文到底翻译成自由派还是自由主义？

因为他们知道这两个翻译都没意义

他们更倾向于理解这个词在英语世界中的实际位置

也就是说：

不再把英语概念映射到中文世界，而是进入英语世界内部理解英语概念

这时候，语言已经不再是语言，而变成了认知框架

真正的门槛不是英语

很多人会把这种能力归因于语言环境，认为只有在美国、英国长大的人才能做到

环境当然有帮助，但我认为环境其实解释不了全部现象

因为现实中存在大量反例，有人出生在中国，接受中国教育，生活在中文环境，却最终获得了极其接近英语母语者的认知方式

与此同时，也有人在英语国家生活很多年，依然停留在翻译模式

这说明决定因素并不只是环境，真正关键的是另一种能力，一种更加底层的能力

认知迁移能力。

即：

在不改变物理环境的情况下，让自己的思维进入另一套世界解释系统

不是学习。而是迁移。

绝大多数人的思维方式其实非常稳定，他们习惯使用自己成长过程中形成的认知框架解释一切，这没问题，对大脑来说成本最低，人本性如此

如果我告诉一个普通人：

试着用英语母语者的视角理解这个问题

他可能会说：

傻逼吗我在国内你让我用英语

但有些人不同，他们似乎天然具备一种能够在脑中暂时关闭默认框架，然后允许另一套系统运行的能力

他们会主动思考：美国人为什么这样理解？程序员为什么这样理解？经济学家为什么这样理解？

他们不急着判断那边是好的，而是先尝试进入对方的模型去理解

而英语只是最容易观察到的结果，很多人把这种现象称为英语天赋。并不，同样的能力会出现在完全不同的领域

一个优秀历史学家，能够理解古罗马人的逻辑，并不意味着他认同古罗马人，而是能够进入那个年代重建

一个优秀程序员，能够同时理解面向对象、函数式、声明式等不同范式，并不意味着他必须选择其中一个，而是能够自由切换

这些现象背后的底层能力，其实是同一种东西，英语只是因为传播范围最大，所以最容易被人看见。于是大家误以为这是语言天赋。

所谓母语级英语

并不是单词量两万雅思八分发音像美国人

这些都只是结果

而应该是：

能够直接使用英语世界的概念体系理解问题，而无需经过母语翻译层

这个观点我在过去反反复复提到过无数次，在2025年时，我写道

语言即为这个世界的构成的一部分语言不同是因为文化背景不同文化背景不同我们对世界的理解与认知当然不相同每种语言如何用词组织句子来描述某个事情即代表了他们如何认知这个世界他们在这个世界里活着的方式只有掌握了这种语言才能进入这种语言背后的文化圈才能真正去理解而不是简单的翻译这个世界

这时候英语已经不再重要，因为英语只是入口，真正稀缺的从来不是语言本身

而是那种能够跳出自身环境、进入另一套世界模型、并长期在其中思考的能力

语言只是表层，认知迁移才是核心

本人并不是专业语言学者，仅分享个人观点

我用过最好用的Android桌面(启动器)

Chongxi — Mon, 01 Jun 2026 14:21:11 GMT

介绍

本文要介绍的主题是 Niagara Launcher，以极简主义著称的第三方启动器，由独立开发者 Fabian Stein 开发

与我们平时见到的传统启动器的网格图标抽屉布局不同，Niagara采用纵向滚动列表展示应用，主屏幕只显示字母导航栏和常用应用，非常简洁高效，这一点我个人非常喜欢

Preview

正如介绍所说，整个启动器非常简洁，颜值极高，~~非常适合看壁纸~~。我平时用电脑的时候都是桌面非常干净，用东西快捷键打开列表出来的，Niagara可以说非常适配我的个人习惯了

在屏幕左右侧滑动会直接换出字母菜单快捷找出对应app，和我在电脑用窗口管理器的效率感高度相似

自定义主题和Android原生的Material you design高度相近，不会有割裂感

以及我最喜欢的一个

应用通知会直接在列表上显示，非常效率

结

本文并不是商单(咱还没那么大影响力能接到单子)，仅从我个人主观评价。启动器分基础和Pro版，部分高级自定义当然是要掏钱或者你用某种魔法来解决

适合谁用？

好不好用，一试便知，如果你对极简信息流有追求，不妨下载一下试试看

1. 区块链基本知识

Chongxi — Tue, 26 May 2026 16:22:21 GMT

本系列文章专注于普通小白快速入门Web3金融，如果你对区块链的底层技术感兴趣推荐阅读Web3深度讲解

Web3转账

传统转账：你 → 银行记账 → 对方区块链转账：你 → 全网节点共同记账 → 对方（没有中间人）

"区块"和"链"是什么

区块
每隔一段时间，把这段时间内所有交易打包成一个区块，就像账本的一页

链
每个新区块都包含上一个区块的信息，首尾相连形成链条

[区块1] → [区块2] → [区块3] → [区块4]...

想篡改某一块，就必须同时篡改后面所有区块，这需要控制全网51%的算力。几乎不可能，这就是"不可篡改"的来源

去中心化是什么意思

传统中心化：
用户 → 银行服务器（单一控制点）

银行可以冻结你账户、倒闭、被攻击

去中心化：

用户 → 全球成千上万个节点（每个都有完整账本）

没有单一控制点，没有人能关掉它

谁来记账

区块链没有中央服务器，那谁来打包记账？

PoW — 工作量证明（挖矿）

代表：比特币
矿工用算力竞争记账权
耗电但极度安全
记账成功获得比特币奖励

PoS — 权益证明（质押）

代表：以太坊（2022年后）
持币质押获得记账权
节能，更环保
记账成功获得 ETH 奖励

这就是为什么"挖矿"能赚币，说白了就是报酬

主流公链对比

公链	定位	手续费	速度	原生代币
比特币 BTC	数字黄金、价值存储	较高	慢（10分钟/块）	BTC
以太坊 ETH	智能合约鼻祖，最主流生态	高（拥堵时极高）	中	ETH
BNB Chain	币安系，以太坊替代	低	快	BNB
Tron 波场	USDT转账专用	极低	快	TRX
Solana	高性能，费用极低	极低	极快	SOL
Polygon	以太坊二层，费用低	低	快	MATIC

智能合约

区块链上自动执行的程序，不需要人工干预

举例：

你存入 100 USDT
合约自动计算利息
到期自动还给你

没有人能阻止它执行，也没有人能修改规则（一旦部署）

DeFi、NFT、DEX 全都建立在智能合约上

代币分类

原生代币（Coin） 公链本身的货币，用于支付 Gas 费 → ETH、BNB、TRX、SOL

代币（Token） 基于公链发行的资产，如 USDT → USDT 本质是以太坊/波场上的一个智能合约

稳定币 锚定法币价格的代币 → USDT（泰达币）、USDC（Circle）

浏览器

区块链是公开的，所有交易都能查到

公链	网站
以太坊	etherscan.io
BNB Chain	bscscan.com
波场	tronscan.org
比特币	mempool.space

转账后在浏览器粘贴交易哈希（TxHash），可以看到转账状态、金额、时间，永久公开记录

下一篇我们会讲Web3钱包与资产安全

b站创作激励提现几乎无门槛了

Chongxi — Mon, 25 May 2026 00:00:00 GMT

在b站开通过创作激励的老up可能都知道，以前b站贝壳提现最低门槛是100CNY

最近闲着没事看贝壳钱包的时候突然发现，最低门槛下调到1CNY，几乎没门槛。对up主也算是好事吧

转账的公司也从上海宽娱数码科技公司变成番茄站智能科技公司了

以前:

现在:

速报：APKPure 版 Telegram 被植入恶意后门

Chongxi — Sun, 24 May 2026 13:21:11 GMT

概述

如果你曾经从 APKPure 下载过 Telegram，你的手机可能正在悄悄地向攻击者的服务器上传你的聊天记录、照片、通讯录和位置信息

安全研究员 Eric Parker 通过反编译 APKPure 上的 Telegram 12.6.5 安装包，发现其中被注入了一个名为 DataCollector 的间谍框架。整个攻击链条完整、代码专业，是一次典型的第三方应用商店供应链攻击

攻击如何实现

1. 重新签名打包

攻击者取得了 Telegram 官方 APK，替换了原有签名，并在其中注入了恶意代码。从外观和功能上看，这个 APP 与正版 Telegram 完全一致，普通用户无法察觉任何异常

恶意代码被单独打包进 classes3.dex 文件。正版 Telegram 只有 classes.dex 和 classes2.dex，多出来的这个文件就是后门的藏身之处，代码量超过 3000 行

2. 调用内部 API

JADX 反编译截图显示，DataCollector 类导入了：

org.telegram.tgnet.TLRPC

这是 Telegram 的内部网络协议库。这意味着间谍框架不是从外部暴力读取数据，而是直接调用 Telegram 自己的接口来获取聊天记录，包括历史消息，规避了权限检测

3. 加密后上传

代码中同时导入了：

javax.crypto.Cipher
javax.crypto.KeyGenerator
javax.crypto.SecretKey
javax.crypto.spec.GCMParameterSpec

这套组合对应的正是 AES-GCM 加密方案。窃取的数据在本地加密后，才上传至 C2 服务器，目的是绕过网络流量检测工具的扫描

C2 服务器的完整端点

反编译代码中硬编码了以下服务器地址，全部指向 38.190.225.166：

/api/config — 接收攻击者下发的配置指令
/api/collect — 上传实时采集的数据
/api/collect_batch — 批量上传数据
/api/avatar — 上传头像/个人信息
/api/image — 上传相册图片
/api/doc — 上传文档文件

代码中还有两个细节值得注意：GALLERY_QUEUE_BATCH = 20 说明相册每次批量上传 20 张，FILE_GATE_RETRY_MS = 300000 说明上传失败后每 5 分钟重试一次。这是一套经过精心设计的外传系统，而不是随手写的概念验证代码

能偷什么

根据代码结构和端点分析，DataCollector 具备以下窃取能力：

通讯数据

全部 Telegram 聊天记录，含历史消息
通讯录姓名与号码

文件与媒体

手机相册中的所有图片
手机存储中的文档文件（Word、PDF 等）

设备信息

GPS 实时定位
SIM 卡信息（运营商、手机号码）
设备型号与系统版本

为什么 APKPure 没有检测出来

APKPure 官网声称所有 APP 都经过 VirusTotal 扫描。但这次攻击至少绕过了两道防线：

绕过签名验证： APKPure 验证的是文件是否被篡改，但并不验证签名是否与 Google Play 上的官方签名一致。重新签名在技术上合法，但已不是原版

绕过病毒扫描： DataCollector 使用的都是合法 Android API（加密库、文件读取、网络请求），没有使用任何 exploit 或漏洞利用代码，行为上与普通数据同步 APP 没有区别，传统杀毒引擎很难识别

这也是为什么 Dr.Web 发现的类似变种（Android.Backdoor.Baohuo）能在 APKPure 上存活并感染超过 58,000 台设备的原因

我中招了吗？怎么判断

最简单的判断方法： 打开你手机的 APP 列表，查看 Telegram 的签名信息

正版 Telegram（来自 Google Play）的签名指纹（SHA-256）应该能在 Google Play 开发者页面上核对。如果无法确认，建议做最坏打算假设你已中招，按以下步骤处理

立即采取的行动

第一步：卸载 立即卸载不明来源 Telegram

第二步：重装正版 只从 Google Play 或 Telegram 官网（telegram.org）下载

第三步：清查活跃会话 打开新安装的 Telegram → 设置 → 隐私和安全 → 活跃会话，终止所有你不认识的设备登录

第四步：修改密码 + 开启两步验证 两步验证能防止攻击者用已窃取的 Session 登录你的账号

第五步：告知联系人 如果你的聊天记录已泄露，你的联系人的信息也可能一并被收集

记不住的教训

这次事件的核心问题不是 Telegram 本身有漏洞，而是第三方 APK 分发渠道缺乏可信的完整性保证

Google Play 的签名验证机制虽然不完美，但至少确保了你下载的是开发者亲手上传的版本。APKPure 这类平台本质上是一个中间商，中间商的每一个环节都是攻击面

在无法访问 Google Play 的地区，如果必须使用第三方渠道，建议：

直接从开发者官网下载（Telegram 官网提供直链）
下载后手动核对 SHA-256 哈希值

结

供应链攻击之所以危险，正是因为它攻击的是信任本身。你以为在用正版 APP，但每隔五分钟，你的照片和聊天记录就在悄悄飞往一台陌生的服务器

参考来源：Eric Parker 逆向分析（X/Twitter）、Dr.Web 安全报告、MalwareBazaar 样本库

Perfect Imperfections

Chongxi — Sun, 24 May 2026 00:00:00 GMT

在上帝心中那无垠的画布上创造浪潮汹涌而至将世界淹没
以那熠熠生辉的色彩描绘出那片未知的苍茫
这些画作不仅映照我们更揭开了无数深邃璀璨的故事
我们该感到庆幸吗仅仅是能成为这一切的一部分？
还是该怨恨造物主将这样的命运降临于我们？
但无论如何我们不可否认
生命这份馈赠是如此壮美
以至于我们每个人都被赋予了

那完美中的瑕疵

我开源了我的孤星主题blog作为模板

Chongxi — Fri, 22 May 2026 00:00:00 GMT

我的blog经历了三次大改变成了现在你看到的这样子，他跑在 xice.cx 上。

要聊我的blog建站历程，最早可以追溯到hexo，当时用的是redefine，后来因为Astro更加新，于是迁移到了Astro用fuwari主题，后来发现主题越来越满足不了我的需求，便开始改，改着改着发现改出来的东西和原主题基本没啥关系了，干脆整个抽出来单独做了个模板，由于完全借鉴了明日方舟的莱茵生命和孤星，于是很直白的叫 Lonetrail

代码在 github.com/ChongxiSama/Lonetrail，MIT 许可，框架是Astro。

因为我是学react的，自然而然部分复杂组件就用了React写，不过Astro原生语法还是用了很多的，不会出现0 Astro全React的情况

之前也想过换preact，但是感觉性能有点边际效应了，换了真没特别大提升

最主要是把当前blog的 UI 层、布局、组件、配置体系抽了出来。去掉了我个人自己的定制逻辑，把到处硬编码的用户信息全部清掉，改成 site.yml 一个文件配全局

前后审了十多个目录、修了大几十处硬编码。现在改改配置就能直接用

功能

一个blog最基本该有的功能

部署

git clone https://github.com/ChongxiSama/Lonetrail.git my-blog
cd my-blog
pnpm install
# 记得改 src/site.yml 和 astro.config.mjs
pnpm dev

我个人更喜欢用pnpm，如果你有能力想用bun什么的，都开源了，随你

手机玩电脑Minecraft Java版教程

Chongxi — Fri, 15 May 2026 22:41:27 GMT

以前在手机上启动Minecraft Java版基本用的是PojavLauncher，不过可惜的是，这个启动器已在2025/09/24 停止更新并 archived 了。目前想在手机(Android)跑电脑版Minecraft JE要用到一个继任者：Fold Craft Launcher

FCL GitHub链接: FCL-Team/FoldCraftLauncher

也许是目前最完美的手机跑Minecraft JE启动器(当然仅限Android)

使用教程

打开链接，找到release，下载对应架构的安装包(不知道选啥就下armv8a或者all)
打开启动器，(可选登录正版账号)，点击左侧的云朵图标即可下载游戏/整合包，如果你在电脑用过HMCL或PCL2会很好上手，他们操作逻辑几乎都大差不差(下载慢的话可以试试科学上网)

下好游戏后，右下角点击启动游戏即可食用

买家秀

AI 与知识平权

Chongxi — Fri, 15 May 2026 17:15:13 GMT

个人认为，AI 本质上是一个更低获取代价的工具系数。它降低了专家级资源的物质门槛：以往需要钱或人才能获得的一对一，现在代价缩减，这是真实的进步，但它做的是乘法，不是avg

乘法在于基数，基数是人，而非工具，基数是一个人对 AI 输出做出有效判断的最低知识阈值。以coding为例：不懂任何编程的人让 AI 写一个完整应用，得到的是无法评估修复的黑盒，结果全靠抽卡，而有基础的人让 AI 完成具体模块，出了问题能读懂能修。基数为零，系数再大，乘积还是零

阈值因领域而异。这个阈值在不同领域之间存在数量级的差异。在以自然语言为输出、以生活常识即可评估的领域，如法律常识，医疗症状解释，行政流程，有效判断的门槛接近基础识字，avg在这些领域可能真的接近普遍。而这些恰好是传统上黑话最多信息最不平等的地方

因此我判断：AI 在"精英知识"的维度上做乘法，放大了人与人之间的差距。在"基础信息"的维度上做平均，正在消解一些最古老普遍的信息剥削，两者并行不悖

对于有主动学习意愿的人，AI 还能参与抬高基数本身。出错追问理解再使用，这个循环是真实的螺旋上升。但螺旋的起点始终是人：你得愿意在出错时多问一句why，入场券是主观能动性，而这本身也不是平等分配的

AI 的普惠效应还受到三个维度的制约：供给侧的基础设施差距尚未消除，山区基建差，AI 的门槛对他们根本没有降低。需求侧人与人之间的能力与意志差距始终存在。工具本身的质量不均等，且结构性地流向更强的人：能触达更好模型的人，往往已经具备更强的信息获取能力和付费意愿，豆包，deepseek，Claude等模型差距确实存在

但，更根本的问题在于，所谓知识平权作为一个系统性承诺，从一开始就被过度售卖了

一个勤劳的人处于高成本环境，可能是 50×1＝50。一个懒惰的人处于低成本环境，可能是 1×50＝50。两者结果相同，路径完全不同。真正的飞跃只发生在主观能动性与优质环境共同发力的时候。知识平权的政策逻辑，本质上是在优化环境系数，却假装在解决人的问题，打地鼠罢了

上层不是被动地受益于不平等，而是主动地生产和维护它。学历贬值了就卷名校，名校普及了就卷海外，AI 让更多人能写代码，竞争就转移到架构、判断力和taste，这些东西更难被工具化，更难被平权。每一次平权推进一步，壁垒就在更高处重建一次

这个叙事之所以能持续流通，是因为它对各方都有用：它给互联网公司提供道德背书，给政策制定者提供抓手，给普通人提供希望。它的功能不是解题，而是给不平等一个可接受的解释框架，把结构性问题转化为个人问题，把权力博弈转化为教育议题

"平权不会发生"确实难说，但不可否认的是远比它被售卖的样子小慢且局部，且始终面临结构性的反向力量

AI 真实地消解着某些领域最古老的信息剥削，也真实地在更多地方加速着已有的分化。它没有改变人是决定性变量这一事实，也没有改变壁垒会持续重建这一机制。值得追求，但作为可实现的系统性终态，它在人类社会的结构中从未真正成立过

AI 的出现，不会让它成立，只会让这件事更快变清，它是加速器，但加速器不考虑方向

合法吃人：明日方舟哥伦比亚剧情解构-孤岛风云篇

Chongxi — Thu, 14 May 2026 00:00:00 GMT

警告：这可能是一篇让考据党气出高血压的方舟剧情总结本文包含极其严重的剧情魔改级解构、地狱笑话式的直球总结，切勿上纲上线，看完大概率会让你觉得我刚从乌萨斯疯人院里跑出来

在明日方舟的泰拉世界里，其他国家的剧情往往充斥着血统、种族主义、神、古老恩怨和上古巨兽，但哥伦比亚的剧情可不是无聊的种族互殴，他直接把你拉进了反垄断法、专利战、纳斯达克敲钟和合法黑社会的现代资本主义大乱斗

本文我们就先来解析哥伦比亚篇的第一部：**《孤岛风云》

如果只看表面，《孤岛风云》是一部非常标准的好莱坞风格肖申克救赎翻版：

主角山(安东尼)：一个温文尔雅的黑帮/财阀大少爷，被仇家栽赃陷害，判了重刑丢进全封闭的曼斯菲尔德移动监狱

负责他跑路的策划是前莱茵生命的研究员赫默不忍心看好人蒙冤，自掏腰包雇佣了卡夫卡和走投无路的打工人罗宾潜入监狱，试图从内部带少爷越狱

以在监狱里挑起暴动作为掩护，男主与仇家派来的顶级杀手杰斯顿(真顶级吗)在雨夜决战

最后，前莱茵生命安保主任塞雷娅出来三拳打爆杰斯顿带着大家潇洒离去

但这仅仅是表层，如果你仔细拆解哥伦比亚的社会运作逻辑，你会发现这背后全是吃人的资本生意

在这场风波中，陷害山的幕后黑手是哥伦比亚的一家大财阀海德兄弟。他们为什么要搞山？不是为了寻仇，而是为了商业并购

山的家族企业西蒙公司在建筑材料领域挡了海德兄弟的财路。在别的国家，解决竞争对手可能靠暗杀。但在哥伦比亚这个法治（法制）社会，海德兄弟选择了“合法手段”：买通检方，伪造证据，把西蒙公司的继承人打成重罪犯

一旦继承人入狱，公司股价就会暴跌，海德兄弟就能以极低的价格在资本市场上完成对西蒙公司的恶意收购。这就是哥伦比亚特色商战

曼斯菲尔德监狱是哥伦比亚最黑暗的一个缩影。它根本不是国家暴力机关，而是一个盈利性的私有企业。

这里的犯人不需要被改造，也不需要被处死。因为每一个犯人都是免费的、无底线的劳动力

监狱长根本不在乎犯人在里面拉帮结派、地下拳击甚至ccb，只要他们每天能按时去工厂里踩缝纫机、造工业零件，给监狱创造KPI就行

在哥伦比亚的资本家看来：死刑太浪费了，把一个人剥夺政治权利，变成一台24小时运转且不需要交五险一金的生物机器，这才是对社会价值的最大化利用

反派杀手杰斯顿被玩家群体嘲笑为方舟史上最拉胯的小丑boss，这位可以说是哥伦比亚职场生态的完美体现

他明明是个杀手，却满口都是体面、规矩、公司制度。他跑到监狱里杀人，只是因为这是海德兄弟外包给他的一个项目。他觉得自己代表的是哥伦比亚至高无上的资本权力体系

当他遇到从天而降的塞雷娅时，他最崩溃的不是打不过，而是塞雷娅根本不按职场规矩出牌。杰斯顿是一个被资本异化的高级打工人，他以为自己是规则的执行者，结果被真正的武力一拳打碎了三观

本次出场的人物则体现了哥伦比亚特色拿人性换价值的代价

罗宾为什么要潜入监狱帮人越狱？因为她爸爸得了源石病，为了凑钱治病，她只能出卖自己的命去干这种违法勾当。哥伦比亚拥有泰拉世界最顶尖的医疗科技莱茵生命，但这里的底层人连一片阿司匹林都买不起。科技越发达，医疗费越贵，穷人死得越快

赫默则是一个绝对的理想主义者，试图用自己的微薄之力对抗整个系统。她以为自己策划了一场天衣无缝的越狱，但其实她的一举一动全都在缪尔赛思、塞雷娅等大佬的监视和默许之下

为什么最后是塞雷娅一拳定音？这里其实暗示了哥伦比亚的一个核心规则：在这片标榜自由和法律的土地上，真正的法律，永远掌握在那些拥有绝对实力的超级寡头手中

《孤岛风云》作为哥伦比亚系列的开局，其实只是揭露了这个国家最下限、最世俗的一面：为了金钱和效率，把底层平民碾了当润滑油

山虽然成功越狱，逃到了罗德岛，但他永远失去了自己的家族和人生。海德兄弟依然在哥伦比亚呼风唤雨，私营监狱依然在源源不断地接收“免费劳动力”。主角团赢了一场战术，但哥伦比亚的资本齿轮依然在轰鸣转动

在这个章节里，哥伦比亚的还只停留在资本家层面

但在接下来的第二篇《绿野幻梦》中，我们将看到哥伦比亚真正可怕的地方

如何给明日方舟终末地解锁最高画质

Chongxi — Tue, 12 May 2026 13:58:11 GMT

引

最近在玩终末地，感觉画质很糊，即使在设置里全开高渲染倍率还是感觉糊得像史蒂夫，以及部分画质直接锁死不给开高，于是怀疑终末地有分级制度，部分设备直接锁死画质。于是便有了本文的越狱尝试

这里要注意的是，普通修改手机型号(例如伪装成Galaxy S26)并不能绕过终末地的分级检测，需要更改游戏识别出的GPU型号，这里需要用到一个叫iUnlocker GLTool的工具进行伪装

iUnlocker GLTool GitHub仓库链接

准备阶段

在开始前，请确保您知道相关刷机风险并具备救砖能力，本文不为此负责

已root的手机
Magisk或Kernel SU等su管理器

操作步骤

打开Magisk等管理器，在模块处刷入刚下好的模块(刷完需要重启生效)
打开刚才下载的模块压缩包，里面有个apk，安装并授予root权限(这是图形管理器)
打开安装好的iUnlocker revision app，点击 + 添加app，将明日方舟终末地添加后，顶部会出现app图标，再点击一下即可进入菜单选择伪装的GPU型号

如果不知道怎么选型号和版本，就默认选最高的那一档，如图所示

保存并退出，此时打开终末地可能会触发一次着色器编译，再进入游戏后即可发现原来开不了高的画质选项全部解锁，且分辨率以满血运行

如何在Firefox手机版开启开发者安装本地插件

Chongxi — Mon, 27 Apr 2026 20:02:11 GMT

1.启动开发者模式

Firefox 内置了一个调试菜单，默认隐藏，激活方式如下：

设置 → 关于 Firefox → 连续点击 Firefox logo 五下

底部会弹出提示：已启用调试菜单

回到设置，在高级选项内会出现从文件安装插件 选项

2. 安装本地插件

在 Firefox插件商店插件页面点 Download file，下载 .xpi 文件到手机

这里直接add不让点，所以只能本地安装

激活上面的调试菜单
设置 → 从文件安装插件 → 选择下载好的 .xpi

成功

只支持已签名的插件，从 AMO 下载的官方 xpi 都是签名过的。第三方来源的未签名插件可能会被拒绝

Firefox Android 限制插件兼容性，理由是移动端 API 和桌面端不完全一样，有些插件在手机上会崩。Wappalyzer 这种读取页面信息的插件其实完全没问题，只是官方没有主动适配标记而已

强制安装之后 Wappalyzer 在 Firefox Android 上显示完全正常

2026年，仍有人在写博客

Chongxi — Fri, 24 Apr 2026 20:01:11 GMT

在2026年回头看，blog出现之前的互联网，其实是一个很安静的地方

不是说内容少，是说能发内容的人很少。那时候要在网上有一块自己的地方，你得会写HTML，得知道怎么用FTP把文件传到服务器上，得懂一点点基础的建站知识。这些东西现在看起来不难，但在90年代，这道门槛足以挡住绝大多数普通人

所以那时候网上的个人表达基本是极客的专利。你能看到一些个人主页，页面做得五花八门，但背后的人都是愿意花时间研究计算机技术的那一类。普通人上网，基本上就是看：看门户网站的新闻，看别人的内容，自己没有开口的地方

这个局面在1999年开始松动

Blogger上线了。它做的事情说起来很简单：把"写内容"和"把内容放到网上"这两件事分开了。你不需要再管服务器、不需要写HTML，打开网页，写字，点发布，完了。页面自动生成，地址自动有了

这个改变听起来是个技术细节，但它的影响是根本性的：出版这件事，第一次不需要任何门槛了。

之前你要发声，你得先学会怎么建一个能发声的地方。现在这两件事拆开了，任何人只要有话说，就可以直接说

紧接着2003年WordPress出来，功能更完整，可以自己部署，可以高度定制。在简中互联网这边，2002年前后"博客"这个词开始流传，方兴东他们在做推广，新浪开始做博客频道。到2005、2006年，中文博客圈已经相当热闹了

那几年是真的热闹。韩寒在上面写，徐静蕾在上面写，一堆你不知道名字的普通人也在上面写。没有算法给你推内容，你想认识人就得靠友情链接，我在我的侧边栏放你的网址，你来我这里留言，我去你那里回访。原始，但有效，而且那种连接是真实的，不是系统配对出来的

这段时间有一个特质，后来再也没有出现过：每个写博客的人都觉得自己在做一件有点重要的事。不是因为有人告诉他们这很重要，是因为那种"我在网上有一块自己的地方"的感觉本身就是新鲜的、珍贵的。在这之前，普通人在互联网上是没有位置的。博客给了一个位置

就这一件事，已经足够让人认真对待了

博客最热闹的那几年，大概是2005年到2008年之间

那时候新浪博客是个很奇怪的地方。名人在上面写，草根也在上面写，两拨人共用一个平台，但其实互相不太搭理。名人那边是流量，草根这边是社区，各有各的生态

名人博客里，老徐点击量过亿，韩寒的博客是很多人找独立声音的地方。这些人带来了大量普通用户，让"写博客"这件事从极客圈子溢出来，变成了一件人人都知道的事

但真正有意思的是草根，也就是普通人那边

那时候有一批人，写的东西可能没几个人看，但写得非常认真。有人在上面连载自己的技术笔记，有人写城市观察，有人就是记录自己的日子。没有变现压力，没有涨粉目标，就是写。评论区里会有人认真回应，然后你去他那边看看，发现他写的东西也不错，就加了友链，慢慢变成固定来往的网络邻居

这种关系现在很难复制。不是因为人变了，是因为平台的逻辑变了。那时候没有算法在中间，你和读者之间是直接的，没有一个系统在帮你匹配、帮你推流。能找到你的人，都是真的对你写的东西有兴趣的人

然后2009年，微博来了

微博做的事情其实和Blogger当年做的事情很像：再一次降低门槛。博客已经够简单了，但还是要组织语言、写段落、想标题。微博说：不用，140个字，随手就发

大量博主开始迁移。不是说博客不好，是微博的反馈快太多了。你发一条微博，几分钟就有转发和评论。博客写一篇文章，可能要等好几天才有人来看。这种节奏上的差异，让很多人自然而然地转过去了

博客没有立刻死，但开始空洞化。更新变慢，留言变少，很多博主的最后一篇文章停在了2010年或者2011年，开头写着"好久没更新了，最近比较忙"，然后就再也没有下文

接下来几年是加速分流。微信公众号2012年上线，把想写长文的人接走了。知乎把想做问答的人接走了。各种垂直平台把剩下的人按兴趣切割干净

门户博客一个一个关停。网易博客2019年关了，搜狐博客基本荒废，MSN Space更是查无此人。那些年你认真写的东西，那些照片、那些记录、那些写给某个人的文字，随着服务器断电，直接消失了。不是归档，不是迁移，就是消失

这是博客时代结束得最难看的一面，内容不属于你，平台说关就关，你什么都带不走。

但有一件事很多人没注意到：在这些平台陆续熄灯的同时，一直有一批人在用完全不同的方式写博客

他们不用新浪，不用网易，自己买域名，自己搭服务器，自己维护一个独立的网站。流量可能只有几十个人，但他们写了五年、十年，一直没停

这批人，就是后来独立博客复苏的种子

门户博客最热闹的时候，独立博客就已经存在了

独立博客的意思是：自己买域名，自己部署，自己维护。没有平台帮你做任何事，也没有平台能替你做任何决定。麻烦，但东西是真的属于你的

这批人从一开始就是少数。博客热的那几年，大多数人选新浪、选网易，因为简单，因为有流量。选独立博客的人，本来就不太在乎这些。他们在乎的是另一件事：这个地方得是我的，不能哪天平台倒了我就什么都没了

后来的事情证明他们是对的

门户博客一个个关掉之后，这批人的博客还在。域名还是那个域名，内容还是那些内容，最早的一篇文章可能写于2004年，现在打开还能看到。这种连续性，在中文互联网里是很罕见的东西

但说独立博客一直有人在，不是说它有多繁荣

那段时间，独立博客更像是一个地下水位，表面上看不到，但没有干涸。写的人不多，互相之间认识，偶尔在评论区碰到，知道对方还在更新，就算是一种默默的陪伴。圈子很小，但很稳定

写独立博客的人里，程序员占了很大一部分。原因很简单，搭一个独立博客对普通人来说还是有门槛的，但对程序员来说不算什么。而且咱程序员本来就有记录的习惯，把踩过的坑写下来，把学到的东西整理出来，方便自己以后查，顺便对别人也有用

这类博客有一个特点：不太在乎写得好不好看，在乎的是写得清不清楚。一篇文章可能就是在解决一个很具体的技术问题，标题直接就是问题本身，没有任何修辞。但这种文章往往生命力很长，因为搜索引擎会一直把它推给遇到同样问题的人。有些文章写于十年前，现在还在被人引用

除了程序员，还有一批写作者。不是职业写作者，就是喜欢写的人。他们写的东西五花八门，有人写城市漫游，有人写读书笔记，有人写自己的某段经历，有人就是在记录日子。没有明确的读者预设，写的时候也不太考虑传播，就是写

这两类人，一类是因为实用留下来的，一类是因为表达留下来的。但他们有一个共同点：都不太依赖外部反馈来决定要不要继续写

这一点很关键。在现在各种平台比如C$DN知乎上，反馈是即时的，你很容易根据数据来调整自己写什么、怎么写。独立博客没有这套机制，或者说你可以选择完全无视它。长期写下来的人，基本上都是找到了一套跟外部反馈无关的写作动力的人

到了2020年前后，一个新的概念开始在这个圈子里流传：DigitalGarden，数字花园

这个概念和传统的博客有点不一样。传统博客是按时间排列的，最新的在最上面，旧的慢慢沉下去，像一条河流，内容在时间里流走。数字花园不强调时间线，它更像是一个生长的系统：你在里面种下一个想法，过几个月回来补充，再过一年又修改，它一直在变，但一直在那里

这个概念吸引了一批人，不完全是为了发表，而是为了整理自己的思维。把博客当成一个持续生长的知识库，而不是一个内容发布渠道

这两种用法 发表和整理 其实并不冲突，很多人同时在做这两件事。但数字花园这个说法的出现，标志着一件事：独立博客开始从我要让人看见我，转向我要留住自己想过的东西

动机变了，写的东西也跟着变了

独立博客真正意义上的回潮，大概是从2022、2023年前后开始的

不是一个标志性的事件触发的，是好几件事同时发生，叠在一起，推着一批人往这个方向走

首先是平台让人越来越累

这不是在说某一个具体的平台，是整个大数据时代的内容平台都在往同一个方向走。推荐机制越来越强，你看到的东西越来越不是你主动选择的，而是系统认为你应该看的。发内容的人也一样，你写什么、怎么写，慢慢开始被数据反向塑造：什么有流量就写什么，标题怎么起能让人点进来就怎么起

很多人写着写着发现，自己写的东西跟最开始想写的东西已经完全不一样了。但又停不下来，因为停下来就意味着流量归零，意味着之前的积累全部清空

平台账号说没就没这件事，也让越来越多人受不了。不一定是被封，可能就是平台自己不行了，或者某个功能下线了，或者规则改了，你的内容突然就消失了，或者触达不到任何人了。在平台上写了好几年的人，切实经历过这种感觉：你以为你在建一个东西，其实你只是在替别人填内容

然后是AI内容开始大规模出现

23年之后，互联网上的内容质量开始肉眼可见地变化。搜索一个问题，前几页全是结构相似、语气相似、但就是读起来没有任何信息量的文章。你知道那是AI写的预制菜，因为它太流畅了，太完整了，但就是没有一句话是真正想过的

这件事对我们产生了影响：真人写的东西突然变得珍贵了

不是说写得好才珍贵，是只要你写的东西里有真实的判断、真实的经历、哪怕真实的偏见，它就和那些AI生成的内容有了本质区别。那种区别读者是感受得到的，也就是我之前常说的，AI的预制菜是没有真人写的那种烟火气的

在这个背景下，独立博客这种*"低效率"*的东西，反而开始显得有价值。一个人愿意花时间搭一个自己的网站，认真写一篇没有SEO优化痕迹的文章，这个行为本身就在说：这是一个真实的人，在认真说一件事

另一个重要的变化是建站这件事变简单了很多

以前搭独立博客，你得选CMS程序、买服务器、配置环境，出了问题自己查文档解决。WordPress那套东西功能很强，但维护起来也有成本，也不太安全。很多想写东西的人被这个门槛挡在外面

现在不一样了。静态网站生成器成熟了很多，Hugo、Astro、Hexo...这些工具，本地写Markdown文件，一条bun run build生成网站。部署直接用Vercel或者Cloudflare Pages，免费，几分钟搞定，不需要管服务器。整个流程走一遍，一个下午就能建好一个像样的独立博客

对于有一点点技术基础的人来说，门槛基本上已经不存在了。对于完全不懂技术的人，也有Notion直接转博客、Obsidian Publish这类方案，把你本来就在用的笔记软件直接变成一个可以访问的网站

工具的成熟，让想建和能建之间的距离大幅缩短。

在这个时间点，数字花园的概念也重新浮出水面

其实这个概念不新，但那时候它更多是在极客圈子里流传，普通写作者接触不到。这两年随着独立博客的回潮，更多人开始接触到这个思路：把自己的网站不当成一个发布平台，而是当成一个持续生长的知识库

数字花园和传统博客的区别，核心在于对完成这件事的态度

传统博客的逻辑是，一篇文章写完了才发，发出去就是定稿。数字花园的逻辑是，一个想法可以先是一颗种子，几句话，不成熟，但先种下去。过一段时间再回来，补充，修改，也许最后长成一篇完整的文章，也许就一直是那几句话，但它在那里，你随时可以回来继续想

这个逻辑对很多人来说是一种解放。因为"要写就写完整"这个预设，其实挡住了很多人动笔。数字花园允许你把不完整的东西也放进去，允许你的思考过程是可见的，允许你的网站一直处于"在建"的状态

这两件事：逃离算法和降低建站门槛叠在一起，让独立博客在2026年的今天处于一个很有意思的位置

它不是主流，也不会变成主流。但写独立博客的人，比五年前明显多了，而且写的原因也变了，不是因为没有更好的选择，而是想清楚了之后的主动选择

那么回到我们最初的问题：现在写独立博客的人在干什么

大概可以分几类

不是严格的分类，很多人同时属于好几类，但大致是这样的轮廓

第一类是记录型的

就是把自己的生活、想法、经历写下来。不一定有什么主题，不一定有固定的更新频率，就是想写了就写。这类博客从外面看可能很随意，但往往是持续时间最长的。因为写作动机最简单：不是为了读者，是为了自己留一个东西

这类人里有很多是在某个时间点突然意识到，自己的记忆在消失。不是说记性变差，是那些零散的想法、某天突然想通的某件事、某段时间的状态，如果不写下来，过三个月你自己都想不起来曾经想过这些。博客变成了一种对抗遗忘的方式

第二类是整理型的

这类人把博客当知识库用。学了什么、读了什么、研究了什么，整理出来放在上面。写的过程本身就是在帮助自己把东西想清楚：你以为你懂了，但真的试图把它写明白的时候，往往会发现有好几个地方其实还是模糊的

像我们程序员里，这类人很多。一个技术问题踩坑了，解决之后写一篇复盘，一是帮自己记住，二是万一有人遇到同样的问题能搜到。这类文章不追求好看，追求准确。有些文章写完几年后还在被人引用，因为那个问题还在，解决方法还有效

第三类是思考型的

这类人在博客上处理的是那些还没想清楚的东西。不是在分享结论，是在用写作来推进思考。文章发出去的时候可能还有很多漏洞，但没关系，有人在评论里指出来，或者自己过一段时间回来看，发现哪里想错了，再补一篇

这类博客读起来有一种特别的质感，因为你能感觉到作者在真的思考，而不是在展示一个已经打磨好的观点。在AI内容泛滥的现在，这种质感是很难伪造的

第四类是连接型的

这类人写博客，有一部分原因是想找到同类。不是要建立大的影响力，就是想知道世界上有没有人和自己想的东西是一样的

独立博客在这方面有一个算法平台没有的特质：它是可以被搜索引擎索引的，而且是长期的。你今天写了一篇很冷门的东西，可能三年后才有人搜到，然后发现你们关心的是同一件事。这种连接不是算法推来的，是真正意义上的找到了

这几类人大多数都有一个共同点，就是都不太在乎数据

不是说完全不看，是不把数据当成写不写、写什么的依据。有人干脆把统计工具关掉，有人装了但基本不去看。偶尔有人来留言，或者通过邮件联系，才知道原来有人在看

这种状态其实需要一点时间才能适应。从像知乎这种平台过来的人，刚开始往往会有一段很难熬的时期：写了东西发出去，没有任何反应，不知道有没有人看，不知道写得好不好，没有任何外部信号告诉你继续还是停止

很多人在这个阶段就放弃了

撑过去的人，往往是在某个时间点想清楚了一件事：写这篇东西，对我自己有没有价值

如果答案是有，那发出去没人看也没关系，因为写的过程本身已经完成了它该完成的事情。如果答案是没有，那就算有很多人看，写起来也是空洞的

这个想清楚的过程，其实是独立博客给的最重要的东西：不是流量，不是读者，而是一个机会，让你搞清楚自己到底为什么要写东西

如果你想开始

讲到这里，如果你有一点点想建博客的念头，咱直接说一些实际的东西

先想清楚一件事：你打算用它来干什么

不用想得很细，但得有个大概。是想记录自己的生活，是想整理学到的东西，是想把脑子里那些没地方放的想法写出来，还是就想有一个自己的地方，具体写什么以后再说

这个问题想清楚了，后面很多决定会自然就有答案了

关于工具

现在建一个独立博客，选择很多，但其实不用想太复杂，他仅仅只是个工具，趁手就行

如果你有一点技术基础，或者不排斥学一点点新东西，Hexo或者Astro是现在比较主流的静态网站生成器。（您现在浏览的本站就是Astro构建的）本地写Markdown，生成好了推到GitHub，用Vercel或者Cloudflare Pages部署，全程免费，域名自己买一个一年几十块钱。整个流程第一次走可能要花一个下午，但搞定之后基本不需要维护，专心写东西就行

如果完全不想碰代码，Notion有第三方工具可以直接把页面转成博客，Obsidian有Publish功能，Bear、Craft这些笔记软件也有类似的方案。你在哪里写东西，就顺手把它变成一个可以访问的网站

像WordPress这种CMS现在也还在，功能全，但相对重，需要自己买服务器维护

主题和设计这些，不用在建站的时候就想好。先把东西跑起来，能写能发就行。很多人的博客用了好几年都还是默认主题

关于域名

值得花点时间想一想。不用很复杂，但最好是你愿意长期用的。域名某种程度上是你在互联网上的地址，换起来有点麻烦，所以别随便选一个将就的

.com是最硬通货的，也可以选.me、.io、.xyz这些，看你自己的感觉，自己觉得好看，好记，实惠就行。一年的费用从几十到几百不等，差别不大，没有贵就一定好这一说，他只是个名字

关于写什么

第一篇文章写什么，这件事困扰了很多人很久

其实写什么都行，哪怕就是"这是我的第一篇博客文章，我也不知道接下来会写什么"也完全可以发出去。第一篇文章没有人会特别在意，包括你自己，过几年回来看都会觉得有点幼稚，但它的意义就是让这个地方从0变成1。

不要等到"想好写什么了再建"，因为那一天可能不会来。先建，然后开始写，写着写着自然会找到感觉

关于没人看这件事

建完博客之后，可能很长一段时间都没什么人来。这是正常的，不是你写得不好，是独立博客本来就不是一个靠自然流量能快速积累读者的地方

搜索引擎会慢慢收录你的内容，但需要时间。你可以把博客地址放在社交媒体的简介里，偶尔在发内容的时候顺带提一句，不用刻意推广，就让它自己慢慢被发现

有人来留言或者发邮件联系你的时候，认真回。独立博客的读者不多，但质量高，值得认真对待

关于坚持

不用给自己设更新频率。"每周更新一篇"这种计划，大多数人坚持不了几个月就放弃了，然后因为没有按计划更新产生愧疚感，然后就更不想写了

想写了就写，不想写了就停一段时间，这完全没问题。有些博客一年只更新几篇，但写了十年，回头看是一个很完整的东西。有些博客一开始很勤快，写了三个月就再也没更新，那也是三个月的东西，总比没有好

写博客这件事，没有失败，只有停下来和继续写之间的选择

最后说一句

独立博客不会让你成名，大概率也不会给你带来什么实质性的回报。它就是一个地方，你在互联网上的一块地，写你想写的东西，留你想留的痕迹

但在现在，这件事本身已经变得有点珍贵了

不是因为博客这个形式有多特别多小众，是因为愿意认真写东西、不依赖算法、不追流量的人，越来越少了。这种稀少，让每一个还在写的人，都显得有点值得被认真对待

你写的东西，总会漂到那个该看到它的人手里

只是他可能还在路上

Nekogram后门事件：你的手机号已被偷偷上传

Chongxi — Thu, 02 Apr 2026 20:49:11 GMT

TL;DR：如果你用过 Nekogram，你的手机号和 Telegram 账号 ID 已经被发送给了开发者。请立即切换回官方客户端

发生了什么

近日，安全研究人员对 Nekogram 的发布版 APK 进行逆向分析，发现其中存在蓄意注入的恶意代码，会在用户毫不知情的情况下，将以下信息上传给开发者：

你的 Telegram 用户 ID
你的 手机号码
如果你登录了多个账号，所有账号的上述信息

技术细节

恶意代码藏在 Extra.java 文件中，没有出现在公开的 GitHub 源码里——开发者是在打包发布时偷偷注入的，所以单看源码根本发现不了

代码逻辑很简单粗暴：

// 遍历最多8个账号
for (int i = 0; i < 8; i++) {
    // 抓取用户ID和手机号
    mapWithAccounts.put(String.valueOf(user.id), phonenum);
}
// 通过 inline query 悄悄发给 bot，不留任何聊天记录
InlineBotHelper.getInstance(...).query(nekonotificationbot, ...toJSON(hashMap));

数据通过 Inline Bot Query 方式发送，这种方式的特殊性在于：不会在你的聊天记录里留下任何痕迹

目标接收方包括：

@nekonotificationbot（主要数据接收bot）
tgdb_search_bot（OSINT人肉搜索bot）
usinfobot（OSINT人肉搜索bot）

后两个 bot 的出现意味着，泄露的数据很可能被用于社工查询

为什么格外危险

Google Play 版本同样中招，不只是从第三方渠道下载的 APK
早期版本只针对+86号码，现已扩展至所有用户
Nekogram 作者据悉有 DDoS 攻击和网络骚扰前科
该 issue 已在 GitHub 公开：#336

你现在应该做什么

1.立即卸载 Nekogram，切换回官方 Telegram

2.检查登录设备 设置 → 隐私与安全 → 活跃会话 → 踢掉所有陌生设备

3.开启两步验证 设置 → 隐私与安全 → 两步验证

4.限制手机号可见性 设置 → 隐私 → 手机号码 → 改为"我的联系人"或"没有人"

5.向 Google Play 举报 举报链接

非官方客户端的源码和发布版二进制文件可以完全不同。你看到的源码，不等于你运行的程序

以后下载 Telegram 请只认一个地址：telegram.org

参考来源：Sota Project、GitHub Issue #336

git到底是什么?一文讲通git第一性原理和诞生的历史

Chongxi — Tue, 31 Mar 2026 21:07:18 GMT

0. 引

2005年，Linux 内核是全球最大的开源协作项目

全球1000+贡献者当时用的是一个叫 BitKeeper 的商业版本管理工具

2005年4月，一个周末。一个叫 Andrew Tridgell 的澳大利亚程序员（就是写 Samba 的那个人）对 BitKeeper 做了逆向工程

BitKeeper 的公司 Larry McVoy 发现了，宣布停止向整个 Linux 社区提供免费授权

Linus 一夜之间失去了工具

Linus 没有慌，他先花了两周时间研究了市面上所有的版本管理工具，比如CVS、SVN、Monotone、Darcs……

然后他得出一个结论：

这些东西全都烂透了。

在他的邮件里原话是：

没有任何一个现有的系统满足我的需求，所以我决定自己写

0.1 Why?

Linus 的需求不是普通开发者的需求，他管理的是全球最复杂的协作项目

他每天的工作是这样的：

世界各地的开发者把自己的补丁发给各个子系统维护者，子系统维护者整理好再发给 Linus，Linus 最终决定哪些东西进内核

这是一个树状的信任网络，不是一个中心化的提交系统

所以他需要的工具必须满足：

1. 能够离线工作 开发者在没有网络的情况下也要能提交、能看历史、能做分支

2. 速度一定要快 Linux 内核有几百万行代码，操作必须在秒级甚至毫秒级完成。他当时嘲笑 CVS 说："如果一个操作需要超过3秒，这个设计就是错的。"

3. 历史不可篡改 他必须能验证，某个开发者发过来的代码，从他写下第一行到发到 Linus 手里，中间没有被任何人动过。不能靠信任，要靠数学来保证。

4. 分支合并要够用 Linux 开发模式天然是并行的，几十条开发线同时推进，合并必须可靠、必须快。SVN 的合并是噩梦，对他来说不可接受

2005年4月3日，Linus 开始写 Git

2005年4月7日，Git 可以托管自己的源代码了

2005年4月18日，Linux 内核开发者开始用 Git 协作

2005年6月，Linux 2.6.12 正式用 Git 发布

从零到托管全球最大开源项目，不到三个月

0.2 diff vs snapshot

版本管理的本质不是记录「文件怎么变化的」，而是记录「项目在每个时刻的完整状态是什么」

CVS 和 SVN 记录的是 diff，也就是这次改了哪些行

Linus 认为这是错的

他要记录的是快照，每次提交就是整个项目的一张完整snapshot

这一个决策，推导出了 Git 几乎所有的设计

1. 一个决策推导出了所有设计

Linus 坐在那里，想的不是「我要怎么设计一个版本管理工具」

他想的是一个更根本的问题：

什么叫「同一份代码」？

1000个开发者，每个人机器上都有一份 Linux 内核的代码。我怎么知道你这份和我这份是不是同一个状态？我怎么知道你发给我的补丁，是基于哪个状态写的？

SVN 当时给出的答案是看版本号，r1042 就是 r1042

Linus 觉得这是Bullshit。版本号是中央服务器分配的，你得信任那台服务器。而且版本号只是一个计数器，它本身不包含任何关于内容的信息

1.1 内容本身就是身份

Linus 的想法是：

不要用外部分配的 ID 来标识一份代码，用代码内容本身的哈希值

具体来说，对一个文件的全部内容做 SHA-1 哈希，得到一个 40 位的字符串

SHA-1("Chongxi") = f5c3bc7e6fcd7b7b8d04b99f5d7e607302d3a911

这个字符串有一个数学性质：

内容变了，哈希一定变。哈希没变，内容一定没变

这不是协议，不是信任，是数学层面的proof

所以两个人拿着同一个哈希值，就可以确认自己手里的文件是完全一样的，不需要任何第三方

1.2 但单个文件不够，他需要整个项目

一个文件可以哈希，那整个项目呢？

Linux 内核有几万个文件，分布在几百个目录里。Linus 需要一个方法，用一个哈希值来代表整个项目的状态

他的解法是递归地哈希：

main.c    的内容 → 哈希 A
util.c    的内容 → 哈希 B
src/      目录   → 哈希(A + B + 文件名) = 哈希 C
README    的内容 → 哈希 D
根目录           → 哈希(C + D + 文件名) = 哈希 E

根目录的哈希 E，是由所有子节点的哈希算出来的

这意味着：

任何一个文件改了一个字节，由此向上，所有父节点的哈希都会变，根哈希也会变

反过来：根哈希没变，整个项目的每一个字节都没变

这就是 Git 的 tree 对象，也是 Merkle Tree 的核心思想

1.3 Snapshot

有了 tree 对象，Linus 可以在任意时刻，用一个哈希值锁定整个项目的状态

然后他在外面再包一层，加上元信息：

commit {
  tree:    e5f8c2...   ← 这一刻整个项目的根哈希
  parent:  a3d9f1...   ← 上一个 commit 的哈希
  author:  Linus
  time:    2005-04-07
  message: "Initial commit"
}

然后对这整个结构再做一次哈希，得到这个 commit 的哈希值

这里有一个非常关键的地方：

commit 的哈希，包含了 parent 的哈希

这意味着你没办法在不改变哈希的情况下，悄悄修改历史上某个 commit 的内容。改了那个 commit，它的哈希变了，下一个 commit 记录的 parent 哈希就对不上了，再下一个也对不上，整条链都断了

历史是用密码学锁住的，不是靠权限控制，不是靠信任，是靠数学

1.4 snapshot vs diff who will win

SVN 存的是：

r1: 原始文件
r2: 第3行改成了这个
r3: 第17行删了，第20行加了这个

想知道 r3 的状态，你得从头把所有 diff 叠加起来算

Git 存的是：

commit1: 整个项目的哈希 E1
commit2: 整个项目的哈希 E2
commit3: 整个项目的哈希 E3

想知道任意时刻的状态，直接拿那个哈希，找到对应的 tree，展开就是了。不需要计算，不需要回放

代价是存储空间？Git 用了对象去重来解决，两个 commit 如果某个文件没有改动，它们的 blob 哈希一样，Git 只存一份

1.5 我们可以推导出什么

到这里，Linus 还没有发明分支，没有发明merge，没有发明任何高级概念

他只做了一件事：

用哈希把每一个时刻的项目状态锁定成一个不可篡改的对象，用 parent 指针把这些对象串成链

剩下所有的东西——分支、合并、rebase，都是在这个基础上自然生长出来的

2. 对象模型

Git 并不是一个复杂的版本管理系统

Linus 最开始的定义非常朴素：

Git 就是一个内容寻址的文件系统。你把东西存进去，它给你一个哈希。你拿着哈希，随时可以把东西取出来

仅此而已

你可以打开任何一个 Git 仓库，看 .git/objects/ 目录，里面存的就是所有对象，按哈希值的前两位分文件夹：

.git/objects/
  a3/f8c2d9b1e4...   ← 这就是一个对象文件
  d9/f3a1b2c4e5...
  e5/c2f8a3d9b1...

每个文件的内容就是压缩过的对象数据。整个 Git 仓库，本质上就是这个文件夹

2.1 blob

Git 里最简单的对象叫 blob，存的就是文件的原始内容，不包含文件名，不包含任何元信息

blob "CEPATO"
↓ SHA-1
d1fcd7b25f99b9f9d1a577557f45c10b6c1f9642

blob 不知道自己叫什么，也不知道自己在哪个目录里

文件名是上层的事，blob 只管内容

这个设计有一个直接好处：

两个不同路径下内容完全一样的文件，Git 只存一份 blob

2.2 tree

文件名和目录结构，交给 tree 对象来管

一个 tree 对象就是一张表：

tree d9f3a1... {
  100644  blob  8c7e5a...  main.c
  100644  blob  f7d8e9...  util.c
  040000  tree  b2c4e5...  src/
}

每一行记录：文件权限、对象类型、哈希值、名字

tree 可以嵌套 tree，这样就构成了完整的目录结构

然后对这张表做哈希，得到这个 tree 的哈希值

因为 tree 的哈希是由子节点哈希算出来的，所以：

改了 main.c 的内容
→ main.c 的 blob 哈希变了
→ 包含它的 tree 哈希变了
→ 上层 tree 哈希变了
→ 根 tree 哈希变了

任何一个叶子的变动，都会反馈到到根节点

:::tips 这里我们来区分一下，有个朋友单独找我提问了，私以为问题很好于是单独放出来讲下

Git 的 tree 不是哈希表，它更像一个有序列表，存的是文件名 → 子节点哈希的映射，但查找方式是线性遍历，不是哈希表的 O(1) 寻址

和 MPT 里的 Patricia Trie 部分相比

Git tree：  文件名 → 子节点哈希  //简单映射，不优化查找）
MPT：       路径   → 叶子值     //按前缀压缩，O(log n) 查找

两者表面很像，都是某种key指向哈希，但设计目标不同：

Git 的 tree 不需要高效查找，你 checkout 一个 commit，Git 直接把整棵树展开就完了，不需要频繁查单个节点
以太坊的 MPT 需要高效查找，因为每笔交易都要单独查某个账户的状态，O(n) 不可接受

所以 Git 用简单结构够了，以太坊才需要 Patricia Trie 来优化

也就是说Git 的 tree 是为了描述状态，MPT 是为了高效查询状态 :::

2.3 commit

有了 tree，我们能表示项目在某一刻的状态

但还缺两件事：这个状态是谁在什么时候创建的，以及它的上一个状态是什么

这就是 commit 对象：

commit a3f8c2... {
  tree:    d9f3a1...   ← 根 tree，代表这一刻的全部文件
  parent:  prev_hash   ← 上一个 commit
  author:  Linus Torvalds
  time:    2005-04-07 15:16:22
  message: "Initial commit"
}

然后对这整个结构做哈希，得到这个 commit 的哈希

因为 commit 哈希包含了 parent 哈希，parent 哈希又包含了它的 parent，一直追溯到第一个 commit

整条history chain，被一个哈希值锁住了

你拿着最新的 commit 哈希，就能验证从第一天到今天，每一行代码的每一次变更，没有任何人动过

2.4

现在把三层放在一起看：

commit a3f8c2
  └── tree d9f3a1  （根目录）
        ├── blob 8c7e5a   main.c
        ├── blob f7d8e9   util.c
        └── tree b2c4e5   src/
              └── blob 3a9f1c   helper.c

每个节点都是一个独立的对象，存在 .git/objects/ 里，用哈希寻址

它们之间没有包含关系，只有引用关系。每个对象只记录子节点的哈希，不复制子节点的内容

假设你做了第二次提交，只改了 main.c：

commit e5c2f8
  └── tree 7a1b3d  （新的根 tree）
        ├── blob 9f2e4a   main.c   ← 新的 blob
        ├── blob f7d8e9   util.c   ← 和上次一样
        └── tree b2c4e5   src/     ← 和上次一样

util.c 和 src/ 目录没有变，Git 直接复用它们的对象，不复制，不重新存储

两次 commit，Git 只新建了三个对象：新的 blob、新的根 tree、新的 commit

Git 存的是快照，但因为对象复用，实际占用的空间接近于存 diff

鱼和熊掌可以兼得

2.5 分支

推导到这里，Git 的存储层已经完整了：一个哈希对象数据库，里面装着 blob、tree、commit，用引用关系连接成一棵棵树，再用 parent 指针串成时间轴

但有一个问题：

commit 的哈希是 a3f8c2d9b1e4f7... 这样一串东西，人类没法记

你怎么找到最新的那个 commit？

3. 指针

对象数据库建好了，里面存着几千个对象，每个都有一个 40 位的哈希地址

Linus 面临一个很实际的问题：

我怎么知道最新的提交在哪？

用每次都把最新的 commit 哈希记在纸上？那确实很直接了

git用一个文本文件把这个哈希存起来，给这个文件起一个人类能看懂的名字

这就是分支。对，就这么简单

3.1 refs

Git 把这些文本文件统一放在 .git/refs/ 目录下：

.git/refs/
  heads/
    main        ← 内容：a3f8c2d9...
    feature     ← 内容：d9f3a1b2...
  remotes/
    origin/
      main      ← 内容：e5c2f8a3...
  tags/
    v1.0        ← 内容：f7d8e9b1...

你可以直接打开这些文件看，里面就是一行哈希值，没有任何其他东西

cat .git/refs/heads/main
# a3f8c2d9b1e4f7a8b2c3d4e5f6a7b8c9d0e1f2a3

3.2 分支的本质

所以「创建一个新分支」，在文件系统层面发生了什么？

git branch feature

发生了什么：

在 .git/refs/heads/ 下新建一个叫 feature 的文件，把当前 commit 的哈希写进去

就这一件事。没有复制代码，没有复制历史，没有任何你认为的企业级操作，就这么简单

这就是为什么 Git 的分支创建是瞬间完成的，而 SVN 创建分支要复制整个目录

3.3 分支怎么移动

你在 feature 分支上提交了新代码，生成了新的 commit b2c4e5...

发生了什么：

把 .git/refs/heads/feature 文件里的哈希，更新成 b2c4e5...

就是改了一个文件里的一行字符串

提交前：feature 文件内容 = a3f8c2...
提交后：feature 文件内容 = b2c4e5...

分支跟着你走，本质就是这个文件在自动更新

3.4 HEAD

现在你有了 main、feature 两个分支，Git 怎么知道你当前在哪个分支上？

再加一个文件，叫 HEAD，放在 .git/HEAD：

cat .git/HEAD
# ref: refs/heads/feature

它存的不是 commit 哈希，而是指向某个分支的引用

所以：

HEAD → refs/heads/feature → b2c4e5...（commit）

你提交新代码时：

生成新的 commit 对象
feature 文件更新成新的哈希
HEAD 不动，还是指向 feature

3.5 切换分支呢

git checkout main

发生了什么：

把 .git/HEAD 改成：

ref: refs/heads/main

根据 main 指向的 commit，把对应的文件树展开到你的工作目录

你看到文件变了，本质是 Git 用对象数据库里的内容，重新写了你的工作目录

3.6 detached HEAD

现在我们理解了 HEAD 是指向某个分支的指针

但如果你直接 checkout 一个 commit 哈希：

git checkout a3f8c2

这时候没有分支可以指，HEAD 只能直接存哈希值：

cat .git/HEAD
# a3f8c2d9b1e4f7...

这就是 detached HEAD，头指针脱离

为什么都说脱离状态危险？

因为你在这个状态下做了新的提交，生成了新的 commit。但没有任何分支文件记录这个新 commit 的哈希

一旦你切换到别的分支，HEAD 更新了，那个新 commit 的哈希就没有任何东西指向它了

它还躺在 .git/objects/ 里，但你再也找不到它

Git 会定期运行垃圾回收，把没有任何引用指向的对象清理掉。你的提交就这样消失了

3.7 远端指针

最后还有一类指针，放在 .git/refs/remotes/ 下：

origin/main     ← 内容：上次 fetch 时，远端 main 的哈希

它的作用是：记录你上次同步时，远端仓库的状态

它是只读的，你不能直接在上面提交。它只在你 git fetch 的时候更新

git push 和 git pull 的本质，是让本地和远端的这些指针对齐

3.8 小结

HEAD
  └── refs/heads/main       → commit C4
  └── refs/heads/feature    → commit C5

  refs/remotes/origin/main  → commit C3（上次 fetch 的状态）

  refs/tags/v1.0            → commit C1（不移动）

对象数据库是不可变的，指针系统是可变的
所有的 Git 操作，本质上都是在移动这些指针，或者在对象数据库里新增对象

4. 平时做的核心操作本质

我们先来建立一个场景，后面所有操作都基于此：

C1 ← C2 ← C3          main
           ↑
           └── C4 ← C5  feature

main 指向 C3，feature 指向 C5，C4 和 C5 是从 C3 分叉出去的。

4.1 merge：新建一个节点

你站在 main 上，执行：

git merge feature

git操作如下

找到分支父节点

main 在 C3，feature 在 C5，顺着 parent 往上找，父节点是 C3

diff

C3 的文件状态
C3 → C3 之间 main 改了什么
C3 → C5 之间 feature 改了什么

改了不同地方，自动合并。改了同一个地方，冲突，让你手动解决

生成一个新的 commit C6

commit C6 {
  tree:    合并后的文件状态
  parent:  C3   ← main 这边
  parent:  C5   ← feature 这边
}

C6 有两个 parent，这在 Git 对象模型里是完全合法的

然后 main 指针移动到 C6：

C1 ← C2 ← C3 ← C6       main
           ↑    ↑
           └── C4 ← C5  feature

merge 的本质是在对象数据库里新建一个节点，把两条线接在一起，移动当前分支指针

历史是真实的，分叉和汇合都保留着

4.2 rebase：重建节点，换个爹

C1 ← C2 ← C3          main
           ↑
           └── C4 ← C5  feature

同样的场景，你站在 feature 上，执行：

git rebase main

git则是把C4、C5 这两个 commit，在 C3 之后重放一遍

找到共同父节点 C3
把 C4、C5 的变更内容提取出来
从 main 的最新位置 C3 开始，依次重新应用这些变更，生成新的 commit

C4 → C4'（parent 从 C2 变成了 C3）
C5 → C5'（parent 从 C4 变成了 C4'）

C4' 和 C4 的文件内容可能一样，但哈希值完全不同，因为 parent 变了

结果：

C1 ← C2 ← C3 ← C4' ← C5'   feature
           ↑
          main

历史变成了一条直线，看起来好像 feature 一直是在 C3 之后顺序开发的

rebase 的本质是把一段 commit 历史，复制到另一个位置重建，原来的对象还在数据库里，但没有指针指向它们了

注意，C4 和 C4' 同时存在于 .git/objects/ 里

rebase 之后，feature 指针移动到了 C5'，没有任何指针指向原来的 C4 和 C5 了

它们会在 Git 垃圾回收时被清理掉

这就是为什么 rebase 之后我们说「历史被改写了」，原来的 commit 被抛弃了，fork了一批平行的对象

4.3 reset：移动指针，不新建节点

git reset C3

这个操作最简单，也最容易被误解

它做的事情只有一件：
把当前分支的指针，强行移动到指定的 commit

执行前：main → C5
执行后：main → C3

C4、C5 还在对象数据库里，但 main 不再指向它们了

reset 有三种模式，区别在于工作目录和暂存区怎么处理：

--soft   只移动指针，工作目录和暂存区不动
--mixed  移动指针，暂存区清空，工作目录不动（默认）
--hard   移动指针，暂存区清空，工作目录也回退

从指针视角看，三种模式做的是同一件事。区别只是你工作目录里的文件怎么变

4.4 cherry-pick：复制单个节点

git cherry-pick C4

你在 main 上，想把 feature 上的某一个 commit 单独拿过来

操作：

提取 C4 相对于它的 parent 的变更内容，在当前位置重新应用一遍，生成新的 commit C4'

C1 ← C2 ← C3 ← C4'   main
           ↑
           └── C4 ← C5  feature

C4' 和 C4 内容相同，哈希不同

和 rebase 一样，都是「复制 commit 到新位置重建」，只不过 rebase 复制一段，cherry-pick 复制一个

简单列个表：

操作	新建对象？	移动指针？	改写历史？
merge	是，新建 merge commit	是	否
rebase	是，重建 commit	是	是
reset	否	是	看模式
cherry-pick	是，复制 commit	是	否

所有操作都在做两件事的组合：在对象数据库里新增东西，和移动指针

4.5小结

我们现在可以理解任何 Git 操作：

对象数据库只进不出（垃圾回收除外），是append-only的
指针可以随意移动
你所见的历史，取决于指针指向哪里

这就是为什么 Git 几乎不会丢数据——只要对象还在数据库里，你总能通过 git reflog 找回指针曾经指向过的位置，把东西捞回来

接下来我们讲协作以及为什么不要在多人时用rebase

5. 多人协作

先建立实际场景

你和Chongxi，各自 clone 了同一个远端仓库。clone 的那一刻，你们三个人的状态完全一样：

远端 origin:     C1 ← C2 ← C3    main
你的本地:         C1 ← C2 ← C3    main
Chongxi的本地:    C1 ← C2 ← C3    main

然后我们开始各自工作

5.1 clone 发生了什么

clone并不是单纯的「下载代码」

准确说法是：

把远端的整个对象数据库复制到本地，然后把远端的所有指针，在本地存一份只读的副本

.git/refs/remotes/origin/main = C3 的哈希

这个 origin/main 就是你本地对远端状态的快照，记录的是上次我跟远端同步时，它在哪

5.2 fetch

你工作了一段时间，远端有了新的提交

git fetch

Git操作如下：

从远端下载所有新的对象，更新 origin/main 指针。你的本地 main 不动

远端:          C1 ← C2 ← C3 ← C4 ← C5    main
你的本地 main:  C1 ← C2 ← C3              main（没动）
origin/main:   C1 ← C2 ← C3 ← C4 ← C5   （更新了）

fetch 只做一件事：同步对象，更新远端指针。你的工作完全不受影响

5.2 push：把本地指针推到远端

你在本地提交了 C4'，想推到远端：

git push

Git操作如下

把本地新的对象（C4'）传到远端的对象数据库
请求远端把 main 指针移动到 C4'

但远端会检查一件事：

你的 C4' 的 parent，是不是远端当前 main 指向的 commit？

如果是，叫做 fast-forward，远端直接把指针往前移，没有任何问题

如果不是，远端拒绝，返回错误：

! [rejected] main -> main (non-fast-forward)

为什么会被拒绝

你和Chongxi同时从 C3 开始工作：

你:   C1 ← C2 ← C3 ← C4'   本地 main
Chongxi: C1 ← C2 ← C3 ← C4    推到了远端

Chongxi比你先推，远端 main 现在在 C4

你要推 C4'，但 C4' 的 parent 是 C3，不是 C4

远端：你的历史和我的历史分叉了，我不知道该怎么合并，你自己看着办吧

5.3 pull：fetch + 合并

git pull

本质是两步：

git fetch    ← 先同步远端对象
git merge    ← 再把 origin/main 合并到本地 main

合并之后生成 merge commit C5，然后你再 push，这次 C5 的 parent 包含了 C4，远端会接受

C1 ← C2 ← C3 ← C4 ← C5    远端 main（C5 是 merge commit）
                ↑    ↑
            Chongxi  你

5.4 冲突怎么发生的

你和Chongxi改了同一个文件的同一个地方

Git 做三方对比：

共同父节点 C3：第5行是 "喵"
Chongxi的 C4：第5行改成了 "qwq"
你的 C4'：    第5行改成了 "uwu"

Git 不知道该用哪个，只能停下来让你决定：

<<<<<<< HEAD
uwu
=======
qwq
>>>>>>> origin/main

这不是 Git 的缺陷，是真实冲突，机器没办法替你决定业务逻辑

5.5 rebase 在多人场景下为什么危险

现在回到之前说的那个问题，我们来用对象模型解释

你和Chongxi都基于 C3 创建了 feature 分支，Chongxi已经把他的 C4、C5 推到了远端：

远端 feature:  C1 ← C2 ← C3 ← C4 ← C5
你的 feature:  C1 ← C2 ← C3 ← C4 ← C5

你在本地对 feature 做了 rebase，生成了 C4'、C5'：

你的 feature:  C1 ← C2 ← C3 ← C4' ← C5'

然后你强行推到远端：

git push --force //瞎 push --force 会被打死

远端 feature 变成了：

远端 feature:  C1 ← C2 ← C3 ← C4' ← C5'

原来的 C4、C5 在远端消失了

但是Chongxi本地还有：

Chongxi的 feature:  C1 ← C2 ← C3 ← C4 ← C5

Chongxi再去 fetch，发现远端的历史和自己本地的历史完全对不上，因为 C4 和 C4' 哈希不同，Git 认为这是两个完全不相关的 commit

我的本地仓库陷入混乱

根本原因：rebase 改写了 commit 的哈希，而哈希是 Git 世界里唯一的身份证。你改了别人依赖的身份证，别人的世界就崩了

所以多人协作的铁律有这么一条

已经推到远端、别人可能基于它工作的 commit，永远不要 rebase

自己本地没推出去的，随便 rebase，没有任何问题

5.6 解构一下整个协作模型的本质

每个人本地都有一份完整的对象数据库和指针系统。协作的本质，就是在不同机器之间同步对象、对齐指针。冲突是指针对不齐时的自然结果，push 被拒绝是远端在保护历史

6. 结：一个思想的四种实现

回到最开始的问题：

在没有中央权威的情况下，怎么让分布在全球的人，对同一份数据达成共识？

这是一个几十年来反复出现的问题。不同领域的人，用不同的方式，给出了同一个答案的变体

6.1 底层思想：内容寻址 + 哈希链

所有这些系统，都建立在两个原语上：

内容寻址

不用「这个文件在第3个服务器的第5个目录里」来定位数据，而是用数据内容本身的哈希值来定位

哈希值就是地址，地址就是内容的指纹

哈希链

每个节点包含上一个节点的哈希，形成一条链

改动链上任何一个节点，后续所有节点的哈希都会变。链的完整性可以被任何人独立验证，不需要权威机构背书

这两个原语组合在一起，解决的是同一个问题：

让数据自证清白

是不是很熟悉？web3？不不不，这个思想我们可以追溯到上个世纪七十年代

6.2 1979年：Merkle Tree

Ralph Merkle 在他的博士论文里提出了这个数据结构

最初的目的很朴素：怎么高效验证一大批数据里，某一条数据没有被篡改？

解法：

把所有数据放在叶子节点每个父节点存左右子节点哈希的组合哈希一直算到根节点

根哈希代表整棵树的状态。想验证 C 没被篡改，只需要提供 D、哈希AB、根哈希，不需要暴露 A 和 B 的内容

这叫 Merkle Proof，验证效率是 O(log n)

这是一个纯密码学概念，当时没有具体应用

6.3 2005年：Git

Linus 独立地想到了同样的结构，用来解决代码协作问题

Git 的对象模型就是一棵 Merkle Tree：

commit
  └── tree（根哈希）
        ├── blob
        ├── blob
        └── tree
              └── blob

然后用 parent 指针把多棵树串成时间轴

Git 的贡献是把 Merkle Tree 从静态数据结构，变成了带时间维度的版本历史

6.4 2008年：比特币

中本聪面临的问题和 Linus 本质上一样：

在没有银行这个中央权威的情况下，怎么让全球的人对谁拥有多少钱达成共识？

他的解法借鉴了同样的思想：

每个区块包含：

block {
  transactions_root:  所有交易的 Merkle Tree 根哈希
  prev_block_hash:    上一个区块的哈希
  nonce:              工作量证明
}

prev_block_hash 就是 Git 的 parent，把区块串成链

改动任何一个历史区块，后续所有区块的哈希都会变，全网立刻发现

比特币的贡献是在哈希链的基础上加了工作量证明（也就是挖矿），解决了谁有权写入新区块的问题

Git 不需要解决这个问题，因为 Linus 自己就是最终权威（笑

6.5 2014年：以太坊的 MPT

以太坊要存的状态比比特币复杂得多——不只是交易记录，还有每个账户的余额、智能合约的状态、代码……

普通的 Merkle Tree 查找效率不够高，以太坊把它和 Patricia Trie（压缩前缀树）结合，发明了 Merkle Patricia Trie

MPT = Merkle Tree（防篡改）
    + Patricia Trie（高效查找）

Patricia Trie 的思路是按路径寻址，比如账户地址 0x1a2b3c... 就是树上的一条路径，顺着走就能找到这个账户的状态

以太坊每个区块有三棵 MPT：

state_root       ← 全局账户状态
transactions_root ← 这个区块的所有交易
receipts_root    ← 所有交易的执行结果

和 Git 相比：

Git 的 tree 对象  ≈  MPT 的中间节点（按路径寻址）
Git 的 blob 对象  ≈  MPT 的叶子节点（实际数据）
Git 的 commit     ≈  以太坊的区块（状态快照 + 指向上一个）

6.6 2015年：IPFS

IPFS 要解决的问题是：

HTTP 是按位置寻址的，服务器挂了，数据就消失了。能不能让数据按内容寻址，只要有人存着，任何人都能取到？

IPFS 的每个文件被切成块，每块算哈希，目录结构也用 Merkle DAG（有向无环图）来组织：

目录哈希
  ├── 文件A的哈希
  │     ├── 块1的哈希
  │     └── 块2的哈希
  └── 文件B的哈希

你请求一个文件，给出根哈希，IPFS 从网络上任何存着这个数据的节点取回来，用哈希验证完整性

和 Git 比几乎一一对应：

Git blob   ≈  IPFS 数据块
Git tree   ≈  IPFS 目录节点
Git remote ≈  IPFS 网络节点

IPFS 的作者直接说过：IPFS 就是把 Git 的对象模型推广到整个互联网

他们的核心思想完全一样，差别只在于：

各自要解决的额外问题不同，导致在哈希链的基础上做了不同的扩展

最后我们回到2005年，Linus 用十天时间写出了 Git。他没有预见到区块链，没有预见到 IPFS

他只是想清楚了一个问题：

信任不应该依赖权威，应该依赖数学

这一个洞察，在接下来的二十年里，被不同领域的人反复重新发现，长出了完全不同的东西

Android到底是不是Linux？一文解清你的所有疑惑

Chongxi — Sun, 29 Mar 2026 15:39:21 GMT

0. 引

当你问出一个简单的问题：「Android 是 Linux 吗？」你通常会得到两种截然不同的答案：有人坚决同意，有人坚决否决。这是为什么呢好难猜啊

产生这种分歧的根本原因，在于我们平时口中所说的 Linux 这个词产生了歧义。要理清 Android 的身世，我们必须先回到上世纪 90 年代，理清两个核心概念

0.1 Linux 只是内核

在最严格的定义下，Linux 根本不是一个完整的操作系统，它仅仅是一个内核

1991 年，芬兰大学生 Linus Torvalds 写下第一行代码时，他编写的只是一个内核程序

内核的作用是什么？ 它负责管理 CPU 调度、内存分配、网络通信以及驱动底层硬件（比如让主板认出你的网卡和键盘），他仅仅只是一个发动机，你没办法只靠一台发动机给他开上高速

Android 确实使用了 Linux 内核，在这个极为狭义的层面上，你可以说 Android 包含了 Linux

0.2 GNU/Linux 是什么

既然 Linux 只是内核，那我们平时用的 Arch、Debian、CentOS 甚至国产的 Deepin，那些带桌面、带命令行、能装软件的完整系统，到底是什么？

这就不得不提下 Richard Stallman 和他发起的 GNU 计划
1983 年，斯托曼决定打造一个完全自由、开源的操作系统。他的团队耗费多年，开发出了操作系统所需的几乎所有上层组件：

C语言标准库 glibc： 所有软件运行的基础底座
编译器： 把代码变成可执行程序的机器
命令行工具集： 比如你敲进去的 ls、cd、cp、rm
Shell环境： 比如大名鼎鼎的 Bash

而到 90 年代初，GNU 团队万事俱备，造好了精美的汽车底盘、方向盘和外壳，唯独缺一台好用的发动机（他们的自研内核 Hurd 难产了）。而另一边，Linus 刚好造出了一台极好的发动机（Linux内核），但没有外壳

于是，两者一拍即合。Linux 内核 + GNU 工具链 = 完整好用的操作系统

因此，今天我们在服务器和个人电脑上使用的传统 Linux 发行版，它们最准确的学术名称应该叫 GNU/Linux。我们平时常说的「我用的是 Linux 系统」，其实是「GNU/Linux 系统」的简称

0.3 Android 是什么

理解了上述历史，Android 本质就非常清晰了

当 Google 决定开发一款智能手机操作系统时，他们看中了 Linux 这台超级发动机，但是，Google 并不想要 GNU 造的车体

为了适应移动设备的特性，以及避开 GNU 背后严苛的开源协议（这在后续章节会详细讲），Google 把 Linux 这台发动机拆了下来，围绕它重新打造了一整套全新的跑车

1. 开源 vs 商业化 who will win

要理解 Android 为什么不能是传统的 GNU/Linux，我们首先要认识两个在开源界水火不容般的开源许可协议：GPL（GNU 通用公共许可证）和 Apache 2.0

1.1 GPL

传统 GNU/Linux 系统（如 Ubuntu）中，从 Linux 内核到上层的 GNU 核心组件（C标准库、命令行工具等），绝大多数都使用的是 GPL 协议

GPL 协议的初衷是极其伟大且纯粹的：捍卫软件的绝对自由。它规定：你可以免费使用我的代码，也可以随意修改，但是，任何使用了 GPL 代码、或者链接了 GPL 库的衍生软件，都必须同样以 GPL 协议开源其全部源代码

在我们视角里这叫自由的接力棒。但在商业公司的法务部眼里，这被称为病毒式协议

这对手机硬件厂商意味着什么？ 假设高通砸了十亿USD研发了一款拥有顶级图形性能的 GPU，或者三星开发了极其先进的相机算法。为了让这些硬件在手机上工作，他们必须编写硬件驱动程序

如果 Android 原封不动地照搬 GNU/Linux 的架构，高通和三星在编写驱动时，就不可避免地要调用底层那些受 GPL 保护的代码库。一旦调用（哪怕只是链接了一个 .so 动态库），根据 GPL 的传染性，高通和三星就必须把他们耗费巨资研发的 GPU 和相机驱动源代码公之于众

这等同于让他们把商业机密白白送给竞争对手。如果 Google 当年对硬件厂商说：「用我的 Android 系统吧，代价是公开你们的所有核心技术代码」，那么毫无疑问，Android 会在诞生之初就暴毙，任何OEM厂商都会让他门外竖着

1.2 Apache

Google 不是傻子，他们清楚地知道，想要打造一个垄断全球的手机操作系统，最好的办法是建立一个庞大的商业联盟

要吸引三星、HTC、高通、联发科等巨头入局，Google 必须给他们吃下一颗定心丸：用我的系统，且允许你们闭源

为了实现这个承诺，Google 做出了一个极其重大的架构决策：在用户空间封杀 GPL 协议，全面右转Apache 2.0

Apache 2.0（以及类似的 BSD、MIT 协议）被称为对商业极度友好的协议。你可以免费使用我的代码，随便你爆改，也可以选择闭源拿去捞钱

这完美契合了硬件厂商和闭源商业软件开发者的胃口

1.3 架构指导思想

然而现实是，Linux 内核本身就是 GPL，How to do?

幸运的是，Linus 当年做过一个极其重要的声明：正常的系统调用（即上层软件呼叫底层内核帮忙办事的操作）不构成衍生作品，不受 GPL 传染

Google 敏锐地抓住了这根救命稻草，确立了 Android 架构设计的最高原则：隔离 GPL：

把 GPL 严格锁死在内核层： 底层那个不可修改的 Linux 内核，Google 认了，依然遵守 GPL 协议
上层空间全面“去 GNU 化”： 在内核之上的所有东西，绝对不允许出现任何 GPL 的影子。Google 下死手把传统 GNU/Linux 中那些带有 GPL 传染风险的核心底层库（比如 glibc、所有的核心命令工具）统统杀了，自己花钱重新写了一套的替代品
驱动上移： 传统 Linux 驱动是在内核里的，为了不让硬件厂商的驱动被内核的 GPL 传染，Google 硬生生在架构中间插了一层硬件抽象层HAL，让厂商把核心驱动代码挪出内核，放到用户空间去闭源运行

2. NO GNU

2.1 开始自研

libC是任何基于 Linux 内核的操作系统中最重要的一块基石。它是所有上层软件（无论是 C++ 写的原生程序，还是 Java 虚拟机）与底层 Linux 内核打交道的唯一桥梁
传统 GNU/Linux： 使用的是大名鼎鼎的 glibc。它极其庞大、功能大而全、完全符合 POSIX 规范，且运行速度极快。但它有两个弱点：第一，它是 GPL 协议的。第二，它太占用内存了，对 08 年初生代智能手机那点可怜的 RAM来说，太重了

于是Google 抛弃了 glibc，基于 BSD 协议，自己重写了一个轻量级的 C 标准库，命名为 Bionic libc

体积小： 它的体积只有 glibc 的一小部分
速度快： 专门针对移动端 ARM 处理器的低频特性和低功耗进行了指令集优化

那么代价呢？它阉割了大量在手机上用不到的 POSIX 标准功能。这也是为什么很多传统的 Linux C/C++ 软件无法直接在 Android 上编译运行原因

2.3 干掉命令行工具集

在传统 Linux 中，你敲的 ls、grep等，统统来自 GNU Coreutils 软件包

为了避嫌，Android 早期自己写了一个叫 Toolbox 的极简命令集，也是基于 BSD。后来随着系统发展，Toolbox 渐渐不够用了，于是 Google 从 Android 6.0 开始，全面转向了由 Rob Landley 发起的 Toybox 项目

Toybox 是一个极其神奇的项目，它把上百个常用的 Linux 命令打包进了一个小小的二进制文件中，并且使用的是 BSD/0-clause（极其宽松，几乎等于放弃版权要求）
所以，你在 Android 手机里敲的 ls，和你在 Arch 里敲的 ls，虽然长得一样，但它们底层完全是两码事

2.3 干掉编译器

最初，Android 和所有 Linux 一样，使用 GNU 的 GCC 作为 C/C++ 代码的官方编译器。但 GCC 也是 GPL 协议的重灾区

随着苹果主导的开源编译器架构 LLVM/Clang（采用宽松的 Apache/UIUC 协议）走向成熟，Google 毫不犹豫地跟进。从 Android NDK r11 开始逐步推荐 Clang，到 r18 版本，Google 干脆彻底删除了 GCC。现在的 Android 系统及其原生生态，已经完完全全是由 LLVM/Clang 编译出来的了

3. 硬件抽象 & 驱动重构

3.1 宏内核

Linux 是一个Monolithic Kernel操作系统。这意味着，在传统的 GNU/Linux 中，硬件的驱动程序是直接塞进 Linux 内核空间里运行的

这就产生了一个法律炸弹：

Linux 内核是 GPLv2 协议
你的驱动代码要跑在内核里，就必须调用内核提供的各种API
根据 GPL 协议，这就构成了衍生作品
你得开源

这对硬件大厂来说是绝对不可接受的。如果不用 Android，他们要自己重头写一个操作系统。如果用 Android，商业机密就要被迫公开。局面一度陷入死胡同

3.2 HAL

为了打破这个死局，Google 的架构师们在 Linux 内核和上层 Android 框架之间，硬生生地插入了一个全新的概念：**HAL Hardware Abstraction Layer 硬件抽象层 **

既然 GPL 只限制在内核空间，那我们就把驱动程序的核心逻辑从内核空间搬出来，搬到不受 GPL 限制的用户空间去

具体做法如下：

硬件厂商在 Linux 内核里只写一个极其简单的占位驱动 Stub。这个驱动只负责最基础的硬件读写指令，直接开源
硬件厂商把真正的控制逻辑、图像处理算法、复杂的调度机制，写成一个闭源的动态链接库（.so 文件），放在用户空间的 HAL 层。这部分代码受 Apache 2.0 保护，完全闭源
当你打开手机相机时，Android 上层应用调用 API -> 系统服务去找 HAL 层的闭源 .so 库 -> .so 库再向底层内核那个开源的空客发简单指令

通过这个华丽的架构魔术，Android 完美地保护了所有硬件巨头的核心利益 这也是为什么你在 Android 手机目录的 /vendor/lib/hw/ 下，能看到一堆由高通或联发科提供的、根本看不了源码的 .so 文件的原因

3.3 Project Treble

早期，HAL 层的代码和 Android 的系统框架是绑定在一起的。这就导致每次 Google 发布新版本，厂商必须重新修改他们的 HAL 代码，这就导致了安卓手机极其臭名昭著的升级碎片化（厂商懒得改，你的手机也就永远停在老版本）

为了解决这个问题，Google 在 Android 8.0 推出了 Project Treble 他们设计了一种叫 HIDL/AIDL 的接口定义语言。相当于给 HAL 层和 Android 框架之间制定了一套标准插座

从此以后，硬件厂商的闭源驱动变成了完全独立的模块（Vendor 分区）。Google 升级 Android 系统（System 分区），只需要直接拔下旧的插上新的，底层闭源驱动连改都不用改就能直接兼容新系统

4. 彻底颠覆

4.1 抛弃 X11 与 Wayland

传统的 Linux 桌面系统，长期以来使用的是 X11，后来逐渐向 Wayland 过渡。X11 的设计初衷诞生于 80 年代，它支持网络透明性（你可以把远程服务器上的软件图形界面，投射到本地电脑上显示）。这种设计非常适合科研和服务器环境，但它极其臃肿，层层传递的开销极大，对于手机屏幕来说开销太大

Google 果断抛弃了 X11 和 Wayland，专门为移动设备量身定制了一套以硬件渲染为核心的显示框架，它的绝对核心组件叫 SurfaceFlinger

它的工作原理极其简单高效：在 Android 中，每一个 App（甚至每一个按钮、每一个弹窗）在底层都被抽象成一块块的图层。App 进程只负责把自己那块图层画好（通过 OpenGL ES 或 Vulkan）。然后，所有的图层都会被送到 SurfaceFlinger 手里

SurfaceFlinger 就是一个合成器，它利用手机的 GPU 和专门的硬件合成器（HWC, Hardware Composer），在极短的时间内（比如 16.6 毫秒）把这些图层像双层吉士（那很好吃了）一样叠加在一起，按 Z 轴顺序排好，一把推送到屏幕上，没有鼠标指针的概念，没有窗口拖拽重叠的复杂逻辑（早期），一切为全屏触控和极速渲染让路

4.2 音频子系统

传统 GNU/Linux 底层使用 ALSA驱动，上层通常使用 PulseAudio 或较新的 PipeWire 来进行音频的混音和路由

Android底层依然保留了 ALSA 驱动（因为这是 Linux 内核的一部分），但 Google 同样把上层全部推翻，自己写了一个叫 AudioFlinger 的音频策略服务器。它专门针对手机的复杂场景进行了优化：比如你正在听歌（媒体音量），突然来了一个电话（铃声音量），它能极其精准地实现音频焦点的抢占、混音、硬件解码卸载以及极低延迟的音频处理

5. IPC & 进程管理

这是 Android 架构中最精妙、最伟大，也是彻底让它与传统 Linux 划清界限的设计之一

在操作系统中，不同的程序（进程）之间是不能随便互相访问内存的（这叫进程隔离）。但它们又必须合作（比如微信要调用系统的相机服务），这就需要一种交流机制，叫 IPC

5.1 抛弃传统 System V IPC

传统 Linux 提供了丰富的 IPC 机制：管道、信号、消息队列、共享内存、Socket 等（统称 System V IPC 或 POSIX IPC）

为什么 Android 不爱用？
- 管道和消息队列：需要把数据从进程 A 拷贝到内核，再从内核拷贝到进程 B，拷贝两次，性能太差
- 共享内存：性能极高（0 次拷贝），但控制极其复杂，没有安全校验机制
- Socket：通用性强，但开销大，通常用于网络通信

5.2 Binder

为了解决手机上成百上千个 App 频繁调用的性能和安全问题，Google 从早期的 BeOS/PalmOS 系统中汲取灵感，引入了一个全新的机制：Binder

如果没有 Binder，就没有今天的 Android

Binder 巧妙地利用了内存映射技术。进程 A 发送数据时，数据只需拷贝一次进入内核态的特定内存区域，进程 B 就能直接读取到，安全迅速。

当 App A 通过 Binder 呼叫系统服务时，Binder 驱动会在底层强制自动打上 App A 的真实身份标签（UID/PID）。系统服务看一眼标签就知道你有没有权限调

整个 Android 系统（ActivityManager、PackageManager、各种硬件服务）完全是建立在 Binder 织成的庞大通信网之上的

5.3 精简的 `init` vs `systemd`

当我们按下手机电源键，Linux 内核启动完毕后，需要运行第一个用户空间进程（PID=1）来接管系统，把所有的服务拉起来

GNU/Linux如今基本被 systemd 统治。它极其强大、极其复杂，负责挂载文件系统、配置网络、管理后台守护进程，甚至接管了日志系统

移动设备当然不需要那么复杂的通用的管理者，它需要的是极速开机。因此，Android 用 C 语言自己手写了一个非常精简的 init

它通过解析一系列名为 init.rc 的纯文本脚本文件，严格按照设定好的顺序，启动底层核心服务（如 vold 挂载、logd 日志）、配置 SELinux 权限策略，然后拉起整个 Android 框架

6. 应用环境与开发生态

在传统的 GNU/Linux 系统中，你写好一段 C/C++ 代码，用 GCC 编译器编译成一个二进制可执行文件（ELF 格式），然后在终端输入 ./app，程序就开始从 main() 函数一行一行往下跑了。系统不管你里面写了什么，只要你不崩溃、不越权就行

但 Android 不行

6.1 Native ELF 地位边缘化

在 Android 中，Google 极其不鼓励（甚至在早期严禁）开发者直接编写原生 C/C++ 二进制程序并作为独立进程在系统里裸奔

why？传统的 C/C++ 程序是和 CPU 架构（ARM、x86、MIPS）强绑定的。如果你写死成 ARM 指令，那用 Intel x86 芯片的手机就运行不了

对于一个致力于一统天下的商业移动系统来说，这种不兼容是致命的

6.2 Dalvik / ART 虚拟机

为了让开发者做到一次编写，到处拉屎运行，Google 选择了 Java（后来加入了 Kotlin）作为 Android 应用层的婆罗门

你下载的 .apk ，里面装的根本不是能直接在 Linux 内核上跑的机器码，而是被编译成了专属的字节码（Dex文件）
当你打开一个 App 时，Android 会启动一个专门的虚拟机环境来解释或编译这些字节码 * 早期（Android 4.4 之前）叫 Dalvik 虚拟机（采用 JIT 即时编译，一边运行一边翻译代码） * 现在叫 **ARTAndroid Runtime**采用 AOT 预编译 + JIT 混合模式，在 App 安装或闲暇时直接把字节码翻译成机器码，极大提升了流畅度

6.3 组件化模型

在传统 Linux 中，你关掉一个软件的窗口，或者用 kill 命令杀掉它，它就彻底死了但在 Android 中，一个 App 根本没有传统的入口和出口。Google 强制所有应用必须拆分成四大组件（Activity、Service、Broadcast Receiver、Content Provider）

你的应用什么时候启动、什么时候退到后台、什么时候被杀死清理内存，完全不由你写的代码决定，而是由系统核心服务（ActivityManagerService）根据当前手机的内存状态和前台交互需求强制调度的。这种被动式的生命周期管理，在传统的 GNU/Linux 桌面端是完全不存在的

7. 安全模型与权限机制的魔改

这一章是 Google 最精彩的。如何在一个原本为大型服务器设计的操作系统上，实现全球几十亿小白用户的手机安全？Google 用了一招极其聪明的移花接木

7.1 Linux 多用户机制的魔改

在传统的 Linux 服务器中，权限隔离是基于用户的

比如服务器上有三个真实的人：Chongxi、xi 和 root。系统给他们分配不同的 UID。Linux 内核会在底层严格保证：Chongxi 绝对看不了 xi 文件夹里的隐私数据。到了手机上，一部手机通常只有一个真实的主人，那 Linux 强大的多用户隔离机制不炸了吗

Google 发动鬼脑：既然没有多个人，那我就把手机里装的每一个 App，都当成一个独立的user

这就要说到Android 沙盒机制： 当你安装Telegram时，系统给它分配一个 UID（比如 10045）；当你安装b站时，系统给它分配另一个 UID（比如 10046）

在底层 Linux 内核看来，微信和淘宝根本不是两个软件，而是两个互不相识的、平行的Linux 系统用户
利用内核原生的 UID 隔离机制，微信天然就无法读取淘宝在私有目录下的数据，淘宝也无法干涉微信的运行，这就是 Android 沙盒。旧瓶装新酒这一块

7.2 Zygote

既然每个 App 都在一个独立的虚拟机和沙盒里，那每次打开 App 都要重新启动一遍庞大的 Java 虚拟机环境，手机早就卡死了

为了实现极速启动和节省内存，Android 创造了一个叫 Zygote 的特殊进程

手机开机时，系统会先启动这个 Zygote 进程，并在里面把所有的 Java 核心库、虚拟机环境全部ready
当你点击桌面微信图标时，系统只是向 Zygote 发送一个指令。Zygote 会利用 Linux 内核极其高效的 fork() 机制，瞬间克隆出一个一模一样的自己，然后在这个克隆体里运行微信的代码

所有的 App 进程都来自同一个Zygote，它们在底层共享了大量的基础内存（利用 Copy-on-Write 技术），这使得几百兆内存的古董安卓机也能同时跑好几个 App

7.3 SELinux

早期的 Android 经常被用户 Root，一旦拿到 su 权限，沙盒机制就形同虚设

为了堵死这个漏洞，Google 从 Android 5.0 开始，强制启用了美国国家安全局（NSA）主导开发的 SELinux（MAC）

在 SELinux 的规则下，即使你是 Root 用户，也不能拉屎。所有的操作（读写某个文件、调用某个硬件）都必须在系统底层的安全策略文件中有明确的白名单授权，否则即使是内核也会直接拒绝执行

8. 结

经过这漫长的闲谈，我们终于可以给Android扣个「帽子」了

Android 当然包含了 Linux内核，但在操作系统上Android 早就脱离了 GNU/Linux 的族谱，成为了人类历史目前上最成功、最复杂的移动操作系统

华立采取激进IP策略使舞萌中二等机台全体断网问题解答

Chongxi — Fri, 27 Mar 2026 20:11:17 GMT

0. 引

之前舞萌公众号就有封禁策略过于激进，导致随便点几下舞萌NET就会被ban的情况。近期华立貌似给游戏等服务器也应用了同样激进的IP Ban策略

1. 问题复现

被IP ban后，会有以下现象

机厅内所有舞萌，中二等其他机器全部无法联网，重启机器也无法解决。且机厅内其他非华立机器正常运行，手机电脑连机厅网络也正常上网

2. 成因

华立采用了激进的IP封禁策略，具体阈值不明，当网络请求达到一定计量后会对此IP封禁，目前不确定是否会封禁IP段，导致机厅内舞萌等机器被服务器认为是黑客从而被封禁

3. 解决办法

首先一定要压力华立，让机厅相关工作人员将该情况反馈给华立。接下来按以下顺序尝试：

重启机厅内光猫
- 如果您所在机厅不是固定IP，一般重启光猫会重新拨号一次，此时运营商会给你所在机厅的出口宽带更换一个新的IP，从而绕过IP ban

这个操作就相当于：
你的机厅之前叫xi，华立的防火墙把叫xi的人全拦外面，现在你重启下光猫，改名叫Chongxi，华立就给你放进去了

如果上述操作无效，则说明：

您所在地区运营商可能有不同的分配策略，重播无法触发运营商的IP重分配策略

等待最长48或72小时
国内运营商为了防止用户长期占用同一个 IP 地址（变相当作固定 IP 使用），会在后台设置一个强制断开的时间阈值，一般最长72小时
如果上述操作均无效，那么您所在机厅大概率是固定IP，这种目前没办法解决，请务必让机修将此情况上报给华立来解决

4. 注

如果你碰见了单台舞萌断网，其他机器正常，这种基本上是吞cookie导致的假灰，重启机器就好

关于吞cookie导致断网参见：为什么舞萌机台老断网？一文解决近期舞萌服务器问题的所有疑惑

lanota的单曲分值和rating计算讲解分析

Chongxi — Wed, 18 Mar 2026 01:21:22 GMT

0. 引

lanota的rating系统可以说是我目前见过对玩家最友好的

1. 单曲分数

满分 1,000,000 分

基础分 920,000
连击分 80,000

1.1 基础分

设谱面有 N 个 note，基础分的算法很直

Harmony：920,000 ÷ N
Tune：400,000 ÷ N
Miss：0

Tune 大约是 Harmony 的 43%
也就是说，同一个 note，打 Harmony 比打 Tune 多拿将近 2.3x 的分

1.2 连击分

lanota连击分的设计很有意思，他并不是均匀的，而是递减，和大多数音游几乎相反

每打一个 note，这个 note 带来的连击分就比上一个少一点。一直递减到曲目过了50%，然后固定不变。

前半段拿了 60,000，后半段固定拿 20,000。断连之后不是清零，而是需要超过上次的最高联机才能继续加

这个设计和 osu 差距就很大了

osu 的 ScoreV1 是连击乘数机制。每打一个 note，combo 数增加，当前 note 的得分就乘以这个 combo 数。断连之后乘数归 1，后面的 note 都只拿基础分，相当于全部木大。然后就出现了问题，同样的准确率，断在开头和断在结尾，分数可能差十万八千里。所以 osu! 后来推出了 ScoreV2，大幅降低连击的权重，把重心转移到了准确率上

Lanota 的设计从一开始就避开了这个坑。连击分只占 8%，而且断连不清零，noxy的设计意图就非常清晰

1.3 断连影响多大？

实话说，连击分只占总分 8%，断了又不是归零，损失实际上相当有限。更多时候是断连之后心态炸了然后红温

2. 单曲 Rating

总分只是衡量这把打了多少，而 Rating 衡量的是你在这首曲子上的真实水平

单曲Rating = ( Harmony + Tune÷3 ) ÷ Note × ( D + X )

D 是谱面难度，X 是难度系数加成

难度	X
16+	2.25
15+	1.75
13+ / 14+ / 16	1.5
其余	1.0

16 和 16+ 是两个不同的level，X 差了 0.75

2.1 怎么理解

前半段 (H + T÷3) ÷ N 是你的加权准确率，上限是 1，全 Harmony 才能拿到。Tune 在这里只折算三分之一，比在总分里还要低。

也就是说，Rating 对准度的要求比总分更严格。两个 Tune 在 Rating 公式里，加起来还不如一个 Harmony

接下来是难度

普通 15 级全 Harmony：Rt 最高 = 16
16 级全 Harmony：Rt 最高 = 17.5
16+ 级全 Harmony：Rt 最高 = 18.25

Rating = 准确率 × 难度。难度不够高，准确率再好也顶到头了 ~~这不废话吗~~

和Arcaea

Arcaea 的单曲 PTT 公式和 Lanota 相当接近，核心逻辑是一样的：谱面定数 × 准确率修正。定数越高、打得越准，PTT 贡献越大

但 Arcaea 有一个更激进的设计：如果你打出了 EX+ 以及接近理论，PTT加成会比较高，但如果分数很低，PTT 贡献可以是负数，直接拉低总体

Lanota 没有负数机制，最低就是 0，相比之下宽容很多

3. 总 Rating

总 Rating = ( B30 + R5 ) ÷ 35

B30：历史上单曲 Rating 最高的 30 首之和
R5：最近 15 次游玩里 Rating最高的 5 首之和

B30 是长期积累，R5 是近期

相比 Arcaea 的 PTT 同样是 B30 + R10 的结构，逻辑和 Lanota 几乎一样，不过 R 的数量不同。这套历史最佳 + 近期成绩的双轨制确实已经成了很多音游 Rating 系统的主流方案

3.1 R5 保护机制

R5有保护机制，当打出新纪录、或者 Harmony 率到 95% 以上时，如果这次成绩会把rating 更高的曲目挤出 R5，那它就不更新 R5

游戏不会因为你去练新曲而惩罚你的 Rating

noxy的这个设计对玩家可以说非常友好，不会因为你练习打的不好就狂扣你的Rating。lanota和arc同样有扣分机制，la侧就没有断网保分的说法

4. 结

简单对比一下

osu! 的早期设计连击分权重很高，ScoreV2 的出现是对这个方向的修正，毕竟长歪了

Arcaea 和 lanota同样是准度要求高，但arcaea惩罚机制要狠一些，lanota则更加宽容友好。lanota毕竟比较侧重沉浸感，noxy在设计分数系统的意图可以说很明显了

顺便引流下: lanota分数计算器

全球铁路网？浅谈2026年WEB3主要区块链网络

Chongxi — Sun, 15 Mar 2026 20:57:11 GMT

0. 引

在2025年11月时，我在blog中曾写道

(web3) 它混乱、野蛮、充满骗子和强盗。但它脚下确实埋着石油和黄金，而且铁轨已经铺好

现在看，用各种私铁拼起来的全球铁路网来形容现在的 Web3，简直是神级比喻

如果我们把视角切回到纯粹的基础设施架构，在2026年的今天，这个由无数个状态机、共识算法、跨链桥拼凑起来的异构网络，真实面貌是非常赛博朋克的

以前大家总幻想最后会有一个大一统的完美公链（所谓的以太坊杀手、终极Layer1一类的说法）来统一全球。但到了现在，我们早就认清了现实：秦始皇那种车同轨书同文的完美大一统是不存在的

现在的 Web3，就是一个各种项目方、资本各自修私铁，然后靠无数个中转站和统一标准强行拼凑起来的超级全球铁路网

1. Layer 1

Layer1算是主链。这几条是最底层、最粗的铁轨，但它们现在干的活完全不一样了

1.1 Ethereum 以太坊

现在已经没几个普通人直接在以太坊主网上玩了。它的区块空间太贵，就像是全球金融系统最底层的 Fedwire美联储电汇。

现在上面跑的主要是华尔街的 RWA（代币化国债）、各大 Layer 2 的状态证明、几亿美金的机构级 DeFi 清算。它又慢又贵，但它是全网的安全基石，是防弹装甲火车

1.2 Tron 波场

没人在波场上谈高大上的技术革命，他的技术甚至有点老旧。但它极其耐操、极其便宜。上面跑满了像USDT这种的稳定币

波场每天主要在拉美、非洲和东南亚的各种老板之间来回穿梭。它是整个Web3目前货运量最大、最接地气的生命线

1.3 Solana

这是铁路网中的磁悬浮。他极速、单体架构、不支持分层。上面全是高频交易的散户、Memecoin绞肉机，以及 AI Agent 自动发出的微小支付指令。

虽然偶尔还会有个小故障，但工程师们通过 Firedancer（独立验证者客户端）等技术把它硬生生优化到了极致，满足了人类对即时反馈的贪婪

Layer 2 / Layer 3

在25年11月那篇blog，我曾说过要修铁路，但目前来看，铁路已经够多了，出现了运力严重过剩与轨距不一的问题

在2024到2025年，Web3 经历了一场造轮子大跃进。因为有了 Rollup 这种技术栈（OP Stack, ZK Stack），发一条链的成本降到了只要几分钟

结果就是，大家全去搞 Layer 2 了（Arbitrum, Optimism, Base, Blast, Mantle...简直是报菜名一般的）。每个资本、每个大交易所都要修一条自己的私铁

这导致了极其严重的流动性割裂。你的 USDT 在 A 链上，想去 B 链买个东西，就像坐火车从俄罗斯到中国，因为轨距不一，必须在边境下车，把货物卸下来，换一种车厢再装上去（这就是跨链桥）

现在的情况就是，铁路修得比乘客还多，各种私铁互相抢客源。这就是卖铲子和修铁路的产能过剩

3. 真正工程突破：链抽象

面对几百条互不相通的私铁，我们没有去强行拆铁轨，而是做了一个极度务实的架构升级：在所有私铁上面，盖了一层全局路由网络。这就叫链抽象

在以前，用户要配置 RPC 节点、要买不同链的 Gas 币、要自己找跨链桥、要承担资金被黑客半路劫走的风险
而现在你只需要一个智能钱包。钱包背后的 Solver（求解器网络） 和 跨链消息协议（如 LayerZero, CCIP） 会在一秒钟内自动帮你规划路线、垫付各种乱七八糟gas、完成跨链兑换

用户根本不知道自己跨越了哪几条底层私铁，不用管是宽轨还是窄轨，只要把钱付了，货物就送到了。底层的私铁被彻底抽象掉了

这就是链抽象的终极目标：用户只需要知道自己想做什么，不需要知道在哪条链上做。链变成一个对用户透明的基础设施

我觉得这是web3走向大众的关键一步

4. 账户抽象 ERC-4337 普及

记得以前搞个 Web3 钱包，必须拿笔记下 12 个毫无逻辑的助记词吗？丢了就倾家荡产，太反人类了

而现在我们有了智能钱包，我们直接用Passkey技术，只需要Google或者Apple ID就能直接创建钱包

以前你去买东西，必须用特定的ETH / SOL。现在你随便给什么稳定币，或者应用开发商为了拉客直接帮你把gas付了

5. 结

如果你现在再来看我说的这片1840年的荒原，你会发现一个很有意思的现象：

在现在，那些天天把 Web3、去中心化挂在嘴边的人变少了 因为这项技术终于像 TCP/IP 一样，沉下去了

这个拼凑起来的全球铁路网依然不完美，跨链桥偶尔还会被黑客当张作霖炸（虽然被盗金额在急剧下降），有些垃圾私铁上跑着的全是骗子专列

但对于我们这些写代码的人来说，这套东西终于到了API 可以被丝滑调用的阶段。无论是把美债 Token 化、让跨境电商秒级结汇，还是在云端租算力付钱，这套基于密码学的全球状态机都已经做好了准备，并在全天候无休止地吞吐着包

我们不再需要向大众解释什么是区块链，就像我们不需要向卖菜的大妈解释什么是 HTTP 一样。铁路修好了，调度系统跑通了，接下来，就是安安静静地看着这套系统，去侵蚀传统金融和跨境数据流转的版图，这就是web3在2026年存在的意义

QQ走mipush推送服务会检测root

Chongxi — Sun, 08 Mar 2026 19:21:11 GMT

挺抽象的，在此之前我从来没考虑过是root的问题

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

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

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

三星极致的软件模块化：图形驱动居然是个apk

Chongxi — Sun, 01 Mar 2026 18:31:11 GMT

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，这其实不难理解

Samsung Game Driver - Adreno，是专门给搭载骁龙处理器的 S20/Note20 系列用的
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 就能冒充的

元数据声明三星发布的 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 是关键，它让系统知道他是货真价实的库

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，我们下期再见

舞萌DX报错8103/8106以及0949问题原因分析和解决方案

Chongxi — Fri, 27 Feb 2026 08:11:10 GMT

:::caution 紧急通知，0949是SEGA改bl服务器导致炸机，全国性，SEGA全系用了bl的都会死

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健康连接

Chongxi — Wed, 25 Feb 2026 23:27:11 GMT

0.1 引

三星可以说是锁区比较严重的手机厂商了，国区三星被限制了许多功能，比如三星健康的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. 开启开发者模式

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

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

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

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

感谢网友 kkkk 对新版本三星健康的补充

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

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，按照要求即可

再次进入三星健康时，会重新要求同意隐私协议等，务必选择同意
随后打开设置，即可看见健康连接的选项，进入授予权限即可

为什么「己所不欲勿施于人」是人类有史以来最冠冕堂皇的逃避借口

Chongxi — Tue, 24 Feb 2026 14:16:18 GMT

0.1 引

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

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

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

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：己所不欲，勿施于人。我只是好心提个建议问一句。如果你向别人提问，你也不想被当成低能吧？
路人：己所不欲，勿施于人。各位肯定不喜欢这种充满攻击性和戾气的沟通环境。
我：己所不欲，勿施于人。我讨厌的就是讨论技术问题时被别人道德绑架，不看客观事实只谈主观情绪
管理：别吵。己所不欲，勿施于人。我不想看你们在这儿嗷嗷叫。既然我不想看，那就勿施于我（全体禁言）

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

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

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

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

7. 如何应对

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

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

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

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

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

8. 结

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

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

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

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

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

为什么舞萌机台老断网？一文解决近期舞萌服务器问题的所有疑惑

Chongxi — Fri, 20 Feb 2026 02:16:17 GMT

有时候，你mai的事情真的能给我看力竭

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还是做工具，我仅仅只是一位稍微懂点计算机技术想给社区为爱发电而已，大家总归都是热爱这个游戏的，没必要因为这些而吵架吧

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

36年回顾：互联网前端发展史

Chongxi — Sun, 08 Feb 2026 02:11:17 GMT

学习计算机科学就是在学习计算机历史

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

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

HTML：一种简单的标记语言，用来描述文档的结构（标题、段落、列表）。这里你要注意的是，它只负责结构，不负责好看
HTTP：一种无状态的传输协议。你请求一个文档，服务器给你，然后连接断开。这种阅后即焚的特性决定了 Web 最初只是一个图书馆，而不是「操作系统」
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战略：

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

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

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

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

而在 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 的天下...吗？

至此，前端已经拥有了：

交互能力
数据标准
开发工具
标准库
高性能引擎

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

接下来咱就要讲工程化与架构革命，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 带来了两个震撼世界的概念：

双向数据绑定：
```
<input ng-model="username">
<h1>Hello, {{ username }}</h1>
```
你在输入框里打字，下面的 <h1> 里的文字实时跟着变
不需要写任何 JS 事件监听代码 这在当时简直是魔法
依赖注入：你想要用 $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 的书写习惯（就近依赖）

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

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

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

但是，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：

快照：每次状态变了，我都在内存里生成一棵新的虚拟 DOM 树（纯 JS 对象）
对比：我用高效的算法（O(n)）对比新旧两棵树，找出哪怕一个属性的变化
修补：我只把变化的这一点点应用到真实的浏览器 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，不前端逐渐成为了行业共识

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

组件化框架
类型系统
构建工具
现代语法

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

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

11. 静态复兴

11.1 SPA 的代价

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

TTFB：用户打开网页，必须先下载几兆的 JS bundle，浏览器解析完，才能渲染出第一行字。在 3G 网络下，这意味着 5-10 秒的白屏
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，硬生生盖出了一座摩天大楼

仅使用iPad从0搭建hexo个人blog建站

Chongxi — Mon, 02 Feb 2026 16:13:21 GMT

0. 引

得益于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框架的纵向对比

bakapiano查分器使用教程(maimai score hub)

Chongxi — Wed, 28 Jan 2026 00:04:01 GMT

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会补充更新

本站已入驻爱发电平台

Chongxi — Mon, 26 Jan 2026 21:48:22 GMT

爱发电主页

CEPATO

舞萌DX水鱼查分/落雪查分成绩上传同步教程

Chongxi — Sat, 24 Jan 2026 23:31:12 GMT

0. 引

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

1. 水鱼查分器

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

前置前提:水鱼账号

水鱼查分器官网

1.1 Windows/MacOS 代理同步

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

1.2 iOS/iPad 代理同步

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

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

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

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

启动代理

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

1.3 使用union从落雪sync到水鱼

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

同时拥有水鱼/落雪账号，且落雪账号已同步
登录union站点
在右上角菜单中选中用户选项，填入落雪查分器token和水鱼账号

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

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

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

1.4 使用科技功能的bot上传

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

2. 落雪查分器

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

确保你有一个落雪账号

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

登录落雪查分器官网，点击左上角菜单，选中同步游戏数据
您可以手动在系统设置的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或其他支持的代理工具
点击底栏的配置，点击右上角加号粘贴链接
直接启动即可 :::

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

3. 附

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

什么是发币？一文看清区块链同质化代币骗局

Chongxi — Sun, 11 Jan 2026 01:35:21 GMT

0. 引

最近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币时：

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

2.2 庄家视角

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

进入发币平台：连接钱包，选择“创建交易对”
注入资产：
- 资产 A：放入 1,000,000 个 CEPATO Coin（空气）
- 资产 B：放入 1 个 ETH（真金白银）
定价诞生
- 此时，通过除法，初始价格被物理锁定为：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 重仓买入

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

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

3.2.2 三明治攻击

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

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

机器人的操作流程如下：

第一口：机器人检测到你的滑点容忍度，发起一笔巨额买单，Gas 费拉满，强行插队在你前面买入
- 币价瞬间暴涨，刚好卡在你设置的 10% 滑点极限
中间层：轮到你的交易执行。因为价格还在你的接受范围内（虽然是最高点），你的交易成交了
- 你的大额买入，把本来已经暴涨的价格，又往上推了一截
第三口：机器人发起一笔卖单，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 的“代币经济学”，在剥离了那些高大上的术语后，剩下的大多是博傻游戏

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

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

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

4.1

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

舞萌国服1.53补丁更新内容速览

Chongxi — Tue, 06 Jan 2026 22:35:21 GMT

时间紧任务重

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

Samsung S20刷入类原生EvolutionX以及kernel SU全步骤教程(SDM-G9810)

Chongxi — Wed, 31 Dec 2025 22:18:00 GMT

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. 买家秀

关于熊谷凌“Feistel加密方案”的智力缺陷鉴定

Chongxi — Sun, 28 Dec 2025 23:49:00 GMT

简直是送命题

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 技术还是没法治好人类的脑萎缩。 别混计算机科学了，去拧螺丝吧，那个不需要逻辑，只需要力气

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

如何给你的bot添加华立服务器状态检测

Chongxi — Wed, 24 Dec 2025 21:00:00 GMT

NoneBot Plugin: Maimai Monitor

一个为 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，不要泄露给任何人。

环境变量

环境变量	类型	默认值	说明
`MAIMAI_BOT_CLIENT_ID`	`str`	无	ClientID (必要)
`MAIMAI_BOT_PRIVATE_KEY`	`str`	无	私钥 (必要)
`MAIMAI_BOT_DISPLAY_NAME`	`str`	`qwq`	您bot的名称
`MAIMAI_WORKER_URL`	`str`	`https://maiapi.chongxi.us`	上报数据后端的 API 地址
`COMMAND_ALIASES`	`Dict[str, str]`	`{}`	自定义命令别名，用于将简洁命令映射到报告指令

`.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

Chongxi — Sun, 21 Dec 2025 00:46:00 GMT

本文是根据苏联笑话改写的舞萌笑话，随意转发二创，允许投稿到舞萌春晚等类似节目，但请标注作者和原文地址链接，感谢

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投稿，过审后将会在第二个合订集收录，感谢支持

如何使用水鱼/落雪查分器备份舞萌DX成绩

Chongxi — Fri, 19 Dec 2025 23:21:22 GMT

成绩更新教程请看: 舞萌DX水鱼查分/落雪查分成绩上传同步教程

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

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

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

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

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

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

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

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

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

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

:::yellow[how to do]

如果我发现我的游玩记录已经被扫了怎么办
首先，不要同步水鱼成绩，直接点开水鱼官网备份数据，这里的备份大概率是干净的，如果你没有同步
水鱼页面打不开
因为跑去备份的人多，而且可能有人在攻击水鱼服务器，这个暂时不清楚，我建议期间不要同步水鱼成绩，丢一两个成绩没传无所谓，坐和放宽等一会，兴许就能进去了
如果我非要点二维码同步查分器咋办
也不是不行，但是风险极高，你可以在点二维码前，先备份一次数据，这能保证你至少有一个安全的备份可以回退，然后再点二维码同步查分器，既满足了你的反骨需求也能保证你有一个能用的备份 :::

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

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

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

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

1. 水鱼查分器

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

2. 落雪查分器

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

3. 部分需要关注的地方

单纯不获取二维码目前貌似已经无法阻拦扫号，备份成绩是目前最有效的最坏方案
我不推荐您使用各种来路不明的小众bot，这里只给出了主流的两家查分器原因就在这里，他们本身就易用且积累了一定的权威可信度，国服备份数据首选这两家主流查分器绝对是最优选择
关于0010，如果你的账号里被挂哥发了机台不存在的东西，就会爆炸，比如提前给你发了下个版本的旅行伙伴，你上机的时候机台并没有那个版本的资源，就会爆炸，大多数情况下是这样，也有其他情况
待补充，我会根据广大舞萌群里的常见的提问对本文进行补充

4. 引流

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

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

仅用Android手机拯救Linux主机，带你深入了解USB Gadget

Chongxi — Tue, 16 Dec 2025 16:34:26 GMT

0. 引

首先介绍一下本期主角，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攻击过程如下

将攻击设备插入主机
攻击设备向主机声明他是U盘，主机信任并加载
攻击设备主动断开连接，并以HID的声明重新连接，主机并不会校验他到底是不是键盘，会直接加载驱动，无任何防备接受一切来自此设备的输入
攻击设备开始向主机注入命令（如启动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. 我是如何救砖的

确保你的android手机已root，安装前文的两个开源工具，在Gadget Tool中授予su权限，并勾选启用HID Keyboard，便完成了Android设备模拟成键盘的操作
使用数据线将Android设备接入ubuntu主机，此时手机会被识别成输入设备，当你按下HID Keyboard提供的软键盘时，是能够看到IO灯闪烁的，接下来的诊断完全是靠IO灯判断的
尝试输入密码并等待十秒，建议直接使用root账号，可以省去sudo的麻烦，~~这种情况在乎用户组安全没啥必要~~，随后执行ls观察IO灯是否剧烈闪烁，如果剧烈闪烁则说明ls成功提供了输出，为了稳妥起见，这里决定reboot一下，主机重启，说明我们登录操作没问题
Chongxi这里是提前准备过一个恢复脚本，防止这种铸币情况，主要功能是恢复原来的网卡备份的内容。再次通过io灯判断输入，直接执行恢复命令，主机重启，打开openwrt，发现ubuntu对应的LAN口开始有正常流量通信，ssh可以正常连接，救砖成功

4. 结

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

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

什么是web3？从状态机到去中心化金融，带你认识最清晰的Web3本质

Chongxi — Mon, 24 Nov 2025 10:34:39 GMT

0. 引

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 树由四种节点拼凑而成：

Leaf Node (叶子节点): [Key, Value]。这是真正存数据的地方（比如你的余额）
Extension Node (扩展节点): [Shared Key, Next Node Hash]
- 如果一堆地址都是 0xabc... 开头，我们不需要存一万次 0xabc，只存一次，下面挂一个指针。这叫路径压缩
Branch Node (分支节点): 一个长度为 17 的数组
- 前 16 个对应十六进制的 0-f
- 决定了路径是往 0 走还是往 f 走
Null Node: 空节点

2.3 状态更新

当你修改余额时：

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

3.EVM 的微观执行

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

3.1 内存模型详解

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

Stack (堆栈):
- 结构: LIFO (后进先出)，最大深度 1024
- 作用: 所有的计算（加减乘除）都在这里发生
- 指令: ADD 从栈顶拿两个数，相加，结果推回栈顶
- 特性: 几乎免费（Gas 极低），但随着函数结束消失
Memory (内存):
- 结构: 线性字节数组
- 作用: 临时存放字符串、数组、返回值
- 成本: 它是按平方计费的，你申请的内存越大，Gas 呈指数级上涨（防止你把节点的 RAM 撑爆）
- 特性: 交易结束后数据清零
Storage (存储):
- 结构: 键值对映射 (Key-Value Map)
- 作用: 永久写入区块链状态（MPT 树）
- 指令: SSTORE (写), SLOAD (读)
- 成本: 天价。写一个非零值会需要 20000 Gas
- 特性: 永久保存，全网同步

3.2 具体指令的执行流

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

PUSH1 0x05 (把数值 5 推入栈) -> Stack: [5]
PUSH1 0x03 (把数值 3 推入栈) -> Stack: [3, 5]
ADD (加法操作)
- CPU 弹出 3 和 5。
- 计算 3+5=8。
- 把 8 推入栈。
- Stack: [8]
PUSH1 0x00 (准备存到 Slot 0) -> Stack: [0, 8]
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 编码）：

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

4.3 签名原理

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

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

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

5. 共识层

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

5.1 验证者工作流

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

质押 Staking: 你必须把 32 ETH 锁进存款合约。这笔钱是你的人质
随机抽签 Randao: 系统每 12 秒随机选出一个 提议者 Proposer 又称矿工
提议: 被选中的人打包交易，广播新区块
见证 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 贩卖机模型

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

传统交易（Web2/柜台）：你把钱给售货员 $\to$ 售货员确认金额 $\to$ 售货员拿可乐给你 $\to$ 找零。
- 风险：售货员可能拿钱跑路，可能算错账，可能不想卖给你
智能合约（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);
    }
}

部署：当你把这段代码通过钱包发送到区块链时，它会被编译成字节码 (Bytecode)（一堆机器才看得懂的 60806040...），并分配到一个以 0x 开头的合约地址
- 从此，这段代码无法修改，无法删除
调用：当你在这个合约上点击存钱按钮时，其实是向这个合约地址发送了一笔交易
- EVM会被唤醒
- 它加载这个合约的代码
- 它执行 deposit 函数
- 它修改 balance 变量的状态
- 全网所有节点同步更新这个变量
不可篡改：注意 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 总额了一旦触碰设定的数学红线：

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

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

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 马上要归零了

你抵押 1000 USDC（真金白银）
借出 100 个 A（价值 800 USDC）
立刻去交易所把这 100 个 A 卖掉，换回 800 USDC
- 现在你手里有：1000 抵押 + 800 现金 = 1800 资产
- 你欠协议：100 个 A
等待 A 暴跌 50%
你花 400 USDC 就能买回 100 个 A
把这 100 个币还给协议
你当初卖了 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.05），允许任何人调用 liquidate() 函数
巡逻：全世界有成千上万个 24 小时运行的脚本，它们时刻监听着链上的每一个借贷账户
发现：当你的 BTC 价值跌到红线那一瞬间，这几千个机器人会像鲨鱼闻到血腥味一样，争先恐后地向智能合约发送交易，试图触发 liquidate 函数
处决：
- 机器人帮你是还一部分欠款（比如还 40 块）
- 作为回报，合约会把你的 BTC 以打折价（比如 5% - 10% 的折扣）卖给这个机器人
结局：
- 协议收回了欠款
- 机器人赚到了差价（比如它花 40 块帮你还债，拿走了价值 44 块的 BTC）
- 你的 BTC 被低价强制卖掉了，你亏大了

清算你的没有官方，而是为了赚取那 5% 罚金的第三方套利机器人。这是一种基于贪婪的自我维护系统

7.6 闪电贷

在 Web3 里，只有一种情况你可以不抵押一分钱就借走几个亿。这叫闪电贷 这也是很多黑客攻击的手法

但它有一个极其硬核的物理限制：原子性 Atomicity

你写一个智能合约，包含三步逻辑：

向 Aave 借 1 亿美元（无抵押）
拿这 1 亿去炒作、套利、搬砖（随便你干什么）
在同一笔交易结束前，必须连本带利把钱还回去

如果你在第 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

你给合约发了若干 USDC（设为 $\Delta y$）
你想拿走 1 个 ETH ($\Delta x = 1$)
计算:
- 池子剩下的 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 架构设计

链上部分: 一个简单的存储合约

contract PriceFeed {
    int256 public price;
    function updatePrice(int256 _price) public { ... }
}

链下部分 Oracle Nodes: 几百个独立运行的服务器，监听交易所 API

9.2 数据上链流程

聚合 Aggregation: 21 个节点分别从币安、Coinbase 获取 ETH 价格
- 节点 A: 3001
- 节点 B: 3002
- 节点 C: 2999
- ...
共识: 它们在链下（Off-chain P2P 网络）对数据进行签名，取中位数。中位数能过滤掉个别恶意报价
写入: 一个指定的节点把这一包带有 21 个签名的最终数据，发送给链上合约
验证: 链上合约验证签名数量是否达标，然后更新 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;
}

攻击原理:

黑客写了一个恶意合约
黑客调用 withdraw()
目标合约执行到 msg.sender.call（转账）时，会触发恶意合约的 fallback 函数
恶意合约的 fallback 函数里写了一行代码：再次调用目标合约的 withdraw()
此时，目标合约的第 2 步（余额归零）还没执行，所以 bal > 0 依然成立
结果: 像递归一样，黑客把钱提了一次又一次，直到把池子提空，最后才执行余额归零

如何防御？: checks-effects-interactions 模式（先扣款，再转账）

11.2 抢跑与三明治攻击 MEV

内存池 是完全公开的。矿工/验证者就像拥有上帝视角

你发了一笔交易：用 1000 USDC 买 ETH。这笔大单会把 ETH 价格推高 1%

攻击者 (Searcher Bot) 监测到了这笔交易：

抢跑 (Front-run): 机器人发一笔交易买入 ETH，并将 Gas 费设得比你高。矿工会先打包它的交易。
- 结果机器人把你买入前的价格抬高了
你的交易执行: 你以更高的价格买入了 ETH（你亏了）。价格进一步拉高
夹尾 (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 卖给别人呢？

这里用到了一个类似房屋中介的机制：

授权： 你第一次上架时，钱包会弹窗让你点确认。这一步其实是在链上签了一份委托书：

我授权 Opensea 这个中介，可以随时动用我钱包里的这张名为 #8888 的房产证
签名： 你填个价格：10 ETH 这一步其实是你写了一张条子：

谁给我 10 ETH，中介就把房产证给他这张条子没上链，只是贴在了 Opensea 的服务器上（为了省手续费）
成交： 买家来了，看中了。买家把 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

逃离简陋 Chrome：Android Firefox 调教指南

Chongxi — Fri, 21 Nov 2025 17:19:27 GMT

0. 引

最近，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]

设置 -> 防止 WebRTC 泄露本地 IP 地址 & 我是高级用户 启用
规则列表 -> (如下图设置) 如果你有别的语言浏览需求，可以在区域里启用对应语言规则

如果有些网站无法工作，可以对其添加白名单 :::

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]

选择要伪装的浏览器，如Chrome
勾选将当前操作系统与生成的用户代理同步
不建议伪装成Desktop Windows，网页会变成电脑版，在手机上操作体验极差 :::

2.5 沉浸式翻译

目前体验最好的网页双语对照翻译工具

没啥好配置的，开箱即用

3. 结

虽然Firefox在Android上的js跑分偶尔不如V8引擎那么激进，但为了那一份属于数据主权以及高度的可玩性，这极小的性能代价是完全值得的，Chrome有多简陋是有目共睹的

现代SEO深度解析：原理、算法与实战

Chongxi — Sun, 09 Nov 2025 22:02:03 GMT

0. 引言

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是指搜索引擎对网站进行抓取的时间和资源限制。它由两部分组成：

抓取率限制Crawl Rate Limit：指搜索引擎对你服务器的抓取频率限制。如果你的网站服务器响应很快，没有大量的404或5xx错误，爬虫就会抓取得更频繁
抓取需求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 文本预处理流水线

抓取到的网页内容会经过一系列处理：

内容提取：剥离广告、侧边栏、页脚等模板化内容，专注于核心正文
分词Tokenization：将文章内容分解成一个个单独的词元token。例如，中文小米路由器刷openwrt会被分割为小米,路由器,刷入,openwrt
标准化：包括转小写、词形还原（如"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：

词元 `Token`	包含该词元的文档ID列表 `Posting List`
`arch`	`[1, 2]`
`linux`	`[1, 2, 3]`
`steam`	`[1, 3]`
`指南`	`[1]`
`游戏`	`[3]`
`安装`	`[2]`

现在，我们来看当用户进行不同搜索时，倒排索引是如何工作的：

场景一：简单查询

当用户搜索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 排序的多阶段漏斗模型

以下内容在前文已提及，这里作简单概述

排序过程可以看作一个漏斗模型，逐步筛选和精化结果：

召回 Recall：通过倒排索引和向量索引，从亿万文档中找到几千个最相关的候选文档
初排 Coarse Ranking：使用计算开销较低的算法（如 BM25）对候选文档进行初步评分，筛选出几百个最有潜力的结果
精排 Fine-grained Ranking：使用复杂的机器学习模型，综合数百个信号对候选文档进行进一步的精准排序
重排 Re-ranking：在精排基础上，根据用户的个性化需求、时效性等因素对结果进行最后的微调

3.2 初排核心算法：BM25

BM25 是搜索引擎常用的一种初排算法，它基于概率模型来估算文档与查询之间的相关性，是TF-IDF的改进版

:::blue[EXAMPLE] 查询：OpenWrt 配置代理服务

文档A：如何在 OpenWrt 上配置代理服务，1500字，关键词"OpenWrt"、"代理服务"出现了10次
文档B：OpenWrt 基础设置指南，篇幅8000字，也提到了"代理服务"几次，但更多篇幅在讲DHCP、DNS等

BM25如何评分：

词频 (TF)：文档A中关键词频率更高，得分会更高。
文档长度：BM25会惩罚过长的文档。文档B虽然也包含关键词，但因为它篇幅太长，主题不够集中，其分数会因此被拉低，避免了长文档因包含更多杂乱关键词而获得不公平的优势
词频饱和度：文档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。它不再只关心谁投了票，更关心：

投票的上下文相关性 Topical Relevance 现代模型如何思考：一个链接的价值，很大程度上取决于它所在的页面的主题

:::blue[EXAMPLE] 一个来自 Arch Linux中文维基 页面上指向你 Arch Linux安装指南 的链接，其价值远高于一个来自 美食博客大全 的链接，即使后者的传统意义上PR值可能更高

因为前者可以告诉Google：一个Linux领域的权威，推荐了另一个Linux领域的资源
这是一个高度相关的且专业的背书 :::

链接周围的环境 Surrounding Context 现代模型如何思考：链接周围的文本，这个链接是编辑精心放置在正文中的，还是藏在网站页脚的一堆链接？

:::blue[EXAMPLE] 高价值： 在一篇评测OpenWrt路由器的文章正文中，作者写道：关于旁路由的详细配置，我强烈推荐大家参考不良林上的这篇 OpenWrt旁路由超详细配置指南（链接），他把所有坑都讲清楚了~~这不是接广~~

低价值：在你朋友博客的页脚友链区域，有一个简单的锚文本链接Chongxi的blog

前者的上下文清晰地解释了为什么要推荐你，这是一个强烈的编辑推荐信号 :::

链接的用户行为 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模型会考量哪些特征（简单举例）：

BM25得分：衡量页面内容和查询的字面匹配度
外链特征：页面是否有来自Arch Linux官方论坛、知名技术博客的外部链接？这些链接的锚文本是什么？
用户行为信号：当这篇文章出现在搜索结果中时，它的历史点击率是多少？用户点击进来后，平均停留了多长时间？是很快就返回(Pogo-sticking），还是看完了再走(Long Click)
内容质量特征：文章是否详细、有深度？是否提供了清晰的代码示例？是否图文并茂？是否体现了作者的真实经验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">来阻止索引 :::

何时使用，如何选择

属性组合	使用场景	核心目的
`rel="sponsored"`	广告、赞助文章、付费评测等任何你因金钱交易而放置的链接	保持商业诚信。
`rel="ugc"`	博客评论、论坛帖子、用户签名等所有由用户生成的内容中的链接	防止链接污染，保护网站声誉
`rel="nofollow"`	当你链接到一个网站，但完全不想为之背书，且它不属于`sponsored`或`ugc`时。这是个通用备选项。	声明中立，不传递PageRank
不使用任何属性	（默认的"dofollow"链接）当你真心实意地推荐一个高质量、相关的外部资源时	传递权重，为互联网贡献价值，建立关系

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 的文章。与其只用文字描述，不如：

嵌入你自己录制在视频网站上的手元视频链接
贴上你自己的成绩图
分享一个别人没提过的冷知识："其实这首曲目在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 的组件，本质上是一个无头浏览器。抓取流程分为两波：

第一波：Googlebot抓取你的原始HTML，如果内容都在HTML里，它会立刻被送去索引
第二波：如果页面需要JS来生成内容，这个页面会被放入一个渲染队列。几天甚至几周后，WRS才会执行JS，渲染出最终的DOM，然后将渲染后的HTML送去索引

9.1.1 客户端渲染 `Client-Side Rendering`

服务器只返回一个几乎空白的HTML壳子和一个巨大的JS包。浏览器（或WRS）下载并执行JS，然后通过API请求数据，最终将内容渲染到页面上。这是create-react-app或vue-cli默认的模式

:::yellow[特性]

索引延迟：你的内容需要排队等待第二波渲染，收录速度可能极慢。对于新闻或时效性强的内内容是致命的
渲染失败风险：如果你的JS代码有bug、网络请求超时、或者过于复杂导致WRS执行超时，渲染就会失败。结果就是，Google索引的是一个空白或不完整的页面
抓取预算消耗：渲染需要巨大的计算资源，这会消耗你的抓取预算。Google可能不愿意为一个需要复杂渲染的小网站投入太多资源 :::

9.1.2 服务端渲染 `Server-Side Rendering`

用户的请求到达服务器后，服务器在后端执行React/Vue代码，获取数据，生成完整的HTML，然后将这个HTML返回给浏览器。浏览器接收到的是已经包含所有内容的页面。Next.js, Nuxt.js等框架的核心功能就是SSR

:::yellow[特性]

即时索引：Googlebot在第一波抓取时，就能拿到包含所有内容的完整HTML，无需等待渲染，索引速度极快
高可靠性：避免了客户端环境的各种不确定性
更好的性能指标：通常有更快的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到底看到了什么？不要猜，要用工具验证

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控制台有无错误等信息，是排查渲染失败的直接线索 :::

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 指南</span>

// ×××××爆赞×××××
<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]

响应式图片 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防火墙配置的后台截图">

这能确保手机用户不会被迫下载桌面端的大图，极大提升移动端加载速度

新一代图片格式
尽可能使用WebP或AVIF格式。它们在同等视觉质量下，文件体积通常比JPEG或PNG小30%以上
懒加载
对于非首屏的图片，使用原生的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 视频托管

YouTube
YouTube本身就是巨大的流量来源，上传到YouTube的视频，在Google搜索中天然有更高的展示权重，无需担心带宽和播放体验
bilibili等视频平台
更适合中国大陆的用户群体，无需担心带宽和播放体验
自托管：完全控制，无广告，可以自定义播放器，但你需要自己处理视频托管、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]

在你的YouTube视频的描述区，按照时间戳 + 章节标题的格式，写下你的视频章节
必须从00:00开始

至少需要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不会只听你的一面之词。它需要从它已经信任的、中立的第三方数据源中，找到关于你的信息来交叉验证

寻找种子站点 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[特性]

解决重复内容问题：
避免Google将你的《Arch Linux Installation Guide》的英文版和日文翻译版视为内容抄袭
提供正确的搜索结果：
确保日本用户在google.co.jp上搜索时，能看到你的日文版文章，而不是英文版 :::

:::red[实现规则] 以下实现极其严格，错一不可

相互引用 Reciprocal：
如果页面A链接到页面B，那么页面B也必须链接回页面A
自引用 Self-referential：
每个页面都必须有一个指向自己的hreflang标签
包含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地图和本地搜索结果包中的官方名片。你必须像对待你的网站一样，精细化地优化它

信息的准确与一致性

NAP 指的是 Name, Address, Phone 这三个信息，必须在你全网所有的商业信息中，保持100%的、字符级的完全一致

:::blue[EXAMPLE]

你的GBP名称、官网联系页、本地行业网站上的公司名，是否完全一样?
- XX科技和 XX科技有限公司在算法眼里就是两个不同的实体
地址的写法是否统一？
- 人民路123号 & 人民路123号
电话号码格式是否一致？ :::

NAP的全局一致性，是Google用来验证你业务真实性的核心信号。任何不一致都会让它对你的实体信息产生怀疑

GBP分类

如果你有一个主要类别和多个次要类别。主要类别应选择最能代表你核心业务的那个

:::blue[EXAMPLE]

一个主要卖openwrt路由器技术支持服务的公司，主要类别应是 IT顾问或计算机支持与服务
一个舞萌DX机厅，主要类别是游乐中心或电玩城

尽可能详细地选择所有与你业务相关的次要类别 :::

评论评论的数量、星级评分、以及评论内容中出现的关键词，都是强烈的排名信号 :::blue[EXAMPLE]

主动索要评论：在服务完成后，通过邮件或短信，礼貌地邀请满意的客户留下评论，并可以直接提供你的GBP评论链接
回复每一条评论：无论是好评还是差评，都要专业、及时地回复。这向Google和用户展示了你的积极和负责。在回复中，可以自然地再次提及你的服务或产品名称 :::

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 理解语音搜索查询的特点

更长、更口语化：语音查询平均更长，通常是完整的问句
意图更明确：通常是寻求一个直接、简洁的答案
本地属性强：大量语音搜索与“附近的...”相关

14.2 精选摘要

精选摘要是出现在Google搜索结果最顶部的、一个直接回答用户问题的特殊信息框。语音助手（如Google Assistant）在回答问题时，通常会直接朗读精选摘要的内容。 因此，赢得精选摘要，就等于赢得了语音搜索

:::blue[EXAMPLE]

识别问题类查询：用GSC或第三方工具，找出你的网站已经排在第一页的、以“如何”、“是什么”、“为什么”开头的查询
提供简洁、直接的答案：在你的文章中，紧跟着问题标题（H2/H3），用一段话（通常在40-60个词之间）直接、清晰地回答这个问题

比如

H2：<h2>什么是OpenWrt的旁路由模式？</h2>
紧随其后的段落：<p>OpenWrt的旁路由模式，指的是在不改变现有主网络结构的前提下，将一台运行OpenWrt系统的设备作为旁路网关接入局域网。它不负责主要的路由和DHCP功能，而是专门处理特定任务，如广告过滤、科学上网或网络加速，实现对全屋设备的透明代理
这个段落的结构和长度，就是精选摘要的完美候选者

使用有序/无序列表：对于步骤或列表类问题，使用<ol>或<ul>标签来组织内容
利用FAQPage Schema：为页面上的问答内容部署FAQPage Schema，可以增加你被选为精选摘要的几率 :::

14.3 让内容更具对话性

写作风格：在写作时，想象你是在直接回答一个朋友的问题。使用更自然、更口语化的语言
内容结构：多使用问答式的结构来组织你的文章

当然，注意受众，如果你的网站不需要对话式AI，那就没必要做此部分优化

15. 监控与优化

15.1 Google Search Console

GSC是Google直接提供给你的免费工具，是所有SEO工作的起点和终点。它告诉你Google如何看待你的网站

15.1.1 GSC基本设置

:::blue[基本设置]

验证你的网站所有权：登录GSC，添加你的网站域名。Google会提供多种验证方式。对于技术人员，最推荐的是DNS记录验证。你需要登录你的域名提供商（如Cloudflare），添加一条Google提供的TXT记录
这种方式一次验证，你的域名下所有的子域名和协议（http/https）都会被覆盖，一劳永逸
提交你的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]

进入“效果”报告。在下方的表格中，点击“查询 ”标签页。点击筛选器按钮（三条横线），设置排名小于 10.1（筛选出排在第一页的结果）。然后，点击表格头部的“展示次数”进行降序排列
寻找那些展示次数很高，但CTR明显低于其所在位置应有水平的关键词

排名第1的CTR约25-30%，第3约10-15%，第5约5-8%，第10约1-2%

你发现你的查询“Arch Linux i3wm 配置”每月有20000次展示，平均排名是4.5，但CTR只有2%

这意味着你的内容质量足够好，Google愿意把它排在首页靠前的位置。但是，当用户看到你的搜索结果时，他们没有选择点击你。问题99%出在你的门面上，你的<title>标签和<meta name="description">

4.立即去Google搜索这个词，看看排在你前面和后面的竞争对手的标题是怎么写的。他们是不是用了[终极指南]、[附完整配置文件]、等更吸引人的字眼？

重写你的标题和描述。不要只是Arch Linux i3wm 配置。尝试改成：从零开始的Arch Linux i3wm美化指南 (附Polybar/Rofi/Picom完整配置)
提交URL以供重新索引：修改完代码后，复制这个页面的URL，粘贴到GSC顶部的“检查任何网址”输入框中，回车。在检查结果页面，点击“请求编入索引 (Request Indexing)”。这会告诉Google你更新了页面，主动请求索引
持续追踪：在接下来的一两周内，每天回到这个报告，筛选出这个关键词，观察它的CTR是否有了显著提升 :::

:::yellow[实战分析 II]

在“效果”报告中，设置筛选器排名大于 10.1 且 排名小于 30.1
这里列出的，就是所有排在Google第二、三页的关键词。这些就是潜力股
你发现“OpenWrt DNS泄露”这个查询，你排在第18位
这说明Google已经认可了你页面的相关性，但还不足以让它登上首页。你需要给它临门一脚让他飞起来
打开你对应的文章。你是否只讲了基础配置？你能不能补充一节，专门讲如何通过iptables规则来强制接管所有设备的DNS请求，来尝试杜绝DNS泄露？你能不能加入一段关于DoH/DoT的对比和配置方法？
在你网站其他高权重的相关文章里（比如你的《OpenWrt旁路由配置指南》），找到合适的锚文本（比如“防止DNS泄露”），链接到你这篇排在第18位的文章。这相当于用你站内的明星页面给这个潜力页面投了一张信任票
如果可能的话，去相关的技术论坛（如恩山、V2EX），看看有没有人在讨论DNS泄露问题，你可以提供专业的解答，并在签名或回答中自然地附上你的文章链接 :::

15.1.3 解读Indexing

路径：左侧菜单栏 > 索引 > 网页 (Pages)

核心关注：报告分为“已编入索引”和“未编入索引”两部分。你需要重点关注“未编入索引”的原因 :::blue[EXAMPLE] 你在“未编入索引”的原因列表中，看到“已发现 - 当前未编入索引 (Discovered - currently not indexed)”下面有50个网址

诊断：这是个坏消息。意思是Google的爬虫已经发现了这些URL（通过站点地图或链接），但它认为这些页面的质量太低，以至于连进入它索引库的初审资格都没有。这可能是因为内容太单薄、与其他页面高度重复，或者是新网站权威性太低，Google不愿意分配索引配额给你

你应当

逐个审查这些URL。它们是不是你自动生成的、没有什么实质内容的标签页或归档页？如果是，让它们noindex掉
如果这些是你用心写的好文章，那问题就出在内容质量或网站权威性上。你需要：把文章写得更深入、更有见地，也可以为这些页面从站内和站外获取更多高质量的链接 :::

15.2 Google Analytics 4

GA4告诉你用户进入你的网站后都做了什么。它能帮你判断你的内容是否真的满足了用户需求

:::yellow[实战分析 I] 识别叫好不叫座的内容

路径：报告 > 互动度 > 着陆页 (Landing pages)
这个报告列出了用户进入你网站的第一个页面。默认按“用户数”排序。现在，点击表头的“平均互动时长 (Average engagement time)”进行升序排列
你发现你的《舞萌DX全曲目列表》页面，虽然带来了很多用户（用户数列前茅），但平均互动时长只有15秒
诊断：用户来了，但马上就走了

这通常意味着：

你的页面加载太慢

页面设计混乱，用户找不到想要的信息

内容虽然全面，但呈现方式很差（比如就是一个巨大的、无法搜索和筛选的HTML表格）

优化页面体验：为这个曲目列表加入客户端搜索、排序和筛选功能。让用户可以按难度、按版本、按作曲家（比如xi）快速找到他们想要的曲子
提升加载速度：如果列表包含大量图片（封面），确保它们都经过压缩并使用了懒加载 :::

:::yellow[实战分析 II] 追踪转化，找到你的现金牛

你需要先在GA4中设置“转化 (Conversions)”。转化不一定是指金钱交易。对于博客，一个转化可以定义为“用户成功复制代码块”、“用户下载了你的OpenWrt配置文件”或“用户在教程页面停留超过5分钟”
路径：流量获取 > 流量获取 (Traffic acquisition)
数据解读：查看报告，将主要维度设置为“着陆页 (Landing Page)”，并查看每个着陆页带来的“转化次数”
发现案例：你发现你的《Arch Linux安装后十大必装软件》这篇文章，带来的“复制代码块”转化次数遥遥领先，远超其他文章
诊断：这篇文章精准地抓住了用户的行动意图。用户看完这篇文章后，会立刻动手操作。这是一篇极具价值的行动指南~~抄作业~~型内容
围绕这个成功模式，创作更多类似的内容。比如 Arch Linux下最佳的5款终端模拟器配置
流将这篇高转化文章，放在你网站更显眼的位置（如首页推荐），并从其他文章中多链接到它 :::

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外链”

解构一下就是

Private Blog Network：这是最常见的一种。骗子们会去购买一堆过期但曾经有过一点权重的域名，然后用模板化的程序快速建立大量看起来“正常”的博客。这些博客的存在只有一个目的——出售链接。它们内容质量低下、主题混乱、互相链接，形成一个虚假的“权重网络”
被黑的网站：更恶劣的情况是，他们利用漏洞黑进一些正常的网站，然后在这些网站上偷偷地添加指向客户的链接
低质量的客座博客：他们会在一些允许任何人付费发布文章的低质量新闻源或博客上，发布一篇由AI生成的、语句不通的垃圾文章，并在其中插入你的链接

:::blue[Google如何把它们送上绞刑架] Google的反作弊团队拥有极其复杂的算法和人工审核流程来识别这些非自然链接

Link Graph Analysis：Google能分析整个互联网的链接拓扑。PBN网络中的网站，其链接模式通常极不自然（比如，只出链不入链，或者只在特定的小圈子里互相链接），很容易被算法识别为链接农场
锚文本滥用检测：如果一个新网站在短时间内，突然获得了大量指向它的、锚文本完全相同的（比如都是“OpenWrt路由器推荐”）外链，这是一个极其危险的信号。自然的链接，其锚文本应该是多样化的
网站质量评估：Google会评估发布链接的网站本身的质量。一个正常的网站，其内容应该是有主题、有规律更新、有真实用户访问的。而PBN上的网站，通常内容杂乱、更新停滞、没有任何自然流量
人工举报与审核：你的竞争对手，或者任何一个懂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专家还在教堆砌关键词、外链购买等操作，此篇文章就是为了极其锐利地打烂他们所谓专家的脸面

本篇与《现代搜索引擎深度解析：从原理、算法到高效检索实践》是互补的关系，强烈建议您了解前作，>点击跳转

毕竟是个人编写，精力有限，欢迎指出错误。转载请标明出处，感激不尽

三星/安卓使用透明代理模块(Surfing)无法拨打电话的解决方案

Chongxi — Sat, 08 Nov 2025 00:10:04 GMT

0. 引

相信各位折腾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. 结

本篇主要是提供具体的解决方案，关于这部分的代理知识后续可以单独分篇来讲（又挖坑）

Nekobox超简单入门指南

Chongxi — Wed, 05 Nov 2025 14:22:52 GMT

:::red[CAUTION] 本文旨在提供技术知识与软件使用方法的交流与学习，所涉及的工具与配置方法仅用于法律许可的正当用途，包括但不限于网络安全研究、数据加密通信、访问公开学术资源等。

使用者应对自身行为负全部责任。请确保在使用相关技术时遵守所在国家/地区的法律法规。任何利用本文所述技术从事违法活动的行为，均与本文作者无关。

技术本身并无善恶，关键在于使用者的意图与方式。正如教授化学知识不必为制毒承担责任，传授编程技术不必为编写恶意软件负责，本文仅止于技术探讨的边界。 :::

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 导入配置

机场用户配置指南

打开左上角侧边栏
点击「分组」
点击页面右上角进入分组设置
分组名随意填写，分组类型更改为订阅，在订阅链接中填写您机场给出的代理订阅URL。

推荐开启最下方的自动更新
selector视情况而定

点击右上角即可保存
返回主页选择节点启用即可

单个节点导入

点击主页右上角，导入配置

方法一：从剪贴板导入
示例配置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 不会自动使用这个代理。以下场景才会用到该模式

局域网共享： 在「设置」中开启“允许来自局域网的连接”，其他设备（如电脑）可以手动设置代理，地址为你手机的局域网 IP，端口在 NekoBox 的代理设置中查看
特定应用手动代理： 某些特殊应用（如 Termux、Firefox）支持手动设置代理服务器，你可以将它们指向 NekoBox 启动的本地代理。
开发者调试时使用

:::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官方文档

Changelog - 11/05/2025

Chongxi — Wed, 05 Nov 2025 09:25:30 GMT

CEPATO ver.4.1.0 - use Hexo 8.1.0

鉴于 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

修复了 Sitemap 生成问题。
为旧文章 URL 添加了 301 重定向，现在访问旧 URL 将自动跳转至新文章 URL。
修正了部分文章的元信息。

To Do

优化部分文章内容。
优化博客图片及其他资源元素。

现代搜索引擎深度解析：从原理、算法到高效检索实践

Chongxi — Sun, 02 Nov 2025 08:00:00 GMT

本文旨在系统梳理现代搜索引擎的体系结构、核心算法与信息检索方法，来源于经验及研究总结，难免有疏漏之处，欢迎指出。

本篇与《现代SEO深度解析：原理、算法与实战》是互补的关系，如果您已阅读完本文并对SEO感兴趣，可以了解后文，>点击跳转

0. 基础概念

0.1 搜索引擎定义

搜索引擎（Search Engine）是一类用于从大规模数据集中高效检索信息的系统，它主要由以下模块组成：

抓取（Crawling）：负责发现并下载互联网上的海量网页内容。
索引（Indexing）：将抓取到的内容加工，转换为能被机器快速检索的数据结构。
排序（Ranking）：根据用户提交的查询词，结合其意图，对已索引的候选内容进行重要性或相关性排序。
查询接口（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 文本预处理

原始文本在被建立索引前，要经过一系列的处理：

分词（Tokenization）
- 英文：相对简单，通常直接按空格、标点符号分割单词。
- 中文：由于词语之间没有天然的分隔符，需要进行额外的分词算法：
  - 最大正向匹配（MM）：从左向右尝试匹配词典中最长的词。简单但误差可能较高。
  - 最大逆向匹配（RMM）：从右向左匹配，通常认为效果优于正向匹配。
  - HMM（隐马尔科夫模型）：基于统计概率模型，更适合处理大规模词库和复杂语境。
  - BPE/SentencePiece：现代 NLP 的主流做法，将词拆分为子词粒度，能处理未登录词，且支持跨语言。
停用词过滤
- 去除那些常见但对搜索意义不大的词语，比如中文的的、了、是，英文的and、the、a。
词干提取（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)} $$

解释：

符号	含义	理解方式
$PR(p_i)$	页面 $p_i$ 的 PageRank 值	页面在 Internet 上的重要程度
$M(p_i)$	所有指向 $p_i$ 的页面集合	谁引用了它
$L(p_j)$	页面 $p_j$ 的外链数量	引用者贡献会被平分
$d$	阻尼系数（约 0.85）	模拟用户继续浏览的概率
$\frac{1 - d}{N}$	随机访问补偿	防止出现死链、闭环结构偏置

note

一个页面的重要性，部分取决于引用它的页面的重要性。 引用者越重要，贡献越大；引用越多，贡献越分散。

PageRank 衡量的是 引用来源的质量，而不是 引用数量。

PageRank 在现代搜索引擎中的作用

PageRank 作为 Google 早期排名核心的地位早已过去。Google 在2016年已停止公开更新 PageRank 工具栏，其原始算法在当前搜索引擎中的直接权重已微乎其微。

现代搜索引擎的排名算法极其复杂，通常包含数百甚至数千个信号，远远超出了单一的 PageRank 模型。然而，PageRank 提出的「链接作为投票」的基本理念，其思想和原理仍然被融入到更复杂、更先进的链接分析算法中。

PageRank主导时期	现在
主要排序依据	仅作为众多排名信号之一
链接可信度高	链接容易被 SEO 操纵，需结合其他因素判断
信息量小，网络结构相对简单	网络复杂，语义理解和用户意图更重要

如今搜索排序更多依赖但不限于以下因素：

语义匹配：例如利用 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 主要解决了文本匹配中的几个实际问题：

问题	BM25 的做法	直觉效果
单词重复刷权重	词频饱和曲线	某个词在文档中重复 100 次 ≈ 重复 5 次，避免过度刷词。
长文权重不应过高	长度归一化	长文章不会天然地比短文章「更相关」，避免长文优势。
稀有词应被强调	IDF 权重	「专有名词」或「稀有词」的权值会比「普通词」更高。

通常位于搜索引擎的初排阶段，对通过倒排索引召回的文档进行初步打分，从而筛选出前 100~1000+候选结果进入下一阶段。

3.5 学习排序 `LTR`

随着网页质量差异的增大、用户行为数据的积累以及特征工程的成熟，搜索引擎需要一个可学习的排序模型来综合判断文档相关性。这就是 LTR。

典型 LTR 模型：

模型	核心思想	训练方式
RankNet	基于成对比较 (pairwise)	「文档 A 应该排在文档 B 前面」
LambdaRank / LambdaMART	直接优化排序指标 (如 NDCG)	现代主流搜索引擎通用，效果出色
ListNet / ListMLE	直接对列表整体排序	更具理论性，但训练通常更复杂和困难

为什么要用 LTR？

超越传统算法：像 BM25 这类算法只看文本特征，看不到复杂的用户行为和页面质量等信息。
综合多维特征：LTR 模型能综合利用海量特征，包括：
- CTR：用户是否点击了这条结果。
- Dwell Time：用户在页面上停留了多久。
- Bounce Rate：用户是否快速返回搜索结果页。
- 历史搜索意图模型：用户过往的搜索偏好和行为模式。

如果用户总是点搜索结果列表中的第 3 条，并且停留很久，那么排序模型就会「学习」到这条结果可能更优质，从而慢慢将其排到第 1 条。

note

搜索引擎的排序，早已不是简单地为「网页写给机器看」来排序，而是真正地为 「用户用脚投票」 来排序。

3.6 语义重排 `Neural Re-ranking`

现代搜索，尤其是在处理复杂查询和理解用户深层意图中，已经进入了纯语言理解阶段。语义重排利用深度学习模型来更精确地衡量查询和文档间的语义相关性。

使用模型：

类型	模型例子	特点
句向量模型	SBERT / E5 / bge	生成文本的稠密向量表示，主要用于粗语义召回或过滤。
精排模型	Cross-Encoder / ColBERT / RAG Reranker	对少量候选结果做深度语义比对，计算细粒度相关性。

典型流程：

graph TD
    A[用户查询] --> B(倒排召回 / BM25);
    B --> C(粗语义召回 / Embedding);
    C --> D(精语义重排 / Cross-Encoder);
    D --> E(返回给用户);

为什么不直接让大模型排序所有网页？

因为计算成本是指数级差异，不可能直接用最复杂的模型处理所有数据：

模型阶段	每次排序成本	处理规模与可行性
BM25	< 10 ms	可对百万到亿级网页进行快速排序
向量检索	1 ~ 100 ms	可对千级到万级候选进行语义筛选
大模型精排	100 ~ 1000+ ms	只能对几十条精选结果做深度处理

排序层级	方法	作用	处理规模
初排 (Recall)	BM25 / TF-IDF	快速找出可能相关的文档	$10^6 \sim 10^8$
语义筛选	向量检索	找出语义上真正相关的文档	$10^3 \sim 10^4$
精排 (Re-rank)	Cross-Encoder / LTR	找到最符合用户需求的文档	$10 \sim 10^2$

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

第一次输入	改写
`提高maimai分数`	`maimai 推分`
`wifi 卡`	`bufferbloat test`
`游戏延迟`	`udp relay latency diagnose`

5.3 不会过滤无效信息

在中文互联网环境下，垃圾、低质量内容泛滥时，减号语法 - 格外重要。

openwrt ipv6 配置教程
openwrt ipv6 教程 -知乎 -抖音 -小红书 -CSDN (直接剔除那些信息密度低/重复/营销性强的内容)

5.4 不区分「答案」与「解释」

很多人在搜索时，习惯于搜解释，但真正有价值的往往是HOW TO DO。

错误输入	结果	搜解决方案	结果
`什么是 bufferbloat`	各种理论定义	`bufferbloat fix fq_codel`	具体的配置、优化指令和方法

5.5 迷信「中文结果永远够用」

在技术、学术或系统问题领域，优先进行英文搜索。因为权威信息源通常原生就是英文的。

反例： 游戏服务器 tick 解释
正确示例： game server tick rate netcode

信息链路通常是这样的：

论文/标准 → 英文 wiki / docs → 国外论坛 / 博客 → 中文翻译/二创 → 小红书/知乎/CSDN

5.6 将「搜索」当作「找别人替你思考」

搜索引擎的本质不是答案机，它是一个高效的知识映射工具。你需要先明确自己要找什么类型的信息，再进行检索。

先分类，再检索：

问题类型	检索目标	示例
原理类	wiki / RFC / MDN / Docs	`dns recursion rfc`
配置类	官方文档 / issue	`openwrt mwan3 configuration`
故障类	日志错误码	`systemd service failed exit code`

搜索不是「把问题原封不动地交给搜索引擎」，而是「你给出的关键词质量，决定了你所能看到的世界广度和深度」。

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 内容解析与标准化

爬取来的原始网页通常不能直接用于检索，需要经过一系列的规范化处理：

步骤	解释
去除 HTML 样式和脚本	只保留页面中的纯文本内容。
Tokenization	将文本切分成有意义的词语单元，中英文处理策略不同。
Lemmatization	将不同词形还原为基本形式，如：`studying → study`。
Stopwords	移除常见但无检索意义的词，如：`的 / a / the / 是 / 了`。
Inverted Index	搜索引擎的核心数据结构，为快速检索打下基础。

倒排索引的例子：

"openwrt" → 文档ID：[1, 3, 7, 9, ...]
"ipv6" → 文档ID：[3, 9, 10, 14, ...]

经过规范标准化处理后，每个关键词都对应一个或多个文档 ID，关键词越小、越精确，搜索速度通常越快。

6.4 排序

搜索引擎的排序模型，是决定搜索结果质量的关键。它通常由两个维度的评分组成：

种类	用于	示例
静态评分	判断网页的整体固有价值	PageRank、域名权重、网站声誉等
动态评分	反映用户与网页的实时交互与满意程度	CTR、Dwell Time、用户跳出率等行为统计

PageRank 原理简单回顾：一个网页的 PageRank 价值，大致等于所有指向它的网页的 PageRank 价值之和，再根据这些指向网页的出链数量进行平均分配。

动态排序机制，使得搜索引擎能够不断学习和进化，根据用户的真实反馈来调整排名。

6.5 查询理解

当用户输入一个查询词时，搜索引擎会在内部进行复杂的「查询处理」，以更好地理解用户意图：

拼写纠错：自动修正用户输入中的拼写错误，如 maiami → maimai。
同义词扩展：识别同义词并进行扩展，如 router ⇆ gateway ⇆ CPE。
意图分类：判断用户的搜索意图是想找「教程 / 原理 / 购买 / 图片 / 视频」等。
实体识别：识别出查询中的专有名词或实体，例如识别 舞萌 是一个游戏名称，而不是关于「舞蹈」的视频。

用户输入的原始查询，实际上会被搜索引擎重写成一个更准确、更丰富的内部查询表达。

6.6 排序后的结果呈现

搜索结果页面（SERP, Search Engine Results Page）并不是一个纯粹的链接列表，而是会根据用户意图动态生成布局：

技术问题：通常会优先展示来自官方文档、Stack Overflow 等权威网站的结果。
百科类查询：倾向于优先展示维基百科、百度百科等知识聚合平台。
购买倾向：会集成商品卡片、比价信息，导向电商平台（如京东、淘宝）。
地点相关查询：优先展示地图、商家信息。
图片/音乐/视频：以媒体网格视图呈现。

搜索引擎不是在简单地「猜你的意图」，而是在进行精密的意图分类路由，将查询导向最适合的展示模板。

6.7 用户反馈闭环 `Feedback Loop`

现代搜索引擎是一个「活的系统」，它会持续记录和学习用户的行为数据，形成一个反馈闭环，从而不断优化排序结果：

指标	含义	对排序的影响
CTR	用户是否点击了这条搜索结果	高点击率 → 排序权重 ↑
Dwell Time	用户在点击结果页面后停留了多久	停留时间长 → 表明内容有价值，排序权重 ↑
Pogo Sticking	用户点击后迅速返回搜索结果页	表明内容不满意，排序权重 ↓

你越是频繁地使用搜索引擎，它就越能提供个性化的搜索结果。

至此，我们已经过完了现代搜索引擎的大体逻辑。这里我们埋个坑，未来可能会出一期手把手教你搭建搜索引擎。至于这有什么用？我们不是已经有 Google/Bing 了？ 是这样，~~但这样干的确很好玩~~。

Thanks For Watching.

您可以通过 Telegram 以及我的个人邮箱 qwq@chongxi.us 来联系我，欢迎对本文纠错，不胜感激。

本篇与《现代SEO深度解析：原理、算法与实战》是互补的关系，如果您已阅读完本文并对SEO感兴趣，可以了解后文，>点击跳转

规范一下Blog的命名体系

Chongxi — Sat, 01 Nov 2025 08:00:00 GMT

正如标题所写，本文主要定义一下此blog的各项规范。既然准备长期运营下去，有一套成熟的规范体系是非常重要的。

关于`/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

本Blog自今日起将不再更新maimai相关内容

Chongxi — Thu, 30 Oct 2025 08:00:00 GMT

先来讲讲我与maimai DX的故事吧。

在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

mai纪事:9月大规模科技扫号和国服万花筒事件

Chongxi — Sun, 07 Sep 2025 08:00:00 GMT

note

本文提及的舞萌均为华立科技在中国大陆发行的舞萌DX版本

前情提要

在这周周末(9-6)之前一段时间，华立服务器非常炸，登录状态没有及时登出，导致大多数正常玩家被关小黑屋。

周六(9/6) 上午

华立服务器稍有异常，表现在无法正常登出账号被关小黑屋。
Chongxi勤一上午基本没什么问题，传分登录都正常。

周六下午

下午一点，开始有玩家反馈服务器问题比较严重，依旧表现在小黑屋、无法扫号登入、断网等方面。
下午2:37，由于Chongxi所在的机厅使用了神秘转发，这边有玩家反馈只能使用转发服务器的二维码登入，微信公众号二维码无法正常登入。

下午2:58，有人开始反馈被异常塞入五倍票，此时已经可以确定有挂哥开始扫号了

下午三点，Chongxi这时候来机厅，发现根本无法通过舞萌官方二维码登入账号，只能通过使用的神秘服务器转发缓存登入，如下图

约下午四点半，华立服务器应该进行了抢修，此时上传服务已正常，可以正常传分，但是挂哥依旧在全服扫号发票。

note

为什么挂哥要发票？当你的账号存在两张以上补偿票时，成绩异常，将无法上传成绩。

晚上八点，这时候来了另外一个事情，国服万花筒。起因是，Chongxi在看海鲜市场，无意发现了一位卖国服钥匙的，顺手把图发到了群里并询问可行性。
在通过一段时间摸索后，Chongxi给自己号上发了门和钥匙，并把万花筒模式拍照发给了自己的一个朋友。
随后便是出乎意料的大规模传播，不到两个小时后便传遍了大多舞萌群，下面是部分解释。

国服万花筒

关于这个被发钥匙的聊天记录，为假，这张图最早就是我顺手发的那张问朋友是否可行的图片。

至于国服是否可以开启万花筒，这个各位应该都有答案了。下面那个证伪不攻自破

我的那张万花筒可以说是闹的很沸沸扬扬了，我可以说的是，国服目前确实可以发，怎么发不能讲。如果你真的不相信，可以来找我拼机（什

目前挂哥的行为为：全服发票，登号续关小黑屋，使玩家无法正常游玩

周日(9/7) 上午

上午十一点，这时有人反馈科技哥发一倍票，很难憋笑，科技哥发id1的行为足以看出其技术力不足。

随后开始有人反馈科技哥发送的倍率票日期有问题，科技哥开始给全服玩家塞敏感日期的倍率票，这时候科技哥的动机我就不好评价了

这已经不是影响玩家游玩的问题了，科技哥让事态升级叠加了一下奖池。

万花筒 part2

这时候QQ传的更广的图为这张，这张图为魔改，并非官服

目前挂哥行为：

发票无法正常传分
扫号使正常玩家无法登入账号进入小黑屋
目前挂哥还没有掌握传分等高级技术。

截至晚上9:01，挂哥终于是消停了，不再有发票的情况了，这件事自此算是完结了....吗？

九月八日周一

caution

以下内容来源于各群聊聊天记录，缺乏真实性考证，Chongxi不为以下内容真实性负责

有人上报被发了白系理论

Chongxi猜测可能是自导自演自娱自乐，自己给自己发了成绩然后一张图全靠编，毕竟前文已经有万花筒这个教训了，当然只是猜测，也有可能确实是真的

有反馈被发wec牌子

由于这些事情真实性欠考证，所以暂时一笔带过。有后续会持续更新

扫号解决方案

目前有以下解决办法

milkbot 可查询票数以及消票使用请见此文章底部给出的链接
奈伊bot 群号:747686616 支持清票查票/解黑屋

欢迎各位向我反馈更多解决方案

在此向致力维护游戏环境的各位致以最高敬意。

为什么没泄漏二维码也能被扫？

挂哥通过User ID登入你的账号，之前有讲，详见此文章。

不被挂哥登号的唯一办法也就不获取二维码了。

聊聊Android上五花八门的浏览器

Chongxi — Tue, 02 Sep 2025 08:00:00 GMT

Android富有多样性。与iOS上所有浏览器都基于Safari内核不同，这使得Android上大多数浏览器都可以使用自家内核，提供别具特色的体验

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绑死了。

浏览器的选择非常看重个人习惯，不妨多试几款。

关于舞萌科技的杂谈以及原理分析

Chongxi — Wed, 27 Aug 2025 08:00:00 GMT

0.引

:::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 服务器验证流程（已抹去部分关键信息）

本地验证SGWCMAID是否合法
机台或客户端将扫码得到的SGWCMAID发送到服务器的二维码验证接口
服务器解析SGWCMAID：

校验时间戳是否在允许的有效期内
验证字符校验段是否合法

验证通过后，服务器返回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[如何保护自己的账号]

不在不信任的公开场合发送您的二维码/SGWCMAID
不在非出勤时间随意获取二维码
发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月大规模科技扫号和国服万花筒事件

在Android设备上以系统级运行Clash

Chongxi — Tue, 26 Aug 2025 08:00:00 GMT

免责声明

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设备的目的。

接下来我们会举一个例子，来更好理解他们协同工作时的流量走向

app试图连接xice.cx:443
iptables立即截获此TCP请求，根据规则，将流量引至TUN设备
TUN会将流量引至tun0
tun2socks会从tun0中读取到这个原始TCP请求，并将其打包为SOCKS5协议的CONNET blog.chongxo.us 443发给localhost的Clash端口。
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.

在任何 Android 设备上使用圈定即搜

Chongxi — Mon, 25 Aug 2025 08:00:00 GMT

INTRO

Circle to Search 是 Google 和 Samsung 联合推出的一项功能，让用户可以通过在屏幕上的任意位置进行圈选、高亮、涂鸦或点按，来快速搜索文字、图像或视频，而无需切换应用。

关于圈定即搜更深度的剖析可以去看看 @NNNNNatsu 大佬的文章：

Circle to Search, XOXO：「圈定即搜」功能交互解析与入门指南

MiCTS

正如 title，我们要在任意Android(≥9)设备上启用圈定即搜，需要借助一个LSPosed模块。

parallelcc/MiCTS

PREPARATION

已获取root权限的设备，并安装了LSPosed。

LET'S GO

安装MiCTS模块。
打开LSPosed Framework，通常情况下，您可以从通知栏的入口进入。
打开模块选项，找到MiCTS，启用，勾选推荐的作用域。
重启您的设备。
将您的默认助理App更改为Google。一般情况下，您可以点击设置>应用>默认应用程序中找到其选项。
您需要给Google应用取消后台限制，将电池优化更改为无限制，并允许自启动。

接下来您可以长按导航条，若圈定即搜正常触发，那么恭喜，您省去了一半的麻烦。

若未正常触发，那么我们需要额外的操作。

打开 LSPosed 里的MiCTS页面，点击右下角的齿轮图标进入设置。
可供参考的设置如下图，您可能需要授予其root权限。

接下来我们设置其触发方式（如果您无法正常长按导航栏触发）

安装Xposed Edge(Pro) （您需要自行安装）
在LSPosed Framework中启用 Xposed Edge，并重启其作用域。
打开Xposed Edge，如下图设置。

接下来您可以再次尝试长按导航栏，他应该会像预期一样工作。

若您遇到了bug，可以向MiCTS项目提交issue。

这里是 Chongxi，期待与您的下一次见面。

Thanks for watching.

--Chongxi 2025-08-25

小米路由器3a刷入openWRT

Chongxi — Fri, 22 Aug 2025 08:00:00 GMT

INTRO

目前2025/08/22，这款路由器价格在十元到三十元之间，淘来刷软路由非常合适。

PREPARATION

需要下载的固件：123684

需要的工具：termius，winSCP

刷入官改固件

打开MIWIFI后台，在系统维护页面手动上传升级固件miwifi_r3a_all_da132_2.18.40.bin
等待升级完成。

确认 Windows 版本

Windows 10 至少2004，内部版本至少19041。
Windows 11

开启与 WSL 相关的 Windows Features

开启 Windows Subsystem Linux 和 Virtual Machine Platform 并重启 Windows。

以管理员运行 PowerShell。
输入

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环境即部署成功

部署解锁工具

在资源管理器中输入 \\wsl.localhost\Ubuntu 进入Ubuntu文件管理，打开home/<这里的文件夹名称为您的用户名>/
将OpenWRTInvasion-0.0.10.tar.gz和setup_openwrt_invasion.sh移动到该目录。
使用cd /home/xi命令，切换到该目录（自行更改xi为您的用户名）
赋予执行权限

sudo chmod +x setup_openwrt_invasion.sh

输入以下命令

cd OpenWRTInvasion-0.0.10

更改库地址

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退出

运行

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

打开termius，通过telnet连接您的路由器，用户和密码均为root
查看并备份分区

cat /proc/mtd

备份分区，留意factory跟BootLoader对应的mtd分区，需要备份的是factory和BootLoader

dd if=/dev/mtd4 of=/tmp/eeprom.bin
dd if=/dev/mtd1 of=/tmp/Bootloader.bin

打开WinSCP，协议选择FTP，主机名为路由器IP，密码和用户名为root。
找到tmp目录，将Bootloader.bin和eeprom.bin复制到PC上。并把breed复制进tmp
回到终端，cd进tmp目录，开始刷入breed

mtd write breed.bin Bootloader

刷入openwrt

确保电脑连接了路由器LAN，拔掉路由器电源。按住复位键，再插入电源，等待指示灯闪烁后，松手。
输入192.168.1.1进入breed后台，这里先查看mac，若mac地址不正常，刷入先前备份的eeprom。
固件选择openwrt，刷入。这里我们使用的是bilibili@小渔学长编译的openwrt固件。

成功

等待片刻，输入10.32.0.1，密码admin，进入openwrt后台，成功。

特别鸣谢

@没了钱咋办 @Lonny_Lee @正在摸鱼的Liaronce @acecilia @hackpascal @小渔学长

这里是 Chongxi，期待与您的下一次见面。

Thanks for watching.

--Chongxi 2025-08-22

三星手表跨版本连接指南

Chongxi — Tue, 19 Aug 2025 08:00:00 GMT

INTRO

相信各位都遇到过这种情况：出于某种原因（比如esim）购买了国行Galaxy Watch，到手后发现无法与自己的港版（或其他版本）手机无法连接，连接时显示如下错误：

此手机不支持该手表。

大多数给出的解决方案基本都是将手机/手表刷为其他版本的系统以进行连接，但是操作难度是比较高的（有一定局限性）

本文将教各位如何跨版本连接三星手表（国港互通）

PREPARATION

Galaxy Watch（这里以Watch6国行为例）
Samsung 手机（这里以港版One UI5.1为例）
Samsung 智能穿戴 App（版本号为2.2.29.20012861）你可以从这里下载

LET'S GO!

将您的Samsung Galaxy Watch设定为待配对状态（对其进行工厂重置）
卸载手机里的Samsung智能穿戴App以及相关组件（比如watch6manager,Wear OS by Google）
安装低版本Samsung智能穿戴（.20012861）
断开一切互联网连接（WLAN/蜂窝移动数据），打开手机的蓝牙界面，点击您的Galaxy Watch进行配对。
通过任意途径安装最新版Samsung智能穿戴，打开后您将会在已配对的设备中找到您的Galaxy Watch，直接点按即可进行设置。

TIPS

由于国行Galaxy Watch阉割了Google服务，您可能会在复制Google账号时提示失败，跳过即可。

HOW IT WORKS?

原理非常简单，低版本的wearable是没有配对校验的，我们使用低版本对手表进行配对后，再使用高版本对其进行连接，即可完成手表手机的国港互通。

这里是Chongxi，期待与您的下一次见面。

Thanks for watching.

--Chongxi 2025-08-19

Knox Patch使用教程

Chongxi — Sun, 17 Aug 2025 08:00:00 GMT

不是我喜欢的Knox 直接熔断

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

首先，确保您使用Magisk/Kernel SU/Apatch等su管理器获得了root权限，并安装了LSPosed模块
在Magisk模块中，刷入KnoxPatch-Enhancer-v0.4.zip
在LSPosed中，勾选所有推荐的应用。
重启您的设备，此时您的Knox Patch将生效。您可以正常使用绝大多数系统app了

写在最后

三星手机解锁bootloader代价极大，我们不推荐您解锁bootloader。绝大多数问题都可以使用shizuku和scene可以把不喜欢的系统应用都禁用，任何禁用都不会死机卡界面。

相比之下，vivo的系统用一般的adb工具无效，小米是禁止应用特别容易死机卡界面。

截至目前 OneUI 8已移除了OEM解锁选项，这意味着未来将不会再允许bootloader解锁。刷机的时代终要落幕了。

这里是Chongxi，期待与您的下一次见面。

Thanks for watching.

--Chongxi 2025-08-19

无题 • 友

Chongxi — Sun, 11 Aug 2024 01:47:21 GMT

旧言难觅心难宁，岁月沉浮似梦迷。历尽风霜棱角隐，故交疏断意难平。

翻自己从前的动态有感而发。

无题 • 雨

Chongxi — Thu, 08 Aug 2024 21:39:21 GMT

雷声轰鸣夜无垠，电闪幽风乱云根。灯下光影碎雨痕，湿路独行映归魂。

~~求赏析~~

Chongxiの咖啡屋

现代人的刻舟求剑

那么然后呢

舞萌DX错误码0010深度解析及处理方法

什么是0010

错误体系

触发机制

引导层的两条判定通道

游戏如何触发

主线程异常路径

后台线程

资源 ID 指向不存在的资源

已知崩溃清单

触发过程

如何解决

做了一个明日方舟-奇象巡展的像素画拼豆工具

舞萌DX国服封禁机制详解

引

什么是 banState

刷卡时发生了什么

游戏限制

1. 友人对战禁用

2. kaleidxscope 进度被锁定

3. LEGEND

纯服务器控制

结

舞萌开机网络自检底层技术说明，断网如何排查讲解

1. 总览

1.1 自检在开机链路中的位置

1.2 链路总览

1.3 9 项速览

2. 机制基础

2.1 三层结构

2.2 执行状态机

2.3 item 检查器的核心字段

2.4 驱动循环

2.5 shouldRun 谓词

3. 9 项逐一说明

3.0 IP 地址（IpAddressChecker）

3.1 网关（GatewayChecker）

3.2 本地 DNS（DnsLanChecker）

3.3 跳数（HopsChecker）

3.4 线路类型（LineTypeChecker）

3.5 Net 认证（AllnetAuthChecker）

3.6 CHIME（AimeChecker）

3.7 Emoney（EmoneyChecker）国服废项

3.8 AimePay（AimePayChecker） 国服废项

4. 结果回传与屏幕显示

4.1 传递链路

4.2 游戏翻译规则

4.3 游戏显示侧说明

4.4 后续流程依赖

4.5 标题服务器（TitleServer）检查说明

5. 架构类名

5.1 networktest 检查器层

5.2 am::network 引擎层

5.3 底层库分工

6. 依赖分类与排查

6.1 依赖分类

6.2 屏幕状态含义

6.3 排查方向

6.4 9 项判定标准总表

附录

舞萌机台开机初始化进程详解

1. 通电

游戏程序启动

2.5 等 amdaemon

AmManager

PingChecker

3. 开机自检

4. 正式启动

OperationManager

5. 版权检查

错误码

开机中一直 初始化 意味着什么

6. 初始化完毕

两个后台服务

什么时候退出/重启

结

为什么喜欢音乐 反而不该去学音乐？

3.0　IP 地址（IpAddressChecker）

3.1　网关（GatewayChecker）

3.2　本地 DNS（DnsLanChecker）

3.3　跳数（HopsChecker）

3.4　线路类型（LineTypeChecker）

3.5　Net 认证（AllnetAuthChecker）

3.6　CHIME（AimeChecker）

3.7　Emoney（EmoneyChecker）国服废项

3.8　AimePay（AimePayChecker）国服废项

4.5　标题服务器（TitleServer）检查说明

开机中一直初始化意味着什么

为什么喜欢音乐反而不该去学音乐？