方案分析 on LiaoKe的个人博客

方案分析 | 2026年软路由系统分析和推荐

Wed, 18 Feb 2026 00:00:00 +0000

2026年软路由系统分析和推荐

截止到目前为止,还在持续维护更新的软路由系统有openwrt系,ikuai,RouterOS.

三大系统简述

ikuai系统不开源,可玩性和软件生态上比openwrt和RouterOS差,但是稳定,适用于对稳定性和兼容性要求比较高的工作环境，比如说企业.
Routeros系统是开源的,基于linux,但是软件生态和可玩性也不如openwrt,Linux内核版本也较低,主打的也是偏稳定向的.
openwrt系统是开源的,相当于阉割魔改版之后的linux（linux可以干的,openwrt通过补全环境和其他方法，基本都可以干,如docker,php,python等）,且积极更新Linux内核和对应s组件依赖,社区力量和软件包是远远大于另外两个软路由系统的,由于openwrt系统非常轻量，所以适配的硬件特别广.而另外两个软路由系统对硬件的要求多相对较高,而openwrt各种嵌入式设备也可以刷入,很多厂商的硬路由openwrt也会适配.所以对于个人玩家来说,强烈推荐openwrt系.

openwrt系分支

而openwrt系又主要分openwrt官方系统,immortalwrt,kwrt,lead,x-wrt,istoreos

openwrt官方系统:

是所有其他分支的源头，更新速度最快,但是软件包源服务器是在国外，国内用户无法直接更新里面的软件包,而且官方服务器里面的软件包数量很少.

immortalwrt:

基于openwrt源代码轻量改动,可以看成openwrt中国特供版,而且极大的丰富了软件包数量,有很多github上面的第三方的软件包，以及把软件包服务器改成了在国内,还有一些其他的优化以及添加了更多的硬件支持,但是每当openwrt新的版本出来,immortalwrt需要过一小段时间才能适配完

kwrt:

基于openwrt,可以看成在openwrt源代码的基础上，自己写了一套代码流程来自定义一些东西,有自己自建的软件仓库,里面软件的数量是openwrt系里面最多的,构建系统镜像的时候还可以提前自定义后台IP地址，宽带账号之类的东西,但是魔改的比较多，特别容易出bug（比如我的r2s固件直接开不了机）,而且这个系统作者的名声在圈内不太好,合并上游系统速度还算及时(immortal需要一点时间)

lede:

准确来说是lean的lede,最原始的lede是openwrt里面分出来，后面又重新与openwrt合并,而github上面的lede是lean(作者)基于最后的lede源代码的个人维护版本,也就是说基于的openwrt主线版本已经十分老旧了,这个系统的优点是有一些闭源驱动，性能非常强大,但由于已经和新版的openwrt代码相差很大，所以很多软件包已经不兼容了.

x-wrt:

基于openwrt的主线分支(不是release分支),所以代码更新速度很快,有自己的软件仓库，国内用户可以直连,相对于官方的系统，已经内置集成的一些功能

istoreos:

基于openwrt以前的分支,一般不会基于最新的主线分支，一般会隔一两个大版本,有自己的软件源，国内用户可直接连,主要就是ui和功能改动,openwrt官方系统或其他分支系统也可以安装istoreos的软件包来实现成istoreos的ui和功能.主打的是将路由器和nas结合，里面内置了很多跟nas有关的功能。

结论

综上所述目前软路由系统，我个人推荐openwrt系,openwrt系里面结合更新速度和软件包数量以及稳定性,lede基于的主线版本太老,istoreos更新上游的速度较慢,kwrt魔改openwrt有点多(不是基于源代码魔改),稳定性较差.x-wrt特色不是很强,所以我个人综合起来更推荐immortalwrt

方案分析 | 我对几种LLM扩展工具的区别与使用心得

Mon, 02 Feb 2026 00:00:00 +0000

关于LLM的几种工具扩展方法的区别和见解

LLM本身只能当做聊天对话机器,他只可以接收对话，然后返回回答,本身是不能干任何额外的事情.

我们使用ai的一些扩展功能，比如联网搜索和其他的工具本质上是让AI返回指定参数,交由外部工具去完成,然后在拿外部工具执行到的信息作为上下文,再返回给AI,llm只是决策者而并非执行者,工具真正的逻辑执行部分和判断部分需要人为的完成.

而市面上主流的LLM主要有以下几种方法扩展工具

