iconv()字符串被截断的直接原因是遇到非法字节序列时默认中止转换并丢弃后续内容；mb_convert_encoding()更宽容，跳过或替换异常字节而不截断，适合处理不洁输入。
iconv() 转码时字符串被截断的直接原因
不是数据丢了，是 iconv() 遇到无法转换的字节序列时，默认行为是中止转换并丢弃后续所有内容。比如你传入一段混有 GBK 乱码或损坏字节的 UTF-8 字符串，执行 iconv('UTF-8', 'GBK', $str)，它可能在第一个非法位置就停住，返回一个远短于预期的字符串。
用 mb_convert_encoding 替代 iconv 处理不洁输入
mb_convert_encoding() 对非法字节更宽容，不会中途截断，而是跳过或替换异常字节，更适合处理真实业务中不可控的客户端输入。
- 把
iconv('UTF-8', 'GBK//IGNORE', $str)改成mb_convert_encoding($str, 'GBK', 'UTF-8') - 如果目标是导出 CSV 且需兼容 Excel（要求 GBK），但原始数据含非法 UTF-8 字节，
mb_convert_encoding能保长度、不断尾 - 注意：
mb_convert_encoding不支持//IGNORE这类修饰符，但它本身已内置容错逻辑
截断发生在文件名或 header 输出时的典型场景
常见于附件下载、IIS URL 重写、上传文件保存等环节——这些地方常需把 UTF-8 字符串转成 GBK 再交给系统层（如 Windows 文件系统或旧版 IE）。
- 不要对整个
$_GET或$_POST批量转码，只对明确需要 GBK 的字段单独处理 - 例如生成下载文件名：
$filename = mb_convert_encoding($originName, 'GBK', 'UTF-8');，再用于header("Content-Disposition: attachment; filename={$filename}.csv") - 若仍报错或截断，先用
mb_check_encoding($str, 'UTF-8')校验原始字符串是否真为合法 UTF-8；不是的话，得先清洗或按实际编码重解码
ThinkPHP 模板中 msubstr 截断显示异常的连带问题
当 msubstr() 或自定义 subtext() 函数内部调用了 mb_substr()，而传入的字符串已被 iconv() 截断过一次，那第二次截取就会基于错误长度计算，导致省略号错位或空字符串。
- 修复顺序必须是：先确保源字符串编码正确且完整 → 再做截取
- 模板中避免写
{$vo.title|msubstr=0,10,'utf-8',true}后又在控制器里用iconv()处理过该字段 - 统一入口做转码：比如在模型的
getAttr或访问器里用mb_convert_encoding规范化，模板只管显示
最易被忽略的是：你以为在某个中间件里“修好了编码”，其实 $_GET 和 $_POST 已被框架早期逻辑污染过；真正安全的干预点，只在 php://input 和 QUERY_STRING 尚未解析前——这比任何后续字符串修复都关键。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
