在Windows上聊Nginx部署很多人第一反应是“这玩意儿不是跑在Linux上的吗”——确实线上服务器几乎清一色是Linux发行版跑Nginx但Windows下对Nginx的需求其实一直存在而且远比想象中频繁。前端开发要解决本地跨域后端要临时开个静态服务运维要在内网搭个轻量反向代理这些场景下Nginx在Windows上的价值立刻就体现出来了。这篇文章就把我在Windows上安装、配置、排查Nginx的完整过程捋一遍重点说清楚那些“网上教程不会明说但实际一定会遇到”的坑。我会从场景判断开始带你把下载、解压、配置、启停、排错这几个环节全部走完。每个操作都会解释为什么要这么做参数是什么意思适合什么情况。目标很简单你看完这篇文章能在半小时内把Nginx在Windows上跑起来并且知道出了问题该去哪里查、怎么处理。1. 为什么要用Nginx而不是直接用别的1.1 谁需要这份部署指南先对号入座看看你属于下面哪类情况。如果你恰好命中那这篇文章就是为你写的。第一类是前端开发。本地起了一个Vue或者React工程开发服务器跑在8080端口后端接口在另一台机器或者另一个端口直接请求会有跨域问题。用Nginx做一层反向代理把/api路径的请求统一转发到后端地址跨域问题在代理层就解决掉了前端代码里不用改任何东西。第二类是后端或全栈开发。本地调试时需要一个静态文件服务比如临时分享一个文件给同事或者模拟线上环境把打包后的dist目录跑起来看看效果。Python有http.serverNode有serve但这两个都不算正经服务器更别说做路径重写和请求转发。Nginx配置一次后续反复复用。第三类是运维和测试人员。内网环境里存在多台应用服务器不想对外暴露太多端口需要用一个统一入口做反向代理或简单负载均衡。Nginx在Windows上虽然不适合扛超高并发但应付内网测试环境的流量完全没问题。第四类比较偏门但真实存在。某些老系统的生产环境就是Windows Server没法随便装Linux虚拟机又不想用IIS那套复杂配置。这种情况下Nginx就成了一个轻量、可控、配置灵活的优秀替代品。1.2 相比IIS、Apache、NodeNginx赢在哪很多Windows用户一听“Web服务器”第一反应是IIS毕竟系统自带的组件勾选一下就能用。但IIS的问题在于配置路径太长——站点、应用程序池、绑定、身份凭据每一个环节都有图形界面要操作而且它的配置文件是XML格式想迁移到其他机器或者做版本管理很不方便。对一个习惯用文本配置的人来说IIS的整套逻辑相当沉重。Apache在Windows上也能跑但它的模块化设计和配置语法相对更“重”而且对Windows的特有优化做得一般。相比之下Nginx的配置就是纯文本核心指令不过几十个一个nginx.conf文件就能说清楚整个服务的行为。想迁到Linux生产环境把配置文件原样拷贝过去基本就能跑。Node的http-server或者Python的http.server更适合“临时起一个服务”但它们没有真正的反向代理能力也没有location匹配、负载均衡、URL重写这些函数。你可以在Node里写代码实现代理但那是“写业务逻辑”不是“做服务器配置”。Nginx是不用写代码就能完成这些事的现成方案。1.3 关于Windows版Nginx的几个认知纠偏先把几个流传很广的误解拆掉。误解一Windows版Nginx是阉割版。实际不是。Nginx官方对Windows的支持虽然不算主推但官方源码是支持Windows编译的提供的Windows预编译包功能上和Linux版本保持了高度一致。你日常会用的指令比如server、location、proxy_pass、rewrite、gzip在Windows版里全部可用。区别主要体现在底层实现上Windows没有Linux的epoll事件模型用的是select和IOCP相关的机制但这影响的是高并发场景下的性能上限对开发调试和中小规模内网使用来说体感差别很小。误解二Windows版Nginx不能用于生产环境。这个说法太绝对。对于内网工具、测试环境、低流量的对公服务Windows版Nginx稳定性和可靠性是够用的。真正要上大流量公网服务出于性能和操作系统的长期稳定性考虑Linux才是首选。但这个选择问题是架构层面的不是“Windows跑不了Nginx”层面的。误解三配置方式和Linux版完全不同。这是错误认知。配置文件格式、指令、模块几乎完全一致只有极少部分涉及路径和进程管理的指令需要调整。学会了Windows版的写法切到Linux只需要改路径格式其余不变。这也是我推荐大家入手Nginx时从Windows开始的原因——不用装虚拟机不用折腾Linux环境一样能学会核心配置。2. 下载、解压与目录结构2.1 版本选择与下载入口下载是第一步但这里就有讲究。打开Nginx官网的下载页面能看到Mainline version和Stable version两个分类。如果你是第一次使用或者追求“能用就行别出幺蛾子”直接选Stable版本。Mainline是新功能验证版更新频繁新特性多但相应的踩坑概率也大。在Windows上部署稳定性优先级高于一切。另一个容易搞错的地方要下载Windows版而不是Linux版。官网下载区会把源码包和Windows版分开列出来Windows版本通常是一个zip压缩包文件名像是nginx-版本号.zip。有同行曾经下载了Linux的tar.gz包在Windows上折腾了半天解压工具才发现不对这种低级错误其实很常见。这里我多说一句下载完压缩包后建议校验一下文件完整性。Windows下用PowerShell执行Get-FileHash命令算一下SHA256和官网公布的值对一下。这一步不少人觉得多余但既然要落地部署哪怕只是本机调试版本养成校验习惯没有坏处。2.2 解压路径与目录结构下载得到的zip包解压后的目录名带着完整的版本号比如nginx-1.26.2。建议把这个目录重命名成nginx然后移动到固定位置。我自己习惯放在C:\nginx有两个原因。第一路径中不要出现中文、空格、括号。这不是玄学。Nginx的配置文件里大量使用相对路径相对路径的基准是Nginx的安装目录。如果目录名带中文在某些版本控制台的默认编码环境下日志和临时文件的读写可能出乱码。空格和括号则是可能在某些配置解析或编程调用场景下引起歧义。所以老老实实把路径取成C:\nginx这样最简单。第二不要让路径层级过深。像C:\Users\你的名字\Downloads\nginx-1.26.2这种路径日志文件路径会变得很长将来查找文件麻烦而且万一你的Windows用户名带中文又踩到上面的坑。放在盘符根目录下的nginx文件夹干净利落。解压完成后不要急着双击先打开目录看看结构。标准目录长这样C:\nginx ├── conf\ # 配置文件目录 │ ├── nginx.conf # 主配置文件 │ ├── mime.types # MIME类型映射表 │ └── ... ├── html\ # 默认网页目录 │ ├── index.html │ └── 50x.html ├── logs\ # 日志目录 │ ├── access.log # 访问日志 │ └── error.log # 错误日志 ├── temp\ # 运行时临时文件目录 └── nginx.exe # 主程序这里面要重点记住的是conf\nginx.conf、logs\error.log和html这三个。nginx.conf是核心后面大部分时间都在改它logs\error.log是排查问题时第一个要看的地方html是默认站点根目录测试Nginx是否启动成功就看这里面的index.html能不能正常访问。2.3 动手前的备份习惯Nginx的配置改起来很容易但改错了启动失败也容易。所以我建议在第一次修改nginx.conf之前养成一个习惯先复制一份原始配置作为备份。操作很简单在conf目录下把nginx.conf复制一份命名为nginx.conf.bak。不要小看这一步。我见过不止一个同事一顿操作猛如虎把配置文件里之前的可用配置覆盖没了想恢复却找不到原始内容最后只能重新下载安装包。有一份备份文件放在旁边任何时候出问题都能退回到最初的可运行状态。另外如果你熟悉版本管理工具建议把nginx.conf纳入版本控制。哪怕只是本地用Git管理也能随时看到每次改动的内容回退和复盘都比手动备份高效得多。3. 核心配置解析与实操要点3.1 配置文件的整体骨架打开conf\nginx.conf不管具体版本怎么变整体结构是稳定的。去掉注释后核心骨架长这样worker_processes 1; events { worker_connections 1024; } http { include mime.types; default_type application/octet-stream; sendfile on; keepalive_timeout 65; server { listen 80; server_name localhost; location / { root html; index index.html index.htm; } error_page 500 502 503 504 /50x.html; location /50x.html { root html; } } }很多第一次接触Nginx的人看到这个文件会觉得信息量很大其实拆开来看就三层意思。worker_processes是这个服务进程的工作进程数。Windows下默认是1就够了不要贪多。原因是Windows的进程模型和Linux不同多开几个worker进程并不会带来线性的性能提升反而会占用更多系统资源日志文件的操作也可能出现竞争。你要真在Windows下用Nginx处理高并发瓶颈几乎都在系统层不在worker数量上。events块里面有一个worker_connections表示每个worker进程能同时维持的最大连接数。默认1024本地调试完全够用。如果你知道你的场景连接数会比较高比如某个页面同时有很多长连接可以加到2048。但不建议在Windows下把这玩意的值调得过大原因和上面worker进程数一样Windows的系统限制就在那里。http块里先是一个include mime.types作用是把文件扩展名和HTTP响应时的Content-Type对应起来。比如访问a.png时告诉浏览器“这是图片类型”访问a.css时告诉浏览器“这是样式表类型”。没有这个include服务器可能会把所有文件都当成下载流浏览器打开页面时就会出现“样式丢失、图片不显示”这类问题。default_type则是兜底用的当找不到对应MIME类型时统一用application/octet-stream也就是当作普通二进制流处理。server块就是真正的一个“站点”了。listen 80表示监听80端口server_name localhost表示这个站点匹配的域名是localhost。这里的逻辑要理解Nginx可以配置多个server每个server有不同的域名和端口请求进来后Nginx会根据域名和端口决定走哪个server的配置。这就是最常见的虚拟主机功能。3.2 静态站点托管的配置写法静态站点托管是Nginx最基础的功能也是Windows下最常用的场景之一。假设你有一个网站构建产物在D:\projects\my-web\dist目录下你想让访问http://localhost时直接显示这个目录里的内容配置这样写server { listen 80; server_name localhost; location / { root D:/projects/my-web/dist; index index.html; } }这里有两个细节要特别注意。第一个是路径写法。Windows下写路径Nginx的配置里最好用正斜杠/而不是反斜杠\。比如上面写的D:/projects/my-web/dist写成D:\projects\my-web\dist在某些版本里也能识别但正斜杠是最保险的写法因为反斜杠在配置里可能被当作转义字符。这是Windows路径在Nginx里最容易踩的坑没有之一。第二个是root的行为逻辑。root指令表示“当请求进来时我把这个目录当作站点根目录”。浏览器请求http://localhost/index.htmlNginx会把请求的/index.html直接拼接在root后面实际查找D:/projects/my-web/dist/index.html。理解了“拼接”这个词后面区分root和alias就不会犯迷糊。配置改完先别着急重启建议先执行下面这条命令检查语法nginx -t如果输出configuration file test is successful说明语法没问题。如果有报错会明确指出配置文件里哪一行有问题跟着改就行了。3.3 反向代理与接口转发反向代理是Nginx的看家本领也是我在Windows上用得最多的功能。典型场景就是解决前端开发跨域前端跑在http://localhost:8080开发服务器后端接口在http://192.168.1.100:9000前端请求/api/login时被浏览器的同源策略拦截。用Nginx再开一个端口比如监听80把/api/开头的请求转发到后端同时返回给前端时保持在同一个域名端口下跨域问题就消失了。一个标准的反向代理配置块长这样server { listen 80; server_name localhost; location /api/ { proxy_pass http://192.168.1.100:9000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } }这里逐行解释一下。location /api/表示匹配所有以/api/开头的请求路径。proxy_pass http://192.168.1.100:9000;是核心它把匹配到的请求原封不动地转发给后面这个地址。但要注意proxy_pass后面有没有带路径对转发行为影响很大。比如你写的是http://192.168.1.100:9000不带路径那请求/api/login转发到后端后还是/api/login如果你写的是http://192.168.1.100:9000/带了根路径/那请求/api/login转发到后端后会被替换成/login。很多后端接口对接不上十有八九是这个问题。接着看三行proxy_set_header。这几行的作用是把客户端的原始信息传递给后端。Host $host告诉后端“客户端访问的域名是什么”X-Real-IP和X-Forwarded-For都用来传递客户端真实IP区别在于X-Real-IP只放一个IPX-Forwarded-For支持代理链场景可以在后面追加出多个IP。后端程序做日志或者风控时经常依赖这两个头。X-Forwarded-Proto告诉后端“客户端是用的HTTP还是HTTPS”如果后端会产生重定向链接这个头尤其重要。上面的配置基本能满足90%的本地联调需求。但如果你想部署的是纯前端静态站并且只代理接口那通常会把静态托管和代理写在同一个server里用不同的location区分server { listen 80; server_name localhost; # 静态文件托管 location / { root D:/projects/my-web/dist; index index.html; } # 接口反向代理 location /api/ { proxy_pass http://192.168.1.100:9000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }这样前端静态资源和后端接口就统一通过http://localhost进出了。前端代码里请求地址不用写绝对IP和端口直接用相对路径/api/xxx即可环境切换时只要改Nginx配置。3.4 location匹配规则与root/alias的区别location匹配规则是Nginx配置里最值得花时间理清的一块因为它决定了“你的请求到底走了哪段配置”。规则说起来不复杂但实际应用时经常出岔子。优先级从高到低排列是这样的精确匹配location /login只有路径完全等于/login时才命中。前缀匹配带^~location ^~ /static/一旦匹配上就不再检查后续正则。正则匹配location ~ \.php$或location ~* \.jpg$按正则表达式的规则匹配。普通前缀匹配location /api/只要路径以这个前缀开头就命中。这里有个容易让人混乱的点正则匹配的优先级其实高于普通前缀匹配。也就是说如果同时写了location /api/和location ~ \.do$一个请求/api/user.do会命中后者因为正则的优先级更高。要打破这个规则需要在前缀上加^~告诉Nginx“只要这个前缀匹配上了就别再去试正规则了”。网上能看到大量这类面试题或者踩坑帖但本地部署时更常见的是下面这个“root与alias的区别”问题。root和alias都用来指定文件路径但行为截然不同。root是把请求的完整URI拼接到目录后面而alias是把location匹配到的部分替换掉。举个例子location /static/ { root D:/projects/my-web/static-files; }请求/static/img/a.jpg时Nginx实际查找的文件路径是D:/projects/my-web/static-files/static/img/a.jpg。注意这里/static/前缀被保留并拼接到了root后面。如果你想让/static/对应到static-files目录本身那就得用aliaslocation /static/ { alias D:/projects/my-web/static-files/; }请求/static/img/a.jpg时实际查找的是D:/projects/my-web/static-files/img/a.jpg。区别看着不大但静态资源全部404、图片加载不出来的时候问题往往就在这里。顺带说一个实操小技巧配置里尽量统一用一种方式不要在这个server用root那个location又用alias时间久了记混了很麻烦。我自己在Windows部署时如果只是托管一个固定目录用root就够了只有需要“不同URL前缀映射到不同物理目录”时才用alias。4. 启动、重载与停止4.1 启动方式与进程关系Windows下启动Nginx有几种方式对应效果不同。方法一进入Nginx目录后在地址栏输入cmd然后把目录切到C:\nginx执行start nginx推荐这种方式。start是Windows的命令会新开一个独立窗口在后台运行Nginx当前命令行窗口不会被阻塞。方法二直接双击nginx.exe。这种方法也能启动但会弹出一个命令行窗口如果这个窗口被人顺手关了Nginx也可能跟着退出。在正式使用环境里我不建议这种方式。启动后可以用浏览器访问http://localhost看到Nginx的默认欢迎页面就说明成功了。这里要理解一下Nginx的进程模型。执行nginx.exe后系统里会出现多个nginx相关进程。一个是master进程主进程负责读取配置、管理worker一个是或者多个worker进程负责实际处理请求。Windows任务管理器里看到多个nginx.exe是正常的不是启动重复了。真正的“启动重复”是你多次执行nginx.exe且第一次的进程没退出导致多个master进程共存这是需要避免的。查看当前是否已有Nginx进程运行tasklist | findstr nginx如果看到两行及以上结果说明Nginx在正常运行状态。4.2 配置校验、重载与优雅退出每次修改完nginx.conf后都需要让Nginx重新加载配置才能生效。但加载前先做一件事校验。nginx -t这条命令会检查配置文件的语法并且验证引用的文件路径是否存在。如果输出successful放心执行重载nginx -s reloadreload的行为值得细说。它会先对新配置做一次语法检查通过后让master进程平滑地加载新配置worker进程逐个重启正在处理的请求不会被中断。如果新配置有问题master会保留旧配置继续运行不会直接退出。这个机制非常优秀线上服务也不会因为一次错误配置就瘫痪。但Windows下有一个特殊情况和Linux行为不完全一致。如果你配置文件里出现了严重问题比如监听端口被占用、路径指向不存在的目录reload有可能让整个服务直接挂掉而不是像Linux那样平滑处理。这种差异虽然不常遇到但再次印证了“改完配置先nginx -t再reload不要跳过校验直接reload”的必要性。停止Nginx有两种方式# 快速停止 nginx -s stop # 优雅停止 nginx -s quitstop是立刻终止进程不管有没有请求正在处理。quit是优雅退出master进程会等worker进程处理完当前请求后再结束。日常本地调试用哪个都行但如果Nginx正在服务一个重要请求建议用quit。4.3 把常用命令封装成批处理Windows下没有Linux那种灵活的命令别名机制每次敲nginx -t、nginx -s reload要切换到Nginx目录路径一长就很烦。我的解决方案是把常用操作封装成.bat文件放在Nginx目录之外再用快捷方式引用用的时候双击或拖到命令行执行。重载配置的批处理可以这样写echo off cd /d C:\nginx nginx -t if %errorlevel% neq 0 ( echo [ERROR] configuration test failed. pause exit /b 1 ) nginx -s reload echo [OK] nginx reloaded. pause核心逻辑是先校验校验失败就停住并提示校验成功才执行reload。%errorlevel%是Windows命令行的环境变量保存上一条命令的退出码0表示成功、非0表示失败。这个批处理能帮你避免“改坏配置后直接reload导致服务挂掉”的尴尬。同样道理可以再做几个配套文件一个start-nginx.bat执行start nginx并检查进程一个stop-nginx.bat执行nginx -s quit并确认进程退出。这套小工具用起来非常顺手而且不依赖任何第三方软件Windows自带的记事本就能写。5. 常见问题排查实录与避坑清单5.1 高频故障速查表整理了一张我在Windows上部署Nginx时高频遇到的故障排查表每个问题都是实际踩过坑换来的。遇到问题先对照这张表定位大概率能直接解决。现象可能原因快速排查方法启动后浏览器打不开80端口被占用netstat -ano | findstr :80查看占用进程结束进程或改listen端口修改配置后不生效没有执行reload执行nginx -t后nginx -s reload访问静态资源404root路径拼接错误检查root后路径是否包含location前缀前端接口跨域代理配置缺失确认location /api/和proxy_pass是否存在且匹配页面文字乱码缺少字符集配置在http块或location中加入charset utf-8;访问目录时403目录索引未开启或权限不足需要看目录时加autoindex on;检查Nginx对目录是否有读取权图片样式丢失include mime.types;被注释或删除恢复include mime.types;这一行启动报bind() ... 10013端口被占用或权限不足以管理员身份运行命令行检查端口占用日志不写入日志目录权限不足确认logs目录存在且当前用户可写代理转发后接口404proxy_pass带路径导致URI被替换确认proxy_pass末尾是否带/按需调整表格里的每个问题我都在实际操作中遇过尤其是代理404和端口占用这两个出现的频率几乎占到了一半以上。5.2 几个典型的逻辑坑除了表格里的高频问题还有几个“表面现象能对上排查表但实际逻辑完全不同”的坑值得单独抽出来讲。第一个坑是Windows下多个nginx.exe进程并存时修改配置文件总是不生效。这个问题最迷惑人。当你以为已经reload了配置但实际请求却总是走到旧逻辑浏览器里看到的还是老页面。排查时用tasklist | findstr nginx看进程如果发现两个master进程都存在那你刚才reload的其实是其中一个而真正接收请求的可能是另一个。出现这种情况一般是因为之前用双击方式启动过一次后来又在命令行里启动了一次。处理方法是全部停掉然后只用一种方式重新启动之后保持“只通过批处理或命令行管理”的习惯。第二个坑是Windows路径转换。配置文件里写静态目录路径时用了反斜杠比如D:\projects\my-web\dist由于Nginx配置里反斜杠在某些指令中存在转义行为可能导致目录找不到日志反复提示open()路径失败。之前在3.2里提过正斜杠的事但这里再强调一次因为真实环境里很多人改完路径后怎么看都“没问题”最后才发现是斜杠方向的事。统一使用正斜杠在配置里写路径是最省心的做法。第三个坑是端口占用与管理员权限纠缠在一起。默认listen 80如果你系统里装了其他Web服务数据库控制台、开发工具、旧的Tomcat很可能把80端口占了。在命令行执行netstat -ano | findstr :80会看到一个PID对应占用端口的进程然后去任务管理器里找到这个进程结束掉或者直接把Nginx的listen改成8080等其它端口先保证服务能起来。但要记住Windows上访问80端口有时会涉及http.sys这个系统组件某些端口对非管理员进程有访问限制出现这种情况需要右键“以管理员身份运行”命令行再启动Nginx或者改用大于1024的高位端口。5.3 日志排查的顺序与技巧Nginx在Windows下使用过程中的绝大多数问题都能通过日志找到线索。日志文件在logs目录下关键的是error.log和access.log。access.log记录每一次请求的详情error.log记录处理请求时的错误。排查问题的顺序建议是先看error.log再看access.log最后结合浏览器开发者工具的Network面板对照。打开logs\error.log最常见的信息格式类似2024/11/12 10:15:30 [error] 1234#5678: *789 connect() failed (10061: No connection could be made because the target machine actively refused it) while connecting to upstream看到connect() failed基本可以确定是proxy_pass配置的后端地址和端口没有服务在监听。你配置的转发目标是http://127.0.0.1:8080但8080端口的服务挂了或者根本没启动就会报这个错。这时候先手动访问一下后端地址确认服务状态再回头看Nginx的配置。看到open()相关错误时通常和静态文件路径有关。比如open() D:/projects/my-web/dist/index.html failed (2: No such file or directory)这是在告诉你Nginx按配置找路径但那个位置没有文件。这时就沿着路径检查是目录不存在还是root拼接逻辑不对还是路径斜杠写错了。所有排查信息都直接给到点子上。还有一个容易被忽略的技巧Windows版的Nginx在启动瞬间如果配置有问题会直接在命令行窗口里输出错误信息这些信息往往比日志更直白。如果你通过批处理或命令行启动时发现有红色报错不要急着关窗口先仔细读一遍。带[emerg]的是最严重级别直接导致启动失败。最后分享几点我自己的使用习惯写到最后说几个我自己在Windows上长期使用Nginx积累下来的习惯也许能帮你少走一些弯路。第一个习惯是“每次修改配置后先nginx -t再reload不要跳步”。这个习惯看似简单但坚持下来真的能避免很多事故。尤其是在改动了多个server块或者location块之后一个不小心就会留下语法错误不校验直接reload的话轻则配置不生效重则整个服务挂掉。nginx -t只要两秒钟却能守住最后的底线。第二个习惯是“凡是路径先正斜杠再检查斜杠”。我在前面反复提到正斜杠的问题因为实际踩过的坑太多。无论是静态文件路径、日志路径还是proxy_pass路径统一用正斜杠几乎可以规避一大类Windows特有的路径解析问题。偶尔遇到用nginx -t也发现不了的逻辑错误我会把Nginx配置里的路径复制出来直接在资源管理器地址栏粘一份“正斜杠版”看看能不能访问到能访问到就说明路径本身没问题问题多半出在拼接逻辑上。第三个习惯是“一人一套批处理工具”。刚接触Windows版Nginx时我用的都是从网上找来的现成脚本后来发现每个人的Nginx目录位置不同、常用命令不同用别人的脚本反而别扭。自己花十分钟写一套适配自己目录的批处理把校验、重载、停止、启动四个操作固化下来之后的日常维护效率会肉眼可见地提升。如果你还想再进一步完全可以配合任务计划程序实现开机自启或者利用计划任务周期性地检查Nginx进程是否存活、异常退出时自动拉起。这套扩展玩法在Windows上非常实用有机会可以单独开一篇讲讲。Nginx在Windows上的部署本质上就是“配置”和“进程管理”两件事。配置弄明白了进程管理顺畅了后续不管切到Linux还是容器环境核心思路都是相通的。希望这篇文章能帮你把前几步走稳少踩几个我已经趟过的坑。