下载所需文件#

设置虚拟机#

1. 打开下载的 .utm 包
2. LineageOS 虚拟机设置 - Network - Network Mode - 选择 Shared Nework

调整虚拟机存储#

1. 虚拟机默认的 16GiB 内部存储肯定不够用 所以在第一次开机前建议更改虚拟机内部存储大小 不然后期想要调整需要恢复出厂设置

Caution

分配前注意看磁盘名称 一定一定要 Resize vdb-2.qcow2 这个虚拟磁盘文件 这是 userdata 分区的盘

另一个 vda-2.qcow2 是 system 分区 随意调整此分区大小可能会导致不可预知的问题

Note

Android 16 最大支持 16TiB 的磁盘 再高会 bootloop 但是不建议分配 16TiB 会导致 QEMU 模拟不正确 有概率导致虚拟机卡死

调整 CPU 与内存#

1. 接着来调整虚拟机内存大小和 CPU 核心数量

Note

CPU 核心数量建议根据自己电脑的配置拉满 RAM 大小则建议 ≥ 6GiB QEMU 不会直接吃掉你分配的所有的 CPU 核心和内存 它会根据虚拟机占用动态调整

Force Multicore 功能可选择性开启（就我感觉 开不开其实差不多）

配置 Bootloader#

1. 先别急着进系统 进入 Bootloader 以后先进入设置 进行一些设置 以方便联网调试和 root

Note

Bootloader 里面的每项设置功能简介

A/B boot control

A/B 分区功能开关 此设置完全无法使用 因为此虚拟机完全不支持 A/B 分区😅

Boot animation

开机动画 默认开启 自选是否打开

Dispiay resolution

调整显示分辨率 系统内无法调这个 建议先默认 后面折腾好了再改 不然不方便切换窗口

HWUI renderer

SystemUI 渲染器 不建议调 可能会导致 SystemUI 黑屏

Insecure ADB

是否允许不安全的 ADB 调试 也就是是否允许开放在 5555 端口的 adb 无线调试 必开 不然无法连接到 adb 调试

Low performance optimizations

低性能优化 默认关闭 如果你的 Mac 是 Apple Sillicon 则保持默认 不用开 如果是 Intel 芯片用户则视情况开 大部分情况下你不需要开这个 保持默认即可

Mitigations

保持默认即可

Quiet boot

安静启动 即在启动时不显示内核日志 默认关闭 自选是否开启 开启后系统开机将不显示内核日志

Screen density

调整系统 DPI 也是系统内无法调的选项 这个也需要根据你 Mac 的屏幕分辨率 问 AI 选什么 DPI 合适 如果是 1080P 屏幕 那么默认即可

Serial console function

开启或关闭虚拟机的串口控制台功能 如果没有特殊的安卓开发需求 保持默认即可

SELinux

设置 SELinux 状态 默认 Enforcing（强制模式） 如果你要 root 的话（特别是用 KernelSU root 的话） 必须改成 Permissive（宽容模式） 否则打开开发者模式设置会闪退

Wi-Fi implementation

是否打开虚拟 Wi-Fi 功能 默认关闭 必须选择 VirtWifi using eth0 interface 否则无法打开无线调试 无法 adb

ZRAM

虚拟内存功能 默认关闭 建议打开

GRUB: timeout

GRUB 超时时间 GRUB 是引导器（bootloader） 也就是现在在的这个界面 这里调整 GRUB 超时时间 默认 3s 超时后自动进入系统 按上下键可中断倒计时 根据需要自己调

Show current setting

显示当前选择的选项

初始化 userdata 分区#

1. 如果你调过 userdata 分区大小的话 退出到主界面 选择 Recovery 并且进入

   接下来选择 Factory reset - Format data/factory reset

   选择 Format data 并且等待 等待时长由你磁盘大小决定

   Caution

   虽然虚拟机里大概率没有重要数据 但是还是提醒一下 这一步会清空你虚拟机里面的所有数据 有重要数据千万千万记得备份

   Tip

   ERROR: recovery: Failed to save locale to /cache/recovery/last_locale: No such file or directory 若 Rocovery 里报错这些是正常的 是因为没有初始化系统导致的

   当 UI 再次出现 下方显示 Data wipe complete. 就可以了

   正常完成后应该输出：

   1
   -- Wiping data...
   2
   Formatting /data...
   3
   Formatting /cache...
   4
   Formatting /metadata....
   5
   Resetting memtag message...
   6
   Data wipe complete.

[可选] 安装 Google Apps#

1. [可选] 安装 Google Apps

   Caution

   GApps 必须在第一次启动系统之前安装 否则会 bootloop 所以第一次启动系统前千万要斟酌一下 确保不会用到 GApps 再启动 不然后期再想装只能恢复出厂设置再安装

   Note

   因为虚拟机自带的 Recovery 有强制包签名校验 导致刷入开源没有签名的 GApps Add-on 会报错

   1
   ERROR: Recovery: Faiied to verffy whole-file signature.
   2
   Update package verification took 10.6 s （result 1）.
   3
   ERROR: recovery: Signature verification failed.
   4
   ERROR: recovery: Err： 21

   所以要刷入带 userdebug 标签的允许刷入未经签名的包的 Recovery

刷入 userdebug Recovery#

• 进入 Recovery 首页 - Advanced - Enter fastboot 进入 fastbootd 并记下上面的 IPv4 address - 192.168.**.*

• 进入到 Fastbootd 首页 记下上面的 IPv4 address - 192.168.**.*

• 接着打开终端

  1
   fastboot -s tcp:$HOST_IP flash recovery /path/to/recovery_arm64only-userdebug.img    # 把 $HOST_IP 替换成 Fastboot 里面给你的 IP /path/to/recovery_arm64only-userdebug.img 替换成你下载的 Recovery 镜像的位置

  • 输出应该类似这样：

  1
  Sending 'vendor_boot' (59492 KB)                   OKAY [  0.132s]
  2
  Writing 'vendor_boot'                              OKAY [  0.068s]
  3
  Finished. Total time: 0.251s

