thinkphp导入excel中文乱码本质是读取阶段字节流解析错误，需从文件读取入口干预：用getrealpath()获取真实路径，强制xls reader解析.xls，禁用输出缓冲，避免手动转格式，并通过mb_detect_encoding验证编码层级。
ThinkPHP导入Excel时中文显示为方块、问号或乱码字符，说明数据在读取阶段已发生编码错位，不是前端渲染问题而是原始字节流解析错误。必须从文件读取入口开始干预编码识别逻辑，否则后续所有处理都建立在错误字节基础上。
确认Excel文件真实编码
不要依赖文件扩展名或右键属性，直接用十六进制编辑器（如HxD）打开Excel文件头部：若开头是D0 CF 11 E0 A1 B1 1A E1，这是.xls的OLE复合文档结构，不带BOM；若开头是50 4B 03 04，这是.xlsx的ZIP格式，内部XML默认UTF-8但可能无BOM。这两种格式都不在文件头声明编码，PhpSpreadsheet必须靠内容推断。
用Excel另存为“CSV（UTF-8）”再重命名为.xlsx，这种操作会破坏原始结构，导致PhpSpreadsheet无法解析——【切勿手动转换文件格式】。
PhpSpreadsheet读取时强制指定编码
PhpSpreadsheet本身不提供setCharset方法，所谓“$reader->setCharset('UTF-8')”是旧版PHPExcel遗留写法，在PhpSpreadsheet中无效。正确做法是控制输入流解码时机：
方法一：用IOFactory加载后立即调用getReader()->setReadDataOnly(true)，跳过样式和公式解析，减少编码干扰源。
方法二：对.xls文件，必须用Xls Reader而非默认自动识别——【自动识别常把.xls误判为CsvReader，导致UTF-8字节被当GBK解析】。
方法三：读取后对单元格值做二次转码，仅适用于明确知道源文件是GBK的情况：$value = mb_convert_encoding($value, 'UTF-8', 'GBK');，但此操作不能修复合并单元格或公式字段的乱码。
ThinkPHP上传路径中的编码陷阱
第一步：获取上传文件临时路径时必须用$file->getRealPath()，不能用$file->getPathname()——后者返回的是包含PHP临时目录的绝对路径，路径中若含中文（如C:\用户\张三\...），Windows系统会将路径名转为GBK再传给PhpSpreadsheet，导致文件打开失败或静默乱码。
第二步：用IOFactory::load()加载时，传入的必须是真实磁盘路径字符串，不是$_FILES超全局数组里的原始name字段。
第三步：禁止在load()前后执行任何echo/print_r/var_dump，输出缓冲区残留的空格或BOM会污染二进制流，使PhpSpreadsheet解析器崩溃并返回空数组。
验证是否真正解决乱码
① 打开PhpSpreadsheet源码vendor/phpoffice/phpspreadsheet/src/Reader/Xlsx.php，搜索SimpleXMLElement实例化位置，在其前插入libxml_disable_entity_loader(false);——否则XML解析器会拒绝加载含中文标签名的自定义XML。
② 导入后立刻用var_dump(mb_detect_encoding($cellValue))检查单个单元格，若返回false或ASCII，说明乱码发生在读取层；若返回UTF-8但浏览器显示乱码，则问题在输出环节。
③ 对比原始Excel文件用Excel软件打开时的显示效果，如果Excel软件里也乱码，说明文件本身损坏或保存时未选“保留兼容性”，需让用户提供原始未另存版本。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
