一套API上线前，产品文档里通常写满功能点，却没人提"每秒最多调几次"。等流量 spike（激增）把服务打崩，团队才想起来：那些横跨所有接口的隐形规则，才是真正的生死线。
ByteByteGo 最近梳理了这类问题的清单。它们有个共同特征——不属于任何一个具体功能，却必须无处不在。行话叫"横切关注点"（cross-cutting concerns），产品经理的噩梦，工程师的加班之源。
身份验证：第一道门的悖论
没它不行，有它烦人。OAuth 2.0、JWT、API Key 选哪个？选错了后期迁移成本极高。更麻烦的是，它得覆盖 100% 的端点，但每个端点的权限粒度又千差万别。
ByteByteGo 的观察很直白：用户感知不到登录系统的存在，直到某天突然登不进去。那时他们会默认是你的问题，而非自己忘了续期 token（令牌）。
限流：产品经理最不愿写的需求
"限制用户行为"这种功能，没有任何业务方主动提。但 2024 年某头部云厂商的教训还在：一个未设限的导出接口被爬虫狂扫，账单飙到七位数。
限流的难点不在技术，在决策。阈值定太高等于没设，定太低误杀正常用户。而且必须全局一致——某个端点漏了，攻击者会精准找到它。
日志与输入验证：沉默的守夜人
日志是事后追责的唯一证据，但存储成本让团队不断压缩保留周期。输入验证更憋屈：写多了代码臃肿，写少了被 SQL 注入教做人。
ByteByteGo 把这两类问题归为一档：工作时完全隐形，出问题时没有替代品。就像飞机的黑匣子，没人希望用到，但不能没有。
统一治理：最难的部分
单个 concern（关注点）不难做，难的是"横切"——让每个端点都执行同一套规则，且不重复造轮子。网关层、中间件、注解驱动，各有利弊。
ByteByteGo 的建议是：早期就选定策略，比后期修补便宜一个数量级。API 数量从 10 个涨到 100 个时，再谈统一治理，工程师会集体破防。
这套隐形层没有用户会点赞，但评审会上漏掉任何一项，上线后的 pager（告警器）会替你补课。你的团队最近一次复盘，是因为功能缺陷，还是这些"不存在于需求文档"的细节？
热门跟贴