1.Tool Calls(很少使用)

这个是一些大语言模型本身自带的功能,可以让用户自定义一段工具介绍，然后让LLM在适当的时候返回工具调用的结构体,然后由用户解析结构体执行程序之后，再返回获取到的结果来完善上下文

缺点: LLM和工具的衔接部分需要自己人为书写,比如需要判断LLM有没有返回工具调用信息,如果返回了，要根据返回的信息进行选择调用,写的工具越复杂，衔接部分需要花费的时间就越大,并且不同的模型的Tool Calls返回的信息可能还有所不同，不同模型的Tool Calls标准不一样，同一个工具需要对不同的模型单独做适配,所以并不流行(不过算是最早的给llm扩展工具的方法)

2.Mcp(流行)

这是一套严格的标准,不会像Tool Calls一样可能因为模型的问题，返回的结构体有所差异,有mcp客户端,还有mcp服务器,工具的连接方式有远程，也有本地调用,是一套很完善的规则.

缺点: 因为调用流程过于严谨和繁琐,所以很容易引起llm上下文直接爆炸,让llm抓不到重点,对话越到后面效果越差。部署和开发也相对麻烦,因为有服务端，客户端，还有一些七七八八.而Tool Calls,可以直接在一个片段代码里面完成开发.

3.Skills(流行)

这个是最近claude推出,我对他的理解是最高级别的prompt,这个严格来说并不是一个标准,而是共识,更偏向于一个技术理念,需要IDE自己去实现这个理念（Claude开源了他们官方skills的实现）,不像mcp和Tool Calls是有一定的标准的,要严格按照官方的标准来。

Skills某种程度上来说和Tool Calls有点类似,但是他不需要写LLM和工具之间的桥接代码,并且还可以完成一些prompt才可以做的事，比如说自定义一下语气和注意事项.

Tool Calls每写一个工具，我需要自己再写程序去判断LLM返回的工具调用信息，然后再去执行运算(并且还可能因为不同的模型返回的信息有差异而导致兼容性问题),而放到Skills,我只需要自定义一段话,不需要写具体的代码(工具本身是要写代码的，只是调用不需要写代码),比如在特定的时候执行某个文件目录下面的某个代码片段传入某些参数,相当于把桥接部分交由了程序本身(如Vscode和windsurf)去执行,所以说需要程序去适配Skills,它是共识和理念，而不是一套标准.(不过当流行起来的时候，共识理念最终也会成为大家默认的标准)

总结

总结:以上三种给LLM扩展工具的方式,我个人对未来最看好的是Skills,我认为把这套逻辑和共识再进行优化加强是完全可以比过Tool Calls和mcp。Tool Calls桥接部分比较麻烦,一切运转都要依靠代码,还有兼容性问题;mcp开发部署繁琐,且容易引起上下文爆炸,LLM运行缓慢.Skills恰好能解决这两者的缺点

方案分析 | Android Root 的演进与抉择

Tue, 09 Dec 2025 00:00:00 +0000

Android Root 发展历程和方案分析

Android Root 顾名思义即给安卓系统获取根权限，让用户拥有系统级权限，极大提升系统可玩性。
一般来说，Root 需要先解锁 bootloader（BL），解锁的目的，是让用户有权限刷写各个分区，从而能：

更换系统（system / vendor / product 等）
更换内核（boot ）
注入 Root / 模块方案

注意：解锁 BL ≠ 必然 Root，也可以只刷机不 Root。
主流 Root 方案按时间大致可以排成这样：

KingRoot → SuperSU → Magisk → SKRoot（小众） → KernelSU → APatch

一、Root 实现思路：按技术路线分类

用户态 Root（User-space Root）

不直接修改内核代码
修改 boot.img → ramdisk → init 脚本，在早期启动阶段插入自己的用户态 root 程序
通过 用户态守护进程 管理权限（例如 magiskd）
一般依赖一个 管理 App 配合使用（授权弹窗、模块管理等）
代表方案：Magisk
优点：对内核无强依赖，兼容面最广
缺点：本质不在内核，某些内核安全策略/厂商定制下会有局限

内核态 Root（Kernel-space Root）

直接在内核中 Hook 权限相关函数 / LSM / syscall
在内核层修改 cred、capabilities 等结构，获得最高权限
部分方案需要内核源码（早期 KernelSU），部分不需要（APatch、SKRoot）
代表方案：KernelSU、APatch、SKRoot
优点：权限层级最高，可做更“隐蔽”和细粒度的控制
缺点：与内核版本/厂商定制强相关，适配成本较高

