核心问题是底层I/O路径和缓存缺失：local驱动不缓存元数据、PHP的fopen()+ext4在>5000文件时触发内核哈希桶冲突、每次Storage::get()都是真实磁盘读，且未绕过PHP处理静态文件。
高并发下 Laravel 文件存储读写变慢，核心问题不在代码，而在底层 I/O 路径和缓存缺失——local 驱动不缓存元数据、PHP 的 fopen() + ext4 目录遍历在 >5000 个文件时触发内核哈希桶冲突、每次 Storage::get() 都是真实磁盘读。
为什么 Storage::get() 和 Storage::size() 越来越慢
当 storage/app/ 下文件数超过 5000，Storage::get('xxx.pdf') 延迟明显上升。这不是 Laravel 的 bug，而是：
• 每次调用都触发一次 stat() 系统调用查元数据，目录项越多，内核哈希桶冲突越严重
• local 驱动默认不缓存内容或元数据，没有“预热”机制
• Nginx/Apache 若未正确配置，会把 /storage/ 请求打到 PHP-FPM，白白消耗进程资源
• Storage::url() 生成的链接若协议（HTTP/HTTPS）与 APP_URL 不一致，浏览器直接拦截，导致前端反复重试加重后端压力
必须手动给元数据加 Cache::remember 包裹
Laravel 自身完全不缓存 filesize()、filemtime() 或 Storage::size()，必须显式封装。否则模板里每调用一次就多一次磁盘 I/O。
• 在 Blade 中避免直接写 {{ Storage::size($path) }}，改用：Cache::remember("file:size:{$path}", 3600, fn() => Storage::size($path))
• 对修改时间、MIME 类型、哈希值等也同理，键建议统一前缀如 file:meta:{$path}
• TTL 设为 3600 是平衡新鲜度与 I/O 压力的常见起点；关键文件（如版本号文件）可设更短，或配合事件监听器主动清除
• 注意：闭包函数不能用于配置文件，但这里是在业务逻辑中，完全安全
让静态文件彻底绕过 PHP
这是最有效、最常被忽略的一环：只要用户请求的是已存在的静态文件（PDF、PNG、MP4），就不该进 PHP。
• 必须执行 php artisan storage:link，确保 public/storage 是指向 storage/app/public 的符号链接
• Nginx 配置中要显式放行 /storage/ 路径，不能只靠 try_files $uri $uri/ /index.php?$query_string —— 它对符号链接后的路径不生效
• Debian/Ubuntu 下确认权限：需 chmod o+x storage/ storage/app/ storage/app/public/，否则 www-data 用户无法穿越目录
• 如果用了 CDN 或反向代理，可在其层面加一层缓存（如 Cloudflare 的 Cache Everything），进一步降低源站压力
大文件上传后立刻返回，处理丢进队列
上传本身不该阻塞 Web 请求。尤其涉及缩略图生成、PDF 解析、视频转码等操作，内存和 CPU 开销极大。
• 控制器中只做基础验证：'image' => 'image|max:2048'，然后立刻 $path = $request->file('image')->store('uploads')
• 立即 dispatch 一个 Job：ProcessUploadedFile::dispatch($path)
• 队列驱动必须用 redis（别用 sync 或 database），并确认 Redis 启用了 notify-keyspace-events，否则延迟队列可能失准
• Job 内部再调用 Storage::get() 时，已脱离用户请求生命周期，不会影响响应时间
真正卡住高并发的，从来不是 Laravel 的某行代码，而是没意识到 stat() 调用在 ext4 上的性能拐点、没切断静态文件的 PHP 路径、也没把元数据读取从“每次都查”变成“查一次缓一小时”。这些点不处理，加多少 Redis 缓存都救不了文件读写。
