企业官网建设流程全解析

1. 为什么偏要在 Windows Cmd 里折腾 Make 指令

先别急着打我，我知道很多人第一反应是：Windows 上想用 Make，装个 WSL 或者用 PowerShell 不香吗？话是没错，但现实工作里总有绕不开的场景——公司内网服务器锁死了权限，装不了 WSL；项目组同事全在 Linux 上维护一套 Makefile，你手里只有 Windows 的 Cmd；或者你正在写一个跨平台的开源工具，CI 脚本里需要同时覆盖 Windows 的构建流程。这时候，能在原生的 Cmd 窗口里直接敲make，解决的不只是命令能不能跑的问题，而是整个团队的协作流程能不能统一。

我最初接触这个需求，是在一个模拟项目 X 里。项目本体是 C 语言写的命令行工具，构建脚本用 Makefile 组织，团队里三分之二的人用 Linux，剩下的人用 Windows。最初 Windows 这边的方法是用 MinGW 的 mingw32-make，但它有个尴尬的问题——默认只认Makefile、makefile、GNUmakefile这三个文件名，而且命令名是mingw32-make，不是make，脚本里一旦写了make clean这种子目标调用，Windows 本地就崩给你看。后来实在忍不了，才认真研究起“用原生 Cmd 跑 Make 指令”这条路。

这篇文章我不会给你推送任何需要图形界面点击安装的“傻瓜方案”（虽然那种方案确实简单，但对你解决实际问题帮助有限），而是把重心放在三个层面：第一，怎么把 Make 环境在 Cmd 里完整搭起来；第二，Makefile 在 Windows 上跟 Linux 有哪些需要注意的差异；第三，遇到报错怎么用最朴素的 Cmd 工具定位问题。全程用我实际踩过的坑作例子，你照着走一遍基本不会卡住。

我一直觉得，命令行的价值不在于工具本身多高级，而在于它是否成为你工作流里不显眼却关键的那一环。Make 就是这样——它本质是一个依赖关系管理工具，但到了 Windows Cmd 这个环境里，每一层都有小脾气。把这些小脾气捋顺了，你会发现在 Cmd 下跑 Make 真的没那么玄乎。

2. 先搞清楚你手上缺的不是 Make，而是 GNU 工具链的路

很多人在 Cmd 里输入make得到“不是内部或外部命令”的第一反应，是自己没装 Make。其实你缺的可能远远不止 Make。

Windows Cmd 跟 Linux Shell 的哲学差别很大。Cmd 的命令解析机制很死板：它只会从当前目录和PATH环境变量里找可执行文件，找到就执行，找不到就报错。而 Make 在运行过程中，除了自身之外，通常还会调用一些基础命令，比如rm、mkdir、echo、cp。在 Linux 上这些是系统自带的核心工具，但在 Windows 原生的 Cmd 里，rm是不存在的——你只有一个del，而且语义还跟rm不完全一样。还有mkdir，Cmd 里确实有mkdir，但参数格式跟 Posix 完全不同。更麻烦的是rm -rf这种在 Makefile 里高频出现的组合拳，在 Cmd 里根本没有对应物。

所以第一步不是装 Make，而是先确定你要用哪一套“环境底座”。我实际比较过两条主路线：

我给你掏心窝子的建议：如果你打算老老实实只用 Cmd，不去碰 PowerShell，也不想引入 WSL 这一层，那就用 MSYS2 作为底座。理由不复杂——MSYS2 里面的make是正儿八经的 GNU Make 4.x，而且它会附带一个精简版的msys-2.0.dll运行时，很多依赖这个 DLL 的工具能直接跑。你只需要把C:\msys64\usr\bin加到 PATH 里，就能在 Cmd 里同时拥有make、rm、cp、sed、awk这些 Linux 习惯依赖的命令。

别小看这一步，我见过太多人只装了 make.exe 本体，结果 Makefile 里第一行rm -rf build就报错，然后开始怀疑是自己写错了，其实只是缺了rm这个命令而已。

安装 MSYS2 的过程不展开了，官网下安装包、一路 Next、装完默认在C:\msys64。装完记得打开 MSYS2 Shell 执行一次pacman -S make，因为默认最小安装里未必带 make。这一步很多人会漏，因为在 MSYS2 的某个版本里，make并不是默认包。

