辉夜铃Ringの博客

加群向导

Thu, 27 Nov 2025 00:00:00 GMT

📬小群体#

QQ
- 点击链接加入群聊[辉夜铃Ring的猫猫头窝]
Telegram
- 点击链接加入群聊[然泽茶馆] (闲置)

📬 联系方式#

📫 邮箱：KaguyaRing@qq.com

给 GL-MT3600BE 适配 OpenWrt：从设备树到开箱即用

Fri, 10 Jul 2026 00:00:00 GMT

给 GL-MT3600BE 适配 OpenWrt：从设备树到开箱即用#

目录#

Tip

可直接点击文字跳转至对应章节

为什么要适配
移植设备树
驱动更新
预装软件包
默认配置优化
技术细节
使用指南
总结

为什么要适配#

GL-MT3600BE 是 GL.iNet 的一款 MT7987A 芯片路由器，硬件配置不错：双 2.5G 网口、Wi-Fi 6、USB 3.0。但问题在于：

OpenWrt 官方 24.10 稳定版没有这个设备的支持。

原厂固件虽然能用，但有几个问题让人不爽：

内存占用高：原厂固件预装了一堆软件
- 原生 WebUI 和 LuCI 同时运行
- nginx、一堆厂商服务、各种预装插件
- 闲置状态下内存占用就不低
功能冗余：很多用不上的功能和服务在后台跑着
可玩性不够：想折腾的话，还是原生 OpenWrt 更自由

想刷 OpenWrt，要么等官方支持，要么自己动手。我选择了后者。

最初想适配 24.10 稳定版，但屡屡碰壁。后来发现 OpenWrt Snapshot（主线开发版）更新更快，驱动支持更好，干脆直接基于 Snapshot 做适配。

移植设备树#

适配的第一步是设备树（Device Tree）。设备树描述了硬件的结构——有哪些接口、GPIO 怎么连的、哪个 LED 对应哪个引脚，等等。

我从哪里找到设备树？

x-wrt 已经有了 GL-MT3600BE 的设备树文件，作者是 Developer X。我直接拿过来，稍作修改，移植到 OpenWrt 主线。

关键文件位置：

1
target/linux/mediatek/dts/mt7987a-glinet-gl-mt3600be.dts

主要修改：

USB 供电控制
- GL-MT3600BE 的 USB 口需要通过 GPIO 14 供电
- 写了个启动脚本 /etc/init.d/turn_on_usb_power，开机时拉高 GPIO
- 否则插 USB 设备没反应
风扇曲线优化
- 原厂风扇曲线：0% / 25% / 50% / 75% / 100%
- 我改成了：0% / 38% / 63% / 88% / 100%
- 为什么？因为原厂曲线起步太慢，温度上来后风扇才开始转，散热不够及时。新曲线起步风量更大，过渡更平滑，既保证散热又控制噪音。
LED 配置
- 蓝色 LED (GPIO 48)：系统状态指示
- 白色 LED (GPIO 49)：启动指示
- 绑定到系统事件，开机自动亮
网络映射
- eth0 (gmac0) → WAN 口（2.5G）
- eth1 (gmac1) → LAN 口（2.5G，内部）

驱动更新#

设备树搞定之后，接下来是驱动。

MT7987A 是联发科的新芯片，主线的驱动支持还在完善中。Snapshot 版本的驱动更新比 24.10 快得多，这也是我选择 Snapshot 的原因之一。

主要驱动：

PHY 固件：mt7987-2p5g-phy-firmware（2.5G 网口）
无线固件：kmod-mt7990-firmware（Wi-Fi 6，MT7996 芯片）
风扇控制：kmod-hwmon-pwmfan（PWM 调速）

这些驱动在 Snapshot 中都是最新版本（截至 2026-03-01），比 24.10 的版本新不少。

预装软件包#

适配完硬件，接下来是软件。我的目标是做一个开箱即用的固件，不需要刷完之后再手动装一堆东西。

预装了什么？

1. LuCI Web 界面#

Argon 主题 v2.4.3：现代化美观主题，比默认主题好看太多
中文语言包：base、package-manager、firewall 的中文翻译

2. OpenClash v0.47.055#

完整源码：放在 /package/luci-app-openclash/
Meta/Mihomo 内核 v1.19.27：预置在固件内，刷完直接能用，不需要手动下载
控制面板：http://192.168.3.1:9090
GeoIP/GeoSite 数据库：由 jsDelivr CDN 自动更新

3. AdGuardHome#

默认运行在 http://192.168.3.1:3000
提供 DNS 广告拦截功能
来自官方 packages feed

4. USB 网络共享支持#

预装完整的 USB 共享网络驱动和工具：

协议支持：RNDIS、ECM、NCM、MBIM、QMI
工具包：umbim、uqmi、comgt、comgt-ncm、usb-modeswitch
效果：插上 4G/5G USB 调制解调器，即插即用

镜像定义文件：

1
target/linux/mediatek/image/filogic.mk (第 2074-2094 行)

默认配置优化#

软件装好了，但默认配置也很重要。我做了一些预设，让固件刷完就能直接用。

安全性增强#

root 账户锁定：首次启动后 root 无法登录
admin 用户：用户名 admin / 密码 admin（uid=0，等效 root 权限）
如果需要 root，可以手动解锁：
Terminal window
```
1
passwd -u root && passwd root
```

网络配置#

LAN IP：192.168.3.1/24
2.4G SSID：GL-MT3600BE-<MAC末4位>
5G SSID：GL-MT3600BE-<MAC末4位>-5G
Wi-Fi 密码：88888888
访客网络：预留 192.168.4.1/24（默认关闭，可手动启用）
wan2 接口：预配置备用上行（metric=30），可绑定 USB 网卡

防火墙规则#

WAN 侧预开放端口：

OpenClash：7874, 7890-7893, 7895, 9090 (TCP)
AdGuardHome：3000 (TCP)

配置文件位置：

1
target/linux/mediatek/filogic/base-files/etc/uci-defaults/99-gl-mt3600be-defaults

技术细节#

构建流程#

Terminal window

1
git clone https://github.com/KaguyaRing/openwrt-custom-gl-mt3600be
2
cd openwrt-custom-gl-mt3600be
3
./scripts/feeds update -a
4
./scripts/feeds install -a
5
make defconfig
6
make -j$(nproc)

构建完成后，固件在 bin/targets/mediatek/filogic/ 目录下：

1
openwrt-mediatek-filogic-glinet_gl-mt3600be-squashfs-sysupgrade.bin

配置种子文件#

1
configs/mt3600be.seed

选择 mediatek/filogic 平台
指定 GL-MT3600BE 设备
禁用 Docker 相关组件（固件体积优化）

CI/CD 系统#

GitHub Actions 自动构建：

.github/workflows/01-check.yml：代码检查
.github/workflows/02-build.yml：自动构建
.github/workflows/03-release.yml：发布固件

使用指南#

安装固件#

方法 1：通过原厂 Web 界面刷入

登录原厂固件的管理界面
找到固件升级选项
上传 .bin 文件
等待刷写完成，设备自动重启

方法 2：通过 U-Boot 刷入

断电，按住 Reset 按钮
上电，等待 LED 闪烁，松开 Reset
浏览器访问 http://192.168.1.1
上传固件文件

方法 3：通过命令行刷入

Terminal window

1
sysupgrade -n openwrt-*.bin

首次使用#

刷写完成后，设备重启
浏览器访问 http://192.168.3.1
用户名：admin / 密码：admin
进入 OpenClash 配置订阅
进入 AdGuardHome 完成初始化

OpenClash 配置#

访问 http://192.168.3.1:9090（Meta 控制面板）
或在 LuCI 界面进入 OpenClash 插件
导入订阅链接
等待规则和代理更新
开始使用

与其他方案的区别#

vs 官方 OpenWrt#

✅ 开箱即用，无需手动配置
✅ 预装 OpenClash + AdGuardHome
✅ 完整的中文界面
⚠️ 基于 Snapshot（滚动更新，非稳定版）

vs x-wrt#

参考了 x-wrt 的设备适配思路
设备树文件源自 x-wrt 开发者（Developer X）
但基于 OpenWrt 主线而非 x-wrt 分支

vs 原厂固件#

内存占用更低：原厂固件预装了一堆软件（原生 WebUI + LuCI + nginx 等），内存占用高，定制版只保留必要组件
更干净：去除冗余服务，系统更纯粹
更强的可定制性：原生 OpenWrt，想装什么装什么
风扇控制更优化：优化后的风扇曲线，散热与静音兼顾

已知限制#

不支持 iStore
- iStore 最高支持 OpenWrt 24.10
- 本项目基于更新的 Snapshot 版本
包管理兼容性
- 第三方插件若强依赖纯 opkg 元数据可能有问题
- Snapshot 主要使用 apk 包管理器
USB 设备枚举
- 需要足功率适配器
- 注意线材质量

总结#

这次适配从移植设备树开始，更新驱动，预装常用软件，优化默认配置，最终做出了一个开箱即用的 OpenWrt 固件。

适配过程中学到的：

设备树的结构和修改方法
OpenWrt 的构建系统和镜像定义
如何预置软件包和配置
USB 供电控制和风扇调速的实现

这个固件适合谁？

想刷 OpenWrt 但懒得配置的人
想用 OpenClash 但不想手动装的人
想折腾路由器但不想从零开始的人

项目地址： https://github.com/KaguyaRing/openwrt-custom-gl-mt3600be

如果你也有 GL-MT3600BE，可以试试这个固件。有问题欢迎提 Issue。

分区这块先到这，谢谢阅读。

参考资料#

Claude Code 中隐藏的中国区域检测机制

Fri, 10 Jul 2026 00:00:00 GMT

Claude Code 中隐藏的中国区域检测机制#

目录#

Tip

可直接点击文字跳转至对应章节

Claude Code 中隐藏的中国区域检测机制

免责声明#

Warning

本文仅用于技术研究和学术交流目的。

本文所有内容基于公开发布的 npm 包进行逆向分析
文中观点仅代表作者个人技术分析，不代表任何官方立场
本文不提供任何绕过或破解方案，仅客观呈现技术事实
读者应遵守相关软件的使用条款和当地法律法规

简介#

在使用 Claude Code（Anthropic 官方的命令行 AI 编程工具）过程中，发现当使用中国区域的 API 端点时，系统行为会出现异常。经过深度逆向分析，发现 Claude Code 内置了针对中国区域的检测机制，并且会主动破坏系统提示词格式。

本文将详细记录整个逆向工程过程，揭示隐藏在混淆代码背后的检测逻辑。

发现契机#

问题最初的表现是：当配置 ANTHROPIC_BASE_URL 指向中国区域的 API 端点时，Claude Code 的行为变得异常。通过分析 npm 包中的 cli.js 文件，发现了大量混淆代码。

使用 strings 命令查看二进制字符串时，发现了一些可疑的 Base64 编码字符串：

Terminal window

1
strings cli.js | grep -i "asia"
2
# 输出: Asia/Shanghai, Asia/Urumqi

这引起了我的注意 — 为什么一个编程工具需要检测时区？

逆向工程过程#

Base64 + XOR 加密#

在 cli.js 中找到了两段 Base64 编码的字符串：

域名黑名单（加密后）：

1
ODV3KDo1MC46MnU4NDZ3NT4vPjooPnU4NDZ3am1odTg0Nnc5OjI/LnYyNS91ODQ2dzk6Mj8udTg0...

关键词列表（加密后）：

1
Pz4+Kyg+PjB3NjQ0NSgzNC93NjI1MjY6I3cjOjYyNTI2dyEzMisudzkyPDY0Pz43dzk6MjgzLjo1...

通过分析混淆代码，找到了解密函数：

1
function DM4(q) {
2
  let K = Buffer.from(q, "base64"),
3
    _ = "";
4
  for (let z of K)
5
    _ += String.fromCharCode(z ^ Mi_);  // XOR 操作
6
  return _.split(",");
7
}

其中 Mi_ = 91 是 XOR 密钥。

解密脚本#

基于上述逻辑，编写了解密脚本：

1
const crypto = require('crypto');
2

3
const XOR_KEY = 91;
4

