企业官网建设流程全解析

1. 三种安装方式全景对比：先想清楚再动手

玩Nginx这么多年，我见过太多人一上来就apt install nginx或者yum install nginx，装完就扔那儿不管了。等哪天想加个模块、想改个安装路径、想把配置统一管理，才发现当初的安装方式把自己坑死了。Nginx的安装方式从大的方向分就三种：源码编译安装、包管理器安装、Docker容器化安装。每一种都不是随便选的，背后对应的是完全不同的使用场景和维护成本。

我先说说这三种方式各自解决什么问题。源码编译安装，适合那种对Nginx功能有特殊要求的场景，比如你要加第三方模块、要定制编译参数、要把Nginx装到指定目录，这时候只有源码编译能满足你。包管理器安装，适合90%的常规场景，无论是个人博客还是中小型业务，apt或者yum一条命令搞定，后续升级也省心。Docker容器化安装，适合追求环境隔离、快速交付、多环境一致性的场景，特别是微服务体系里，Nginx作为网关或者反向代理容器跑，跟业务服务一起编排，管理起来非常顺手。

三种方式用一句话概括：源码方式是"自己盖房子"，包管理器是"买精装房"，Docker是"拎包入住、随时搬家"。你选哪种，取决于你手头有多少时间、多少运维精力、以及对Nginx可控程度的要求。

1.1 源码编译安装：自由度和可控性的天花板

源码编译安装本质上是把Nginx的源代码下载到你服务器上，然后通过configure脚本检测当前系统的环境，生成对应的Makefile，最后make编译、make install安装到你要的目录。

这种方式的最大优势是自由度。你可以完全控制安装路径、编译选项、加载哪些模块、不加载哪些模块。比如生产环境需要SSL支持，那就加--with-http_ssl_module；需要查看实时连接状态，就加--with-http_stub_status_module。这些在包管理器安装里，很多情况下都不支持后期追加，因为发行版的Nginx包默认编译选项是固定的。

缺点也很明显：手动编译耗时长、需要自己处理依赖、升级时配置容易散落。而且如果系统更新了底层库，比如OpenSSL升级了，你编译出来的Nginx可能没法直接用，还得重新编译一次。所以源码安装适合"一次性配置好、长期不动"的稳定性场景，不适合频繁折腾的人。

1.2 包管理器安装：日常使用的最佳性价比

包管理器安装是主流发行版提供的方式。Debian系用apt，RedHat系用yum或dnf，一条命令把Nginx、配置文件、系统服务脚本、默认目录结构全部给你安排得明明白白。

这种方式的优势是省心。安装完成后，Nginx自动注册为系统服务，systemctl start nginx就能启动，开机自启、日志轮转、默认安全策略都帮你处理好了。后续升级也方便，直接apt upgrade或者yum update就行。

代价是可控性弱。首先，发行版仓库里的Nginx版本通常滞后，比如最新稳定版已经很新了，但apt源里可能还是半年前的版本。其次，安装路径是固定的，一般就是/etc/nginx、/usr/share/nginx、/var/log/nginx，你想换个目录装根本不行。最后，想要加第三方模块非常麻烦，要么重新编译要么找第三方仓库，很多时候还不如直接源码装一个来得干脆。

1.3 Docker容器化安装：环境隔离与交付利器

Docker方式是把Nginx跑在一个容器里，镜像从Docker Hub拉取即可，nginx官方镜像或者nginx:alpine这种轻量镜像都行。这种方式对环境的要求极低，只要机器上有Docker，就能跑起来，不受宿主机操作系统版本的影响。

Docker方式的最大优势是环境一致性和快速交付。你在一台机器上调试好的Nginx配置，直接把镜像推到仓库，另外一台机器拉下来跑，效果完全一致。加上docker-compose，可以把Nginx和上游应用服务一起编排起来，一条命令全部启动。对于做自动化运维、持续交付的团队来说，这是效率最高的方式。

但它也有坑。容器是短暂的，配置文件如果不挂载出来，容器一删就什么都没了。日志管理也比直接跑在系统里复杂，需要额外配置日志驱动或者挂载目录。还有网络层面的端口映射、容器间通信，新手很容易绕晕。

1.4 不同场景怎么选：我的推荐逻辑

