Yii框架需借助扩展实现JS合并：Yii1用EClientScript但存在调试无效、执行顺序错乱、不支持ES6等问题；Yii2推荐skeeks/yii2-assets-auto-compress，需正确配置assetsAutoCompress、jsFileCompile等参数，并验证合并产物。
Yii 框架本身不自动合并 JS 文件，必须通过扩展或手动配置实现；直接改 clientScript 配置项或依赖未维护的旧插件，大概率导致资源加载错乱、调试困难甚至页面白屏。
Yii1 中用 EClientScript 扩展合并 JS 的实际效果与限制
这个插件（yii-EClientScript）是 Yii1 时代最常用的方案，但它的行为和预期有明显偏差：
-
combineScriptFiles => TRUE确实会把所有registerScriptFile()注册的 JS 合并成一个请求，但只在非YII_DEBUG模式下生效 —— 开发时永远看不到合并效果 - 它不会重排执行顺序：如果 A.js 依赖 B.js，但 B.js 后注册，合并后仍按注册顺序拼接，运行时报
undefined是常态 - 不处理
POS_END和POS_HEAD的物理位置分离 —— 所有 JS 不管注册在哪，最终都塞进<body>底部，可能破坏 DOM 就绪逻辑 - 压缩用的是
JSMin变体，对 ES6+ 语法（如箭头函数、解构）直接报错，2026 年已基本不可用
Yii2 推荐用 skeeks/yii2-assets-auto-compress 而不是自己写合并逻辑
自己遍历 AssetBundle、读文件、拼字符串、写缓存，既重复造轮子又容易出竞态。官方生态里 skeeks/yii2-assets-auto-compress 是目前唯一持续维护、适配 PHP 8.x 和 Yii2.0.45+ 的方案：
- 启用前必须确保
bootstrap中注册了assetsAutoCompress，否则整个组件不启动，静默失效 -
jsFileCompile => true才真正触发合并；jsCompress => true是额外的代码级压缩（需tedivm/jshrink），二者要同时开才有意义 - 合并后的 JS 默认输出在
</body>前，但如果你在AppAsset里显式设置了jsOptions['position'] = \yii\web\View::POS_HEAD，它会尊重该设置 —— 这点比 Yii1 插件靠谱得多 - 注意
readFileTimeout默认是 3 秒，若项目有大体积第三方库（比如three.js），得调高，否则合并中途失败，页面只剩裸 HTML
合并 JS 时最容易被忽略的路径和权限问题
合并失败往往不报错，只回退到单文件加载，你以为“看起来正常”，其实优化根本没生效：
- 插件默认只合并
web/目录下的 JS，如果你把脚本放在@app/assets/或@vendor/下且没配basePath，它们会被跳过 - Web 服务器用户（如
www-data）必须对runtime/assets-auto-compress/有写权限，否则缓存无法生成，每次请求都重新编译，CPU 拉满 -
cssFileCompile和jsFileCompile共享同一级缓存目录，若 CSS 合并失败（比如某 CSS 里写了@import url(...)），JS 合并也会卡住 —— 它们底层共用同一个文件锁 - 使用
file_get_contents()读取远程 URL（如 CDN 上的 jQuery）会被拒绝，插件只处理本地文件系统路径
真正在生产环境跑通 JS 合并，核心不在“怎么配”，而在“是否验证了合并产物”。上线前务必 curl 页面源码，搜 .js?v= 后缀，确认只有一个 JS 请求，且响应内容确实是多文件拼接结果 —— 其他都是幻觉。
