接口统一异常处理的目的，是让调用方能识别错误并让团队找到证据，而不是把所有失败包装成相同的成功响应。对于 .NET 业务系统，需要同时约定 HTTP 状态、业务错误和排查标识。
先区分请求错误与服务故障
参数缺失、权限不足、业务状态冲突和未预期异常需要不同处理。把它们全部变成 500 会制造告警噪声；全部返回 200 又会让调用方和监控误判。应结合已有客户端兼容性逐步调整，不能只改后端格式。
返回给用户的信息与内部日志分开
响应可以提供稳定错误码、简短说明和请求关联标识，内部日志记录必要异常上下文。生产响应不应暴露连接字符串、完整堆栈或内部路径。错误说明也要区分用户可以修正的问题与需要稍后重试的情况。
用统一结构保留业务差异
可评估 ProblemDetails 等结构，但业务错误码仍需有含义和维护责任。避免每个控制器手工拼 JSON；同时检查中间件、认证失败和路由不存在等路径是否也遵守约定，而不仅是 Action 内抛出的异常。
验收真实客户端的失败行为
覆盖参数错误、未登录、无权限、状态冲突和依赖不可用。检查前端提示、重试策略及监控分类是否一致。交付物应包含错误契约和示例响应，不只是一段全局捕获代码。
常见问题：统一异常处理后，还需要业务层返回失败结果吗？
需要按业务语义选择。预期的业务拒绝可以用明确结果表达，不必全部依赖异常控制正常流程。
技术参考：微软：ASP.NET Core 异常处理。具体接口与配置请结合使用版本核对。
将评估落实到你的系统
如果内部团队需要把这些约定落到可运行的工程中，可以通过微服务基础架构建设沟通接口、公共能力与交接范围，先以一个业务场景验证方案。