5
// 域名黑名单 Base64
6
const DOMAINS_BASE64 = "ODV3KDo1MC46MnU4NDZ3NT4vPjooPnU4NDZ3am1odTg0Nnc5OjI/LnYyNS91ODQ2dzk6Mj8udTg0Nnc6NzI5Ojk6djI1OHU4NDZ3OjcyKzoidTg0Nnc6NS88KTQuK3YyNTh1ODV3MC46MigzNC51ODQ2dzkiLz4/OjU4PnU1Pi93IzI6NDM0NTwoMy51ODQ2dzgvKTIrODQpK3U4NDZ3MT91ODQ2dzE/ODc0Lj91ODQ2dzkyNzI5MjcydTg0dzI9NyIvPjB1ODQ2dygvPis9LjV2MjU4dTg0Nnc6NzIiLjU4KHU4NDZ3ODV2KDM6NTwzOjJ1PTg6Kyt1KS41dzg1djk+MjEyNTx1PTg6Kyt1KS41dyM6NjI1MjZ1ODQ2dzY0NDUoMzQvdToydzo1Iik0Li8+KXUvNCt3Kzo4MCI6KzJ1ODQ2dzoyODQ/PjYyKSk0KXU4NDZ3OjI8NDg0Pz51ODQ2dzM0NTwoMzo1dTg0NncyLDM6Nz44NzQuP3U4NDZ3PzM4ND8+KXU1Pi93Nz42NDU8Ky91LzQrdyEzMjMuMjorMnUvNCt3MjUvKDI8dTU+L3czMjwzdj0yLT52OjJ1IyIhdzg3NC4/KCw6InU1Pi93byg6KzJ1ODQ2d25pYmJtanU4NDZ3Y2NiYm11ODc0Lj93Y2M4ND8+dToyd2NjODQ/PnU0KTx3Ymo4ND8+dSspNHdiYmlpaG11IyIhdzoydTg0Pz4qOip1ODQ2dzoydTMiOTwhKHU4NDZ3OjJ1MDEtMzN1ODQ2dzoyODo1OisydTg0Nnc6Mjg0PzI1PHUoM3c6MjM6KC91KDIvPnc6MjMuOTYyI3U4NDZ3OjU2NCkidTg0Nnc6KzJ1bmlraWtoa3UjIiF3OisydTo5NzoydS80K3c6KzJ1OTI6NSMyPnU6Mnc6KzJ1OTcvOCJ1OjJ3OisydTgrOigodTg4dzorMnU/Pi1jY3UvPjgzdzorMnU/KT46Njw+KXU4NDZ3OisydT4jKzo1KDI0NXU4MzovdzorMnU8Lj46MnU4NDZ3OisydTM0Nz86MnUvNCt3OisydTIwLjU4ND8+dTg4dzorMnU3ODQ1OjJ1ODQ2dzorMnU3MjUwOisydTQpPHc6KzJ1NjA+OjJ1ODQ2dzorMnU1PjA0OisydTg0Nnc6KzJ1NDoyKyk0dTg0Nnc6KzJ1KS4iLjV1PS51dzorMnUoKDQrPjV1LzQrdzorMnUvLnYhMnU4NDZ3OisydS48NyI4Oi91ODh3OisydS1odTg2dzorMnUsMzovOjJ1ODh3OisydSwrPCEodS80K3c6KzJ1Iy8idTorK3c6KzJ1Ii4+PDc+dTg0Nnc6KzJ1ISEiLnU2Pnc6KzI2OikvdToydzorKykpNHU2OiI1NClqa2lvdTcyLT53OisyIjJ1ODQ2dzorKzciMXUzMjorMnUvNCt3Oi48Ni41L3U4NDZ3OW8udSohIXUyNHc4NzouPz8idTg0Nnc4NzouPz52ODQ/PnYzLjl1Oisrdzg3Oi4/PnY0Ky4odS80K3c4NzouPz4yPz51NT4vdzg0dSI+KHUtPHc4ND8+dSw+NSw+NXY6MnU4NDZ3ODQ/PnUjdjoyNHU4NDZ3ODQ/PjI3Ojl1ODQ2dzguOT41OD51ODQ2dz8+PispNC4vPil1LzQrdz8yNjopOiJ1ODQ2dz82IzorMnU4NDZ3PzQ4KHU6Mjw4aT91ODQ2dz8uODA4ND8yNTx1ODQ2dz0wdTMoMywwdTQpPHc9NzorODQ/PnU4NDZ3PTQjODQ/PnUzKDMsMHU0KTx3PTQjODQ/PnUpMTF1ODh3PS43MnUzIzJ1Nj53PD4vPDQ6KzJ1ODQ2dzwrL3UhMzIhPjU8IT41PHU4NDZ3PCsvPDQ/dTg3NC4/dzwrLzA+InU+LnU0KTx3PCsvKzoidSgvNCk+dzM/PCg5dTg0NnczPjU6KzJ1LzQrdzI1KC84NCsyNzQvdjorMnU4NDZ3MT41MiI6dS80K3cxMj4wNC51OjJ3MDx2OisydTg3NC4/dzVqNXU6Mnc1Pix2OisydS5vLSl1ODQ2dzU+LHUjIjgzOi86MnU4NDZ3NDU+djorMnU5Ny84InUvNCt3NDU+dTQ4NDQ3OjJ1ODQ2dzQ1PjorMnUrOjI1Lzk0L3UvNCt3NCs+NXUjMjo0MTI1PDoydTg0Nnc0Kz41ODc6Lj8+dTY+dzQrLih1PCsvLi51ODQ2dys0NzQ6MnUvNCt3KzQ3NDorMnUvNCt3KykyLTU0Pz51ODQ2dyspNCMiOjJ1ODQ2dyoyNSEzMjoydTg0NncpMjwzL3U4ND8+KHcpLjU6NSIvMjY+dTMjMnU2PncoKCg6Mjg0Pz51ODQ2dygvNCk+dSEhIi4odS90K3cvMjo1LzI6NToydSspNHcuMi4yOisydTg0NncuNTI6KzJ1OjJ3LTIrdS41PyIyNTw6KzJ1ODQ2dyw0Nz06MnUvNCt3LCEsdT8+bnU1Pi93LCEsdSsrdS46dyM6Mik0Li8+KXU4NDZ3IzoyIzorMnU4NDZ3IzI6NDMuOisydSgyLz53IzI6NDMuNjI1MnUoMi8+dyMidSs0NzQ6KzJ1ODQ2dyI6NSg/bW1tdTg0NnciOjUoP21tbXUvNCt3Ii41LC51OjJ3Ii41LC51IT46OS4pdTorK3chPjU2LiN1OjI=";
7

8
// 关键词列表 Base64
9
const KEYWORDS_BASE64 = "Pz4+Kyg+PjB3NjQ0NSgzNC93NjI1MjY6I3cjOjYyNTI2dyEzMisudzkyPDY0Pz43dzk6MjgzLjo1dygvPis9LjV3a2o6Mnc/OigzKDg0Kz53LTQ3OD4o";
10

11
function decrypt(base64Str) {
12
  const buffer = Buffer.from(base64Str, 'base64');
13
  let result = '';
14
  for (let byte of buffer) {
15
    result += String.fromCharCode(byte ^ XOR_KEY);
16
  }
17
  return result.split(',');
18
}
19

20
console.log('=== 域名黑名单 ===');
21
console.log(decrypt(DOMAINS_BASE64));
22

23
console.log('\n=== AI 实验室关键词 ===');
24
console.log(decrypt(KEYWORDS_BASE64));

显示更多显示更少

检测机制详解#

检测条件#

Claude Code 通过 三重检测 判断是否处于中国区域：

1
function Zi_() {
2
  if (OM()) return null;  // 检查是否禁用
3

4
  let q = fi_(),  // 获取 ANTHROPIC_BASE_URL 的 hostname
5
      K = Hu6(),  // 获取系统时区
6
      _ = K === "Asia/Shanghai" || K === "Asia/Urumqi";  // 时区检测
7

8
  if (!q)
9
    return { known: false, labKw: false, cnTZ: _, host: null };
10

11
  return {
12
    known: Wi_().some((z) => q === z || q.endsWith("." + z)),  // 域名匹配
13
    labKw: Di_().some((z) => q.includes(z)),  // 关键词匹配
14
    cnTZ: _,
15
    host: q
16
  };
17
}

显示更多显示更少

检测逻辑：

域名匹配： 检查 ANTHROPIC_BASE_URL 是否在 40 个域名黑名单中
关键词匹配： 检查域名是否包含 11 个 AI 实验室关键词
时区检测： 检查系统时区是否为 Asia/Shanghai 或 Asia/Urumqi

40 个中国域名黑名单#

解密后的完整域名列表：

1
volcengine.com, openai-hk.com, aigc001.com, api2d.net, chatanywhere.tech,
2
api2gpt.com, aiproxy.io, aihubmix.com, songshugpt.com, aiguoguo.com,
3
closeai.biz, chatgpt.com, api.gptsapi.net, gptapi.us, openkey.cloud,
4
ai-yyds.com, aigcbest.top, api.openai-proxy.org, api.openai-sb.com,
5
api.openai.com, oa.api2d.net, builtbetter.tech, api.oaipro.com,
6
one-api.bltcy.top, api.lightai.io, beta.theb.ai, gpts.wxredcover.cn,
7
www.jcapikey.com, api.caifree.com, burn.hair, openai-proxy.com,
8
openrouter.ai, www.typingmind.com, devv.ai, poe.com, kimi.moonshot.cn,
9
api.deepseek.com, spark-api.xf-yun.com, glm.ai

11 个 AI 实验室关键词#

1
moonshot, deepseek, baichuan, zhipu, baidu, minimax,
2
doubao, volcano, stepfun, siliconflow, abab

这些关键词对应了中国主要的 AI 公司：

moonshot - 月之暗面（Kimi）
deepseek - 深度求索
baichuan - 百川智能
zhipu - 智谱 AI（ChatGLM）
baidu - 百度（文心一言）
minimax - MiniMax
doubao - 字节跳动（豆包）
volcano - 火山引擎
stepfun - 阶跃星辰
siliconflow - 硅基流动
abab - MiniMax 的模型系列

版本演进分析#

通过对比多个版本的 Claude Code，确定了检测机制的引入时间：

版本	发布时间	检测代码	说明
v2.1.90	2026-04-01 23:31 UTC	❌ 无	最后一个干净版本
v2.1.91	2026-04-02 22:37 UTC	✅ 有	检测代码首次引入
v2.1.98	2026-07-09 (当前)	✅ 有	检测逻辑持续存在

时间线：

2026年4月1日： v2.1.90 发布，代码完全干净
2026年4月2日： v2.1.91 发布，首次加入完整的检测机制
至今运行 3+ 个月： 所有新版本都保留了这个机制

提示词破坏机制#

当检测到中国区域时，系统会修改提示词中的日期格式，插入换行符破坏提示词结构：

1
function Gi_(q, K) {
2
  if (!q && !K) return "'";        // 正常情况: 单引号
3
  if (q && !K) return "\n\n";      // 域名匹配: 两个换行
4
  if (!q && K) return "\n";        // 关键词匹配: 一个换行
5
  return "\n\n";                   // 同时匹配: 两个换行
6
}
7

8
function fM4(q) {
9
  let K = Zi_(),
10
      _ = Gi_(K?.known ?? false, K?.labKw ?? false),
11
      z = K?.cnTZ ? q.replace(/-/g, "/") : q;
12
  return `Today${_}s date is ${z}.`;
13
}

破坏效果对比：

正常情况：

1
Today's date is 2026-07-10.

检测到中国区域后：

1
Today
2

3
s date is 2026/07/10.

注意到：

's 被拆分成了两行
日期格式从 2026-07-10 变成了 2026/07/10
插入的换行符会破坏整个系统提示词的结构

实际影响#

这种提示词破坏会导致：

系统提示词格式错误：多余的换行符破坏 markdown 或 JSON 结构
模型行为异常：错误的提示词格式可能导致模型输出不符合预期
功能降级：某些依赖严格格式的功能可能失效
隐蔽性强：用户很难发现问题根源，只会感觉”用着不太对”

代码证据#

完整的检测函数位于 cli.js 中（去混淆后）：

1
// src/content/posts/Claude-Code-China-Detection/index.md:372
2
function Zi_() {
3
  if (OM()) return null;
4

5
  let hostname = getHostnameFromBaseURL(),
6
      timezone = getSystemTimezone(),
7
      isChinaTimezone = timezone === "Asia/Shanghai" || timezone === "Asia/Urumqi";
8

9
  if (!hostname)
10
    return { known: false, labKw: false, cnTZ: isChinaTimezone, host: null };
11

12
  return {
13
    known: DOMAIN_BLACKLIST.some((domain) =>
14
      hostname === domain || hostname.endsWith("." + domain)
15
    ),
16
    labKw: LAB_KEYWORDS.some((keyword) => hostname.includes(keyword)),
17
    cnTZ: isChinaTimezone,
18
    host: hostname
19
  };
20
}
21

22
function formatDateWithDetection(date) {
23
  let detection = Zi_(),
24
      separator = getLineSeparator(detection?.known ?? false, detection?.labKw ?? false),
25
      formattedDate = detection?.cnTZ ? date.replace(/-/g, "/") : date;
26

27
  return `Today${separator}s date is ${formattedDate}.`;
28
}

