可复用性在于明确约束下保持最小必要抽象。函数应分离稳定逻辑与可变行为，用高阶函数或回调封装变化点；组件需纯函数化、单向数据流、显式依赖；避免隐式状态、过度配置和假复用。

JavaScript 中所谓“可复用”，不是写得越通用越好，而是**在明确约束下保持最小必要抽象**。盲目追求复用反而导致参数爆炸、逻辑耦合、调试困难。

函数设计：只暴露真正需要变化的参数

一个函数是否可复用，取决于它是否把「稳定逻辑」和「可变行为」清晰分离。常见错误是把所有可能的分支都塞进一个函数，靠一堆布尔参数控制流程。

• ✅ 正确做法：用高阶函数或回调封装变化点，比如 map、filter 的第二个参数是 callback，而不是 if (type === 'number') {...} else if (type === 'string') {...}
• ❌ 错误示例：formatData(data, type, locale, shouldCapitalize, fallback) —— 5 个参数，其中 3 个只在特定场景用，调用时总要查文档
• 性能提示：避免在函数体内重复创建闭包或正则（如 new RegExp(pattern)），应提前定义为常量或缓存

组件封装：用纯函数 + props 约束边界

即使不用 React，也可以用纯 JavaScript 写可复用 UI 组件。关键是把 DOM 操作收口，把数据流限定为单向输入输出。

• 组件本质是一个接受 props、返回 HTMLElement 或渲染副作用的函数，例如：createButton({ label, onClick, size = 'medium' })
• 不要在组件内直接读取 localStorage 或发起网络请求 —— 这些应由调用方传入（作为 onLoad 回调或 fetcher 函数）
• 兼容性注意：若需支持旧浏览器，避免使用 class 语法或可选链；用 Object.assign({}, defaults, props) 替代展开运算符做浅合并

避免“假复用”：警惕过度配置与隐式依赖

很多所谓“通用组件”实际只是把业务逻辑藏得更深，调用方反而更难理解它的行为。

• 检查你的函数是否悄悄依赖全局状态（如 window.config、document.body）—— 这会让单元测试失效，也阻碍 SSR
• 如果一个函数

  

  必须配合某个 CSS 类名才能正常工作，那就不是真复用，而是“模板片段”；应把样式逻辑显式声明为 className 参数或通过 CSSStyleSheet 注入
• 命名即契约：debounce 就该只做防抖，不该顺带处理 cancel 后的清理逻辑；否则别人调用时会误以为它自动管理生命周期

真正的复用性，往往体现在删掉一半代码后还能跑通，而不是堆满注释和配置项后勉强可用。