漏洞 Root（Exploit-based Root）

利用系统或内核漏洞临时/半永久获取 Root
通常依赖特定 Android / 内核版本，系统一更新就失效
代表方案：KingRoot 等一键 Root 工具
优点：用户体验简单，历史上对锁 BL 的机器也有机会
缺点：完全吃漏洞红利，维护性差，安全风险高

二、按时间线看典型方案

KingRoot：漏洞驱动的早期 Root

主要活跃在 Android 4.4 ~ 6.0 时代
通过 内核 / 系统漏洞（如提权漏洞）获得 Root
多为 临时或半永久 Root，重启或 OTA 后经常失效
随着漏洞不断被修复，这类方案很快被淘汰

定位：
完全基于漏洞的时代产物，如今更多是历史意义。

SuperSU：system 分区注入 su 的经典方案

思路：直接修改 system.img，在 /system/bin 或 /system/xbin 注入 su 二进制
通过 su 的 setuid 机制实现提权
典型适用 Android 4.x ~ 6.x，system 还比较“好改”的时代
随着：
- system 分区逐渐只读 / 受更严格完整性保护
- Magisk 引入 systemless Root

SuperSU 很快失去优势。

定位：
传统“改 system.img 注入 su”的代表

Magisk：用户态 systemless Root 的时代

Magisk 把 Root 方式拉到了一个新高度。

核心实现

修改 boot.img → ramdisk → init：
- 用 magiskinit 接管早期启动，作为“第一个用户态进程”
- 启动 root 守护进程 magiskd
/system/bin/su 在 Magisk 中 只是前端/中转：
- 解析参数 → 连接 magiskd → 由 magiskd 以 root fork/exec 真正的命令
- 提权的决策和执行在 magiskd 中完成，而不是在 su 本身
不在 system 分区直接写入文件，做到 systemless
（实际上是用挂载/覆盖的方式“虚拟出”修改过的系统视图）

关键特点

首创 magic mount 模块系统：
- 在不实际修改系统文件的情况下，实现对 /system、/vendor 等目录的文件覆盖
- 极大提升“玩机模块生态”
强兼容性：
- 只要能改 boot.img中的init脚本，大多数内核版本都能使用
依赖管理 App（Magisk App）：
- 管理模块、处理 su 授权弹窗、升级/卸载

局限

纯用户态方案，需要搭配app
模块生态与内核态模块（如 APatch 的 KPM ）相比，在内核能力利用上略逊一筹
不支持kernelsu后来的模块webui功能,需要额外安装app解决

SKRoot：早期“内核 Root + su 环境注入”的探索者

时间上早于目前主流内核 Root（KernelSU / APatch）
无需内核源码：
- 离线分析目标内核镜像（ELF/镜像格式）
- 找到如 do_execve 等关键函数与 task_struct/cred/seccomp 的偏移
- 插入自定义 shellcode 实现内核级提权
号称“隐藏性很强”：
- 没有模块系统
- 常见用法是：针对单个或少数进程注入 su 环境
- 通过 PATH / so 寄生等方式，让特定 APP 获得 su，而不是全局暴露
适配范围：大致 3.10 ~ 6.6 内核

优点：

不依赖内核源码，适配范围相对广
su 环境可以“定向注入”，对其他进程很隐蔽

缺点：

没有完整的模块系统，操作较繁琐
生态小众，文档和社区支持相对较弱

KernelSU：主流内核态 Root + overlayfs 模块

基本定位

代表性的 内核态 Root：
- 在内核中安装 hook（LSM / cred 修改等）
- 在执行 /system/bin/su 时，内核直接修改进程 cred 实现提权
/system/bin/su 在 KernelSU 中是真正的 提权入口：
- 它触发内核 hook
- 提权是在内核里完成的，而不是转发给某个守护进程（区别于 Magisk）

技术路径演进

早期：通过 谷歌GKI 内核（已被官方淘汰） / 内核源码集成（已被官方淘汰） 集成 KernelSU
现在主流：LKM（ko 模块）方式：
- 把修改封装成内核模块加载进 GKI 内核
- 同一大版本Gki内核编译出来的ko模块具有一定通用性,所以安装体验上不需要内核源代码
- 但 ko 的编译仍依赖内核的源码，只是这部分由项目方/维护者完成
- 对用户体验来说“不需要自己改源码”