装完之后回到 Cmd，敲make --version，如果能正常打印 GNU Make 版本号，说明第一步你走通了。如果你执意用独立的 make.exe，也不是不行，但后续遇到rm、cp这类命令缺失的时候，你可能还需要手动下载 coreutils 二进制包补全，工作量不小。

提示：在 MSYS2 的 usr\bin 里，命令的原生二进制大多依赖msys-2.0.dll，如果你把整个目录直接复制到另一台机器上而不带 DLL，大概率跑不起来。所以建议做环境迁移时，直接拷贝整个 MSYS2 目录，或者在那台机器上重新装一遍。

3. Cmd 里的 Make 指令到底怎么敲才不出错

环境解决之后，很多人以为万事大吉，结果在 Cmd 窗口里敲make又碰壁。原因很微妙：Cmd 对特殊字符的转义规则跟 Bash 完全是两套。

先从一个最简单的 Makefile 开始。假设你有一个这样的文件：

all: build build: @echo Building project...

在 Linux 的 Bash 里，敲make就能看到输出。在 Cmd 里，如果你把 Makefile 的换行符搞成了 Windows 的 CRLF（回车+换行），那 GNU Make 还能勉强容忍，但有些老版本会直接报错“missing separator”，因为制表符后面跟了回车字符，Make 就懵了。这是 Windows 上用 Make 最经典的第一坑：Makefile 的缩进必须用真实 Tab 字符，且行尾建议转成 LF。

更隐蔽的问题是：Makefile 里 recipe 中如果用了 Cmd 特有的语法，比如@echo off这种，那 Make 会把这行原样丢给cmd.exe /c去执行，结果通常不是你想要的。反过来，如果你在 Makefile 里写了$(shell ...)函数，Bash 能执行的字符串，在 Cmd 里未必能执行。

我建议养成一个习惯：在 Windows 的 Cmd 里跑 Make，优先把 Makefile 当作“可移植脚本”来写，而不是“Linux 专属脚本”。意思是说，尽量在 Makefile 里避免平台相关的命令，统一用$(RM)、$(MKDIR)这种 Make 内置的变量，或者通过命令行传入覆盖变量来适配 Windows。GNU Make 本身提供了一些默认变量，比如RM默认是rm -f，MKDIR默认是mkdir -p。上面说了 MSYS2 环境下，rm和mkdir是存在的，所以这些默认值在 Cmd 里也能用，这算是 MSYS2 路线额外的好处之一。

再举一个实际例子。假设你要在 Makefile 里写一个 clean 目标：

clean: rm -rf build/

在只装 make.exe 的 Windows 裸环境下，这行会直接报错，因为rm不存在。但在 MSYS2 环境下，rm被解析为C:\msys64\usr\bin\rm.exe，能正常运行。你不需要改任何代码，这就是我喜欢 MSYS2 的根本原因——它让 Makefile 内容尽量保持跨平台一致。

那什么时候你需要改 Makefile？当你在 recipe 里用到了无法通过 PATH 补全的 Windows 原生命令时，比如：

release: if exist build\\* (echo Cleaning...) else (echo No build dir)

这种语法是 Cmd 的批处理语法，你用 Make 去执行时，由于 GNU Make 默认用/bin/sh或者cmd.exe /c来执行 recipe，实际行为可能不是你预期的那样。GNU Make 在 Windows 下，如果检测不到sh.exe（MSYS2 里其实有），它会退回到cmd.exe /c来执行每条命令。也就是说，你的 recipe 实际上是在 Cmd 里跑的，只是 Make 本身在替你管理依赖关系。这个理解很重要：Make 在 Windows 上更像一个“带依赖检查的批处理调度器”。

实际敲指令时，还有几个最基本的套路，我顺手整理给你：

1. 只打印将要执行的命令，不真正执行：make -n。在 Cmd 里跑这个，能把整个依赖链上的命令先给你过一遍，方便排查路径问题。这个调试手段在 Windows 上格外有用，因为 Cmd 里没有bash -x那种直接的办法。
2. 指定 Makefile 文件名：make -f MyBuild.mk。如果你项目里同时存在多个构建脚本，这个参数是必需品。
3. 指定目标：make build DEBUG=1。在 Cmd 里传环境变量给 Make，可以直接作为命令行参数附加，GNU Make 会用命令行传入的变量覆盖 Makefile 里的同名变量。
4. 并行构建：make -j4。这里提醒一下，在 Windows 的 Cmd 里，-j并行执行 recipe 时，如果 recipe 里用了共享临时文件，比较容易出现竞争问题，所以并行度不要拉得太高，-j4已经足够大多数场景。

