网关能挡住一部分异常请求，却无法替应用判断每个用户是否有权执行某项业务操作。落实“API网关与应用层防护策略如何分工”，关键是让网关管入口、流量和通用协议规则，让应用管身份背后的权限、数据和业务状态。以下六步可用于设计或检查一套分层方案。
第一步：先列清接口和风险边界
按路由、HTTP 方法和调用方整理接口清单，例如查询、创建、更新、删除分别记录。标出公开接口、内部接口以及涉及敏感数据或重要操作的接口。不要只按服务名称划分：同一服务的只读查询与删除操作，风险通常不同。
同时确定哪些检查可以统一执行，哪些必须读取应用数据后才能判断。这个边界是回答“API网关与应用层防护策略如何分工”的起点，也能避免同一规则在多处配置却彼此不一致。
第二步：在网关实施通用入口控制
网关适合执行与具体业务对象无关的规则，包括路由与允许的方法、请求体大小上限、内容类型约束、基础身份认证、来源限制和速率限制。可按路由设置不同阈值：公开查询接口与管理操作接口不必采用相同的限流策略。阈值应依据正常流量基线、突发模式和后端承载能力调整；超限时可返回 HTTP 429，并记录触发的路由和时间。
若所用网关支持请求格式校验，也可以先拒绝明显不符合约定的结构；但这不代表应用可以省略输入校验。网关主要减少不合规流量进入后端。
第三步：区分身份认证与授权控制
网关可验证令牌的签名、有效期及预期受众等通用属性，拦截缺少凭证或凭证无效的请求。具体实现取决于身份体系和网关能力，不能把“通过认证”理解为“允许操作”。
授权控制通常应在应用完成，因为应用更清楚资源归属、用户角色和操作条件。例如，日程服务收到取消某个会议的请求后，仍需核对调用者是否为组织者或具备相应管理权限。不要仅凭客户端提交的用户编号或角色字段作决定。
第四步：在应用中校验数据与业务状态
应用要对收到的字段进行输入校验：检查类型、必填项、长度、枚举值及字段之间的关系；需要时使用参数化查询，避免把用户输入拼成数据库命令。随后执行业务规则，例如会议已开始后是否仍允许取消、参与人数是否超过设定容量。这些规则依赖当前数据和业务状态，网关通常无法可靠判断。
错误响应也应有边界：向调用者返回必要的原因和状态码，内部日志保留排查所需上下文，但避免把密钥、完整令牌或不必要的敏感数据写入日志。
第五步：把防护规则映射到执行位置
落实“API网关与应用层防护策略如何分工”时，可用一张责任表减少遗漏：
| 控制事项 | 优先位置 | 原因 |
|---|---|---|
| 路由、方法、通用限流 | 网关 | 统一执行，尽早拦截 |
| 身份凭证基础验证 | 网关与应用协作 | 网关过滤无效凭证，应用按自身信任边界复核必要信息 |
| 资源权限、业务状态 | 应用 | 需要访问业务数据和规则 |
| 字段及业务输入校验 | 应用 | 关系校验依赖接口语义 |
网关可作为第一道检查，但应用应具备独立保护能力，尤其是在内部调用可能绕过公共入口时。避免只在网关实施授权，或只依赖应用承担所有流量过滤。
第六步：用测试和日志验证分层效果
- 逐条写用例：覆盖无凭证、格式错误、超过限流阈值、无权访问资源和业务状态不允许等情况。
- 确认拦截位置：检查通用入口问题是否在网关被拒绝，权限和业务规则问题是否由应用拒绝。
- 检查可观测性：关联网关请求标识与应用日志，记录路由、响应状态和耗时，避免记录敏感凭证。
- 分阶段发布：先在测试环境验证规则，再观察生产环境中的误拦截和后端错误，按实际流量调整限制。
常见问题
网关能否承担全部安全校验？
不能。它适合执行通用入口规则，无法替代应用对资源权限和业务状态的判断。
同一项身份认证要做两遍吗？
不一定。网关可做统一的基础验证；应用应依据调用链和信任边界，决定是否复核身份信息，不能盲目信任可被伪造的请求头。
限流阈值应该设多少？
没有适用于所有接口的固定值。应结合历史流量、突发需求和后端容量测试，并分别评估不同路由。
如何快速判断规则放错了层？
若规则需要查询资源归属或业务状态，应优先放在应用；若规则对所有请求都通用且与业务数据无关，通常更适合放在网关。守住这条边界，才能让“API网关与应用层防护策略如何分工”落到可维护的实现上。