模块系统：元模块（支持overlyfs/magic mount或者自定义挂载方式）

默认使用 overlayfs 实现模块系统(首创)：
- 支持对 /system 等只读分区做“上层覆盖”(模块安装后通常需要 重启才能生效对/system的修改)
对比 Magisk 的 magic mount：
- overlayfs 是内核特性，语义更标准
- 但实时性稍差，多数变更需要重启

特点与限制

特点：
1. 内核态 su：安全模型清晰，可做细粒度 App profile（按 UID/GID 控制权限大小）
2. 官方overlayfs 模块系统：结构正规，可与 GKI 思路统一
限制：
- 对低版本 / 非 GKI 内核兼容性差
- 一些魔改了内核且不开源的gki设备对谷歌官方gki内核支持差,刷了可能开不了机
- 官方更推荐搭配 5.10以上的 GKI 内核搭配ko模块使用

APatch：无需源码的 kpimg 内核 Root + KPM 模块

在内核 Root 方案中，APatch 的技术路线是目前最“工程化 + 通用”的一类。

核心实现方式

仍然是 内核态 Root，但：
- 不需要内核源码
- 使用 KernelPatch 工具链解析并 patch 目标内核镜像
通过在内核镜像中注入 kpimg：
- 修改内核启动入口 / early init 流程
- 把自定义 hook 注入到内核的启动过程
- 重启后，kpimg 会在早期阶段接管部分逻辑，实现：
  - Root 提权
  - 内核 hook（supercall / inline hook）
  - 启动用户态守护/事件（apd 等）

兼容性

内核版本范围广：3.18 ~ 6.12
不依赖 GKI，不要求厂商公开内核源码
对各家定制内核更友好（因为是直接对内核二进制镜像做符号分析与 patch）

特点

KPM 内核模块：
- 在已经被 kpimg 接管的内核里，动态加载 KPM 模块
- 支持对内核函数进行 hook，部分 hook 即时生效
- 无/system/bin/su文件，通过监听拦截/system/bin/su或su指令来实现提权
模块系统 + Lua 脚本：
- 用户态 apd 管理模块目录、事件（post-fs-data / boot-completed 等）
- 最新版本中可以用 Lua 替代传统 shell 脚本，增强复杂逻辑可维护性
不依赖内核源码的工程化链路：
- 用 tools/kallsym.c、tools/patch.c 等做符号解析、patch
- 用 kernel/patch/android/user_init.sh 等把 apd 接到系统启动阶段
支持kernelsu的元模块挂载方案(2026.1.12补)

三、综合对比与结论

技术路线对比（简表）

方案	类型	是否改内核代码	是否需源码	是否依赖 App	su 角色	模块系统
KingRoot	漏洞 Root	否	否	需要	各家自定义	无 / 简单补丁
SuperSU	system 注入 su	否	否	可选	传统 setuid su	无
Magisk	用户态 Root	间接（不改内核）	否	强依赖	`/system/bin/su`中转到 `magiskd`	magic mount
SKRoot	内核 Root	是（patch 镜像）	否	有工具/库	隐藏 su + 进程定向注入	无完整模块系统
KernelSU	内核 Root	是（源码/GKI/LKM）	技术层面上需要	App 非必须	`/system/bin/su` 触发内核提权	元模块
APatch	内核 Root	是（kpimg patch）	否	App 非必须	内核 hook su/execve 等	APM/KPM + Lua

目前最主流的三款root方案分析

Magisk：
适合追求 广泛兼容 + 成熟模块生态 的用户，一般设备能解锁 boot.img 就能用。
KernelSU：
适合有 GKI 内核，且希望在内核层面细控 Root 权限（App profile）的人，
更偏“官方化”的内核模块方案，但对旧机型支持有限可以自定义挂载
APatch：
从技术理念上最“硬核”，不依赖源码、支持广泛内核版本，
内核模块 hook + Lua 模块系统，对研究者 / 高级玩家非常友好。

方案分析 | 如何选择最适合你的 AI IDE 与扩展插件

Mon, 08 Dec 2025 00:00:00 +0000

AI IDE 工具推荐

为什么使用 AI IDE？

