kong适合lua生态团队，插件需显式声明并重启加载；tyk权限模型清晰但启动复杂；krakend性能高但无运行时插件；python应直连网关，避免重复实现治理逻辑。
Kong 适合已有 Lua 生态或需要深度插件定制的团队
Kong 的核心是 OpenResty，所有插件逻辑跑在 nginx 进程内，用 lua 编写。如果你团队熟悉 lua-resty-http、有现成的 lua 鉴权/限流模块，或者需要在请求头解析前就做协议转换（比如把 GraphQL 请求转成 REST），Kong 是最直接的选择。
但要注意：kong.conf 里 plugins 列表必须显式声明启用哪些插件，漏写会导致 404 或插件完全不生效；自定义插件放在 /usr/local/share/lua/5.1/kong/plugins/ 下后，必须重启 kong 进程（不是 reload），否则新插件不会加载。
常见踩坑点：
-
kong migrations up执行失败时，别直接删数据库重来——先检查postgres用户是否有CREATE EXTENSION权限 - 用
kong docker启动时，默认不暴露8001管理端口，docker run必须加-p 8001:8001 -
jwt插件默认只校验Authorization: Bearer xxx，不支持Cookie或query参数传 token，得自己改插件或加request-transformer
Tyk 不适合小团队快速验证，但企业级权限模型更清晰
Tyk 的强项是细粒度 API 级别策略：能按 org_id + api_id + key_id 三级控制配额、访问范围、甚至字段级响应过滤。如果你的客户要各自管理子账号、不同部门调用不同后端、且审计日志必须带完整上下文，Tyk 的 Policy 和 Session Object 比 Kong 的 Consumer + Plugin Config 更易对齐业务语义。
立即学习“Python免费学习笔记（深入）”；
代价是启动成本高：社区版不支持集群模式，tyk-gateway 单节点扛不住高并发；企业版需单独部署 tyk-pump 收集日志到 Elasticsearch，配置项分散在 tyk.conf、app.conf、middleware 目录下，改一个限流阈值可能要动三处。
典型问题：
-
tyk start报错Failed to load middleware，大概率是middleware_dir路径没写绝对路径，或.so文件架构不匹配（ARM 机器上用了 x86 编译的插件） - 启用
GraphQL支持需在tyk.conf开enable_graphql，但社区版只支持proxy模式，不支持execute模式（即不能合并多个后端请求） - Web UI 中创建的 API 定义，实际生效依赖
tyk-dashboard向tyk-gateway的API Reload请求，网络不通就会“界面上配了，但网关不认”
KrakenD 性能最高，但所有逻辑必须前置到配置里
KrakenD 是纯 Go 写的，无状态、零中间件、全靠 krakend.json 配置驱动。如果你的场景是聚合多个后端（比如把 /user + /orders 合并成一个响应）、且后端协议全是 HTTP/JSON，KrakenD 的吞吐量和延迟明显优于 Kong/Tyk。官方压测数据在同等硬件下，KrakenD QPS 比 Kong 高 2–3 倍。
但它没有运行时插件机制：想加 JWT 校验？得在配置里写 jwt_signing_method 和 jwt_jwk_url；想动态改路由？只能改配置 + kill -HUP 重载；想做请求体修改？只能靠 extra_config 里的 proxy 字段写 modify 规则，不支持任意代码逻辑。
容易忽略的限制：
-
backend数组里每个url_pattern必须唯一，重复会静默忽略后一个 -
concurrent并发数设太高（比如 >50），遇到后端超时会把连接池打爆，错误日志只显示context deadline exceeded，看不出是 KrakenD 自身配置问题还是后端慢 - 使用
redis做缓存时，cache_ttl单位是秒，但rediskey 过期时间实际是毫秒级精度，短 TTL（如1s）可能导致缓存命中率骤降
Python 项目直连网关？别绕过它写 SDK
很多 Python 团队想用 requests 封装一层网关调用逻辑，比如自动加 X-Api-Key、重试、熔断。这看似省事，实则把网关该干的事搬回业务代码里：鉴权规则散落在各服务、限流策略无法统一、故障定位要跨两层日志。正确的做法是让 Python 服务当“裸客户端”，所有治理能力交给网关。
真正该在 Python 侧做的只有两件事：一是用 httpx.AsyncClient 复用连接池（避免每次新建 TCP），二是对网关返回的 429 / 503 做简单退避重试（别重试 401 或 404）。其余一律透传。
特别注意：
- 不要在 Python 里解析
X-RateLimit-Limit头做本地限流——网关集群下这个头只反映单节点配额，全局不一致 - 如果网关启用了
gzip压缩，Python 用requests时得显式设headers={'Accept-Encoding': 'gzip'}，否则网关可能跳过压缩 - KrakenD 默认不透传
Set-Cookie，要在extra_config里开proxy的allow_set_cookies，否则 Python 服务拿不到下游写的 cookie