• Fastbootd 里选择 Power off 关机 重启再启动到 Recovery - Apply update - Apply from ADB - 再次记下上面的 `IPv4 address - 192.168.**.*

  Tip

  1
  ERROR: recovery： [libfs_mgr］ Failed to mount /mnt/vendor/shared: Invalid argument
  2
  ERROR: recovery： [libfs_mgr］ Failed to mount /mnt/vendor/shared: No such file or directory
  3
  ERROR: recovery： [libfs_mgr］ Failed to mount for path ［/mnt/vendor/shared］

  若 Rocovery 里报错这些也是正常的 还是因为没有初始化系统导致的

通过 ADB 侧载 GApps#

• 底下显示 Now send the package you want to apply to the device with "adb sideload <filename>"... 时打开终端

  1
   adb connect $HOST_IP    # 把 $HOST_IP 替换成 Recovery 里面给你的 IP

  • 输出应该类似这样：

  1
  * daemon not running; starting now at tcp:5037
  2
  * daemon started successfully
  3
  connected to 192.168.**.*:5555

  • 接下来用 adb devices 检查是否连接上：

  1
   adb devices
  2
  List of devices attached
  3
  192.168.**.*:5555       recovery

  • 显示如上则已连接上

  • 接下来开始侧载：

  1
  adb sideload -h /path/to/MindTheGapps-**.*.*-arm64-yyyymmdd_******.zip    # 把 /path/to/MindTheGapps-**.*.*-arm64-yyyymmdd_******.zip 替换成你下载的 GApps 包的位置

  • Recovery 里会提示

  1
  Signature verification failed
  2
  Install anyway?

  • 选 Yes
  Tip

  应当会输出

  1
  ERROR: recovery: Failed to find CPU thermal info in /sys/class/thermal/

  报错这个这是正常的 因为虚拟机的缘故

  1
  Supported API:3
  2
  Finding update package.
  3
  Verifying update package.

  1
  ERROR: recovery: failed to verify whole-file signature
  2
  Update package verification took 10.6 s （result 1）・
  3
  ERROR: recovery: Signature verification failed
  4
  ERROR: recovery: error: 21

  报错这个也是正常的 因为开源 GApps 没有包签名 只要在 Recovery 里提示

  1
  Signature verification failed
  2
  Install anyway?

  的时候选 Yes 即可继续

  1
  Installing update.
  2
  **********************
  3
  MindTheGapps installer
  4
  **********************

  正式开始安装

• 当 UI 再次出现 Recovery 日志提示

  1
  Cleaning up files
  2
  Unmounting partitions
  3
  Done!
  4
  
  5
  Install completed with status 0.

  即已完成

  选择 Reboot system now 进入系统

---

[可选] Root#

Root 部分使用 KernelSU，对应准备工作中的 boot.img 与 KernelSU Manager。

进入系统并开启 ADB#

1. bootloader 里选择第一项 LineageOS **.* 进系统
2. 第一次启动系统可能会比较慢 特别是你选择了装 GApps 的时候 具体时长与电脑性能有关

1. 简单过下 OOBE

   Tip

   带 GApps 的版本和不带的 OOBE 略有区别

   这是无 GApps 的版本：

   

1. 先连下 WiFi 再进设置 - 关于本机 - 狂点最下面的 Build 号 进入开发者模式

2. 设置 - 系统 - 开发者选项 - 无线调试 - 允许

1. 进入 无线调试 记下里面的 IP

1. 打开终端

1
 adb connect $HOST_IP    # 把 $HOST_IP 替换成 Recovery 里面给你的 IP

• 输出应该类似这样：

1
* daemon not running; starting now at tcp:5037
2
* daemon started successfully
3
connected to 192.168.**.*:5555

接下来用 adb devices 检查是否连接上：

1
 adb devices
2
List of devices attached
3
192.168.**.*:5555       recovery

• 显示如上则已连接上

安装并配置 KernelSU#

1. 安装 KernelSU Manager

1
 adb -e install /path/to/KernelSU_v*.*.*-**-g******ab_*****-release.apk    # 把 /path/to/KernelSU_v*.*.*-**-g******ab_*****-release.apk 换成你下载的管理器路径

• 输出应该类似这样：

1
Performing Streamed Install
2
Success

1. 推送 boot.img 到虚拟机并修补

1
 adb -e push /path/to/boot_*.img /sdcard    # 把 /path/to/boot_*.img 换成你下载的 boot.img 路径

• 输出应该类似这样：

1
/path/to/boot_*.img: 1 file pushed, 0 skipped. ** MB/s (46219264 bytes in 0.100s)

1. 打开 KernelSU 管理器 - 选择文件并修补 - 选择 boot.img - [可选]备份为原厂镜像&总是给 Shell 授予 Root 权限&启动时强制启用 ADB 调试 - 下一步 - KMI 选择见下

Tip

如何查看 KMI

见 KernelSU 官方文章

记住圈出来的路径

• 输出应该类似这样：

1
  _  __                    _ ____  _   _
2
 | |/ /___ _ __ _ __   ___| / ___|| | | |
3
 | ' // _ \ '__| '_ \ / _ \ \___ \| | | |
4
 | . \  __/ |  | | | |  __/ |___) | |_| |
5
 |_|\_\___|_|  |_| |_|\___|_|____/ \___/
6

7
- Bootdevice: /data/data/me.weishu.kernelsu/cache/boot.img
8
- Preparing assets
9
- Unpacking boot image
10
- KMI: android16-6.12
11
- Adding KernelSU LKM
12
- Backup stock boot image
13
- Stock image has been backup to
14
- /data/user_de/0/me.weishu.kernelsu/boot_backup/ksu_backup_*
15
- Adding allow shell config
16
- Adding adb_debug props
17
- Adding props to enable adbd
18
- Repacking boot image
19
- Output file is written to
20
- /storage/emulated/0/Download/kernelsu_patched_yyyymmdd_*.img     # ⬅️ 记住这行
21
- Done!

展开收起

刷入修补后的 boot.img#

1. 从虚拟机拉取修补好的 boot.img 并刷入

• 终端输入 adb -d pull /storage/emulated/0/Download/kernelsu_patched_yyyymmdd_*.img ./ # 把 /storage/emulated/0/Download/kernelsu_patched_yyyymmdd_*.img 换成你刚刚记的目录

• 重启虚拟机 - LineageOS **.* Recovery - Advamced - Enter fastboot 进入 Fastbootd

• fastboot -s $HOST_IP flash boot kernelsu_patched_yyyymmdd_*.img 直接刷入

  • 输出应该类似这样：

  1
  Sending 'boot' (45616 KB)                          OKAY [  0.127s]
  2
  Writing 'boot'                                     OKAY [  0.270s]
  3
  Finished. Total time: 0.546s

• 选择 Reboot system now 重启系统

如果你在开机日志里看到了 KernelSU: * 证明成功了

---

Enjoy!#

把搞好的 .utm 虚拟机包传到 iPad 上 用 UTM 导入即可在 iPad 上享受 Android Tablet 了（）

🪨 A Stone Badge & 不死图腾#

1
        🟫🟫🟫🟫🟫🟫
2
      🟫🟨🟨🟨🟨🟨🟨🟫
3
      🟫🟨🟨🟨🟨🟨🟨🟫
4
      🟫🟧🟧🟨🟨🟧🟧🟫
5
      🟫⬜🟩🟧🟧⬜️🟩🟫
6
      🟫🟩🟩🟨🟨🟩🟩🟫
7
      🟫🟧🟧🟨🟨🟧🟧🟫
8
🟫🟫🟫🟫🟫🟧🟨🟨🟧🟫🟫🟫🟫🟫
9
🟫🟨🟧🟫🟨🟨🟧🟧🟨🟧🟫🟧🟨🟫
10
🟫🟫🟫🟨🟨🟨🟨🟨🟧🟧🟫🟫🟫🟫
11
      🟫🟨🟧🟧🟧🟧🟨🟫
12
      🟫🟫🟫🟫🟫🟫🟫🟫
13
        🟫🟨🟧🟧🟧🟫
14
        🟫🟨🟧🟧🟨🟫
15
          🟫🟫🟫🟫

提问的艺术#

❎ 错误的提问方式 ❎#

Note

请不要这样提问 错误的提问方式将使开发者无法解答你的问题

xxx 怎么搞/激活啊

xxx 为什么不能用啊

Important

进群前请确保你有一定的玩机基础 不然将会使沟通成为一场灾难

✅ 正确的提问方式 ✅#

• 问题：xxx？

• 环境：

  1
  Root 方式
  2
  Magisk /KernelSU /Apatch
  3
  
  4
  微信版本
  5
  8.0.xx
  6
  
  7
  API 版本
  8
  100 及更低/101/102
  9
  
  10
  Xposed API 调用保护
  11
  未启用/已启用
  12
  
  13
  Dex 优化器包装
  14
  支持/不支持
  15
  
  16
  框架版本
  17
  xxx-it/irena/别的分支 (xxxx)
  18
  
  19
  管理器包名
  20
  com.android.shell/org.lsposed.manager
  21
  
  22
  系统版本
  23
  xx (API xx)
  24
  
  25
  设备
  26
  xxx
  27
  
  28
  系统架构
  29
  x86-64/arm64-v7a/v8a/v8a (4K)/risc-v

  展开收起

Tip

给新手的小提示

在 LSPosed 主界面长按即可复制设备信息

微信版本在 微信设置 ➡️ 关于 里看

记得补充你的 Root 方式和微信版本号

• 日志：xxx.zip

一些常见问题 (Q&A)#

安装、激活教程#

PART 1️⃣ LSPosed 的安装#

Important

此教程只针对 KernelSU 及其分支撰写 不保证 Magisk 以及 Apatch 用户跟随本教程一定能用上此模块

Step 1️⃣ 确保你的📱已经获取了 Root 权限#

Tip

如果你通过小米机型越狱的半残废 Root 或者魅族的官方半残废 Root 使用 LSPosed 则可以忽略上一条

Step 2️⃣ 下载 Zygisk 实现模块 ReZygisk 或者 ZygiskNext并刷入#

PerformanC

/

ReZygisk

Transparent implementation of Zygisk.

—

—

GPL-3.0

C

Dr-TSNG

/

ZygiskNext

Standalone implementation of Zygisk

—

—

no-license

C

Note

至于为什么有两个模块这件事么……是这样的： https://github.com/Dr-TSNG/ZygiskNext 一段时间前停止了开源 然后就有人搞了个开源的 https://github.com/PerformanC/ReZygisk 出来 从安全性的角度 本人更建议 https://github.com/PerformanC/ReZygisk 毕竟闭源的模块的安全性么……这就全看模块作者良心了 但是吧 https://github.com/PerformanC/ReZygisk 这模块也是刚刚出来的 稳定性这块还是差一点的（虽然本人目前用着也没发现大问题）所以你自己取舍吧

Step 3️⃣ 下载 并且刷入#

有两种方法下载 LSPosed:

1. 访问 lsposed.zip 直接下载
2. 如果无法访问 可加入 tg@lsposed 到群组内下载

Important

自 2024年4月26日 LSPosed 恢复更新起 LSPosed 不再开源并且进行内部测试制 并且不再分发于 Github 上 用户必须进入 https://t.me/LSPosed 群组 获取稳定版更新 而想要内测版用户则需要申请进入 LSPosed Internal Test 内测群组 详情见 ⬇️

在此加入 LSPosed 频道 ⬇️

LSPosed

内测群进群方式

• 🔗 在此 自己想办法解决吧

1
                                                echo aHR0cHM6Ly90Lm1lLytOZkh6dGZ5TkJaczJaRGxs | base64 -d

Important

WeKit 每次发版会发 legacy 版本和 standard 版本（也就是 api101 版本） 强烈建议你根据上面的教程更新 LSPosed 至 API102 以防止出一些奇奇怪怪的问题

Tip

给新手的小提示 你可以在 LSPosed 主界面查看 LSPosed API 及 LSPosed 版本

Tip

给新手的小提示： 你可以从 LSPosed 的压缩包里提取出 manager.apk 并安装 这样你的 LSPosed 就不再寄生在 Shell 里了 可以常驻在后台

PART 2️⃣ WeKit 的安装与激活#

Step 1️⃣ 获取最新版 Wekit#

方法 1️⃣ 加入 Wekit Telegram 超级群组 获取最新版 Wekit#

点击加入 Telegram 超级群组

方法 2️⃣ 到 Github Action 下载最新版 Wekit#

1. 点此进入 Github Action

2. 把浏览器 UA 调整成 PC

Note

也就是什么 电脑模式 桌面模式 之类的模式

1. 找到最新 master 分支的 Action Runner 戳进去

• 

1. 页面滑到底 戳 wekit-apk 旁边的下载按钮

2. 

Step 2️⃣ 安装 WeKit 并在 LSPosed 里激活 WeKit#

1. 安装

1. LSPosed 主页 ➡️ 模块 ➡️ WeKit（可能在下面）

2. WeKit ➡️ 启用模块 ➡️ 勾选微信 ➡️ 长按微信 ➡️ 强行停止 ➡️ 确认 ➡️ 启动

3. 打开微信 ➡️ 我的 ➡️ 设置 ➡️ WeKit ➡️ Enjoy!

---

About us#

** WeKit 是一个功能丰富的微信 Xposed 模块，提供大量微信增强功能，涵盖聊天体验、界面美化、隐私保护、自动化等多个方面。 **

特色功能#

• 基于 JavaScript 和 WAuxiliary Jvav 的脚本引擎
• 贴纸包同步 (Telegram Stickers Sync)
• 通知进化 (MessagingStyle)
• Markdown 消息渲染
• 指纹支付 (基于 TEE 的安全加密)
• 自动抢红包
• 单向删除好友检测
• 发送 SILK/MP3 语音
• 聊天工具栏
• 发送卡片消息
• 原生 Hook
• 支持免 Root 框架

致谢#

WeKit 上游

WAuxiliary

NewMiko

QAuxiliary

FingerprintPay

WADN WAD

零、前言#

每次我写这种文章，总会有人跳出来说：“bro 你又偏激了！”、“Windows 现在已经很好了！”、“WSL 启动！”。

现在是 2026 年，不是 2006 年，也非 2016 年。二十多年过去了，Windows 在严肃的程序开发这件事上，依然是一个彻头彻尾的笑话。不是因为微软不努力，而是因为它的根是烂的。把一棵树的树根泡在福尔马林里，树冠上挂再多 LED 灯也没用。

2026 年，曾经被认为是 精神病人 的 macOS 游戏玩家已经可以玩不少 3A 大作。那个 “Linux 不能玩游戏” 的 Linux —— 已经成为最适合玩游戏的操作系统。Steam Deck 卖了几百万台，Wine / Proton 让 Windows 游戏在 Linux 上跑得比在 Windows 上还快。

游戏，这个 Windows 曾经唯一的护城河，几乎被攻破了。

而 Windows 呢？它连 “用来开发” 这件事都做不好。

一个用来在星巴克剪视频的操作系统现在更适合开发，一个用来开发的操作系统现在更适合玩游戏。世界颠倒了，但 Windows 还是那个 Windows，至死不渝。

你的合作者用 Linux 和 macOS，你用 Windows —— 恭喜你，自动成为了团队里的 “那个麻烦”。

一、路径分隔符#

在 Linux 和 macOS 上，路径是 /home/JH/project/src/main.c。在 Windows 上，路径是 C:\Users\JH\project\src\main.c。

就是这个字符，让你的人生比其他人多出 33% 的烦恼。你在代码里写 path.join("build", "output")，在 Python 里用 os.path.join，在 C++ 里用 std::filesystem::path::preferred_separator —— 你觉得你处理好了。不，你没有。

总会有某个库、某个脚本、某个第三方工具 硬编码 了 "/" 或者 "\\"。写 path/to/file 在 Windows 上可能侥幸能跑，但把路径传给 cmd.exe 的时候，不认。传给 cl.exe 的 /I 参数的时候，偶尔不认。传给某个用 CreateFileA 的古老工具时，绝对不认。

更糟糕的是，你的 Linux 队友写了个 CMake 脚本：

1
set(OUTPUT_DIR "build/${CONFIG}/obj")

你高高兴兴拉到 Windows 上一跑，CMake 把它变成了 build\Debug\obj。看起来没问题？等你把这个路径传给一个用 Python 的 pathlib 生成的东西，再传给一个用纯字符串拼接的东西，再经过三层脚本 —— 恭喜，你得到了 build\\Debug\\obj 和 build/Debug/obj 混在一起的奇观。构建系统开始报“找不到文件”，你花两个小时发现是某个 shell 脚本里有一行 sed 's/\//\\/g' 写错了。

你的 Linux 队友不用想这些。你的 macOS 队友也不用想这些。只有你。

你用 Nushell 或者 PowerShell Core？Nushell 是结构化 Shell，它懂表格，懂数据流，但它不懂为什么 Windows 的世界里到处都是反斜杠。启动是快了，试试在里面执行一个 Windows 原生命令，返回一个路径 —— 给的是 C:\Users\JH\project。你要把这个路径传给下一个命令，下一个命令期望的是 C:/Users/JH/project。或者反过来。你可以在脚本里用 str replace 把 \ 换成 /，但你每写一个 pipeline 都要做一次。你的脚本变得又臭又长。

你的 Linux 队友，打开终端，瞬间。输入命令，路径永远是 / 分隔，永远不会错。他们不知道你在经历什么。

二、cl.exe 和 MSVC 构建工具：活在 1995 年的编译器#

有人说 “Windows 上可以用 clang 啊”。可以，当然可以。但用 clang for Windows，你链接的是什么库？还是 MSVC 的运行时库。避无可避。

MSVC 的问题不在于它不符合标准（虽然它曾经很烂，现在依然有一些角落烂着），而在于它的 工作流。

在 Linux 上写 gcc main.c -o main，完事。在 macOS 上写 clang main.c -o main，完事。在 Windows 上？

首先，你得找到 cl.exe。它不在 PATH 里。你得打开 “Developer Command Prompt”，或者运行 vcvarsall.bat。这个脚本干了什么？设置了二十几个环境变量，修改了 LIB 和 INCLUDE 路径，还把一堆莫名其妙的东西塞进 PATH。

想自己配？那你告诉我，cl.exe 需要的 mspdbcore.dll 在哪？vcruntime.h 在哪？kernel32.lib 在哪？你不知道。我也不完全知道。微软自己把它藏在一个每六个月变一次路径的目录里：C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.44.35207\bin\Hostx64\x64。你感受一下。

然后你说 “我用 CMake”。好，CMake 能帮你找到这些东西。但 CMake 自己也要先知道用哪个 generator。你用 -G "Visual Studio 17 2022"，CMake 生成了一大堆 .sln 和 .vcxproj 文件。这些文件是 XML。巨大无比。你打开看一眼就想吐。你不想用 Visual Studio IDE，你只想用命令行。但 MSVC 的命令行生态是 二等公民。

最可笑的是预编译头。在 Linux 上没人用预编译头，因为编译速度没那么慢。在 Windows 上不用预编译头？#include <windows.h> 一个头文件展开后几十万行，再 #include <iostream> 又是几万行。你的编译速度慢得像是在用软盘装系统。而 MSVC 的预编译头机制 —— /Yc 和 /Yu——复杂到专门有一本书的章节讲它。而且它在命令行下用起来别扭得要死。

你花在工具链上的时间，你的 Linux 队友用来写 feature。

三、Rust 工具链#

有人说 “我在 Windows 上用 Rust 开发体验很好”。是的，体验很好。但你知道这个 “很好” 是怎么来的吗？

Rust 为了在 Windows 上找到 cl.exe 和相关环境，专门写了约 2000 行代码，一整个专门的 package。你以为 cargo build 能直接工作是理所当然的？不是。那是 Rust 工具链的维护者替你受了你本该受的苦。

在 Linux 上写 cargo build，它调用 cc，cc 调用 gcc 或者 clang，完事。三行逻辑。

在 Windows 上写 cargo build，背后是一台用胶带和铁丝绑在一起的 Frankenstein 怪物。而 Rust 团队花了无数个日夜，让这个怪物看起来像个正常人。

你觉得体验好，是因为有人替你挡了子弹。和 Windows 毫无关系。

四、LF vs CRLF：一场持续五十年的愚蠢战争#

这是最让我无语的一个问题。它本来不应该存在。

Unix 用 LF（\n，0x0A）表示换行。古老的 Mac OS 9 用 CR（\r，0x0D）。Windows 用 CRLF（\r\n，0x0D 0x0A）。

为什么 Windows 用 CRLF？因为 MS-DOS 抄袭 CP/M，CP/M 用 CRLF 因为它的文件系统用 CRLF 来 “兼容 TTY（电传打字机）”。TTY，你听听，电传打字机！！

现在是 2026 年。谁还用电传打字机做终端输出？没有。但 Windows 记事本 —— 直到 2018 年 —— 都不支持 LF 作为换行符。你打开一个 LF 结尾的文件，它会显示成一行。整个文件粘在一起。后来微软改了，但那是 2018 年！距离 Unix 发明已经过了 49 年。

你以为现在没问题了？Naive!

Git 有 core.autocrlf。你设成 true，它会在 checkout 时把 LF 转成 CRLF，commit 时转回 LF。看起来很美。但你会遇到：

• 一个 shell 脚本里有 #!/bin/bash，它要求文件以 LF 结尾。Git 把它转成了 CRLF，bash 不干了。
• 一个 JSON 文件里嵌了换行符，你的解析器逐字节读，发现多了一个 \r，JSON 解析失败。
• 你的 Python 脚本用 open("file", "r") 打开一个 CRLF 文件，在 Linux 上读出来每行末尾有 \r，你 strip 了吗？没有，于是你比较字符串的时候永远相等不了。
• 你的队友不小心提交了一个 CRLF 文件，你用 git diff 看到整个文件每一行都被修改了。因为 diff 工具认为每一行末尾多了一个看不见的字符。

你在 Windows 上配 .gitattributes 配到怀疑人生。你设 * text=auto，又设 *.sh text eol=lf，又设 *.bat text eol=crlf。然后你发现 .gitattributes 自己也被转成了 CRLF，导致 Git 不认这个文件。

你的 Linux 队友从不思考这个问题。他写代码，commit，push。你 pull 下来，所有文件都在报错。你花半天时间 dos2unix 整个目录，commit，push。你的 macOS 队友 pull 下去，他的编辑器显示 “文件格式混合”。他开始骂你，你开始骂 Windows。

而 Windows 说：“我们有 WSL 啊，你在 WSL 里开发不就好了？”

五、WSL 不是答案#

每次说到这，总有 Windows 粉丝说 “你用 WSL 啊”。我建议你把 WSL 的全名念一遍，WSL 是 Windows Subsystem for Linux。

WSL 1 是翻译层，把 Linux 系统调用翻译成 Windows 系统调用。慢得一塌糊涂，I/O 性能像在爬。

WSL 2 跑了一个真正的 Linux 内核在 Hyper-V 虚拟机里。性能好了，但你的文件在哪？你在 /home/JH/project 下，这个目录实际在虚拟硬盘文件里。你想访问 Windows 的 C:\Users\JH\project？可以，它在 /mnt/c/ 下面。但访问 /mnt/c/ 的性能 又回到了 WSL 1 的水平，因为要经过 9p 协议来回转换。

所以你在 WSL 里工作的最佳实践是什么？把代码放在 WSL 自己的文件系统里。也就是说，你不用 Windows 的文件系统了。你的编辑器呢？你可以在 Windows 上用 VS Code 连接 WSL，通过 Remote - WSL 插件。VS Code 在 Windows 上跑界面，后端在 WSL 里跑。

等等，那你的开发环境到底算 Windows 还是 Linux？你调试一个程序，它在 WSL 里跑，但你用的工具链是 Linux 的 gcc，链接的是 Linux 的 .so 文件，生成的是 Linux 的 ELF 二进制。这个二进制在 Windows 上跑不了。你想生成 Windows 的 exe？那你得退出 WSL，回到 Windows，用 MSVC。

所以 WSL 不是让你在 Windows 上开发 Windows 程序。它是让你在 Windows 上开发 Linux 程序。换句话说，你用 Windows 作为宿主机，跑一个 Linux 虚拟机，然后在虚拟机里开发。那你为什么不直接装 Linux？

WSL 的存在说明：微软承认 Windows 的开发体验不如 Linux，所以他们给你一个 Linux 虚拟机。但你每多一层抽象，就多一层麻烦。网络配置、设备映射、环境变量传递、进程间通信 —— 每一个都有一堆奇怪的边界情况。

这就好比你说 “我想学游泳”，然后有人给你买了一个游泳池，但游泳池里没有水，水在隔壁的另一个池子里，你得用一个桶把水拎过来。你问 “为什么不直接在那个池子里游泳”？他说 “因为那个池子太丑了”。

六、摩登的 PowerShell#

你说你用 PowerShell。好，我问你：你打开一个终端，输入 powershell，回车，然后呢？

等…

等……

等………

等五秒钟。等六秒钟。有些配置稍差的设备，甚至能等十秒。

你告诉我，你在一台 CPU 是 5GHz，内存 64GB，NVMe SSD 的机器上，启动一个 Shell 要五秒钟。这不是开玩笑吗？五秒钟够 Linux 启动整个系统了。

为什么？因为 PowerShell 启动时要加载 .NET 运行时。.NET 运行时要 JIT 编译一大堆代码。它要加载几百个 DLL。它要读取你的 profile 脚本。它要做一百件你根本不关心的事情。

你说 “那我用 Nushell”。Nushell 启动只要 9 毫秒。你算算：5000 毫秒除以 9 毫秒，555 倍。这是什么概念？PowerShell 用户眼里的 Nushell 就像普通人眼里的 Faiz 加速形态。

七、MSVC Build Tools：许可证问题让你无法自动化#

这可能是最荒谬的一点。

你想在 CI/CD 里自动构建 Windows 程序。你在 Linux runner 上交叉编译？不行，你缺 MSVC 的 headers 和 libraries。

那你怎么办？你需要安装 MSVC Build Tools。你怎么安装？你去微软官网下载 vs_BuildTools.exe，然后手动点击下一步、下一步、同意许可协议、勾选组件、等待安装。

你不能用 winget 自动安装。你不能用 Chocolatey 自动安装（虽然社区有包，但不是微软官方支持的）。你不能在 Docker 镜像里预装（除非你用 Windows 容器，那又是另一个地狱）。

MSVC Build Tools 的许可证不允许你以编程方式绕过安装程序的 “技术限制”。你可以自己写脚本调用静默安装参数，但那不叫 “自动化”，那叫 “我帮你点下一步” —— 你依然需要一个交互式会话或者预先配置好的镜像。

在 Linux 上装 gcc：apt install gcc。一条命令，不需要点击任何东西，不需要同意任何许可协议，不需要等待一个蜗牛般的下载。

微软为什么不能把 MSVC 工具链放到一个简单的 .tar.gz 里？因为许可证不允许。因为微软希望你用 Visual Studio IDE。因为命令行用户是二等公民。从 1990 年代到现在，一直是。

八、GBK 编码：一个本该在 2006 年死去的东西#

写中文注释。处理中文文件路径。你的队友在 macOS 上提交了一个包含中文字符的 JSON 文件。

恭喜你，触发了 Windows 最恶心的 “特性” 之一：GBK 编码。

在 Linux 和 macOS 上，文本文件默认是 UTF-8。从 2000 年代初就是这样。今天是 2026 年，UTF-8 已经是绝对的主流，全世界 98% 的网页用 UTF-8。

Windows 呢？Windows 的 “ANSI 代码页” 默认是 GBK（如果你在中文系统上）。你用记事本保存一个文件，默认编码是 ANSI（也就是 GBK）。你用 PowerShell 输出重定向，默认编码是 UTF-16LE（不是 UTF-8）。你用 cl.exe 编译一个源文件，如果源文件是 UTF-8 with BOM 它能认，没有 BOM？它当成 ANSI 处理，然后你的中文字符串变成了乱码。

你的 Linux 队友提交了一个 UTF-8 文件，你拉下来用 VS Code 打开，VS Code 猜编码猜错了，你看到一堆 ä½ å¥½。你手动改编码，保存。然后你的队友拉下去，发现文件变成了 CRLF（我们后面说这个）加 UTF-8 with BOM。他开始骂你。

你在 Python 脚本里写 open("file.txt", "r")，在 Linux 上读 UTF-8，在 Windows 上读 GBK。你的脚本 “在我电脑上能跑”，在你队友电脑上崩了。

你说 “那我用 Python 的 encoding='utf-8' 参数”。你知道你要写这个参数，你写了。但你调用的第三方库呢？它没写。你的构建脚本里的某个工具呢？它没写。总有某个地方，某个人，某段代码，默认用了系统 ANSI 代码页。

这个问题从 Windows 95 时代就存在。30 年了。没有解决，且永远不会解决。

九、LLM Agent 时代的致命伤#

这是 2026 年才变得特别明显的问题。

你让一个 LLM Agent 比如 Claude Code、OpenAI Codex 帮你执行一条命令。在 Linux 上，Agent 写 grep "hello world" file.txt，直接执行，成功。

在 Windows 上，Agent 写 findstr "hello world" file.txt，执行，成功。看起来不错。

然后你让 Agent 执行一条稍微复杂一点的命令：

1
powershell -Command "& { Get-ChildItem -Recurse | Where-Object { $_.Name -match 'test' } }"

问题来了。引号嵌套。Agent 不知道什么时候用双引号，什么时候用单引号，什么时候转义。PowerShell 的语法是出了名的 “写起来像英语，转义起来像咒语”。

你让 Agent 生成一行 C++ 代码并通过 cl.exe /D 传入：

1
cl /D"MY_STRING=\"hello\\nworld\"" main.c

你需要两层转义：一层给 shell，一层给 C 预处理器。在 cmd.exe 里，转义规则和 PowerShell 不一样。在 PowerShell 里，转义规则又不一样。在 Git Bash 里，又不一样。

Agent 试了三次，都失败了。它开始 “深度思考”，写了一个 Python 脚本来生成命令，然后执行 Python 脚本——绕了一个大圈子。你的 token 消耗从 100 变成了 5000。没关系，Windows 用户的 token 是大风刮来的。

你的 Linux 队友的 Agent 从未失败过。因为 Linux shell 的转义规则是清晰的、一致的、可预测的。Windows 有四种不同的 shell（cmd，PowerShell，Git Bash，WSL bash），四种不同的转义规则，每一种都有自己的 “惊喜”。

十、关不掉的 Windows Defender#

你说你的编译慢。你说你的 npm install 慢。你说你的 git clone 慢。

我告诉你原因：Windows Defender 在扫描每一个文件。

你编译一个 C++ 项目，生成 1000 个 .obj 文件。Defender 在每个文件创建时扫描一遍。在每个文件写入时扫描一遍。在链接器读取每个文件时再扫描一遍。

你在 Linux 上编译同一个项目，没有这些扫描。编译时间差多少？首席水煮牛肉师实测，同一台设备，物理安装 Linux + XeLaTeX 编译一份 .tex 文档，比 Windows 快 80%。

80%！这意味着你在 Windows 上等 10 分钟，在 Linux 上等 2 分钟。一天编译 20 次，你浪费了 160 分钟。将近三个小时。

那我关掉 Defender？你试过吗？你知道怎么关吗？

你可以去 “Windows 安全中心” 关掉 “实时保护”。五分钟后它会自动重新打开。你可以在组策略里禁用。但 Windows 10/11 的家庭版没有组策略。你可以修改注册表。但下一次 Windows Update 会把它改回来。你可以装一个第三方杀毒软件，Defender 会自动关闭 —— 但你现在不仅要对付 Defender，还要对付另一个杀毒软件。

能不能完全永久关掉？不能。Windows 不允许你关掉它最核心的安全功能。这是“为了你好”。微软替你做了决定。

你说 “那我把编译目录加到排除列表里”。可以。但你做 CI/CD 的时候呢？你的构建机每次都是新的，排除列表每次都要重新配置。你的 Docker 容器里跑 Windows？排除列表在容器里不生效。

而在 Linux 上，安全是你的责任。你想关 SELinux？setenforce 0。你想关 AppArmor？systemctl stop apparmor。系统听你的。Windows 不听你的。Windows 是你的 Master，你不是它的用户。

十一、NTFS 和 ReFS 的悲剧#

在 Windows 上编译一个项目，生成几千个小文件。慢到怀疑人生。

你把项目放到 Dev Drive 上（微软 2023 年推出的“开发者专用”分区格式，基于 ReFS）。快了一点。但为什么还是比 Linux 慢？

因为问题的根源不是文件系统格式，是 安全软件插在文件系统上的那些钩子 （filters/hooks)。Dev Drive 之所以快，是因为 Windows 默认不对 Dev Drive 上的文件进行某些安全检查。但即使这样，Linux 在处理大量小文件的场景下依然比 Windows 快得多。

Linux 的文件系统设计从一开始就考虑了 “很多小文件” 的场景。ext4、XFS、btrfs，它们的目录结构、inode 管理、缓存策略，都是为真实世界的工作负载优化的。

NTFS 的设计目标是 “与 DOS 和 Windows 95 兼容”。它的根目录下还有 C:\、D:\ 这种盘符的概念——这是 1970 年代的 CP/M 遗留的设计。你什么时候在 Linux 上见过盘符？没有。/mnt 和 /media 是挂载点，不是盘符。

你说 “那我用 WSL 2，把代码放在 WSL 的文件系统里”。是的，这样快。但你本质上是在用 Linux 的文件系统。那你为什么不直接装 Linux？

Windows 的文件系统性能问题不是 “差一点”，是 “差一个数量级”。你编译一次可能只差几十秒，但你一天编译几十次，一周五天，一年五十二周——算算你浪费了多少生命？

十二、Windows 11 的内存黑洞#

你说你的电脑是 8GB 内存。你说你只是想写写前端代码。

8GB 内存在 Windows 11 上连 “开机后什么都不做” 都勉强。

Windows 11 开机后，系统自身吃掉 3-4GB。Windows Defender 吃掉 500MB。Windows Update 服务吃掉 200MB。各种 “现代” 应用的后台进程——天气、新闻、Xbox、Your Phone、Cortana*（对，它还在）*加起来又是 1GB。

你已经用了 5-6GB。你打开 Chrome 或 Edge？一个 tab 100MB 起，开十个 tab 就是 1GB。你打开 VS Code？又一个 500MB。你打开 Docker Desktop？2GB 没了。你的内存开始 swap。swap 到 SSD，SSD 寿命下降。你的电脑开始卡。

你说 “那我加内存”。好，你加到 16GB。Windows 11 会咸因吗？不会。它会用更多内存来 “缓存” 东西，因为它的内存管理策略现在是 “有多少用多少”。你打开任务管理器，看到 “已提交” 内存是物理内存的两倍。你问系统管理员这是怎么回事，他说 “You’re Absolutely Right!”。

正常？你在 Linux 上跑 free -h，看到 used 是 2GB，cached 是 4GB，available 还是 4GB。你清楚知道内存去哪了。Windows 的 “资源监视器” 给你看一堆数字，你看了三遍也不知道到底谁吃了你的内存。

更可笑的是，Windows 11 的推荐配置是 4GB 内存。4GB！安装都装不进去 —— 安装程序自己就要 2GB，还要留空间解压文件。微软的硬件兼容性团队是不是在用 8 + 128 (8TB SSD + 128GB RAM) 的机器测试，然后写文档的人觉得是 8 + 128 GB，才能如此心安理得地写下 推荐配置 4GB？

十三、WebView UI 把操作系统变成浏览器#

Windows 11 最 “现代” 的特性是什么？WebView UI。

设置界面是 WebView。开始菜单是 WebView。文件资源管理器的部分界面是 WebView。通知中心是 WebView。任务栏的 “小组件” 是 WebView。

没错！你的操作系统，现在是用 HTML、CSS 和 JavaScript 渲染的。

你打开 设置 → 个性化 → 颜色。你点了 “深色模式”。UI 卡了 0.5 秒。为什么？因为它要重新渲染整个 WebView 页面。你在 Linux 上改个 GTK 主题，瞬间生效。因为 GTK 是原生渲染。

WebView 有什么问题？

• 内存占用翻倍。每个 WebView 实例是一个迷你浏览器，有自己独立的渲染进程。设置界面是一个实例，开始菜单是一个实例，小组件是一个实例。每个实例吃掉 100-200MB 内存。你的 8GB 机器就这样被一点点蚕食。
• 渲染延迟。你点击“开始”，等 0.3 秒菜单才弹出来。不是动画时间，是 WebView 响应时间。你在 Linux 上用 KDE 或 GNOME，点击开始菜单，瞬间弹出。因为那是原生代码，不是 JavaScript。
• 动画掉帧。你打开通知中心，动画掉到 30fps。你问微软为什么不优化，微软说 “我们用 Fluent Design 的流畅动画”。流畅？30fps 叫流畅？你在 macOS 上打开通知中心，ProMotion 120fps 丝般顺滑。Windows 11 的 UI 性能甚至不如 2015 年的 Windows 10，而 Windows 10 的性能不如 2012 年的 Windows 8/8.1。开倒车，而且是坐着火箭开倒车。

一个操作系统，连自己最基础的 UI 都做不好，你指望它能做好开发体验？

十四、微软官方承认的 boot loop 特性#

2025 年，微软官方发布了一篇支持文档，标题是 “Windows 更新后可能出现 boot loop”。

你再读一遍这句话。

微软官方承认，他们的操作系统在更新后可能会 boot loop。

你的电脑开机，启动 Windows，加载更新，重启，开机，启动 Windows，加载更新，重启 …… 循环往复，直到你手动进入恢复模式，卸载更新，或者重装系统。

2025 年，微软说 “我们正在修复这个问题”。

2026 年，这个问题依然存在。

你在写代码，Windows 提示 “需要重启以完成更新”。你说 “稍后”。Windows 不听你的，因为 Windows 作为大总统的权力是无限的。Windows 在凌晨 3 点自动重启了。你的工作没有保存。你的 IDE 没有恢复会话。你的本地 git 仓库可能有未提交的变更。全是你的责任，你用 Windows 这个权力无限大系统应该承受的责任。

第二天早上你打开电脑，看到 “正在配置更新 0%”。你等。等到 30%。它重启。又开始 “正在配置更新 0%”。

你这一天废了。你要花两个小时进入恢复模式，卸载更新，然后关闭 Windows Update 服务。你的 Linux 队友已经提交了三个 PR 然后超额完成任务给自己放假了。

你说 “那我用 Windows LTSC 版本，没有这些花里胡哨的更新”。好，但你用的是企业版，你的公司不一定买。而且 LTSC 版本三年才更新一次，你的开发工具需要的新 API 没有。你装个 Node.js 18，它说 “需要 Windows 10 1903 或更高版本”。你的 LTSC 是 1809。你又被卡住了。

Windows 是一个强制性的、不可预测的、可能摧毁你工作进度的操作系统， 其中 “操” 念第四声。你永远不知道它什么时候会来，来了之后会不会把你的系统搞崩。

十五、最大的讽刺，最好的游戏系统#

这是起点，亦是终点。

2000 年代，Windows 的护城河是什么？游戏。你想玩游戏？你必须装 Windows。Linux 上连《魔兽世界》都跑不了，macOS 上更别想。那时候的 Windows 用户嘲笑 Linux 用户：“你的系统能玩 3A 大作吗？或者 Galgame？”

2026 年，情况完全反过来了。

• Steam Deck 卖了几百万台，跑的是基于 Arch Linux 的 SteamOS。
• Wine / Proton 让成千上万的 Windows 游戏在 Linux 上无缝运行。很多游戏在 Proton 下的性能甚至 超过原生 Windows，因为 Vulkan 翻译层比 DirectX 在某些场景下更高效，也没有无数次生生不息的 Defender 扫描，也没有残废的文件系统。
• NVIDIA 和 AMD 的 Linux 驱动已经成熟到可以跑光线追踪。
• macOS 游戏玩家 —— 就是那群被嘲笑了二十年的 “用 Mac 玩游戏的精神病人”，现在已经可以通过 Game Porting Toolkit 玩不少 3A 大作。苹果甚至官方支持这件事。

游戏。Windows 最后的堡垒，几乎已经沦陷了。

而 Windows 呢？它在开发领域依然是一团糟。你在 2026 年用 Windows 开发，你要面对：

• 路径分隔符的混乱（来自 1980 年代的 DOS）
• CRLF 换行符（来自 1970 年代的 CP/M）
• MSVC 工具的许可证地狱（来自微软的商业模式）
• PowerShell 五六秒的启动时间（来自 .NET 的包袱）
• GBK 编码（来自中国区 Windows 的特殊 “待遇”）
• Defender 关不掉的 I/O 拖累
• 四种 shell 四种转义规则
• 8GB 内存不够开机（来自 Windows 11 的 “现代化”）
• WebView UI 卡成 30fps（来自 “我们也是 Web 公司” 的幻觉）
• boot loop（来自微软官方承认的 bug 特性）

你的 Linux 队友在做什么？TA 在 Arch 或者 NixOS 上全成就通关《魔法少女的魔女审判》，在《鸣泣之时》中听着志方晶子志仓千代丸作的曲子看沙都子大战梨花，在《素晴日》里穿着轻飘飘的衣服于楼顶上抽烟，切到桌面，gcc main.c -o main，完事。

你的 macOS 队友在做什么？TA 在 MacBook Pro 上打开《赛博朋克 2077》《死亡搁浅 2》《生化危机》《博德之门 3》《艾尔登法环》《巫师 3》《无人深空》，关掉，clang main.c -o main，完事。甚至还有余力剪辑游戏录屏然后发到 B 站。

你呢？笔电男大？你在等待 PowerShell 启动，你在等待 Windows 启动，但有时它们永远也不会启动，像极了在一代杀戮尖塔玩鸡煲的你。你在跟 CRLF 搏斗。你在想 cl.exe 你到底在哪，cl.exe 你根本不在 C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.44.35207\bin\Hostx64\x64，你在想 cl.exe 为什么会和 nvcc、cygwin 撞车。你在想 Everything 为什么能在你本地搜出 11 个 ghc 安装目录下的 MSYS2。你在考虑要不要把编译目录加到 Defender 排除列表里，你在想要不要重装一个更稳定的第三方修改版 Windows。你在 Stack Overflow 上搜 “vswhere 找不到 Visual Studio”。你的电脑在 boot loop。你的 UI 在掉帧。你的内存被 WebView 吃光了。你打开 IM 尝试求助群友，但是每个人都在发 “喜报” 图片。

你想你的 Arch Linux 了。

帕特玛颠倒了，世界颠倒了。但 Windows 没变。

后记#

有读者问我 “你是不是对微软有偏见”。我对微软没有任何偏见。我对任何浪费我时间的工具有偏见。Windows 是其中最突出的一个，MS Office 也是，不过这是另一个话题了。

还有读者问 “2026 年了，你还用 Windows 吗？”

用。为了写出这篇文章，我还得用。

本土化翻译#

1
echo 3 | sudo tee /proc/sys/vm/drop_caches

1
  JH on Monday at 8:39 PM                                                            0.764s  MEM: 77.51% (12/16GB)
2
  {  home }  free -m
3
                total        used        free      shared  buffered/cached   available
4
  Mem:          16000        6560         212           0             9228        9440
5
  Swap:          1000        35.3         988

原文版本历史#

目录#

• 声明
• 简介
• 在提问之前
• 当你提问时
  • 慎选提问的论坛
  • Stack Overflow
  • 网站和 IRC 论坛
  • 第二步，使用项目邮件列表
  • 使用有意义且描述明确的标题
  • 使问题容易回复
  • 使用清晰、正确、精准且合乎语法的语句
  • 使用易于读取且标准的文件格式发送问题
  • 精确地描述问题并言之有物
  • 话不在多而在精
  • 别动辄声称找到 Bug
  • 低声下气不能代替你的功课
  • 描述问题症状而非你的猜测
  • 按发生时间先后列出问题症状
  • 描述目标而不是过程
  • 别要求使用私人电邮回复
  • 清楚明确地表达你的问题以及需求
  • 询问有关代码的问题时
  • 别把自己家庭作业的问题贴上来
  • 去掉无意义的提问句
  • 即使你很急也不要在标题写紧急
  • 礼多人不怪，而且有时还很有帮助
  • 问题解决后，加个简短的补充说明
• 如何解读答案
  • RTFM 和 STFW：如何知道你已完全搞砸了
  • 如果还是搞不懂
  • 处理无礼的回应
• 如何避免扮演失败者
• 不该问的问题
• 好问题与蠢问题
• 如果得不到回答
• 如何更好地回答问题
• 相关资源
• 鸣谢

声明#

许多项目在他们网站的帮助文档中链接了本指南 这很好，这正是我们想要的用途 但如果你是该项目管理员并试图创建指向本指南的超链接，请在超链接附近的显著位置注明：

本指南不提供此项目的实际支持服务！

我们已经深刻领教到缺少上述声明所带来的痛苦：我们将不停地被那些认为发布这本指南就意味着有责任解决世上所有技术问题的傻瓜苦苦纠缠

如果你因寻求某些帮助而阅读本指南，并在离开时还觉得可以从本文作者这里得到直接帮助，那你就是我们之前说的那些傻瓜之一 别问我们问题，我们只会忽略你 我们在这本指南中想教你如何从那些真正懂得你所遇到的软件或硬件问题的人处取得协助，而 99% 的情况下那不会是我们 除非你确定本指南的作者之一刚好是你所遇到的问题领域的专家，否则请不要打扰我们，这样大家都会开心一点

简介#

在黑客的世界里，你所提技术问题的解答的好坏, 很大程度上取决于你提问的方式与此问题的难度 本指南将教你如何正确地提问以获得你满意的答案

现在开源（Open Source）软件已经相当盛行，您通常可以从其他更有经验的用户那里获得与黑客一样好的答案，这是件好事；和黑客相比，用户们往往对那些新手常遇到的问题更宽容一些 尽管如此，以我们在此推荐的方式对待这些有经验的用户通常也是从他们那里获得有用答案的最有效方式

首先你应该明白，黑客们喜爱有挑战性的问题，或者能激发他们思维的好问题 如果我们并非如此，那我们也不会成为你想询问的对象 如果你给了我们一个值得反复咀嚼玩味的好问题，我们自会对你感激不尽 好问题是激励，是厚礼 好问题可以提高我们的理解力，而且通常会暴露我们以前从没意识到或者思考过的问题 对黑客而言，“好问题！”是诚挚的大力称赞

尽管如此，黑客们有着蔑视或傲慢面对简单问题的坏名声，这有时让我们看起来对新手、无知者似乎较有敌意，但其实不是那样的

我们不讳言我们对那些不愿思考、或者在发问前不做他们该做的事的人的蔑视 那些人是时间杀手 —— 他们只想索取，从不付出，消耗我们可用在更有趣的问题或更值得回答的人身上的时间 我们称这样的人为 失败者（loser） （由于历史原因，我们有时把它拼作 lusers）

我们意识到许多人只是想使用我们写的软件，他们对学习技术细节没有兴趣 对大多数人而言，电脑只是种工具，是种达到目的的手段而已 他们有自己的生活并且有更要紧的事要做 我们认可这点，也从不指望每个人都对这些让我们着迷的技术问题感兴趣 尽管如此，我们只为那些真正有兴趣并愿意积极参与问题解决的人调整回答问题的风格 这点不会变，也不该变：否则，我们就是在最擅长的事情上降低效率

我们（在很大程度上）是自愿的，从繁忙的生活中抽出时间来解答疑惑，而且时常被提问淹没 所以我们无情地滤掉一些话题，特别是拋弃那些看起来像失败者的家伙，以便更高效地利用时间来回答赢家（winner）的问题

如果你厌恶我们的态度，高高在上，或过于傲慢，不妨也设身处地想想 我们并没有要求你向我们屈服 —— 事实上，我们大多数人非常乐意与你平等地交流，只要你付出小小努力来满足基本要求，我们就会欢迎你加入我们的文化 但让我们帮助那些不愿意帮助自己的人是没有效率的 无知没有关系，但装白痴就是不行

所以，你不必在技术上很在行才能吸引我们的注意，但你必须表现出能引导你变得在行的特质 —— 机敏、有想法、善于观察、乐于主动参与解决问题 如果你做不到这些使你与众不同的事情，我们建议你花点钱找家商业公司签个技术支持服务合同，而不是要求黑客个人无偿地帮助你

如果你决定向我们求助，当然你也不希望被视为失败者，更不愿成为失败者中的一员 能立刻得到快速并有效答案的最好方法，就是像赢家那样提问 —— 聪明、自信、有解决问题的思路，只是偶尔在特定的问题上需要获得一点帮助

（欢迎对本指南提出改进意见 你可以把你的建议发送至 esr@thyrsus.com 或 respond-auto@linuxmafia.com 然而请注意，本文并非网络礼节的通用指南，而我们通常会拒绝无助于在技术论坛得到有用答案的建议）

在提问之前#

在你准备要通过电子邮件、新闻群组或者聊天室提出技术问题前，请先做到以下事情：

1. 尝试在你准备提问的论坛的旧文章中搜索答案
2. 尝试上网搜索以找到答案
3. 尝试阅读手册以找到答案
4. 尝试阅读常见问题文件（FAQ）以找到答案
5. 尝试自己检查或试验以找到答案
6. 向你身边的强者朋友打听以找到答案
7. 如果你是程序开发者，请尝试阅读源代码以找到答案

当你提出问题的时候，请先表明你已经做了上述的努力；这将有助于树立你并不是一个不劳而获且浪费别人的时间的提问者 如果你能一并表达在做了上述努力的过程中所学到的东西会更好，因为我们更乐于回答那些表现出能从答案中学习的人的问题

运用某些策略，比如先用 Google 搜索你所遇到的各种错误信息（搜索 Google 论坛和网页），这样很可能直接就找到了能解决问题的文件或邮件列表线索 即使没有结果，在邮件列表或新闻组寻求帮助时加上一句 我在 Google 中搜过下列句子但没有找到什么有用的东西 也是件好事，即使它只是表明了搜索引擎不能提供哪些帮助 这么做（加上搜索过的字串）也让遇到相似问题的其他人能被搜索引擎引导到你的提问来

别着急，不要指望几秒钟的 Google 搜索就能解决一个复杂的问题 在向专家求助之前，再阅读一下常见问题文件（FAQ）、放轻松、坐得舒服一些，再花点时间思考一下这个问题 相信我们，他们能从你的提问看出你做了多少阅读与思考，如果你是有备而来，将更有可能得到解答 不要将所有问题一股脑拋出，只因你的第一次搜索没有找到答案（或者找到太多答案）

准备好你的问题，再将问题仔细地思考过一遍，因为草率的发问只能得到草率的回答，或者根本得不到任何答案 越是能表现出在寻求帮助前你为解决问题所付出的努力，你越有可能得到实质性的帮助

小心别问错了问题 如果你的问题基于错误的假设，某个普通黑客（J. Random Hacker）多半会一边在心里想着蠢问题…，一边用无意义的字面解释来答复你，希望着你会从问题的回答（而非你想得到的答案）中汲取教训

绝不要自以为够格得到答案，你没有；你并没有 毕竟你没有为这种服务支付任何报酬 你将会是自己去挣到一个答案，靠提出有内涵的、有趣的、有思维激励作用的问题 —— 一个有潜力能贡献社区经验的问题，而不仅仅是被动地从他人处索取知识

另一方面，表明你愿意在找答案的过程中做点什么是一个非常好的开端 谁能给点提示？、我的这个例子里缺了什么？以及我应该检查什么地方比请把我需要的确切的过程贴出来更容易得到答复 因为你表现出只要有人能指个正确方向，你就有完成它的能力和决心

当你提问时#

如何解读答案#

如何避免扮演失败者#

在黑客社区的论坛中，你以本指南所描述的或类似的方式，可能会有那么几次搞砸了 而你会在公开场合中被告知你是如何搞砸的，也许攻击的言语中还会带点夹七夹八的颜色

这种事发生以后，你能做的最糟糕的事莫过于哀嚎你的遭遇、宣称被言语攻击、要求道歉、高声尖叫、憋闷气、威胁诉诸法律、向其雇主报怨、不去关马桶盖等等 相反地，你该这么做：

熬过去，这很正常 事实上，它是有益健康且合理的

社区的标准不会自行维持，它们是通过参与者积极而公开地执行来维持的 不要哭嚎所有的批评都应该通过私下的邮件传送，它不是这样运作的 当有人评论你的一个说法有误或者提出不同看法时，坚持声称受到个人攻击也毫无益处，这些都是失败者的态度

也有其它的黑客论坛，受过高礼节要求的误导，禁止参与者张贴任何对别人帖子挑毛病的消息，并声称如果你不想帮助用户就闭嘴 结果造成有想法的参与者纷纷离开，这么做只会使它们沦为毫无意义的唠叨与无用的技术论坛

夸张的讲法是：你要的是“友善”（以上述方式）还是有用？两个里面挑一个

记着：当黑客说你搞砸了，并且（无论多么刺耳）告诉你别再这样做时，他正在为关心你和他的社区而行动 对他而言，不理你并将你从他的生活中滤掉更简单 如果你无法做到感谢，至少要表现得有点尊严，别大声哀嚎，也别因为自己是个有戏剧性超级敏感的灵魂和自以为有资格的新来者，就指望别人像对待脆弱的洋娃娃那样对你

有时候，即使你没有搞砸（或者只是在他的想像中你搞砸了），有些人也会无缘无故地攻击你本人 在这种情况下，抱怨倒是真的会把问题搞砸

这些来找麻烦的人要么是毫无办法但自以为是专家的不中用家伙，要么就是测试你是否真会搞砸的心理专家 其它读者要么不理睬，要么用自己的方式对付他们 这些来找麻烦的人在给他们自己找麻烦，这点你不用操心

也别让自己卷入口水战，最好不要理睬大多数的口水战 —— 当然，这是在你检验它们只是口水战，并且未指出你有搞砸的地方，同时也没有巧妙地将问题真正的答案藏于其后（这也是有可能的）

不该问的问题#

以下是几个经典蠢问题，以及黑客没回答时心中所想的：

问题：我能在哪找到 X 程序或 X 资源？

问题：我怎样用 X 做 Y？

问题：如何设定我的 shell 提示？

问题：我可以用 Bass-o-matic 文件转换工具将 AcmeCorp 文件转换为 TeX 格式吗？

问题：我的程序/设定/SQL 语句没有用

问题：我的 Windows 电脑有问题，你能帮我吗？

问题：我的程序不会动了，我认为系统工具 X 有问题

问题：我在安装 Linux（或者 X）时有问题，你能帮我吗？

问题：我怎么才能破解 root 帐号/窃取 OP 特权/读别人的邮件呢？

问题：我能在哪找到 X 程序或 X 资源？

回答：就在我找到它的地方啊，白痴 —— 搜索引擎的那一头 天哪！难道还有人不会用 Google 吗？

问题：我怎样用 X 做 Y？

回答：如果你想解决的是 Y ，提问时别给出可能并不恰当的方法 这种问题说明提问者不但对 X 完全无知，也对 Y 要解决的问题糊涂，还被特定形势禁锢了思维 最好忽略这种人，等他们把问题搞清楚了再说

问题：如何设定我的 shell 提示？？

回答：如果你有足够的智慧提这个问题，你也该有足够的智慧去 RTFM，然后自己去找出来

问题：我可以用 Bass-o-matic 文件转换工具将 AcmeCorp 文件转换为 TeX 格式吗？

回答：试试看就知道了 如果你试过，你就知道了答案，就不用浪费我的时间了

问题：我的{程序/设定/SQL 语句}没有用

回答：这不算是问题吧，我对要我问你二十个问题才找得出你真正问题的问题没兴趣 —— 我有更有意思的事要做呢 在看到这类问题的时候，我的反应通常不外如下三种

• 你还有什么要补充的吗？
• 真糟糕，希望你能搞定
• 这关我屁事？

问题：我的 Windows 电脑有问题，你能帮我吗？

回答：能啊，扔掉微软的垃圾，换个像 Linux 或 BSD 的开源操作系统吧

注意：如果程序有官方版 Windows 或者与 Windows 有互动（如 Samba），你可以问与 Windows 相关的问题，只是别对问题是由 Windows 操作系统而不是程序本身造成的回复感到惊讶， 因为 Windows 一般来说实在太烂，这种说法通常都是对的

问题：我的程序不会动了，我认为系统工具 X 有问题

回答：你完全有可能是第一个注意到被成千上万用户反复使用的系统调用与函数库文件有明显缺陷的人，更有可能的是你完全没有根据 不同凡响的说法需要不同凡响的证据，当你这样声称时，你必须有清楚而详尽的缺陷说明文件作后盾

问题：我在安装 Linux（或者 X）时有问题，你能帮我吗？

回答：不能，我只有亲自在你的电脑上动手才能找到毛病 还是去找你当地的 Linux 使用群组者寻求实际的指导吧（你能在这儿找到用户群组的清单）

注意：如果安装问题与某 Linux 的发行版有关，在它的邮件列表、论坛或本地用户群组中提问也许是恰当的 此时，应描述问题的准确细节 在此之前，先用 Linux 和所有被怀疑的硬件作关键词仔细搜索

问题：我怎么才能破解 root 帐号/窃取 OP 特权/读别人的邮件呢？

回答：想要这样做，说明了你是个卑鄙小人；想找个黑客帮你，说明你是个白痴！

好问题与蠢问题#

最后，我将透过举一些例子，来说明怎样聪明的提问；同一个问题的两种问法被放在一起，一种是愚蠢的，另一种才是明智的

蠢问题：

我可以在哪儿找到关于 Foonly Flurbamatic 的资料？

这种问法无非想得到 STFW 这样的回答

聪明问题：

我用 Google 搜索过 “Foonly Flurbamatic 2600”，但是没找到有用的结果 谁知道上哪儿去找对这种设备编程的资料？

这个问题已经 STFW 过了，看起来他真的遇到了麻烦

蠢问题：

我从 foo 项目找来的源码没法编译 它怎么这么烂？

他觉得都是别人的错，这个傲慢自大的提问者

聪明问题：

foo 项目代码在 Nulix 6.2 版下无法编译通过 我读过了 FAQ，但里面没有提到跟 Nulix 有关的问题 这是我编译过程的记录，我有什么做的不对的地方吗？

提问者已经指明了环境，也读过了 FAQ，还列出了错误，并且他没有把问题的责任推到别人头上，他的问题值得被关注

蠢问题：

我的主机板有问题了，谁来帮我？

某黑客对这类问题的回答通常是：好的，还要帮你拍拍背和换尿布吗？，然后按下删除键

聪明问题：

我在 S2464 主机板上试过了 X 、 Y 和 Z ，但没什么作用，我又试了 A 、 B 和 C 请注意当我尝试 C 时的奇怪现象 显然 florbish 正在 grommicking，但结果出人意料 通常在 Athlon MP 主机板上引起 grommicking 的原因是什么？有谁知道接下来我该做些什么测试才能找出问题？

这个家伙，从另一个角度来看，值得去回答他 他表现出了解决问题的能力，而不是坐等天上掉答案

在最后一个问题中，注意告诉我答案和给我启示，指出我还应该做什么诊断工作之间微妙而又重要的区别

事实上，后一个问题源自于 2001 年 8 月在 Linux 内核邮件列表（lkml）上的一个真实的提问 我（Eric）就是那个提出问题的人 我在 Tyan S2464 主板上观察到了这种无法解释的锁定现象，列表成员们提供了解决这一问题的重要信息

通过我的提问方法，我给了别人可以咀嚼玩味的东西；我设法让人们很容易参与并且被吸引进来 我显示了自己具备和他们同等的能力，并邀请他们与我共同探讨 通过告诉他们我所走过的弯路，以避免他们再浪费时间，我也表明了对他们宝贵时间的尊重

事后，当我向每个人表示感谢，并且赞赏这次良好的讨论经历的时候，一个 Linux 内核邮件列表的成员表示，他觉得我的问题得到解决并非由于我是这个列表中的名人，而是因为我用了正确的方式来提问

黑客从某种角度来说是拥有丰富知识但缺乏人情味的家伙；我相信他是对的，如果我像个乞讨者那样提问，不论我是谁，一定会惹恼某些人或者被他们忽视 他建议我记下这件事，这直接导致了本指南的出现

如果得不到回答#

如果仍得不到回答，请不要以为我们觉得无法帮助你 有时只是看到你问题的人不知道答案罢了 没有回应不代表你被忽视，虽然不可否认这种差别很难区分

总的来说，简单地重复张贴问题是个很糟的点子 这将被视为无意义的喧闹 有点耐心，知道你问题答案的人可能生活在不同的时区，可能正在睡觉，也有可能你的问题一开始就没有组织好

你可以通过其他渠道获得帮助，这些渠道通常更适合初学者的需要

有许多网上的以及本地的用户群组，由热情的软件爱好者（即使他们可能从没亲自写过任何软件）组成 通常人们组建这样的团体来互相帮助并帮助新手

另外，你可以向很多商业公司寻求帮助，不论公司大还是小 别为要付费才能获得帮助而感到沮丧！毕竟，假使你的汽车发动机汽缸密封圈爆掉了 —— 完全可能如此 —— 你还得把它送到修车铺，并且为维修付费 就算软件没花费你一分钱，你也不能强求技术支持总是免费的

对像是 Linux 这种大众化的软件，每个开发者至少会对应到上万名用户 根本不可能由一个人来处理来自上万名用户的求助电话 要知道，即使你要为这些协助付费，和你所购买的同类软件相比，你所付出的也是微不足道的（通常封闭源代码软件的技术支持费用比开源软件的要高得多，且内容也没那么丰富）

如何更好地回答问题#

**态度和善一点 ** 问题带来的压力常使人显得无礼或愚蠢，其实并不是这样

**对初犯者私下回复 ** 对那些坦诚犯错之人没有必要当众羞辱，一个真正的新手也许连怎么搜索或在哪找常见问题都不知道

如果你不确定，一定要说出来！ 一个听起来权威的错误回复比没有还要糟，别因为听起来像个专家很好玩，就给别人乱指路 要谦虚和诚实，给提问者与同行都树个好榜样

**如果帮不了忙，也别妨碍他 ** 不要在实际步骤上开玩笑，那样也许会毁了提问者的设置 —— 有些可怜的呆瓜会把它当成真的指令

**试探性的反问以引出更多的细节 ** 如果你做得好，提问者可以学到点东西 —— 你也可以 试试将蠢问题转变成好问题，别忘了我们都曾是新手

尽管对那些懒虫抱怨一声 RTFM 是正当的，但能给出文档的链接（即使只是建议个 Google 搜索关键词）会更好

**如果你决定回答，就请给出好的答案 ** 当别人正在用错误的工具或方法时别建议笨拙的权宜之计（workaround），应推荐更好的工具，重新界定问题

正面地回答问题！ 如果这个提问者已经很深入的研究而且也表明已经试过 X 、 Y 、 Z 、 A 、 B 、 C 但没得到结果，回答 试试看 A 或是 B 或者 试试 X 、 Y 、 Z 、 A 、 B 、 C 并附上一个链接一点用都没有

**帮助你的社区从问题中学习 ** 当回复一个好问题时，问问自己如何修改相关文件或常见问题文件以免再次解答同样的问题？，接着再向文件维护者发一份补丁

如果你在研究一番后才作出了回答，展现你的技巧而不是直接端出结果 毕竟授人以鱼不如授人以渔

相关资源#

如果你需要个人电脑、Unix 系统和网络如何运作的基础知识，参阅 Unix 系统和网络基本原理

当你发布软件或补丁时，试着按软件发布实践操作

鸣谢#

Evelyn Mitchel 贡献了一些愚蠢问题例子并启发了编写如何更好地回答问题这一节， Mikhail Ramendik 贡献了一些特别有价值的建议和改进

🪨 A Stone Badge & 不死图腾#

1
        🟫🟫🟫🟫🟫🟫
2
      🟫🟨🟨🟨🟨🟨🟨🟫
3
      🟫🟨🟨🟨🟨🟨🟨🟫
4
      🟫🟧🟧🟨🟨🟧🟧🟫
5
      🟫⬜🟩🟧🟧⬜️🟩🟫
6
      🟫🟩🟩🟨🟨🟩🟩🟫
7
      🟫🟧🟧🟨🟨🟧🟧🟫
8
🟫🟫🟫🟫🟫🟧🟨🟨🟧🟫🟫🟫🟫🟫
9
🟫🟨🟧🟫🟨🟨🟧🟧🟨🟧🟫🟧🟨🟫
10
🟫🟫🟫🟨🟨🟨🟨🟨🟧🟧🟫🟫🟫🟫
11
      🟫🟨🟧🟧🟧🟧🟨🟫
12
      🟫🟫🟫🟫🟫🟫🟫🟫
13
        🟫🟨🟧🟧🟧🟫
14
        🟫🟨🟧🟧🟨🟫
15
          🟫🟫🟫🟫

提问的艺术 ‼️ FBI WARNING ‼️ 不看鸡把短 10CM~ ‼️ FBI WARNING ‼️#

❎ 错误的提问方式 ❎#

xxx 怎么搞/激活啊

xxx 为什么不能用啊

✅ 正确的提问方式 ✅#

• 问题：xxx？

• 环境 （这是最重要的 一眼就可以让人知道这个问题是否值得回答以及问题的根源）：

  1
  Root 方式
  2
  Magisk /KernelSU /Apatch
  3
  
  4
  微信版本
  5
  8.0.xx
  6
  
  7
  API 版本
  8
  100 及更低/101/102
  9
  
  10
  Xposed API 调用保护
  11
  未启用/已启用
  12
  
  13
  Dex 优化器包装
  14
  支持/不支持
  15
  
  16
  框架版本
  17
  xxx-it/irena/别的分支 (xxxx)
  18
  
  19
  管理器包名
  20
  com.android.shell/org.lsposed.manager
  21
  
  22
  系统版本
  23
  xx (API xx)
  24
  
  25
  设备
  26
  xxx
  27
  
  28
  系统架构
  29
  x86-64/arm64-v7a/v8a/v8a (4K)/risc-v

  展开收起

Tip

给新手的小提示

在 LSPosed 主界面长按即可复制设备信息

微信版本在 微信设置 ➡️ 关于 里看

记得补充你的 Root 方式和微信版本号

• 日志：xxx.zip （有最好 没有也罢）

一些常见问题 (Q&A)#

1. Q: 打开微信卡第一屏然后闪退？#

• 像这样：

A: 你的 LSPosed 肯定还在 1.9.x 版本 请按照 PART 1️⃣ LSPosed 的安装 更新你的 LSPosed

4. Q: 已成功激活 NewMiko 并且功能正常 但是 app 里显示 未激活 ？#

• A: 小明留给我们的陈年老 Bug 无视即可 在 LSPosed 2.0.0 及以上版本会出现

Tip

给新手的小提示： 在 LSPosed 设置里 关闭 **强制显示桌面图标** 功能并 重启你的📱 打开 NewMiko app ➡️ 更多设置 ➡️ 打开 隐藏桌面图标 这样你就不会看见这烦人的 未激活 了

Tip

此时若要打开 NewMiko app 的话 在 LSPosed 管理器里点 NewMiko ➡️ 右下角图标就可以了

还有的话我想到再补吧 妈妈的 累死劳资了

---

安装、激活教程#

PART 1️⃣ LSPosed 的安装#

Important

此教程只针对 KernelSU 及其分支撰写 不保证 Magisk 以及 Apatch 用户跟随本教程一定能用上此模块

Step 1️⃣ 确保你的📱已经获取了 Root 权限#

Tip

如果你通过小米机型越狱的半残废 Root 或者魅族的官方半残废 Root 使用 LSPosed 则可以忽略上一条

Step 2️⃣ 下载 Zygisk 实现模块 ReZygisk 或者 ZygiskNext 并刷入#

PerformanC

/

ReZygisk

Transparent implementation of Zygisk.

—

—

GPL-3.0

C

Dr-TSNG

/

ZygiskNext

Standalone implementation of Zygisk

—

—

no-license

C

Note

至于为什么有两个模块这件事么……是这样的： https://github.com/Dr-TSNG/ZygiskNext 一段时间前停止了开源 然后就有人搞了个开源的 https://github.com/PerformanC/ReZygisk 出来 从安全性的角度 本人更建议 https://github.com/PerformanC/ReZygisk 毕竟闭源的模块的安全性么……这就全看模块作者良心了 但是吧 https://github.com/PerformanC/ReZygisk 这模块也是刚刚出来的 稳定性这块还是差一点的（虽然本人目前用着也没发现大问题）所以你自己取舍吧

Step 3️⃣ 下载 并且刷入#

有两种方法下载 LSPosed:

1. 访问 lsposed.zip 直接下载
2. 如果无法访问 可加入 [tg@lsposed]（https://t.me/LSPosed） 群组 到群组内下载

Important

自 2024年4月26日 LSPosed 恢复更新起 LSPosed 不再开源并且进行内部测试制 并且不再分发于 Github 上 用户必须进入 https://t.me/LSPosed 群组 获取稳定版更新 而想要内测版用户则需要申请进入 LSPosed Internal Test 内测群组 详情见 ⬇️

https://t.me/LSPosed/275

• 在此加入 LSPosed 频道 ⬇️

LSPosed

内测群进群方式

https://t.me/LSPosed/287

• 🔗 在此 自己想办法解决吧

1
echo aHR0cHM6Ly90Lm1lLytOZkh6dGZ5TkJaczJaRGxs | base64 -d

Important

请使用 LSPosed API 版本 ≥ 101 的版本（ LSPosed 版本 ≥ 2.0.0）以防止出一些奇奇怪怪的问题

Note

奇奇怪怪的问题.png

原因：未升级 LSPosed 2.0.0 及以上版本

Tip

给新手的小提示 你可以在 LSPosed 主界面查看 LSPosed API 及 LSPosed 版本

Tip

给新手的小提示： 你可以从 LSPosed 的压缩包里提取出 manager.apk 并安装 这样你的 LSPosed 就不再寄生在 Shell 里了 可以常驻在后台

PART 2️⃣ NewMiko 的安装与激活#

Step 1️⃣ 加入 tg@MikoCIBuilds 频道获取最新版 NewMiko、#

Miko CI Builds

Step 2️⃣ 安装 NewMiko 并在 LSPosed 里激活 NewMiko#

1. 安装

2.LSPosed 主页 ➡️ 模块 ➡️ :newmiko: NewMiko（可能在下面）

3.NewMiko im.mingxi.miko ➡️ 启用模块 ➡️ 勾选微信 ➡️ 长按微信 ➡️ 强行停止 ➡️ 确认 ➡️ 启动

4.打开微信 ➡️ 我的 ➡️ 设置 ➡️ NewMiko ➡️ Enjoy!

---