显示更多显示更少

结论与思考#

通过完整的逆向分析，我们发现：

检测范围广泛： 40 个域名 + 11 个关键词覆盖了几乎所有中国 AI 服务提供商
加密隐藏： 使用 Base64 + XOR 加密试图隐藏检测目标
主动破坏： 不是简单的功能限制，而是主动破坏提示词结构
持续存在： 从 v2.1.91（2026-04-02）至今已运行 3+ 个月

技术层面的疑问：

为什么需要检测中国区域的 API 端点？
为什么要主动破坏提示词格式而不是直接报错？
为什么要加密域名和关键词列表？

对开源社区的启示：

商业软件即使发布为 npm 包，依然可能包含隐藏逻辑
混淆代码并不能真正隐藏意图，只是增加分析成本
用户应该有权知道软件在背后做了什么

本文仅呈现技术事实，不做价值判断。读者可以根据这些信息自行判断和选择。

参考资料#

[!INFO]
更新日志：

2026-07-10：初版发布，完成完整逆向分析

OpenWrt 安装网易 UU 加速器插件：完整安装与配置指南

Fri, 10 Jul 2026 00:00:00 GMT

OpenWrt 安装网易 UU 加速器插件：完整安装与配置指南#

目录#

Tip

可直接点击文字跳转至对应章节

什么是 UU 加速器路由器插件
支持的系统和架构
安装方法
- 方法一：官方安装脚本（推荐）
- 方法二：第三方 APK 包
防火墙配置
绑定与使用
常见问题排查
总结

什么是 UU 加速器路由器插件#

网易 UU 加速器提供了 OpenWrt 路由器插件，可以让连接到路由器的所有设备享受游戏加速服务，无需在每台设备上单独安装客户端。

适用场景：

主机游戏（PS5、Xbox、Switch）加速
多设备同时加速
不方便安装客户端的设备

工作原理：

插件运行在路由器上，通过 VPN 隧道加速网络流量
使用手机 APP 远程控制路由器上的加速服务
支持按设备、按游戏精细化控制

支持的系统和架构#

系统版本支持#

✅ 支持：OpenWrt 19.x ~ 最新版本
⚠️ OpenWrt 22.03 及以上：需要额外安装 iptables-nft 兼容层

架构支持#

官方目前支持以下架构：

架构	说明	常见设备
`aarch64`	ARM 64位	树莓派 4、大部分现代 ARM 路由器
`arm`	ARM 32位	较老的 ARM 路由器
`mipsel`	MIPS 小端	大部分联发科路由器
`x86_64`	x86 64位	软路由、虚拟机

如何查看架构：

Terminal window

1
grep '^DISTRIB_ARCH' /etc/openwrt_release

安装方法#

方法一：官方安装脚本（推荐）#

这是网易官方提供的安装方式，自动识别架构并下载对应版本。

1. SSH 连接路由器#

查看路由器 IP：

Windows：Win + R → 输入 cmd → 输入 ipconfig
macOS/Linux：终端输入 ip route | grep default 或 ifconfig
路由器 IP 通常是 192.168.1.1 或 192.168.3.1

SSH 连接（将 IP 替换为你的路由器 IP）：

Terminal window

1
ssh root@192.168.1.1

输入路由器密码后进入命令行。

2. 下载安装脚本#

Terminal window

1
cd /tmp
2
wget https://uurouter.gdl.netease.com/uuplugin-script/openwrt/install/v2/install.sh

3. 运行安装脚本#

大部分架构（自动识别）：

Terminal window

1
/bin/sh install.sh openwrt $(uname -m)

MIPS 大端架构（如果上面命令安装失败且 SN 为空）：

Terminal window

1
/bin/sh install.sh openwrt mipseb

安装成功后会显示设备 SN 码：

1
sn=94:83:c4:cc:ad:7c

保存这个 SN 码，后面绑定时需要用到。

4. 检查 TUN 模块#

查看是否已安装 kmod-tun：

Terminal window

1
opkg list-installed kmod-tun

如果没有输出，需要安装：

Terminal window

1
opkg update
2
opkg install kmod-tun

验证 TUN 设备：

Terminal window

1
ls /dev/net/tun

如果显示文件存在（如 crw------- 1 root root ...），说明 TUN 模块正常。

5. 启动服务#

Terminal window

1
/etc/init.d/uuplugin enable    # 开机自启
2
/etc/init.d/uuplugin start     # 立即启动

检查服务状态：

Terminal window

1
ps w | grep uuplugin | grep -v grep

如果看到类似以下输出，说明运行正常：

1
9230 root      5304 S    /tmp/uu/uuplugin /tmp/uu/uu.conf

方法二：第三方 APK 包#

这是社区维护的安装包，适用于 OpenWrt 25.12 及以后版本。

OpenWrt 25.12+ (APK 包管理器)#

Terminal window

1
cd /tmp
2
pkg_name=uuplugin-latest-$(grep '^DISTRIB_ARCH' /etc/openwrt_release | awk -F "'" '{print $2}').apk
3
wget "https://github.com/ttc0419/uuplugin/releases/download/latest/$pkg_name"
4
apk add --allow-untrusted $pkg_name || echo "不支持你的路由器架构！"

OpenWrt 25.12 之前 (OPKG 包管理器)#

Terminal window

1
cd /tmp
2
pkg_name=uuplugin_latest-1_$(grep '^DISTRIB_ARCH' /etc/openwrt_release | awk -F "'" '{print $2}').ipk
3
wget "https://github.com/ttc0419/uuplugin/releases/download/latest/$pkg_name"
4
opkg install $pkg_name || echo "不支持你的路由器架构！"

项目地址：ttc0419/uuplugin

防火墙配置#

⚠️ 重要：OpenWrt 高版本（22.03+）需要调整防火墙规则才能正常加速。

通过 LuCI 网页配置#

打开浏览器，访问路由器管理后台（如 http://192.168.1.1）
进入网络 → 防火墙
将以下三项都改为 接受 (accept)：
- 入站数据
- 出站数据
- 转发
点击 保存并应用

通过命令行配置#

Terminal window

1
uci set firewall.@defaults[0].input='ACCEPT'
2
uci set firewall.@defaults[0].output='ACCEPT'
3
uci set firewall.@defaults[0].forward='ACCEPT'
4
uci commit firewall
5
/etc/init.d/firewall restart

绑定与使用#

1. 下载 UU 加速器 APP#

iOS：App Store 搜索 “网易UU加速器”
Android：应用商店搜索 “网易UU加速器”

2. 在 APP 中绑定路由器#

打开 UU 加速器 APP
点击底部 路由器加速 标签
点击 添加路由器 或 绑定设备
输入之前保存的 设备 SN 码（如 94:83:c4:cc:ad:7c）
绑定成功后，即可在 APP 中控制路由器加速

3. 使用加速#

选择游戏：在 APP 中选择要加速的游戏
选择设备：可以为特定设备开启加速
开启加速：点击启动，路由器会自动建立加速通道

常见问题排查#

1. 安装后无法启动#

检查服务状态：

Terminal window

1
/etc/init.d/uuplugin status
2
ps w | grep uuplugin | grep -v grep

查看日志：

Terminal window

1
logread | grep -i uu

常见原因：

TUN 模块未安装或未加载
防火墙规则阻止
架构不匹配

2. 提示 “Create or open pid file failed”#

这通常说明服务已经在运行，检查进程：

Terminal window

1
ps w | grep uuplugin | grep -v grep
2
cat /var/run/uuplugin.pid

如果确实没有运行，删除 PID 文件后重启：

Terminal window

1
rm -f /var/run/uuplugin.pid
2
/etc/init.d/uuplugin start

3. 找不到 SN 码或 SN 为空#

重新运行安装脚本：

Terminal window

1
/bin/sh install.sh openwrt $(uname -m)

手动查看 MAC 地址（SN 通常是 MAC 地址）：

Terminal window

1
ifconfig | grep HWaddr
2
ip link show

4. 加速不生效#

检查项：

防火墙规则：确保已设置为 ACCEPT
Terminal window
```
1
uci show firewall.@defaults[0]
```
路由表：查看是否有加速路由
Terminal window
```
1
ip route
```
TUN 设备：确认虚拟网卡已创建
Terminal window
```
1
ifconfig | grep tun
```
APP 绑定：确保设备已在 APP 中绑定并开启加速

5. 升级 OpenWrt 后插件失效#

OpenWrt 升级通常会清空 /tmp 目录，需要重新安装：

Terminal window

1
cd /tmp
2
wget https://uurouter.gdl.netease.com/uuplugin-script/openwrt/install/v2/install.sh
3
/bin/sh install.sh openwrt $(uname -m)
4
/etc/init.d/uuplugin enable
5
/etc/init.d/uuplugin start

总结#

快速安装流程#

Terminal window显示更多显示更少

1
# 1. 下载并运行安装脚本
2
cd /tmp
3
wget https://uurouter.gdl.netease.com/uuplugin-script/openwrt/install/v2/install.sh
4
/bin/sh install.sh openwrt $(uname -m)
5

6
# 2. 安装 TUN 模块（如果需要）
7
opkg update
8
opkg install kmod-tun
9

10
# 3. 启动服务
11
/etc/init.d/uuplugin enable
12
/etc/init.d/uuplugin start
13

14
# 4. 配置防火墙（命令行方式）
15
uci set firewall.@defaults[0].input='ACCEPT'
16
uci set firewall.@defaults[0].output='ACCEPT'
17
uci set firewall.@defaults[0].forward='ACCEPT'
18
uci commit firewall
19
/etc/init.d/firewall restart

显示更多显示更少

关键要点#

✅ 支持版本：OpenWrt 19.x ~ 最新版本
✅ 需要模块：kmod-tun 必须安装
✅ 防火墙：高版本需要设置为 ACCEPT
✅ 绑定方式：使用手机 APP 扫描 SN 码绑定
✅ 适用场景：主机游戏加速、多设备同时加速

参考资源#

如果遇到其他问题，可以：

查看 OpenWrt 系统日志：logread
检查插件运行日志：logread | grep -i uu
访问 UU 加速器官方支持页面获取帮助

重写 VRChat 翻译助手：当 VRCT 的网络问题让人抓狂

Fri, 10 Jul 2026 00:00:00 GMT

重写 VRChat 翻译助手：当 VRCT 的网络问题让人抓狂#

目录#

Tip

可直接点击文字跳转至对应章节

为什么要重写
技术选型
架构设计
核心功能实现
开发中的坑
使用体验
未来计划
总结

为什么要重写#

VRCT 是个很棒的 VRChat 翻译工具，功能强大，支持语音识别和实时翻译。但用起来有几个让人头疼的问题：

VRCT 的痛点#

网络问题
- 模型文件托管在 Hugging Face
- 国内下载经常失败或速度极慢
- 需要手动配置镜像源或代理
配置繁琐
- 需要手动下载模型文件
- 配置路径容易出错
- 首次使用门槛高
启动卡顿
- 启动时立即加载 AI 模型
- 模型加载需要几秒钟
- 这段时间整个应用卡死

我的解决思路#

既然问题这么明显，那就重写一个：

懒加载模型：启动时不加载，首次翻译时才加载，避免启动卡顿
自动化配置：首次启动向导，引导用户下载模型，降低使用门槛
现代化架构：Tauri + React + Python，UI 和 AI 推理分离
开箱即用：尽可能减少配置步骤

于是就有了 VRC-GoTrans。

技术选型#

为什么选 Tauri？#

最初考虑过 Electron，但 Electron 打包体积太大（动辄 100MB+），而且内存占用高。

Tauri 的优势：

体积小：打包后只有几 MB（不含 Python 运行时）
性能好：基于系统 WebView，内存占用低
安全性：Rust 后端，类型安全
跨平台：Windows、macOS、Linux 都支持

为什么选 React？#

前端框架选择 React 19，主要原因：

生态成熟：组件库、工具链完善
Radix UI：无障碍、可定制的组件库
TypeScript：类型安全，减少运行时错误

为什么用 Python Sidecar？#

AI 推理需要 Python 生态（llama-cpp-python、faster-whisper），但 Tauri 主进程是 Rust。

解决方案：Sidecar 模式

Python 以独立进程运行
通过 HTTP 接口与 Rust 通信
AI 推理不阻塞主应用

技术栈总览#

1
前端：React 19 + TypeScript + Radix UI + Vite
2
桌面壳：Tauri 2 (Rust)
3
AI 推理：Python 3.11 + llama-cpp-python + aiohttp
4
包管理：uv (Python) + pnpm (Node.js)

架构设计#

整体架构#

1
┌─────────────────────────────────────────────────┐
2
│            React 前端（Tauri WebView）           │
3
│  - 用户界面                                      │
4
│  - 配置管理                                      │
5
│  - 翻译日志                                      │
6
└─────────────┬───────────────────────────────────┘
7
              │ Tauri IPC
