宝塔修复工具仅修改网站目录下文件和目录的权限：PHP等文件设为644、目录设为755，runtime等可写目录设为755；不处理数据库、日志、配置文件及PHP/MySQL配置，也不识别框架差异，故Laravel等需775的目录会被误设为755导致写入失败。
宝塔修复工具到底修了哪些权限
它只改 www 用户对网站目录的读写权限，不碰数据库、日志、配置文件等其他路径。核心逻辑是：递归把网站根目录下所有 .php、.html、.js 等静态/脚本文件设为 644，目录设为 755，然后把 runtime、uploads、cache 这类可写目录单独设为 755（注意：不是 775，这点常被误以为“没修好”）。
常见错误现象：file_put_contents(): failed to open stream: Permission denied 修完还在报，大概率是程序自己创建的子目录（比如 runtime/logs/2024/06/）没被递归覆盖到——宝塔修复工具默认不深入三级以上子路径。
- 使用场景：适合刚部署完 WordPress、ThinkPHP、Laravel 等框架，或迁移后首页能打开但后台上传/缓存失败
- 它不会动
/www/server/php/下的配置，也不会重置 MySQL 用户权限 - 如果网站用到了
opcache或apcu，权限修复后需手动重启 PHP 进程，否则旧缓存可能仍引用错误路径
什么时候不该点“一键修复”
点了反而让网站直接 500。典型情况是 Laravel 的 storage 和 bootstrap/cache 目录必须由 Web 服务器用户（www）拥有且可写，但宝塔修复工具会把它们也设成 755，而 Laravel 要求它们是 775 或 777（取决于 umask）。此时修复 = 锁死写入。
- 使用场景：Laravel、Symfony、Django（通过 WSGI）等需要运行时生成文件的框架
- 参数差异：
chmod -R 755 storage不行，得用chmod -R 775 storage；chown -R www:www storage必须显式执行 - 性能影响：如果误把
public下的.htaccess权限改成644（正确），但 Apache 配置里关闭了AllowOverride，那 rewrite 规则就失效了——问题看似权限，实为配置
修复后还要手动检查的三个位置
宝塔工具修的是“面”，但关键问题常在“点”。这三个地方不检查，90% 的权限问题还会复发：
-
/www/wwwroot/你的域名/.user.ini：里面可能锁死了open_basedir，导致 PHP 认为某个路径“不可访问”，和文件权限无关但表现一样 -
/www/server/php/版本/etc/php-fpm.d/www.conf中的user和group是否真为www（有些用户手动改过，修复工具不读这个） -
wp-content/plugins/某插件/下的vendor/目录：Composer 安装的包常带755目录但600文件，PHP 执行时读不到 autoload.php
Linux 命令补救比宝塔按钮更可控
当修复工具失效或不确定它干了什么，用终端两行命令反而更快、更透明：
chown -R www:www /www/wwwroot/你的域名/
find /www/wwwroot/你的域名/ -type f -exec chmod 644 {} \;
find /www/wwwroot/你的域名/ -type d -exec chmod 755 {} \;
但注意：这两行会把所有文件都设成 644，包括你可能需要可执行权限的 shell 脚本（比如部署钩子），所以实际用时得加排除：
- 排除
deploy.sh：find ... -name "deploy.sh" -prune -o -type f -exec chmod 644 {} \; - 排除整个
vendor：find ... -path "./vendor" -prune -o -type d -exec chmod 755 {} \; - 修复后立刻验证：
sudo -u www php -r "file_put_contents('test.txt', 'ok'); echo file_get_contents('test.txt');"，避免空跑
复杂点在于：不同框架对同一目录的权限预期不同，Laravel 要 775，WordPress 插件更新却接受 755；而宝塔修复工具只按一套规则走，没法自动识别上下文。这点容易被忽略——你不是权限没修，是修错了对象。
