post-install-cmd 是唯一自动触发的钩子但默认不执行，需确保未启用 --no-scripts、脚本名精确为 post-install-cmd、package.json 存在且 cwd 为项目根目录；推荐用 node_modules/.bin/npm 加前置判断调用 npm，并区分 install/update 钩子行为。
post-install-cmd 是唯一能自动触发的钩子，但默认不执行——必须确保没加 --no-scripts，且脚本名拼写精确。
为什么 post-install-cmd 不生效？
常见错误现象：composer install 完成后静默退出，npm 命令根本没跑。
根本原因不是配置错，而是触发条件被破坏：
-
--no-scripts被隐式启用：CI 环境常设COMPOSER_NO_DEV=1或直接传参，会跳过所有脚本 - 脚本名写成
post-install或after-install：Composer 只认post-install-cmd（带-cmd后缀） - 项目根目录下没有
package.json，但脚本里硬写了npm install：命令失败但 Composer 默认忽略非 0 退出码 - Docker 或 symlink 环境中，
getcwd()返回路径不是项目根目录，导致npm找不到package.json
怎么安全地在 post-install-cmd 中调用 npm？
直接写 "npm install && npm run build" 看似简单，但跨平台和容错性差。推荐以下写法：
- 用
node_modules/.bin/npm替代全局npm：避免 Windows 上找不到命令或版本不一致 - 加前置判断：
sh -c "if [ -f package.json ]; then node_modules/.bin/npm ci --silent && node_modules/.bin/npm run build; fi" - 把构建逻辑封装进
scripts/build.sh，再在 JSON 里写"bash scripts/build.sh"：便于调试、加日志、处理权限 - 若只在生产环境构建，检查
$_SERVER['APP_ENV']或getenv('APP_ENV')，避免本地开发时反复编译
composer install 和 composer update 的脚本差异
两者都支持 post-install-cmd 和 post-update-cmd，但行为不同：
前端设计优化skill
下载
前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。
-
post-install-cmd只在首次安装或vendor/不存在时触发；composer update不会触发它 -
post-update-cmd在composer update时运行，但composer install不会触发它——别指望一个钩子覆盖全部场景 - 如果想统一处理，两个钩子里都写相同命令；如果想区分逻辑（比如更新时跑迁移、安装时跑构建），就得分开配置
-
post-autoload-dump更可靠：只要 autoload 文件重生成就会触发，适合清理缓存或生成前端代理文件，但不能替代构建
构建失败时怎么快速定位问题？
Composer 默认吞掉命令输出，构建失败却无提示。实际部署中容易卡在“静态资源没生成”却查不出原因：
立即学习“前端免费学习笔记（深入）”；
- 去掉
--silent或-q参数，让npm输出原始错误 - 在脚本开头加
set -e（bash）或exit-on-error（PowerShell），确保任一命令失败立即中断 - 把构建日志重定向到
storage/logs/npm-build.log，方便事后排查 - 注意
node_modules/权限：Docker 中若用非 root 用户运行，npm ci可能因写权限失败，得提前chown -R www-data:www-data node_modules/
