直接用 composer run-script 清理静态资源不可靠，因其不自动触发且跨平台兼容性差；正确做法是封装为PHP脚本，用is_dir()和glob()安全清理，并严格区分asset-packagist自动管理目录与手动维护目录。
直接用 composer run-script 清理静态资源，90% 的失败不是因为命令写错，而是没搞清它根本不会自动触发——它只响应你手动调用，或被 post-install-cmd 这类钩子间接拉起。
post-install-cmd 里写 rm -rf public/js/vendor 真的可靠吗？
不可靠。这种写法在 CI/CD 或多环境部署中极易中断：
- 路径不存在时
rm -rf会报错并终止整个composer install流程（除非加|| true） -
public/js/vendor可能是前端构建产物目录，也可能是你手动维护的 CDN 备份，删错就丢文件 - Windows 环境下
rm命令根本不存在，脚本直接退出 - 没判断
public/目录是否存在，mkdir -p缺失会导致后续拷贝失败
正确做法是封装成 PHP 脚本：php scripts/clean-static.php，用 is_dir() 和 array_map('unlink', glob(...)) 安全清理，跨平台无依赖。
为什么不能把 npm run build && rm -rf node_modules 放进 scripts？
因为 composer run-script 不保证 Node.js 环境可用：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- CI 构建镜像可能没装 Node.js，
npm命令直接报command not found -
node_modules是开发期产物，不属于 Composer 管理范围；composer install --no-dev不会碰它，但你脚本里删了，下次npm install就得重下 - 若清理逻辑和构建耦合（比如先
npm run build再删src/），一旦构建失败，残留文件会污染输出目录
真正该清理的，是 public/build/ 下的旧哈希文件、未引用的 CSS chunk、或 vendor/xxx/assets/ 中重复拷贝的 JS —— 这些才是 Composer 阶段该管的静态资源。
asset-packagist.org 的资源清理必须配 extra.asset-installer-paths 吗？
必须。漏配等于白装：
-
extra.asset-installer-paths是 asset-packagist 插件的开关，不是可选项；不写，哪怕你require npm-asset/jquery，文件也不会自动复制到public/ - 路径格式必须严格：
{"public/js/{$name}": ["npm-asset/jquery"]}，{$name}是占位符，会被替换成包名，不能手写成jquery - 清理这类资源时，不能直接删
public/js/jquery—— 下次composer install会重新拉，但如果你删的是public/js/jquery/dist而源包只提供src/，那复制就失败
推荐清理方式：只删 public/js/* 下非 asset-packagist 管理的目录（比如你手工放的旧版本），保留插件自动管理的部分。
最易被忽略的一点：composer run-script 执行时，当前工作目录是项目根，但 vendor/autoload.php 刚生成，APP_ENV 等变量尚未加载 —— 所有依赖环境判断的清理逻辑，必须显式读取 .env 或通过 getenv() 拿系统级变量，不能指望框架配置已就绪。