传统 AI 聊天无法：
- 实时读取本地文件
- 兼顾项目的宏观框架管理
偏商业化的 AI IDE：
- 一般不允许自定义第三方服务商接口
- 强制使用平台模型收取订阅费
- 实时读取本地文件
- 适配开发的执行流程与逻辑

因此，为了高效开发和项目管理，需要使用 AI IDE。

AI IDE 的能力评价指标

硬实力：自带模型能力
软实力：上下文补全与逻辑能力
- 通过插件、执行策略、隐藏的上下文prompt 等实现

两者缺一不可

AI 编程工具分类

1. CLI 命令行AI开发工具

开发效率比 IDE 差
- 文件引用需手动输入
不适合宏观项目管理
适合单一功能的改进
代表工具：
- OpenAI Codex★★★(也有vscode 插件版本,但开发效率不如集成式ai ide,仍然是片段式更改)
- Claude Code★★★(也有vscode 插件版本,但开发效率不如集成式ai ide,仍然是片段式更改)
- OpenCode（开源）（可自定义服务商接口，但上下文能力较弱）

2. IDE AI 开发工具

直接从文件管理器拖入文件即可
支持项目级宏观管理

国内 AI IDE

Trae
- 特有 Solo 模式（和普通模式感觉主要是 UI 差别，在功能上感觉差的不是很大，可能隐藏 prompt 有所优化）
- 可使用规定的国内其他服务商接口
Qoder
- 无特色
- 上下文消耗快
- 无法使用国外模型或其他接口
通义灵码
- 无特色
- 无法使用国外模型或其他接口

国内 IDE 的共性

喜欢构建工作区文件全量索引，每次提问前先查索引文件，消耗大量上下文 token，有时查找的文件过多反而忽略关键问题
国内模型编码能力较弱，且不允许使用国外更强的模型
方便支付订阅, 界面中文支持较好

国外 AI IDE

GitHub Copilot★★
- VSCode 插件形式
- 适合片段式的文件
- 上下文补全能力较弱
- 无法全面定制化
Cline★★（开源）
- 可自定义任意服务商
- VSCode 插件形式
- 适合片段式的文件
- 上下文补全能力较弱
- 无法全面定制化
Kilo（开源）
- 可使用规定的第三方服务商api
- VSCode 插件形式
- 适合片段式的文件
- 上下文补全能力较弱
- 无法全面定制化
Cursor★★★
- 基于 VSCode 深度定制
- 自研模型 Composer 1 (专为编程训练, 功能强大)
- 可使用规定的其他服务商 API
- agent可以直接连接github远程储存库(特色功能)
- 预设 Prompt 优秀输出质量高，但免费额度少，订阅贵
- 亮眼功能：
  - 浏览器设计模式：可以直接在ide里面打开网页，并且选择元素，方便设计网页
  - debug：可以根据log寻找隐藏bug
kiro 电脑安装闪退，我用不了(哭)
Windsurf★★★
- 基于 VSCode 深度定制
- 自研模型 SWE-1.5 (专为编程训练, 功能强大)
- 亮眼功能：
  - Memories：可以根据对话和习惯生成对应的记忆（ai自动生成记忆，以在对话之间保持上下文连贯性）
  - DeepWiki：独家功能,定位项目中关键函数或变量，了解用途和在项目其他地方引用 (方便学习他人的开源项目)
  - CodeMap：独家功能,用于分析现有项目代码结构,可以根据输入的问题生成项目代码实现的流程图,点击流程图可以定位对应代码实现的部分（对于解剖他人项目的功能实现很有用）
  - 浏览器设计模式：可以直接在ide里面打开网页，并且选择元素，方便设计网页
  - 对话消息互通：独家功能,不同对话之间可以选择互通消息，如两个不同的项目,具有一定的关联性，我们就可以通过这个功能实现两个项目在对话层面上的互通，而不需要ai去研究另外一个项目的代码，防止添加过多的内容，导致上下文混乱
- 免费额度高，价格便宜
- 支持规定的其他服务商 API
Zen Editor（开源）
- 可使用任意服务商接口
- 自带免费额度高
- 上下文补全能力较弱

总结推荐

综合价格、模型能力和上下文补全能力，我个人首推 Windsurf
DeepWiki、CodeMap 和消息互通是其最大亮点，让其上下文补全能力非常强大
其他 AI IDE 在 UI 功能上同质化严重，差别主要在 AI 模型、执行逻辑和预设 Prompt
如果不考虑开发效率，单论编码能力,openai的codex和claude code这种命令行式开发可能是最强的一批,其次就是cursor和windsurf

