核心思路是用默认acl锁定新文件属主权限，配合umask与专用部署用户隔离，阻断解压继承原始包的危险权限；需确认文件系统启用acl、设置default acl及mask、规范解压用户与umask，并自动化验证nginx访问权限。
核心思路是：用默认ACL锁定新文件的属主权限，再配合umask和部署用户隔离，让解压行为不继承原始包的权限“毒素”。502报错本质常是Web服务器（如Nginx）因无读/执行权限无法加载PHP/JS等资源，而源头正是解压后文件权限混乱——比如原包由root打包，解压到/www下导致所有者为root、组为root、其他无权限，Nginx worker进程（通常跑在www-data或nginx用户下）直接被拒之门外。
确保文件系统真正启用ACL
很多故障卡在这一步，setfacl命令静默失败却不报错。不能只看发行版是否“默认支持”，必须验证挂载选项：
- 运行
mount | grep "$(df . | tail -1 | awk '{print $1}')" | grep acl，确认输出含acl字样 - 若无，临时启用：
sudo mount -o remount,acl /var/www（把/var/www换成你的发布根目录） - 永久生效：编辑
/etc/fstab，在对应分区行的挂载选项里追加,acl（注意逗号无空格），再执行sudo mount -a
为发布目录设置Default:User ACL并覆盖mask
关键不是给现有文件改权限，而是让所有新解压出来的文件自动获得干净、可控的权限基线。以Nginx站点目录 /var/www/myapp 为例：
- 先清空历史ACL干扰：
setfacl -b /var/www/myapp - 设默认规则（仅对新文件/子目录生效）：
setfacl -d -m u:www-data:rwX,g:www-data:rwx,o::rX /var/www/myapp
（X大写很重要：对目录加x，对普通文件只在原权限有x时才加x，避免脚本被意外剥夺执行权） - 强制重算mask，确保上限不卡死：
setfacl -m m::rwx /var/www/myapp
否则即使设了u:www-data:rwX，若mask是r--，实际就只剩r
约束解压行为本身：用户、umask与归档格式
ACL管的是“出生后”的权限，但解压过程本身能决定“谁来当爹”。必须切断原始包的UID/GID污染链：
- 部署流水线中，禁止用root解压。统一使用专用部署用户，如
deploy：sudo -u deploy tar -xzf release.tgz -C /var/www/myapp - 为
deploy用户设置宽松umask（推荐002）：
在/home/deploy/.bashrc或全局/etc/profile.d/deploy.sh中加入umask 002，确保新建文件基础权限为664、目录为775 - 打包阶段就规范源：CI流水线打包时用
tar --owner=deploy --group=www-data，从源头消除root UID残留
验证与兜底：每次发布后自动检查
靠人眼检查不可靠，应在发布脚本末尾加入自动化校验：
- 创建测试文件：
sudo -u www-data touch /var/www/myapp/.health_check && sudo -u www-data mkdir /var/www/myapp/.health_dir - 检查ACL继承：
getfacl /var/www/myapp/.health_check | grep "user:www-data" | grep "rw-"应返回成功 - 检查Nginx可访问性：
sudo -u www-data ls -l /var/www/myapp/index.php 2>/dev/null | grep -q "www-data.*www-data" - 失败则立即退出并报警，不进入后续重启服务步骤
不复杂但容易忽略：Default ACL不是万能解药，它只作用于“创建瞬间”。如果解压工具（如某些版本的unzip）绕过内核创建逻辑、或使用特权上下文覆盖了ACL，仍可能失效。因此必须三者齐备——文件系统acl挂载、default ACL+mask显式设定、部署用户+umask双保险。
