报错1366 Incorrect string value是因为MySQL拒绝写入4字节UTF-8字符（如emoji、生僻汉字），根源在于phpEnv中MySQL默认字符集为utf8（即utf8mb3）且PHP连接未显式指定utf8mb4，导致客户端与服务端编码不匹配。
直接说结论：报错 1366 Incorrect string value 是因为 MySQL 拒绝写入 4 字节 UTF-8 字符（如 emoji、某些生僻汉字），根源几乎总是客户端连接没走 utf8mb4，而你用的是 phpEnv —— 它默认的 MySQL 配置和 PHP 连接行为大概率仍停留在 utf8（即 utf8mb3）。
phpEnv 中 MySQL 的默认字符集不是 utf8mb4
phpEnv 封装的 MySQL（尤其是旧版或一键安装包）通常沿用历史配置：character-set-server 和 collation-server 默认是 latin1 或 utf8（注意：MySQL 的 utf8 实际只支持最多 3 字节，不兼容 emoji）。即使你建库时写了 CHARACTER SET utf8mb4，服务端默认值不改，新连接仍可能 fallback 到 latin1。
检查方法：
- 进 phpEnv 控制面板或 SSH 进 MySQL，执行
SHOW VARIABLES LIKE 'character_set_server';—— 若返回utf8或latin1，就坐实了问题 - 修改方式：编辑 phpEnv 对应 MySQL 的
my.ini或my.cnf（路径常为phpEnv\mysql\conf\my.ini），在[mysqld]段下添加：
character-set-server = utf8mb4 collation-server = utf8mb4_unicode_ci
然后重启 phpEnv 的 MySQL 服务。不重启，改了也白改。
立即学习“PHP免费学习笔记（深入）”；
PHP 连接时没显式声明 utf8mb4
phpEnv 自带的 PHP 版本本身没问题，但你的代码如果还沿用老写法，比如：
-
$pdo = new PDO("mysql:host=localhost;dbname=test", $u, $p);—— 缺charset=utf8mb4 -
$mysqli->set_charset('utf8');—— 写的是utf8，不是utf8mb4 - 或更隐蔽的：
mysqli_connect(...)第 7 个参数传'utf8'
这些都会让连接使用 MySQL 的“默认客户端字符集”，而那个默认值就是上面没改对的 latin1 或 utf8，导致插入 emoji 时触发 1366 错误。
正确写法只有两个可靠路径：
- PDO：DSN 中必须带
charset=utf8mb4，且加PDO::ATTR_EMULATE_PREPARES => false - mysqli：连接后立刻调用
$mysqli->set_charset('utf8mb4')（不能漏掉mb4）
别信“我在 my.cnf 里设了，PHP 就会自动继承”——不会。
验证三值是否真为 utf8mb4
光改配置、写对代码还不够。MySQL 连接建立后有三个关键变量控制传输编码：@@character_set_client、@@character_set_connection、@@character_set_results。只要其中任意一个是 utf8 或 latin1，1366 就可能复现。
连接成功后，立即执行：
SELECT @@character_set_client, @@character_set_connection, @@character_set_results;
期望输出全是 utf8mb4。如果不是：
- 说明 DSN 或
set_charset()没生效（比如语句写在query()之后） - 或者被中间件、框架的自动连接池覆盖（如 Laravel 的
database.php配置里没写charset和collation） - phpEnv 的 Apache/Nginx 模块可能缓存了旧连接，试下重启整个 phpEnv 环境
phpEnv 下容易被忽略的 BOM 和文件编码
phpEnv 运行在 Windows 上的概率很高，而 Windows 记事本/部分编辑器保存 PHP 文件时默认加 BOM。BOM 是 3 字节的隐藏头（\xEF\xBB\xBF），一旦存在，PHP 会把它当普通输出提前发送，导致 header() 失败、JSON 输出异常，间接影响字符集协商逻辑。
检查方式：
- 用 VS Code 打开 PHP 文件，右下角看编码标识 —— 必须是
UTF-8，且显示with BOM就要点击切换成UTF-8 without BOM - 用命令行查：
file -i your_script.php（Linux/macOS）或用 HxD 查十六进制头
连数据库前的 header('Content-Type: text/html; charset=utf-8'); 和 HTML 中的 <meta charset="utf-8"> 也得同步确认，否则浏览器按错误编码解析，你看到的“乱码”可能根本不是数据库层的问题。
真正卡住人的地方，从来不是“该不该用 utf8mb4”，而是五层链路（MySQL server → 连接参数 → PHP 文件编码 → HTTP header → HTML meta）中任意一层悄悄退回到 utf8 或漏掉 mb4 后缀。phpEnv 把环境封装起来，反而让这些隐性依赖更难察觉。
