Windows 上编 Nginx 最难的不是命令，是凑工具链。 四样东西缺一样都不行，而且报错都在流程后半段。
10.3.2 是 Linux 下的做法，这一节换到 Windows。 结论可能让你意外：多数情况不该自己编。
一、要凑齐的四样
Linux 上 apt install build-essential 就齐了，Windows 上得自己找。
① Visual Studio：提供 cl.exe 与链接器。
没有它根本编不了。
② MSYS2：提供类 Unix 的命令环境。
configure 是个 shell 脚本，普通 cmd 跑不起来。
③ Perl：处理部分源码生成。
缺了会在 configure 中途报错。
④ NASM：汇编优化代码。
缺了会编到一半报找不到 nasm。
这四样最折磨人的地方是「报错位置」： 它们都不在开头报，而是在流程跑了十几分钟之后才出现。 所以要养成「先检测、再动手」的习惯。
二、MSYS2 编出来的东西有限制
用 MSYS2 编出来的 Nginx 只能在 MSYS 环境里跑。
它依赖 msys-2.0.dll 这类运行时，
拷到别的机器上双击是跑不起来的。
要编「真正能单独运行」的版本，得用 MSVC 工具链，
MSYS2 只是提供 shell 与 make，编译器还得是 cl.exe。
这个分工第一次接触很容易搞混。
判断标准很简单：
编出来的 nginx.exe 拷到一台没装 MSYS2 的机器上能跑，
那才是原生版本。
跑不起来、报缺 dll，就是没编对。
三、多数情况不该自己编
如果目标只是「在 Windows 上跑一个带 RTMP 的 Nginx」， 最省事的不是自己编，是找别人编好的： GitHub 上有人提供带 nginx-http-flv-module 的 Windows 产物， 下载解压就能用。
自己编只在两种情况下值得： ① 要特定的模块组合，现成的包都不满足。 ② 要特定版本的 OpenSSL，比如因为合规要求。
两条都不占，就别花这个时间。 把时间花在配置与压测上，收益大得多。 这也是这一节最实在的一句建议。
四、动手 Demo：Windows 下编译——先把工具链凑齐
真查一遍本机有哪些工具、版本够不够， 比编到一半才发现缺东西强得多。
import shutil, subprocess
TOOLS = [("perl", ["perl", "-v"]),
("nasm", ["nasm", "-v"]),
("gcc", ["gcc", "--version"]),
("make", ["make", "--version"]),
("git", ["git", "--version"]),
("openssl", ["openssl", "version"])]
have = 0
for name, cmd in TOOLS:
path = shutil.which(cmd[0])
if path is None:
print("%-10s 没有" % name)
continue
have += 1
try:
r = subprocess.run(cmd, capture_output=True, timeout=10)
txt = (r.stdout or r.stderr).decode("utf-8", "replace")
txt = txt.splitlines()[0][:34]
except Exception:
txt = "（调用失败）"
print("%-10s 有 %s" % (name, txt))
print("一共 %d 个，找到 %d 个" % (len(TOOLS), have))
实跑输出：
--------------------------------------------------------------------
Windows 下编译——先把工具链凑齐
--------------------------------------------------------------------
**① Windows 上没有现成的编译环境**
**Linux 上 `apt install build-essential` 就齐了，Windows 上得自己凑。**
**官方推荐的路子是 MSYS2 + MinGW，但它不能编出 Windows 原生的服务，**
**只能编出「在 MSYS 环境里跑」的版本。**
**要编真正能双击运行的 Nginx，需要一整套：**
工具 干什么 缺了会怎样
-----------------------------------------------------------------------
Visual Studio 提供 cl.exe 与链接器 根本编不了
MSYS2 提供类 Unix 的命令环境 configure 脚本跑不起来
Perl 处理部分源码生成 configure 中途报错
NASM 汇编优化代码 编到一半报 nasm 找不到
**这四样缺一样都不行，而且它们的报错都不在开头，**
**是在流程跑到一半才出现——这才是最耗时间的地方。**
**② 真查一遍本机有哪些**
**编译前先跑一遍检测，比编到一半才发现缺东西强。**
工具 找得到吗 版本前 30 字
-----------------------------------------------------------
perl 没有 -
nasm 没有 -
gcc 没有 -
make 没有 -
git 有 git version 2.55.0.windows.3
openssl 有 OpenSSL 3.5.7 9 Jun 2026 (Li..
**6 个里找到 2 个。**
**找不到的那些就是要先装的。**
**注意这张表只代表「这台机器现在有什么」，**
**不代表「够不够用」：**
**有的工具版本太老也会编不过，比如 Perl 5.8 之前的版本处理不了部分脚本。**
**版本号那一列就是给这种情况看的。**
**③ 一条更省事的路**
**如果只是想在 Windows 上跑一个带 RTMP 的 Nginx，**
**最省事的不是自己编，是找别人编好的：**
**GitHub 上有人提供带 nginx-http-flv-module 的 Windows 编译产物，**
**下载解压就能用。**
**自己编的价值只有两个：**
**① 要特定的模块组合**；**② 要特定版本的 OpenSSL。**
**两条都不占，就别花这个时间。**
**这也是本节最实在的一句建议。**
这台机器上只找到 2 个，说明要编还得装一大半。
shutil.which 只查 PATH，装了但没加 PATH 一样查不到。
版本号那一列是给「版本太老」这种情况看的，不是摆设。
先检测再动手，能省掉十几分钟的无效编译。
30 秒实验
- 把
shutil.which换成查注册表，想想能多查到什么——装了但没加 PATH 的程序能查到，这是它的价值。 - 把
nasm -v改成nasm -h，看结果差多少——帮助文本也是到 stderr，所以抓 stderr 更稳。 - 给
TOOLS加一个cl，看沙箱里有没有——没有，这也是「不能在本机编」的直接证据。
常见误区
- 「装了 Visual Studio 就能编」——还得有 MSYS2 跑 configure。
- 「MSYS2 编出来的能随便拷」——依赖 msys-2.0.dll，拷走跑不了。
- 「自己编总是更好」——只为跑起来的话，现成包更省事。
自测三问（点开对答案）
1. Windows 上编 Nginx 缺哪四样之一都不行？ —— **Visual Studio、MSYS2、Perl、NASM。** 2. 怎么判断编出来的是原生版本？ —— **拷到没装 MSYS2 的机器上能跑**，报缺 dll 就不是。 3. 什么情况下才值得自己编？ —— **要特定模块组合或特定 OpenSSL 版本**，否则用现成包。- ☐ （本节完，下一节 10.4.1 Nginx 配置文件结构）