Mac 上 Laravel 安装失败，八成是权限或路径权限没对齐，不是 Composer 或 PHP 本身坏了。
mkdir(): Permission denied 错误直接指向属主/属组错乱
这个错误不是 Laravel 的锅，而是当前用户对目标目录（比如 ~/Sites 或 /usr/local/bin）没有写入权。Mac 默认启用了 SIP（System Integrity Protection），/usr/local/bin 在较新系统里连 sudo 都改不了权限 —— 所以别硬碰 /usr/local/bin，换路走。
用 groups 看当前用户属于哪些组，常见是 staff 或 admin创建项目目录时，先确保父目录归属正确：sudo chown -R $USER:staff ~/Sites不要用 sudo composer create-project，它会让生成的 vendor/ 和 storage/ 归属变成 root，后续 php artisan 就会反复报错如果已错，进项目根目录执行：sudo chown -R $USER:staff .（注意末尾的点）
storage 和 bootstrap/cache 权限不够导致日志/缓存写失败
Laravel 启动后立刻报 file_put_contents(/path/to/storage/logs/laravel.log): failed to open stream，说明运行 PHP 的用户（通常是当前终端用户）无法往这两个目录写文件。777 不是必须，但 Mac 下最稳的临时解法就是明确放开。
chmod -R 775 storage/ bootstrap/cache/ 是最小权限推荐值；若仍失败，再升到 777别只改 storage/ 忘了 bootstrap/cache/，后者存着路由/配置缓存，artisan 命令一跑就写如果用 Valet，它默认以当前用户身份运行 PHP，所以只要目录属主是你自己，755 就够；但 Sail/Docker 场景下，容器内 UID 可能不匹配，这时需在 docker-compose.yml 中显式指定 user: "1000:1000" 并同步宿主机目录属主
composer self-update 或 install 卡住/报 zlib_decode() error
这不是压缩算法出问题，而是 Composer 下载的 ZIP 包中途损坏，大概率是网络波动或 DNS 污染导致。Mac 上尤其容易因国内网络环境触发降级模式（degraded mode）。
先试 composer config -g repo.packagist composer https://packagist.phpcomposer.com（国内镜像）或者更彻底：用阿里云镜像源：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/如果还卡在 zlib_decode(): data error，加 –prefer-dist –no-cache 强制重下压缩包并跳过本地缓存：composer create-project –prefer-dist –no-cache laravel/laravel myapp避免全局用 sudo composer，它会污染 ~/.composer 权限，之后所有非 sudo 的 composer 命令都可能失败
Docker + Sail 构建失败提示 “unmet dependencies” 或 “held broken packages”
这是 Docker 构建阶段的 apt 包冲突，不是你本地 Mac 的问题。Sail 默认用 Ubuntu 基础镜像，而某些扩展（如 gnupg、perl-base）版本锁死，和镜像源里最新版打架。
别手动关 SIP 或改系统级 apt 源——你在容器里，改宿主机没用在项目根目录的 Dockerfile（或 .docker/alpine/Dockerfile）里，把 apt-get install 拆开，并强制指定版本，例如：apt-get install -y gnupg=2.2.19-3ubuntu2.1~更省事的方案：删掉 .docker/ 目录，改用官方 Sail 最新版（v1.24+），它已切换到更稳定的 php:8.3-cli-slim 基础镜像，基本避开 Ubuntu 包冲突构建前清空本地镜像缓存：docker builder prune -a，否则旧层残留会误导依赖解析
Mac 上 Laravel 的权限问题，本质是「用户 → 目录 → 进程」三者身份没对齐。很多人修完 storage/ 就以为搞定，结果 artisan serve 能跑，phpunit 或队列 worker 一启动又挂——因为它们可能用不同用户或不同 PHP SAPI 运行，得挨个确认归属和 umask 设置。
评论(0)