pathinfo() 与系统语言环境无关，纯字符串解析，中文后缀如“报告.xlsx”可正常提取扩展名；问题多源于文件名编码错乱、上传截断、终端显示异常等上游环节。
pathinfo() 根本不依赖系统语言环境
它纯字符串解析，跟 locale、LANG、LC_ALL 完全无关。中文后缀（如 报告.xlsx、简历.pdf）能正常提取，pathinfo('报告.xlsx', PATHINFO_EXTENSION) 返回 xlsx，和英文名行为一致。所谓“获取不到”，实际是误判了问题根源——不是函数失效，而是你看到的文件名本身已损坏或编码错乱。
真正导致中文后缀“消失”的常见原因
多数情况下，pathinfo() 返回空字符串或错误值，背后是以下几种可验证的问题：
- 文件名从浏览器上传或表单提交时被截断或 URL 解码失败（如
%E6%8A%A5%E5%91%8A.xlsx没用urldecode()就直接传入） - PHP 文件读取或变量赋值过程中发生 UTF-8 与 GBK 双重编码（例如前端用 GBK 提交，PHP 脚本没声明
mb_internal_encoding('UTF-8')，导致strrpos()类函数在多字节字符上定位偏移错误） - 你在调试时用
var_dump()看输出，但终端/IDE 不支持 UTF-8 显示，把中文名渲染成乱码或空白，误以为后缀丢了 - 路径中混入不可见控制字符（比如从 Excel 复制的文件名带
\u200e或\ufeff），pathinfo()仍会解析，但肉眼无法识别分隔点
如何快速验证是不是 pathinfo 的锅
写一行最简诊断代码，绕过所有业务逻辑：
<?php $test = '测试文档.pdf'; var_dump($test); var_dump(pathinfo($test, PATHINFO_EXTENSION)); ?>
如果输出是：
立即学习“PHP免费学习笔记（深入）”；
string(15) "测试文档.pdf" string(3) "pdf"
说明 pathinfo() 完全正常。此时问题一定出在你拿到的那个变量身上——检查它来源（$_FILES['file']['name']？file_get_contents()？数据库查出来的？），而不是怪函数。
中文文件名场景下必须加的防护措施
即便 pathinfo() 本身可靠，中文环境仍需主动防御几类现实问题：
- 上传时用
mb_convert_encoding($_FILES['file']['name'], 'UTF-8', 'auto')统一源编码，避免 GBK/Big5 混入 - 不要直接信任
$_FILES['file']['name']—— 它可能被客户端篡改，且浏览器对中文名处理不一致；更稳妥的是用pathinfo(basename($_FILES['file']['name']), PATHINFO_EXTENSION)先剥离路径再取后缀 - 若需兼容旧系统（如 Windows + GBK 本地开发），在调用
pathinfo()前先做iconv('GBK', 'UTF-8//IGNORE', $filename)，否则遇到「测试.docx」可能返回空，因为 GBK 编码下点号位置计算错误 - 永远用
is_string($ext) && $ext !== ''判断后缀是否存在，别只靠empty($ext)——pathinfo('.gitignore', PATHINFO_EXTENSION)返回空字符串，但这是合法的无扩展名情况
最易被忽略的一点：pathinfo() 对中文安全，但整个文件处理链路里，只有它是“干净”的。从用户输入到最终存储，中间每一步都可能悄悄破坏编码完整性——盯住源头，比反复调试 pathinfo() 有效得多。
