commonjs 依赖打包工具桥接非模块化脚本：browserify 用 browserify-shim 声明式映射全局变量；webpack 通过 externals、imports-loader 和 exports-loader 实现外部化与导出包装；rollup 需插件或自定义钩子处理，但非首选；推荐手写 wrapper 封装，明确可控。
CommonJS 本身不支持直接加载非 CommonJS 模块（比如全局变量暴露的库、UMD 脚本、IIFE 包裹的传统 JS 文件），但主流打包工具提供了多种转换机制，让这类模块能被 require() 正常引用。关键不是“强行转成 CommonJS”，而是建立桥接层，补全导出逻辑。
Browserify + browserify-shim：专治老式全局库
这是处理 jQuery 插件、Lodash CDN 版、或 legacy 工具库最成熟的组合。browserify-shim 不是转换代码，而是“声明式打桩”：
- 在
package.json中配置 shim，告诉 Browserify：“当有人require('jquery')时，请把它当成window.jQuery导出” - 支持重命名导出（如把
require('three')映射为THREE全局对象） - 可指定依赖顺序（例如先加载 jQuery，再加载依赖它的插件）
- 无需修改源码，也不需要额外构建步骤，shim 配置即生效
Webpack 的 externals + imports-loader / exports-loader
Webpack 更倾向“外部化 + 注入导出”的方式，尤其适合已知全局变量名的脚本：
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
-
externals: { jquery: 'jQuery' }告诉 Webpack：遇到require('jquery')别打包，直接取window.jQuery -
imports-loader可在模块开头注入变量（如$=jQuery），解决无require但依赖全局符号的问题 -
exports-loader可把一个 IIFE 脚本的返回值包装成module.exports（例如exports?MyLib表示导出window.MyLib） - 现代项目中，更推荐用
import语法配合/* webpackIgnore: true */+ 动态import()加载非模块化资源
Rollup 的 @rollup/plugin-commonjs + 自定义 resolve
Rollup 默认只处理 ES 模块，要兼容 CommonJS 已属扩展；对非 CommonJS，则需分两步：
- 先用
@rollup/plugin-commonjs把 npm 中的 CommonJS 包转成 ES 模块（这是它最常用场景） - 对纯全局脚本，通常配合
@rollup/plugin-inject或自定义resolveId+load钩子：拦截特定路径，返回一段包裹了export default window.Xxx的虚拟模块代码 - 不建议用 Rollup 主打非模块化兼容——它优势在 ESM 和 tree-shaking，强塞 legacy 支持反而配置复杂、易出错
通用建议：优先封装，而非硬转
比起让打包工具“猜”怎么导出，更可靠的做法是自己写一层薄薄的 wrapper：
- 新建
src/adapters/jquery.js，内容为：import $ from 'jquery'; export default $;（如果已安装 jQuery npm 包） - 若只能用 CDN script，就写：
export default window.jQuery;，然后在 HTML 中确保 script 标签在 bundle 前加载 - 这种 wrapper 明确可控，调试方便，也避免打包工具插件版本升级带来的行为变化
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