方案分析 | 代理工具的选择

Wed, 03 Dec 2025 00:00:00 +0000

主流代理核心简介（代理核心 + 前端 UI）

所有代理工具本质上都是 代理核心 + 前端图形界面（UI） 组成。
前端 UI 可以千变万化，但真正承担流量处理的 代理核心只有少数几种。

以下是目前主流、最常见的核心介绍。

Clash(更新停滞)

Clash 是一个最初由 Go 编写的多协议代理核心（原项目已删除）。
使用广泛，生态庞大。

特点：

使用统一的 YAML 配置，无需因平台不同而修改
GUI 客户端数量最多、生态最大
跨平台兼容性极强

缺点：

原项目已停止维护
新协议支持较慢（如 Reality、Hysteria2 等）

Mihomo（Clash Meta）★★★

MetaCubeX 社区维护的 Clash 增强版，也是目前最主流的 Clash 继承者。

特点：

完全兼容 Clash 配置
支持现代协议（Reality、Hysteria2、TUIC 等）
活跃维护，性能更高

Sing-Box（sb）★★

由 SagerNet 开发的现代化代理核心，目前增长最快、架构最先进。

特点：

极度轻量，理论性能高
高度可定制的网络与路由配置
支持大量现代协议
跨平台优秀

缺点：

配置难度高，对新手不友好
GUI 生态较少

V2Ray(更新缓慢)

由 v2fly 社区维护的原始 V2Ray 核心。

特点：

配置灵活
结构成熟
较为轻量

缺点：

开发速度慢
新协议支持不佳
配置复杂
GUI 生态弱

Xray

V2Ray 的增强版核心，由 XTLS 项目维护。

特点：

完全兼容 V2Ray 配置
支持 Reality
支持 XTLS，性能大幅提升
性能明显高于官方 V2Ray

缺点：

配置复杂
GUI 生态较弱

dae

基于 eBPF 的 Linux / 路由器高性能代理引擎，更像“下一代分流框架”。

特点：

基于 eBPF，性能极高
几乎不占 CPU
延迟极低
路由分流能力极强

缺点：

仅支持 Linux / OpenWRT
配置复杂
GUI少

各操作系统主流GUI代理客户端(整体按照知名度排序)

Windows

v2rayN★★ — 支持 Xray / sing-box / clash/others 内核,支持Windows/Linux/macOS
Clash Verge Rev★★ — 内置 Mihomo内核,支持 Linux/macOS/Windows
Mihomo Party★★★(推荐) - 支持linux/windows/macos
Karing — 基于 sing-box 内核,支持Android/ios/linux/windows/macos
Sparkle★★ — 基于 Mihomo 内核，支持 Windows / macOS / Linux
Clash Mi —支持android/ios/Windows / macOS / Linux
FlClash — 基于 Mihomo 内核,支持Android/linux/windows、macos
GUI.for.Clash — Windows / macOS / Linux
Pandora-Box — 基于 Mihomo 内核,支持linux/windows/macos

macOS

Surge★★★ — 付费高级客户端,支持ios/macos
Quantumult X★★★ — 付费,支持ios/macos
Loon — 付费,支持ios/macos
v2rayN — 支持 Xray / sing-box / clash/others 内核,支持Windows/Linux/macOS
Clash Verge Rev — 内置 Mihomo 内核,支持 Linux/macOS/Windows
Mihomo Party - 支持linux/windows/macos
Karing — 基于 sing-box 内核,支持Android/ios/linux/windows/macos
Sparkle — 基于 Mihomo 内核，支持 Windows / macOS / Linux
FlClash — 基于 Mihomo 内核,支持Android/linux/windows、macos
Clash Mi —支持android/ios/Windows / macOS / Linux
GUI.for.Clash — Windows / macOS / Linux
Stash★★ — 基于 sing-box（付费）
Pandora-Box — 基于 Mihomo 内核,支持linux/windows/macos

Linux

