webman项目gitlab ci/cd成功部署的核心前提是：.gitlab-ci.yml文件名准确、语法规范且位于根目录；composer install需指定php镜像、扩展及--no-interaction等参数；php webman restart须加ssh -t分配pty并确保用户权限与daemon配置一致。
Webman 项目用 GitLab CI/CD 自动构建发布，核心不是选 Docker 还是 rsync，而是先让 .gitlab-ci.yml 被识别、composer install 不卡住、php webman restart 真能生效——三者任一失败，整个流水线就静默失效。
为什么 .gitlab-ci.yml 总是不触发 pipeline
GitLab 只认一个文件名：.gitlab-ci.yml（开头带点、全小写、yml 后缀），拼错一个字符（比如 .gitlab-ci.yaml 或 gitlab-ci.yml）就完全不加载。常见现象是 UI 显示 “CI/CD is disabled” 或日志里报 “configuration not found”。
- 用
git ls-files | grep -i gitlab确认文件是否在仓库根目录且名字准确 - 执行
chmod -x .gitlab-ci.yml—— 某些 Runner 会拒绝加载有可执行权限的配置文件 - YAML 缩进必须用空格，不能用 Tab；
stages、build这类顶层关键字前不能有任何空格 - 提交后去 GitLab 项目页 > CI/CD > Editor，看能否自动解析出 stage 和 job —— 解析失败基本就是语法或命名问题
composer install 在 CI 中反复失败的硬伤
本地能装，CI 里报 extension missing、timeout 或卡在“Loading composer repositories”，大概率是基础镜像没配对，或命令缺关键参数。
- 必须显式指定 PHP 版本与扩展：比如用
php:8.2-cli-alpine，但没装ext-curl或ext-zip，composer install就会在 require 阶段直接报错，而不是提示“扩展缺失” - 必须加
--no-interaction --no-dev --optimize-autoloader：缺--no-interaction会导致 Composer 等待 stdin 输入，CI 环境无交互，job 就一直挂起 - 如果项目依赖私有 Packagist 包，需提前在 CI job 中注入
auth.json，用 GitLab Secrets 存 token，不能硬编码到仓库 - 避免在 deploy 阶段重复
composer install：build 阶段应生成完整vendor/并通过artifacts传递，deploy 阶段只同步代码 + 缓存
rsync 部署后 php webman restart 不生效
Webman 的守护进程（webman start / restart）默认只监听当前终端会话，CI 里 ssh 远程执行命令时若未分配伪终端（pty），进程启动后立即退出，导致看似重启成功实则服务未更新。
- 远程执行命令必须加
-t参数强制分配 pty：ssh -t user@host 'cd /var/www/webman && php webman restart' - 确保目标服务器上 Webman 已用
php webman start --daemon启动过，否则restart找不到 pid 文件 -
rsync命令务必加--delete --exclude='.git' --exclude='storage/logs'：不加--delete会残留旧 vendor 或配置；不排除storage/logs可能覆盖线上运行日志 - 部署后建议加健康检查：
curl -f http://localhost:8787/health（假设 Webman 监听 8787），返回非 2xx 就让 job 失败，避免“部署成功但服务挂了”
最常被忽略的是 Webman 进程的用户权限和工作路径：CI 用 root 或 runner 用户 rsync 同步代码后，php webman restart 若以不同用户身份执行，pid 文件读写权限不对，就会假重启。务必统一部署用户，并在 webman.php 中确认 daemon 配置的 user 字段与实际运行用户一致。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