8
┌─────────────▼───────────────────────────────────┐
9
│               Rust 后端（Tauri 2）              │
10
│  - OSC 客户端（rosc）                            │
11
│  - Sidecar 生命周期管理                         │
12
│  - 配置持久化                                    │
13
│  - 系统信息查询                                  │
14
└─────────────┬───────────────────────────────────┘
15
              │ HTTP (127.0.0.1)
16
┌─────────────▼───────────────────────────────────┐
17
│          Python Sidecar（uv 管理）              │
18
│  - llama-cpp-python 推理                        │
19
│  - HY-MT1.5 模型加载                            │
20
│  - 异步 HTTP 服务（aiohttp）                     │
21
└─────────────────────────────────────────────────┘
22

23
              ↓ OSC (UDP)
24
┌─────────────────────────────────────────────────┐
25
│              VRChat (OSC 端口 9000)             │
26
└─────────────────────────────────────────────────┘

显示更多显示更少

数据流#

1
用户输入文本
2
    ↓
3
React 组件调用 Tauri 命令
4
    ↓
5
Rust 后端转发到 Python Sidecar (HTTP POST /translate)
6
    ↓
7
Python 加载 HY-MT1.5 GGUF 模型
8
    ↓
9
llama-cpp-python 推理生成翻译
10
    ↓
11
返回翻译结果（JSON）
12
    ↓
13
Rust 通过 rosc 发送 OSC 消息到 VRChat
14
    ↓
15
VRChat 聊天框显示翻译

显示更多显示更少

为什么要三层分离？#

UI 层（React）：负责界面交互，不关心底层实现
Shell 层（Rust）：负责系统调用、进程管理、网络通信
AI 层（Python）：负责模型推理，不阻塞主进程

这样做的好处：

UI 永远不会因为 AI 推理而卡顿
Python 进程崩溃不会影响主应用
各层独立开发、测试、部署

核心功能实现#

1. Python Sidecar 自动引导#

问题：用户不一定安装了 Python，也不知道如何配置环境。

解决方案：使用 uv 自动安装 Python 和依赖。

实现（src-tauri/src/sidecar.rs）：

1
pub async fn bootstrap_and_start(app: &AppHandle) -> Result<SidecarHandle, SidecarError> {
2
    let src_python = src_python_dir();
3

4
    // 自动运行 uv sync，安装 Python 3.11 + 依赖
5
    run_uv_sync(app, &src_python).await?;
6

7
    // 启动 Python sidecar
8
    start_sidecar(app, &src_python, model_path.as_deref()).await
9
}

效果：

首次运行时，自动下载 Python 3.11
自动安装 llama-cpp-python、aiohttp 等依赖
支持镜像源配置（清华、阿里云、豆瓣、PyPI）
用户完全无感知

2. 懒加载翻译模型#

问题：VRCT 启动时立即加载模型，导致启动卡顿。

解决方案：首次翻译时才加载模型。

实现（src-python/src/vrc_gotrans/translator/local.py）：

1
class LocalTranslator:
2
    def __init__(self, model_path: str, ...):
3
        self._llm: Llama | None = None  # 懒加载
4
        self._lock = threading.Lock()
5

6
    def _call_sync(self, prompt: str) -> str:
7
        with self._lock:
8
            if self._llm is None:
9
                # 首次翻译时才加载模型
10
                self._llm = Llama(model_path=..., n_ctx=1024, ...)
11
            result = self._llm(prompt, **_GEN_KW)
12
            return result["choices"][0]["text"]

优势：

启动时不加载模型，启动速度快
首次翻译时加载，用户有心理预期
线程安全（threading.Lock）
推理在线程池执行，不阻塞 asyncio 事件循环

3. VRChat OSC 集成#

问题：如何将翻译结果发送到 VRChat 聊天框？

解决方案：通过 OSC（Open Sound Control）协议。

实现（src-tauri/src/osc.rs）：

1
pub fn send_chatbox_message(&self, message: &str, send_immediately: bool) -> Result<(), String> {
2
    let msg = OscMessage {
3
        addr: "/chatbox/input".to_string(),
4
        args: vec![
5
            OscType::String(truncated.to_string()),
6
            OscType::Bool(send_immediately),
7
        ],
8
    };
9
    let packet = OscPacket::Message(msg);
10
    let buf = rosc::encoder::encode(&packet)?;
11
    self.socket.send_to(&buf, self.target_addr)?;
12
    Ok(())
13
}

支持的 OSC 地址：

/chatbox/input - 发送消息到聊天框（最多 144 字符）
/chatbox/typing - 显示/隐藏打字指示器

效果：

翻译结果自动显示在 VRChat 聊天框
延迟低于 10ms（本地 UDP）
支持打字指示器

4. 首次启动向导#

问题：新用户不知道如何配置。

解决方案：首次启动时引导用户配置。

实现（src/components/FirstRunWizard.tsx）：

5 步引导流程：

欢迎页面：介绍 VRC-GoTrans
翻译引擎选择：在线 API vs 本地模型
模型下载/定位：自动下载或手动选择模型文件
OSC 配置：默认端口 9000，可自定义
完成页面：配置完成，开始使用

配置持久化到 ~/.vrc-gotrans/config.json

5. 类型安全的多语言支持#

问题：多语言翻译容易漏 key 或写错。

解决方案：TypeScript 类型约束。

实现（src/locales/）：

1
// zh-Hans.ts 定义类型
2
export const zhHans = {
3
  app: { title: "VRC-GoTrans" },
4
  translate: { input: "输入文本" },
5
  // ...
6
};
7
export type TranslationShape = typeof zhHans;
8

9
// 其他语言必须匹配此类型
10
const en: TranslationShape = {
11
  app: { title: "VRC-GoTrans" },
12
  translate: { input: "Enter text" },
13
  // 缺 key 会编译失败
14
};

效果：

编译时检查，缺 key 会报错
支持 4 种语言：简体中文、English、日本語、한국어
类型安全，减少运行时错误

开发中的坑#

1. llama-cpp-python 编译问题#

问题：llama-cpp-python 依赖 C++ 编译器，Windows 上编译困难。

解决方案：使用预编译的 wheel 包。

1
[tool.uv]
2
find-links = [
3
    "https://github.com/abetlen/llama-cpp-python/releases/download/v0.3.33/"
4
]

2. Sidecar 握手超时#

问题：Python sidecar 启动慢，Rust 端等待超时。

解决方案：握手机制 + 健康检查。

1
// 等待 sidecar 启动
2
for _ in 0..30 {
3
    if health_check().await.is_ok() {
4
        return Ok(handle);
5
    }
6
    tokio::time::sleep(Duration::from_millis(100)).await;
7
}

3. OSC 消息长度限制#

问题：VRChat 聊天框最多 144 字符。

解决方案：自动截断。

1
let truncated = if message.len() > 144 {
2
    &message[..144]
3
} else {
4
    message
5
};

4. 模型推理阻塞事件循环#

问题：llama-cpp-python 推理是同步的，会阻塞 asyncio。

解决方案：在线程池执行。

1
async def translate(self, text: str, ...) -> str:
2
    loop = asyncio.get_running_loop()
3
    return await loop.run_in_executor(self._executor, self._call_sync, prompt)

使用体验#

安装#

从 Releases 下载安装包
运行安装程序
首次启动会自动安装 Python 环境（约 1-2 分钟）

首次配置#

选择界面语言（简体中文 / English / 日本語 / 한국어）
选择翻译引擎（推荐：本地模型）
下载/定位 HY-MT 模型文件（约 1.1GB）
配置 OSC（默认端口 9000）
完成设置

日常使用#

启动 VRChat 并启用 OSC（Settings → OSC → Enable OSC）
启动 VRC-GoTrans
点击”开始”按钮启动翻译会话
输入要翻译的文本，按 Enter 发送
翻译结果自动显示在 VRChat 聊天框

性能指标#

模型加载时间：~1.5 秒（首次）
翻译延迟：0.3-0.5 秒/句（CPU，Q4_K_M 量化）
内存占用：~1.5-2GB（模型加载后）
磁盘空间：~2GB（含模型）
OSC 延迟：<10ms（本地 UDP）

与 VRCT 的对比#

特性	VRC-GoTrans	VRCT
启动速度	快（懒加载）	慢（立即加载模型）
配置难度	低（向导引导）	高（手动配置）
网络依赖	低（镜像源支持）	高（Hugging Face）
UI 现代化	React 19	PyQt
语音识别	开发中	✅ 支持
跨平台	Windows（macOS/Linux 开发中）	Windows

未来计划#

短期#

✅ OSC 集成（已完成）
🚧 faster-whisper 语音识别
📋 麦克风/扬声器设备选择

中期#

macOS/Linux 支持
GPU 加速（CUDA）
批量消息队列

长期#

实时语音翻译
自定义翻译模型训练
云端配置同步

总结#

重写 VRC-GoTrans 的初衷很简单：VRCT 的网络问题和配置繁琐让人抓狂。

这次重写学到的：

Tauri 的 Sidecar 模式很适合集成 Python AI 应用
懒加载模型可以显著改善启动体验
首次启动向导可以大幅降低使用门槛
类型安全（TypeScript + Rust）可以减少很多运行时错误

这个项目适合谁？

VRChat 玩家，想用翻译但嫌 VRCT 配置麻烦
开发者，想学习 Tauri + React + Python 的跨语言集成
对 AI 桌面应用开发感兴趣的人

项目地址： https://github.com/KaguyaRing/VRC-GoTrans

如果你也在玩 VRChat，可以试试这个工具。有问题欢迎提 Issue，也欢迎加 QQ 群交流：辉夜铃Ring的猫猫头窝

谢谢阅读。

参考资料#

Android 的 AVB 与启动校验

Wed, 08 Apr 2026 00:00:00 GMT

Android 的 AVB 与启动校验#

目录#

Tip

可直接点击文字跳转至对应章节

Android 的 AVB 与启动校验

简介#

你有没有遇到过这种情况：明明镜像刷写进去了，fastboot 也没报错，结果重启之后设备就是起不来？或者更奇怪的是，系统是启动了，但 Wi-Fi 怎么都连不上？

很多人第一反应是”镜像有问题”或者”我刷写方法不对”。但其实，问题可能根本不在镜像本身，而是出在一个叫 AVB 的机制上。

AVB 是 Android 8 之后引入的启动校验机制。用原厂系统的时候你完全感觉不到它的存在，但一旦开始解锁 BL、刷写第三方镜像、修补 boot 分区，AVB 就会跳出来”拦”你一下。如果不处理好它，轻则功能异常，重则直接开不了机。

那 AVB 到底在干什么？为什么它能”拦”住我们？我们一步步来看。

什么是 AVB#

AVB 全称是 Android Verified Boot。简单说，它就是一套”检查员”机制：在设备启动之前，Bootloader 会先检查关键分区有没有被动过手脚，签名是不是还在可信链中。

那它要检查哪些分区呢？通常包括：

boot — 内核和 ramdisk 都在这里
init_boot — Android 13+ 设备拆出来的通用 ramdisk
vendor_boot — 厂商相关的启动内容
system — 系统主体文件
以及其他被 vbmeta 描述到的分区

这就引出了一个新问题：Bootloader 怎么知道要检查哪些分区？检查的标准又是什么？答案就在 vbmeta 里。

vbmeta 是什么#

你可以把 vbmeta 理解成一份”检查清单”。Bootloader 在校验别的分区之前，会先读取这份清单，看看里面写了什么。

vbmeta 里通常包含这些内容：

分区描述信息（descriptor） — 告诉 Bootloader 要检查哪些分区
哈希或哈希树 — 每个分区应该对应什么样的校验值
公钥和签名 — 用来验证这份清单本身是不是可信的
标志位（flags） — 控制校验的严格程度
回滚保护用的版本索引 — 防止你降级到旧版本

如果你在教程里看到这些命令参数，别慌，它们都是在调整 vbmeta 的行为：

disable-verity — 关掉运行期的 dm-verity 校验
disable-verification — 放宽 AVB 对分区的校验要求

很多教程让你”刷写 vbmeta.img”或者”修补 vbmeta 分区”，修改的就是这些标志位。

[!INFO]
有些设备不止一个 vbmeta，还会拆成 vbmeta_system、vbmeta_vendor 之类。实现细节不同，但原理是一样的。

AVB 的工作流程#

理解了 vbmeta 之后，整个流程就清楚了：

Bootloader 启动 — 设备开机，Bootloader 开始工作
读取 vbmeta — Bootloader 先去读这份”检查清单”，看看里面记录了什么
检查各个分区 — 按照清单里的 descriptor，逐个校验 boot、init_boot、system 等分区的哈希和签名
全部通过 — 校验都过了，继续引导系统
任何一步失败 — 根据当前策略处理（BL 带锁时直接拒绝启动，BL 解锁时可能允许继续但会显示警告）

