1. 比起“服务”，我还是更倾向于把操作系统当作纯正的工具。可能这就是旧信息时代遗老吧。
2. “缘，妙不可言”。
3. 具体工作具体分析吧。跨平台开发 Arch 也挺舒服的。但 Adobe 全家桶就显然不适合了。

最近重新组织了下家里的设备，咱的笔记本也是先后经历了 Arch 转 Win11 再转 Arch 的路子。时至今日，我曾经跟着律回指南安装 Arch 的步骤有些不再适用，有些需要补充。总而言之，还是重新整理一下我的流程吧。

参考链接

本文有参考以下的安装教程：

1. 律回彼境：Arch Linux 折腾指南&记录（以下简称“律回指南”）
2. Nakano Miku：Arch 简明指南（以下简称“Miku 指南”）
3. Arch Wiki：Installation Guide

I. 前期准备

• 下载安装镜像：清华镜像 (最新版本)、官方下载。

烧录过程不再赘述，推荐用 Ventoy 统一管理安装镜像。参见 Ventoy 中文主页

• 固件¹：启用 UEFI、禁用安全启动（Secure Boot）。

近十几年的主板大都支持 UEFI，我也懒得花篇幅去讲传统 BIOS 引导。对于 Arch Linux 的 UEFI 引导方式，我另有一篇笔记讨论，可供部署阶段参考。
至于 Secure Boot，不用想了，给.efi启动文件签名着实是件麻烦事。对我而言折腾这个没有意义。

• 网络²：如需连接 WiFi，提前把 WiFi 名字（SSID）改成英文。

安装全程在命令行（CLI）环境进行，并且 LiveCD（维护环境，下同）显示不出中文，也打不出中文。

II. LiveCD 基础配置

与律回指南 Ch.1 相同，但省略了分配固定 IP 的一步（我完全可以ip addr猹询）。

III. 分区

对于固态硬盘，不提倡建立过多的分区。那么在 UEFI 启动、GPT 分区表的系统盘上，至少可以这么分：

• EFI 启动分区^[1]：挂载/efi或/boot^[2]
• 系统分区：挂载根目录/

我个人在此基础上，倾向于在硬盘（逻辑扇区的）末端开多一个交换分区。

详细的分区步骤参见 Miku 指南。由于该指南假定保留 Windows 系统分区，其对分区方案的介绍实际上拆成了两部分：

• 🆕 全新安装
• 7. 分区和格式化（使用 Btrfs 文件系统）

然后是挂载。务必注意先挂载/！此外，不要把不同分区、子卷挂到同一个挂载点上；有分交换分区的话记得swapon。

IV. pacman 配置

i. 换源

Linux 的包管理器默认食用国外的软件源，pacman也一样。因此，非常建议先换用国内镜像，加快包下载速度。

然鹅在更换之前可能需要等待片刻：一经联网，reflector会自动筛选最新的 20 个镜像站，然后才从快到慢排序³。如果换源过早，很可能会被reflector摘桃子。

编辑/etc/pacman.d/mirrorlist（vim还是nano请自便）：

# 在文件开头起一空行，复制下列镜像源：
Server = https://mirrors.tuna.tsinghua.edu.cn/archlinux/$repo/os/$arch
Server = https://mirrors.ustc.edu.cn/archlinux/$repo/os/$arch
Server = https://mirrors.aliyun.com/archlinux/$repo/os/$arch

ii. 自身配置

默认pacman是逐个下载软件的。但哪怕是 1MB/s 小水管，并行下载四、五个软件包也绰绰有余了。

编辑/etc/pacman.conf：

1. 找到# Misc options，删掉Color ParallelDownloads = 5前面的注释#：

# Misc options
#UseSyslog
Color            # 输出彩色日志
#NoProgressBar
CheckSpace
#VerbosePkgLists
ParallelDownloads = 5   # 最大并行下载数（根据你的网速自行斟酌，不建议写太大）

2. 翻页到文件末尾，删掉[multilib]和底下Include =这两行的注释#。

multilib是 32 位软件源。默认下载的包都是x86_64的，而有一些程序仍需要 32 位的库。

V. 正式部署

参见 Miku 指南—基础安装—9. 安装系统。或者像律回指南那样顺手装一些工具也无何不可：

pacstrap -K /mnt base linux linux-firmware base-devel linux-headers \
  vi vim nano git wget tmux openssh networkmanager htop ntfs-3g \
  intel-ucode    # or `amd-ucode`

(126/126) checking keys in keyring
warning: Public keyring not found; have you run `pacman-key --init`?
downloading required keys...
error: keyring is not writable
...
error: failed to commit transaction (unexpected error)

pacman-key --init
pacman-key --populate

然后genfstab -U /mnt > /mnt/etc/fstab生成挂载表；
再arch-chroot /mnt切换进新系统里，继续配置吧。

接下来在chroot环境里的配置我参考了律回指南 Ch.4，大体也符合官方文档的流程：调整时区、系统编码、设置主机名、root 密码、新建用户、配置 EFI 引导。

不过在visudo那一步我没有启用“免密sudo”（如下），律回本人也意识到免密sudo并不安全。

## Same thing without a password
#%wheel ALL=(ALL:ALL) NOPASSWD: ALL

VI. 新系统的配置

跟着律回指南的三、四章装好系统之后，重启登入新系统的终端。
首先通过nmtui连上 WiFi。

i. CN 源和 AUR 助手

在联好网的新系统里配置archlinuxcn源：再次打开/etc/pacman.conf，末尾添加如下小节

[archlinuxcn]
Server = https://mirrors.cernet.edu.cn/archlinuxcn/$arch

并安装 CN 源的签名密钥和 AUR 助手：

sudo pacman -S archlinuxcn-keyring  # 安装密钥环
sudo pacman -S yay paru   # 安装 AUR 助手

sudo pacman-key --lsign-key "farseerfc@archlinux.org"

ii. 硬件（一）音频安装

音频分为固件（或者说驱动）和管理套件两部分：

# 音频固件
sudo pacman -S sof-firmware alsa-firmware alsa-ucm-conf
# pipewire 及其音频管理套件
sudo pacman -S pipewire gst-plugin-pipewire pipewire-alsa pipewire-jack pipewire-pulse wireplumber

显卡驱动等其他硬件设施需要等装好桌面环境再考虑，在只有字符色块滚过的纯终端环境里也没有折腾显卡驱动的必要。

iii. KDE 桌面环境

跟完前面的内容之后，你便拥有了一个无 GUI 的终端 Arch 系统。但作为日常使用的话，图形桌面肯定必不可少。

本文与那两篇参考外链一样采用 KDE 桌面环境。当然除了 KDE 之外，你也可以考虑 GNOME 桌面环境 （只是我用腻了）； 也可以考虑散装方案（比如niri，部分配置可参见 aglab.dotfiles）。

# 分别安装 xorg 套件、sddm 登录管理器、KDE 桌面环境，以及配套软件
sudo pacman -S xorg
sudo pacman -S plasma sddm konsole dolphin kate okular spectacle partitionmanager ark filelight gwenview
# 启用 sddm 服务，重启进 SDDM 用户登录
sudo systemctl enable sddm
sudo reboot now

重启后在用户登录界面输入密码回车，恭喜你，距离投入日常使用只剩几步之遥了。之后对 KDE 和系统的配置大部分仍可参考律回指南 Ch.6。

iv. 硬件（二）显卡驱动与蓝牙

“so NVIDIA, F**K YOU! ”——Linus Torvalds

AMD 或 NVIDIA 显卡可参见律回指南 §6.4 和 Miku 指南—进阶安装—显卡驱动篇。 但我是锐炬核显捏，只需要在 Konsole 终端里sudo pacman -S安装英特尔的驱动：

• mesa lib32-mesa（OpenGL）
• vulkan-intel lib32-vulkan-intel（Vulkan）
• intel-media-driver（VAAPI 解码器，OBS 需要）

如果有蓝牙的话，在 Konsole 里启用（并立即启动）蓝牙服务：

sudo systemctl enable --now bluetooth

之前误以为bluetooth是 Arch 本身就有的服务，结果发现是桌面环境依赖了蓝牙组件包bluez。

v. 额外中文字体和输入法

律回指南安装的字体分别是 Noto 系列（Linux 常用的 Unicode 字体）和思源系列（也算是 Noto 系列的子集）。 其中 Noto 系列的汉字部分由于一些神秘的原因^[4]，不做额外配置的话，渲染出来只能说……能用。

至于输入法，现阶段推荐直接安装fcitx5，参见 Miku 指南—进阶安装—常用应用—10. 输入法。

至此，Arch 的安装告一段落，你可以像捣腾 Windows 那样玩转 Arch 了。

附录：系统美化

“爱美之心，人皆有之。”

I. 主题

主题这边我也没啥好推荐的，虽然 KDE 6 现在也出现了一些比较好看的主题，但终究是因人而异吧。

我想说明的是，KDE 商店的多数主题在 X11 会话、125% 甚至更高缩放率下会出现“非常粗窗口边框，使我的窗口肥胖”的现象（至少我的笔记本如此）。
我个人目前是直接修改主题 Aurorae 配置文件，利用二分法逐步找到四条边的最适 Padding。 网上貌似也有“把缩放调回 100%，但是更改字体 DPI”的做法，但个人觉得显示效果应该好不到哪去（

II. 仿 Mac 上下双栏布局

KDE 原生的桌面 UI 就挺 Windows 的，但胜在自由度足够高。 我个人觉得 Mac OS 那种双栏比较好看、比较方便，所以稍微按照如下配置调整了面板布局。

