thinkphp5文件上传应通过自定义filesystem驱动扩展，而非硬塞第三方类；需在config/filesystem.php配置磁盘并实现filesysteminterface，控制器中用storage::disk()->putfile()替代$file->move()，同时封装uploadservice统一处理验证、存储与后处理。
request()->file() 返回的是 \think\File 实例，它本身不支持直接“扩展函数”，但 ThinkPHP5 提供了清晰的介入点：通过自定义驱动、封装上传逻辑、或替换/增强 move() 行为。关键不是改函数签名，而是控制文件落地前后的处理链。
如何替换默认上传驱动（Local → 自定义）
move() 底层依赖 think\File 的 save() 方法，而该方法会调用当前磁盘配置对应的写入驱动。要真正“扩展上传能力”，比如加水印、转码、异步上传到 OSS，必须走 filesystem 扩展路径，而不是硬塞第三方 Upload 类。
-
config/filesystem.php中新增一个磁盘配置，例如'oss'或'custom'，type设为自定义类名（如'app\driver\CustomUploadDriver'） - 该类需实现
League\Flysystem\FilesystemInterface，或继承think\filesystem\Driver并重写write()、writeStream()等方法 - 控制器中不再调用
$file->move()，而是用Storage::disk('custom')->putFile('uploads/', $file) - 注意：自定义驱动里拿到的
$file是原始$_FILES数组项，不是\think\File对象；如需复用验证逻辑，得手动调用$file->validate()再传入
为什么不要直接 import 第三方 Upload 类
像Loader::import('org.Upload.php') 这种方式在 TP5.0 后期已属历史遗留，存在几个硬伤：
- 与
filesystem机制完全脱节，无法享受统一的磁盘切换、URL 生成、缓存策略 -
Upload类的saveName、subName等参数和 TP5 的getSaveName()返回格式不一致，容易导致路径拼接错误 - 不支持多应用模式下的
runtime/应用名/storage隔离路径 -
exts参数只校验后缀，不校验 MIME 类型，存在安全风险（如上传shell.jpg.php） - 错误信息返回结构混乱，和 TP5 的
$file->getError()不兼容
怎样安全地封装自己的 upload() 工具方法
与其“扩展函数”，不如在app\common\service\UploadService.php 里封装一个静态方法，把验证、存储、后处理串起来：
- 接收
\think\File实例或$_FILES数组项 - 先调用
$file->validate(['size' => 2097152, 'ext' => 'jpg,png,gif']) - 再根据业务规则生成唯一子目录，例如
date('Ym') . '/' . substr(md5($file->getInfo('tmp_name')), 0, 2) - 调用
$file->move(ROOT_PATH . 'public/uploads/', $saveName, true)（第三个参数true表示覆盖） - 成功后可选触发水印、压缩、记录数据库等操作
- 返回统一结构：
['code' => 0, 'path' => '/uploads/202608/abc123.jpg', 'url' => '@#@#@#@#@#@#@#@#@#@0']
TP5 的上传扩展难点不在语法，而在驱动抽象层和业务逻辑的耦合点——多数人卡在没意识到 move() 只是快捷封装，真正可控的入口是 filesystem 磁盘和自定义 Driver。
