结论：is_file() 本身不干扰子目录，但配合 readdir() 或 scandir() 遍历时若未拼接完整路径、未过滤 . 和 ..、未校验权限或缓存，会导致误判；正确做法是用 realpath() 构建绝对路径后调用 is_file()，并辅以 file_exists() 预检和 clearstatcache() 防缓存滞后。
直接说结论：is_file() 本身不干扰子目录，但如果你用它配合 scandir() 或 readdir() 遍历目录时没做类型过滤，就会把子目录当成“可处理文件”误判——问题不在函数，而在调用逻辑。
为什么 is_file() 在遍历中总返回 false 或误判子目录
常见错误是：先用 scandir($dir) 拿到所有条目（含 .、.. 和子目录名），然后对每个名字直接拼路径再调用 is_file()，却忘了验证拼出来的路径是否真实存在、是否可访问。
-
scandir()返回的是文件名列表，不是完整路径；直接is_file('subdir')判断的是当前脚本所在目录下的subdir，不是你目标目录里的 - 没跳过
.和..，导致is_file('.')或is_file('..')返回false（它们是目录，不是文件） - 父目录权限不足（比如无执行权
+x），is_file()会静默失败并返回false，不是因为文件不存在，而是 PHP 根本读不到目录内容
正确组合 is_file() + realpath() 防止路径歧义
必须把相对名转成绝对路径再判断，否则跨目录操作必出错。尤其在 include 路径或 Web 路由中，__DIR__ 是最稳的锚点。
- 用
realpath($dir . '/' . $entry)构建完整路径，再传给is_file()—— 这能避免软链接、相对路径、符号路径带来的歧义 - 加一层
file_exists()预检：如果file_exists($fullPath) === false，is_file()就没必要调了，省一次系统调用 - Windows 下注意反斜杠，统一用
str_replace('\', '/', $path)或直接用dirname(__FILE__) . DIRECTORY_SEPARATOR . $entry
遍历目录时怎么安全跳过子目录只处理文件
核心不是“排除子目录”，而是“只留下文件”。别靠名字猜，要用函数实锤。
立即学习“PHP免费学习笔记（深入）”；
- 先用
is_dir($fullPath)排掉所有目录（包括.、..和子目录），剩下再进is_file()流程 - 不要写
if (!is_dir($path)) { ... }就认为一定是文件——万一是个符号链接、socket 或设备节点呢？is_file()才是唯一权威判断 - 批量处理时记得调
clearstatcache(true, $fullPath)，尤其在循环里反复检查同一路径，PHP 的 stat 缓存会导致结果滞后
is_file() 在 FileRun 类项目中的典型误用场景
FileRun 默认把用户文件存在 /var/www/html/filerun/files/，但它的权限模型依赖精确的文件/目录区分。这里最容易栽跟头：
- 上传后校验用
is_file($uploaded_path)，但没确认$uploaded_path是否在files/目录内——攻击者可能构造../../etc/passwd绕过，is_file()会如实返回true，造成路径泄露 - 生成缩略图前调
is_file()，但源文件刚被另一个进程 rename 或 unlink，缓存未清，is_file()还返回true，后续file_get_contents()就报failed to open stream - 日志审计里记录
is_file($path) ? 'file' : 'not file'，但没补上is_dir($path)分支——结果所有子目录都记成 “not file”，无法还原操作上下文
真正麻烦的从来不是函数本身，而是你没把它放在完整路径验证和权限检查的链条里。漏掉任何一环，is_file() 就从精准工具变成误导源头。