仅供参考咯。

除了 Finder 栏外，可以在系统设置里更改屏幕四周的鼠标表现。 比如，鼠标移动到左上角可以自动弹出“应用程序启动器”，移到右上角可以切换你的桌面，等等。

附录：GPG 密钥配置

主要讨论配置提交签名（Commit Signing）时遇到的问题。

I. VSCode 提交签名

大体上跟着 Commit Signing - VSCode Wiki 就可以了。唯一需要留意的是pinentry。

VSCode 的主侧栏“源代码管理”页提交时并不会走终端，也就莫得 pinentry 的 CUI；莫得 pinentry 输密码验证，提交就签不了名。 虽然有人好像搞了个pinentry-extension出来，但 6 月初我去看的时候它连说明书都莫得，也没有上架，那用集贸。

所以我选择编辑~/.gnupg/gpg-agent.conf：

default-cache-ttl 21600
pinentry-program /usr/bin/pinentry-qt

保存后重启gpg-agent：gpg-connect-agent reloadagent /bye。

ls /usr/bin | grep 'pinentry'
echo GETPIN | pinentry

除此之外，pinentry需要指定 tty，否则找不到 IO 设备也会炸。解法：export GPG_TTY=$(tty)。

经测试，大部分终端均能在 SSH 连接中调出 CUI。若 VSCode Remote-SSH 打开的终端签不了名，检查一下是不是终端分割得太小了。

II. GPG 密钥备份（导出导入）

之前并没有意识到备份 key 的重要性，结果重装 Arch 重新配置提交签名时， 我发现 GitHub 和腾讯 Coding 会重置提交验证（同一个邮箱只能上传一个公钥），届时就是我痛苦的 rebase 重签了。 不过好在受影响的多数只是我的个人项目，变基无伤大雅。

gpg --list-secret-keys --keyid-format LONG
# export
gpg -a -o public-file.key --export <keyid>
gpg -a -o private-file.key --export-secret-keys <keyid>
# import
gpg --import ~/public-file.key
gpg --allow-secret-key-import --import ~/private-file.key

重新导入 Key 之后，可能还需要gpg --edit-key更改密码（passwd）、重设信任（trust）。

当然有人马上会想到虚拟机，比如熟悉的 VirtualBox、VMWare，比如winapps。但虚拟机也好，双系统也罢，都太重量级了，我个人并不喜欢。

那都玩 Linux 了，Wine 兼容层怎么样呢？不也有过 Wine 跑《原神》的成功案例了嘛。但遗憾的是，自 9.17-1 版本开始，原生 Wine 的 DDraw 兼容都做得十分甚至九分的抽象，无论是红警 2 本体还是 FA2 地图编辑器都无法正常显示，原生 Wine 也就不再适用了。

现阶段也不再建议用 Wine 玩原神，容易被封号。可以试试云原神，但首先需要解决“鼠标无法转动视角”的问题。

所以，兜兜转转，还是回到了 Bottles。

那么正式开始之前，我有必要先说一下我的 Linux 环境。由于 Linux 发行版众多，我无法保证别的包源、别的发行版能否这么操作。

• 操作系统：Arch Linux
• 桌面环境：KDE 6

一、Bottles

Bottles 是由 bottlesdevs 开发的可视化 Wine 配置工具，旨在“让用户便利地在喜欢的发行版里运行 Windows 程序”。

参考链接：GitHub 官网

官方推荐通过 Flatpak 安装，在沙箱里运行。但由于“懒加载”^[1]问题，游戏本体和地编都无法正常启动。因此还是改用pacman吧。

首先需要引入archlinuxcn源。具体步骤参见《Arch 安装流程》，这里不再重复。
接着sudo pacman -Sy bottles-bwrap安装。等待进度跑完，就可以从“应用程序菜单栏”运行了。

初次运行 Bottles 会弹出一个向导跟你 blabla，无脑下一步即可。 到最后一步时 Bottles 会下载一些组件包。由于众所周知的原因，可能会花费比较长的时间。

二、部署 Bottle

2.1 新建

进入 Bottles 的主界面，点击“新建 Bottle……”（或者窗口左上角的加号），填些基本信息：

• 名称Name：自拟（为便于说明，后面用$venv表示）；
• 环境Environment：建议选自定义Custom。

应用程序Application和游戏Gaming这两个预设，初次新建 Bottle 时会下载巨量的依赖。 如果你网不是特别好，也没走代理，直接“自定义”就可以了。

• 打开共享用户目录Share User Directory选项
• 兼容层，或者说运行器Runner选择 soda-9.0-1（以最新版为准）

如果你选了预设，这里是改不了兼容层的，得等创建好 Bottle 之后进设置再改。

此外，cn 源的 Bottles 使用系统中装的原生 Wine。在文章开头我就强调过原生 Wine 已不适用红红。所以务必换用别的。

• Bottle 目录Bottle Directory可改可不改（为便于说明，后面用$bottles表示）。

默认你的环境位于~/.local/share/bottles/bottles目录下。

然后在右上角点击“创建”即可。

2.2 Bottle 选项

点击刚建好的 Bottle 进入详情页，点开设置Settings：

1. 需要开启 DirectX 翻译——将组件Components部分的 DXVK 和 VKD3D 打开；
2. 可以考虑在显示Display部分启用独立显卡Discrete Graphics（我的笔记本没有捏）；
3. 性能Performance部分的同步Synchronization可以考虑 Fsync，除此之外的选项建议不动；

做完设置，退回上一页把依赖Dependencies装上：

三、部署游戏环境

下载好《星辰之光》大版本包体（如有必要，额外再下载小更新包），用unzip解压：

sudo pacman -S unzip
# 请根据实际情况替换压缩包路径
unzip -O GBK -o '~/Documents/Extreme Starry v0.6.zip'
# 如果网络不好，不方便更新，并且群里恰有离线更新包，也可以直接下载、覆盖更新
unzip -O GBK -o '~/Documents/0.6.2 离线更新包.zip' -d '~/Documents/Extreme Starry'

然后点开你的 Bottle 进入详情页，为客户端Extreme Starry.exe添加快捷方式，这样就不需要每次都点“运行可执行程序”找半天了。

四、渲染补丁

我们知道，红警 2 是个 Windows 游戏，但众所周知，由于系统调用的不同，Windows 程序无法直接在 Linux 上跑，这点对于“渲染补丁”也是一样。 所以客户端设置也好，玩家自备ddraw.dll也罢，均无法在 Wine 里使用。

4.1 游戏本体

可能你会有疑问：前面不是让装cnc-ddraw了吗？怎么又有问题捏？因为文中的 Bottles 以及用于原生 Wine 的 Winetricks 均只提供这个。换言之，你基本上只有cnc-ddraw类补丁可以选。

除此之外，Bottle 容器与 Windows 类似，默认从游戏目录（即“内建Builtin”）加载 DLL。所以，还需要调整ddraw.dll加载次序。

• 找到 Bottle 详情的“工具”一栏；
• 点开Legacy Wine Tools找到Configuration，打开winecfg。
• 选中函数库Libraries页面，在列表中选中ddraw，点击编辑Edit；
  若找不到，先在上面的输入框里手打ddraw.dll，点击添加Add。
• 在弹出的 5 个选项中，选择原装Native (Windows)。

而对于 Reshade，国内有一些 Reshade 会伪装成d3d*.dll。由于上面提到的默认规则，这种 Reshade 实际仍能配合ddraw.dll运作，在游戏中显示出 Reshade 版本提示。当然具体特效显示成什么样就未经细致测试了。

4.2 FA2 及其扩展（FA2sp 等）

开篇提到，我还有做地图的需求。

目前圈子里所谓“FA2 防卡补丁”实际是 DxWnd，它仍会加载系统目录的ddraw.dll。那么对本随记而言，便只需讨论“原装”的 DDraw。经过测试，刚建好的 Wine 环境其ddraw.dll恰可以为 FA2 所用。

原生 9.16-1 那版对我来说刚好，但是无视缩放比；
9.17-1 及往后的新版本则会因屏幕缩放有一些拉扯感，不知高分屏用户觉得如何。
Proton 等 Wine 改版的表现与 9.16-1 一致。推测是并未跟进最新版本。

那需要做的就很简单了：另起一个 Bottle 跑地编。或者，在cnc-ddraw安装之前先提取出$venv/drive_c/windows/System32（也可能是SysWOW64，如果有的话）里面的ddraw.dll，覆盖 DxWnd。

五、开玩

在做完全部配置之后，点击你建过的快捷方式右边的▶图标，开耍。……虽然，读条可能会比较慢。

附录：关于 Syringe 命令行

Linux 的文件名允许英文引号（如"game"md.exe），在终端里，这会给 Syringe 带来歧义：

Syringe.exe "\"gamemd.exe\"" -SPAWN ...

解法也很简单，把它扔进批处理即可：

PUSHD %~dp0
Syringe.exe "gamemd.exe" -SPAWN -log -cd -speedcontrol

然后把批处理扔进游戏目录（或者说和gamemd.exe放在一起），让 Wine 去启动批处理即可：

# wine 运行时会把 Linux 根目录挂载到 Z 盘。
wine cmd /c "Z:/home/agxcoy/Documents/ES-FA2/launch.cmd"

在此感谢岛风 @frg2089 指路。

UEFI 启动简述：启动项管理

UEFI 规范定义了名为“UEFI 启动管理器”的一项功能……（它）是一种固件策略引擎，可通过修改固件架构中定义的全局 NVRAM 变量来进行配置。启动管理器将尝试按全局 NVRAM 变量定义的顺序依次加载 UEFI 驱动和 UEFI 应用程序（包括 UEFI 操作系统启动装载程序）。……

