PHP在Windows下fopen中文路径失败的根本原因是UTF-8路径字节被GBK接口错误解析，必须在调用前用iconv("UTF-8", "GBK//IGNORE", $path)显式转码并校验UTF-8编码，否则字节错位导致文件找不到。
PHP 文件在 Windows 下因大小写报错，根本不是 Windows “不区分大小写”导致的，而是你代码里调用了 fopen()、file_get_contents() 这类底层函数，而它们在 Windows 上默认用 GBK 解释 UTF-8 编码的路径字符串——字节错位，直接报 failed to open stream: No such file or directory。
为什么 Windows 下 fopen('./测试.txt') 会失败
你写的 PHP 字符串 './测试.txt' 是 UTF-8 编码的字节序列，但 Windows 版 PHP 默认调用的是 Win32 ANSI API（即 GBK 接口），不会自动把 UTF-8 路径转成系统本地编码。结果就是：PHP 把 测试 的 UTF-8 字节当 GBK 解，解出来是乱码路径，fopen() 自然找不到文件。
-
mb_internal_encoding()和default_charset对路径无效，改了也没用 -
$_FILES['file']['name']来的中文名本身就是 UTF-8 字节，不要urldecode()或二次iconv() - VS Code 保存为 UTF-8（无 BOM）≠ PHP 运行时路径自动转码，这是两个层面的事
Windows 下安全打开中文路径文件的唯一做法
必须在调用 fopen() 前，把 UTF-8 路径显式转成 GBK（或当前系统区域设置对应编码），且带容错：
在 Windows 11 上"直接发声"的 TTS（从 WSL2/TUI 调用 powershell.exe + System.Speech）。适用于用户说"说出来/读出来/语音播报/用TTS"，或反馈"没声音/tts 生成的 mp3 是空的/播不出来"，以及需要中文语音但 OpenClaw 内置 tts 不可用时。
- 用
iconv("UTF-8", "GBK//IGNORE", $path)——//IGNORE能跳过无法映射字符，避免整个路径崩掉 - 别用
mb_convert_encoding($path, "GBK", "UTF-8")，它在部分 PHP 版本中对路径处理不稳定 - 转换前先确认：
if (mb_check_encoding($path, 'UTF-8')) { ... } - 示例：
$utf8_path = './测试.txt';<br>if (mb_check_encoding($utf8_path, 'UTF-8')) {<br> $gbk_path = iconv('UTF-8', 'GBK//IGNORE', $utf8_path);<br> $fp = fopen($gbk_path, 'r');<br>}
phpEnv 环境下必须手动开的两个开关
phpEnv 自带的 PHP 不开 iconv 扩展、不调错误级别，你写了转换逻辑也白搭：
立即学习“PHP免费学习笔记（深入）”；
- 打开
phpEnv安装目录下的php/{version}/php.ini - 取消注释：
extension=iconv - 加一行：
error_reporting = E_ALL & ~E_NOTICE，否则iconv()遇到不可映射字符会抛警告中断流程 - 别碰
open_basedir，除非你真需要限制目录范围；它和中文路径问题无关
真正容易被忽略的点是：这个转换动作必须发生在每个 fopen()、file_get_contents()、scandir() 调用之前——没有全局钩子，没法一劳永逸。哪怕你封装了一个 safe_file_get_contents() 函数，只要漏掉一处，就可能卡在生产环境某个上传回调里。
