外部程序高频调用网站接口时，哪几类端点最该先做限流和凭证管理

内容管理系统的公开接口被高频调用时，应该优先给哪些端点做限流，凭证怎么管理？原则是一句话：按「被调用的频次 × 单次调用的代价」排序。读多写少的高频端点先用限流挡住滥用，写入与全站级端点用凭证与权限收敛调用方，两类动作的先后不能颠倒。

被高频调用的通常是哪几类端点

AnQiCMS 接口调用的高频能力面很清晰：文档列表/详情、分类与标签、上传图片、留言与评论、友情链接、系统设置与联系方式。对外挂件、小程序、聚合页通常都在反复打前几类。风险分层也不一样：列表与详情是典型的读放大入口，被轮询时最先耗尽服务器资源；上传图片与留言评论是写入端点，除了频控还要校验来源，否则就是垃圾内容通道；系统设置类接口即便只是读取，也不应暴露给不受信调用方。

公开 API 文档先回答的三个问题

给外部开发者看的接口文档，要能直接回答三件事：每个端点的身份要求（公开读取，还是必须持 JWT 凭证）；预期的调用节奏（超过什么频率会被拒绝或排队）；错误的语义（限流、鉴权失败、参数错误分别返回什么）。写不清这三条，集成方只能靠试探，试探本身就是无效流量。

批量导入走 import/archive 接口的节奏

内容搬家与批量灌入建议走文档内容导入接口 /api/import/archive：支持按标题查询是否已存在，再决定是否提交，天然具备幂等性。实操节奏：先按标题批量查重，跳过已存在条目；分批提交并保留批次号，失败只重试该批；导入窗口内避开业务高峰。标题查重这一步不能省——重复提交是接口被限流后最难排查的一类原因。

限流与凭证的先后顺序

顺序建议这样安排：第一步用 JWT 认证把调用方分成匿名、受信合作、管理三类，匿名只留只读公开端点；第二步按类别设限流档位，高频读端点从宽、写入端点从严、系统级端点默认关闭；第三步给每个凭证绑定用途与到期时间，密钥轮换后旧凭证即时失效；第四步留存调用日志，按端点看峰值与拒绝率，档位随真实流量校准。接口防御本身也依赖底层安全：内置的 JWT 认证与内容过滤是防 SQL 注入和 XSS 攻击的第一道收敛点，限流建立在这套身份体系之上才有意义。

常见问题

问：先限流还是先鉴权？ 答：鉴权先行——不区分调用方的统一限流会误伤正常集成，也会让恶意流量躲在共享额度里。

问：导入接口要限到什么程度？ 答：按批量任务的实际吞吐设档：正常导入是脉冲式的高频提交，档位应容纳一个批次而拒绝持续轰炸，配合按标题查重可以安全重放。

问：留言评论类端点除了限流还做什么？ 答：它们是公开写入面，频控之外必须叠加验证码与内容审核，把机器灌水与不良内容一起挡在存储之前。