——（译）UEFI 启动：实际工作原理

本“议题”只讨论 UEFI 原生启动项和回退路径启动项。恕不对 BIOS 兼容的部分作详细展开。

i. 原生启动项

用 Windows 7 及更高版本系统的朋友肯定知道这个东西：Windows Boot Manager。bootmgr它代替了ntldr，从此便沿用至今。

事实上，Windows Boot Manager 是系统安装完成后，初次加载系统时为其创建的原生启动项。它明确指出需要启动指定设备中的指定引导文件（即bootmgfw.efi）。

即便 WinToGo 也是如此——在以 U 盘身份进入 WTG 系统时，Windows 也会悄悄地把原生启动项建立好。然后重启之后再按快捷键进入启动菜单，你可能会在部分主板上发现有两个启动项，指向同一个设备：

Windows Boot Manager ( Koi Series Pro ...)
USB HDD: Koi Series Pro ...

需要注意的是，原生启动项是存储在主板里的（更准确的说，是全局 NVRAM 变量）。有些主板在检测到原生启动项失效（找不到指定引导文件）后，会自行删除该启动项。比如安装 Grub 后更换过硬盘，后来又把原盘插回去，可能仍然找不到 Grub 启动项。

ii. 回退路径启动项

对于 WinPE、Windows 安装镜像而言，它们并非用于长线运行，不可能到处添加原生启动项，那么 UEFI 如何认出它们捏？ 还记得上面提到的同一设备双启动项吗？UEFI 固件是能够找到可启动设备，并且尝试启动的。但它是依据什么去找的捏？

UEFI 固件首先会遍历各硬盘的 ESP 分区，并在其中查找\EFI\BOOT\boot{cpu_arch}.efi。前面的这一固定路径就称为回退路径，通过查找回退路径建立的启动项就称作回退路径启动项。其中，cpu_arch即 CPU 架构，已知的有：

• x64：x86-64
• ia32：x86-32
• ia64：Itanium
• arm：AArch32，即 arm32 （胳膊 32）
• aa64：AArch64，即 arm64 （64 条胳膊）

如果同一硬盘、同一 CPU 架构存在多个匹配的 EFI 文件（比如，可能有两个 ESP 分区，分开装不同系统的 EFI），那么只会选第一个有效的去执行。

对于 WinPE U 盘，通常它们是 MBR 分区表，那么会考虑更泛用的搜索：采用 FAT 文件系统的活动分区； 对于 GPT 分区表，可以直接搜索 ESP 分区。当然如今的主板并不会卡那么死，哪怕只是普通的 FAT 分区，也会尝试搜索、执行。

也就是说，哪怕原生启动项意外被固件扬了，只要还有回退启动项，便仍可从同一个硬盘启动系统。

启动加载器（以 Grub 为主）

这也是最广泛使用的启动方式 ，Windows 也干了。在 Linux 当中，最常用的加载器是 Grub。当然，也有使用 rEFInd 的。

启动加载器（bootloader）本身作为跳板，被 UEFI 固件加载后，需要根据配置找到真正的 Linux 内核，并经由内核引导用户硬盘上的 Arch 系统。而在 Windows 中，boot[a-z]{3,4}.efi会根据BCD配置文件，执行硬盘其中一个 Windows 副本中的winload.efi，并将该副本的其余加载流程交给它完成。

正常使用 Windows 单系统的用户可能对启动过程并无察觉，但一旦与 Linux 混用，你就需要留意 Linux 的加载器会不会被 Windows 刷下去（甚至被覆盖）。除此之外，固件和内核之间隔着加载器这么一块跳板，势必会拖慢引导流程。因此就个人来说，我不会再考虑 Grub 这类方案了。

i. 修复 Grub 引导

Windows 启不动我们会尝试修复引导，Arch 亦然。修复 Grub 引导实际上就是重走 Grub 安装流程：

• mount挂载相应分区；
• genfstab重建挂载表（如有必要）；

个人建议无论如何都重建一遍fstab。反正刷完绝对是最新的。

• arch-chroot切换进硬盘上的系统；
• grub-install重建 grub 引导。
• grub-mkconfig重建 grub 配置（可能不需要……？）。

ii. 改用回退启动项

事实上，需要反复重建 Grub 引导的一大原因就在于，Grub 只会写入它自己的grubx64.efi，以及原生启动项：

那么办法也很简单：像 Windows 那样也建一个回退路径启动项。最简单的做法当然是复制改名，若求稳妥可以考虑用grub-install刷：

grub-install --target=x86_64-efi --efi-directory=/efi --bootloader-id=GRUB --removable

当然如果是像图中那样不止一个 Grub，甚至同盘 Windows 和 Arch 双系统，那我不推荐你这么做。

固件直接引导（EFIStub）

Grub 本身写入 ESP 的内容不多，配置啊、Linux 内核啊都在/boot。有人便主张把/boot还给/，ESP 分区实际挂载/efi。 而岛风则提出了更激进的主张：让固件直接引导内核。

An EFI boot stub (aka EFI stub) is a kernel that is an EFI executable, i.e. that can directly be booted from the UEFI.

——Arch Wiki: EFIStub

根据 Wiki，默认情况下 Arch Linux 的内核本身就是可启动 EFI，只是需要附加内核参数：

# 为便于阅读，这里分了三行。
root=UUID=7a6afcd0-a25a-4a6c-bf7b-920b53097eae
resume=UUID=b84ae173-edbc-442c-b00b-5c47eef203f1
rw loglevel=3 quiet initrd=\intel-ucode.img initrd=\initramfs-linux.img

LiveCD 里的efibootmgr工具可以直接操作固件的启动项。当然若是遵照律回指南和 Miku 指南，那么efibootmgr业已安装到你的系统中，你可以在运行中的本机 Arch 系统中折腾：

# 首先确定你要操作的硬盘和分区，不要搞错。UUID 马上就会用到。
lsblk -o name,mountpoint,uuid
# 参见 Wiki，以 Btrfs 为例，仅供参考
sudo efibootmgr --create --disk /dev/nvme0n1 --part 1 \
  --label "Arch Linux" --loader /vmlinuz-linux \
  --unicode 'root=UUID=f6419b76-c55b-4d7b-92f7-99c3b04a2a6f rw rootflags=subvol=@  loglevel=3 quiet initrd=\intel-ucode.img initrd=\initramfs-linux.img'

归根结底，EFIStub 代替了启动加载器，由我们用户手动建立 UEFI 原生启动项。但这种方式硬要说优点吧……可能也就比 Grub 快那么几秒而已。维护起来并不比 Grub 轻松多少。

统一内核映像（UKI）

在应用 EFIStub 的时候我就在想，有没有可能写一个bootx64.efi，直接带内核参数启动vmlinuz-linux呢。后面偶然找到了“统一内核映像”的介绍，豁然开朗。

A unified kernel image (UKI) is a single executable which can be booted directly from UEFI firmware, or automatically sourced by boot loaders with little or no configuration.

——Arch Wiki: Unified Kernel Image

根据介绍，UKI 实际上就是将内核引导的资源整合起来，打包而成的 EFI 可执行文件。某种意义上这也算是一种「固件直接引导」，只不过 EFIStub 只创建原生启动项，而它两种启动项都可以做。

接下来以mkinitcpio为例。

i. 内核参数

Wiki 中介绍了两种方法：

• 向/etc/cmdline.d/里投喂.conf配置（文件名随意）。比如root.conf决定/如何挂载，等等。
• 直接把所有参数搓成一行 echo 喂给/etc/kernel/cmdline文件。

于我而言，显然第二种更方便。

# 我在 LiveCD 里 arch-chroot 进去做的。别问我为什么没权限。
echo 'root=UUID=... resume=UUID=... rw loglevel=3 quiet' > /etc/kernel/cmdline

与 EFIStub 不同，这里不需要指定initrd=——工具会自己打包。

ii. 预设文件

编辑/etc/mkinitcpio.d/linux.preset。

#PRESETS=('default' 'fallback')
PRESETS=('default')

#default_config="/etc/mkinitcpio.conf"
#default_image="/boot/initramfs-linux.img"
#default_uki="/efi/EFI/Linux/arch-linux.efi"
default_uki="/efi/EFI/BOOT/bootx64.efi"
default_options="--splash /usr/share/systemd/bootctl/splash-arch.bmp"

本身 UKI 默认是丢到esp\EFI\Linux\arch-linux*.efi里的，相对来说已经比较通用（Grub 可以直接读，也可以用作原生启动项）。但我尝试 UKI 本就是为了摒弃前面两种方案，殊途同归反倒不值得这么整了。所以我个人选择让 UEFI 固件直接加载回退路径启动项。

iii. 创建映像

按需建立路径，并跑一遍生成：

mkdir -p /efi/EFI/BOOT/
mkinitcpio -p linux

如有必要，清理系统中废旧的启动文件（grubx64.efi、refind_x64.efi等），并用efibootmgr手动清理遗留的原生启动项。

建完之后退出系统，重启按快捷键进入启动菜单，这下该有你硬盘的 UEFI 回退路径启动项了：

HDD: PM8512GPKTCB4BACE-E162

最近也是经历了许多烂事，我也好久没有机会去维护自己的博客了。既然 Ag 这个网名也终于启用，我想是时候补全一下那三个基于化学元素拟定的网络形象了。

钙

