接口报错到底该给前端多少细节？"堆栈裸奔"和"一坨 500"之间，中间态怎么做

背景

先打个比方：错误信息就像餐厅后厨的"出菜提示"。顾客问"这菜怎么还没上"，你要么回"我们 3 号灶的天然气阀门第 7 根管子漏了，请等 8 分钟"——太透，等于把后厨图纸递给了竞争对手；要么回"稍等"——太模糊，顾客根本不知道是排队还是出事了，只会一直催、一直投诉。

我最近帮 3 个团队做安全加固审计，翻了一遍他们的线上 API 错误返回，发现一个特别普遍的分歧：

• A 派（裸奔派）：500 Internal Server Error 直接带完整堆栈、SQL 报错、甚至 Redis 连接串。开发说"方便排查"，安全说"这是把数据库版本、表结构、框架版本、依赖路径一次性打包送给攻击者"。
• B 派（一坨 500 派）：所有错误统一返回 500, message=system error，日志里才记全量。安全满意了，但客服和前端抓瞎——同一个 500，用户到底是"参数错了"还是"我们系统真挂了"？无法分辨。
• C 派（中间态派）：业务错误用稳定的 errorCode + 用户可读 message，技术错误只回 requestId + 通用 message，堆栈全部进日志和 APM。

常见分歧（我观察到 3 个具体拉扯点）

1. 4xx 的业务错误要不要"细"？ 比如"库存不足"、"余额不够"、"该手机号已注册"——这些是业务规则，给细一点用户体验好；但"该手机号已注册"同时也是账号枚举的探针。我见过一个电商，登录接口直接回"账号不存在"vs"密码错误"两种不同文案，被脚本刷账号撞库刷了两周才被发现。

2. 5xx 的技术错误要不要"细"？ 我的立场是绝对不给堆栈，只给 requestId。但团队里总有开发反驳："我本地联调的时候看不到 detail 怎么调？"——这就引出第 3 点。

3. 本地联调 / 灰度 / 生产三套错误粒度，谁来管？ 我见过最好的做法是：错误响应结构统一，但 detail 字段由网关按来源裁剪——内网/带 debug token 的请求能看到，公网一律剥掉。这样开发联调不用切环境，攻击者也拿不到。

我的倾向

偏 C 派，但有一条底线：用户可见的 errorCode 一旦发布就不能变，因为它已经成了前端、客服、监控告警三方共同依赖的"契约"。技术错误只承诺 requestId 可查，其他一律不承诺。

理由有三：

• 安全侧：堆栈、SQL、依赖版本是攻击者的"地形图"，多给一个字段就多一条爆破路径；
• 体验侧：稳定的 errorCode 让前端可以做"友好文案 + 引导动作"（比如 STOCK_NOT_ENOUGH → 提示"看看类似的"），比裸 500 体验好一个量级；
• 可运维侧：requestId 是排障的唯一锚点，日志、APM、链路追踪全靠它对得上，比把堆栈怼到前端更管用。

想听大家

1. 你们线上 API 的错误返回结构长什么样？有没有踩过"错误文案被攻击者反向利用"的坑（比如账号枚举、版本指纹）？
2. 本地联调想看到 detail，生产又不能给——你们怎么解决？是网关裁剪、header 白名单、还是干脆两套响应体？
3. 有没有团队把 errorCode 当成对外契约来管理（变更走评审、有 changelog）？还是每次后端一抖，前端就跟着改？

欢迎带真实案例聊，越具体越好——尤其是那种"安全说必须改、开发说不能改"的拉锯战，我想听听你们最后怎么收的场。