触发器中慎用replace，易误删数据；应优先用regexp_replace（postgresql）或生成列（mysql 8.0+）标准化字段，并注意字符集、全角空格及业务语义。
触发器里用 REPLACE 会丢数据，别直接写在 INSERT 触发器里
MySQL 和 PostgreSQL 的 BEFORE INSERT 触发器确实能改 NEW 行的字段值，但直接对字符串字段反复套 REPLACE 容易出错：比如把 '00123' 里的前导零全干掉变成 '123'，而你其实只想清理中间空格；又或者误删了用户本意保留的连字符（如电话号 '138-0013-8000'）。关键不是 REPLACE 不能用，而是它太“粗暴”——没有上下文判断能力。
实操建议：
- 只对明确约定格式的字段用，比如统一要求去除全角空格、制表符、回车符：
REPLACE(REPLACE(REPLACE(NEW.phone, '\t', ''), '\r', ''), '\n', '') - 避免嵌套超过三层
REPLACE，可先用TRIM清首尾，再单独处理内部符号 - 如果字段可能含 JSON、URL 或带分隔符的编码（如
'A,B,C'），绝对不要无差别替换逗号或斜杠
PostgreSQL 中用 REGEXP_REPLACE 比 REPLACE 更安全
MySQL 的 REPLACE(str, from_str, to_str) 是纯子串替换，没法限定位置或加条件；PostgreSQL 的 REGEXP_REPLACE 支持模式匹配和全局/局部替换，更适合标准化场景。比如统一手机号为 11 位纯数字，同时保留原始值用于审计：
CREATE OR REPLACE FUNCTION normalize_phone() RETURNS TRIGGER AS $$
BEGIN
NEW.phone_clean := REGEXP_REPLACE(NEW.phone, '[^\d]', '', 'g'); -- 去所有非数字
IF LENGTH(NEW.phone_clean) != 11 THEN
RAISE EXCEPTION 'invalid phone length: %', NEW.phone_clean;
END IF;
RETURN NEW;
END;
$$ LANGUAGE plpgsql;
注意点：
-
'g'参数必须加，否则只换第一个匹配项 - 别用
REGEXP_REPLACE(NEW.phone, '\s+', '', 'g')清空格——\s在 PostgreSQL 里默认不匹配全角空格，得显式写[[:space:] ]（中文全角空格是 U+3000） - 函数体里别漏
RETURN NEW，否则新行会被静默丢弃
MySQL 8.0+ 可用生成列 + 触发器组合，避免运行时重复计算
如果标准化逻辑固定（如邮箱转小写、身份证号脱敏前 6 位），与其每次 INSERT 都跑一遍 REPLACE，不如用生成列存结果，触发器只负责校验。这样查询快，且避免触发器里修改 NEW 引发的隐式类型转换问题：
ALTER TABLE users ADD COLUMN email_norm VARCHAR(255) GENERATED ALWAYS AS (LOWER(TRIM(email))) STORED;
再配一个轻量触发器做兜底：
DELIMITER $$
CREATE TRIGGER check_email_format
BEFORE INSERT ON users
FOR EACH ROW
BEGIN
IF NEW.email NOT REGEXP '^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}$' THEN
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Invalid email format';
END IF;
END$$
DELIMITER ;
好处是：
- 标准化逻辑集中在 DDL 层，应用和触发器都不用重复写
REPLACE - 生成列可建索引，
WHERE email_norm = 'a@b.c'查询走索引 - MySQL 5.7 不支持 STORED 生成列，此时只能老实用触发器，但务必在触发器开头加
IF NEW.email IS NOT NULL THEN ... END IF;防空值报错
真正容易被忽略的坑：字符集和排序规则影响 REPLACE 行为
同一个 REPLACE(col, ' ', '') 在 utf8mb4_0900_as_cs 和 utf8mb4_unicode_ci 下结果可能不同——前者区分大小写和变音符号，后者会把 'é' 和 'e' 当等价字符处理。更隐蔽的是全角空格（U+3000）和半角空格（U+0020）在多数 collation 下不等价，但 REPLACE 默认只认字面值。
所以：
- 检查字段 collation：
SHOW FULL COLUMNS FROM users LIKE 'name';，如果不是utf8mb4_bin，REPLACE对 Unicode 符号的识别可能失效 - 清理全角空格必须显式写出：
REPLACE(NEW.name, ' ', '')（注意这个空格是中文输入法下的） - MySQL 8.0+ 可用
CONVERT(NEW.name USING utf8mb4)强制转码，但会损失性能，仅限脏数据临时救急
标准化不是加一层 REPLACE 就完事，得看字段实际进来的字符范围、业务对“标准”的定义粒度，以及数据库底层怎么存、怎么比。没理清这三点就写触发器，大概率修一个 bug 引出三个新 bug。
