用动态规划思路，一步一步实现响应式数据（从本质到落地）

文章目录

用动态规划思路，一步一步实现响应式数据（从本质到落地）
- 一、第一步：用动态规划逆向思维，拆解响应式的"最终目标"
- - [1. 最终目标（fn）：数据变化 → 依赖该数据的函数自动执行](#1. 最终目标（fn）：数据变化 → 依赖该数据的函数自动执行)
  - [2. 倒推第一个前置依赖（dep1(fn)）：需要知道"哪些函数依赖了该数据"](#2. 倒推第一个前置依赖（dep1(fn)）：需要知道“哪些函数依赖了该数据”)
  - [3. 倒推第二个前置依赖（dep2(dep1)）：需要能"拦截数据的读写操作"](#3. 倒推第二个前置依赖（dep2(dep1)）：需要能“拦截数据的读写操作”)
  - [4. 倒推第三个前置依赖（dep3(dep2)）：需要能"标记当前正在执行的依赖函数"](#4. 倒推第三个前置依赖（dep3(dep2)）：需要能“标记当前正在执行的依赖函数”)
  - [5. 梳理完整的逆向拆解链路（动态规划核心）](#5. 梳理完整的逆向拆解链路（动态规划核心）)
- 二、第二步：按拆解链路，逐步实现响应式（从底层到上层）
- - [1. 实现子问题3：标记当前活跃的依赖函数（全局标记）](#1. 实现子问题3：标记当前活跃的依赖函数（全局标记）)
  - [2. 实现子问题2：数据读写拦截（Proxy）](#2. 实现子问题2：数据读写拦截（Proxy）)
  - [3. 实现子问题1：依赖收集与触发（整合上面两步）](#3. 实现子问题1：依赖收集与触发（整合上面两步）)
  - [4. 实现最终目标：完整响应式效果](#4. 实现最终目标：完整响应式效果)
- 三、第三步：升华：动态规划思维的通用价值（不止于响应式）
- - 对比两种开发思路，你就懂了差距：
  - 核心总结（必记）
- 四、最后：给初学者的建议

前言：提到响应式数据，大家第一反应往往是Vue的Proxy、React的useState，或是Object.defineProperty这类API的应用。但很少有人会把「动态规划」和「响应式实现」联系起来。今天就和大家分享一个不一样的视角------用动态规划的逆向思维，从"最终效果"倒推，一步一步拆解响应式的实现逻辑，让你不仅能写出可运行的代码，更能看透响应式的本质，再也不用死记硬背API用法。

先澄清两个核心认知，避免走偏：

动态规划不是"算法题专属"：它的核心是「将复杂问题拆解为重叠子问题，通过解决子问题实现最终目标」，本质是一种"由果溯因、层层拆解"的思维方式，适用于所有复杂功能的设计（包括响应式）；
响应式的本质不是"数据劫持"：数据劫持（Proxy/Object.defineProperty）只是实现手段，响应式的核心是「数据变化 → 依赖该数据的函数自动执行」，这也是我们要实现的"最终效果"。

今天我们全程围绕「动态规划逆向思维」展开，核心公式就是咱们今天推导的：impl(fn) = impl(dep(fn))（想要实现最终效果fn，必须先实现它的前置依赖dep(fn)）。

一、第一步：用动态规划逆向思维，拆解响应式的"最终目标"

动态规划的核心思路是「先锁定最终目标，再倒推前置条件」，我们先明确响应式的"最终目标"，再一步步拆解它的"子问题"（前置依赖）。

1. 最终目标（fn）：数据变化 → 依赖该数据的函数自动执行

举个直观的例子：定义一个响应式数据obj，有一个函数render（用于渲染视图）依赖obj.name，当obj.name修改时，render函数能自动重新执行，不用手动调用------这就是我们要实现的最终效果。

用伪代码表示就是：

javascript 复制代码

// 响应式数据
const obj = reactive({ name: "张三" });
// 依赖数据的函数（副作用函数）
function render() {
  console.log("视图更新：", obj.name);
}
// 执行一次，触发依赖收集
render(); // 输出：视图更新：张三
// 修改数据，自动触发render重新执行
obj.name = "李四"; // 自动输出：视图更新：李四

2. 倒推第一个前置依赖（dep1(fn)）：需要知道"哪些函数依赖了该数据"

要实现"数据变化 → 函数自动执行"，首先要解决一个问题：数据变化时，到底要执行哪些函数？

这就是第一个子问题（前置依赖）：我们需要一个"依赖收集"机制，记录「某个数据 → 依赖它的所有函数」的映射关系。比如obj.name对应的依赖函数是render，当obj.name变化时，我们能找到这个映射，然后执行render。

这里可以类比动态规划的"状态存储"：我们需要一个容器，存储每个数据的依赖列表，就像DP表存储子问题的解一样，后续直接复用这个"依赖映射"，避免重复判断。

3. 倒推第二个前置依赖（dep2(dep1)）：需要能"拦截数据的读写操作"

要实现"依赖收集"，又需要解决一个子问题：什么时候收集依赖？什么时候触发依赖执行？

答案很明确：

当「读取数据」时（比如render函数中访问obj.name），触发依赖收集，把当前执行的函数（render）加入该数据的依赖列表；
当「修改数据」时（比如obj.name = "李四"），触发依赖执行，遍历该数据的依赖列表，执行所有依赖函数。

要实现"拦截读写"，在JavaScript中，我们可以用ES6的Proxy（推荐，支持对象、数组等所有引用类型），替代Vue2的Object.defineProperty（仅支持对象，有局限性），它能拦截对象的get（读取）、set（修改）等操作，这是实现依赖收集和触发更新的技术基础。

4. 倒推第三个前置依赖（dep3(dep2)）：需要能"标记当前正在执行的依赖函数"

拦截到get操作时，我们需要知道"当前正在执行的函数是什么"，才能把它加入依赖列表。比如render函数执行时，访问obj.name，此时当前正在执行的函数是render，我们就把render加入obj.name的依赖列表。

这就需要一个全局标记（类似动态规划的"状态变量"），用于记录"当前活跃的依赖函数"------当函数开始执行时，把它赋值给这个全局标记；当函数执行结束时，清空标记，避免误收集无关函数。

5. 梳理完整的逆向拆解链路（动态规划核心）

到这里，我们用动态规划逆向思维，拆解出了响应式实现的完整依赖链路（从最终目标到最底层子问题）：

实现「数据变化→函数自动执行」（最终目标）

→ 必须先实现「依赖收集与触发」（子问题1）

→ 必须先实现「数据读写拦截」（子问题2）

→ 必须先实现「当前活跃函数标记」（子问题3）

这个链路，和我们今天推导"参数默认值区分"的思路完全一致------都是"由果溯因，层层拆解"，先解决最底层的子问题，再往上拼装，最终实现最终目标。这也是动态规划思维的核心价值：不盲目堆砌代码，而是有逻辑、有步骤地拆解问题，让每个环节都有明确的目标。

二、第二步：按拆解链路，逐步实现响应式（从底层到上层）

动态规划的实现思路是"先解决子问题，再拼装最终解"，我们按照上面的拆解链路，从最底层的"活跃函数标记"开始，一步步实现完整的响应式逻辑，每一步都对应一个子问题的解决。

1. 实现子问题3：标记当前活跃的依赖函数（全局标记）

定义一个全局变量，用于存储当前正在执行的依赖函数（副作用函数），再封装一个watchEffect函数，用于执行副作用函数并标记活跃状态------这一步对应动态规划中"初始化状态变量"。

javascript 复制代码

// 全局标记：当前正在执行的副作用函数（依赖函数）
let activeEffect = null;

// 执行副作用函数，并标记活跃状态
function watchEffect(effect) {
  // 标记当前活跃函数
  activeEffect = effect;
  // 执行函数（会触发数据读取，进而触发依赖收集）
  effect();
  // 函数执行完毕，清空标记，避免误收集
  activeEffect = null;
}

2. 实现子问题2：数据读写拦截（Proxy）

用Proxy创建对象的代理，拦截get（读取）和set（修改）操作，为后续的依赖收集和触发更新做准备。这里我们会用到"依赖容器"（Dep类），用于存储每个数据的依赖列表------这一步对应动态规划中"存储子问题解"。

javascript 复制代码

// 依赖容器：管理某个数据的所有依赖函数（对应动态规划的DP表）
class Dep {
  constructor() {
    // 用Set存储依赖函数，避免重复
    this.subscribers = new Set();
  }

  // 收集依赖：将当前活跃函数加入依赖列表
  depend() {
    if (activeEffect) {
      this.subscribers.add(activeEffect);
    }
  }

  // 触发依赖：遍历依赖列表，执行所有依赖函数
  notify() {
    this.subscribers.forEach((effect) => effect());
  }
}

// 数据读写拦截：创建响应式对象（Proxy代理）
function reactive(target) {
  // 存储"数据属性 → 依赖容器"的映射（每个属性对应一个Dep实例）
  const depsMap = new Map();

  return new Proxy(target, {
    // 拦截读取操作：收集依赖
    get(target, key) {
      // 1. 为当前属性获取/创建依赖容器
      let dep = depsMap.get(key);
      if (!dep) {
        dep = new Dep();
        depsMap.set(key, dep);
      }
      // 2. 收集当前活跃的依赖函数
      dep.depend();
      // 3. 返回原始属性值（用Reflect保证this指向正确）
      return Reflect.get(target, key);
    },

    // 拦截修改操作：触发依赖
    set(target, key, value) {
      // 1. 修改原始属性值
      Reflect.set(target, key, value);
      // 2. 获取当前属性的依赖容器，触发所有依赖函数
      const dep = depsMap.get(key);
      if (dep) {
        dep.notify();
      }
      return true;
    },
  });
}

这里有两个关键细节，和动态规划的思想高度契合：

Dep类：相当于动态规划的"DP表"，存储每个子问题（数据依赖）的解（依赖函数列表），后续修改数据时，直接复用这个列表，不用重新收集；
depsMap：用于映射"属性→Dep实例"，避免不同属性的依赖混淆，相当于动态规划中"划分不同子问题的边界"，确保每个子问题的解独立存储、互不干扰。

3. 实现子问题1：依赖收集与触发（整合上面两步）

到这里，我们已经解决了所有底层子问题，现在只需要整合起来，就能实现"依赖收集"和"触发更新"------这一步对应动态规划中"子问题解的拼装"。

我们用一个完整的示例，验证依赖收集和触发的效果：

javascript 复制代码

// 1. 创建响应式数据（子问题2：读写拦截）
const obj = reactive({ name: "张三", age: 20 });

// 2. 定义副作用函数，用watchEffect标记活跃状态（子问题3）
watchEffect(() => {
  console.log("视图更新：", obj.name, obj.age);
});
// 执行结果：视图更新：张三 20（此时已完成依赖收集：obj.name和obj.age的依赖都是这个箭头函数）

// 3. 修改数据，触发依赖执行（子问题1）
obj.name = "李四";
// 自动输出：视图更新：李四 20（依赖触发成功）

obj.age = 21;
// 自动输出：视图更新：李四 21（依赖触发成功）

4. 实现最终目标：完整响应式效果

整合上面所有代码，我们就实现了响应式的核心功能------数据变化时，依赖该数据的函数自动执行。而且我们的实现是通用的，支持多个副作用函数、多个响应式数据，完全贴合实际开发场景：

javascript 复制代码

// 多个副作用函数
watchEffect(() => {
  console.log("副作用1：", obj.name);
});
watchEffect(() => {
  console.log("副作用2：", obj.age);
});

// 修改obj.name，只触发依赖它的副作用函数
obj.name = "王五";
// 输出：副作用1：王五

// 修改obj.age，只触发依赖它的副作用函数
obj.age = 22;
// 输出：副作用2：22

这就是动态规划思维的威力：我们没有一开始就去写Proxy、写依赖容器，而是先拆解问题，解决每个底层子问题，再逐步拼装，最终实现最终目标。整个过程逻辑清晰，每个环节都有明确的目的，再也不用死记硬背响应式的实现流程。

三、第三步：升华：动态规划思维的通用价值（不止于响应式）

今天我们用动态规划的逆向思维实现了响应式，但这套思路的价值远不止于此------它适用于所有复杂功能的设计，比如我们今天一开始推导的"区分参数默认值"，还有防抖节流、组件封装、权限管理等，核心都是「由果溯因，层层拆解」。

对比两种开发思路，你就懂了差距：

常规思路（正向思维）：看到响应式，先想到Proxy/Object.defineProperty，然后盲目堆砌代码，写出来的代码逻辑混乱，遇到bug无从下手；
动态规划思路（逆向思维）：先锁定最终效果，再倒推每个前置依赖，解决每个子问题，代码逻辑清晰，可扩展性强，哪怕遇到bug，也能快速定位到某个子问题（比如依赖收集失败，就去检查get拦截和activeEffect标记）。

核心总结（必记）

响应式的本质：「数据变化 → 依赖函数自动执行」，数据劫持只是实现手段，依赖收集和触发才是核心；
动态规划的核心：「由果溯因，层层拆解」，将复杂问题拆解为可解决的子问题，再逐步拼装，适用于所有复杂功能的设计；
本次实现的核心链路：标记活跃函数 → 拦截数据读写 → 收集依赖/触发更新 → 实现响应式（完全遵循动态规划的子问题拆解与拼装思路）；
延伸思考：我们今天实现的是基础版响应式，Vue3的响应式还做了很多优化（比如懒代理、浅层响应式、避免内存泄漏等），但核心思路和我们今天推导的完全一致------都是用"子问题解决最终问题"的动态规划思维，大家可以在此基础上进一步扩展。

四、最后：给初学者的建议

很多初学者学响应式，只记API用法，却不懂底层逻辑，导致换个场景就废。其实，无论是响应式、算法题，还是实际开发中的复杂功能，最核心的不是"记住代码"，而是"掌握思维方式"。

动态规划的「逆向拆解」思维，就是一种"看透本质"的思维------它让你不再纠结于表面的API，而是深入到功能的底层，从最终目标出发，一步步拆解问题、解决问题。这种思维，比你背一百个API、记一百个框架用法，值钱一万倍。

大家可以试着用今天的思路，去拆解其他功能（比如防抖、节流），你会发现，很多看似复杂的功能，拆解成子问题后，都会变得非常简单。

后续我会继续分享用动态规划思维解决前端实际问题的案例，关注我，一起从"会写代码"变成"会设计代码"～

附：完整可运行代码（复制到浏览器控制台即可执行）

javascript 复制代码

// 全局标记：当前正在执行的副作用函数
let activeEffect = null;

// 执行副作用函数，并标记活跃状态
function watchEffect(effect) {
  activeEffect = effect;
  effect();
  activeEffect = null;
}

// 依赖容器：管理某个数据的所有依赖函数
class Dep {
  constructor() {
    this.subscribers = new Set();
  }

  // 收集依赖
  depend() {
    if (activeEffect) {
      this.subscribers.add(activeEffect);
    }
  }

  // 触发依赖
  notify() {
    this.subscribers.forEach((effect) => effect());
  }
}

// 创建响应式对象（Proxy代理）
function reactive(target) {
  const depsMap = new Map();
  return new Proxy(target, {
    get(target, key) {
      let dep = depsMap.get(key);
      if (!dep) {
        dep = new Dep();
        depsMap.set(key, dep);
      }
      dep.depend();
      return Reflect.get(target, key);
    },
    set(target, key, value) {
      Reflect.set(target, key, value);
      const dep = depsMap.get(key);
      if (dep) {
        dep.notify();
      }
      return true;
    },
  });
}

// 测试代码
const obj = reactive({ name: "张三", age: 20 });

watchEffect(() => {
  console.log("视图更新：", obj.name, obj.age);
});

obj.name = "李四";
obj.age = 21;