mysqli_real_escape_string无法解决字段超长问题，根源在于数据库字段长度限制而非SQL注入；应使用mb_strlen校验字符长度、mb_substr安全截断，并按字段特性定制处理策略。
导入时 mysqli_real_escape_string 无法解决字段超长问题
很多同学以为加了转义就能防截断，其实不是——数据库插入失败或静默截断，根源在字段定义长度（如 VARCHAR(20)），而非 SQL 注入。PHP 层面的转义只管特殊字符，不管字节数。一旦用户填了 30 个汉字进 VARCHAR(20) 字段（UTF8mb4 下占 120 字节），MySQL 默认会截断并报 Warning: Data truncated for column 'name' at row 1，但 PHP 不抛异常，容易漏掉。
实操建议：
- 导入前用
mb_strlen($value, 'UTF8')检查字符长度，不是strlen()（后者按字节算，中文会误判） - 对照数据库表结构，提前读取
SHOW COLUMNS FROM student_list LIKE 'name'获取Type字段里的长度限制（如varchar(20)） - 对超长字段，明确策略：截断（
mb_substr($value, 0, $maxLen, 'UTF8')）、标记报错、还是转成日志人工复核
用 str_pad 和 mb_substr 做安全截断不丢字
直接 substr 可能砍在中文中间，造成乱码；而 mb_substr 能按字符切，但要注意第三个参数必须是 'UTF8'，否则在非 UTF8 环境下失效。另外，有些字段如电话、学号需补零对齐（如统一 8 位学号），这时 str_pad 比手动拼接更稳。
示例：
立即学习“PHP免费学习笔记（深入）”；
// 姓名最多 10 字符，超长则截断且不破坏汉字 $name = mb_substr($_POST['name'] ?? '', 0, 10, 'UTF8'); // 学号强制补零到 8 位，不足左补 '0' $student_id = str_pad($_POST['id'] ?? '', 8, '0', STR_PAD_LEFT);
注意：mb_substr 在部分低版本 PHP（如 5.3 以下）可能未启用 mbstring 扩展，上线前务必确认 extension=mbstring 已开启。
批量导入时用 INSERT ... ON DUPLICATE KEY UPDATE 避免主键冲突引发截断掩盖
班级通信录常以学号/工号为主键，导入重复数据时若用普通 INSERT，会因主键冲突中断整个批次；若改用 INSERT IGNORE，又可能把本该报错的字段超长问题一起忽略掉。更稳妥的是用 ON DUPLICATE KEY UPDATE，它既继续执行后续行，又能通过 VALUES() 函数拿到原始值做二次校验。
例如：
INSERT INTO student_list (id, name, phone)
VALUES (?, ?, ?)
ON DUPLICATE KEY UPDATE
name = IF(CHAR_LENGTH(VALUES(name)) > 10, LEFT(VALUES(name), 10), VALUES(name)),
phone = IF(CHAR_LENGTH(VALUES(phone)) > 11, LEFT(VALUES(phone), 11), VALUES(phone));
这个写法把长度判断逻辑交给了 MySQL，但代价是失去 PHP 层的可读性和调试便利性——建议仅用于已知字段长度稳定、且需高吞吐的后台任务。
LOAD DATA INFILE 导入时字段截断不可控，必须预处理
有人图快用 LOAD DATA INFILE 直接灌 CSV，但它完全绕过 PHP，字段超长时 MySQL 会静默截断且不返回警告（除非开启 sql_mode=STRICT_TRANS_TABLES）。一旦通信录里出现“张三丰…”这种被截成“张三丰”的名字，后期很难追溯。
正确做法：
- 禁用裸
LOAD DATA INFILE，改用 PHP 逐行读 CSV +fgetcsv()解析 - 每行解析后立即校验各字段长度，记录错误行号和字段名，生成
import_error.log - 对 Excel 文件（.xlsx），用
phpspreadsheet读取，它默认按 Unicode 字符计数，比PHPExcel更准
真正麻烦的不是截断本身，而是不同字段对“超长”的容忍度不同：姓名可截，身份证号绝不能截，电话中间几位丢了就打不通——得为每个字段单独配规则，而不是写一个 trim_all_fields() 通杀。
