Filesystem组件在Symfony 6.4中方法兼容但使用场景受限：不再适用于对象存储、缓存目录清理或权限干预，mkdir()校验更严格，上传处理需配合UploadedFile生命周期，推荐用Flysystem替代抽象文件操作。
Symfony 5.4 升级到 6.4 后，Filesystem 组件本身没有发生方法级废弃或签名变更——它仍提供 mkdir()、copy()、remove()、exists() 等常用方法，调用方式完全兼容。真正需要注意的，是使用上下文、默认行为和配套实践的变化，尤其在与 Flysystem、缓存、权限模型联动时容易出问题。
Filesystem 类仍在，但推荐场景已转移
Symfony 的 Symfony\Component\Filesystem\Filesystem 是一个轻量工具类，用于本地文件系统操作（如创建目录、复制临时文件、清理缓存）。它在 6.4 中未被弃用，但官方文档更强调：
- 它不适用于对象存储（S3/OSS）或抽象文件操作——这类任务应交由 Flysystem（v2+）处理；
- 它不参与 Symfony 缓存生命周期管理——
var/cache/目录的清理由cache:clear命令统一控制，不应再手动Filesystem::remove(var/cache)； - 它不再自动处理 SELinux 或容器挂载限制——比如 Docker 中
var/cache目录若以只读方式挂载，mkdir()会直接抛IOException，而 5.4 时代部分环境可能静默忽略。
mkdir() 行为更严格，失败反馈更明确
虽然 mkdir($path) 依然支持递归创建，但 6.4 对路径合法性校验增强：
Kadence Theme Design System
下载
使用 Kadence 主题作为 WordPress 项目的设计系统，涵盖设计令牌、布局系统、页头/页脚/导航设置以及页面/归档/单篇文章模板。
- 若
$path是空字符串、null或仅含空白符，会立即抛InvalidArgumentException（5.4 可能静默跳过）； - 若路径中包含
..且超出根目录范围（如/var/www/../etc/passwd），会触发LogicException，防止路径遍历； - 不再容忍末尾斜杠冗余写法：
/tmp/uploads/和/tmp/uploads被视为不同路径，但后者才是mkdir()接受的标准格式（前者可能因 rtrim 失败导致创建失败）。
上传与临时文件处理需配合新约定
升级后表单上传流程更依赖 UploadedFile 的生命周期管理：
-
move()方法仍可用，但推荐改用getFile()->move($targetDir, $name)配合Filesystem::mkdir()提前建好目标目录； - 不再建议手动
touch()或chmod()上传后的文件——权限应由umask或filesystem配置统一控制； - 若启用
upload_max_filesize或post_max_size限制，错误提示现在统一由FormError抛出，而非底层Filesystem异常。
替代方案更清晰：什么情况不该再用 Filesystem
| 场景 | 5.4 常见做法 | 6.4 推荐做法 |
|---|---|---|
| 上传头像并重命名 | Filesystem::copy($_FILES['file']['tmp_name'], $dst) |
注入 FilesystemOperator，用 writeStream($path, fopen(...))
|
| 清理用户上传的旧文件 | Filesystem::remove($oldPath) |
使用 Flysystem 的 delete() + fileExists() 显式判断 |
| 生成带时间戳的缓存目录 | Filesystem::mkdir(sprintf('/tmp/cache/%s', date('Y-m-d'))) |
改用 CacheItemPoolInterface + 自定义前缀，避免磁盘污染 |
基本上就这些。核心不是“方法没了”，而是“该不该用它来干这件事”变得更明确了。
