ERROR 1366是因字符集链路断裂导致：需同步修改phpEnv的my.ini中[client]、[mysql]、[mysqld]三段为utf8mb4，建库建表显式指定utf8mb4，PHP连接时调用mysqli_set_charset()或DSN加charset=utf8mb4，并清洗GBK/latin1污染的源数据。
phpEnv 里 MySQL 报 1366 错误，根本不是 phpEnv 的锅
phpEnv 只是 Windows 下的集成环境套件，它本身不决定字符集行为。报 ERROR 1366 (HY000): Incorrect string value，说明你正在往 MySQL 插入 utf8mb4 字节（比如 emoji 或生僻汉字），但某一层用了旧式 utf8（即 utf8mb3）或 latin1。phpEnv 默认配的 MySQL 5.7/8.0 多数仍沿用老配置，character_set_server 很可能还是 utf8，而不是 utf8mb4。
必须改 phpEnv 自带的 my.ini，且改对位置
别只改 [mysqld] 段——phpEnv 启动时同时读 [client]、[mysql]、[mysqld] 三处。漏掉任一环节，连接层就断链：
-
[client]段加default-character-set=utf8mb4 -
[mysql]段加default-character-set=utf8mb4 -
[mysqld]段加character-set-server=utf8mb4和collation-server=utf8mb4_unicode_ci
改完重启 phpEnv 的 MySQL 服务（不是仅重启面板）。验证：连上后执行 SHOW VARIABLES LIKE 'character_set%';，确保 character_set_client、character_set_connection、character_set_results、character_set_server 全是 utf8mb4。
数据库和表结构不自动继承 my.ini 设置
即使服务端配对了，新建库/表默认字符集仍可能 fallback 到旧值。不能依赖“改完配置就万事大吉”：
立即学习“PHP免费学习笔记（深入）”；
- 建库时显式指定：
CREATE DATABASE mydb CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; - 已有库需 ALTER：
ALTER DATABASE mydb CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci; - 已有表需逐个改字段：
ALTER TABLE users CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;（注意：这会重写整张表，大数据量慎用）
别信 ALTER TABLE ... DEFAULT CHARSET=utf8mb4 ——它只改新列默认值，不转换已有数据的存储编码。
PHP 连接 MySQL 时必须显式声明 utf8mb4
phpEnv 里的 PHP 默认用 mysqlnd 驱动，但不会自动读 my.ini 的字符集。你在代码里用 mysqli 或 PDO 连接时，必须手动设：
mysqli_set_charset($conn, 'utf8mb4');- PDO DSN 加参数：
charset=utf8mb4，例如mysql:host=localhost;dbname=test;charset=utf8mb4
漏掉这步，哪怕数据库和表全配对了，PHP 发送的请求仍按 latin1 或 utf8 解释字节，MySQL 收到 \xF0\x9F\x98\x8A 就直接拒收。
最易被忽略的是：Windows 下从记事本复制中文进 SQL 文件再导入，文件实际是 GBK 编码却无 BOM，phpEnv 的命令行 mysql 客户端默认当 latin1 读——这时候改 my.ini 也没用，得先用 iconv -f GBK -t UTF-8//IGNORE input.sql > cleaned.sql 转码，再导入。