我个人的选型逻辑是这样的。个人开发环境或者快速测试，直接docker跑一个nginx，用完就删，不污染系统。生产环境如果是传统架构，交付物是一台服务器，那就用官方仓库的包管理器安装，兼顾稳定性和升级便利。如果业务对Nginx有特殊要求，比如要加http_grpc_module、要做动态模块加载，或者公司有统一的二进制管理平台，那就源码编译，而且最好把编译参数固化成一键脚本，别每次手动敲。

还有一条很重要：不管你用哪种方式安装，配置管理一定要跟上。Nginx的价值不在安装本身，而在配置。很多人装完就完事，配置全靠手改，改出错来还不知道回滚，这是最危险的。

2. 源码编译安装全流程：从下载到注册成系统服务

源码编译安装是理解Nginx底层运行机制最好的方式。我强烈建议每个愿意花时间深挖的人，哪怕你平时用的是包管理器，也至少手动编译一次。编译一次，你才知道Nginx依赖什么、模块是怎么编进去的、配置和二进制文件分别放在哪里。

2.1 准备工作：先把依赖补齐

在开始之前，先确认系统基础环境。Nginx编译需要gcc、make这两个基础工具，另外几个库是可选的但强烈建议装上，否则很多功能会被编译选项自动跳过。

• gcc、make：编译工具链，没装的话后面会报"make: command not found"之类的错。
• libpcre3-dev（或pcre-devel）：Nginx的rewrite模块依赖它，做URL重写必备。
• zlib1g-dev（或zlib-devel）：gzip压缩模块依赖它，不开gzip你还能忍？
• libssl-dev（或openssl-devel）：HTTPS协议支持需要它，现在这年代不装SSL模块的Nginx基本没法用。

Debian系的安装命令：

apt update apt install -y gcc make libpcre3-dev zlib1g-dev libssl-dev

CentOS/RedHat系的命令：

yum install -y gcc make pcre-devel zlib-devel openssl-devel

这里有个细节容易踩坑：有些系统默认没装make，只有gcc，编译到一半报错找不到make。所以动手之前，先跑一下make --version确认一下，别等到报错才去装。

2.2 下载源码与configure参数详解

去Nginx官网下载稳定版源码包，稳定版的命名一般是nginx-1.2x.x.tar.gz，解压后进入目录。

wget https://nginx.org/download/nginx-1.24.0.tar.gz tar -xzf nginx-1.24.0.tar.gz cd nginx-1.24.0

接下来是重头戏：configure。这个脚本会检查系统环境并生成Makefile，你传进去的那些参数决定编译出来的Nginx长什么样。我常用的参数组合如下：

./configure \ --prefix=/usr/local/nginx \ --user=nginx \ --group=nginx \ --with-http_ssl_module \ --with-http_stub_status_module \ --with-http_gzip_static_module \ --with-pcre

逐个解释一下。--prefix指定安装根目录，这里是/usr/local/nginx，所有文件都会装到这个目录下。--user和--group指定Nginx worker进程运行时的系统用户，建议单独建一个专用于Nginx的用户，不要用root跑worker进程，权限过大容易出安全问题。--with-http_ssl_module开启HTTPS支持，--with-http_stub_status_module开启连接状态统计，访问/nginx_status能看到当前活跃连接数，排障很有用。

配置完成后运行make -j$(nproc)编译。-j参数表示并行编译，$(nproc)获取CPU核心数，能大大缩短编译时间。编译时间看机器性能，一般几分钟到十几分钟。看到make命令无报错顺利结束后，执行make install，安装完成。

2.3 注册系统服务与目录结构

源码安装默认不会注册成系统服务，也就是说你没有systemctl start nginx这个待遇。这不行，生产环境必须做成服务托管。手动写一个systemd单位文件就行。

在/etc/systemd/system/nginx.service下创建如下内容：

[Unit] Description=nginx - high performance web server After=network-online.target remote-fs.target nss-lookup.target Wants=network-online.target [Service] Type=forking PIDFile=/usr/local/nginx/logs/nginx.pid ExecStartPre=/usr/local/nginx/sbin/nginx -t -c /usr/local/nginx/conf/nginx.conf ExecStart=/usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.conf ExecReload=/usr/local/nginx/sbin/nginx -s reload ExecStop=/usr/local/nginx/sbin/nginx -s quit PrivateTmp=true [Install] WantedBy=multi-user.target

