不能直接合并前端资源，但可通过scripts钩子（如post-update-cmd）触发webpack等工具执行构建，将合并、压缩、生成source map等任务交由前端工具完成，并输出至public/build等Web可访问目录，避免污染vendor和autoload。
composer.json 的 scripts 钩子能自动合并前端资源吗？
不能直接“合并”，但可以触发构建流程来生成合并后的资源。Composer 本身不处理文件内容合并（比如把多个 .js 拼成一个），它只负责执行命令。真正做合并的是 webpack、rollup 或 npm run build 这类前端工具。
常见错误是以为在 post-install-cmd 里写个 cat a.js b.js > bundle.js 就算“自动合并”——这确实能拼，但没处理依赖、ES模块解析、source map、压缩等关键环节，上线后大概率报错或体积失控。
- 必须确保运行环境已安装 Node.js 和对应构建工具（
npm或yarn） -
COMPOSER_DISABLE_FUNCTIONS环境变量或--no-scripts参数会直接跳过所有钩子，CI/CD 中容易漏查 - 脚本路径默认在项目根目录执行，若构建配置（如
webpack.config.js）放在子目录，需用cd assets && npm run build显式切换
post-install-cmd 和 post-update-cmd 哪个更适合触发构建？
优先用 post-update-cmd，除非你明确需要首次安装时就产出资源。原因很实际：
-
post-install-cmd只在composer install且无vendor/时触发；而composer update不会调它，导致依赖升级后前端资源未重建 -
post-update-cmd在install和update两种场景下都会执行，更符合“依赖变了，前端也要同步更新”的逻辑 - 若项目含
package-lock.json，建议同时在post-update-cmd里加npm ci，避免npm install引入非锁定版本
示例配置：
立即学习“PHP免费学习笔记（深入）”；
前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。
"scripts": {
"post-update-cmd": [
"cd resources/assets && npm ci && npm run build"
]
}
如何让合并后的资源被 PHP 安全访问而不污染 vendor？
核心原则：静态资源绝不放进 vendor/，也绝不进 Composer autoload。正确路径是输出到 Web 可达目录（如 public/build/），再由 PHP 通过路径或 URL 拼接引用。
- Webpack/Vite 输出目录必须设为
public/build/或类似位置，不能是vendor/xxx/dist/ - PHP 中引用时用绝对 URL（如
<script src="/build/app.js"></script>），而非相对路径或file_get_contents()读取 - 如果要用 PHP 动态注入资源路径（比如根据环境切 CDN），应读取构建后生成的
manifest.json，而不是硬编码文件名 - 务必在
.gitignore中忽略public/build/，防止误提交构建产物；CI 中应明确执行构建步骤
为什么用 fxp/composer-asset-plugin 已不推荐？
该插件自 Composer 2.2 起已停止维护，且与现代 PHP 版本（8.1+）存在兼容性问题。它依赖老旧的 asset-packagist.org，该源站自 2025 年底起响应缓慢、包元数据缺失严重，composer require npm-asset/bootstrap 经常卡在下载阶段或返回 404。
更关键的是，它仍试图把前端资源“塞进 Composer 流程”，违背了分工原则——PHP 包管理器不该承担资源分发和构建职责。
- 替代方案是彻底解耦：用
composer.json管 PHP 依赖，用package.json管前端依赖，靠post-update-cmd协调执行 - 若需统一入口，可封装一个
make build或./build.sh脚本，内部顺序调用composer install和npm run build，比强绑 Composer 钩子更可控 - 遗留项目迁移时，重点检查是否还残留
"type": "bower-asset"或"type": "npm-asset"的包声明，这些类型已被主流生态弃用
真正难的不是怎么触发构建，而是让 PHP 和前端两套流程在权限、路径、缓存、部署节奏上不互相踩脚——这点容易被忽略，但决定长期可维护性。
