首要原因是父目录缺少执行（x）权限，Linux中“进入目录”即执行操作，file_exists逐级stat路径各段，任一父目录无x权限即返回false；此外符号链接失效、SELinux/AppArmor限制及realpath缓存未更新也会导致误判。
file_exists 返回 false 的首要原因：父目录缺执行权限
不是文件没权限，是路径上任意一级父目录缺少 x（执行）权限。Linux 下“进入目录”本质就是执行该目录，file_exists 会逐级 stat 路径各段，任一父目录无 x 权限就直接失败——哪怕目标文件本身 rw- 全开。
- 用
ls -ld /var/www/html/config/检查每一级目录权限，确认都有x（如drwxr-xr-x） - 常见误配：
chmod 644 /var/www→ 目录变-rw-r--r--，file_exists必然返回false - Web 服务用户（如
www-data）必须对完整路径中每个目录都具备x权限，仅文件可读没用
如何快速验证是不是权限问题
别猜，直接切到 PHP 进程用户身份测试。假设 Web 服务跑在 www-data 下：
- 命令行执行：
sudo -u www-data ls -l /path/to/your/file.txt—— 如果报Permission denied，基本锁定是父目录x权限缺失 - 同理测试父目录：
sudo -u www-data ls -d /path/to，看是否能列出目录本身 - 注意：CLI 模式下当前工作目录可能不同，务必用绝对路径复现 Web 环境行为
符号链接、SELinux 和 realpath 缓存也会干扰结果
即使权限全对，这三类情况仍会导致 file_exists 返回 false：
- 符号链接指向失效目标：
file_exists检查的是链接最终解析后的路径，不是链接文件自身；用is_link($p) && file_exists($p)不能说明链接有效 - SELinux 或 AppArmor 限制：检查
ausearch -m avc -ts recent是否有拒绝日志，临时用setenforce 0测试是否缓解（勿在线上长期关闭） - realpath 缓存未更新：文件被外部程序快速创建/删除后，
file_exists可能返回过期结果；调试时加clearstatcache(true, $path)强制刷新，但别在循环里调用
替代方案：当 file_exists 不可靠时怎么补救
不推荐硬刚，优先修复权限；若受限于环境（如只读挂载、NFS 延迟），可用更底层但更费资源的方式交叉验证：
立即学习“PHP免费学习笔记（深入）”；
- 用
@stat($path)：比file_exists多返回元数据，且抑制警告；返回非false即存在（注意@是抑制错误，不是解决根本问题） - 对已知可读父目录，用
scandir(dirname($path))获取列表再in_array(basename($path), ...)—— 绕过子目录x权限依赖，但慢且要求父目录可读 - 绝对不要用
shell_exec('ls ' . escapeshellarg($path))：跨平台差、易注入、不可靠，还绕不开权限限制
真正容易被忽略的点是：file_exists 的行为完全取决于操作系统层面的 stat 调用结果，它不关心你“想不想读”，只回答“能不能触达”。路径写错、open_basedir 限制、容器挂载时机异常，都会让它沉默地返回 false——而这些，全得靠权限、路径、上下文三者交叉排查。
