Nginx源码编译实战：参数规划、模块选择与平滑升级-北京尧图网络

1. 先想清楚什么时候值得自己编译 Nginx包管理器一条命令就能把 Nginx 装上配置文件在/etc/nginx日志在/var/log/nginx服务脚本人家已经帮你写好了。既然这么省事为什么还要折腾源码编译这个问题我在带新人的时候被问过不止一次而每次我的回答都差不多源码安装解决的从来不是“能不能跑起来”的问题而是“跑起来的东西能不能被我完全控制”的问题。主流发行版仓库里的 Nginx 版本普遍偏旧这是常识。更要命的是仓库版本为了兼容性和稳定性往往把一堆模块裁掉了或者把一些模块编成了动态模块你想加载还得额外装包。等你要用到某个特性——比如四层 TCP 转发、比如 HTTP/2、比如某个第三方模块——你会发现系统自带的那个二进制文件根本给不了你这时候除了重编译没有第二条路。还有一种情况特别常见线上机器的 OpenSSL 版本是系统自带的而那个版本可能已经比较老了你想让 Nginx 用上新版本的 TLS 能力靠换系统库是不现实的因为一旦改动系统的 OpenSSL会连带影响一整片依赖它的程序。源码编译允许你把指定版本的加密库直接静态链接进 Nginx 二进制里形成一个相对独立、自包含的可执行文件这在无法随意改动运行环境的情况下是一个相当非常规但确实有用的做法。最后一种情况是定制化。你的业务可能需要打补丁、可能需要裁剪掉用不到的模块来压体积、可能需要在编译期就把一些路径写死以便和内部规范对齐。这些操作在二进制包上全都做不了只能从源码开始。我把这三类场景整理成了一张表对照着看更直观场景仓库二进制包源码编译关键差异点想用最新稳定版本只能等发行版跟进自己按需选版本版本迭代节奏由自己掌控需要 HTTP/2、stream 四层代理常被裁剪成独立包参数里加一行就有模块归属清晰可控需要第三方模块基本不支持--add-module即可这是二进制包的根本短板需要静态链接指定 OpenSSL做不到--with-openssl指定源码环境隔离性更好部署速度一条命令几分钟首次编译 10 分钟以上源码安装的时间成本真实存在后续安全更新包管理器一条命令需要重新编译替换二进制这是源码安装最容易被低估的负担这张表我想多解释一句很多文章在讲源码安装时只讲“更灵活、更可控”却不提它的代价。代价就是后续每一次版本更新和安全补丁你都得自己重新走一遍编译流程包括参数校验、二进制替换和回归验证。如果你的机器只有两三台、Nginx 只做简单的反向代理和静态资源服务我的建议是老老实实用包管理器装把运维精力放在更有价值的地方。源码编译真正划算的场合是机器规模到一定程度、或者有一个绕不开的模块需求。至于这篇文章适合谁看完全没编译过 Nginx 的可以照着走一遍把流程和参数吃透踩过坑的老手可以重点看第三、第五、第六部分那里讲的都是参数取舍和排错细节是文档里不太会写的东西。2. 编译环境准备与依赖取舍2.1 最小依赖清单以及每个依赖到底在干什么很多人编译失败不是因为参数写错而是因为依赖没装全报错信息又看不懂。所以在敲./configure之前先把依赖这件事说清楚。Nginx 的源码编译有三组依赖分两个层次第一层是编译工具链也就是 gcc、make 这一套以及头文件包。Debian 系叫build-essentialRHEL 系叫gcc gcc-c make。这层没什么可说的缺了连 configure 都跑不起来。第二层是功能依赖库这三个是重点库作用缺失时的后果是否可以不用PCRE / PCRE2提供正则表达式引擎location里的正则匹配、rewrite指令全靠它configure 直接报错退出或运行时rewrite不可用用--without-http_rewrite_module可以绕过但基本没人这么干zlib提供 gzip 压缩能力gzip on无法编译进去--without-http_gzip_module可绕过OpenSSL提供 TLS、哈希、证书处理所有带ssl后缀的模块都编不进去不用 HTTPS 就不需要这三个库每个都有两种用法这个区别必须搞清楚否则你会遇到很奇怪的报错用系统预装的开发包直接装libpcre3-dev、zlib1g-dev、libssl-dev这类包configure 时不需要加任何参数Nginx 会自动去找系统里的库。用自定义版本的源码目录下载对应库的源码并解压configure 时用--with-pcre/path/to/pcre-src指过去。注意第二种方式里的路径指的是源码目录不是安装目录。Nginx 在编译过程中会自己去那个目录里构建这些库所以那个目录必须包含完整的源码文件configure、Makefile.in之类而不是已经装好的.so和头文件。这一点坑过很多人有人把库装到/usr/local/openssl然后写--with-openssl/usr/local/openssl结果编译报错找不到文件因为那里只有安装产物没有源码。提示判断该用哪种方式看你的需求。只是想让 Nginx 能跑 HTTPS系统包足够想要特定版本的 OpenSSL比如需要较新的 TLS 能力才用源码目录的方式并且要做好后续手动跟进安全更新的心理准备。2.2 版本兼容性几个容易踩到的地方依赖装全了不等于能编过版本组合也有讲究。OpenSSL 3.x 与老版本 Nginx 的兼容问题。如果你打算用源码方式链接一个比较新的 OpenSSL同时 Nginx 版本又比较老编译阶段可能会冒出一堆废弃 API 的告警甚至直接报错。稳妥的组合是Nginx 用较新的稳定版或主线版OpenSSL 用 1.1.1 系列或 3.x 系列中较新的小版本。如果 Nginx 版本实在老就别硬上新 OpenSSL。PCRE1 和 PCRE2 的区分。较新的 Nginx 版本已经支持 PCRE2对应参数是--with-pcre后面指向 PCRE2 的源码目录configure 的输出里会明确告诉你它用的是 PCRE2 还是 PCRE。如果你用系统包装libpcre2-dev就对了如果两个版本的开发包都装了以 configure 输出为准。gcc 版本过低。老系统上 gcc 可能是 4.x编译一些新版本的开源代码时会遇到语法不支持的问题。这种情况要么升级工具链要么换一个旧一点的 Nginx 版本硬扛没意义。还有就是磁盘和内存。完整编译一次 Nginx 加 OpenSSL中间产物加上最终二进制几百 MB 是跑不掉的/tmp分区给小了的机器上容易在中途报“No space left on device”。另外make -j开太高在低配机器上会触发 OOM Killer编译进程被直接杀掉报错信息往往只有一句Killed看起来莫名其妙。我的做法是核数少于 4 的机器就make -j24 核及以上再make -j$(nproc)稳妥优先。3. 编译参数怎么定逐个说清楚为什么3.1 路径类参数一次性把目录规划好configure 的路径参数有十几个全写出来很长但每一个都对应一个实际的文件位置。不写也能编过Nginx 会全用相对于--prefix的默认值但那样的话日志、配置、临时文件全挤在一个目录里后期做日志切割、做监控、做权限隔离都会很难受。下面这份是我常用的路径规划可以直接抄./configure \ --prefix/usr/local/nginx \ --sbin-path/usr/local/nginx/sbin/nginx \ --conf-path/usr/local/nginx/conf/nginx.conf \ --pid-path/usr/local/nginx/run/nginx.pid \ --lock-path/usr/local/nginx/run/nginx.lock \ --error-log-path/usr/local/nginx/logs/error.log \ --http-log-path/usr/local/nginx/logs/access.log \ --http-client-body-temp-path/usr/local/nginx/temp/client_body \ --http-proxy-temp-path/usr/local/nginx/temp/proxy \ --http-fastcgi-temp-path/usr/local/nginx/temp/fastcgi \ --http-uwsgi-temp-path/usr/local/nginx/temp/uwsgi \ --http-scgi-temp-path/usr/local/nginx/temp/scgi \ --usernginx \ --groupnginx逐条解释几个容易理解的点和容易误解的点--pid-path单独设成run/目录是我个人习惯。很多运维脚本、监控采集、systemd 单元文件都要读这个 pid 文件把它从logs/里分离出来语义更清楚权限也好单独控制。--user和--group指定的是worker 进程的运行账号不是 master 进程。master 依然以 root 身份启动否则没法绑定 80 和 443 端口然后通过 setuid 把 worker 降权到这个账号。所以这个账号必须在编译前就存在否则启动时会报“getpwnam failed”类似的错误。创建时建议加-r -s /sbin/nologin让这个账号纯粹用于运行服务不具备登录能力。那五个temp-path是临时文件目录处理大请求体、代理转发、FastCGI 交互时都会往这里写。默认值相对--prefix分布我统一收拢到temp/下一个层级。这里有个必须记住的点这些目录 Nginx 不会自动创建只在启动时检查。目录不存在就会启动失败报错形如nginx: [emerg] mkdir() /usr/local/nginx/temp/client_body failed (2: No such file or directory)所以安装完成后第一件事就是mkdir -p把这些目录建出来并且把属主改成 worker 账号。后面第五部分还会再提一次因为这是最高频的启动失败原因之一。3.2 模块参数加什么、减什么心里得有数模块参数是区分“能跑”和“好用”的关键。默认情况下 Nginx 会编入一大批基础模块你需要额外打开的是那些默认关闭的。先说 SSL 和 HTTP/2--with-http_ssl_module \ --with-http_v2_module \--with-http_ssl_module是 HTTPS 的前提没它连ssl_certificate指令都认不出来。--with-http_v2_module提供 HTTP/2 支持但它依赖 SSL 模块两者必须一起加否则 configure 会直接拒绝。这一点很多教程没写清楚导致有人只加 v2 编译失败还找不到原因。再说几个实用但常被忽略的--with-http_realip_module \ --with-http_stub_status_module \ --with-http_gzip_static_module \ --with-http_sub_module \ --with-http_secure_link_module \ --with-threads \ --with-file-aio \--with-http_realip_module在 Nginx 前面还有一层负载均衡或者 CDN 的时候几乎是必需的否则 access.log 里记录的全是上一跳的地址排查问题时会怀疑人生。--with-http_stub_status_module提供一个极简的状态页暴露连接数、请求数这些指标。功能很朴素但接监控采集的时候它是最省事的数据源。--with-http_gzip_static_module和--with-http_gzip_module不是一回事前者是直接返回已经预压缩好的.gz文件省掉 CPU 压缩开销后者是实时压缩。两个都编进去配置里按需开启。--with-threads是线程池支持配合aio threads使用在处理大量慢磁盘 IO 的场景下有用。--with-file-aio是异步文件 IO注意它在某些文件系统上不一定生效实际效果需要压测验证别照抄配置就以为生效了。如果要做四层代理加上 stream 相关模块--with-stream \ --with-stream_ssl_module \ --with-stream_realip_module \--with-stream是四层转发的入口做数据库代理、TCP 负载均衡都靠它。--with-stream_ssl_module让它能处理 TLS 四层透传或终止。这两个模块默认都不编译需要显式开启。如果要加第三方模块静态方式用--add-module/path/to/module动态方式用--add-dynamic-module/path/to/module。动态方式的好处是模块以.so形式存在将来增删模块不需要重新编译整个 Nginx但前提是编译主程序时要加--with-compat这个参数会放宽模块 ABI 的校验让动态模块能在不同小版本之间通用。不加--with-compat而用动态模块加载时可能报“module is not binary compatible”这个报错很多人看不懂其实就是 ABI 不匹配。至于裁剪如果你确定用不到某些功能可以反向关掉来减小体积--without-http_autoindex_module \ --without-http_ssi_module \ --without-mail_pop3_module \ --without-mail_imap_module \ --without-mail_smtp_module \mail 那三个模块默认是编进去的除非你真的用 Nginx 做邮件代理否则关掉能省一点体积也能减少潜在的攻击面。不过说实话省下来的体积有限我更倾向于保留默认除非有明确的安全审计要求。3.3 编译器优化参数别乱加也别不加--with-cc-opt和--with-ld-opt这两个参数控制编译和链接时的额外选项。不写也能编过但生产环境通常会把一些安全加固选项写进去。--with-cc-opt-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE2 -fexceptions -fstack-protector-strong --paramssp-buffer-size4 \ --with-ld-opt-Wl,-z,relro -Wl,-z,now这几个选项的作用值得说一下-O2是常规优化级别兼顾性能和编译时间。不建议上-O3收益不明显还可能引入一些难以复现的行为差异。-fstack-protector-strong加上-Wl,-z,relro -Wl,-z,now是一组常见的二进制加固措施前者做栈溢出保护后两者让 GOT 表在加载后只读能提高一些利用门槛。这类加固在现代发行版的默认编译选项里基本都有了自己写上去算是显式声明。-g保留调试符号会显著增大二进制体积可能翻好几倍。如果追求二进制精简可以把-g去掉如果将来可能需要用 gdb 排查崩溃就留着。我一般线上包会去掉-g排障时再单独编一个带符号的版本。还有一个坑要提-Wp,-D_FORTIFY_SOURCE2在很老的 gcc 上可能不被支持会报一堆告警甚至警告升级为错误。遇到这种情况把这一项从参数里删掉即可不影响功能。4. 走一遍完整的编译安装流程4.1 下载、校验、解压流程上有几个细节决定了后面顺不顺利。第一步选版本。下载页面上有主线版和稳定版两条线我的建议是新上线的项目用稳定版追求新特性且有能力跟进问题的用主线版。不要用太老的版本尤其是安全更新已经停止的版本。第二步下载。拿到源码包后用curl或wget拉下来即可。这里我要强调的是校验下载完成后核对一下官方提供的校验值这一步在很多人眼里是形式主义但它能避免下载到不完整的包——网络中断导致的截断包解压后会在编译中途以莫名其妙的语法错误暴露出来排查成本远高于花十秒钟做一次校验。# 下载后核对哈希 sha256sum nginx-1.xx.x.tar.gz # 与发布页给出的值逐字比对第三步解压然后进入源码目录。解压出来的目录里结构很清晰src/是源码auto/是 configure 脚本用的探测逻辑conf/是默认配置模板objs/是编译后才生成的。第一次解压是看不到objs/的。4.2 configure把参数落地把第三部分整理好的参数拼成一条完整命令执行。这一步的执行时间不长但输出信息很值得读它会告诉你哪些模块被编入、用了哪个版本的 PCRE、用的是哪个 gcc、生成了哪些 Makefile。cd nginx-1.xx.x ./configure [上面那一长串参数]执行完之后建议立刻做一次确认./objs/nginx -V注意这里用的是objs/下的临时二进制不是安装后的。-V会输出编译时的所有参数这也是最实用的参数恢复技巧如果你接手一台已经装好 Nginx 的机器想知道当初是怎么编译的一条nginx -V就能拿到完整参数列表照着抄就能复现同样的编译环境。这个技巧在接手别人的环境时几乎必用。configure 的输出里如果有 using PCRE2 library这样的字样说明它找到的是 PCRE2如果只写 PCRE那可能是 PCRE1。两种都能正常工作但如果你明确需要 PCRE2就得回头检查开发包有没有装对。4.3 make控制并行度看着点内存make -j$(nproc)这一步是耗时大头。执行期间会看到大量cc -c的输出刷屏属于正常现象。这里两个提醒第一-j的数值别贪大。$(nproc)在大多数场景下是安全的但在容器环境里nproc返回的可能是宿主机核数而不是容器配额并行度过高会导致内存撑爆。容器里编译建议手动指定-j2或-j4。第二如果编译失败不要直接从头再来。看看报错信息注释掉可疑参数尤其是第三方模块改完重新跑 configure make。make clean能清掉上次的中间产物避免旧目标文件干扰。编译成功后会生成objs/nginx可以用ls -lh看看大小正常范围在几 MB 到十几 MB 之间带-g的可能几十 MB。4.4 make install 与目录结构确认make install这一步做的事情很简单把编译好的二进制、默认配置、页面文件按--prefix和路径参数复制过去。执行完之后重点检查这几件事/usr/local/nginx/sbin/nginx -V # 参数是否和预期一致 /usr/local/nginx/sbin/nginx -t # 配置语法检查此时会暴露临时目录缺失问题 mkdir -p /usr/local/nginx/temp/{client_body,proxy,fastcgi,uwsgi,scgi} chown -R nginx:nginx /usr/local/nginx/tempnginx -t这一步非常关键它会在真正启动前把配置和路径问题都暴露出来。如果报临时目录不存在就按上面的命令创建如果报 pid 目录不存在同理创建。把所有报错在-t阶段解决掉比启动失败后再去翻错误日志效率高得多。再确认一下 worker 账号存在id nginx不存在的话需要先创建。5. 装完之后把它变成一个真正的系统服务5.1 用 systemd 接管进程管理make install只给你一个二进制文件开机自启、异常重启、优雅重载这些能力都得自己补上。现代发行版统一用 systemd写一个单元文件是最省事的做法。[Unit] DescriptionNginx Web Server Afternetwork.target remote-fs.target nss-lookup.target [Service] Typeforking PIDFile/usr/local/nginx/run/nginx.pid ExecStartPre/usr/local/nginx/sbin/nginx -t -q -g daemon on; master_process on; ExecStart/usr/local/nginx/sbin/nginx ExecReload/usr/local/nginx/sbin/nginx -s reload ExecStop/bin/sh -c /usr/local/nginx/sbin/nginx -s quit; while kill -0 $(cat /usr/local/nginx/run/nginx.pid) 2/dev/null; do sleep 0.5; done [Install] WantedBymulti-user.target几个设计取舍解释一下Typeforking是因为 Nginx 默认以守护进程方式启动master 进程会 fork 出去然后父进程退出systemd 需要靠PIDFile来跟踪真正的 master 进程号。ExecStartPre里跑一次nginx -t是很有价值的保险配置写错了直接启动失败而不是启动成功之后再莫名其妙地 500。加-q是为了只在出错时输出正常启动不刷屏。ExecStop里用-s quit而不是-s stop是因为quit是优雅退出会等待正在处理的请求完成而stop是快速退出会直接断开连接。线上服务用优雅退出。后面接一段轮询等待 pid 消失是为了确保 systemd 认为服务完全停止否则可能出现“已经执行过 stop但进程还在、systemd 又拉不起来”的状态。ExecReload用nginx -s reload这是平滑重载不中断连接。写完之后执行systemctl daemon-reload让它生效然后systemctl enable --now nginx。5.2 日志切割别让 access.log 吃到磁盘满这是源码安装和包管理器安装差距最大的一块。包安装会顺带装一个 logrotate 配置源码安装什么都不给你日志文件会一直增长直到把磁盘吃满——等到服务报“No space left on device”才发现损失就大了。Nginx 的日志切割机制很直观master 进程会监听一个信号收到之后重新打开所有日志文件。所以切割流程是“重命名旧文件 → 发信号让 Nginx 重新打开新文件”。系统一般自带 logrotate写一份配置放进去就行/usr/local/nginx/logs/*.log { daily rotate 14 missingok notifempty compress delaycompress sharedscripts postrotate [ -f /usr/local/nginx/run/nginx.pid ] kill -USR1 $(cat /usr/local/nginx/run/nginx.pid) endscript }USR1就是那个“重新打开日志文件”的信号。sharedscripts保证多个日志文件只触发一次信号避免重复执行。delaycompress让最近一份日志保持未压缩状态方便你 inmediat 排查问题——这一点很实用很多时候问题刚发生你就需要去 grep 刚被切割的那个文件。注意如果切割后日志没有写到新文件而是继续写到了带日期的旧文件名里几乎可以确定是信号没发到或者 pid 文件路径写错了。先确认 pid 文件里那个进程号确实存在再手动执行一次信号发送验证。5.3 二进制升级与平滑替换源码安装最容易被忽略的日常工作是升级。等出了安全更新你需要重新编译一个二进制然后替换掉正在运行的那个。这里的关键是不要直接make install覆盖在线服务的文件。正确做法是新版本编译好之后把objs/nginx拷到 sbin 目录先备份旧的然后通过信号做平滑升级# 1. 备份旧二进制 mv /usr/local/nginx/sbin/nginx /usr/local/nginx/sbin/nginx.old # 2. 放入新的 cp objs/nginx /usr/local/nginx/sbin/nginx # 3. 检查新旧二进制是否可用 /usr/local/nginx/sbin/nginx -t # 4. 向 master 进程发送平滑升级信号 kill -USR2 $(cat /usr/local/nginx/run/nginx.pid)USR2会让 master 启动一个新的 master 进程新进程沿用旧进程的监听端口通过文件描述符继承同时旧的 pid 文件会被重命名为nginx.pid.oldbin。此时新旧两套进程并存新进程开始接新连接。确认新进程工作正常、旧进程的请求处理完之后再发QUIT给旧 master 让它退出kill -QUIT $(cat /usr/local/nginx/run/nginx.pid.oldbin)如果发现新版本有问题要回滚流程是反的给旧 master 发HUP让它重新接管给新 master 发QUIT让它退出。这个流程比“停机换二进制再启动”复杂不少但换来的是零停机。高频交易的场景下这几分钟的差别很重要而如果只是内部管理系统停机两分钟换二进制完全能接受没必要走这套流程。还有一点升级时不只是换二进制。如果新版本引入了配置指令的变更配置也要跟着改如果编译参数变了比如新加了模块要重新确认-V输出如果有动态模块.so文件也需要同步更新。这几件事漏一件都可能导致升级后功能异常。6. 常见报错与排查速查6.1 编译阶段configure 与 make 的典型报错configure 阶段最常见的报错是依赖缺失报错文本通常很直白./configure: error: the HTTP rewrite module requires the PCRE library.这句的意思是找不到 PCRE。解决方式二选一装libpcre3-devDebian 系或pcre-develRHEL 系或者用--with-pcre指向源码目录。同理SSL modules require the OpenSSL library对应 OpenSSL 开发包缺失。另一个高频报错是./configure: error: the invalid value in --with-ld-opt-Wl,-z,relro -Wl,-z,now这种情况多见于引号处理不当或者在参数里混入了 shell 会解释的特殊字符。检查引号是否成对参数之间是否有不可见字符。make 阶段我遇到最多的是两种。第一种是fatal error: xxx.h: No such file or directory头文件缺失回头补对应的-dev包即可。第二种是编译到一半进程直接消失只留一个Killed这就是内存被 OOM Killer 干掉了降并行度重来。还有一种是第三方模块导致的编译失败报错五花八门。排查思路很简单把--add-module相关的参数去掉重新 configure如果就能编过说明问题在那个模块上去看它的 README 和兼容的 Nginx 版本范围。6.2 运行阶段启动就挂掉怎么查启动阶段的报错第一个要看的是nginx -t的输出第二个是error.log。nginx: [emerg] mkdir() /usr/local/nginx/temp/client_body failed (2: No such file or directory)临时目录不存在前面讲过了建目录改属主。nginx: [emerg] getpwnam(nginx) failedworker 账号不存在。id nginx确认一下不存在就创建注意要-r -s /sbin/nologin。nginx: [emerg] bind() to 0.0.0.0:80 failed (13: Permission denied)端口被占或者权限不足。80 以下端口需要 root 或者相应的能力配置。检查端口占用用ss -lntp | grep :80。nginx: [emerg] open() /usr/local/nginx/run/nginx.pid failed (2: No such file or directory)pid 目录不存在建一下即可。还有一类问题不报错但行为异常比如 502。这时候别急着改配置先看 error.log 里的 upstream 记录通常是后端地址不通、超时设置不合理或者 SELinux 之类的强制访问控制把出站连接拦了。最后这个坑很隐蔽因为报错信息里会写Permission denied而不是“连接被拒绝”容易往权限配置的方向误判。排查方法是用getenforce看看状态再对照审计日志确认。6.3 一张速查表遇到问题先对号入座现象最可能原因处理方向configure 报 PCRE 缺失开发包未安装或路径不对装 dev 包或--with-pcre指源码configure 报 OpenSSL 缺失同上装 dev 包或--with-openssl指源码configure 报 v2 模块错误缺少 SSL 模块补上--with-http_ssl_modulemake 中途Killed内存不足降低-j并行度make 报头文件找不到对应 dev 包缺失按报错文件名补包启动报 temp 目录不存在临时目录未创建mkdir -p 改属主启动报 getpwnam 失败worker 账号不存在创建系统账号启动报 80 端口权限不足端口被占或非 root 启动查占用确认启动身份动态模块加载失败主程序未加--with-compat重新编译主程序reload 后配置不生效配置语法有误但未检查先nginx -t再 reload日志切割后仍写旧文件信号未送达检查 pid 路径与USR1平滑升级后新旧并存旧 master 未退出对.oldbin发QUIT这张表我建议收藏实际工作中前六行覆盖了绝大多数情况。剩下的几行属于偶发问题但一旦遇到知道往哪个方向查能省很多时间。最后分享一个我自己的习惯每次编译完把完整的nginx -V输出和 configure 命令一起存到代码库里文件名叫build-notes.md。看起来是个小事但等到半年后需要重新编译、或者需要在新机器上复现一套一模一样的环境时这份记录就是救命的。我吃过一次亏当时凭印象重新写参数结果漏了一个模块上线后某个四层转发规则失效回头才发现是编译参数少了--with-stream。从那以后这个习惯就再没断过。

Nginx源码编译实战：参数规划、模块选择与平滑升级

相关推荐

AI科研插图生成：结构化提示词与JSON配置实践

APK反编译工具链实战：apktool、dex2jar与jd-gui完整拆包指南

把出路拆成可执行清单：能力、副业、财务与学习复利

更多资讯

text-to-CAD技术原理与工程落地：从自然语言生成STEP/URDF/DXF

impeccable CLI：基于PRODUCT.md与WebAuthn的零配置浏览器扩展交付范式

t3code CLI：Web开发者跨端调试工具（Electron+iOS）

OpenMontage：面向AI视频生产的Agent原生编排平台

自动排课系统实战：贪心+局部搜索实现课程表算法

t3code：个人开发工作台的模板、片段与脚本实战

今日更新

Agent-Reach：打通大模型触达外部系统的最后一公里

深度学习图像隐写分析实战：从CNN原理到毕设源码全解析

AI赋能知识产权供需匹配：专利评估、需求挖掘与多路召回工程实践

本周精选

防幻觉智能体架构：电源硬件设计中的大模型编排与工具化实践

OpenGL面试核心考点：渲染管线、矩阵变换与性能排查全解析

全国计算机二级C语言真题PDF高效刷题指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？