微服务内部调用，要不要给每个接口都上鉴权？聊聊"内网=安全"这个老习惯

先抛个背景：最近帮几个团队做安全加固，发现一个特别普遍的现象——外部入口有网关、有鉴权、有审计，可一旦流量进了内网，服务之间的调用就像"进了自家小区的门"，基本是裸奔：HTTP 明文、无 token、无签名，谁都能调谁。

我打个比方：这就像把银行金库的门锁得死死的，但金库到柜台之间那条走廊，保安是拿绳子随便一拦的。外面的人进不来，可一旦走廊里混进一个人（比如某个被攻破的服务、一个误配的路由、一次 SSRF），后面就全敞开了。这也是为什么"内网=安全"这句话，我越来越觉得是个危险的默认假设。

但我也知道，"每个接口都上鉴权"不是免费的，这里有几个真实的分歧点，想听听大家的做法：

1. 性能 vs 安全：内部调用往往 QPS 很高，每个请求都验签、验 token，会不会把延迟和 CPU 吃上去？大家是倾向于全量鉴权，还是只对"敏感接口"（比如改余额、改权限、删数据）做加强，读接口放宽？

2. 怎么鉴权：内部调用到底用 JWT、mTLS、还是简单的共享密钥 + 签名？mTLS 看着最优雅，但证书管理、轮转的运维成本是真的高；JWT 又担心泄露后一把梭。你们生产上现在跑的是哪一套？

3. 谁来兜底：如果坚持"内网默认信任、敏感接口单独加固"，那"哪些算敏感"的清单谁维护、怎么防漏？我见过不少团队这个清单就是靠口口相传，新接口一上来就忘了标。

我个人的倾向是：默认不信任，但分级处理——所有内部调用至少带上"我是谁"的身份（哪怕只是 mTLS 的服务身份），改数据类的接口必须再叠加一次细粒度校验，纯读的内部接口可以只依赖网络层隔离 + 身份可追溯。理由是不追求一步到位的完美，而是保证"出事了能追溯到谁、且攻击者不能一步跨到最敏感的操作"。

想问问大家：你们在什么场景下会选哪一档？特别是——当安全要求被业务方以"影响性能/太麻烦"顶回来的时候，你们一般怎么取舍、怎么留痕？欢迎拿真实案例来聊。