v2rayN★★ — 支持 Xray / sing-box / clash/others 内核,支持Windows/Linux/macOS
Clash Verge Rev★★ — 内置 Mihomo 内核,支持 Linux/macOS/Windows
Mihomo Party★★★ - 支持linux/windows/macos
Karing — 基于 sing-box 内核,支持Android/ios/linux/windows/macos
Sparkle — 基于 Mihomo 内核，支持 Windows / macOS / Linux
FlClash — 基于 Mihomo 内核,支持Android/linux/windows、macos
Clash Mi —支持android/ios/Windows / macOS / Linux
GUI.for.Clash — 支持 Linux/macOS/Windows
Pandora-Box — 基于 Mihomo 内核,支持linux/windows/macos

Android

Clash Meta for Android★★★(推荐)
Karing — 基于 sing-box 内核,支持Android/ios/linux/windows/macos
Clash Mi —支持android/ios/Windows / macOS / Linux
FlClash★★ — 基于 Mihomo 内核,支持Android/linux/windows、macos

iOS

Surge★★★ — 付费高级客户端,支持ios/macos
Shadowrocket★★★ — 付费,支持多协议
Quantumult X★★★ — 付费,支持ios/macos
Loon — 付费,支持ios/macos
Karing — 基于 sing-box 内核,支持Android/ios/linux/windows/macos
Clash Mi —支持android/ios/Windows / macOS / Linux

HarmonyOS NEXT

ClashBox — 独苗这一块

路由器（OpenWRT / Linux）

OpenClash★★ - OpenWRT 上主流的 Clash 客户端
OpenWrt-nikki★★★(推荐) — 基于clash核心
daed — 基于dae内核
Passwall2
openwrt-nekobox — 基于 Sing-box核心

总结

小白无脑选择clash系客户端，有其他要求可自定义选择。

方案分析 | 博客框架的选择

Tue, 02 Dec 2025 00:00:00 +0000

博客框架我们应该如何选择？

博客大体上可以分为静态博客和动态博客。

动态博客采用的是前端+后端的模式,而静态博客就是纯前端静态文件（方便托管）

动态博客的优缺点:

优点:

适合大型博客或者论坛
自带后台管理评论
功能集成很多，适合小白，基本不需要额外去弄什么

缺点:

资源占用大
必须依赖服务器运行，不可使用静态host主机/serverless服务提供商(cloudflare/vercle/github pages)
网站加载速度相对较慢
有一定的运维成本(服务器/防火墙等费用)

静态博客的优缺点:

优点:

加载速度相对较快
资源占用少。
可以将网站交给serverless服务商托管（白嫖党狂喜，不需要专门的服务器）

缺点:

要有一定的web技术功底，会手动改配置文件、布局,写文章模板
框架集成的功能较少，如评论功能，音频播放器，需要自行对接第三方接口（不过很多静态博客主题里面已经把功能模板写好了，只需要更换接口地址就行）
缺乏统一的后台管理功能

动态博客框架

WordPress★★★

  世界知名动态博客框架，主题资源插件丰富，教程多。

Typecho

 轻量级动态博客框架，主打一个快速部署，快速上线

Halo★★

 界面很漂亮，资源插件相对来说比较丰富，社区正在逐步发展，安装部署方法较为麻烦，比较吃服务器性能

静态博客框架

Hexo★★★

 node.js开发,教程很多，社区插件主题资源丰富，缺点是当文章数量>1k时，构建速度会显著减缓

Hugo★★★

 go语言开发,使用go template模板，学习门槛相对其他的来说高点。运行build效率很高,支持热加载,更改不需要刷新网页页面即可生效。教程资源丰富,社区插件资源也很多，稍逊hexo,最大的优势是当文章数量很多时，构建静态网站的速度可以快其他框架几倍.

Jekyll★★

 资源插件相对较少,界面简洁直观,但有github官方支持,可以直接将存入仓库的md文件转换成网页

VitePress

 资源插件丰富，可扩性强,常用于构建文档，不用于博客

Astro★★

新一代静态框架,0 javascript的技术理念让网站首页加载起来非常快,采用服务端渲染的技术理念
可局部初始化组件为spa,增强网站运行效率,可搭配其他前端框架组件使用，但主题资源相对较少。

总结

对于零基础的小白，想搭建博客，首先推荐动态博客框架，首选wordpress,有一定技术基础，搭建自己个人的轻量博客推荐静态框架,首选hexo/hugo,想要更快的构建速度和热加载，选择hugo.如果想尝试更先进的技术理念和更快的首页加载速度，可以尝试astro

杂谈

本站采用hugo构建,github仓库储存,cloudflare远程克隆部署,评论功能对接waline。