symfony 7.2 文件存储应分四层：控制器仅协调与基础校验，业务服务封装意图与规则，存储适配器实现落盘并屏蔽差异，抽象与配置通过di分离；各层职责清晰，便于测试与扩展。
Symfony 7.2 文件存储业务应按职责清晰分层：**上传入口 → 业务处理 → 存储适配 → 文件系统抽象**。不建议在 Controller 中直接调用 move() 或写入磁盘，也不推荐把路径拼接、格式校验、权限检查等逻辑混在一起。
1. 控制器层（Controller）只做轻量协调
接收 UploadedFile 对象，验证基础参数（如非空、大小限制），然后委托给专用服务处理。避免任何文件 I/O 操作或路径构造。
- 使用 Request::files 获取上传对象，不依赖 $_FILES
- 若需预校验（如 MIME 类型白名单），调用独立的 FileValidator 服务，而非硬编码 in_array()
- 上传成功后，只返回结构化响应（如文件 ID、URL、元数据），不返回物理路径
2. 业务服务层（Service）封装核心逻辑
这是真正处理“业务意图”的地方，例如：“保存用户头像”、“归档日志包”、“生成并存储报告”。它不关心文件存在哪，只定义规则和流程。
- 接收 UploadedFile 或临时路径，执行业务级检查（如用户配额、文件名规范、内容哈希去重）
- 调用 StorageManager 接口保存，而非直接 new LocalFilesystemStorage()
- 触发领域事件（如 UserAvatarUpdatedEvent），供监听器后续处理缩略图、清理旧版本等
3. 存储适配层（Storage Adapter）实现具体落盘
实现统一接口（如 FileStorageInterface），屏蔽底层差异。Symfony 7.2 推荐基于 Symfony\Component\Filesystem\Filesystem 构建本地适配器，并预留 S3、FTP、WebDAV 等扩展点。
- 本地适配器：用 Filesystem::dumpFile() 写入，Filesystem::remove() 删除，自动容错
- 路径生成由适配器内部完成（如
user/{id}/avatar/{hash}.{ext}），不暴露给上层 - 所有 I/O 异常统一转为自定义异常（如 StorageUnavailableException），便于上层捕获与降级
4. 抽象与配置分离
通过依赖注入和配置驱动行为，避免硬编码。例如：
- 在
services.yaml中定义App\Storage\LocalFileStorage为App\Storage\FileStorageInterface的默认实现 - 用
%env(resolve:FILE_STORAGE_TYPE)%切换适配器（local/s3/minio），无需改代码 - 上传目录路径通过参数
kernel.project_dir+app.files.upload_dir组合，支持环境变量覆盖
这种分层让单元测试更干净：Controller 测试只 mock 服务；Service 测试可注入 vfsStream 适配器；Storage 层本身可独立跑集成测试。不是为了分层而分层，而是让每层只回答一个问题：“谁该为这件事负责？”
