最典型报错是“notice: iconv(): detected an illegal character in input string”或返回false；因iconv零容忍非法字节且默认不抛异常，易在csv或上传文件中静默失败，需用//ignore或//translit容错，或改用更稳的mb_convert_encoding。
iconv 函数转换失败时常见报错是什么
最典型的是 Notice: iconv(): Detected an illegal character in input string，或者直接返回 false。这不是 PHP 报错级别高，而是它默认不抛异常，容易被忽略——尤其在批量处理 CSV 或用户上传文件时，某一行含 BOM、混合编码（比如 GBK 里夹了个 UTF-8 emoji）就会静默截断或崩掉整个转换。
根本原因是 iconv() 对非法字节零容忍，且默认不启用容错模式。解决办法只有两个：
- 加
//IGNORE后缀：如iconv('GBK', 'UTF-8//IGNORE', $str)，跳过无法转换的字节（但可能丢数据） - 加
//TRANSLIT：尝试音译替代（如把 “é” 转成 “e”），但对中文无效，且某些系统不支持 - 先用
mb_detect_encoding($str, ['UTF-8', 'GBK', 'BIG5'], true)粗略判断源编码，再传给iconv()，避免硬写错源码表
mb_convert_encoding 处理中文乱码更稳，但要注意什么
它底层用的是 PHP 的多字节扩展（mbstring），对中文、日文等双字节字符支持更原生，不会因为一个错字就整串报废。但它也有隐性坑：
- 默认不启用
mbstring.func_overload（已废弃），所以strlen()、substr()这类函数依然按字节算，不能指望它自动“接管”所有字符串操作 - 编码检测靠
mb_detect_encoding()，但这个函数不准——它只检查字节模式是否“可能合法”，比如纯 ASCII 字符串会被同时识别为 UTF-8 / GBK / ISO-8859-1，必须手动指定候选集并设$strict = true - 目标编码写错会静默返回原字符串，比如
mb_convert_encoding($str, 'UT8', 'UTF-8')（少个 F），不报错也不转换
推荐写法：mb_convert_encoding($str, 'UTF-8', ['GBK', 'BIG5', 'UTF-8'])，第三个参数是源编码候选列表，比单猜更可靠。
什么时候必须用 iconv，而不是 mb_convert_encoding
两个硬场景绕不开 iconv()：
- 需要转 EUC-JP、ISO-2022-JP 这类小众日文编码，
mb_convert_encoding()不支持（PHP 官方扩展没内置这些表） - 要调用系统级 iconv 库的特性，比如用
//IGNORE+//TRANSLIT组合做最大力度容错，mb_convert_encoding()没有 translit 模式 - 运行环境没开
mbstring扩展（虽然现在少见，但某些嵌入式 PHP 或旧 Docker 镜像仍存在）
注意：iconv() 在 Windows 下默认用系统 locale 编码（比如 CP936），和 Linux 行为不一致，跨平台部署时得显式指定 setlocale(LC_CTYPE, 'en_US.UTF-8') 或改用 mb_* 系列。
性能差异真有那么大吗
单次调用几乎感知不到差别，但高频循环里差距明显：
-
iconv()是 C 实现，轻量，适合简单、确定编码的批量转换（如日志清洗） -
mb_convert_encoding()要查表、做多步校验，尤其开了mb_detect_encoding()就更慢；不过它支持流式处理（mb_convert_variables()批量转数组），iconv()只能单字符串操作 - 实测 10 万次 UTF-8 → GBK 转换，
iconv()比mb_convert_encoding()快约 1.8 倍（PHP 8.2，无检测）
真正卡顿往往不是函数本身，而是你一边 mb_detect_encoding() 猜编码，一边又用 iconv() 强转——重复解析同一段字节，白耗 CPU。
编码转换最麻烦的从来不是选哪个函数，而是搞不清原始数据到底是什么编码。BOM、HTTP header、数据库连接 charset、文件保存时编辑器用的编码……漏查任何一环，函数再稳也救不回乱码。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
