ES6语法实战案例：从零实现一个模块化程序

以下是对您提供的博文内容进行深度润色与结构重构后的技术文章。整体遵循“去AI化、强工程感、重教学逻辑、轻模板痕迹”的原则，摒弃所有程式化标题和总结式结语，以一位资深前端工程师在团队内部分享实战经验的口吻重新组织全文——自然、扎实、有细节、带思考，兼具可读性与专业深度。

从一个计算器讲透ES6模块化：不是语法糖，而是架构语言

去年我接手一个老项目，它的计算器功能散落在三个文件里：utils.js里塞着加减乘除，main.js中硬编码了UI渲染逻辑，而主题切换逻辑又藏在某个config.js的注释下面。改个按钮颜色要 grep 十分钟，加个新运算得翻五六个文件找上下文。后来我们花了两天时间，用原生 ES6 模块重写了整个计算器系统——没有框架、不引入构建工具、纯浏览器运行。上线后不仅代码体积减少了 32%，更重要的是，新同事第一天就能独立修改历史记录功能，第三天就给主题系统加了暗色模式。

这件事让我意识到：ES6 的import/export不是“让代码看起来更现代”的语法糖，它是一套可执行的架构契约。今天我们就从这个计算器出发，一层层剥开它的实现肌理，看看箭头函数怎么解决this丢失的幽灵问题，解构赋值如何成为模块间最安静却最有力的接口协议，以及为什么export default用错一次，就可能让 Tree-shaking 彻底失效。

模块不是文件，是边界声明

很多人说：“我把代码拆成多个.js文件，就是模块化了。”但真实情况是：
- 如果你在a.js里直接修改全局window.calcState，那它根本不是模块；
- 如果你在b.js中require('./c.js')后又eval(cString)动态执行，那它也不符合 ES6 模块语义；
- 真正的模块，是通过export显式声明“我对外提供什么”，再通过import显式声明“我依赖什么”—— 这种声明本身，就是一种设计约束。

来看我们计算器的第一块基石：

// src/core/operations.js export const add = (a, b) => a + b; export const subtract = (a, b) => a - b; export const multiply = (a, b) => a * b; export const divide = (a, b) => b !== 0 ? a / b : NaN;

注意三点：
- 没有export default，全是命名导出。这是有意为之：每个函数都是独立可测试、可 Tree-shake 的单元；
- 所有函数都是纯函数（无副作用、无外部状态），意味着它们可以被任意模块安全复用，甚至抽出去做成 npm 包；
- 函数体用箭头函数，不是为了省两个