SolidJS createMemo为什么不适合执行副作用

SolidJS 的 createMemo 不适合执行副作用，因为它负责计算和缓存一个只读派生值，回调应保持纯计算，不修改其他响应式状态。请求、写入存储、操作外部对象等动作如果混入 memo，会把“值的依赖关系”变成难以控制的反馈关系。跟随状态同步外部系统用 createEffect；只在用户点击时发生的操作放到事件处理器。

官方文档地址：https://docs.solidjs.com/

如果让我设计一个报价预览组件，我会先把“算出报价”和“把报价同步到外部”分开。下面是这种取舍的说明性代码，不是一次已执行的项目复盘；范围限定为 solid-js 当前官方文档中的基础响应式 API 和普通客户端组件，不讨论实验接口或 SolidStart 的数据提交流程。

报价预览需要的是值，不是执行次数

假设 unitPrice 是单价，quantity 是数量，total 是合计。页面两个位置都需要 total，把计算放进 memo 后，消费者读取的是派生结果，无需各自重复乘法。这个例子的乘法本身很便宜，采用 memo 主要是演示共享派生值；不能据此宣称组件获得了某个比例的性能提升。

我最在意的约束是：total 必须能够由输入说明，不能暗中发请求或改变 quantity。这样显示区、外部同步和用户提交各自都有清楚的入口，不必追查“读一次值是否做了一次保存”。

memo 的缓存规则不是业务事件规则

createMemo 返回访问器函数，调用它取得缓存值。依赖变化会触发重新计算，默认以严格相等判断新旧结果，相等时不通知下游。其回调第一次计算初始值，不是必须有人点击或首次读取后才执行。官方 createMemo 参考 明确要求回调不要修改其他响应式值。

因此不能把“memo 重新计算”解释成“用户完成了一次操作”，也不能把“下游没有更新”解释成“源输入没有变化”。例如输入字符串从“ A ”变成“A”，一个去除首尾空格的 memo 可能仍然得到相同结果，依赖它的 effect 就不必因为这个结果重新同步。

我会按动作目的比较三种方案

对我来说，最不值得保留的写法是“为了得到 total，先在 effect 里 setTotal”。如果 total 完全由单价和数量决定，额外的 total signal 就多了一份需要同步的状态。官方 Memos 概念说明 也建议把派生状态保留在 memo 中，而不是靠 effect 更新另一份派生状态。

相反，浏览器标签标题不属于报价计算的返回值，把它放到单独的 effect 比塞进 memo 更容易解释。这只是外部同步的演示；真正的保存动作仍应由业务明确决定。

把纯计算和外部同步放在不同位置

下面是一个可放进已有 Solid 项目的 TSX 组件。输入事件只接受有限、非负的数量；总金额用整数分表示，避免示例引入小数金额运算。它不包含网络提交。

import { createEffect, createMemo, createSignal, onCleanup } from "solid-js";

export default function QuotePreview() {
  const [unitPrice] = createSignal(1250);
  const [quantity, setQuantity] = createSignal(2);
  // memo 只计算整数分合计，不写状态、不操作浏览器
  const total = createMemo(() => unitPrice() * quantity());
  let previousTitle: string | undefined;

  createEffect(() => {
    const amount = total();
    // 外部同步留在 effect；守卫避免意外访问非浏览器环境
    if (typeof document === "undefined") return;
    previousTitle ??= document.title;
    document.title = "报价预览：" + amount + "分";
  });

  // 此清理注册在组件作用域，仅用于组件卸载时恢复标题
  onCleanup(() => {
    if (typeof document !== "undefined" && previousTitle !== undefined) {
      document.title = previousTitle;
    }
  });

  return (
    
 {
          const next = event.currentTarget.valueAsNumber;
          // 非法输入不写入状态，数量取整数
          if (Number.isFinite(next) && next >= 0) {
            setQuantity(Math.floor(next));
          }
        }} />
      
合计：{total()} 分
      
预览合计：{total()} 分
  );
}

这段代码里，total 的职责只有计算；createEffect 读取 total 并设置 document.title；onCleanup 负责恢复组件接管前的标题。组件中两个显示位置读取同一个 total 访问器。参考 createEffect 文档，普通 effect 的首次执行在当前渲染阶段结束后安排，同一更新周期中的纯计算先于 effect；多个 effect 之间的顺序不能作为业务承诺。

示例假定只有这个组件管理页面标题。多个组件或路由同时管理标题时，直接恢复 previousTitle 可能覆盖别人的标题，应交给统一的标题管理机制。客户端例子也不是 SSR 标题方案，不能依赖 createEffect 生成服务端页面的标题。

换成 effect 以后，仍要留意反馈和清理

我不会把“副作用移到 effect”理解成问题全部消失。effect 如果读取 quantity 又持续改写 quantity，仍可能制造反馈；日志函数、辅助函数若读取更多响应式值，也可能扩大订阅范围。能够直接派生的值尽量返回，不另外写入一份 signal。

相等判断也要讲清：memo 内部的动作若已经执行，结果相等只影响下游通知，不会撤销那个动作。把 equals 设置成 false 会改变传播策略，不能让请求或存储写入自动变得可靠，也不是修复不纯 memo 的办法。

若 effect 建立定时器、订阅或监听器，就需要对应释放。onCleanup 官方说明 区分了组件卸载清理和跟踪作用域刷新清理：注册在 effect 内的清理会随该作用域重新执行或销毁而运行，注册在组件中的清理服务于组件卸载。不要把注册位置当成无关细节。

我采用这套拆分时会观察什么

• memo 回调是否只读输入并返回值，没有 setter、请求或持久化写入。
• 展示消费者是否直接读取派生访问器，没有维护第二份 total 状态。
• 外部同步是否允许初始化时发生，失败如何反馈。
• 用户保存是否由明确事件触发，而不是依赖 memo 重算次数。
• 订阅和外部资源是否有匹配的释放位置。
• 全局对象是否有多组件竞争，是否需要统一管理。

读者接入示例后可修改 quantity，观察两处展示与标签标题；也可临时移除标题 effect，确认合计本身仍可独立使用。这些是建议的观察项，不是本文提供的实测结果。

只是加一条 console.log，也算副作用吗？

算，但调试日志和业务请求的风险不同。排查时短暂日志可以帮助理解计算，不能让业务正确性依赖日志次数，也不应把调试动作当成 memo 的永久职责。

createMemo 回调能写入另一个 signal 吗？

语言层面可能写得出来，但违背 memo 的纯计算约束，并可能引入反馈或难以理解的依赖。先判断该值是否可以直接作为 memo 返回值；不能派生的外部动作再单独安排。

所有计算都必须使用 memo 吗？

不是。简单、低成本、很少读取的派生函数可以足够。需要共享缓存、减少重复计算或利用结果相等抑制传播时，memo 更有价值，但它仍然是值节点，而不是副作用执行器。

我的取舍是让职责保持可解释：输入维护源状态，memo 提供派生值，effect 同步外部对象，事件表达用户意图。多一个职责层不一定多很多代码，却能避免把缓存语义和业务动作绑在一起。