file_exists传入相对路径时按getcwd()查找而非__dir__，易因工作目录不符导致误判；需改用绝对路径并检查open_basedir限制、权限及符号链接有效性。
file_exists 传入相对路径时找不到文件
PHP 的 file_exists 不会自动补全当前工作目录（getcwd()）或脚本所在目录（__DIR__），它只按你传入的路径字面量去查。比如你在 /var/www/html/app/index.php 中写 file_exists("config.json")，PHP 就真的去查 getcwd() 目录下的 config.json——而这个工作目录很可能是 Web 服务器启动时的路径（如 / 或 /var/www），不是你的脚本目录。
常见错误现象：file_exists("config.json") 返回 false，但文件明明就在同级目录；用 ls config.json 在终端能列出，PHP 却读不到。
- 用绝对路径最稳妥：把
"config.json"改成__DIR__ . "/config.json" - 别依赖
chdir()或 Apache 的DocumentRoot来“修正”路径，行为不可控 - 调试时加一行
var_dump(__DIR__, getcwd(), "config.json");，立刻看清三者关系
权限或 open_basedir 限制导致 file_exists 失败
file_exists 在遇到权限不足或被 open_basedir 拦截时，**不报错也不抛异常，直接返回 false**。这是最容易误判为“文件不存在”的地方。
使用场景：本地开发正常，上线后突然失效；或者文件在 /tmp、/var/log 等系统路径下查不到。
- 检查 PHP 错误日志，搜索
open_basedir restriction或Permission denied - 运行
echo ini_get('open_basedir');看是否限制了目标路径 - 用
is_readable()和is_writable()分别测试权限，比单靠file_exists更可靠
符号链接未启用 follow_symlinks
当目标是符号链接，且链接指向的源文件本身不存在或不可访问时，file_exists 默认会跟随链接（follow），然后判断目标是否存在。但如果 PHP 配置了 symlinks 被禁用（极少见），或链接本身损坏（dangling symlink），就可能返回 false。
性能影响：启用 follow 是默认行为，开销极小；禁用它需改内核参数或编译选项，普通用户几乎不会碰到。
- 先用
readlink -f path/to/file在终端验证链接是否有效 - 用
stat命令确认链接目标路径和权限 - 不必在代码里绕过 symlink——修复链接或权限才是正解
Windows 下大小写与反斜杠陷阱
Windows 文件系统默认不区分大小写，但 PHP 的 file_exists 在某些 SAPI（如 CLI）或启用了严格模式的扩展下，仍可能因大小写不一致返回 false。更常见的是路径分隔符混用：用 "C:path o ile.txt" 没问题，但若字符串里有未转义的
或 （比如拼接时没注意），就会变成非法路径。
错误信息示例：file_exists("C:
ewconfig.json") 实际查的是 C:ewconfig.json（因为
被解释为换行）。
- 统一用正斜杠：
"C:/new/config.json"，PHP 全平台兼容 - 字符串拼接时用
dirname(__FILE__) . DIRECTORY_SEPARATOR . "config.json" - 避免硬编码反斜杠；用
str_replace('\', '/', $path)临时清理也行
真正难排查的，往往是路径拼接时漏了 __DIR__，或者线上环境的 open_basedir 比本地严得多——这两点不打印出来看，光靠 file_exists 的返回值根本没法定位。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
