触发器报错导致应用崩溃，是因为异常未被捕获而透传至客户端。需在应用层（如.NET中间件或Spring @ControllerAdvice）拦截SqlException等并返回友好提示，切忌在触发器内吞错或事务中静默捕获。
触发器报错为什么会让应用直接崩溃
SQL 触发器在执行期间抛出异常（比如 RAISERROR、THROW 或违反约束），默认会中止整个事务，并将错误原样透传到客户端。如果应用程序没对数据库异常做捕获或兜底，就可能触发未处理异常——尤其在 .NET 的 ExecuteNonQuery()、Java 的 PreparedStatement.executeUpdate() 这类同步调用里，错误直接变成运行时异常，进而导致线程中断、HTTP 500、甚至进程级崩溃（如未配置全局异常处理器的 ASP.NET Core 应用）。
常见现象包括：
- 前端收到空响应或 500，日志里只有类似
SqlException: The INSERT statement conflicted with the FOREIGN KEY constraint - 后台服务突然断连，堆栈里出现
System.Data.SqlClient.SqlException且无上层try/catch - 触发器里写了
RAISERROR('xxx', 16, 1)，但应用层没识别这个级别错误的语义，直接当致命错误处理
在 .NET 中用中间件拦截 SQL 异常
ASP.NET Core 不会自动捕获数据访问层抛出的异常，必须显式拦截。推荐在管道最外层加异常中间件，但要注意：它只能捕获 HTTP 请求生命周期内的异常，对后台任务、定时器、SignalR Hub 方法等不生效。
关键点：
- 中间件需放在
UseRouting()之后、UseEndpoints()之前 - 只捕获
SqlException和DbUpdateException，避免把业务逻辑异常也吞掉 - 检查
SqlException.Number判断是否来自触发器（例如 SQL Server 的自定义错误号通常 ≥ 50000） - 不要在中间件里重试或修复数据——触发器错误本质是业务规则冲突，应返回明确提示给前端
示例片段（简化）：
app.UseExceptionHandler(appBuilder =>
{
appBuilder.Run(async context =>
{
var exception = context.Features.Get<IExceptionHandlerFeature>()?.Error;
if (exception is SqlException sqlEx && sqlEx.Number >= 50000)
{
context.Response.StatusCode = 400;
await context.Response.WriteAsJsonAsync(new { error = "业务校验失败", detail = sqlEx.Message });
return;
}
// 其他异常走默认逻辑
});
});
Java Spring Boot 的 @ControllerAdvice 拦截方案
Spring 的 @ControllerAdvice 能统一处理 Controller 层抛出的异常，但前提是 DAO 层异常能向上冒泡。若用了 MyBatis，需确认 SqlSessionTemplate 没被静默吃掉异常；若用了 JPA，检查是否启用了 spring.jpa.properties.hibernate.jdbc.batch_size=0（批量模式下触发器错误可能延迟暴露）。
实操建议：
- 定义专用异常类如
TriggerValidationException，在 Service 层主动包装DataAccessException - 在
@ExceptionHandler中匹配该类型，返回ResponseEntity.badRequest() - 避免在
@Transactional方法里用try/catch吞掉异常——这会导致事务不回滚，数据状态不一致 - 注意 PostgreSQL 的触发器错误码是
P0001，MySQL 是HY000，需按驱动实际抛出的SQLException.getSQLState()匹配
触发器本身要不要加 TRY…CATCH？
SQL Server 支持在触发器里用 TRY...CATCH，但不推荐用来“兜住错误继续执行”。触发器本质是事务的一部分，强行 CATCH 后不 THROW，会导致主 DML 成功提交，而业务规则被绕过——比如本该拒绝的非法订单，结果进了库。
更稳妥的做法：
- 触发器只做轻量校验，复杂逻辑移出到存储过程或应用层
- 若必须拦截，
CATCH块里仍要THROW或RAISERROR，只是换一个更友好的消息（如RAISERROR('库存不足', 16, 1)） - 避免在
INSTEAD OF触发器里拼接动态 SQL——错误定位困难，且容易引入注入风险 - MySQL 的
BEFORE触发器无法使用DECLARE EXIT HANDLER捕获所有错误，部分约束违规（如 NOT NULL）会跳过 handler 直接报错
真正难处理的是跨库、异步写入、或触发器调用外部 Web API 的场景——这些地方的失败很难原子化回滚，得靠补偿事务或状态机，不是加个拦截就能解决的。
