可复用性在于明确约束下保持最小必要抽象。函数应分离稳定逻辑与可变行为，用高阶函数或回调封装变化点；组件需纯函数化、单向数据流、显式依赖；避免隐式状态、过度配置和假复用。
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)替代展开运算符做浅合并
避免“假复用”：警惕过度配置与隐式依赖
很多所谓“通用组件”实际只是把业务逻辑藏得更深，调用方反而更难理解它的行为。
立即学习“Java免费学习笔记（深入）”；
- 检查你的函数是否悄悄依赖全局状态（如
window.config、document.body）—— 这会让单元测试失效，也阻碍 SSR - 如果一个函数必须配合某个 CSS 类名才能正常工作，那就不是真复用，而是“模板片段”；应把样式逻辑显式声明为
className参数或通过CSSStyleSheet注入 - 命名即契约：
debounce就该只做防抖，不该顺带处理cancel后的清理逻辑；否则别人调用时会误以为它自动管理生命周期
真正的复用性，往往体现在删掉一半代码后还能跑通，而不是堆满注释和配置项后勉强可用。
