PHP filesize() 踩坑指南：从字节计算到实战避坑

做文件上传或下载模块时，很多人习惯随手甩一句 $size = filesize($file)。代码跑起来没问题，一上线却频频报出“无法获取大小”或者前端显示乱码的容量。其实 filesize 本身不复杂，但它背后的系统调用机制和 PHP 版本迭代，藏着不少容易被忽略的细节。摸清这些，能避开大半低级错误。

最常见的误解是把函数返回的 false 直接等同于文件不存在。实际上，当脚本运行账户对目标路径没有读取权限，或者遇到损坏的硬链接时，它同样会返回布尔假值。排查时应先执行 is_readable() 做前置拦截，配合清晰的异常提示，能快速区分是权限配置缺失还是路径拼写错误。对于真正内容为空的零字节文件，它会稳稳返回整数 0。判断逻辑里务必把“不存在/不可读”与“值为 0”拆开处理，否则很容易误删合法的空文件。

远程资源的校验规则在 PHP 8.0 之后发生了硬性变更。过去依赖 http:// 流包装器直接解析头信息的旧写法已被移除。若继续沿用 filesize('https://cdn.example.com/image.jpg')，不仅拿不到准确数值，还会触发安全策略拦截。应对线上校验，直接改用 cURL 发起 HEAD 请求。仅抓取响应头里的 Content-Length 字段，既避开完整下载带来的带宽浪费，又能锁定原始字节数。接收到的字符串记得强制转整型，杜绝浮点数比较时的隐形偏差。

本地大文件场景下，性能通常不构成瓶颈。因为 filesize 底层走的是操作系统的 stat 系统调用，直接读取文件元数据，响应几乎是毫秒级的。只有当文件体积逼近或超过 9PB 时，PHP 默认的浮点表示法才会暴露精度丢失风险。常规业务保持原生返回值即可，若涉及资产盘点或极限存储统计，建议将结果交由 bcpow() 扩展或纯字符串算法比对，守住最后一道底线。

拿到原始字节后，如何优雅地转换成人眼可读的单位？很多遗留代码直接用固定除法四舍五入，结果经常卡在 1024 B 被吞成 0 KB 的尴尬位置。下面这套转换逻辑补足了边界判定，开箱即用：

function formatBytes($bytes, $precision = 2) {
    $units = ['B', 'KB', 'MB', 'GB', 'TB'];
    if ($bytes === 0) return '0 B';

    $size   = log(abs($bytes), 1024);
    $index  = min((int) floor($size), count($units) - 1);
    $result = round(abs($bytes) / pow(1024, $index), $precision);

    return sprintf('%s %s', number_format($result, $precision, '.', ''), $units[$index]);
}

这段实现的核心在于动态匹配数量级层级，配合 floor 向下取整切断无效换算。遇到几十兆的备份包，它能稳定吐出 45.20 MB；碰到几十字节的配置片段，则原样保留 12 B，彻底告别“未定义指数”的报错干扰。配合 number_format 的千分位控制，前端表格对齐也会清爽许多。

开发中遇到文件尺寸校验，不妨多留半秒审视上下文环境。明确当前运行时的 PHP 版本对网络协议的支持范围，确认 Web 进程用户对目标目录的访问阶梯，再把格式化脚本沉淀为公共方法。把这些细节固化为基础规范，后续排查成本会大幅收敛。工具函数的价值不在于调用次数多少，而在于你是否清楚它在各种极端输入下的真实反馈。