Composer没有pre-release钩子，需用pre-update-cmd或自定义命令如check:pre-deploy模拟；上线前检查必须在代码执行前完成，重点校验配置存在性、环境变量、目录可写性及构建产物完整性，失败须exit(1)。
pre-release脚本不存在，得用pre-update-cmd或自定义命令模拟
Composer 没有 pre-release 这个内置钩子。所谓“上线前检查”，实际要拆解为两个场景：一是本地打 tag 前的校验，二是部署流水线中构建前的防护。前者靠 Git hook + composer run check:pre-deploy 更可控；后者推荐用 pre-update-cmd（因为 release 通常伴随依赖更新）或显式调用自定义脚本名。
直接在 composer.json 里写 "pre-release": "echo 'no such hook'" 不生效，会被忽略。
- 如果 release 流程本质是
git tag v1.2.0 && git push --tags，就在.git/hooks/pre-tag里调用composer run check:pre-deploy - 如果 release 是 CI 触发（如 GitHub Actions on tag），就在 workflow 里先跑
composer run check:pre-deploy，再执行构建和发布 -
pre-update-cmd可用，但注意它只在composer update时触发——如果你 release 不涉及 update，这个钩子就压根不跑
check:pre-deploy 脚本该检查什么？别漏掉这三类硬性条件
上线前检查不是走形式，核心是拦截那些“能跑通但会炸线上”的隐性问题。重点盯住路径、权限、环境一致性三块。
- 检查
config/下关键配置文件是否存在且可读：file_exists('config/database.php')，并验证DB_HOST等必需 env 变量已设（用getenv()或$_ENV） - 确认
storage/和bootstrap/cache/目录可写（is_writable()），否则 Laravel/ Symfony 启动即挂 - 校验前端构建产物完整性：比如
file_exists('public/build/manifest.json')，或比对public/build/*.js修改时间是否晚于resources/js/（避免漏构建）
所有检查失败必须 exit(1)，并输出具体错误到 STDERR，否则 CI 会当成成功继续往下走。
怎么注册和运行 check:pre-deploy？别硬编码路径
把检查逻辑写进独立 PHP 文件（如 scripts/check-pre-deploy.php），然后在 composer.json 里用引用方式挂载，避免后期改路径要到处搜。
示例注册方式：
"scripts": {
"check:pre-deploy": "php scripts/check-pre-deploy.php",
"pre-update-cmd": ["@check:pre-deploy"]
}
-
scripts/check-pre-deploy.php必须有#!/usr/bin/env php头，且 Linux/macOS 下加执行权限：chmod +x scripts/check-pre-deploy.php - Windows 用户注意：不要依赖 shebang，确保
php在 PATH 中，或显式写成php scripts/check-pre-deploy.php - CI 中若用 Docker，需确认镜像里装了 PHP CLI，且工作目录正确（
WORKDIR /app）
为什么不用 post-install-cmd 做上线检查？它时机不对
post-install-cmd 在 composer install 完成后才跑，此时代码可能已部分加载、缓存已生成、甚至 Web 服务已启动——检查失败也来不及回滚。
- 上线检查必须在任何代码执行前完成，属于“守门员”角色，不是“善后员”
-
post-install-cmd更适合做构建后同步（如cp public/build/* public/）、缓存预热等确定性操作 - 如果误把检查塞进
post-install-cmd，遇到Class not found错误时，你根本分不清是 autoloader 没生效，还是检查本身被跳过了
真正容易被忽略的是：检查脚本里用的路径（如 __DIR__ . '/../config'）在不同执行上下文（CLI vs Web SAPI）下行为一致，建议统一用 dirname(__DIR__) 定位项目根，别信相对路径。
