composer不直接管理前端资源，仅通过post-install-cmd等脚本调用npm/yarn构建产物并输出至public/build/供php引用；需加防护层判断package.json存在、避免构建失败中断php安装，并将构建与发布流程解耦。
Composer 本身不处理前端资源，但能可靠触发 npm/yarn 构建、同步产物、甚至参与发布流程——关键在于别让 post-install-cmd 承担不该它干的活，也别把构建逻辑硬塞进 shell 一行命令里。
npm install 和 npm run build 该不该放 post-install-cmd？
可以放，但必须加防护层。直接写 "post-install-cmd": "npm install && npm run build" 是危险操作：本地开发时可能误触发、CI 中 node_modules 已存在时会重复安装、package.json 缺失时直接崩溃。
- 先判断
package.json是否存在：@php -r "file_exists('package.json') ?: exit(0); system('npm install && npm run build');" - 生产环境禁用 dev 依赖时，
post-install-cmd默认不执行——得显式加--no-dev参数或改用composer run build:frontend - 构建产物（如
public/build/）路径要固定，且确保 Web 服务器有读权限；别依赖相对路径，用__DIR__或环境变量定位
如何避免前端构建污染 PHP 部署流程？
前端构建失败不应导致 Composer install 失败，PHP 依赖和 JS 依赖是两套生命周期，强行耦合会拖垮部署稳定性。
- 把构建拆成独立 script：
"build:frontend": "@php scripts/build-frontend.php"，脚本内用proc_open()捕获 npm 错误并返回非零码，但不中断主流程 - CI 中应分步执行：
composer install --no-dev→npm ci→npm run build，而非全塞进一个钩子 - 构建产物提交与否需明确：若提交
public/build/，则跳过部署机上的构建；若不提交，就得确保部署机装了 Node.js 并设好NODE_ENV=production
发布时怎么同步前端静态资源？
发布 ≠ 构建，构建完成后的产物同步，才是发布链路中真正需要脚本介入的环节。
- 不要在
post-release里直接rsync—— 权限、目标路径、排除规则都容易出错；改用封装好的 PHP 脚本，比如scripts/sync-assets.php，支持 dry-run 模式预检 - 同步前检查构建产物完整性：
file_exists('public/build/manifest.json')或校验public/build/*.js时间戳是否新于assets/ - 远程同步命令建议用
rsync -av --delete public/build/ user@host:/var/www/html/build/，注意末尾斜杠含义；避免scp -r导致覆盖残留文件
为什么 build:assets 脚本总在 CI 里失败？
常见原因是环境差异：本地有全局 npm 包（如 cross-env），CI 容器却只装了基础 Node.js，或者 PATH 不一致导致找不到 npm。
- 所有命令显式调用完整路径：
/usr/bin/npm ci或$(which npm) run build，别信默认 PATH - Node.js 版本必须锁定：CI 配置中指定
node-version: '20.15.0'，并在.nvmrc和engines.node里声明 - 缓存
node_modules时，别只缓存顶层目录——npm ci依赖package-lock.json精确还原，缓存失效会导致构建不一致
最易被忽略的是：前端构建产物的哈希命名（如 app.a1b2c3.js）和 PHP 模板中引用路径的自动替换，这一步没法靠 Composer script 完成，得靠构建工具自身能力或额外的 post-build 脚本注入，否则上线就 404。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
