ERROR 1364 是因 MySQL 严格模式（含 STRICT_TRANS_TABLES）拦截了对 NOT NULL 且无默认值字段的空插入；确认方式为在 phpMyAdmin 执行 SELECT @@sql_mode；临时解法是 SET SESSION sql_mode 去掉严格项，永久解法是修改 phpEnv 自带的 my.ini 中 sql-mode 配置并重启服务。
phpEnv 下 MySQL 报错 ERROR 1364: Field 'xxx' doesn't have a default value，本质不是 phpEnv 的问题，而是它内置的 MySQL（通常是 5.7 或 8.0）默认启用了严格模式（STRICT_TRANS_TABLES），你插入数据时漏填了 NOT NULL 且无默认值的字段，校验直接拦截。
怎么确认是 strict_mode 导致的
进 phpEnv 控制面板 → 点击「MySQL」→ 「phpMyAdmin」→ 执行 SQL：
SELECT @@sql_mode;
如果返回结果里含 STRICT_TRANS_TABLES 或 STRICT_ALL_TABLES，就是它。phpEnv 默认配置基本都带这个，尤其新版集成包。
临时绕过：用 SET 修改当前会话模式
适合调试、导入 CSV、跑通初始化脚本。执行后本连接生效，重启就恢复：
立即学习“PHP免费学习笔记（深入）”；
SET SESSION sql_mode = 'NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION';
- 别用
SET GLOBAL—— phpEnv 多数没给 root 的全局权限，会报Access denied - PHP 代码里执行也行，但得在
INSERT前调用一次：$pdo->exec("SET SESSION sql_mode = 'NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION'"); - 注意：这不修复数据逻辑，只是让 MySQL 把缺失值转成隐式默认（如
''、0），字段类型不同行为不同，比如DATETIME可能变成'0000-00-00'
永久关闭（phpEnv 环境下最稳妥的改法）
phpEnv 的 MySQL 配置文件路径固定，不用猜：
- Windows：打开
phpEnv\MySQL\my.ini - macOS/Linux（若用 Docker 版 phpEnv）：进容器查
/etc/my.cnf或/usr/my.cnf
找到 [mysqld] 段，在下面找 sql-mode 行。常见写法有：
sql-mode="STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION"
改成：
sql-mode="NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"
⚠️ 注意：NO_AUTO_CREATE_USER 在 8.0.11+ 已废弃，但 phpEnv 当前主流 MySQL 版本（5.7.x）仍需要它；逗号前后不能有空格，否则启动失败。
改完必须重启 phpEnv 的 MySQL 服务（控制面板点「重启 MySQL」或命令行 net stop mysql && net start mysql）。
为什么别直接 ALTER TABLE 加 DEFAULT
看起来最“正统”，但实际在 phpEnv 场景容易翻车：
-
ALTER TABLE t ADD COLUMN platId INT NOT NULL DEFAULT 0;—— 如果表已有数据，MySQL 会拒绝，除非加ALGORITHM=INSTANT（5.7 不支持） - 用户表（
mysql.user）绝对不要手动ALTER或INSERT，字段如ssl_cipher、x509_issuer是权限系统强依赖字段，乱设默认值会导致登录失败 - ORM（如 Laravel Eloquent、ThinkPHP）生成的迁移可能忽略
DEFAULT，只设NOT NULL，此时加默认值要同步改模型层逻辑，否则 PHP 写入仍可能漏字段
真正该补默认值的，是业务表里你明确知道可安全兜底的字段（比如 status TINYINT DEFAULT 1）；其他字段，优先从插入逻辑补全值，而不是靠数据库妥协。
复杂点在于：phpEnv 是封装环境，你看到的「MySQL」其实是它打包好的二进制 + 预置配置，所有修改都得落在它的文件路径里，而不是系统级 MySQL。很多人卡在找不到 my.ini，其实就在 phpEnv 安装目录的 MySQL\ 子文件夹下——别去系统 C:\Windows 或 /etc 找。
