move_uploaded_file()报“permission denied”几乎总是因目标目录对web服务器用户（如www-data）不可写，而非文件权限问题；需用is_writable()验证、ls -ld确认属主与执行位，并避免滥用777。
PHP上传音频文件后必须手动调用chmod()设置权限，move_uploaded_file()本身不支持指定权限参数。
为什么move_uploaded_file()不生效就报“Permission denied”
这个错误几乎总是因为目标目录对Web服务器用户（如www-data、nginx）不可写，而不是文件本身权限问题。系统在移动文件时，会沿用当前进程的umask（比如0022或0077），导致新文件默认是0600或0644，但前提是目录先得允许写入。
-
move_uploaded_file()失败时，$_FILES['audio']['error']通常为UPLOAD_ERR_NO_FILE或UPLOAD_ERR_CANT_WRITE，不是0 - 直接
var_dump(is_writable($target_dir))比猜权限数字更可靠 - Linux下用
ls -ld /path/to/uploads确认目录属主和属组，尤其注意组执行位（drwxrwxr-x中的x）——没有它，Web用户无法进入目录 - 不要用
chmod -R 777 uploads/临时测试后忘记改回来，这等于敞开服务器大门
chmod()必须在move_uploaded_file()成功后立刻调用
临时文件（$_FILES['audio']['tmp_name']）在移动前不能被chmod()，移动后目标路径才是操作对象。八进制权限值必须带前导0，否则会被当成十进制解析（644 ≠ 0644）。
- 正确写法：
chmod('/var/www/uploads/song.mp3', 0644) - 如果Web服务需读取+执行（比如Nginx通过
alias提供音频流），目录权限建议0755，文件0644 - 返回
false？检查：get_current_user()是否与ps aux | grep nginx显示的用户一致；SELinux是否启用（sestatus） - 避免在循环中对每个文件都
chmod()——批量上传时可统一设目录权限，减少系统调用
音频文件权限设置常被忽略的三个细节
音频处理链路长（上传→转码→分发），权限问题容易在中间环节暴露，且表现不一致。
- FFmpeg输出文件默认继承输入文件权限，如果源MP3是
0600，转码后仍是0600，即使你chmod()了原始上传文件也没用 - 使用
file_put_contents()生成封面图或JSON元数据时，同样要跟chmod()，否则前端请求/uploads/song.jpg会403 - Docker环境里，宿主机挂载的
uploads/目录权限由挂载时uid/gid决定，PHP容器内chown无效，得在docker run时用--user指定
真正卡住人的往往不是chmod()那行代码，而是没确认Web用户能否“走进目录”、能否“看到文件”、能否“执行后续命令”。权限不是一次设置就完事，它是整个处理流程里每一步的上下文约束。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