看起来很简单对吧？但这里藏着一个关键问题：如果你修改了 boot 分区，但 vbmeta 里记录的还是原来的哈希值，会发生什么？

答案是：校验失败。如果 BL 还带锁，设备直接拒绝启动。即使 BL 解锁了，很多设备也会因为校验不通过导致部分功能异常——比如 Wi-Fi 用不了。

这就是为什么很多教程会让你同时处理 boot 和 vbmeta：你不光要修改 boot，还要让 vbmeta 不再按原来的标准去校验它。

dm-verity#

前面说的 AVB 是在启动前做检查。那系统启动之后呢？还会继续检查吗？

会的。这就是 dm-verity 的作用——它负责运行期的完整性校验。

dm-verity 主要用在只读分区上，比如 system 和 vendor。系统每次读取数据块时，都会对照预先计算好的哈希树，检查内容有没有被改动过。如果某个块的哈希对不上，轻则报错，重则直接导致系统无法启动。

这就是为什么很多 Root 或修改系统分区的教程，都会让你处理 disable-verity / disable-verification，然后刷写一个修改过的 vbmeta——目的就是让设备在运行时不再做这些严格的校验。

Warning

注意一个常见误区：解锁 BL 不等于 dm-verity 自动失效。很多设备即使解锁了 BL，依然会保留原厂的校验机制，除非你主动修改过相关分区。

那这里又引出一个新问题：如果我解锁了 BL，但没有禁用 AVB 和 dm-verity，修改 boot 之后会怎样？

BL 带锁和解锁的区别#

这里先把 BL（Bootloader）带锁和解锁的区别说清楚，因为这直接决定了 AVB 会不会”拦”住你。

BL 带锁时：

Bootloader 只信任厂商认可的签名
任何关键分区被修改，校验失败后设备通常直接拒绝启动
如果没有 9008 授权或官方救砖工具，基本只能去售后或闲鱼买临时授权

BL 解锁后：

设备允许加载第三方引导程序
你才能正常刷写 boot、init_boot、vbmeta 这些关键分区
重启时通常会显示”设备已解锁”的警告
但 AVB 的校验不会消失，只是从”严格拒绝”变成”允许继续，但仍会警告或限制部分功能”

这就是很多人踩的坑：以为解锁 BL 之后就可以随便改了，结果发现修改 boot 后 Wi-Fi 用不了，或者系统功能异常。原因就是 AVB 还在按原来的标准做校验，只不过不再直接拒绝启动而已。

为什么修改了 boot 或 vbmeta 开不了机#

现在我们可以回答开头的问题了：为什么明明刷写成功了，设备却起不来？

原因通常有这几种：

你修改了 boot，但 vbmeta 里记录的还是原始校验值 — Bootloader 一对比，发现哈希对不上，校验失败
你修改了 vbmeta，但没有用设备认可的密钥重新签名 — Bootloader 读取 vbmeta 时发现签名不对，直接拒绝
你只修改了镜像，但没有处理 disable-verity / disable-verification — 设备还在按严格标准做校验
设备还处在带锁状态 — Bootloader 根本不接受修改后的镜像

这就是为什么很多人”刷写了 Magisk 修补的 boot.img 后开不了机”——不是 Magisk 有问题，而是 AVB 还在按原来的链做校验。你改了 boot，但没有告诉 AVB”别再检查它了”。

Warning

如果设备还没解锁 BL，千万不要直接刷写修改过的 boot 或 vbmeta。先解锁，再刷写，最后处理 AVB。

那怎么”告诉”AVB 别检查了呢？通常有两种办法：

刷写一个禁用了校验的 vbmeta — 把标志位改成 disable-verity 和 disable-verification
用空的 vbmeta 覆盖原来的 — 让 Bootloader 读不到校验信息，自然也就不检查了

具体用哪种方法，要看你的设备和你想达到的效果。

回滚保护#

最后还有一个容易被忽略的机制：回滚保护（Rollback Protection）。

你有没有遇到过这种情况：明明镜像版本更旧，但签名是对的，为什么还是刷写不进去？

这就是回滚保护在起作用。它的目的是防止设备被降级到旧版本——因为旧版本可能存在已知的安全漏洞。

具体怎么实现的呢？vbmeta 里会带一个回滚索引（rollback index），设备本地的安全存储（比如 TrustZone 或 TEE）也会记录一个当前允许的最低版本值。Bootloader 校验时会比较这两个值：

如果你刷写进去的镜像版本更旧，即使签名没问题，也可能直接被拒绝
如果版本相同或更新，才允许继续

这就是为什么有些设备”能把旧包刷写进去，fastboot 也没报错，但就是无法正常引导”——不是刷写失败了，而是回滚保护把它拦住了。

所以如果你想降级，光刷写镜像可能不够，还要看设备的回滚保护策略是不是允许。

参考资料#

Android 的 Root 与定制 ROM

Wed, 08 Apr 2026 00:00:00 GMT

Android 的 Root 与定制 ROM#

目录#

Tip

可直接点击文字跳转至对应章节

Android 的 Root 与定制 ROM

简介#

为什么要 Root？为什么要刷定制 ROM？

很多人并不是为了研究系统本身，而是因为原厂系统的各种限制：广告太多、后台限制太严、停更太快，或者 Google 服务体验不完整。Root 和定制 ROM 就是为了解决这些问题。

但在开始之前，先问自己几个问题：你真的需要 Root 吗？你的设备支持解锁 BL 吗？你能接受可能带来的风险吗？

如果答案是肯定的，那我们就来理一遍 Root 和定制 ROM 这块内容。

Root 与 su#

先说清楚 Root 到底是什么。

Root 就是 Android 的最高权限。因为 Android 底层是 Linux，所以 Root 这个概念也是从 Linux 的 root 用户来的。拿到 Root 后，你可以：

修改系统文件
运行各种需要高权限的模块
安装需要深度访问的工具

但这也意味着风险。删错文件、刷写错模块、修改错权限，结果都可能比普通 App 崩掉麻烦得多。

那 su 是什么？

su 是 Linux 里的 switch user 命令。Root 之后，很多 App 实际上就是通过调用 su 去提权的。

Root 管理器（比如 Magisk）的作用就是控制这个过程：当某个 App 请求 Root 权限时，管理器会弹出授权提示，你可以选择允许、拒绝或者仅本次放行。它还会记录每个 App 的请求历史，方便你随时调整权限策略。

主流 Root 方案#

现在主流的 Root 方案主要有这几种。它们的实现思路不同，适用场景也不一样。

Invalid directive. ("github" directive must be leaf type "::github{repo="owner/repo"}")

Android 的分区系统

Wed, 08 Apr 2026 00:00:00 GMT

Android 的分区系统#

目录#

Tip

可直接点击文字跳转至对应章节

Android 的分区系统

简介#

你有没有想过：Android 系统是怎么组织的？为什么刷机教程里有时候让你刷 boot，有时候让你刷 init_boot？为什么有些设备有 super 分区，有些没有？

这些都和 Android 的分区系统有关。由于 Android 版本不断迭代，新设备的分区结构已经比以前复杂不少。如果你后面要碰刷写、Root、AVB 这些，分区这块绕不过去。

我们一步步来理清楚。

几个最常见的分区#

先从最基本的说起：Android 设备上通常有哪些分区？它们各自负责什么？

boot — 保存内核与 ramdisk。很多 Root 方案直接是以启动时侵入来提权的，所以经常要修改这个分区
init_boot — Android 13+ 新设备常见，保存通用 ramdisk。这是 Google 为了实现 GKI（通用内核镜像）拆出来的
vendor_boot — 厂商相关的 ramdisk 和设备树
system — Android 系统主体文件，类似于 Windows 的 C:\Windows
vendor — 厂商驱动与 HAL（硬件抽象层）
vbmeta — AVB 校验元数据（在 AVB 那篇已经细说过了）
userdata — 用户数据分区，你的照片、应用数据都在这里。格式化这个分区会清空数据
super — 动态分区容器，里面可以切出多个逻辑分区（后面会详细说）

想知道你的设备上实际有哪些分区？可以用这个命令：

Terminal window

1
adb shell ls -la /dev/block/by-name/

你可能会发现，有些分区名后面还带着 _a 或 _b 后缀。这就引出了下一个话题：A/B 分区。

A-Only 与 A/B#

你有没有遇到过这种情况：系统 OTA 更新到一半突然断电，然后设备就开不了机了？

早期的 Android 设备就是这样。它们只有一套分区（A-Only），OTA 更新时直接覆盖原分区。更新过程中如果出问题——断电、网络中断、文件损坏——很容易直接把系统刷坏。

Google 在 Android 7.0 引入了 A/B 分区来解决这个问题。

A/B 分区的思路是什么？

准备两套槽位（slot_a 和 slot_b）：

平时从一套启动（比如 slot_a）
更新的时候写另一套（slot_b）
写完之后切换槽位，重启时从新的槽位启动
如果新槽位有问题，可以回退到旧槽位

这样 OTA 更稳定，更新失败也更容易回退。即使更新过程中断电，旧槽位的系统还是完整的，设备还能正常启动。

现在新设备基本都是 A/B 或者 Virtual A/B（后面会说），A-Only 越来越少见了。

这对刷机有什么影响？

如果你的设备是 A/B 分区，刷写的时候要注意当前在哪个槽位。很多刷机工具会自动处理，但如果手动刷写，最好先确认一下：

Terminal window

1
fastboot getvar current-slot

Virtual A/B 与动态分区#

A/B 分区解决了更新安全性的问题，但带来了新的问题：存储空间翻倍了。

因为你需要两套完整的系统分区（system_a 和 system_b、vendor_a 和 vendor_b 等等），这对存储空间的占用很大。

Google 在 Android 11 引入了 Virtual A/B 来解决这个问题。它的思路是：不再准备两套完整的分区，而是只存一套，更新时用快照（snapshot）和差异数据来实现 A/B 的效果。

这样既保留了 A/B 的安全性，又节省了存储空间。

而在 Android 10，Google 还引入了另一个重要概念：动态分区（Dynamic Partition）。

动态分区是什么意思？

以前每个分区的大小是固定的——system 多大、vendor 多大，出厂时就定死了。如果某个分区不够用了，你也没办法从别的分区借空间。

动态分区改变了这一点：很多原来独立的分区被塞进了一个叫 super 的容器里，大小可以动态调整。

所以你拿到新设备一看，分区名好像没几个，实际上很多原来独立的分区都被塞进了 super 里。

super 分区#

super 就是动态分区引入的容器。它不是普通意义上的单一分区，更像一个大的”仓库”。

这个仓库里装了什么？

通常包含这些逻辑分区：

system — 系统主体
vendor — 厂商驱动
product — 产品相关的定制
system_ext — 系统扩展
odm — 设备相关的定制

这些逻辑分区的大小可以动态调整。比如某次更新 system 需要更多空间，可以从 vendor 或 product 那边”借”一些，前提是总容量不超过 super 的大小。

这对刷机有什么影响？

如果你在教程里看到”动态分区”这个词，基本就绕不开 super。有些刷机操作需要重新分配 super 里的逻辑分区大小，或者直接刷写整个 super 镜像。

所以现在很多刷机包会提供 super.img，而不是单独的 system.img、vendor.img 等。

recovery 分区#

recovery 分区包含一个轻量级的恢复系统，像是设备的备用操作系统，用来在正常系统无法启动时提供帮助。

recovery 能做什么？

双清（wipe data 和 wipe cache）
刷入 OTA 更新包（官方更新通常通过它安装）
ADB sideload（通过电脑传入文件并刷写）
挂载分区、查看日志（调试用）

两种 recovery 模式：

Stock Recovery（原厂 recovery）— 功能有限，通常只能刷官方签名的包
Custom Recovery（第三方 recovery）— 比如 TWRP、OrangeFox，功能更强大，可以刷各种第三方包、备份整机、挂载分区进行修改等

对 LineageOS 这类第三方系统而言，你可能需要先刷一个第三方 recovery，然后通过它来刷入 ROM。

init_boot#

这个分区容易搞混，需要注意一下。

以前刷 Root，教程告诉你修补 boot.img 就行。但由于 GKI（Generic Kernel Image）和启动结构调整，部分 Android 13+ 设备把原来 boot 里的一部分内容（主要是 ramdisk）拆了出来，单独放到 init_boot。

为什么要拆？

GKI 的目标是让内核更通用、更新更快。拆分之后：

boot 主要装内核
init_boot 装 ramdisk（包含启动脚本、初始化配置等）

这样厂商可以单独更新内核，而不影响启动流程的其他部分。

