nginx以事件驱动、异步非阻塞架构实现高并发低延迟，优势在于单线程万级连接、资源占用低、热重载稳定、模块化清晰、反向代理健壮；缺点是无原生动态处理、配置容错差、静态逻辑难扩展、日志调试弱、多进程共享受限。
Nginx 的架构设计以事件驱动、异步非阻塞为核心，不是靠堆线程或进程来应对并发，而是用少量工作进程（worker process）高效调度成千上万连接。这种底层逻辑决定了它在高并发、低延迟、资源敏感场景中表现突出，但也带来一些天然约束。
优势：轻量、高效、稳定、可扩展
● 单线程高并发能力极强：基于 epoll（Linux）、kqueue（BSD）等系统级事件机制，一个 worker 进程可同时管理数万 TCP 连接，上下文切换开销极小，实测轻松支撑 2~5 万并发，内存占用常低于 10MB。
● 资源占用率低：不依赖每个请求启动新进程或线程，CPU 和内存使用平滑稳定；在 VPS 或容器环境中部署成本明显低于 Apache 等多进程模型服务。
● 热重载与优雅重启支持成熟：修改配置后执行 nginx -s reload，新 worker 启动、旧 worker 逐步退出，整个过程零请求丢失，适合 7×24 小时运行的关键业务。
● 模块化设计清晰可控：核心只保留网络 I/O 和进程管理，HTTP、Mail、Stream 等功能按需加载；第三方模块（如 Lua 模块）也可安全集成，不污染主干逻辑。
● 反向代理与负载均衡原生健壮：支持加权轮询、IP hash、least_conn 等多种策略，内置健康检查、自动摘除故障节点、fail_timeout 回退机制，无需额外组件即可构建生产级网关层。
缺点：动态处理弱、配置有门槛、扩展有边界
● 无原生动态语言执行能力：Nginx 不解析 PHP、Python 或 Java 字节码；处理动态内容必须通过 FastCGI、uWSGI、proxy_pass 转发给后端应用服务器，链路变长、调试路径复杂。
● 配置语法简洁但容错性低：缺少运行时校验，括号不匹配、分号遗漏、指令位置错误等都会导致 nginx -t 失败甚至服务无法启动；高级功能（如嵌套 if + rewrite + map 组合）易引发意料外行为。
● 静态配置难以应对实时业务逻辑：标准 Nginx 无法在请求处理中调用数据库、执行风控规则或生成动态响应头；需要 OpenResty 或外部服务协同，否则就得写 C 模块——开发周期长、维护成本高。
● 日志与调试能力偏基础：access_log 和 error_log 格式固定，缺乏 Apache 那类灵活的 CustomLog + LogFormat 组合；调试复杂请求流需依赖 ngx_http_rewrite_module 的 log_not_found 或第三方 trace 工具。
● 多进程模型带来 IPC 局限：worker 之间默认不共享内存，计数器、限流状态、会话缓存等需借助 Redis、共享内存 zone（如 limit_req_zone）或外部存储，否则容易出现数据不一致。
适用与不适用的典型场景
● 非常适合：静态资源托管（CDN 边缘节点）、API 网关（统一鉴权/限流/转发）、动静分离架构中的静态层、HTTPS 终止点、微服务前端负载均衡器、邮件代理（SMTP/POP3）。
● 不太适合：纯动态站点（如传统 PHP 博客全站由 Nginx 直接驱动）、需高频读写共享状态的实时网关（如每请求查本地内存黑名单）、依赖 .htaccess 灵活覆盖规则的小型共享主机环境。
● 可搭配增强：引入 OpenResty 后，可用 Lua 在 Nginx 内直接编写业务逻辑，弥补动态能力短板；配合 Prometheus + nginx-module-vts 可补足可观测性缺口。