还有一个小细节我最后才意识到：Cmd 里如果路径带空格，比如C:\Program Files\SomeTool\tool.exe，你需要额外小心。GNU Make 的 recipe 是由 Make 拼接字符串后交给 shell 执行的，Cmd 对带空格路径的解析规则跟 POSIX 不一样。保险的做法是用$(subst ...)把空格处理掉，或者用short path（8.3 短文件名）来规避这个坑。我用过最省心的方法，是把工具安装到不带空格的路径下，比如直接放C:\tools\，虽然有点土，但省了一堆麻烦。

4. 从零到一：在 Cmd 里跑通一个完整的多文件构建流程

上面讲了不少理论，现在用一个小项目演示完整的实操过程。这个项目是个纯 C 语言的工具，包含三个源文件main.c、util.c、util.h，目标产物是app.exe。Makefile 写得比较典型，你可以照着它理解依赖关系怎么建立。

CC = gcc CFLAGS = -Wall -O2 OBJS = main.o util.o TARGET = app.exe all: $(TARGET) $(TARGET): $(OBJS) $(CC) $(CFLAGS) -o $@ $(OBJS) main.o: main.c util.h $(CC) $(CFLAGS) -c main.c util.o: util.c util.h $(CC) $(CFLAGS) -c util.c clean: rm -f $(OBJS) $(TARGET) .PHONY: all clean

把这个 Makefile 存成Makefile，注意换行符必须转成 LF，缩进必须用 Tab。在 Windows 记事本里直接写的话，默认是 CRLF 和空格缩进，容易翻车。我强烈建议你用一个能控制换行符的编辑器（比如 VSCode、Notepad++），写好之后切换行尾为 LF。

打开 Cmd，切换到项目目录，执行：

make

如果你是第一次在你的 Cmd 环境里跑 Make，大概率会遇到两种情况：

第一种：什么输出都没有，只报'gcc' 不是内部或外部命令。这说明你的 PATH 里没有 gcc。如果你之前装过 MinGW-w64，通常它的 bin 目录没有自动加入 PATH，你手动加进去就行。如果你没装 gcc，那这条路就得先补编译器，纯用 Make 没有编译器是构建不了 C 项目的。

第二种：报错Makefile:8: *** missing separator. Stop.。这个错误基本可以断定 line 8 的缩进不是 Tab，或者行尾带了 CR。把编辑器切到“显示所有字符”模式，确认 build 和$(CC)两行前面是真实的 Tab 字符，换行符是 LF。

成功执行之后，你会看到类似这样的输出：

gcc -Wall -O2 -c main.c gcc -Wall -O2 -c util.c gcc -Wall -O2 -o app.exe main.o util.o

这是 Make 在跟你汇报它正在执行的动作。它按依赖关系自动推导：先编译 main.o，然后 util.o，最后链接 app.exe。你自己手动在 Cmd 里敲这三条命令也能得到一样的结果，但 Make 的优势在于——如果你改动了util.c，重新执行make时，它只会帮你重编译util.o和重新链接app.exe，不会白白重编main.o。这个过程依赖的是文件时间戳对比：util.c比util.o新，就认为util.o过期了，需要重建。

这时候你再执行make clean，MSYS2 环境下的rm -f会删掉中间产物和最终产物。如果你用的是纯 Cmd 且没配备 MSYS2 工具链，这一行大概率报错，那么建议你把 clean 目标改成：

clean: -del /q *.o 2>NUL -del /q $(TARGET) 2>NUL

前面加一个短横线-，是告诉 Make：如果这条命令返回非零退出码，忽略错误继续执行。这个技巧在 Windows 上极其常用，因为del /q在没有匹配文件时会返回非零状态码，如果不加-，Make 会在第一个没有匹配文件的删除处停下来报错。

不过我必须坦白说：这种改造虽然应景，但属于“被 Windows 逼着改 Makefile”。当你面对一个庞大的跨平台项目，我建议还是统一用 MSYS2 环境，保持 Makefile 原汁原味，少做这种平台化分支处理，否则维护成本真的高。

在实际项目里，我还经常用到 Make 的-C参数：

make -C submodule

