触发器中引用 NEW.xxx 报 Unknown column 错误，说明字段在表中不存在或命名不一致，常见于字段新增未更新触发器、拼写错误、反引号缺失、跨库字段映射错误或 ORM 动态生成字段名偏差。
触发器里引用 NEW.xxx 报 Unknown column 错误
说明触发器中写的字段名在对应表里根本不存在，MySQL 解析时直接失败，不是运行时报错。常见于建表后加了字段但忘了更新触发器，或拼写漏了下划线（比如 user_name 写成 username）。
实操建议：
- 执行
DESCRIBE table_name或SHOW COLUMNS FROM table_name，逐行比对输出和触发器里的NEW.field_name - 注意反引号：如果字段建表时用了
`user-id`这种含连字符的名，触发器里也必须写成NEW.`user-id`，不能省略 - 别依赖“看着像”：大小写在 Linux 下虽不区分列名本身，但若建表时用反引号定义了
`UserName`，那NEW.username就会报错 - 检查是否在子查询或嵌套逻辑里误用了
NEW——NEW只在当前触发器作用域有效，不能传进存储过程或函数里当参数用
BEFORE UPDATE 触发器里 NEW.field 赋值失败
赋值语句本身语法正确，但执行时报错，大概率是字段不允许为 NULL 或类型不兼容。例如给一个 NOT NULL 字段设了 NULL，或把字符串塞进 INT 列。
实操建议：
- 确认目标字段定义：
SHOW CREATE TABLE table_name，重点看DEFAULT、NOT NULL和数据类型 -
SET NEW.field = ...必须保证右侧表达式结果能隐式转为目标类型；避免用CONCAT('x', NEW.id)给INT字段赋值 - 如果字段有默认值，但你在触发器里显式设为
NULL，且没声明DEFAULT NULL，就会失败 - 别在同一个触发器里多次对同一字段赋值——后一次会覆盖前一次，但不会报错，容易掩盖逻辑问题
触发器跨库操作时提示字段不存在
明明目标表字段存在，但在触发器里写 INSERT INTO other_db.t2 (col1) VALUES (NEW.col1) 却报错，问题出在字段作用域隔离：NEW 只属于当前触发表，不能直接映射到另一张表的字段名。
实操建议：
- 字段名必须一一对应：确保
other_db.t2真有叫col1的字段，且类型兼容；不要假设“名字一样就能通” - 显式列出目标字段：
INSERT INTO other_db.t2 (target_col) VALUES (NEW.source_col)，避免用*或省略字段列表 - 检查字符集差异：如果源表用
utf8mb4，目标表是latin1，插入中文时字段虽存在，但会因编码不兼容导致截断或隐式失败，看起来像字段问题 - 权限不足也会表现为“字段找不到”：用户对
other_db.t2没有SELECT权限时，SHOW COLUMNS FROM other_db.t2都查不到，更别说触发器里引用了
ORM 生成的触发器 SQL 中字段名动态拼接出错
触发器本身没问题，但应用层（如 Django、Laravel）自动生成的 SQL 里字段名被错误替换，比如模型字段名改了，但迁移没跑全，或模板里硬编码了旧字段名。
实操建议：
- 别信报错信息里的字段名——它可能是变量插值结果。用
SELECT @@version;和SHOW CREATE TRIGGER trigger_name看实际存进去的 SQL - Django 用户检查
models.py中字段定义和db_column参数是否一致；Laravel 用户核对模型里的$fillable和数据库真实字段 - 临时关闭 ORM 日志脱敏，在日志里抓完整 SQL，复制到
mysql -e "..."手动执行，确认是不是字段问题还是权限/上下文问题 - 避免在触发器里调用 ORM 方法或拼接字段名字符串——触发器是纯 SQL 层，不认 Python/PHP 变量
