新文件权限为644是因php默认用0666 mode经umask过滤所致，需显式chmod或用临时文件+rename原子操作设权，并统一管控umask、属主与部署流程。
PHP用file_put_contents()或move_uploaded_file()替换文件后，新文件权限变成644，不是你想要的600或755——这不是PHP“变聪明了”，而是它默认按系统umask生成权限，且不继承原文件权限。必须显式干预。
为什么新文件总是644？
PHP写入或移动文件时，底层调用的是系统open()或rename()，权限由当前进程umask和传入的mode共同决定。即使原文件是600，新文件也不会自动继承；file_put_contents($path, $data)默认不指定$flags或$context，等价于open($path, O_WRONLY | O_CREAT | O_TRUNC, 0666)，再经umask（通常是0022）过滤，结果就是644。
- umask=0022 → 0666 & ~0022 = 0644
- umask=0002 → 0666 & ~0002 = 0664（组可写）
-
move_uploaded_file()完全不接受权限参数，新建文件权限固定由umask决定
用chmod()补救必须在写入后立即执行
不能指望PHP自动设权，得手动加一步。但要注意：如果PHP进程没权限改目标文件（比如父目录属主是root），chmod()会静默失败或报错。
- 对单个文件：写完立刻
chmod($path, 0600)或chmod($path, 0755) - 对上传文件：先
move_uploaded_file()，再chmod($dest, 0644)（PHP脚本文件）或0600（敏感配置） - 避免
chmod()被禁用：检查disable_functions是否含chmod，宝塔里PHP设置→禁用函数列表要确认
更可靠的做法：改umask或用临时文件+原子替换
直接改umask影响整个进程，不推荐；但用临时文件+rename()能绕过部分权限限制，且rename()在同文件系统下是原子操作，更安全。
- 生成临时文件：
$tmp = tempnam(sys_get_temp_dir(), 'upload_'); - 写入或移动到
$tmp，再chmod($tmp, 0600) - 最后
rename($tmp, $final_path)——新文件权限继承$tmp的设置 - 注意：
tempnam()创建的文件默认权限也是受umask影响，所以chmod()那步不能省
部署时统一修复比代码里硬编码更稳妥
开发环境写死chmod(0600)没问题，但上线后若PHP以www-data运行，而文件属主是deploy用户，chmod()可能失败。这时应靠部署脚本统一处理：
- Git钩子或CI/CD流程中，在
composer install后执行：find . -name "*.php" -exec chmod 644 {} \; - 敏感配置文件单独处理：
chmod 600 config/database.php - 上传目录保持
755，确保PHP用户有写权限：chown -R www-data:www-data storage/ && chmod -R 755 storage/
真正麻烦的不是644本身，而是它暴露了权限管理断层——代码里设权、部署时覆盖、运维又手动chown，三者没对齐。盯住属主和umask，比反复chmod更治本。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
