结论：该错误是mysql拒绝将null插入not null字段，真正原因常为隐式转换、驱动行为或sql模式（如strict_trans_tables）导致值变为null后触发约束；需查字段定义、历史数据、sql mode及应用层传值逻辑。
直接说结论：这个错误不是“你没传值”，而是MySQL明确拒绝把NULL塞进一个定义为NOT NULL的字段——但真正卡住你的，往往是隐式转换、驱动行为或SQL模式在背后捣鬼。
查字段定义和当前数据是否冲突
错误提示里那个字段名，先去确认它是不是真被设成了NOT NULL：
- 执行
DESCRIBE table_name;或SHOW COLUMNS FROM table_name LIKE 'col_name';，看Null列是否显示NO - 如果显示
NO，再查历史数据：SELECT COUNT(*) FROM table_name WHERE col_name IS NULL;—— 如果有结果，说明表里已有NULL，但你又想加NOT NULL约束，这一步就会失败 - 别信“我什么都没填，应该自动用默认值”——如果字段没设
DEFAULT，又NOT NULL，那没传值就等于传了NULL，直接撞墙
检查SQL mode是否开启严格模式
STRICT_TRANS_TABLES 是最常背锅的配置。它会让MySQL在类型转换失败（比如往INT插'abc'）后不静默转成0，而是把值变成NULL，再触发NOT NULL报错。
- 运行
SELECT @@sql_mode;，如果返回里含STRICT_TRANS_TABLES，基本就是它 - 临时验证：执行
SET sql_mode = '';，再重试插入；成功了就坐实问题 - 永久修复：改
my.cnf（Linux）或my.ini（Windows），在[mysqld]段写sql-mode="NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"，然后重启MySQL - 顺手检查
explicit_defaults_for_timestamp—— MySQL 5.6+ 默认ON，会导致无默认值的TIMESTAMP列被当成NOT NULL，加一行explicit_defaults_for_timestamp=OFF更稳
排查应用层传值逻辑
代码里看似没传值，其实可能悄悄塞了个NULL或空字符串''：
- Java JDBC：
PreparedStatement.setString(1, "")往INT列插，某些驱动会转成NULL再撞NOT NULL；应改用setInt()等类型匹配方法 - PHP PDO：
bindValue(':name', $_POST['name'])—— 如果$_POST['name']未提交或为空，实际传的是NULL；得加判断：!empty($_POST['name']) ? $_POST['name'] : null，并确保数据库字段允许NULL或提供默认值 - C# MySQL Connector：
@param语法在较老版本可能解析异常，优先换用?占位符；或连接串加oldsyntax=true - Oracle vs MySQL差异：Oracle把
''当NULL，MySQL不等价——如果你的代码是跨库写的，传""到Oracle会直接触发ORA-01400
外键字段和自增主键的特殊坑
这两类字段出错时，表现一样，原因完全不同：
- 外键列本身可以为
NULL，但前提是建表时没写NOT NULL；查INFORMATION_SCHEMA.COLUMNS确认IS_NULLABLE是YES还是NO；如果是NO但业务需要留空，就得ALTER TABLE tbl ALTER COLUMN fk_col INT NULL; - 自增主键（
AUTO_INCREMENT）列如果报Column 'id' cannot be null，大概率是INSERT语句里显式写了id = NULL，或者用了INSERT INTO t(id) VALUES (NULL)；正确做法是省略该字段，或写DEFAULT - 还有一种情况：表里已有数据，但自增起始值被手动调高（
ALTER TABLE t AUTO_INCREMENT = 100），而新插入ID刚好卡在间隙里，某些场景下也会误报这个错——用SHOW CREATE TABLE核对AUTO_INCREMENT值
最麻烦的不是报错本身，而是错误掩盖了真实问题：关掉strict mode能过，但可能让脏数据悄悄入库；改代码补默认值，却忘了旧数据里混着''和NULL两种“空”，它们在MySQL里完全不等价。
