PHP文件操作失败主因是路径解析错误，需确认getcwd()与__DIR__差异、避免单引号变量不展开、校验路径合法性、用file_exists()前置拦截、注意Windows编码及空格问题，并以var_dump($path)验证实际路径。
这个错误不是环境配置问题，而是 PHP 在执行 fopen、include、file_get_contents 等函数时，压根没找到你写的那个路径——它可能拼错了、不存在、权限不够，或者根本就不是你想象中的位置。
路径是相对谁的？先搞清当前工作目录
PHP 不会按你浏览器访问的 URL 路径去找文件，也不按项目根目录找。它默认以「当前执行脚本启动时的工作目录」为基准解析相对路径。这个目录和 __DIR__（当前文件所在目录）经常不一致，尤其在 CLI 模式或被其他脚本 require 时。
- 立刻加一行：
echo getcwd();，看输出是什么路径——这就是相对路径的起点 - 再加一行：
echo __DIR__;，对比两者是否相同；不同就说明你写的./config.php其实是在找getcwd()目录下的config.php，而不是你脚本旁边的 - 线上环境（如 Nginx + php-fpm）下，
getcwd()往往是 web server 的 root（比如/var/www/html），而你的脚本可能在/var/www/html/app/里
单引号字符串里变量不展开，别信字面量
写 $path = 'data/$env/config.json'; 是无效的——单引号完全禁用变量插值，$env 就是纯文本，不会替换成实际值。结果就是 fopen 去找一个叫 data/$env/config.json 的文件，当然报错。
- 改用双引号并显式包裹变量：
$path = "data/{$env}/config.json"; - 更推荐字符串拼接，语义清晰不易出错：
$path = 'data/' . $env . '/config.json'; - 如果
$env来自用户输入或配置，务必先校验合法性（比如只允许字母数字下划线），避免路径遍历（../）或空值导致data//config.json这种非法路径
用 file_exists() 别只是“检查”，要提前拦截
很多人把 file_exists() 当作调试手段，但真正该做的是：在调用 fopen 或 include 前，强制验证路径有效性，否则错误直接抛给用户或触发 500。
立即学习“PHP免费学习笔记（深入）”；
- 不要这样写：
$f = fopen($path, 'r');—— 失败时警告+返回 false，后续若直接fread($f)会报错 - 应该这样写：
if (!file_exists($path) || !is_readable($path)) { throw new RuntimeException("Missing or unreadable config: {$path}"); } - 注意
file_exists()对 symlink 和权限敏感；若目标是符号链接，确保链目标存在且可读；若用 SELinux 或 Docker，还要确认上下文权限（如httpd_can_network_connect）
Windows 下中文路径或空格路径必须转码
PHP 内部路径处理在 Windows 上对编码特别敏感。如果你的路径含中文（比如 C:\站点\配置\app.php），而 PHP 文件本身是 UTF-8 编码，fopen() 会按系统默认 ANSI（通常是 GBK）去解析，导致乱码 → 找不到文件。
- 临时方案：用
iconv('UTF-8', 'GBK', $path)转换后再传入fopen - 长期建议：彻底避免中文路径，用拼音或英文命名；所有路径统一用正斜杠
/，PHP 在 Windows 下完全兼容 - 路径含空格时（如
C:/My Project/data.txt），不加引号不会报错，但某些旧版 PHP 或扩展可能误截断，稳妥起见仍建议用realpath($path)归一化后再操作
最常被忽略的一点：错误提示里的路径，是你代码里写的原始字符串，还是经过变量拼接后的最终结果？别只盯着报错信息抄路径去查——用 var_dump($path); 把实际传给 fopen 的值打出来，才是真实依据。