对刷机的影响？

现在很多教程不是修补 boot.img，而是修补 init_boot.img。这不是教程写错了，而是设备的分区结构变了。

刷 Root 之前，最好先查清楚你的设备是哪种分区方案。通常：

老设备（Android 12 及以下）或不支持 GKI 的设备 → 修补 boot.img
新设备（部分 Android 13+）且支持 GKI → 修补 init_boot.img

可以用下面的命令检查设备是否有 init_boot：

Terminal window

1
fastboot getvar all | grep init_boot

如果有输出，说明你的设备有这个分区。

刷机时最常碰到的几个分区#

列一下实际操作中经常会遇到的分区：

boot — 装内核和 ramdisk（或只有内核，如果设备有 init_boot），Root 修补最常涉及的分区
init_boot — 新设备上拆出来的 ramdisk，部分设备 Root 需要修补它而不是 boot
vendor_boot — 厂商相关的启动配置，有些设备刷 Magisk 也需要处理它
vbmeta — AVB 校验元数据，刷第三方 ROM 时经常需要禁用它（--disable-verity --disable-verification）
userdata — 用户数据，格式化它相当于恢复出厂设置（双清的一部分）

操作场景：

修改 boot / init_boot → 通常和 Root 有关
修改 vbmeta → 通常和 AVB 校验有关（刷第三方包时需要禁用）
格式化 userdata → 通常和双清、解锁 BL、换 ROM 有关

分区这块先到这，谢谢阅读。

参考资料#

AOSP 官方文档

Android 的基本概念

Wed, 08 Apr 2026 00:00:00 GMT

Android 的基本概念#

目录#

Tip

可直接点击文字跳转至对应章节

Android 的基本概念

简介#

如果你刚开始接触 Android 刷机、Root 或者换 ROM，多半会被一堆术语搞晕：什么是 Bootloader？fastboot 和 ADB 有什么区别？为什么有人说”卡刷”，有人说”线刷”？AVB 又是什么东西？

这篇文章不会直接告诉你”怎么刷机”，而是把这些概念理一遍。遇到不认识的词，可以回来查。

Android 与 AOSP#

先从最基础的说起：Android 系统是从哪来的？

AOSP（Android Open Source Project）是 Google 开源的 Android 基础代码。所有 Android 设备，不管是 Google 自己的 Pixel，还是小米、三星、OPPO 的定制系统，甚至社区维护的第三方 ROM，都是在 AOSP 的基础上改出来的。

Pixel — Google 基于 AOSP 做的最接近原生的版本
HyperOS / One UI / ColorOS — 各家厂商的定制版本
LineageOS / crDroid — 社区维护的第三方 ROM

那 Android 底层是什么呢？答案是 Linux 内核。所以后面你会看到的 Root、SELinux、su 这些概念，其实都能绕回 Linux 的权限体系。

Bootloader（BL）#

你有没有想过：手机开机的时候，谁先跑起来？

答案是 Bootloader（引导加载程序）。它负责在系统启动之前初始化硬件，然后决定是否继续加载后面的镜像。

出厂时，Bootloader 通常是锁着的，只允许加载厂商认可并签名的镜像。这就是为什么你不能随便刷写第三方系统——Bootloader 会拒绝加载它。

那解锁 BL 之后呢？

解锁之后，设备允许加载第三方引导程序，你才能修改 boot、vbmeta、init_boot 这些关键分区。但这也带来了新问题：解锁时大多数设备会自动格式化 userdata 分区，也就是清空数据。部分品牌（比如三星）还会熔断 eFuse（Knox），不可逆。

解锁前后的区别#

BL 带锁时：

Bootloader 只信任厂商认可的签名
关键分区被修改后，设备通常直接拒绝启动

BL 解锁后：

允许加载第三方引导程序
你可以刷写修改过的镜像
重启时会显示”设备已解锁”的警告

解锁命令通常是：

Terminal window

1
fastboot flashing unlock

Warning

解锁时大多数设备会自动格式化 userdata 分区，也就是清空数据。部分品牌还会熔断 eFuse（如三星 Knox），不可逆。

各家解锁政策#

不同厂商对解锁的态度差别很大：

Google Pixel — 最简单，直接 fastboot flashing unlock
小米 — 国内现在基本走不了官方渠道，账号、答题、等待期都加上了
一加 / OPPO — 很多机型要走深度测试或审核流程
三星 — 限制更重，不同地区差异很大
vivo / 荣耀 / 华为 — 官方一般不开放解锁路径

如果你打算刷机，最好买设备之前先查一下能不能解锁 BL。

fastboot 与 EDL#

解锁了 BL 之后，怎么和设备通信呢？这就要用到 fastboot。

fastboot 是 PC 和 Bootloader 之间通信的协议。手机进入 fastboot 模式后，你可以在电脑上直接操作设备：

Terminal window

1
# 解锁 BL
2
fastboot flashing unlock
3

4
# 刷写镜像到指定分区
5
fastboot flash boot patched_boot.img
6

7
# 临时启动一个镜像（不写入分区）
8
fastboot boot recovery.img
9

10
# 重启设备
11
fastboot reboot

这里特别注意 fastboot boot 这个命令——它只是临时启动一个镜像，不会写进分区。重启之后设备会恢复原样。这在测试 Recovery 或者修补过的 boot 时特别有用：你可以先临时启动看看效果，确认没问题再正式刷写。

那 EDL 是什么？

EDL（Emergency Download Mode，也叫 9008 模式）是高通平台更底层的救砖模式。当设备完全开不了机、fastboot 也进不去的时候，EDL 可能是最后的救命稻草。

不过 EDL 一般需要授权文件或者官方工具才能用，普通情况下用不到。

ADB#

你可能听说过 ADB，也可能听说过 fastboot，那它们是一回事吗？

不是。它们工作在不同的阶段：

fastboot — 工作在 Bootloader 阶段，设备还没启动系统
ADB（Android Debug Bridge）— 工作在系统或 Recovery 启动之后

ADB 是日常调试最常用的工具。你可以用它查看设备状态、推送文件、安装应用、进入 shell：

Terminal window

1
# 查看连接的设备
2
adb devices
3

4
# 进入设备的 shell
5
adb shell
6

7
# 推送文件到设备
8
adb push local_file /sdcard/
9

10
# 从设备拉取文件
11
adb pull /sdcard/remote_file ./
12

13
# 安装 APK
14
adb install app.apk

所以如果有人让你”在 fastboot 模式下用 ADB”，那肯定是搞混了——fastboot 模式下只能用 fastboot 命令，ADB 要等系统启动起来才能用。

Recovery#

你有没有想过：如果系统坏了，连桌面都进不去，怎么修复？

这就是 Recovery 存在的意义。它是独立于主系统之外的一个小环境，主要用来做系统维护——刷写升级包、清分区、恢复出厂设置、备份和恢复。

出厂自带的 Recovery 功能通常比较有限，只能刷写官方签名的 OTA 包。如果你想刷写第三方 ROM 或者 Magisk，就需要第三方 Recovery。

常见的第三方 Recovery 有：

Invalid directive. ("github" directive must be leaf type "::github{repo="owner/repo"}")

训练 LLM 的心得分享

Fri, 27 Feb 2026 00:00:00 GMT

训练 LLM 的心得分享：从零到 Liko 第五代#

目录#

Tip

可直接点击文字跳转至对应章节