• 生命周期：2017-2021
• 种属：兽娘·猫郎^[1]
• 瞳：青绿，猫瞳
• 代表色：白
• 性格：内向
• 配偶：Cl（氯）
• 喜欢的：苹果；尝试、摸索、折腾
• 讨厌的：阅读理解（

最早启用的设定。虽然理论上任何钙离子组成的盐都可以指代我，但中学阶段最常见的沉淀果然还是 CaCO₃ 吧。然后“碳酸钙摘掉两个氧”，最初的名字——Caco 就确定下来了。后来又衍生出音译“卡扣”、Casheen 和相应音译“卡伸”。
老朋友们大抵还是愿意叫我“卡”这组名字，特别是接触过的红警 2 modder 和地图师。

猫少年啊……说实话现在回头想想，可能是受到初中同好的影响也说不定。不过印象中被说“可爱”确实是很早就开始了。（话说真的可爱吗？）
总之上图已经是我能找到尽可能完整的立绘了，看上去不需要额外添几笔细致的外貌描写。

“他呀……是个很可爱的家伙呢。初见看着很腼腆，相谈甚欢了又开始滔滔不绝，和我独处又脸红得像熟透的苹果一样。
“hmm？当初怎么认识的啊……说来有点搞笑。他一开始的个人简介整了个莫名其妙的反应方程，然后我看着好玩就和他聊上咯。再然后？嘻嘻，自己猜去。
“搞起熟悉的东西来能心无旁骛搞个通宵……啧，有时候还挺羡慕他的。但…再怎么说也稍微陪陪我啊。明明他自己也很喜欢抱抱的说。
“唉，明明说好了做我的专属的……到头来还是把我抛下了嘛……”

——ChlorideP

氯

• 生命周期：2022-2025.3
• 种属：幽灵（♀）
• 瞳：黄绿，类人瞳孔
• 代表色：黄绿
• 性格：寡言、孤僻
• 配偶：Ca（钙）
• *伴侣：Ag（银）
• 喜欢的：听故事和讲故事
• 讨厌的：毫无营养的信源

在 Caco 因故被一小撮原神同人女散兵厨攻击之后不久，钙的形象弃用，咱也随即改名为 Chloride Pussemi，即 ChlorideP 了。而后有人因为末尾这个 P 以为我是 VOCALOID 曲师（P 主），加上这个昵称全小写起来并不方便手写，遂又更名为 NyaCl.

氯的种属启发自氯单质（氯气）的物理性质。作为气体，它是有在空中的那种飘浮感的，不难想到幽灵也是在空中飘飞的存在。于是就决定是“黄绿色的幽灵”这样的形态。上图是 Q 版氯，其实还有一版正式立绘，是个大姐姐的形象。可惜弄丢了。

后来经历的一些事情让我的精神状态逐渐贴合氯气的化学性质：有毒、刺鼻。有时候的确觉得自己到处倒垃圾很困扰人；应激起来说话很大声，不也挺“刺”耳的。（苦笑）

“你说她？我的食物罢了。知不知道一颗电子对阳离子来说有多么诱人？
“刚找上她的时候她还在郁郁寡欢呢。结果呢？还不是顺从本能乖乖交粮。（舔唇）
“不过还别说，强氧化的元素就是不一样，比什么碳酸根的美味多了。听说她已故的另一半也和碳酸根有点关系？乐。
“后来一来二去的，她似乎也走出来了，愿意和我一起贴贴……嗯哼，就这点来说我还是很喜欢她的。
“最后倒是和她贴了个痛快。不知道她觉得如何，我是觉得她这结局挺好的。好歹舒服地享受完最后一刻。
“就是可惜……再也找不到这么好的食物咯……（叹气）”

——SilverAg.L

银

• 生命周期：2025.4-
• 种属：兽娘·猫娘（亚种，魅魔混血）
• 瞳色：粉红，爱心瞳
• 代表色：银白（亮白）
• 性格：对外满不在乎，私底下很细腻
• 喜欢的：涩涩（无论主动被动）
• 讨厌的：烦心事

银这个设定实际上直到去年才给她勾个轮廓——白丝魅魔猫娘少女。乍一听这四个词组合在一起很违和。说实话我也觉得（

相比前面两个反映我不同时期的、特点鲜明的自设，“银”这一形象就相对一以贯之，同时又很随性了。大约在初中我就误入当时流传的所谓“本子库”^[2]，所以涩涩也算是我一直以来的隐藏属性，如今启用这个自设也有种借谐音梗的题发挥的意思。

至于这个轮廓为什么这么左右脑互搏，只能说是基于自身经历导致的历史惯性吧。钙设是猫少年嘛，加上我认识的老朋友们普遍爱发猫猫表情包，所以我的口癖不可避免地也倾向于喵来喵去，忽然摘掉“猫”这个元素反倒不知道怎么表达了（毕竟我做不到真像魅魔那样妩媚）。但我又希望能够突出涩涩的要素，所以最终形象就是点缀上白丝、魅魔尾巴、猫耳猫爪的少女啦。但自己想象的时候感觉更像雌小鬼一点（）

设定上魅魔尾巴非常敏感，只是碰触就会浑身战栗的程度。若是摸上那么一两下说不定就开始发情了吧。

“你是怎么看我的呢，氯喵？你会要我吗？
“好想再被你抱着……抱在怀里，就像…就像……”

——Ag

后记

事实上我确实没想过它们之间会有什么社会关系，毕竟本质上都是我在网络上的皮套而已，它们都是我，却又不完全是。但真的做出决定，“既然我本来就没活，索性把身为创作者的我，叫做‘氯’的我给埋葬了吧”，这么做的时候，我的内心还是会觉得痛苦，仿佛真的失去了重要的人一般。

基于这样的感情，我才决定写下这一篇随笔，完善这几个自设的形象。至于每个设定底下的自白，更多地是对友链 PR 里的小对话做一个扩写，很抱歉我并不擅长写一个完整的故事，只能像这样侧面地刻画 CaCl₂ 和 AgCl 这两对之间的亲密关系。

不论钙、氯还是银，都是我精神世界的投射，也都寄托了我的愿望或是欲求。也许我就是很享受被人家说可爱呢？哪怕最终只是在博客里发癫、写一篇篇的碎碎念。

• Zero-Fanker：Ares Wiki
• 王道论坛：2023 考研 408 学习资料

背景

FA2sp 是为了改善红警 2 地图编辑器 FinalAlert2（下面简称 FA2）的使用体验而开发的扩展库。它通过 Syringe 注入 Hook 的方式，无需修改 FA2 本体便能享受到扩展的功能和修复。

2024年3月8日，EA 在发布 Steam 版红警 2 时，终于把 FA2 的源码放了出来，自此 FA2sp 完成了历史使命。彼时我的考研刚刚坠机，本着“用进废退”的思想^[1]，我打算温习下学习 408 得来的船新经验：寄组的汇编和操作系统的进程并发。于是才疏学浅的我结合自学来的粗略理解，尝试研究 FA2sp 项目作者 @secsome 留下来的逆向成果——finalalert2yr.exe.idb。

复习一下寄组

寄存器

除了考研常考的通用寄存器e[abcd]x、帧指针ebp栈指针esp外， 在遇到 Fatal Error 时，我们还重点关注except.txt里的eip寄存器：

EIP: 00534096	ESP: 013A89D4	EBP: 013A89FC
EAX: 00000000	EBX: 00886240	ECX: 00886240
EDX: 003F5000	ESI: 00886230	EDI: 2A3C0000

在 FA2sp 里，这些寄存器可以通过 Syringe Hook 定义里的REGISTERS *R指针参数存取。

跳转汇编指令

常规：Jump 系列

分为 jmp 无条件跳转，和 jcondition 有条件跳转两种。其中条件跳转可以部分参考 pwsh 的比较：

在 IDA 中，jmp j...通常跟的是标签（如LABEL_20），标签用于指代某一个虚拟地址（32 位程序基址0x400000）。 跳转指令认出标签指代的地址后，将 EIP 寄存器设为该地址，CPU 从那里继续取指、间址（可能跳过）、执行、中断（可能跳过）四部曲。

特殊：函数调用

主要是call和ret这一对。

call lbl是父级函数去“调用”。它会把函数参数、下一指令地址压入栈，然后无条件跳转到lbl标签指代的地址（同时改变 EBP 的值，以便建立新的栈帧）；

相对的，ret是子函数要“返回”。在回收子函数栈帧、还原 EBP 之后，ret指令会无条件跳转回先前执行到的位置。

int eg_sub(int x, int y) { return x * y; }
int example() {
  int a = 10;
  int b = eg_sub(a, 1024);
  return b - a;
}

push ecx     # 设 a=10 位于 ecx
call eg_sub  # 函数调用，返回值在 eax
mov ebx, eax # 假设 b 在 ebx，把返回值赋给 b

push ebp
...
mov ecx, [ebp + 12]  # 假设 ecx 存 y
mov edx, [ebp + 8]   # 假设 edx 存 x
...

寻址方式

上面讲栈帧出现了个[ebp + 12]，涉及到两种寻址：寄存器间接寻址和 EBP“相对寻址”。

首先是 EBP 寻址。进程由操作系统管理，其堆栈空间在内存中开辟。既然如此，EBP 和 ESP 的值实际上就是指向内存中栈空间的地址。 比如在上面「栈帧」里举的例子，执行example()函数主体时，[EBP]=0x520，[ESP]=0x504； 进入eg_sub()函数调用后，[EBP] 则变为 0x500。

