postgresql中需在before触发器内用正则lower(new.id) ~ '^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$'校验uuid格式，捕获非法值并raise exception，且必须return new；after触发器无法阻止写入，不可用于合法性拦截。
触发器里怎么判断 UUID 字段是否合法
PostgreSQL 本身不校验 UUID 字段值是否符合标准格式，哪怕你定义了 UUID 类型，插入 'abc' 或 '123' 也会被自动转成 00000000-0000-0000-0000-000000000000（即全零 UUID），而不是报错。所以光靠类型声明拦不住无效值。
必须在触发器中显式校验：用 to_uuid() 尝试转换，捕获异常；或用正则匹配标准 UUID 格式。
-
to_uuid()是最准的，但它不是内置函数，需先创建（PostgreSQL 14+ 可直接用，旧版要自己写） - 推荐正则：
NEW.id ~ '^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$'，注意大小写——UUID输入通常小写，但应用可能传大写，建议加ILIKE或用lower()统一处理 - 别用
LENGTH()+REPLACE()数横杠，容易漏判格式错误（比如多一个横杠或少一位）
BEFORE INSERT/UPDATE 中如何拦截并报错
校验逻辑必须放在 BEFORE 触发器里，且函数末尾必须 RETURN NEW（修改后行）或 RETURN NULL（丢弃操作）。只 RAISE EXCEPTION 不够——PostgreSQL 会继续执行后续逻辑，直到函数返回。
- 对
INSERT：检查NEW.id是否为空或非法；空值是否允许，取决于业务——若主键是UUID类型且NOT NULL，空值本身就会被约束拦住，触发器只需管“非空但非法” - 对
UPDATE：同样校验NEW.id，但要注意——如果业务允许更新 ID，就得同时比对OLD.id IS DISTINCT FROM NEW.id，避免误拦自增主键场景（虽然 UUID 一般不更新） - 示例片段：
IF NEW.id IS NOT NULL AND NOT (LOWER(NEW.id) ~ '^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$') THEN RAISE EXCEPTION 'invalid UUID format: %', NEW.id; END IF;
为什么不能在 AFTER 触发器里做这事
AFTER 触发器无法阻止数据写入。一旦进入 AFTER 阶段，INSERT/UPDATE 已完成，事务已修改数据。此时 RAISE EXCEPTION 只会让事务回滚，但副作用已发生——比如触发器里顺带写的审计日志、调用的外部函数、或提前发出去的通知，都可能无法撤回。
- 典型坑：有人把 UUID 校验放
AFTER INSERT，以为能“补救”，结果发现数据已经落库，只是最后报错回滚，但中间可能已触发下游同步或缓存更新 - 更隐蔽的问题：如果表上有多个触发器，
AFTER的执行顺序不可控，依赖它做校验等于把防线建在城门之后 - 唯一适合
AFTER的场景是纯记录类动作（如写日志、发消息），跟数据合法性无关
并发下 UUID 校验会不会有性能问题
正则匹配是轻量级 CPU 操作，单次开销微乎其微，远低于索引查找或磁盘 I/O。但在高吞吐写入场景下，仍要注意两点：
- 避免在触发器里查表（比如去
uuid_blacklist表验证），这会引入锁和延迟；UUID 格式校验必须是纯计算 - 如果业务需要“生成新 UUID”而非“校验传入值”，别在触发器里调
gen_random_uuid()—— 它依赖pgcrypto，且每次调用都有轻微随机开销；更稳的方式是应用层生成后传入 - 真正卡点往往不在校验本身，而在你是否忘了给
id字段建唯一索引——格式合法 ≠ 值不重复，这两层防护缺一不可
'00000000-0000-0000-0000-000000000000'），而这个值恰好能过正则，却在业务逻辑里被当“空”或“未设置”处理——校验通过了，语义却错了。**
