Filesystem::chmod() 仅对当前已存在且可访问的文件/目录生效，但要求 PHP 进程用户拥有所有权或所属组写权限，否则抛出 IOException；它不绕过 umask、不递归修改，且易因 root 创建文件、SELinux、挂载限制等导致静默失败。
在 Symfony 7.1 中用 Filesystem 组件调用 chmod() 修改已有文件权限，很容易失效或静默失败——这不是你代码写错了，而是它压根不负责“修复旧文件”，只影响新创建内容。
Filesystem::chmod() 的真实作用范围
这个方法仅对 当前已存在且可访问的文件/目录 生效，但有硬性前提：
- PHP 进程用户（如
www-data）必须对该文件拥有 所有权或所属组写权限，否则chmod()调用会直接抛出IOException - 它不会绕过系统
umask；如果当前 umask 是0077，即使传入0644，最终也可能变成0600 - 不递归：传入一个目录路径，它只改该目录本身的权限，不会处理其下子文件或子目录
为什么 chmod() 看似执行了却没变化？
常见原因不是代码问题，而是环境约束未满足：
Yuanfang Design System
下载
yuanfang-skills 的共享设计系统，提供 token CSS 变量、12+ 主题以及可复用的布局类型 HTML 块，供 yuanfang-html-image（以及 fu...）使用。
- 目标文件由
root或其他用户创建（比如用sudo composer install），当前 PHP 用户无权修改其权限 - SELinux 或 Docker 容器中启用了强制访问控制，
chmod系统调用被拦截（可用ausearch -m avc -ts recent查日志） - 文件系统挂载时用了
noexec、nosuid或mode=参数，限制了权限变更能力 - 调用前没做
is_writable($path)检查，导致异常被忽略或吞掉
更可靠的做法：别依赖 Filesystem::chmod()
对已有文件批量修权，应脱离 PHP 运行时，用系统命令或封装为可控命令：
- 终端手动修复：
find var/cache -type f -exec chmod 644 {} \;和find var/cache -type d -exec chmod 755 {} \; - 写成 Symfony 命令，用
Symfony\Component\Filesystem\Filesystem配合Process组件执行chmod，避免 PHP 权限上下文干扰 - 部署脚本中统一处理：在
composer install后立即运行权限修复，而不是等运行时才发现 - 开发阶段启用 ACL（如 macOS 的
chmod +a或 Linux 的setfacl），让多个用户共享写权，减少 chmod 需求
顺带提醒：别和 Flysystem 权限配置混用
Flysystem 的 filePermission 和 dirPermission 只影响它自己创建的文件（如 $filesystem->write()），和 Filesystem::chmod() 完全无关。两者同时配置不会叠加，也不会冲突，但目标不同——一个管“出生”，一个管“成长”。
