浏览器中无法直接通过 import 语句导入未声明 export 的传统脚本（如 var feature = {...}），因为 es6 模块系统要求显式导出；必须通过动态导入、全局污染隔离或封装包装等方式间接接入。
浏览器中无法直接通过 import 语句导入未声明 export 的传统脚本（如 var feature = {...}），因为 es6 模块系统要求显式导出；必须通过动态导入、全局污染隔离或封装包装等方式间接接入。
在现代浏览器环境中，ES6 模块（type="module"）具有严格的静态解析和作用域隔离机制：它只识别符合 ECMAScript 模块规范的代码——即包含 export 或 export default 声明的文件。像以下这类传统脚本：
// feature.js
var Feature = {
foo() { console.log('Hello from Feature'); }
};本质上是“脚本（script）”而非“模块（module）”，执行时仅向全局作用域（window 或 globalThis）注入变量，无法被静态 import "/feature.js" 解析为模块绑定，因此 Feature 在模块作用域内不可访问。
✅ 可行的解决方案（按推荐度排序）
1. 动态导入 + 全局变量捕获（推荐，零修改原库）
利用 await import() 执行脚本（注意：它会触发脚本执行，但不提供命名绑定），随后从 globalThis 安全读取并立即删除，避免长期污染：
// index.js
async function loadFeature() {
await import('/feature.js'); // ✅ 触发执行，挂载 Feature 到 globalThis
const Feature = globalThis.Feature;
delete globalThis.Feature; // ? 主动清理，限制作用域
return Feature;
}
// 使用
const Feature = await loadFeature();
Feature.foo(); // 正常调用
console.log(globalThis.Feature); // undefined —— 已隔离⚠️ 注意：此方式依赖脚本执行顺序，需确保 feature.js 确实向 globalThis 写入变量，且无副作用冲突。
2. 封装为兼容模块（最佳实践，一次封装，长期复用）
创建一个轻量级包装模块（如 feature-wrapper.js），显式导出所需对象：
// feature-wrapper.js import '/feature.js'; // 仅执行，不绑定 export const Feature = globalThis.Feature; // 可选：清理 delete globalThis.Feature;
然后在主模块中正常导入：
// index.js
import { Feature } from './feature-wrapper.js';
Feature.foo(); // ✅ 安全、静态、可 tree-shaking3. 利用 UMD 输出（针对你提到的 Gmail 库）
你观察到的 UMD 片段：typeof exports !== 'undefined' && (exports.Gmail = Gmail)，说明该库支持 CommonJS 环境，但在浏览器中默认仍走全局分支。此时更稳妥的做法是显式模拟 exports 对象，避免污染全局：
async function loadGmail() {
const exports = {}; // ? 局部 exports，不挂载 globalThis
await import('/libs/gmail.min.js', {
assert: { type: 'text/javascript' }
}).catch(() => {
// 若直接 import 失败（因非模块），回退为 script 注入
const script = document.createElement('script');
script.src = '/libs/gmail.min.js';
script.async = false;
document.head.appendChild(script);
await new Promise(r => script.onload = r);
});
// UMD 会向局部 exports 写入 Gmail（需库实际支持 exports 注入）
// 否则仍需 fallback 到 globalThis.Gmail
return globalThis.Gmail ?? exports.Gmail;
}❗ 关键提醒：你原方案中手动赋值 globalThis.exports ??= {} 并非可靠 workaround——它污染了全局 exports，且无法保证库在浏览器中主动写入该对象（UMD 的 exports 分支通常仅在 Node.js 中生效）。应优先采用封装或动态捕获策略。
总结
- ❌ 静态 import "/xxx.js" 对非模块脚本无效，且不会暴露其全局变量；
- ✅ 动态 import() 是执行脚本的合法入口，配合 globalThis 读取+清理，可实现模块内安全使用；
- ✅ 封装 wrapper 模块是最符合工程规范的解法，清晰、可维护、支持类型推导与构建工具优化；
- ⚠️ 避免向 globalThis 写入临时对象（如 exports），除非明确控制生命周期。
最终目标不是“绕过模块系统”，而是尊重模块边界，将遗留代码桥接进现代模块生态。
