javascript类型判定本身不是设计模式的直接应用场景，但策略模式用于按类型选择处理逻辑，工厂模式用于按类型创建适配对象，装饰器模式用于运行时增强类型行为，状态模式用于类型即状态的场景。
JavaScript 类型判定本身不是设计模式的直接应用场景，但围绕类型检查、类型分发和类型适配，开发者常借用几种经典设计模式来组织逻辑、提升可维护性与扩展性。关键不在于“判定类型”，而在于“如何根据类型做不同处理”——这正是模式发力的地方。
策略模式：按类型选择处理逻辑
当需要对不同数据类型（如 string、array、object、date、null）执行差异化操作时，策略模式最自然。它把每种类型的处理逻辑封装成独立函数或类，主流程只负责匹配和调用。
- 定义一组策略函数，如
handleString、handleArray、handleDate - 用
typeof+Object.prototype.toString.call()精准识别类型 - 主函数根据判定结果查表调用对应策略，新增类型只需加策略，不改主干
工厂模式：按类型创建适配对象
类型判定后常需生成特定实例（如将原始值转为可操作的包装器），工厂模式能解耦“判什么”和“造什么”。
- 输入一个值，先判定其类型（例如是
URL实例还是字符串） - 工厂返回统一接口的对象（如
UrlWrapper或StringWrapper），内部行为因类型而异 - 调用方只关心接口方法（如
.normalize()），无需重复写 if/else 分支
装饰器模式：在运行时增强类型行为
对已有对象按类型动态添加能力（如给数组加链式方法、给数字加精度控制），装饰器避免侵入原对象，也绕过硬编码类型分支。
- 用
Proxy或高阶函数包裹目标值，拦截访问并注入类型相关逻辑 - 例如：
decorate(123.456, 'number')返回带.toFixedSafe()的代理对象 - 判定发生在装饰阶段，后续使用完全透明，逻辑复用率高
状态模式：类型即状态，行为随类型切换
适用于类型间存在明确流转关系的场景（如解析器中 token 类型决定下一步动作），把每种类型当作一个状态类，由上下文委托执行。
- 定义
StringState、NumberState、NullState等，各自实现process() - 上下文持有当前状态引用，判定类型后切换状态实例
- 避免深层嵌套判断，状态变更清晰，易于单元测试
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