写完之后执行：

systemctl daemon-reload systemctl enable --now nginx systemctl status nginx

注意Type=forking配置是因为Nginx启动后master进程会fork出worker进程，主进程在后台运行，systemd需要靠PIDFile文件确认主进程的PID。这是源码编译安装后很容易忽略的一步，如果不写service文件，服务器重启你就得手动去启动Nginx。

源码安装的默认目录结构：主配置在/usr/local/nginx/conf/nginx.conf，二进制在/usr/local/nginx/sbin/nginx，日志在/usr/local/nginx/logs/。这个结构跟包管理器完全不同，所以配置管理不能想当然。

2.4 源码安装的核心优势与注意点

编译安装最核心的优势就是模块可定制。比如你想加入第三方模块，比如headers-more或者http_realip_module，你需要在configure里加上--add-module=/path/to/module，然后重新编译。这种操作在包管理器安装下几乎没法完成，除非你换一个预编译好的第三方仓库。

但缺点也很现实，升级维护成本高。每次Nginx出新版本，你想升级安全补丁，都得重新走一遍下载源码、配置、编译、install的流程。配置文件虽然可以保留，但二进制替换要小心。我一般这么操作：

1. 先备份旧版nginx二进制和conf目录。
2. 用同样的configure参数编译新版。
3. 用make install覆盖安装，注意--prefix要跟之前一致。
4. 测试nginx -t，然后nginx -s reload平滑切换。

这里有个经验：configure参数一定要保存成一个脚本文件，放在安装目录旁边，比如/usr/local/nginx/build_params.sh，下次升级直接复用，不用翻历史记录去想当初到底加了哪些参数。

3. 包管理器安装：五分钟上手，但细节决定成败

包管理器安装是大多数人入门Nginx的方式，但里面有几个坑，填不平后面会很难受。

3.1 Debian系（apt）：一条命令与默认配置

Debian/Ubuntu系是最常见的环境，安装三步走：

apt update apt install -y nginx systemctl enable --now nginx

安装完成后，Nginx配置文件在/etc/nginx/下，主配置文件是nginx.conf，conf.d目录放自定义配置，sites-available和sites-enabled是Debian系特有的逻辑：sites-available放站点配置，然后在sites-enabled里建一个软链接启用它，形成"可用的配置"和"已启用的配置"的区分。

这里有个默认网站的问题。apt安装完会自动启用一个默认站点，监听80端口，返回一个"Welcome to nginx"页面。很多新手直接把自己的配置文件丢进conf.d，结果跟默认站点冲突，端口都占着，一脸懵。我建议先禁用默认站点：

rm -f /etc/nginx/sites-enabled/default

然后把自定义配置丢进/etc/nginx/conf.d/下，文件名以.conf结尾，主配置里会自动include。

3.2 RedHat系（yum/dnf）：仓库选择是分水岭

CentOS系默认仓库里没有Nginx，所以安装前需要先装EPEL仓库：

yum install -y epel-release yum install -y nginx systemctl enable --now nginx

但请注意：EPEL仓库里的Nginx版本通常比官方慢不少。想要最新稳定版，推荐直接添加nginx官方仓库。官方仓库提供了一系列针对不同系统版本的源，例如对于RHEL/CentOS系，你可以创建一个/etc/yum.repos.d/nginx.repo文件：

[nginx-stable] name=nginx stable repo baseurl=http://nginx.org/packages/centos/$releasever/$basearch/ gpgcheck=1 enabled=1 gpgkey=https://nginx.org/keys/nginx_signing.key module_hotfixes=true

配置好后执行yum install -y nginx，装出来的就是官方最新稳定版。注意baseurl里的$releasever和$basearch是yum自动替换的系统版本号与架构，不用手动改。

3.3 官方仓库与系统仓库的取舍

这两者的选择本质上是"稳定保守"与"功能更新"的取舍。

系统仓库的优点是跟系统契合度高，安全补丁由发行版维护团队负责，跟系统其他组件一起统一升级，不容易出兼容性问题。缺点是版本比较旧，有些特性没有，比如新版本对HTTP/3的支持，老版本就没法用。