这个参数的含义是：先切换到submodule目录，再执行 Make。很多项目会在顶层 Makefile 里通过这个命令去递归调用子目录的 Makefile。在 Cmd 里使用-C也很安全，因为这个参数是 GNU Make 自己处理的，不经过 shell 的路径转换。这个特性在做多模块项目时非常顺手，比如你的项目分src、tests、tools三个子目录，你可以分别给它们写 Makefile，然后在根目录再写一个总控 Makefile，用-C串联起来。

注意：Windows Cmd 里，make -C后面的路径可以用正斜杠/也可以反斜杠\，推荐统一用正斜杠，避免转义问题。

5. 环境变量、字符串操作和路径转换的兼容性细节

跨到 Windows 上，Makefile 里最烦人的不只是换行符，还有路径分隔符和字符串处理。

GNU Make 内置了不少文本函数，比如$(patsubst pattern,replacement,text)、$(subst from,to,text)。这些函数是跨平台的，不依赖底层 shell，所以你可以在 Windows 上放心用。但一旦涉及“把 Windows 风格路径转换成 Unix 风格路径”这类需求的时候，麻烦就来了。

举个例子。假设你在 Makefile 里写了这个变量：

SRC_DIR = src\main

在 Windows 的 Makefile 里，反斜杠\在 GNU Make 里不是转义字符，而是普通字符。所以这个变量的值是src\main。后来你用$(wildcard $(SRC_DIR)/*.c)去匹配源文件，在 Linux 上没问题，但在 Windows 上，通配符展开用的是 Make 内部逻辑，它并不认为\是路径分隔符，于是匹配结果可能是空。我在某个跨平台项目上就被这个坑搞掉整个下午，最后是统一改成/分隔符，或者用$(subst \,/,$(SRC_DIR))转换。

这件事的本质是：GNU Make 本身只理解/分隔符。它在底层对文件名做比较、排序、时间戳检查时，都用/。Windows 的内核 API 虽然能接受/，但 Make 不一定会帮你转换。所以最佳实践是：在 Makefile 里统一写正斜杠/。你不用担心/在当前目录的前缀问题，Cmd 下执行make时，.\src\main\和./src/main/最终都指向同一个目录，区别只在于 Make 的内部处理。

再说环境变量。你在 Cmd 里用set FOO=bar设置的环境变量，make 能通过$(FOO)拿到吗？答案是能。GNU Make 在启动时会继承当前进程的环境变量，并且将它们作为 Make 变量暴露。但反过来有个坑：你在 Makefile 里用FOO = baz定义的变量，不会自动导出为环境变量，除非你用export FOO明确声明。在 Cmd 里调试这种问题时，你可以在 recipe 里加一句echo %FOO%，不过在 Makefile 的 recipe 里写%FOO%是 Cmd 的语法，跟 Make 的变量展开$(FOO)完全不同，两者容易混淆。我建议 recipe 里如果需要打印 Make 变量，用$(info $(FOO))，这是 Make 内置的信息输出函数，在构建日志里直接把这个变量的值打出来，方便调试。

还有一个与路径转换相关的历史遗留问题，如果你用 MSYS2，可能会遇到所谓“路径自动转换”的现象。MSYS2 的运行时在调用原生 Windows 程序时，会把以/开头的命令行参数自动转换成 Windows 路径，比如/c/Users/admin变成C:\Users\admin。这本来是个贴心设计，但在某些场景下会帮倒忙——比如你在 Makefile 里写了一个参数/usr/bin，MSYS2 的转换逻辑可能把它的形式改成C:\msys64\usr\bin，而这个参数本来是传给工具做匹配用的，被改动之后就对不上了。

解决这个问题的思路很简单：要么给程序传MSYS2_ARG_CONV_EXCL="*"环境变量，显式禁用参数路径转换；要么干脆不用 MSYS2 的 make.exe，而用 MinGW-w64 自带的 mingw32-make.exe，后者不依赖 msys-2.0.dll，没有路径转换的副作用。每种方案都有取舍：mingw32-make 没有把rm、cp一起带过来，而 MSYS2 的 make 又有路径转换抢戏的毛病。我的经验是，在纯命令行交互且 Makefile 写得比较防御性的前提下，MSYS2 的 make 其实更好用，因为只要把路径分隔符统一成/，它大部分时间不会出差错。

6. 那些年我在 Cmd 下被 Make 整懵的时刻

挑三个真实的踩坑记录，每个都是能让你浪费半天时间的问题，我把排查过程完整写下来，你遇上了可以少走弯路。

第一个坑：命令压根不执行。Makefile 写了新目标，触发条件都满足，但构建日志里根本看不到这条命令。后来检查发现，Makefile 里那行 recipe 的前缀缩进用了 8 个空格而不是一个 Tab。GNU Make 的规则是：每一行 recipe 必须以 Tab 开头。这是 Make 语法里少有的“强规范”，就算你用别的编辑工具把 Tab 自动转换成空格了，它也会义无反顾地报错。而且这个问题好死不死的不是报在语法解析阶段，而是可能在解析阶段直接卡住，用make -p调试才能看出端倪。我后来给自己定了个规则：Makefile 一律在 VSCode 里设置editor.detectIndentation: false和insertSpaces: false，从根源上防止 Tab 变空格。

第二个坑：%在 Cmd 里的解释问题。目标是 Windows 批处理里那种百分号变量。我在 Makefile 里写了一个模式规则：

%.o: %.c $(CC) $(CFLAGS) -c $< -o $@

在 MSYS2 的 make 下，这行一切正常。但如果你通过某种方式让 recipe 变成由cmd.exe /c执行，且 recipe 里出现了%字符（比如某个工具的格式化参数），Cmd 会试图把%后面跟着的名字当作环境变量展开，然后展开失败，留下空字符串。结果就是工具拿到一个残缺的参数，行为变得不可捉摸。解决办法是，遇到这类情况，要么把%写成%%（Cmd 的转义方式），要么避免在 recipe 里直接使用带%的命令行参数，改用配置文件替代。

第三个坑：并行构建时共享中间文件冲突。我头一回在 Cmd 里跑make -j8，项目里有一个步骤会生成config.h，另一个步骤会读config.h。Make 的依赖分析里，如果这两个步骤之间没有正确的依赖关系声明，并行构建时后一个步骤有可能先于前一个执行，结果读到的是不完整甚至不存在的config.h，引发一连串编译错误。这个问题在 Linux 上同样有，但 Windows 上的表现更加诡异，因为文件被占用的提示有时不会立刻弹出。我的教训是：并行构建时别贪心，先-j1完整跑一遍，确认没有隐藏依赖问题，再上-j4或-j8。

除了这三个，还有一个经常带新手绕弯路的情形：多目标的伪目标声明。如果你的 Makefile 里没有写.PHONY: clean install，而磁盘上刚好有一个叫clean的文件，Make 会认为clean目标已经是最新的，从而跳过 recipe 不执行。在 Windows Cmd 下，你很容易在某个目录里无意间创建了一个叫clean的空文件，然后疯狂怀疑 Make 坏了。排查这个问题的命令是make -n clean，它可以看 Make 会不会“空跑”这个目标。

7. 如果不想纯 Cmd，还有哪些值得留意的变化形态

说了这么多，我必须承认：纯 Cmd + MSYS2 的方案并不是 Windows 上唯一的路。如果你稍微放开一点限制，还有两个变体值得了解，因为它们在某些场景下比纯 Cmd 更好用。

第一个变体是Cmd 唤起 PowerShell，但注意这不等于 PowerShell 里原生跑 Make。实际操作是，你在 Makefile 里通过$(MAKESHELL)指定 PowerShell，或者在 Cmd 里面先执行powershell -Command "make ..."。但我不推荐在 Makefile 里直接混用 PowerShell 语法，因为 recipe 在两种 shell 间的解释差异会让调试成本陡增。我个人的习惯是：让 Make 的 recipe 尽量保持可移植性，不求执行它的 shell 多强大。

第二个变体是用 WSL 里的 make 来构建面向 Linux 的产物，然后通过wsl命令跟 Cmd 交互。这其实已经不是“Windows Cmd 使用 Make 指令”的原始含义了，它能解决的是另一类跟平台的目标产物相关的问题。如果你需要在同一台 Windows 机器上同时产出 Linux 和 Windows 的构建物，方案上建议拆成两个完全独立的构建流程，一个在 WSL 里跑 Make，一个在 MSYS2 的 Cmd 里跑 Make，二者不要混用同一个 Makefile 里的 recipe 变量，否则你会陷入无穷无尽的路径转换地狱。

另外，如果你最近在 GitHub 上看到不少项目已经用 CMake + Ninja 替代了手写 Makefile，也别急着改换门庭。CMake 确实在 Windows 上更友好，生成的构建系统默认适配 Visual Studio 或者 Ninja，跨平台能力更强。但很多老项目、嵌入式项目、以及个人脚本，Makefile 依然无可替代，因为它的语法更直接、依赖关系一目了然、也不需要先生成一层构建配置。我处理大多数个人项目时，第一选择仍然是 Makefile，只有在需要给用户提供一键构建体验时，才会用 CMake 包一层。

8. 根据我个人的经验，最后说几个让 Make 在 Cmd 里更好用的习惯

第一，把 MSYS2 的usr\bin放进 PATH 是第一步，但不是全部。更稳妥的做法是单独写一个msys_env.bat，里面把你常用的工具目录全部加进去，这样你在任何一个新开 Cmd 窗口里执行这个脚本，就能快速构建出统一的命令环境。这个脚本甚至可以放到项目的scripts目录里，让其他协作者一键配置。

第二，Makefile 里尽量固定用$(info ...)记录关键变量的值。在 Windows 上，路径分隔符、Shell 类型、编译器路径这些变量一旦出错，你靠肉眼看很难发现，但打印出来，一眼就能看出问题。

第三，构建目录和源码目录的分离。这句话我在 Windows 上体会尤其深刻。如果把中间产物，比如.o文件，跟源码放在同一个目录里，一旦 Makefile 的清理规则没写对，Windows 的资源管理器又会因为文件占用而弹出“无法删除”的提示，然后 Make 返回非零状态码，整个流程就卡住了。Build 目录单独分离，比如build/，不仅清理起来干净，心态也会好很多。

第四，动态设置环境变量时留点心。Cmd 里set设置的变量只对当前进程有效，而 Make 启动的子进程会继承这份环境变量，但如果你在 Makefile 里调用了export来标记某个 Make 变量，那它会被传下去。反过来，你如果在 recipe 里用set FOO=bar && make subdir，这个FOO只影响这条 Cmd 命令行，不会持久化。我早年在这个细节上栽过跟头，后来干脆使用make VAR=value的方式注入，比环境变量干净得多。

第五，不要忘记make --debug=basic。这个参数能告诉你 Make 在检查哪些文件的时间戳、判定哪些目标需要重建、为什么会跳过某些目标。在 Windows 上，文件系统的时间戳精度和 NTFS 的访问行为可能跟 Linux 有细微差异，当你遇到“明明改了源码但 make 不重新编译”时，第一反应不是怀疑 Make 坏了，而是先看看--debug输出的时间戳比较结果，多半是源码文件和目标文件的时间戳刚好精确到同一秒，而 NTFS 时间戳的精度又在这里产生了影响。这时候touch一下源文件通常能立刻触发重建，但治本的方法是别过分依赖时间戳，手动指定make -B强制重建一次确认乘积没问题，再回归正常模式。

9. 最后再分享一个小技巧：把 Make 的输出拽到 Cmd 的日志里

在 Cmd 里跑构建时，输出信息被终端吞掉的体验还挺常见，尤其是并行构建的时候，多条命令的输出会混在一起，根本分不清哪行是哪个目标产生的。我后来习惯在 Makefile 里加几个格式统一的日志函数：

define log_info @echo [INFO] $(1) endef define log_error @echo [ERROR] $(1) endef

然后在 recipe 里用$(call log_info, Building main module...)输出日志。这行命令在 Cmd 里也能正常执行，因为echo是 Cmd 自带的命令。加上前缀[INFO]后，构建日志的可读性瞬间提升一个档次。如果项目跑 CI，你可以把 stdout 重定向到日志文件：make all > build.log 2>&1，在 Cmd 里这个重定向语法同样有效，构建失败时打开日志文件搜索[ERROR]，定位问题的速度比盯屏幕快得多。

说到底，Windows Cmd 和 Make 的配合，并没有想象中那么别扭。只要环境搭对了，知其然也知其所以然，它完全可以像在 Linux 上一样成为你构建流程里可靠的伙伴。我在模拟项目 X 里用这套方案跑了两三个月，团队里那几个 Windows 上的同事从最初的抗拒，到后来习惯了make build、make test、make package这套指令，再也没回头。

如果哪天你也把 Make 在 Cmd 下跑通顺了，你会发现这件事的意义不只是“少装一个 WSL”那么简单——它意味着你的脚本、你的构建流程、你的团队协作，真正做到了跨平台曾经在文档里承诺的统一。