于是，我们可以对栈指针 ESP 和帧指针 EBP 做加减运算，找出函数参数、局部变量等信息。 例如上面建立eg_sub的栈帧时把函数参数从栈里读出来（不是pop出栈），就用eg_sub的 EBP 往上加。 由于两个栈帧之间总隔着一个“返回地址”，所以第一个参数并不是+4，而是+8。 而相对的，访问局部变量可以用 EBP 往下减，EBP - 4，EBP - 8，之类的。

通常来说，ESP 容易受pop push指令的影响，比较“多动”；而 EBP 相比起来更“安稳”一些。
当然 ESP 寻址肯定是有的，Syringe 里的XXX_STACK就是 ESP 寻址。只是 EBP 寻址我讨论起来方便。

其次是寄存器间接寻址。对 EBP 指针做加减运算，找到参数、局部的地址之后，还需要做一次间接寻址，去内存里把真正的数据抓出来。
间接寻址不需要你操心，我只是让你注意寄存器旁边的中括号而已：

mov eax, ebx    # 把 EBX 寄存器里的值直接传给 EAX
mov eax, [ebx]  # 把 EBX 里的内存地址取出来，再读那个内存地址，把数据传进 EAX。

初探 IDA

案例

FA2 的“国家”和“所属”是靠后缀区分的，国家直接取自 Rules*.ini，所属则是在国家基础上添加了 House后缀，比如国家YuriCountry和所属YuriCountry House。
默认在触发编辑器属性页里，触发所属方会截断空格，只许你选“国家”。现要求把这个碍事的截断给干掉，方便我们实现多人合作地图的“所属”关联。

逆向分析

void CTriggerOptionsDlg::OnEditchangeHouse()
{
    // ... 前面忘了

	CString newHouse;
	m_House.GetWindowText(newHouse);  // 实际是 GetWindowTextA

	// FA2 读完所属会用 CSF 本地化这些窗口控件的所属名字（但是非常鸡肋）
    // 这一步又把本地化的所属翻译回 INI 的所属 ID
	newHouse=TranslateHouse(newHouse);

	newHouse.TrimLeft();
    // 如果你英语好一点，空格 => space，你便已经找到要淦的位置了：
	TruncSpace(newHouse);

    // ... 后面忘了
}

void TruncSpace(CString& str)
{
	str.TrimLeft();
	str.TrimRight();
	if(str.Find(" ")>=0) str.Delete(str.Find(" "), str.GetLength()-str.Find(" "));
}

开始之前赞美一下书伸，书门！（
没有书伸的成果，我不可能很快找出待修改函数的虚拟地址。

在 32 位 IDA 里新建一个反编译项目，打开 FA2 的主程序。我们案例要淦的函（方）数（法）位于0x501D90，在菜单栏Jump里找到Jump to address，把这个地址复制进去确认。
默认它会切换为 Graph View，你需要右键改为 Text View：

往下翻到.text:00501E58，注意到GetWindowTextA这个 WinAPI。如果你翻看了上面的源码，就会发现我们离目标不远了。

借着上面的提示，同屏GetWindowTextA后面只剩两个怀疑对象：sub_43C3C0和sub_43EA90。

接下来看看这两个嫌疑函数的特征。直接菜单栏View，Open subviews，Generate pseudocode (F5)生成反汇编代码，于是我们得到案例方法的 C 式伪代码：

由上面的源码可得，截断空格的函数TruncSpace只有一个参数，至此我们确定是sub_43EA90背锅。

编写 Hook

目前我已知两种 Hook 用法，我们这里写的 Hook 是第二种用途：

• 在原函数里新增内容实现扩展（return 0）
• 绕过（或覆盖）原函数的执行流程（return到目标地址）

背景芝士：Syringe

Syringe.h提供了定义 Hook 的宏：

#define EXPORT_FUNC(name) extern "C" __declspec(dllexport) DWORD __cdecl name (REGISTERS *R)

#define DEFINE_HOOK(hook, funcname, size) \
declhook(hook, funcname, size) \
EXPORT_FUNC(funcname)

更详细的介绍可以翻 Zero Fanker 的 Ares Wiki。这里只需要知道，写 Hook 靠DEFINE_HOOK准没错。
然后解释一下DEFINE_HOOK这个宏要补的三个参数：

• hook：即你要灌注（覆盖）的地址。

毕竟你外部定义的 Hook 不可能凭空插入原程序里，肯定需要遮掉原有的一部分指令机器码，才有机会跳转到你的 Hook。

• funcname：即你的 Hook 名字。

• size：即 Hook 覆盖多少字节的原函数指令码（bixv >= 5B）

注意事项

我们这里针对的是函数调用，需要注意 C++ 的函数执行完成后会触发栈区局部变量的析构函数（通常是空间回收），因此并不建议把传参的汇编指令也给覆盖掉。

就这个例子而言，只需覆盖call指令：

实战

都有现成项目 FA2sp 了，你不会想着要白手起家吧？

在 FA2sp 项目里依次打开FA2sp\Ext\CTriggerOption，在Hooks.cpp里添一个 Hook：

DEFINE_HOOK(501EAD, CTriggerOption_OnCBHouseChanged, 5)
{
  // 这里什么都不用做，我们只是跳过 FA2 截断空格那一步而已。
  return 0x501EB2;  
}

由于declhook宏设置 Hook 位置时已经标了0x（可以在 Visual Studio 里把鼠标移到宏上面预览展开的代码）， 这里DEFINE_HOOK后面设置的地址就不需要再补0x了。

补充

REGISTERS 寄存器类

在上面的「背景芝士」中，注意到导出的 Hook 函数只有一个REGISTERS类的指针参数 R。
有时我们会需要获取原函数的实参、局部变量等信息，并加以修改，这时就要靠 R 指针获取了：

进阶知识：Hook 函数的用法

具体的例子还要结合已有的idb逆向成果自行意会。虽然函数调用的基本原理在计组那一块已有涉及， 但一个函数叫什么名字、里面什么寄存器对应什么变量，这些都是前辈们自行逆向出来的结论。对此，咱还是保留点最起码的尊重罢。

观前注意

由于涉及一些编程知识点，本文可能存在亿些阅读困难。 虽然经过与 Zero Fanker 等人的讨论后决定做些修缮重写，但难免仍有需要改进之处。

绪论

研究背景

红警 2 的地图创作中，流程设计是战役最重要的一环，其中触发发挥着举足轻重的作用。好的剧情流程能够让人印象深刻，如何用触发设计出好的流程，就得凭借地图师们的逻辑智慧了。但长久以来，红红的地图教程偏实用性居多，大多数地图师对触发并没有明晰的认识，他们或许在脑内对任务流程有着天马行空的设想，但落到触发实现上往往束手无策。

本文基于已有的触发和编程实践，尝试阐明触发组件的运作逻辑，并就这套系统的一些缺陷提出个人的见解，希望能够对各位读者有所启发。如果能稍稍地推进触发设计的简化事业，那就再好不过了。

研究目的与意义

本文旨在用程序化的思想阐述触发的运作逻辑（而非原理，更不是底层原理），指出这套系统存在的逻辑缺陷，并试着给出可行的解决思路。通过对触发逻辑的分析，用不同的视角去看待触发，或许可以一定程度上简化触发的表达，增强地图师们的逻辑思维，启发他们对优秀设计模型（如状态机）的借鉴、化用，提升剧情的观赏性，为观众们带来更多精彩的“剧目”吧。

必须指出的一点是：逻辑与实现并不等同。逻辑关心客观事物的本质、规律，实现则关心符合这个规律的解决方案。

一、触发组件相关概念

1.1 触发

地图触发是早在《命运与征服：泰伯利亚黎明》就引入的系统，负责处理地图当中的“事件”¹。

一局游戏瞬息万变，其中总有一些既成的、游戏引擎能感知的事，叫做事件。比如什么关键建筑被打爆了啊，哪家缺电缺钱了，等等。 这些事件会被触发捕捉到，并驱动后者去执行相应的行为，也就是游戏引擎能做到的各种效果：可以是刷兵，改变光照，炸个桥，平地起心灵信标……诸如此类。

再次强调，捕获到的事件、要执行的行为，都仅限引擎能做到的范围之内。

有一些地编调整过用词，事件改称“条件”，行为改叫“结果”。你可以简单这么理解。

1.2 局部变量

变量系统则在《命运与征服：泰伯利亚之日》才开始出现，根据[VariableNames]小节所处的位置不同， 分为 Rules 里的全局变量，和地图里的局部变量²。本文主要讨论局部变量。

在地图创作中，局部变量就是对设计者有具体意义的，会因触发（和动作脚本）做出改变的，临时在某一局游戏起作用的数值。

值得一提的是，从原版一直到 Ares 扩展平台，局部变量均有如下限制：

• 存在数目上限：至多能设置 100 个；
• 取值范围有限：变量的值只能为0（清除）和1（设置）两种。

一直到 @secsome 在 Phobos 平台扩展了变量系统之后，上述限制才被打破。

参考链接： pr#321, pr#424, pr#425.

二、触发组件的程序逻辑分析

2.1 触发的逻辑本质

提及触发，各位地图师看过教程、初步上手后应该会建立这样的基本印象：

• 触发有一定前置事件。
• 触发指明了执行行为。
• 触发要等前置事件（条件）完成，才会执行相应行为，表现出各种结果。

比如简单的延时字幕，你确实需要等上那一段时间，然后才会冒出来一句“必须重新集结部队”。

这种“等待条件”的现象与高中数学讨论的“若 p 则 q”命题（即条件命题）非常类似。一个条件命题要能判断其真伪，条件就必不可少；同样的，一个触发要能执行，首先要等待前置事件完成。在程序框图中，像这种具有前置条件的语义用条件分支表示（如下图），又称选择结构。

