before触发器可安全修改new字段值，after中修改无效；禁止在触发器内update本表以防递归；insert中不可依赖new.id做逻辑；赋值需注意类型、长度及约束。
BEFORE 触发器里能直接改 NEW 字段值
可以，而且这是唯一安全修改当前行数据的方式。BEFORE INSERT 或 BEFORE UPDATE 触发器中，NEW 是一个可写的临时行对象，对它的字段赋值会直接影响即将插入或更新的那行数据。
常见错误现象：AFTER UPDATE 里试图改 NEW.column —— 没用，MySQL 会静默忽略，且不会报错；更糟的是，有人在 AFTER 里再执行 UPDATE 自己刚处理的表，触发递归调用，直接报错 Can't update table 'xxx' in stored function/trigger because it is already used by statement which invoked this stored function/trigger。
-
BEFORE触发器中，写SET NEW.name = UPPER(NEW.name);是合法且生效的 -
AFTER触发器中，SET NEW.id = 123;语法通过但无实际效果 - 想“修正”用户传入的数据（比如清洗手机号、补默认时间），必须放在
BEFORE
UPDATE 触发器里不能用 UPDATE 语句改本行
在触发器内部执行 UPDATE 修改同一张表的当前行，大概率触发递归或死锁。MySQL 默认禁止这种操作，不是因为技术做不到，而是为了避免隐式循环和不可控副作用。
使用场景：你可能想根据某字段变化自动更新另一字段（比如 status 变为 'done' 时写入 finished_at），但这完全可以用 BEFORE UPDATE SET NEW.finished_at = NOW(); 一行解决，没必要也不该用 UPDATE 语句。
- 触发器内执行
UPDATE t SET x=1 WHERE id = NEW.id;会报错Can't update table 't'... - 哪怕加了
WHERE条件精确匹配当前行，MySQL 仍视为“正在使用中”，不放行 - 绕开方法（不推荐）：用临时表中转、或改用应用层逻辑——但那就不是触发器该干的事了
INSERT 触发器里不能读取自增 ID 再反写回 NEW
在 BEFORE INSERT 中，NEW.id 还没生成（如果是 AUTO_INCREMENT），此时读 NEW.id 是 NULL 或默认值，无法用于计算或关联；而 AFTER INSERT 中虽然 NEW.id 已知，但不能再写回 NEW —— 它只读。
性能影响：有人想在 BEFORE INSERT 里先 SELECT MAX(id)+1 模拟自增，这不仅破坏并发安全，还拖慢插入速度，且极易冲突。
-
BEFORE INSERT：可设NEW.created_at = NOW()，但不能依赖NEW.id做逻辑 -
AFTER INSERT：可用NEW.id去写其他表（如日志、关联表），但不能改本行 - 如果业务真需要“插入后立刻基于 ID 做点什么”，优先考虑应用层获取
LAST_INSERT_ID()，而非塞进触发器
触发器里修改字段值要注意数据类型和约束
给 NEW.column 赋值时，MySQL 不会自动做类型转换或长度截断。如果赋的值超出定义范围，或者违反 NOT NULL、CHECK 约束，会在语句执行末尾统一报错，而不是在触发器里立即失败。
容易踩的坑：比如字段是 VARCHAR(10)，你在触发器里写 SET NEW.tag = CONCAT(NEW.prefix, '_suffix_longer_than_ten');，结果超长，插入失败，但错误位置指向原始 INSERT 语句，不容易定位到触发器里这行。
- 确保赋值前检查长度：
IF LENGTH(NEW.content) > 100 THEN SET NEW.content = LEFT(NEW.content, 100); END IF; -
NOT NULL字段在BEFORE INSERT中没被显式赋值，又没有默认值，就会报错 - 触发器里的逻辑越简单越好，复杂清洗尽量交给应用层，避免把校验逻辑分散在数据库和代码里
