Facade注册需在app/provider.php中bind接口与实现，并在Facade类中重写getFacadeClass()返回具体实现类完整命名空间，同时确保类文件路径、命名空间、文件名三者严格一致。
Facade 类怎么注册到容器并绑定接口
ThinkPHP 的 Facade 本质是静态代理，不是直接 new 实例，而是通过 getFacadeClass() 告诉框架“这个门面背后该找谁”。你不能只写一个继承 Facade 的类就完事，必须让容器知道它对应的真实服务类。
常见错误：写了 FileHelperFacade，但没在 app/provider.php 或服务提供者里绑定接口实现，调用时抛出 Target class [app\facade\FileHelperFacade] does not exist 或更隐蔽的 Call to undefined method。
- 在
app/provider.php中追加一行：bind('app\contract\FileHelperInterface', 'app\service\FileHelper') -
FileHelperFacade类中必须重写getFacadeClass()，返回具体实现类完整命名空间，比如return 'app\service\FileHelper'; - 确保
FileHelper类本身已定义，并且构造函数参数能被容器自动解析（避免手动 new 依赖）
FileHelper 服务类该封装哪些核心能力
文件处理不是堆功能，Facadе 封装的价值在于统一入口 + 隔离细节。别把 move_uploaded_file、fopen 等底层操作直接暴露出去，重点收拢业务侧高频、易出错、需一致策略的场景。
典型可用能力：
立即学习“PHP免费学习笔记（深入）”；
-
upload($file, $path = 'uploads/', $rule = 'md5')：封装上传校验（类型、大小）、生成唯一文件名、移动并返回结构化结果（含相对路径、绝对路径、原始名） -
delete($filepath)：兼容本地/云存储路径，自动识别协议前缀（如s3://、public://），避免误删系统文件 -
url($filepath, $expire = 0)：根据环境返回可访问 URL，开发环境走/static/，生产环境走 CDN，临时链接支持签名过期 - 不建议封装
read()/write()这类低级 I/O —— 直接用 PHP 原生函数或thinkFile更清晰
为什么 upload 方法要返回数组而不是 bool 或路径字符串
返回布尔值或纯路径看似简单，但在真实项目里会立刻踩坑：前端需要展示原文件名、后端要记录文件元信息、日志要留痕、失败时得区分是类型不符还是磁盘满。单一返回值撑不住这些需求。
推荐结构化返回（数组）：
[
'success' => true,
'path' => 'uploads/2024/06/a1b2c3.jpg',
'url' => '/uploads/2024/06/a1b2c3.jpg',
'name' => 'avatar.jpg',
'size' => 204800,
'type' => 'image/jpeg'
]
这样调用方可以按需取值：$result['url'] 给前端，$result['path'] 存数据库，!$result['success'] 统一处理错误。如果硬塞进对象，反而增加序列化和调试成本。
Facade 调用报错 Class 'app acadeFileHelperFacade' not found 怎么查
这不是代码写错了，而是自动加载没生效。ThinkPHP 的 Facade 类默认放在 app/facade/ 下，但这个目录不在 composer 的 autoload 自动扫描路径里 —— 它靠框架自己的 Loader 在运行时动态加载。
- 确认类文件路径确实是
app/facade/FileHelperFacade.php，且命名空间为app acade - 检查该文件是否被
composer dump-autoload扫描到（一般不会，因为 facade 目录通常不在autoload.files里）—— 不用管，框架自己处理 - 最常忽略的一点：类名必须和文件名严格一致，包括大小写。Windows 下可能不报错，Linux 服务器直接 500
- 临时加一句
var_dump(class_exists('app\facade\FileHelperFacade'));在控制器里验证，false 就说明文件没被正确加载
路径、命名空间、文件名三者对不上，是这类报错的绝对主因，不用怀疑其他配置。
