嵌入式浏览器模块化优化核心是让模块边界“可识别、可裁剪、可延迟”：强制使用ESM语法、显式声明sideEffects、禁用动态导入与CommonJS转换、按硬件能力分级拆分模块、构建时固化依赖图并排除预置库。
在嵌入式浏览器（如车载系统、智能电视、IoT设备等资源受限环境）中，JavaScript模块化本身不是问题，但默认打包方式容易导致模块边界模糊、冗余代码无法剔除、首屏加载卡顿。优化核心是让模块边界“可识别、可裁剪、可延迟”，而非简单套用桌面端策略。
明确模块导出与副作用声明
嵌入式环境通常内存小、解析慢，Tree Shaking失效会直接放大体积负担。必须确保每个模块的“可摇性”：
- 所有业务模块使用 ESM 语法（
export/import），禁用require()或动态字符串导入（如eval('import(...)')） - 在
package.json中显式声明"sideEffects": false；若含 CSS、字体或全局 patch，只列出具体文件路径（如["*.css", "src/init.js"]），避免整包保留 - 检查第三方库是否提供 ESM 入口：查看其
package.json是否有"module"字段；优先选用lodash-es、dayjs/esm等原生 ESM 版本
强制模块物理隔离与静态分析友好
嵌入式 JS 引擎（如 QuickJS、JerryScript 或定制 V8 子集）对动态特性支持有限，需规避运行时决定模块结构的行为：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 禁用 Babel 的
transform-modules-commonjs插件，防止将 ESM 转为 require —— 这会彻底破坏 Tree Shaking - 避免在模块顶层执行副作用逻辑（如直接调用 API、修改
Array.prototype），否则该模块会被整块保留 - 用
/*#__PURE__*/标注纯函数调用，辅助 Terser 在压缩阶段识别并移除未被引用的表达式
按能力分级拆分模块边界
不追求“路由级懒加载”，而按硬件能力与用户路径做更粗粒度、更确定的模块切分：
立即学习“Java免费学习笔记（深入）”；
- 将功能划分为 必需层（基础 UI 渲染、事件总线）、可选层（图表、音视频解码）、降级层（离线缓存、本地数据库），各自打包为独立 entry
- 用
import('./feature.js')+try/catch实现降级加载：若模块加载失败（如内存不足报RangeError: Maximum call stack size exceeded），自动 fallback 到轻量替代逻辑 - 对高频交互模块（如遥控器方向键响应）单独提取为
inline模块（通过构建插件内联到主 bundle），避免额外请求开销
构建时固化模块依赖图
嵌入式设备通常无网络或带宽极低，无法依赖 CDN 或 HTTP/2 多路复用，需在构建阶段就锁定最小依赖子图：
- 用
vite-plugin-analyzer或source-map-explorer输出模块引用关系树，人工确认是否存在跨模块循环引用 —— 这类引用在弱引擎上易引发解析死锁 - 对稳定第三方模块（如
zlib.min.js解压库）通过externals排除打包，由设备固件预置并挂载到全局（如window.zlib），构建时仅保留类型声明 - 启用
build.rollupOptions.treeshake.moduleSideEffects为false，关闭 Rollup 对模块副作用的保守假设，提升摇树激进度
