结论其实很清楚：这个错误的本质，就是 MySQL 拒绝把 NULL 写入定义为 NOT NULL 的字段中。但在实际排查时，问题通常没有表面看起来那么直接，真正的触发原因往往出在隐式类型转换、数据库驱动层的处理逻辑，或者 SQL mode（例如 STRICT_TRANS_TABLES）设置上——这些因素会先把原本传入的值“转换”为 NULL，随后才引发字段约束报错。因此，解决 MySQL Column cannot be 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 与 MySQL 的差异也要注意：Oracle 会把
''视为NULL，而 MySQL 并不完全等同——如果你的程序是跨数据库兼容写法，把""传到 Oracle 时就可能直接触发ORA-01400
外键字段和自增主键的特殊坑
外键字段和自增主键在出现 Column cannot be null 报错时，表面现象类似，但实际原因往往完全不同：
- 外键列本身是可以为
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 里，它们从来不是同一个概念。
