网关这东西，最容易被两种极端忽悠：一种觉得「Nginx 就够了，网关都是折腾」；另一种觉得「没有网关就落后了，先上一个再说」。两次真实经历，正好各踩一头。
第一次：用 Nginx 硬扛「网关」的活，扛得很痛
第一次是把 Nginx 当网关用：路由、限流、灰度、鉴权全在 Nginx 配置里堆。一开始很顺，半年后开始痛：
- 配置漂移：路由规则散在十几台机器的 conf 里，改一次灰度要记着每台都同步，漏一台就是线上事故。
- 限流规则难灰度：Nginx 的限流改完要 reload，想「先放 1% 流量验证」基本靠手写脚本。
- 动态路由做不了：服务注册表一变，Nginx 侧就要跟着改配置——服务化的动态性和静态配置天然打架。
复盘时我才想明白：这不是 Nginx 的错，是我用错了层。Nginx 是优秀的反向代理，但我要的「动态路由 + 规则可灰度 + 集中管控」是网关的能力。工具本身没错，错在把工具用到它不擅长的层。
第二次：直接上 APISIX，又踩了另一头的坑
第二次学乖了，直接引入 APISIX：动态路由、Admin API、插件热更新，确实把第一次的痛点全解决了。但新坑也随之而来：
- 故障面变大：网关层从「Nginx + 配置」变成「一个带数据库的集群」（etcd），它挂了全站入口就没了。第一次没想过网关要高可用设计。
- 插件质量参差：开源插件的成熟度差别很大，个别插件在流量大时有性能问题，不是官方文档里写了就敢直接上——每个插件都要压测。
- 学习与维护成本：团队从「会 Nginx」变成「要会 APISIX + etcd + 插件体系」，值班同学半夜遇到网关问题，压力比 Nginx 时代大得多。
复盘出来的判断框架（现在我用它决策）
先回答三个问题，再谈选型：
- 你的流量需要「动态变更」吗？ 路由/限流/灰度的变更频率——一年改不了几次的静态场景，Nginx 足够，别引入集群复杂度。
- 网关会成为故障单点吗？ 如果所有流量都过网关，就要把网关当「核心系统」设计：高可用、降级、容灾预案一样不能少。
- 团队养得起吗？ 引入一个带 etcd 的网关，意味着值班同学多一套要懂的系统。养不起的复杂度，就是未来的事故。
| 场景 | 我的选择 | 理由 |
|---|---|---|
| 单入口、规则很少变 | Nginx / OpenResty | 简单即稳定，配置就是代码 |
| 服务多了、路由要动态 | APISIX / Envoy 系 | 动态能力值得引入，但要配高可用 |
| 团队很小、没专职运维 | 云厂商托管网关 | 把高可用外包，别自建 etcd 集群 |
落地清单
- 先回答「变更频率」：动态需求真实存在吗
- 网关按核心系统设计（高可用/降级/预案）
- 每个插件压测后再上，不信文档
- 值班与运维成本算进选型账（方法论见技术选型）