post-install-cmd脚本默认以当前shell用户身份运行，如CI中gitlab-runner用户执行，则所有命令均以其权限操作；若storage/属www-data而该用户未加入对应组，chmod等操作将因权限不足失败。
直接给 Composer 自动化发布脚本分配“最低所需权限”，关键不是给 composer 命令本身提权，而是控制它执行时的**用户身份、工作目录权限、命令作用域**——绝大多数“权限失败”都源于脚本以错误用户运行，或试图操作非属主目录。
post-install-cmd 脚本默认以谁的身份运行？
就是你当前 shell 的用户。比如你在 CI 里用 gitlab-runner 用户跑 composer install，那 post-install-cmd 里的所有命令（php artisan cache:clear、chmod）全由 gitlab-runner 执行。如果 storage/ 目录属于 www-data，而 gitlab-runner 没被加进 www-data 组，chmod -R 775 storage/ 就会 Permission denied。
- 别用
sudo写在 scripts 里——CI 环境通常禁用交互式密码输入，且违反最小权限原则 - 检查目标目录归属：
ls -ld storage/ bootstrap/cache/，确认是否和执行用户一致 - 生产部署推荐将部署用户加入 Web 服务器组，例如：
usermod -aG www-data gitlab-runner
哪些命令在 scripts 里必须显式限制路径和参数？
像 chmod、chown、rm 这类系统命令，一旦路径写错或没加 -R，轻则无效，重则删错目录。它们不因“在 Composer 脚本里”就自动变安全。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
chmod只设必要权限：chmod 755 storage/（目录），chmod 644 .env（文件），避免无脑777 -
chown不要硬编码用户：chown -R $USER:www-data storage/比chown -R www-data:www-data storage/更可控 - 清缓存类命令优先用
@php artisan ...而非裸php artisan，确保走项目内 PHP 解释器，避免 CLI 版本差异 - 敏感操作如数据库迁移，必须加
--no-interaction --force，否则卡住等于阻塞整个发布流程
为什么 --no-dev 和 --no-scripts 要分开判断？
--no-dev 关闭开发依赖加载，是性能与安全必需；但 --no-scripts 会直接跳过 post-install-cmd，导致权限、缓存等后续动作全部失效——很多人误以为“生产环境要关脚本”，结果部署完发现 storage/ 还是 755，缓存也没清。
- 正确组合是：
composer install --no-dev --optimize-autoloader（保留脚本） - 若真要禁用某类脚本，应拆成独立命名脚本，例如：
"deploy:fix-perms": "chmod -R 775 storage/ bootstrap/cache/"，再显式调用：composer run deploy:fix-perms - CI 流水线中可用环境变量兜底：
if [ "$APP_ENV" = "prod" ]; then composer install --no-dev; else composer install; fi
真正难处理的不是“怎么加权限”，而是“谁该拥有哪个目录”。一个 storage/ 目录，CLI 用户要写日志，Web 用户要读视图缓存，两者必须共属同一组，且 umask 设置得当——这点在 Docker 或多用户共享服务器上最容易被忽略。