官方仓库（nginx.org）的优点是版本新，官方维护，能第一时间用上最新特性，而且官方仓库里的Nginx编译参数很全，常用模块都被编进去了。缺点是它跟系统仓库是两套独立的升级通道，时间长了系统里可能出现两套Nginx相关的包，管理时要自己注意别混了。

我的建议：优先用官方仓库。Nginx是一个迭代比较快的软件，版本新旧直接影响安全性和性能。用系统仓库往往一两年都停留在特别老的版本上，等出事了才后悔没更新。

3.4 包管理安装的隐藏坑点

第一，版本锁定。有些团队为了统一环境，会对Nginx包做版本锁定，比如在/etc/apt/apt.conf.d/里设置Pin-Priority或者用yum versionlock插件。这个没问题，但要记住下次升级的时候先解除锁定，否则每次都报"held by another process"，很烦人。

第二，配置文件权限。包管理器安装的配置文件默认属主是root，而Nginx worker进程运行在nginx用户下。如果某些缓存目录、日志目录权限设置不对，会出现"Permission denied"的报错。检查一下/var/log/nginx、/var/cache/nginx这些目录的属主和读写权限。

第三，卸载不彻底。apt remove nginx并不会删除配置文件，如果你想彻底清空重新来，需要apt purge nginx，否则你会发现卸载后再安装，老配置还在，跟你印象里的"全新安装"完全不一样。

4. Docker容器化安装：跑起来容易，跑得优雅需要章法

Docker方式现在越来越流行，特别是Kubernetes普及之后，Nginx大多以Ingress或者网关容器的身份存在。单机环境下用Docker跑Nginx也很常见，但很多人只学会了一个docker run nginx就把容器跑起来了，后面排查问题的时候头大如斗。

4.1 基础命令：先跑起来再说

最常见的命令是：

docker run -d --name nginx-demo -p 80:80 nginx:alpine

这条命令做了几件事：从Docker Hub拉取nginx:alpine镜像，后台运行一个叫nginx-demo的容器，把容器内80端口映射到宿主机80端口。

为什么用nginx:alpine而不是nginx？alpine版镜像体积要小很多，基础镜像是Alpine Linux，自带包管理器apk，整个镜像只有几十MB，而标准版要一两百MB。对于Nginx这种轻量服务来说，追求的是启动速度和资源占用，alpine版是上策。

跑起来后，访问http://localhost就能看到nginx欢迎页。但是这只是第一步，容器的价值在于把配置和数据持久化出来，否则容器一删，配置全没。

4.2 配置文件挂载与日志管理

正确做法是把宿主机的配置文件目录挂载进容器。先用-v参数：

docker run -d --name nginx-demo \ -p 80:80 \ -v /data/nginx/conf.d:/etc/nginx/conf.d \ -v /data/nginx/html:/usr/share/nginx/html \ -v /data/nginx/logs:/var/log/nginx \ nginx:alpine

这样宿主机/data/nginx/conf.d下面放你的站点配置，/data/nginx/html放网站静态文件，/data/nginx/logs让日志写出来方便查看。

这里有一个关键点要提醒：修改配置后别直接重启容器，用reload。很多人改完配置就docker restart nginx，其实Nginx支持平滑重载，多数情况下不应该中断服务。

docker exec nginx-demo nginx -s reload

这条命令会在容器内执行nginx -s reload，实现配置重新加载而不中断连接。前提是你挂载的配置目录是同一个，且容器内Nginx主进程还活着。

另外，日志挂载目录的权限要留意。容器内Nginx的worker进程运行在nginx用户下，如果你的宿主机目录权限是root独占，容器写入日志会报权限错误。解决办法是宿主机目录设成chown -R 101:101 /data/nginx/logs，因为nginx:alpine镜像里nginx用户的UID和GID都是101（不同镜像版本可能有差异，先docker exec nginx-demo id nginx确认一下）。

4.3 用docker-compose编排：从单容器到多服务

单容器用docker run没问题，但涉及两个以上容器的协同，就该用docker-compose了。

举个例子：前端用Nginx做静态托管和反向代理，后端是一个API服务。在docker-compose.yml里这么写：

version: '3.8' services: nginx: image: nginx:alpine container_name: front-gateway ports: - "80:80" - "443:443" volumes: - ./conf.d:/etc/nginx/conf.d:ro - ./html:/usr/share/nginx/html:ro - ./logs:/var/log/nginx networks: - front-net depends_on: - api api: image: your-api-image:latest container_name: backend-api expose: - "8080" networks: - front-net networks: front-net: driver: bridge