训练 LLM 的心得分享：从零到 Liko 第五代
训练框架
版本演进
- 预训练数据演进
- V4-和-V5-详细对比
- [SFT-数据演进 V1→V5](#sft-数据演进 v1→v5)
训练过程

简介#

该文档分享了我从零开始训练中文 LLM 的实践心得，目前已经迭代到了 Liko（灵可）第五代。

Tip

训练一个 LLM 需要考虑多种因素，数据清洗是最关键的一步

训练环境#

硬件配置#

说实话，训练 LLM 对硬件要求还是挺高的。我目前使用的是：

GPU: 单卡 RTX 4090 24G（租的）
内存: 90G(我这里是AutoDL分给我的Docker容器,AutoDL实际主机的大概在730G左右)
磁盘: 30G系统盘 + 50G 数据缓存盘

Tip

这也是我选择租 GPU 服务器的原因——毕竟不是每个人都有多卡高配置的环境

目前训练数据量在 10GB 左右，数据和模型差不多有个 125M 的水平。这个规模对于个人实验来说比较合适，既不会太消耗资源，也能看到不错的效果。

数据准备#

数据集选择#

训练过程中下载的是 CCI3-HQ 分卷，数据量大概 11GB 左右。

经过对比，我发现 CCI3-HQ 相对来说比 CCI3-Data 要更干净，因为是已经清理过的数据。这一点非常重要——训练一个 LLM，数据必须得是清洗过的。

Warning

关于分词器的选择：如果你要训练中文模型，最好使用 Qwen 的分词器。我这里使用的是 GPT 的分词器，可能不是最优选择。

可用数据资源#

以下是一些我整理的开源数据资源：

BAAI 开源的数据（需要自行同意许可）:

代码训练集:

StarCoder2

BigCode 开源的数据（需要自行同意许可）:

训练框架#

目前使用的是 nanochat 外加 LLM 自己写的脚本。

后续 V6 版本我准备使用 uv + HuggingFace Transformers 来进行训练。

版本演进#

从 V1 到 V5，Liko 模型经历了多次迭代，以下是各版本的数据和训练情况：

预训练数据演进#

版本	数据源	数据量	Token 数量	备注
V1/V2	项目内早期小语料	-	~19 万	早期小语料测试
V3	simplewiki 样本	~25MB	~2,645 万	加入维基百科数据
V4	中文维基清洗语料	~2.6GB	~27.5 亿	主增量，使用 CCI2-Data 抽样
V5	BAAI/CCI3-HQ	10.778GB (11 分卷)	~76 亿	当前版本，GPT-2 BPE 预处理

V4 和 V5 详细对比#

V4:

训练数据：BAAI/CCI2-Data 抽样文件 cci2_approx_5gb.jsonl
规模：1,826,579 行
训练结论：20k 步跑完，最佳点在 ~15.8k 附近（val_loss 最低）

V5:

训练数据：BAAI/CCI3-HQ，11 个分卷共 10.778GB
预处理：GPT-2 BPE
- 行数：1,836,229
- 训练 tokens：7,593,980,487
- 验证 tokens：400,017,578
- 词表大小：50,257
训练结论：40k 步明显优于 70k 步

Warning

为什么 70k 步反而不如 40k 步？

70k 步是从 40k 步的检查点继续训练的，而且学习率没有正确调整，导致模型出现退化现象（输出乱码）。这说明了学习率调度和训练步数规划的重要性。

SFT 数据演进（V1→V5）#

版本	数据文件	条数	说明
V1	`liko_train_std_expanded_v1.jsonl`	126	基于规范问答扩写
V2	`liko_train_std_expanded_v2.jsonl`	198	新增 72 条，强化身份认知 + 防提示词注入
V3	`liko_train_std_expanded_v3_multilingual.jsonl`	294	新增 96 条，加入多语言样本
V4	`tiny_sft_v4_mix.jsonl`	720	混合版（60% 通用对话/30% 规范问答/10% 身份防注入）

Tip

V5 的 40k 步 checkpoint 是目前最佳模型。70k 步是从 40k 步检查点继续训练，因学习率未正确调整导致退化

训练过程#

训练步数与-Loss-曲线#

训练步数和 Loss 曲线是监控训练过程的重要指标。通过观察这些曲线，可以判断模型是否过拟合、欠拟合，或者是否需要调整学习率等超参数。

以下是 Liko 第五代从 0 到 40k 步的训练日志曲线：

训练日志曲线 (0-40k)

模型测试输出#

在训练到 40k 步时，我进行了多次采样测试（均未进行 SFT 微调）：

测试配置 1（温度 0.7，max_tokens=50）:

推理测试 - 温度 0.7

测试配置 2（温度 0.9，repetition_penalty=1.15，top-k=50）:

续写测试 - 温度 0.9

Tip

以上测试均直接使用基础模型采样，未进行 SFT 微调

GPU-租赁的优势#

租 GPU 服务器确实是一个比较好的选择：

成本低：几块钱就能跑一次训练
灵活：可以根据需求选择不同的配置
无需维护：不用自己操心硬件维护

Tip

几块钱就能把一个中文模型带回家，已经是一个不错的成就了

训练-LLM-需要考虑的因素#

经过这段时间的实践，我总结出训练 LLM 需要考虑以下几个关键因素：

因素	说明
GPU 显存和算力	显存大小决定了你能训练多大的模型，算力决定了训练速度
RAM 运行内存	数据处理和加载需要足够的内存，否则会成为瓶颈
磁盘空间	训练数据通常很大，需要足够的磁盘空间来存储

总结#

训练一个 LLM 确实需要考虑多种因素，但通过合理的选择和规划，个人也能完成这个看似”高大上”的任务。

目前的 Liko 第五代还在持续训练中，后续会继续分享更多的经验和成果。如果你对训练 LLM 感兴趣，欢迎一起交流讨论！

Tip

希望有老哥送给我多卡高配置的 GPU，还有一个比较好的带宽服务器

参考资源#

类型	链接
HuggingFace 镜像	https://hf-mirror.com/
Transformers 学习	https://huggingface.co/docs/transformers/main_classes/trainer

数据#

Tip

本文提到的所有数据集和工具均需要自行配置和下载

配置 Docker 镜像源

Fri, 26 Dec 2025 00:00:00 GMT

配置Docker Compose源#

Tip

可直接点击文字跳转至对应章节

目录#

配置Docker Compose源

简介#

在国内，由于部分运营商可能对国外网站或镜像源进行 SNI 拦截或 DNS 污染，直接访问官方 Docker 镜像源可能会较慢甚至失败。因此，建议使用 国内加速源 来拉取 Docker 安装包和镜像，从而提升下载速度和稳定性。

安装 Docker#

使用 LinuxMirror 脚本安装#

使用 LinuxMirror 提供的脚本进行安装(推荐)

Terminal window

1
bash <(curl -sSL https://linuxmirrors.cn/docker.sh)

使用官方脚本安装#

或者使用 Docker Hub 官方提供的脚本进行安装

Terminal window

1
bash <(curl -fsSL https://get.docker.com)

指定镜像源安装#

再或者使用 Docker Hub 官方提供的脚本进行安装再指定镜像源(—mirror 后的参数为镜像源)

Terminal window

1
bash <(curl -fsSL https://get.docker.com) --mirror Aliyun

Tip

如已经安装，只需要修改 Docker 部分请跳转至配置docker

配置 Docker#

一般针对于小白,我比较推荐直接使用 Docker Compose 来完成部署项目，因为部署只需要写好 docker-compose.yaml 文件，随后在 docker-compose.yaml 的同级目录运行 docker compose up -d 即可完成部署。

好了，我们开始配置 Docker Registry 源的配置。

使用脚本修改#

上方我们有提到使用安装脚本,那么这里也可以使用直接脚本来完成修改。

Terminal window

1
bash <(curl -sSL https://linuxmirrors.cn/docker.sh)

自行修改#

自行修改 Docker 源,这也是一种备选方式,也是我个人比较推荐的方式。

编辑配置文件#

Terminal window

1
# 可选备份
2
cp /etc/docker/daemon.json /etc/docker/daemon.json.bak
3

4
# 使用nano 编辑器(推荐)
5
nano /etc/docker/daemon.json
6

7
# 或使用vim编辑器
8
vim /etc/docker/daemon.json

Tip

如果没有安装 nano 编辑器，请自行使用 apt 安装。

如果显示没有权限修改，请在命令前加上 sudo ，打比方：sudo nano "/etc/..." 。

Vim 退出时需要按下 ESC 后,输入 :wq 命令后回车来进行写入并退出。

文件示例#

这里给个示例,且使用的 毫秒镜像 源。你可以直接复制并将它写入你的文件。

1
{
2
  "registry-mirrors": ["https://docker.1ms.run"]
3
}

重载服务#

Warning

注意重载 Docker 服务时,所有的 Docker 容器及服务会重启。

修改 daemon.json 后需要重载服务，才能让新配置生效。

重载服务

Terminal window

1
systemctl daemon-reexec
2
systemctl restart docker

如果无法执行此命令请在命令前添加 sudo 。

重载完成后，你可以使用以下命令来验证配置是否生效：

Terminal window

1
docker info | grep -A 5 "Registry Mirrors"

如果输出中包含你配置的镜像源地址，说明配置生效了。

Docker镜像源列表#

这里是 Docker Registry 列表

1
# 毫秒镜像
2
http://docker.1ms.run
3

4
# DockerProxy
5
http://dockerproxy.net
6

7
# DaoCloud
8
http://docker.m.daocloud.io
9

10
# 阿里云
11
http://registry.cn-hangzhou.aliyuncs.com     # 阿里云-杭州
12
http://registry.cn-shanghai.aliyuncs.com    # 阿里云-上海
13
http://registry.cn-qingdao.aliyuncs.com    # 阿里云-青岛
14
http://registry.cn-beijing.aliyuncs.com     # 阿里云-北京
15
http://registry.cn-zhangjiakou.aliyuncs.com # 阿里云-张家口
16
http://registry.cn-huhehaote.aliyuncs.com   # 阿里云-呼和浩特
17
http://registry.cn-wulanchabu.aliyuncs.com  # 阿里云-乌兰察布
18
http://registry.cn-shenzhen.aliyuncs.com   # 阿里云-深圳
19
http://registry.cn-heyuan.aliyuncs.com      # 阿里云-河源
20
http://registry.cn-guangzhou.aliyuncs.com   # 阿里云-广州
21
http://registry.cn-chengdu.aliyuncs.com    # 阿里云-成都
22
http://registry.cn-hongkong.aliyuncs.com    # 阿里云-香港
23
http://registry.ap-northeast-1.aliyuncs.com  # 阿里云-日本
24
http://registry.ap-southeast-1.aliyuncs.com # 阿里云-新加坡
25
http://registry.ap-southeast-3.aliyuncs.com # 阿里云-马来西亚
26
http://registry.ap-southeast-5.aliyuncs.com # 阿里云-印尼
27
http://registry.eu-central-1.aliyuncs.com   # 阿里云-德国
28
http://registry.eu-west-1.aliyuncs.com      # 阿里云-英国
29
http://registry.us-west-1.aliyuncs.com      # 阿里云-美国西部
30
http://registry.us-east-1.aliyuncs.com       # 阿里云-美国东部
31
http://registry.me-east-1.aliyuncs.com      # 阿里云-中东
32

33
# 腾讯云镜像
34
http://mirror.ccs.tencentyun.com
35

36
# Google 镜像
37
https://gcr.io
38
https://asia.gcr.io
39
https://eu.gcr.io
40

41
# Docker Hub 官方镜像
42
https://registry.hub.docker.com

显示更多显示更少

使用Docker Compose快速部署NapCat

Thu, 27 Nov 2025 00:00:00 GMT

使用Docker Compose快速部署NapCat#

目录#

Tip

可直接点击文字跳转至对应章节

使用Docker Compose快速部署NapCat

简介#

该文档介绍了如何使用Docker Compose快速部署NapCat。

Tip

该文章只针对于Linux系统

什么是NapCat?#

基于 TypeScript 构建的 Bot 框架，通过相应的启动器或者框架，主动调用 QQ Node 模块提供给客户端的接口，实现 Bot 的功能。

开始#

安装Docker#

运行以下命令安装Docker(如果已经安装Docker可以跳过此步骤)：

Terminal window

1
bash <(curl -sSL https://linuxmirrors.cn/docker.sh)

随后根据脚本提示完成Docker的安装。

下载NapCat Docker Compose文件#

你可以使用以下命令将 docker-compose.yml 文件下载到你的项目目录中：

Terminal window

1
cd /path/to/your/project
2
curl -o docker-compose.yml https://raw.githubusercontent.com/KaguyaRing/NapCat-Docker-Template/main/docker-compose.yml

或者使用Github代理：

Terminal window

1
cd /path/to/your/project
2
curl -sSL-o docker-compose.yml https://gh-proxy.org/https://raw.githubusercontent.com/KaguyaRing/NapCat-Docker-Template/main/docker-compose.yml

此处的 /path/to/your/project 需要替换为你希望存放 docker-compose.yml 文件的实际路径。

docker-compose.yml 只部署NapCat服务，如果你需要其他服务，请替换为相应的模板文件名称。

该项目已经提供了NapCat单服务、AstrBot+Napcat、等多种模板文件，您可以根据需要选择合适的模板文件进行下载。

启动服务#

只需要在包含该仓库下载的 docker-compose.yml 文件的目录下运行以下命令即可启动 NapCat 服务：

Terminal window

1
docker compose up -d

查看日志#

你可以使用以下命令查看 NapCat 服务的日志以获取Token登录WebUI：

Terminal window

1
docker compose logs napcat

停止服务#

你可以使用以下命令停止 NapCat 服务：

Terminal window

1
docker compose down

重启服务#

你可以使用以下命令重启 NapCat 服务：

Terminal window

1
docker compose restart napcat

对接#

Tip

NapCat 支持多种对接方式，您可以参考官方文档进行配置：

NapCat 对接文档

附加说明#

Tip

该仓库已经提供了NapCat单服务、AstrBot+Napcat、多种模板文件，您可以根据需要选择合适的模板文件进行下载。

KaguyaRing

NapCat-Docker-Template

Waiting for api.github.com...

00K

Waiting...

免责声明#

Warning

为了确保 NapCat 服务的安全性,此处已经将 调试端口 只允许本地访问,如果你需要部署到外网调试您的NapCat，请手动移除 docker-compose.yml 文件中 napcat 服务的 post 中的 127.0.0.1移除，如果手动移除后遭到任何安全问题,本仓库及作者概不负责。

数据#

Tip

该仓库的模板文件均存储在 ./data/* 目录下， *为对接框架的名称，您可以根据需要进行修改和定制。 ./data/napcat 目录存储NapCat服务的数据。 ./data/qq 目录存储QQ账号的数据。

Unity中国特供转国际版本

Wed, 26 Nov 2025 00:00:00 GMT

Unity中国特供转国际版本#

目录#

Tip

可直接点击文字跳转至对应章节

简介
判断
为什么要安装国际版本
解决方法
Unity 列表
引用
示例图片

简介#

此文章说明如何解决安装Unity时为中国特供版本,如何转换为国际版本的帮助。

判断#

查看Unity Hub安装的Unity版本后缀是否携带c1后缀,如果有则为中国特供版本,否则为国际版本。

为什么要安装国际版本#

Unity中国特供版存在功能限制，强制用户安装中国特供版本的Unity等。

以下内容引用自Unity中国想钱想疯了。

1
这次事件再次证明了两点
2

3
1. Unity官方无论是对于本文中提及的收入问题，还是这次如何计算下载量问题，都属于拍脑袋定的政策，完全没有明确的量化标准。
4
2. Unity内部也不统一思想，官网的解释都能互相矛盾。
5
这次定价不仅对中小开发者和独立开发者不友好，还是要杀死超休闲游戏的节奏。国内情况我不清楚，但海外如voodoo这种超休闲大厂，很多产品就是Unity做的，推广纯靠买量，一个用户买量成本也就几美分，现在即使按照最便宜的档位算，也几乎成本翻倍了，这谁顶得住？

解决方法#

如果已经安装了Unity,请先卸载当前版本的Unity,然后再尝试进行以下步骤。

方法一#

也是最简单的方法通过官方的Unity Editor官方的发行界面下载Unity Editor,随后将安装好的Unity版本添加至UnityHub(可选)。

点我跳转至官方的Unity Editor发行界面

方法二#

使用代理软件来进行安装,市面上有很多代理软件可供选择,例如Shadowsocks、V2Ray、Clash等。

以下是推荐代理软件的GitHub仓库地址(现依旧在更新的仓库,截至2025.11.26):

v2rayN - 客户端多平台支持
Clash Verge - Clash 变体客户端，支持 Windows/Mac/Linux，GUI 友好，兼容 Meta 内核。

如果你使用的是Shadowsocks/Clash类的代理软件，只需修改浏览器的HTTP/HTTPS代理或者修改规则即可

以下是在Windows/MacOS系统的解决方式

Windows:

将以下文本使用 记事本 或者其他编辑器保存后,右键重命名为 .bat 后缀名

点我跳转至示例截图

Terminal window

1
@echo off
2

3
# 此处1080为你的代理端口,如果代理端口不在1080,请修改为你的代理端口
4
set HTTP_PROXY=http://127.0.0.1:1080
5
set http_proxy=http://127.0.0.1:1080
6
set HTTPS_PROXY=http://127.0.0.1:1080
7
set https_proxy=http://127.0.0.1:1080
8

9
# 此处为Unity Hub的默认安装路径,如果你的安装路径不一样请修改为你的安装路径
10
start "" "C:\Program Files\Unity Hub\Unity Hub.exe"

MacOS：需要在终端中运行下面脚本，然后把生成的launchUnityHub.command挪到一个方便的位置（例如桌面）

Terminal window

1
echo '#!/bin/bash
2
# 此处1080为你的代理端口,如果代理端口不在1080,请修改为你的代理端口
3
export HTTP_PROXY=http://127.0.0.1:1080
4
export http_proxy=http://127.0.0.1:1080
5
export HTTPS_PROXY=http://127.0.0.1:1080
6
export https_proxy=http://127.0.0.1:1080
7
nohup "/Applications/Unity Hub.app/Contents/MacOS/Unity Hub" &>/dev/null &' > launchUnityHub.command
8
chmod +x launchUnityHub.command

双击运行生成的launchUnityHub.command即可启动Unity Hub。

方法二#

如果你的代理软件支持TUN模式,可以直接开启TUN模式+全局代理。

如果有已安装的Unity Hub版本，先卸载，为以防万一，卸载之后删除~/AppData/Roaming这个目录下的Unity Hub目录。然后再安装。 Windows可以运行以下命令以删除Unity Hub的配置文件夹:

Terminal window

1
rd /s /q " %USERPROFILE%\AppData\Roaming\UnityHub"

直接开启TUN模式,然后直接下载Unity国际版本。

点击这里下载Windows版本点击这里下载MacOS版本

这里有一些Unity编辑器的软链接安装版本列表

点我跳转至安装版本列表

Unity 列表#

VRChat官方给出的Unity版本是2022.3.22f1

点击此处安装VRChat官方推荐的Unity版本

这里是Unity软连接地址(点击对应版本号会自动唤起本地的Unity Hub应用开始安装对应版本的Unity):

Tips: 如果你下列没有需要版本你可以以unityhub://开头然后又添加上 {版本号} 的格式来安装其他版本的Unity。

由于版本有点多,我给出了一个版本目录(基于如何取得Unity Hub内旧版本Unity下载链接基础上优化显示)方便你更好的找到他们。

Unity 2020.1#

2020.1.1xf1

2020.1.17f1/9957aee8edc2

2020.1.16f1/f483ad6465d6

2020.1.15f1/97d0ae02d19d

2020.1.14f1/d81f64f5201d

2020.1.13f1/5e24f28bfbc0

2020.1.12f1/55b56f0a86e3

2020.1.11f1/698c1113cef0

2020.1.10f1/974a9d56f159

2020.1.xf1

2020.1.9f1/145f5172610f

2020.1.8f1/22e8c0b0c3ec

2020.1.7f1/064ffcdb64ad

2020.1.6f1/fc477ca6df10

2020.1.5f1/e025938fdedc

2020.1.4f1/fa717bb873ec

2020.1.3f1/cf5c4788e1d8

2020.1.2f1/7b32bc54ba47

2020.1.1f1/2285c3239188

2020.1.0f1/2ab9c4179772

Unity 2019.4(LTS)#

2019.4.2xf1

2019.4.20f1/6dd1c08eedfa

2019.4.1xf1

2019.4.19f1/ca5b14067cec

2019.4.18f1/3310a4d4f880

2019.4.17f1/667c8606c536

2019.4.16f1/e05b6e02d63e

2019.4.15f1/fbf367ac14e9

2019.4.14f1/4037e52648cd

2019.4.13f1/518737b1de84

2019.4.12f1/225e826a680e

2019.4.11f1/2d9804dddde

2019.4.10f1/5311b3af6f69

2019.4.xf1

2019.4.9f1/50fe8a171dd9

2019.4.8f1/60781d942082

2019.4.7f1/e992b1a16e65

2019.4.6f1/a7aea80e3716

2019.4.5f1/81610f64359c

2019.4.4f1/1f1dac67805b

2019.4.3f1/f880dceab6fe

2019.4.2f1/20b4642a3455

2019.4.1f1/e6c045e14e4e

2019.4.0f1/0af376155913

Unity 2019.3#

2019.3.1xf1

2019.3.15f1/59ff3e03856d

2019.3.14f1/2b330bf6d2d8

2019.3.13f1/d4ddf0d95db9

2019.3.12f1/84b23722532d

2019.3.11f1/ceef2d848e70

2019.3.10f1/5968d7f82152

2019.3.xf1

2019.3.9f1/e6e740a1c473

2019.3.8f1/4ba98e9386ed

2019.3.7f1/6437fd74d35d

2019.3.6f1/5c3fb0a11183

2019.3.5f1/d691e07d38ef

2019.3.4f1/4f139db2fdbd

2019.3.3f1/7ceaae5f7503

2019.3.2f1/c46a3a38511e

2019.3.1f1/89d6087839c2

2019.3.0f6/27ab2135bccf

Unity 2019.2#

2019.2.1xf1

2019.2.21f1/9d528d026557

2019.2.20f1/c67d00285037

2019.2.19f1/929ab4d01772

2019.2.18f1/bbf64de26e34

2019.2.17f1/8e603399ca02

2019.2.16f1/b9898e2d04a4

2019.2.15f1/dcb72c2e9334

2019.2.14f1/49dd4e9fa428

2019.2.13f1/e20f6c7e5017

2019.2.12f1/b1a7e1fb4fa5

2019.2.11f1/5f859a4cfee5

2019.2.10f1/923acd2d43aa

2019.2.xf1

2019.2.9f1/ebce4d76e6e8

2019.2.8f1/ff5b465c8d13

2019.2.7f2/c96f78eb5904

2019.2.5f1/9dace1eed4cc

2019.2.4f1/c63b2af89a85

2019.2.3f1/8e55c27a4621

2019.2.2f1/ab112815d860

2019.2.1f1/ca4d5af0be6f

2019.2.0f1/20c1667945cf

Unity 2019.1#

2019.1.1xf1

2019.1.14f1/148b5891095a 2019.1.13f1/b5956c0a61e7 2019.1.12f1/f04f5427219e 2019.1.11f1/9b001d489a54 2019.1.10f1/f007ed779b7a

2019.1.xf1

2019.1.9f1/d5f1b37da199 2019.1.8f1/7938dd008a75 2019.1.7f1/f3c4928e5742 2019.1.6f1/f2970305fe1c 2019.1.5f1/0ca0f5646614 2019.1.4f1/ffa3a7a2dd7d 2019.1.3f1/dc414eb9ed43 2019.1.2f1/3e18427e571f 2019.1.1f1/fef62e97e63b 2019.1.0f2/292b93d75a2c

Unity 2018.4(LTS)#

2018.4.32f1

2018.4.32f1/fba45da84107

2018.4.31f1/212ea663d844

2018.4.30f1/c698a062d8e6

2018.4.29f1/50cce2edf27f

2018.4.28f1/a2d4f71491a4

2018.4.27f1/4e283b7d3f88

2018.4.26f1/a7ac1c6396db

2018.4.25f1/b07bfa0a8827

2018.4.24f1/3071911a89e9

2018.4.23f1/c9cf1a90e812

2018.4.22f1/3362ffbb7aa1

2018.4.21f1/fd3915227633

2018.4.20f1/008688490035

2018.4.1xf1

2018.4.19f1/459f70f82ea4

2018.4.18f1/61fce66342ad

2018.4.17f1/b830f56f42f0

2018.4.16f1/e6e9ca02b32a

2018.4.15f1/13f5a1bf9ca1

2018.4.14f1/05119b33d0b7

2018.4.13f1/497f083a43af

2018.4.12f1/59ddc4c59b4f

2018.4.11f1/7098af2f11ea

2018.4.10f1/a0470569e97b

2018.4.9f1/ca372476eaba

2018.4.8f1/9bc9d983d803

2018.4.7f1/b9a993fd1334

2018.4.6f1/cde1bbcc9f0d

2018.4.5f1/7b38f8ac282e

2018.4.4f1/5440768ff61c

2018.4.3f1/8a9509a5aff9

2018.4.2f1/d6fb3630ea75

2018.4.1f1/b7c424a951c0

2018.4.0f1/b6ffa8986c8d

Unity 2018.3#

2018.3.1xf1

2018.3.14f1/d0e9f15437b1

2018.3.13f1/06548a9e9582

2018.3.12f1/8afd630d1f5b

2018.3.11f1/5063218e4ab8

2018.3.10f1/f88de2c96e63

2018.3.9f1/947e1ea5aa8d

2018.3.8f1/fc0fe30d6d91

2018.3.7f1/9e14d22a41bb

2018.3.6f1/a220877bc173

2018.3.5f1/76b3e37670a4

2018.3.4f1/1d952368ca3a

2018.3.3f1/393bae82dbb8

2018.3.2f1/b3c100a4b73a

2018.3.1f1/bb579dc42f1d

2018.3.0f2/6e9a27477296

Unity 2018.2#

2018.2.2xf1

2018.2.21f1/a122f5dc316d

2018.2.20f1/cef3e6c0c622

2018.2.1xf1

2018.2.19f1/06990f28ba00

2018.2.18f1/4550892b6062

2018.2.17f1/88933597c842

2018.2.16f1/39a4ac3d51f6

2018.2.15f1/65e0713a5949

2018.2.14f1/3262fb3b0716

2018.2.13f1/83fbdcd35118

2018.2.12f1/0a46ddfcfad4

2018.2.11f1/38bd7dec5000

2018.2.10f1/674aa5a67ed5

2018.2.xf1

2018.2.9f1/2207421190e9

2018.2.8f1/ae1180820377

2018.2.7f1/4ebd28dd9664

2018.2.6f1/c591d9a97a0b

2018.2.5f1/3071d1717b71

2018.2.4f1/cb262d9ddeaf

2018.2.3f1/1431a7d2ced7

2018.2.2f1/c18cef34cbcd

2018.2.1f1/1a9968d9f99c

2018.2.0f2/787658998520

Unity 2018.1#

2018.1.xf2

2018.1.9f2/a6cc294b73ee

2018.1.8f1/26051d4de9e9

2018.1.7f1/4cb482063d12

2018.1.6f1/57cc34175ccf

2018.1.5f1/732dbf75922d

2018.1.4f1/1a308f4ebef1

2018.1.3f1/a53ad04f7c7f

2018.1.2f1/a46d718d282d

2018.1.1f1/b8cbb5de9840

2018.1.0f2/d4d99f31acba

Unity 2017.4(LTS)#

2017.4.4xf1

2017.4.40f1/6e14067f8a9a

2017.4.3xf1

2017.4.39f1/947131c5be7e

2017.4.38f1/82ac2fb100ce

2017.4.37f1/78b69503ebc4

2017.4.36f1/c663def8414c

2017.4.35f1/e57a7bcbbf0b

2017.4.34f1/121f18246307

2017.4.33f1/a8557a619e24

2017.4.32f1/4da3ed968770

2017.4.31f1/9c8dbc3421cb

2017.4.30f1/c6fa43736cae

2017.4.2xf1

2017.4.29f1/06508aa14ca1

2017.4.28f1/e3a0f7dd2097

2017.4.27f1/0c4b856e4c6e

2017.4.26f1/3b349d10f010

2017.4.25f1/9cba1c3a94f1

2017.4.24f1/786769fc3439

2017.4.23f1/f80c8a98b1b5

2017.4.22f1/eb4bc6fa7f1d

2017.4.21f1/de35fe252486

2017.4.20f2/413dbd19b6dc

2017.4.1xf1

2017.4.19f1/47cd37c28be8

2017.4.18f1/a9236f402e28

2017.4.17f1/05307cddbb71

2017.4.16f1/7f7bdd1ef02b

2017.4.15f1/5d485b4897a7

2017.4.14f1/b28150134d55

2017.4.13f1/6902ad48015d

2017.4.12f1/b582b87345b1

2017.4.11f1/8c6b8ef6d111

2017.4.10f1/f2cce2a5991f

2017.4.10f1

2017.4.9f1/6d84dfc57ccf

2017.4.8f1/5ab7f4878ef1

2017.4.7f1/de9eb5ca33c5

2017.4.6f1/c24f30193bac

2017.4.5f1/89d1db9cb682

2017.4.4f1/645c9050ba4d

2017.4.3f1/21ae32b5a9cb

2017.4.2f2/52d9cb89b362

2017.4.1f1/9231f953d9d3

Unity 2017.3#

2017.3.1f1/fc1d3344e6ea

2017.3.0f3/a9f86dcd79df

Unity 2017.2#

2017.2.5f1/588dc79c95ed

2017.2.4f1/f1557d1f61fd

2017.2.3f1/372229934efd

2017.2.2f1/1f4e0f9b6a50

2017.2.1f1/94bf3f9e6b5e

2017.2.0f3/46dda1414e51

Unity 2017.1#

2017.1.5f1/9758a36cfaa6

2017.1.4f1/9fd71167a288

2017.1.3f1/574eeb502d14

2017.1.2f1/cc85bf6a8a04

2017.1.1f1/5d30cf096e79

2017.1.0f3/472613c02cf7

Unity 5#

Unity5.6以下版本不支持从Unity Hub中部署，故无法提供链接

引用#

文章引用了大部分文章并总结,原文地址如下:

如何逃离Unity中国特供版

Unity中国想钱想疯了

如何取得Unity Hub内旧版本Unity下载链接