JavaScript函数本质是行为契约而非功能封装，需明确“谁调用、给什么、要什么”三问，确保无隐式依赖、参数清晰、返回稳定；纯函数优先，副作用集中，模块化重在依赖可见而非简单拆文件。

JavaScript 函数不是“功能封装”而是行为契约

函数在 JavaScript 中本质是 Function 类型的对象，可被赋值、传参、返回，甚至动态构造。所谓“可复用”，关键不在于代码是否重复使用，而在于它是否明确表达了「输入 → 处理 → 输出」的契约关系。没契约的函数，哪怕写了十遍 utils.js，照样一改全崩。

写函数前先问清三个问题：谁调用？给什么？要什么？

很多函数不可复用，是因为默认绑定了调用上下文（比如 this）、隐式依赖全局变量、或返回值类型模糊。真正可复用的函数必须能脱离当前文件/作用域独立运行。

• 谁调用？ → 避免依赖 this 或闭包外的变量；若需上下文，显式传入对象（如 formatDate(date, options) 而非 date.format()）
• 给什么？ → 参数尽量扁平、命名直白；避免靠位置猜含义（如 transform(data, true, false, 'en')），改用对象解构：transform(data, { deep: true, strict: false, locale: 'en' })
• 要什么？ → 返回值类型稳定，不因参数微小变化而从 string 变成 null 或 undefined；必要时用 throw new Error('...') 明确失败边界，而不是静默返回错误值

模块化 ≠ 拆文件，而是控制副作用和依赖可见性

把一堆函数塞进 helpers.js 并不等于模块化。真正的模块化是让每个函数的依赖和副作用都“看得见、管得住”。ESM 的 export 不是打包出口，而是接口声明。

export function clamp(value, min, max) {
  if (typeof value !== 'number' || typeof min !== 'number' || typeof max !== 'number') {
    throw new TypeError('clamp: all arguments must be numbers');
  }
  return Math.min(Math.max(value, min), max);
}

// ✅ 可单独测试、可 Tree-shaking、无副作用、无外部依赖
// ❌ 不读 localStorage，不修改传入对象，不 console.log

• 纯函数优先：相同输入永远返回相同输出，且不修改外部状态
• 副作用集中处理：如需发请求、读本地存储，单独抽成 fetchUser(id) 这类明确命名的函数，不要混在 formatUser(user) 里
• 避免默认导出（export default）：它掩盖了模块的接口结构，不利于类型推导和静态分析

常见陷阱：看似可复用，实则暗藏耦合

这些写法在单个项目里跑得通，但一旦跨项目或换人维护，就会暴露问题：

• localStorage.getItem('theme') 写在工具函数里 → 把浏览器环境硬编码进逻辑
• return data.map(item => ({ ...item, id: item._id })) → 假设所有后端都用 _id，实际可能是 uuid、pk、objectId
• function formatDate(date) { return new Date(date).toLocaleDateString('zh-CN'); } → 语言固化、时区未指定、Date 构造失败时静默返回 Invalid Date

可复用性的成本不在写代码时，而在别人想改你函数的时候——如果他必须翻三遍源码才能搞清参数怎么来、错误怎么报、边界在哪，那这个函数已经失败了。