这样编排的好处是：Nginx和API服务在同一个front-net网络里，Nginx配置里可以直接用服务名api作为上游地址，比如proxy_pass http://api:8080;。Docker网络内置DNS会帮你把服务名解析成容器IP，不用手动维护IP地址清单。depends_on确保API服务先启动，Nginx容器再启动，减少了启动竞态问题。

需要说明的是，这样的depends_on只是启动顺序上的控制，并不表示API已经就绪。如果要真正等到API健康再启动Nginx，还需要在compose文件里加healthcheck配置，实战场景中这个细节经常被忽略。

4.4 容器化部署的边界与注意事项

容器化最大的边界在于：官方镜像的默认配置文件和编译选项是固定的，如果你需要加一个官方镜像里没有的模块，比如http_geoip_module，那要么换镜像，要么自己写Dockerfile在官方镜像基础上重新编译。所以我的建议是：容器化适合"标准功能"场景，特殊模块需求尽量用源码方式去搞，别硬塞进容器。

另一个注意点是容器内时区。官方镜像默认是UTC时区，你的日志时间戳会比北京时间晚8小时。可以在Dockerfile里加一行：

RUN ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime

或者运行时挂载-v /etc/localtime:/etc/localtime:ro（这个做法在部分宿主机会因只读或动态库问题失效，更稳妥的是直接修改镜像内的时区配置，或用TZ环境变量，按你的镜像基础来定）。

5. 三种方式的对比迁移与我的踩坑记录

三种方式不仅安装时思路不同，后续的升级、回滚、迁移操作也有很大差异。

5.1 升级与回滚策略

包管理器升级最方便。Debian系apt upgrade nginx，RedHat系yum update nginx。升级前先用nginx -t测试当前配置语法，没问题再执行升级。升级后别忘了systemctl restart nginx（或者reload，取决于版本差异大小）。

源码编译升级最繁琐。我刚才说了，保存configure参数脚本，新版本下载编译，老版本二进制做好备份。回滚的做法是把备份的二进制重新覆盖回来。

Docker升级是最干净的。新版镜像拉下来，先起一个新容器，确认没问题后把旧容器停掉，并且建议把旧容器改名而不直接删除，留一个快速回滚的后路，比如：

docker tag nginx:alpine nginx:alpine-bak docker pull nginx:alpine docker stop nginx-demo docker rm nginx-demo docker run ...

这样如果新版有问题，立刻把镜像tag回nginx:alpine-bak重新启动，基本秒级回滚。

5.2 配置迁移时的三个陷阱

迁移Nginx配置，最容易踩三个坑。第一个是路径差异。源码安装的配置在/usr/local/nginx/conf/，包管理器在/etc/nginx/，Docker在容器内/etc/nginx/。配置文件里如果写了绝对路径，比如access_log /var/log/nginx/access.log;，换到源码安装环境就报错，因为源码安装默认日志目录是/usr/local/nginx/logs/。迁移前务必全局检查一下路径。

第二个是编译模块差异。你在包管理器环境用的指令，比如gunzip on;，如果新环境的Nginx编译时没加--with-http_gunzip_module，启动会直接报"unknown directive"。解决方法是迁移前对照配置文件和编译参数，逐项确认。

第三个是用户权限差异。比如user nginx;这条指令，源码安装默认可能是注释的（默认以nobody运行），如果你在配置里显式指定了user nginx;，而系统里没有nginx用户，Nginx启动会报错。迁移前先确认系统用户存在，或者用useradd -r nginx创建系统用户。

5.3 一个典型的生产环境切换案例

我之前在某个项目里，从包管理方式切换到了Docker方式，简要记录一下操作步骤，供参考。

原环境是CentOS系统，Nginx由yum安装，跑着几个站点的反代和静态托管。当时因为机房里还有另外几套部署Docker的应用，统一管理工具链的需求越来越明显，决定把Nginx迁到容器里。

第一步，把原来/etc/nginx/conf.d/下面的所有*.conf文件整理出来，连同mime.types、nginx.conf一起放到宿主机/data/nginx/conf/目录。

第二步，启动容器，先不映射端口，只把配置挂载进去：