从游戏实际运行的现象来看，触发会在条件满足（为真）后执行相应的“处理程序”（也就是行为），这一点符合基本印象。而当条件尚未满足时，触发则阻塞等待。
假如逻辑上就是希望判断条件不满足（为假），由于触发一直等不到条件满足，则直到游戏结束为止这个条件都得不到任何处理。如此看来，触发的逻辑本质就是如上左图的条件单分支结构。

而在程序语言里，这种条件单分支常用if表示：

if condition:  # 条件
  do_sth()  # 结果

在这段代码中，只有当条件condition满足（为真），才会去走do_sth()那一步，执行出结果来。 而触发也是等到条件满足，才会执行结果。既然如此，抛开触发的所属、难度开关等等其他属性，不妨就把一个触发当成这种if结构。

至于事件condition和行为do_sth()，事实上它们可以不止一条。多条件姑且不论，有些朋友可能很喜欢在单一触发里塞十几条结果。 那么多个条件、多个结果之间是如何串起来的呢？你可以自行翻阅各扩展平台的 YRpp，或是在 FA2 等地图编辑器中实验一下，这边就直接说结论了：

• 多个条件之间以逻辑且（AND）连接，所有条件必须全部满足，才可以执行对应的结果；
• 多个结果之间形成队列按序执行，但因为每一条结果执行耗时很短，表面上看似乎是同时完成。

至此，可以用这样的伪代码描述一个触发的 $p_1 \land \ldots \land p_n \to Q$ 逻辑了：

if event1 and event2() and ...:
  action1()
  action2()
  ...

01019810 = len_actions, a1_type, a1p1, a1p2, ..., a1p6, a1_wp, a2_type, ...

class TActionClass : public AbstractClass {
public:
	TriggerAction      ActionKind;  // aX_type
	union {
		RectangleStruct    Bounds; // map bounds for use with action 40
		struct {
			int Param3;
			int Param4;
			int Param5;
			int Param6;
		};
	}; // It's enough for calling Bounds.X, just use a union here now. - secsome
	int                Waypoint;   // aX_wp
	int                Value2; // multipurpose  // aXp2
	int                Value; // multipurpose   // aXp1
};

bool TActionExt::EditVariable(
  TActionClass* pThis, HouseClass* pHouse, ObjectClass* pObject,
  TriggerClass* pTrigger, CellStruct const& location)
{
  // blabla
  return true;
}

2.2 顺序结构

顺序结构是最简单、最基本、最符合思维直觉的结构。大部分战役任务的流程也都是线性、有序的流程。以被广为改编的《脑死》为例，它的任务流程具有很典型的顺序性：

1. 建立一座锅盖苏军雷达
2. 超时空援军就位后，摧毁最后一座心灵控制器
3. 秋风扫落叶，清除残余敌军。

在线性系统中，按时间先后执行的流程我们认为就是顺序结构³。

然而两个触发之间常常在宏观上表现为异步：同样都是延时 10s，A 触发和 B 触发看起来好像是同时执行、互不相干的。那要如何保证顺序呢？ 一个简单的办法是用行为 53 允许触发。假定有两个触发 $t_0$ 和 $t_1$，要求先触发 $t_0$ 后触发 $t_1$。只需在触发编辑器里完成如下步骤：

• 为 $t_1$ 触发勾上“禁止”选项；（$t_0$ 无需再做处理）
• 在 $t_0$ 触发的行为（或者结果）页面中，添加一项（行为类型选中 53，参数选择 $t_1$ 触发）。

如需链式允许一系列触发，比如 $t_1 \to t_2 \to \ldots \to t_n$ ，也是如法炮制。以此类推，就形成触发链：

而在程序代码当中，顺序是通过代码行的先后次序来体现的：

x = input("输入 x：")
y = input("输入 y：")
print(x + y)

可以很清楚地看出，这段程序先读入x，后读入y，最后输出它们两相加 （实际上是拼接） 的结果。自上而下、逐行执行，这就是程序代码的顺序结构。

从 2.1 一节的讨论可知，触发在逻辑上可以表达成if单分支的伪代码。那么不妨将这些if也按照地图师期望的顺序，自上而下地排列起来：

# t0. start
if anyEvent:  # P8 任何事件（当*单独使用*时，它会令触发*立即执行*）
  lock_input()  # Q46 禁止用户输入
  play_speech("EVA_EstablishBattlefieldControl")  # Q21 播放 EVA 语音

  # t1. intro.brief.A
  if elapsedTime(6):  # Q13 流逝时间
    text_trigger("mission:naosi_A")  # Q11 文本触发

其中，$t_0$ 触发的条件是anyEvent。结合右边的注解和前面对于if执行过程的讨论，这个条件肯定是恒满足的，也就是为真（True）。

上述代码段的排布与前面的案例一致，$t_1$ 是排在 $t_0$ 后面的，这样 $t_1$ 必定会等 $t_0$ 先触发；除此之外，$t_1$ 还往右缩进，与 $t_0$ 的那两条结果对齐，意味着 $t_0$ 不触发时，绝对不会触发 $t_1$，以此避免独立触发和触发链的歧义。

但随着触发链越来越长，这种层层缩进的形式也会因为不同结果的穿插变得混乱不堪。除此之外，这种表示也很难解释行为54 禁止触发。由于本人水平有限，如何解决这些缺陷、让逻辑表达更贴近 Q53、Q54 的表述，就权当是留给有兴趣的读者一道思考题吧。

2.3 循环结构

早期扩展平台对于屏幕界面的利用并不充分，地图师只能每隔一段时间在屏幕左上方提示玩家当前的任务目标。那么像这种需要重复执行同一个流程的结构，就叫循环结构。

对于循环结构，已知的触发教程大概会让你关注触发的「重复类型」：

通常来说，选择 2 - Repeating OR 那一项便足以满足很多简单的重复需求。

而在程序代码中，while循环则取代if扮演这个执行重复主体的角色：

while True:
  print("Hello World")

将上述代码粘贴进 Python IDLE 回车运行，你也能看到终端里打出来一行行Hello World，除非用任务管理器干掉这个进程，否则它会无休止地输出下去。

分析这个运行表现不难发现，它是类似下图图二的流程：首先它走到while处执行判断，由于条件恒满足，往下执行print；然后循环并没有结束，它重新回到while重复执行前面说的流程，将坏掉的乐土打字机事业推进下去爱莉希雅死辣。

上面的Hello World案例也是类似图二的流程。于是，重复触发可以用while循环表示：

while elapsedTime(6):  # 每隔 6 秒
  text_trigger("mission:naosi_enemyarmada")  # 输出文本
  reinforcement("01014514")  # Q7 援军（小队）

2.4 线性多分支选择结构

在触发设计中，有的时候还会希望在某一个节点，根据不同的情况分别做出不同的反应，这就涉及到了选择。选择结构是创建分支流程的重要组成部分，可用于实现条件发生变化时流程也随之发生改变的效果³。

选择结构其实前面 2.1 一节已经介绍过，并且基于触发运行的现象指出触发本质是“条件单分支结构”。由于存在阻塞等待，触发并不会主动判断条件不满足（为假）的情形，所以在实际应用中比起去实现双分支，地图师更倾向于关注多个条件分支之间如何组织。

当大量的选择结构简单串联之后，实际上就构成了线性多分支结构³。而在涉及到多个条件时，不同条件之间的关系也会影响选择结构的实际效果。具体来说，是互斥与否的关系。

互斥是说，这组条件分支不可能同时满足，因此必然只会运行其中一个处理程序。用程序语言来说，就是if-elif-else。比如用公式法求一元二次方程，不可能 $\Delta > 0$ 还说方程找不到实根。
非互斥是指，多条件中至少有两条同时满足，有可能同时经过若干个处理程序。比如说重叠区间：

• 若 $x \in (0, 233]$，则令 $x = -x$；
• （反之）若 $x \in (220, 512]$，则又令 $x = x^3$。

如果没有加上那个“反之”，考虑输入一个特殊值 $x = 230$：首先 $230 < 233$，$x$ 变换成 $-230$；随后 $230 > 220$，对 $-x$ 做幂运算得出 $-12,167,000$。
而一旦加上“反之”，上述处理就是互斥的：“反之”要求 $0 < x \le 233$ 这一条件首先不满足。对于特殊值 $230$，显然 $230 < 233$ 满足条件，$x$ 变成 $-230$ 就直接结束了。

由于触发的 $p \to q$ 语义无法通过逻辑上互斥实现选择，因此实践中更倾向物理实现这个互斥：一旦某一分支成功触发，就需要尽快阻止触发其他分支。实践中通常会考虑 Q54 禁止触发、摧毁选择器等方式，让用户来不及进入另外的分支。

比如近年来的子阵营指挥：设有三支部队分别从三个方向开进，你需要选择指挥其中一支。这种桥段通常会刷三个假单位充当选择信标，玩家选中一个就把那一路部队更改所属。那么这种情况会在玩家选择之后立刻摧毁其他选择信标（Q119 摧毁所属方）。

if objSelected(BeaconA):
  del BeaconA, BeaconB, BeaconC
  ...
# B、C 信标也是一样，就不再展开了。

非互斥的多分支实际上就是顺序地经过这些条件分支，如此便又回归顺序结构的处理方式。其中比较典型的设计类似数学上的“大、小前提”。 考虑一个争夺战：玩家与敌军互相争夺油田，但狡猾的敌军可能直接摧毁油田。假如有两个 Phobos 扩展局部变量充当计数器：

