原型式继承本质是基于原型链的对象复用机制，非函数式编程范式；它依赖__proto__和动态委托查找，易导致共享可变状态，违背函数式纯函数、不可变性原则；实践中应仅将原型作为只读方法容器，状态须在实例自身创建，或改用工厂函数+对象展开实现安全复用。
原型式继承本身不属于函数式编程范式，它本质上是 JavaScript 面向对象机制中一种基于对象复用的继承模式，核心依赖 __proto__ 或 Object.setPrototypeOf 和原型链查找，与“不可变数据”“纯函数”“无副作用”等函数式编程原则并不天然契合。但若在函数式风格的代码中使用原型式继承，关键在于：不破坏函数式约束的前提下，仅把原型作为**只读共享行为的载体**，而非可变状态的容器。
原型式继承如何避开命令式陷阱
函数式编程强调避免共享可变状态。而原型式继承若直接复用含引用类型（如数组、对象）的原型对象，就会导致多个实例意外共享同一份数据——这明显违背函数式精神。所以实践中需主动规避：
- 原型上只放纯函数方法（如
map、filter的封装逻辑），不存name、items等实例状态 - 所有状态都由构造函数或工厂函数在实例自身上创建（即用
this.items = [...]而非从原型继承一个items: []） - 若需复用逻辑，优先用高阶函数或函数组合（如
compose(log, validate, save)），而不是靠原型链查找方法
用纯函数模拟“原型式复用”效果
真正贴近函数式思想的做法，是放弃 new 和 prototype，改用工厂函数 + 对象展开，实现类似原型继承的“行为复用”：
const baseBehaviors = {<br> log: (msg) => console.log(`[LOG] ${msg}`),<br> isValid: (x) => typeof x === 'number' && x > 0<br>};<br><br>const createUser = (name, age) => ({<br> name,<br> age,<br> ...baseBehaviors // 浅拷贝行为，无原型链，无共享风险<br>});<br><br>const u1 = createUser('Alice', 30);<br>const u2 = createUser('Bob', 25);<br>u1.log('active'); // [LOG] active<br>u2.isValid(42); // true
这种方式不依赖原型链，每个对象独立拥有方法副本（或通过闭包共享纯函数），完全可控、无隐式共享，更符合函数式对确定性和隔离性的要求。
为什么不能把原型链当“函数式继承”来用
原型链的本质是动态委托查找，运行时才决定调用哪个方法——这带来不确定性；而函数式偏好显式、静态、可推导的行为组合。更重要的是：
- 无法保证方法是纯函数（原型上的方法可能修改
this或外部变量） - 继承关系隐藏在
__proto__中，难以做类型推导或编译期检查 - 与不可变更新（如用
immer或结构共享）不兼容，因为原型链修改会影响所有下游对象
所以，在严肃的函数式项目（如用 Ramda、Redux、Elm 风格架构）中，几乎不会看到原型式继承的身影——它被更清晰、更可控的组合（composition）、柯里化（currying）和代数数据类型（ADT）所替代。
