能，MySQL 5.5+ 在 BEFORE 触发器中可用 SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT 抛出自定义错误，但必须搭配 MESSAGE_TEXT、仅限 BEFORE 时机、需预检约束（不可依赖兜底），且客户端需正确捕获。
SIGNAL 能自定义错误信息，但前提是用对了位置、语法和场景。MySQL 触发器本身不“无法”返回自定义错误——只是很多人没写对，或者误用了限制条件。
BEFORE 触发器中 SIGNAL 必须带 MESSAGE_TEXT
只写 SIGNAL SQLSTATE '45000' 是无效的：MySQL 会抛出空错误或默认的 Unknown error，客户端收不到你写的文案。
必须显式指定：SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = '用户名不能为空'。
常见错误现象：ERROR 1644 (45000): Unknown error 1644，就是漏了 SET MESSAGE_TEXT。
AFTER 触发器里 SIGNAL 不会阻断主操作
在 AFTER INSERT 中写 SIGNAL，语句其实已经执行完了——数据已落库，事务已提交（或即将提交），此时再抛错，客户端看到错误，但数据可能已不可逆地写入。
更糟的是：如果 AFTER 触发器里还试图修改本表（比如 UPDATE users SET updated_at = NOW()），会先触发 ERROR 1442 (HY000)，SIGNAL 根本没机会执行。
所以真正能可靠中断并返回自定义提示的，只有 BEFORE 触发器。
客户端收不到提示？检查 SQL 模式和驱动行为
即使触发器写了正确的 SIGNAL，以下情况也会导致“看似没返回”：
- MySQL 未启用严格模式：sql_mode 缺少 STRICT_TRANS_TABLES，部分校验失败会被静默处理，SIGNAL 不触发
- 应用层驱动吞掉了错误：比如 Python 的 pymysql 默认捕获异常但没打印 message_text，需显式访问 exc.args 或 exc.errno
- 错误被上层逻辑掩盖：比如 ORM 自动重试或 fallback 到默认提示，根本没透出原始 SQLSTATE '45000'
想覆盖外键/唯一索引错误，不能靠兜底，得预检
有人以为加个 BEFORE INSERT 触发器就能把 ERROR 1062 (23000) 或 ERROR 1452 (23000) 替换掉——但实际不行：系统约束检查发生在触发器执行之后（MySQL 内部顺序），SIGNAL 还没来得及跑，约束已先报错中断。
正确做法是主动预检：
- 查 SELECT 1 FROM parent_table WHERE id = NEW.parent_id，不存在就 SIGNAL
- 查 EXISTS(SELECT 1 FROM users WHERE email = NEW.email)，存在就 SIGNAL
注意：这些查询字段必须有索引，否则查重变全表扫描，写入性能崩塌。
真正的难点不在语法，而在于理解 MySQL 的执行时序：约束检查、触发器调用、语句执行三者不是线性可插队的。你以为的“拦截”，其实要抢在系统机制之前完成验证——这要求你清楚每一步谁先谁后，而不是只盯着 SIGNAL 写没写对。