• remaining计算地图上还有多少油田。若余量小于玩家应占数目，任务失败；
• player_owns计算玩家占了多少油田。大于等于应占数目，任务完成。

那么当一个油田 P48 被摧毁 时，首先想到余量remaining减一。如果这个油田先前是玩家持有，那就再对player_owns减一。简单的允许触发即可：

if objDestroyed(OilA):
  remaining -= 1  # 编辑变量 (Phobos)
  if oil_A_captured and objDestroyed(OilA):
    player_owns -= 1

三、局部变量的程序逻辑分析

前面的分析都是基于触发系统本身，贴的代码也只是对假想条件和结果的调用。而在地图创作中，除了直接利用已有的条件库，还会用局部变量间接地做条件判断。为了讲清楚它如何参与到触发逻辑当中，不妨引入经典案例“运输船找妈妈”。

3.1 案例实现思路

“运输船找妈妈”简单来说，就是在乘客还有事要做的情况下，让运载乘客的载具打哪来，回哪去。观察一下 YR S01：时空转移的相关演出，易得流程如下：

• 满载的运输船从地图外刷出，移动到定点；
• 等待所有乘客下船。然后乘客有可能还会打光几秒、更改所属方……；
• 空载的运输船从定点返回地图外。

难点就在于，如何得知卸出乘客后船是空的。翻看条件库，好像也没有类似的选项。
于是考虑设apc unload变量初始为 0，然后在运输船卸出乘客之后Q56 设置局部变量，触发得知 P36 局部变量被设置 了，就建一个空船小队把它拉走。

3.2 案例逻辑分析

已知这一经典例子中运用了局部变量，那么引入局部变量后触发逻辑有什么变化呢？

首先考虑局部变量的位置。从语义、代码语法上说，不可能未经定义就使用一个变量——好比解应用题，只设了未知数x却凭空跑出个y来。

在 FA2 的局部变量窗口中，你需要为局部变量起名（声明），然后 FA2 默认会令它等于 0（初始化，当然你可以改这个初始值）。那么这些局部变量保存到地图里肯定也是带着初始值的。
这些局部变量最终又被引擎读进内存，组成数列（或者说数组）。所以，在游戏开始之前，这些变量就已经就位了。

那么不妨把局部变量放在程序代码的开头：

apc_unload = 0  # 多数编程语言并不允许变量名带空格
if ...:
  ...

既然声明了局部变量，那么就要用起来。触发里有一组事件和一组结果分别读写局部变量（设待操作的局部变量为 $x$）：

• P36：局部变量被设定（为 1），即当 $x = 1$ 时
• P37：局部变量被清除（0），即当 $x = 0$ 时

• Q56：设置局部变量（值为 1），即令 $x = 1$
• Q57：清除局部变量（值），即令 $x = 0$

那么上述案例便可以用如下伪代码表示：

apc_unload = 0

if elapsedTime(20):
  play_speech("EVA_ReinforcementsHaveArrived")
  reinforcement("LCRFCome")

if apc_unload == 1:
  create_team("LCRFBack")  # Q4 建立小队

触发就是通过对局部变量值的变动，来实现一些较为复杂的逻辑判断。并且随着 Phobos 扩展了变量系统，触发对变量的判断也不再局限于 0 和 1 的“左手倒右手”，而是与科技类型、超级武器、随机数等联系了起来，实现更加精细的随机机制和流程控制。

3.3 高阶用法：逻辑门电路

触发条件仅以逻辑“且” 相连。其阻塞等待决定了它没有类似“否则”的设计，也就莫得直给的逻辑“非”；已知的触发实践也表明，多条件不可能在仅满足其中一个的情况下执行触发，无法直接判断逻辑“或”。那是否说明，触发就是做不到逻辑完备，如同早期面对平台限制一样无解呢？非也。

事实上，依据软硬件的逻辑等价性原理，触发确实可以做到或、非逻辑的判定。但显然，用累加去实现相乘，比起直接列个竖式配合九九乘法表，总是麻烦得多。自行实现的或、非逻辑也一样。

3.3.1 门电路的搭建

“逻辑智能所有的基础，都不过是这小小的开关。”

——ElectroBOOM

在 1.2 一节中已知，原版的局部变量只有0和1两种取值，恰如一个“开关”。前面两个小节的实例分析也展示了局部变量作为“开关”，在触发系统中的辅助判断作用。有了开关，就可以人为建立起“或”、“非”，乃至更为复杂的逻辑通路。

我们不妨从先前一直遗漏的“条件双分支结构”入手。很显然，双分支摘去一支就退化为了单分支；反过来，双分支的真、假两路恰好是一个开关的两极。那么有没有可能，可以通过局部变量连结两个单分支，组合成一个“条件双分支”呢？这就是接下来要讨论的单刀双掷开关（SPDT）设计。

从 3.2 一节的介绍可以看出，触发是取局部变量的瞬时值做的判断，变量值为0还是为1是两个独立事件。既然逻辑上通过局部变量反映了条件的真假，不妨假设经过这个双分支时，该局部变量的值“保持恒定”，于是得出以下的实现思路：

# t0: if-else 双分支：条件判断器
if elapsedTime(114514) and ...:
  your_local_var = 1
# t1: 条件为真时的处理
if your_local_var == 1:
  ...
# t2: 条件为假时的处理
if your_local_var == 0:
  ...

注意前面 2.4 讨论多分支时，还提到要“尽快阻止触发其他分支”。在上面这个简单模型中，令 $t_1$ 第一时间“禁止”$t_2$，反过来也一样，就可以了。

事实上，不单是局部变量，像 YR A03：集中攻击那关争抢电厂的桥段，“电厂是否属于玩家”也可以采用 SPDT 设计，直接判断关联电厂的归属是敌是友，并相应地允许（或禁止）敌军反占电厂的演出。

像这样将条件映射到局部变量，用变量代为影响执行流的“逻辑电路”思想，接下来会多次体现。

3.3.2 或运算——殊途同归

如今的任务有一个利好玩家的设计：如果你实在没钱（假定低于 $100），或者你的矿车被打没了，就给你派送几个钱箱子救急，所谓“战争援助”。不妨以这个设计为例。

那首先判断“缺钱”是有现成事件52 金钱低于 的；至于判断“缺少矿车”，在原版中可反向考虑用事件20 生产特定类型的载具 判断玩家生产了矿车。如果任务流程足够简单，玩家和其他 AI 阵营绝不可能生产出相同种类的矿车，也可以用 YR 的事件61 科技类型不存在。

条件输入、结果输出两端都 OK，就可以用局部变量搭建“或门”电路了：

• 设一局部变量player low funds，初值为 0；
• 触发 $I_1$：若玩家*金钱低于* $100，则令该变量值为 1；
• 触发 $I_2$：若玩家补牛（没有牛车），也令该变量值为 1；
• 触发 $O$：若该变量值为 1，则在指定路径点刷出奖励箱子。

对应的伪代码如下：

player_low_funds = 0
if creditsBelow(100):
  player_low_funds = 1
if noMiner:  # 取决于你怎么判断玩家缺牛车
  player_low_funds = 1
if player_low_funds == 1:
  create_crate(0, waypoint=81)  # 参数写 0 表示*大量金钱*

“一真皆真”，这就是或门的精髓。当然 Python 里真正的or有短路特性，这里就不再展开了。

3.3.3 非运算——逆向思维

原版 RA2 A08 有这样一个任务流程：在心灵信标影响到谭雅之前摧毁心灵信标。换言之，要求指定时间内摧毁目标（也就是计时器没有超时，并且目标被摧毁）。

在开始之前，不妨先捋一捋这个条件组的逻辑。这实际上是个必要不充分条件：要保证完成流程，必需满足以下两个分条件：（一）没有超时，计时器没有走完；（二）目标被摧毁。但反过来，单纯“没有超时”推不出任务完成——目标可能还在。

由于目标被歼灭 这个分条件不需要非运算，因此重点关注 流程能完成 $\Rightarrow$ 没超时 这一分路。这一路条件按照设计得是真命题，原命题为真，其逆否命题也为真：超时了 $\Rightarrow$ 流程完不成。这样就得到非运算的关键实现了。

有思路之后打开触发编辑器，现有这些条件与计时器有关：流逝时间、计时器时间到、流逝游戏时间……无不判断一个计时器超时。根据刚刚得到的逆否命题，用局部变量实现“非门”电路：

• 设一局部变量obj1 reachable，初始为 1；
• 触发 $I$：若计时器超时，则令该变量值为 0；
• 触发 $O$：若变量值仍为 1（即未超时），且目标不再存在，则宣布任务完成。

对应的伪代码如下：

obj1_reachable = 1
if timeout:  # 取决于你用 P13 P14 还是 P47
  obj1_reachable = 0
if obj1_reachable == 1 and techTypeNotExist("NAPSYB"):
  play_speech("EVA_ObjectiveComplete")
  ...

当然，虽然理想很美好，但从原版一直到纯 Ares（特别是 Hares 平台），100 个局部变量的限制依然不容忽视。对于有限的资源，还是需要做出合理的分配。

结论

综上所述，红警 2 的触发组件在任务设计当中举足轻重，把握其运行的逻辑，有利于互相交流（至少不需要甩一堆截图）、有利于把更精妙的脑洞付诸实践、有利于优秀触发设计的提炼与发掘，对于触发编写乃至地图创作都有重要意义。

