thinkphp 的 require 验证不等同于数据库 not null 约束，因二者职责不同：require 判定请求中字段是否存在且非空，not null 仅拦截写入时的 null 值；若 php 层未显式校验，将直接触发 mysql 错误而非友好提示。
ThinkPHP 本身不处理数据库层的 NOT NULL 约束校验，也不自动将数据库约束映射到 PHP 层验证；如果字段在数据库设了 NOT NULL 但 PHP 层没做对应校验，插入时就会直接报 MySQL 错误（如 Column 'xxx' cannot be null），而不是友好的业务提示。
为什么 validate() 里的 require 不等于数据库 NOT NULL
两者职责不同：require 是对「请求数据中该键是否存在且非空」做判断，而数据库 NOT NULL 是对「写入值是否为 NULL」做拦截。常见脱节点：
- 前端没传
status字段 →$request->param()里压根没有status键 →require规则根本不会触发（因为字段不存在） - 前端传了
"status": null或"status": ""→require会失败，但如果你用array_merge($defaults, $data)补了默认值，require就可能绕过 - 模型
save()时没显式调用validate(true)→ 所有验证规则都被跳过，直接交由数据库兜底
补全结构 + 显式验证必须一起做
光靠默认值补键、或光靠 require 都不够。真实链路是：原始请求 → 补缺 → 验证 → 写入。关键动作：
- 用
array_merge($defaults, $this->request->param())确保所有业务必填字段都有 key（哪怕值是null） - 验证规则里对这些字段写
'status' => 'require|number'，而不是只依赖default - 调用
$model->validate(true)->save($data)，TP6 中validate(true)是硬性开关 - 避免在模型
$type里只写'status' => 'integer'—— 它只转类型，不补 key，也不拦null
数据库约束不能代替 PHP 层校验
MySQL 的 NOT NULL 是最后一道防线，不是第一道。它带来的问题很实际：
- 报错信息是
SQLSTATE[HY000]: General error: 1048 Column 'name' cannot be null，前端无法解析，只能记日志 - 事务中若多个操作，其中一个因
NOT NULL失败，可能已执行的前序操作没回滚（除非你手动包try/catch + rollback） - API 返回 500 而不是 400，不符合 RESTful 规范，前端难做统一错误处理
- 某些字段允许为空（比如
remark），但业务上「未传」和「传了空字符串」语义不同，数据库约束完全无法区分
真正稳的方案，是把结构补全、字段存在性判断、空值/非法值过滤、类型转换这四步全收口在控制器入口处，别指望某一层自动帮你兜底。漏掉任意一环，NOT NULL 就会突然跳出来打脸。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