docker run -d --name nginx-test \ -v /data/nginx/conf:/etc/nginx/conf.d \ nginx:alpine

第三步，docker exec nginx-test nginx -t检查语法，确认无报错后，把80、443端口映射加上，重建正式容器。

第四步，切换流量。因为原Nginx还在监听80端口，所以先停掉原来的Nginx服务，再启动新容器。停旧启新的间隙会有几秒的请求中断，我选择在流量低谷时操作。

整个切换过程不超过十分钟，配置文件没有改一行，因为Docker镜像里Nginx编译选项跟官方仓库很接近，指令都能兼容。但如果你遇到的不兼容情况，基本都会在上面说的模块差异里面找到答案。

6. 常见问题与排查技巧速查

这部分是我平时帮别人排障时最常用到的，整理成速查卡，按症状定位原因给解法。

6.1 编译安装时的两个高频报错

报错一：./configure: error: the HTTP rewrite module requires the PCRE library。这个就是忘了装libpcre3-dev/pcre-devel。解决：先装依赖，再重新跑configure，缓存在当前目录里，不需要重新解压源码。

报错二：make: *** 没有规则可以创建目标... 需要的目标... 停止。大概率是你解压的源码目录不完整，比如压缩包没解压完全，或者编译过程中磁盘满了。先df -h看磁盘，再重新解压一次源码包。

还有一个建议：编译时不要用root直接跑make install，除非你确实需要装到root才允许写的路径。建议规划好prefix目录，并把安装目录属主设置成管理用户，避免污染系统根目录结构，也方便后续权限管理。

6.2 启动失败与语法检查

任何时候修改了配置文件，先跑：

nginx -t

这条命令会检查配置文件语法，并显示配置文件路径。如果报了emerg级别的错误，比如“[emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)”，那就是端口被占了。用ss -lntp | grep :80找出占用进程，常见的是系统自带的Apache或者另一个Nginx实例。解决方法是停掉冲突服务，或者改Nginx监听端口。

如果nginx -t通过但进程起不来，多半是权限问题，比如nginx.pid文件目录不可写，或者logs目录没有写权限。看一下error.log里的报错，通常第一行就会给出真正的原因。

6.3 Docker方式常见排查实录

容器跑起来但访问不到页面的情况最多。第一步先确认映射端口：

docker port nginx-demo

确认80端口确实映射到宿主机了。第二步看容器状态：

docker logs nginx-demo

如果看到bind() to 0.0.0.0:80 failed，说明宿主机80端口被占。第三步检查防火墙，尤其是云主机或安全组策略，很多教程没说这一点——容器端口映射正常，但云厂商安全组把80封了。

如果页面返回502 Bad Gateway，说明Nginx起来了但连不上上游服务。在容器里测试上游连通性：

docker exec -it nginx-demo curl http://api:8080/health

如果curl报Could not resolve host，说明容器和上游服务不在同一个网络里，检查compose里网络配置。

6.4 关于性能与安全的最后叮嘱

不管哪种方式安装的Nginx，有两点不能妥协。第一，worker进程数设置为auto，让它按CPU核心数自动分配，或者手动指定为核数，不要盲目调大，worker数超过CPU核心数的两倍性能反而会下降。第二，务必配置user指令不要用root跑worker，编译安装和包管理器安装默认会处理，但用Docker时有些自定义镜像可能会不小心把worker跑成root，等于把一个高权限进程暴露在公网上，风险很大。检查方法很简单：ps aux | grep nginx看work进程的属主。

另外顺便提一句，Nginx编译安装的二进制是静态链接还是动态依赖，也会影响迁移。源码编译默认动态依赖系统库，你把编译好的二进制拷到另一台机器上，如果那台机器缺库就起不来。生产环境如果要做二进制分发，建议在编译时加上-static相关参数，或者干脆用Docker方式，把运行时依赖全部封进镜像里，这才是更彻底的交付方式。

我自己用Nginx这么多年，三种方式轮着用过，最终的体会是：没有绝对的好坏，只有适不适合当前阶段。刚入门想快速看到效果，用包管理器或Docker；想深挖性能和模块，花一个下午手动编译一次；在生产环境中维护一堆机器，把配置文件纳入版本管理比纠结安装方式重要得多。配置管理到位了，装在哪里、怎么装的，都是小问题。