触发系统在逻辑层面上类似if单分支语句的设计，使其就入门而言并无太大门槛；支持顺序、选择、循环三种结构，可以实现大部分任务所需的线性叙事。然而其在逻辑运算上又有所欠缺，稍微复合一点的或、非逻辑判断必须通过局部变量绕路实现，对于地图师的逻辑思维能力是一大考验。

参考文献

1. ModEnc. Triggers [EB/OL], 1.31.2024, 6.17.2024.
2. ModEnc. VariableNames [EB/OL], 5.16.2024, 6.17.2024.
3. RN Studio. map_tutorial [EB/OL], 4.29.2024, 5.6.2024.

致谢

时光荏苒，距离最开始做大白板雪原、遭遇战一样的战役地图应该也有九个年头了。能够写到这里，全拜各位大佬、同行、玩家朋友所赐。Lin 在此谢过诸位。

首先，感谢 RN Studio 指导本次“实验”。感谢制作组的地图教程，为“选题”指引方向；感谢 Zero Fanker 等人提出的指导和改进意见，以及触发实际执行的补充、佐证和更正。

其次，感谢曾经与仍在为红警 2 模组创作贡献智慧的各路人才，为论证提供各种帮助。特别感谢地图师同行们对触发系统所作的各种实地测试和表述修订，同时感谢 Phobos 团队开源触发组件的扩展实现，以及 Heli 等人为简化地图开发所做的各种尝试。

最后，感谢各位喜爱战役的红红玩家，特别是《星辰之光》的测试员和玩家朋友们拨冗测试和体验。

后记

比起“逻辑”，modder 们始终更在乎切实的、能实装进游戏和编辑器的改善。除此之外，红警 2 的触发逻辑本身就与“引擎实现”密不可分。比如：

• 越靠近[Triggers]小节头的触发越容易触发；
• 通过所属方的启动是经由所属方的某个函数执行的，此函数调用为每 8 帧一次，根据所属方列表从上而下依次执行。（FA2spHDM 附文档）
• 包含两个非持续伴随事件的触发永远不会启动，因为这两个事件是相继发生的，而不是同时发生的，因此永远不可能同时满足条件。（FA2spHDM 附文档，有关概念参见 Ares 文档）
• ……

凡此种种，都加深了我个人的自我怀疑——我写这些真的有意义吗？
但至少我是很想找到“存在的意义”的。所以哪怕本文多么“空中楼阁”，至少就让它烂在这里吧。

基础设施

首先除非你想要亲自呆在老机器旁边操作，否则肯定需要远程连接到那台老机器上的，也就需要保证别的设备能和老机器互通。

如果两台机同在一个内网（比如以 WiFi、有线等方式，设备间连接同一个路由器），那么通常来说需要固定老机器的 IP，否则刚搭的“自组服务”可能没几天就飘不知道哪去，得登进路由器里查咯。固定 IP 可以在老机器的系统里操作，等会具体到系统上再分别讨论；一些路由器也支持用户登录进去固定主机的 IP，但我家网关莫得这个功能。

若并非同一内网，则更麻烦亿些。我个人折腾过可行的最简方案是 Zerotier 虚拟组网，毕竟当时对寄网了解有限，搜内网穿透也只能搜出来“喂我花生”之类的东西（我家网关也只支持某某壳子）。

sudo systemctl status zerotier-one.service

sudo systemctl enable --now zerotier-one.service

sudo zerotier-cli join Network_ID
sudo zerotier-cli listnetworks

docker pull zerotier/zerotier
# 务必注意网络通信方式！
docker run -d --name zt --network host zerotier/zerotier
docker exec -it zerotier bash
zerotier-cli join Network_ID
zerotier-cli listnetworks

Windows——性能分摊

相信大多数人玩电脑接触最多的还是 Windows 系统，那么对于如何使用它，想必都是很有经验的罢。根据老机器配置的不同，它承担负载的多寡也自然各有参差。

固定 IP

• Win11 参考电脑屋的教程；
• Win8.1 及以下通常还是从控制面板固定，也参考电脑屋。
• Win10 除了控制面板法，也可以直接在“设置—网络和 Internet—状态”中找到上网的网络（通常标以太网或者 WiFi），点进底下的属性，往下划拉到 IP 设置那边手动分配 IP。

远程连接

白嫖国产软件的免费服务也可以，最常见的当属向日葵了吧。但我是受不了手机端向日葵广告满天飞，所以还是折腾 Windows 自带的 RDP 吧。

欲使用 RDP 连接，需要启用 Windows 的远程控制功能。据微软称家庭版只能它控别人，不能别人控它。但我都 LTSC 2021 起手了，又有何惧。 远程控制选项可在以下两个入口找到（以 Win10、11 为准，不推荐“开发人员设置”）：

• 设置—系统—远程桌面，启用之（顺便根据指引把“睡眠”禁用掉、把“网络发现”打开）；
• 打开“系统属性”^[2]的“远程”选项卡，允许远程连接、勾上“仅允许……”选项（恕我懒得打全称）。

然后就可以使用 RDP 连接了。控制端可以用mstsc（Windows）、Windows App（Android，原“RD 桌面”）、FreeRDP 以及 Remmina（Linux），等等。

然后该干嘛干嘛。顺带一提，远控的鼠标一般是不记录位移、只改变坐标的，也就是说《原神》这类游戏远程玩效果并不佳；但《剑网三》重制版则更建议远程玩，因为接下来讲的 Moonlight 串流没法向它传递键盘输入。

串流

这里的串流主要是指类似“云原神”那样的——服务端跑游戏，其他设备接收画面、回传操作的——类似看别人直播的模式。顺带一提，自己直播也是一种串流，只不过方向相反：是你这边把音画上传^[3]到直播平台。

串流自建云游戏的主要方式是 Moonlight+Sunshine 和 Parsec，其中前者结合 Zerotier 虚拟组网，甚至可以异地云玩。有关的配置方式可以参考知乎专栏或者 B 站搜索“自建云原神”之类的关键词（也可以看看“阿西西”这个 UP 主的魔改 Moonlight 客户端）。咱已经很久没搞了，讲出来也不一定对，就略过吧。

文件共享

最简单的就是 Windows 自带的 Samba（SMB）文件共享，也就是右键文件/文件夹属性里边的“共享”选项卡。

此外还有其他参考：

• 网络文件系统 NFS：参见微软文档
• WebDav 服务器（需要 IIS）：参见微软文档，或参考《Windows 开启 WebDAV》（少数派）

其他服务

• 推流机（挂着直播平台的直播软件，开第三方推流接收内网 OBS 推过来的 rtmp 串流）
• 挂下载（主要是各种限速客户端的下载，或者数据量大的下载）
• 自动化脚本
• RemoteApps（迫真“家庭”版 Office，当然还有 Adobe 全家桶，等等）
• ……

Linux——Web 接口

Linux 通常还是作为服务器而非日用的系统使用，所以相比费劲折腾 VNC 等远程桌面，不妨就让它挂一些长线运行的服务好了。而既然莫得远程桌面，这些长线服务很显然只剩 WebUI 这一种可视化的选择。当然如果你更偏好 CLI（命令行界面），那也不是不行。

固定 IP

不同的发行版主要用到的网络管理工具都不太一样。

• 像 Arch Linux 安装阶段会用systemd-networkd分配固定 IP；
• 而 Ubuntu 虽然也有上述服务，但更多在用Netplan（参见 FreeCodeCamp）；
• 还可以用ifconfig做临时配置：

ifconfig  # 查看所有网卡的配置信息
ifconfig eth0  # 查看某网卡的配置信息，如 eth0
ifconfig eth0 172.16.129.108 netmask 255.255.255.0  # 配置网卡的临时生效的IP地址
route add default gw 172.16.129.254  # 配置网关

总之，具体问题（发行版）具体分析，像/etc/sysconfig/network-scripts这种上古教程还是不要无脑跟了。我的 Ubuntu Server 24.04.2 LTS 连sysconfig都莫得。

SSH 远程连接

安装openssh包，并启用sshd服务。多数软件包管理器应该都支持 SSH。以咱的 Ubuntu Server 为例：

sudo apt update
sudo apt install openssh
sudo systemctl enable --now sshd
sudo systemctl status sshd

部署服务（分层讨论）

首先说一下分层怎么回事。有些服务可能是通过容器分发的，那么 Docker 就是这些服务的下层，为这些服务提供支持（有点绕口？）；而 Docker、npm 之类通常又依赖国外的源（像 DockerHub、npmjs），于是代理又是容器的下层。当然正经分类起来这些都属于应用层。只是细化一下粒度便于讨论。

geox-url:
  geoip: "https://fastly.jsdelivr.net/gh/MetaCubeX/meta-rules-dat@release/geoip.dat"
  geosite: "https://fastly.jsdelivr.net/gh/MetaCubeX/meta-rules-dat@release/geosite.dat"
  mmdb: "https://fastly.jsdelivr.net/gh/MetaCubeX/meta-rules-dat@release/geoip.metadb"
  asn: "https://github.com/xishang0128/geoip/releases/download/latest/GeoLite2-ASN.mmdb"

后记

通篇看下来，我的服务场景都挺简单的，不是吗？说实话……我并不熟悉寄网（哪怕为了跨考自学过 408），平时也没有太多 Web 编程的实践和需求。能简单搭这么一个自用的服务便已经方便我不少了。若是真正的大佬，或许还会利用反代、软路由等种种轮子实现更加 NB 的东西吧。

不过反正我这人也没什么水平，笔记也不过抛砖引玉。菜逼有菜逼的天马行空，简单点写，懂的都懂。