Kong推荐：新手该选哪种入门方案
搜 Kong推荐的人，通常不是想看一串功能名，而是在纠结：用 Docker 还是 Kubernetes，选声明式配置还是数据库，先装哪些插件。下面按新手最常遇到的四组选择逐项对比，帮你配出一套不臃肿、后续又能扩展的 Kong 入门方案。
运行环境对比：Docker更适合第一周，Kubernetes留给已有集群的人
给纯新手的 Kong推荐很明确：先用 Docker Compose。一个网关容器、一个模拟上游、一个配置文件，半天能把代理、认证和限流全摸到。它的问题也明显：多副本、服务发现、证书自动化都要自己补，别把本地 Compose 当生产架构。
Kubernetes 适合已经有成熟集群、Ingress 规范和监控体系的团队。它能让 Kong 跟着服务编排、扩缩容和发布流程走，但学习成本不只在 Kong 本身，还包括 CRD、Service、Ingress/Gateway 资源和网络策略。没有 K8s 基础时硬上，排错会很痛苦。
配置方式对比：DB-less清爽，数据库模式更偏动态治理
DB-less 的优点是可复现。路由、服务、插件写进 YAML，提交 Git，代码评审能看出谁改了哪个接口策略。对于接口数量不多、发布节奏可控的项目，这是我最推荐的起步方式。缺点是每次变更需要按发布流程加载配置，不适合随手在线改。
数据库模式适合需要频繁创建 Consumer、动态调整路由或由平台统一操作的场景。代价是要维护数据库、迁移和备份，还要防止“控制台改过、仓库没同步”的漂移。新手如果连配置版本管理都没建立，先别急着把复杂度拉满。
入口策略对比：Path适合内部服务，Host适合域名清晰的产品
Path 路由像 /api/user、/api/order，开发调试直观，内部平台很常用。要留意前缀处理：Kong 转给上游时是否去掉 /api，需要在测试用例里写死预期，否则迁移时很容易多一层或少一层路径。
Host 路由像 user.example.com、open.example.com，适合边界清楚的业务域名，也方便做证书和独立治理。它的前提是 DNS、负载均衡和 TLS 配置跟得上。一个项目早期只有少量接口，没必要为了“看起来专业”拆出一堆子域名。
插件对比：第一批只推荐认证、限流、CORS和日志
新手别见插件就开。第一批建议选 key-auth 或与现有身份系统适配的认证方式、rate-limiting、CORS、file-log 或 HTTP 日志输出。它们能覆盖最常见的入口控制和排错需求，而且容易验证：有无凭据、是否 429、浏览器跨域是否通过、日志有没有记录。
缓存、请求转换、复杂流量切分、深度自定义插件，都应该等基础链路稳定后再上。插件越多，请求链路越难解释。我的经验是每新增一个插件，就补两条测试：正常请求应如何变化，异常请求应返回什么。这样以后定位问题不靠猜。
一套够用的起步组合：小而稳，比大而全值钱
如果你只是给 3 到 10 个内部 API 加统一入口：Docker Compose + DB-less + Path 路由 + 一种认证插件 + 限流 + 日志，已经够用。配置放仓库，密钥走环境变量或专用密钥系统，管理接口只留内网。
如果团队已有 Kubernetes 和统一身份平台：优先沿用现有发布、证书、日志、监控方案，再把 Kong 接进去。Kong推荐不是推荐某个“万能模板”，而是推荐少引入一层未知系统。网关应该让服务更简单，不该成为全团队最难维护的组件。
推荐阅读
常见问题
Kong新手推荐用免费版还是企业版？
先从满足当前需求的版本和功能集开始。代理、路由及常用治理能力已经能支持学习和许多基础场景；是否需要企业功能，应根据身份集成、治理流程、支持服务和团队规模评估。
Kong推荐先学哪些概念？
按 Service、Route、Consumer、Plugin 的顺序学。先让请求转发成功，再加调用方身份，最后叠加限流、日志等策略，理解会更牢。
小项目有必要上Kong吗？
只有一个后端、没有统一认证或流量治理需求时未必有必要。出现多个服务、多个客户端、重复鉴权逻辑或需要统一审计时，Kong的价值会更明显。