before insert触发器中可通过直接赋值new.字段名覆盖null值，mysql用set语句、postgresql需return new；default约束对显式传入的null无效，故需触发器兜底；应用层预处理是更可控的首选方案。
BEFORE INSERT 触发器里怎么给 NULL 字段赋默认值
直接在触发器里对 NEW.字段名 赋值就能覆盖原始插入值，包括 NULL。MySQL 和 PostgreSQL 都支持，但语法细节不同——MySQL 允许直接赋值，PostgreSQL 要用 RETURN NEW 显式返回修改后的行。
常见错误是写成 SET NEW.col = 'default' WHERE NEW.col IS NULL，这是错的：BEFORE INSERT 触发器中没有 WHERE 子句，也不能用 DML 语句操作 NEW；只能逐字段判断并赋值。
- MySQL 示例（给
created_at和status补默认值）：CREATE TRIGGER users_before_insert BEFORE INSERT ON users FOR EACH ROW BEGIN IF NEW.created_at IS NULL THEN SET NEW.created_at = NOW(); END IF; IF NEW.status IS NULL THEN SET NEW.status = 'active'; END IF; END; - PostgreSQL 示例需注意：必须以
RETURN NEW结尾，否则插入会失败CREATE OR REPLACE FUNCTION set_default_user_values() RETURNS TRIGGER AS $$ BEGIN IF NEW.created_at IS NULL THEN NEW.created_at := NOW(); END IF; IF NEW.status IS NULL THEN NEW.status := 'active'; END IF; RETURN NEW; -- 这行不能少 END; $$ LANGUAGE plpgsql;
为什么不能在 DEFAULT 约束里解决所有问题
DEFAULT 约束只在显式省略字段时生效，一旦客户端传了 NULL，哪怕字段允许为空，DEFAULT 也不会触发。而业务代码经常「主动传 NULL」表示“不填”，这时候就得靠触发器兜底。
比如 ORM 框架生成的 INSERT 语句可能把未设置的字段全写成 NULL，或者前端传参缺失时后端未做清洗就拼 SQL，这些场景下 DEFAULT 完全失效。
-
DEFAULT CURRENT_TIMESTAMP对NULL无效，只有字段没出现在 INSERT 列表里才生效 - 复合逻辑默认值（如“若 category 为空则取 parent.category”）无法用
DEFAULT表达，必须进触发器或应用层 - 某些数据库（如 SQLite）的
DEFAULT不支持函数表达式，NOW()类函数必须靠触发器
触发器补默认值容易踩的三个坑
补默认值看着简单，但线上出过不少静默故障，核心问题都集中在“什么时候该干预”和“改了会不会破坏业务语义”。
- 别无差别覆盖所有
NULL：有些字段的NULL是有意义的（比如deleted_at为NULL表示未删除），要严格按字段语义判断，而不是统一IF NEW.x IS NULL - 避免触发器里调用耗时函数：比如在
BEFORE INSERT里查另一张表来决定默认值，会拖慢写入、还可能引发死锁；这类逻辑尽量前置到应用层 - MySQL 中触发器不能修改被插入表以外的表，如果需要联动更新（如同时更新统计计数），得用
AFTER INSERT，但那就没法影响当前插入行的值了
替代方案：应用层预处理比触发器更可控
触发器是兜底手段，不是首选。真正健壮的做法是在 ORM 或 DAO 层做字段默认值填充，比如：
- Java MyBatis-Plus 的
@TableField(fill = FieldFill.INSERT)配合自定义MetaObjectHandler - Python SQLAlchemy 的
default（非数据库级）或before_insert事件钩子 - Node.js TypeORM 的
@BeforeInsert()实体监听器
这样既能统一控制逻辑，又避免数据库耦合，还能在单元测试里直接验证默认值行为。触发器只留给那些无法修改应用代码的遗留系统，或者必须保证“哪怕绕过应用直连 DB 也安全”的极端场景。
真要用触发器补默认值，务必在每个赋值前加明确注释说明业务意图，比如 -- status=NULL 表示前端未选择，强制设为 active，否则半年后没人记得当初为啥这么写。
