solid-js：响应式与组件

solid-js/store 与 solid-js/web

@solidjs/router 与 @solidjs/start

章节地图

一句话心智模型

• 组件函数只执行一次。JSX 长得和 React 一样，语义却相反：React 里它是「每次更新都重跑的渲染函数」，Solid 里它是「一次性的布线说明书」；
• 真正的更新单元是信号（createSignal），不是组件。版本基准 Solid 1.x，全栈元框架是 SolidStart；它的卖点从来不是生态，是运行时开销。

两步机制，推出三条反直觉规则

• 编译期把静态结构变成一个 HTML 模板字符串（运行时 clone 一次就完事），动态位置只留下一句 insert；运行时insert 判断参数是不是函数，是就用 createRenderEffect 包一层——这一句是整个框架的枢纽；
• 于是：读信号要调用（「更新」的实现就是重新调用那个函数）、props 不能解构（解构等于当场取值，读取时机丢了）、条件要用 <Show>（三元在布线时就把分支定死了）。

命令

模板名去掉 -ts 就是 JS 版，但建议直接上 TS——props 与信号的类型提示能挡掉不少响应性的坑（10 章）。

项目结构与关键文件

三条硬规则

判断方法只有一句：这个值是在「每次要用时」被读出来的，还是在「组件初始化那一次」被读出来的？后者就断了。

从 React 逐条翻译

签名

时机与特性

为什么「set 了没反应」

默认用 === 判断新旧值：同一个对象引用再 set 一次，什么都不会发生。改数组和对象要么换新引用（setList([…list(), x])），要么用 store，要么显式 { equals: false }。

读要调用，写有两种

• const [count, setCount] = createSignal(0)——count 是访问器函数，读值写 count()，不是 count。
• 写有两式——setCount(5) 直接设值；setCount(c => c + 1) 基于旧值更新。连续更新、或不确定当前值时，用函数式更稳。

为什么读是函数调用

• 正因为读是一次函数调用，Solid 才能在你读它的那一刻「记一笔」——谁读了我，谁就订阅了我。这套自动依赖收集是整个响应式的核心。写成裸变量就没有这个「读」的时机，也就无从追踪。

能装什么、初值怎么给

• 信号能装任何值——数字、字符串、布尔、对象、数组，甚至函数（存函数要包一层，见下方 tip）。createSignal() 不给初值时，初值是 undefined。
• 在响应式作用域外面读信号完全没问题（比如在事件处理函数里读一下当前值），只是那次读不建立依赖——依赖只在 effect、memo、JSX 这些追踪上下文里才会被收集。

lab 里跑过

• 实验台里 setCount(5) 后 count() 是 5，再 setCount(c => c + 1) 后是 6——函数式更新拿到的就是当前最新值。

自动、动态的依赖

• effect 体里读到哪个信号，就订阅哪个，无需 React 那样的依赖数组。而且依赖是动态的——每次重跑只订阅这一次实际读到的信号。if (a()) b() 里 a() 为假时，这轮就不订阅 b。

创建时先跑一次

• effect 创建时会立刻跑一次（在同步作用域结束时冲刷），目的是拿到初值、把依赖收集上——之后才靠依赖变化驱动重跑。这点和 React 的 useEffect 不同——它不需要依赖数组，也没有「只在挂载后跑」的空数组写法，依赖完全由「这一次读了谁」自动决定。

什么该进 effect

• 只放副作用——日志、订阅、手动操作 DOM、和外部系统同步。派生一个值别用 effect，那是 createMemo 的活（effect 没有返回值，产物也不能被别人追踪）。

缓存、依赖变即算、纯

• 缓存——只要依赖没变，多次读 total() 只计算一次，后续直接给缓存值。
• 只在依赖变时重算——price 或 qty 变了，才重新算一次。
• 必须是纯函数——只做计算、同步返回一个值，别在里面发请求或改 DOM（那是 effect 的活）。

和 effect 的关键区别

• createMemo 有返回值，且这个值能被别的 effect/memo 追踪；createEffect 没有返回值，是响应式的终点。要「A 变了自动算出 B、B 还要被别处用」，就用 memo，别用「effect 加一个额外信号」去凑。

和「写个普通函数」比

• 你当然可以写 const total = () => price() * qty()——但它每次被读都重算，自己也不是一个能被追踪的源。createMemo 多给两样东西——缓存（依赖没变就不重算）和信号身份（下游只在它的结果真的变了时才更新）。计算便宜、只读一次，普通函数就够；计算贵、或被多处读，才上 memo。

lab 里跑过

• 实验台里给 memo 的计算函数插桩——连读两次 total()，计算只发生一次；setQty 改依赖后立刻发生第二次计算（急切，不等你读它，哪怕没有下游在用），之后读到的是新缓存值。缓存与「依赖变才重算」都成立。

怎么选

• 要一个能改的状态源 → createSignal。
• 要从状态算出一个值、还可能被别处用 → createMemo。
• 状态变了要做点事、不产出值 → createEffect。

数据只往一个方向流

• 源 → 派生 → 出口——signal 喂给 memo，memo（或 signal）喂给 effect。别让 effect 回头去 set 上游 signal 制造环；需要「从 A 得 B」时，那是 memo 的职责。

用一个购物车串起来

• signal——price 和 qty 是用户能改的源。
• memo——total 从两个源派生，界面里多处（小计、结算按钮）都读它。
• effect——总价一变就上报埋点或写日志，这是不产出值的副作用。三者各就各位，数据从源一路流到出口，谁都不回头。

三条出路

• 建新对象——setObj(prev => ({ ...prev, count: prev.count + 1 }))，新引用，必触发。
• 用 Store——createStore 在属性级拦截读写，不靠整体引用相等，天生适合嵌套对象/数组（详见 06 章）。
• 关掉相等性——createSignal(v, { equals: false })，每次 set 都触发（连相同值也触发）。少用，适合「值语义上没变但就是要重跑」的场景。

lab 里跑过

• 实验台里对比过——默认信号 set 同引用，effect 不重跑；同一个对象换成 { equals: false } 的信号再 set，effect 重跑了。印证默认走 ===、equals:false 能强制触发。

控制追踪与冲刷

四种「副作用」的时机

它到底省了什么

• 实验台里放一个同时读 a() 和 b() 的 effect，再分别 setA(1)、setB(1)——effect 被冲刷两次；把这两次 set 包进 batch，effect 只跑一次。
• 省掉的就是那次「中间态」的重算：a 变了但 b 还没变时，没人真正需要那一版结果。

什么时候才真需要它

• 连着改好几个信号、又只想让下游冲刷一次时最有用。Solid 不会自动替你合并——无论是同步事件处理器，还是 await 之后、setTimeout / Promise.then 里，两次 set 就是两次冲刷（lab 合成事件与真实委托事件都不自动合并）。异步回调里尤其容易连改多个信号，手动 batch 最常用在那儿，能避免 UI 抖动和重复计算。
• 把「逻辑上属于同一次更新」的多个 set 圈在一起，语义也更清楚。

验证过的行为

• lab 里一个 effect 读 a()、又用 untrack(() => b()) 读 b：setB(5) 之后 effect 不重跑；setA(5) 才重跑。也就是说 b 只是被「顺便看了一眼」，没进依赖表。

典型用途

• effect 主要关心 a 的变化，但过程中需要读一下 b 的当前快照又不想被它触发——比如「a 变了就上报，顺带带上此刻的 b」。
• 写日志、埋点、和外部命令式库交互时，读些「参考值」但不想它们把 effect 拖着反复跑。
• 在 setter 里基于「别的信号的当前值」算新值，又不希望这个 effect 订阅那个信号时，untrack 正好断开这层依赖。

和 on 的分工

• untrack 是「减法」：默认全订阅，个别几个不想要就单独包一层。
• 本章后面的 on 是「加法」：默认谁都不订阅，只有点名的源才算依赖。想跳过一两个用 untrack，想只保留一两个用 on，按哪种更少来选。

它解决什么

• 普通 effect 是「读到什么就订阅什么」，有时会订阅到你不想要的信号。on 把依赖钉死成你指定的那几个，回调里再怎么读别的都不影响。
• 回调签名是 (值, 上一次的值) =>，天然能拿到 prev，做「变化前后对比」很方便。

defer：首次不跑

• 默认 effect 会立刻跑一次做初始化。加 { defer: true } 后，首次同步执行时跳过，只有依赖之后真的变了才第一次运行。
• lab on(x, fn, { defer: true }) 建好时 fn 没被调用；setX(2) 才第一次跑，setX(3) 时能拿到 prev 为 2。适合「初始值不用管，只在用户改动时才响应」的场景。

多个源

• 第一个参数传数组 on([a, b], …) 就能同时追踪多个源，回调收到的值也是数组 [aVal, bVal]，prev 同理。

不只配 effect

• on(…) 返回的就是个普通回调函数，除了 createEffect，也能交给 createMemo——让一个派生值只在指定源变化时才重算，回调的返回值就是 memo 的新值。
• 当你发现「这个 effect / memo 订阅到了不该订阅的信号」，把它改写成 on(真正的源, …) 往往是最直接的修法。

时序差在哪

• createEffect 的回调在初始那轮同步执行里被延迟，等所属作用域（render / createRoot）同步跑完才冲刷。lab 里在 createRoot 体内部读它的产物是 undefined。
• createComputed 与 createRenderEffect 则同步执行：lab 里在 root 体内部就能读到它们算出的结果。

它们各自的定位

• createComputed：立即、无缓存地跑，可以在里面写信号。它是最底层的计算原语，容易写出「A 改 B、B 改 A」的连锁更新，官方也建议普通开发别用。
• createRenderEffect：在渲染阶段同步跑，用于「DOM 提交前就要读写」的场合（如某些测量、第三方 DOM 库对接）。

坑长什么样

• lab 复现：obj.n = 1 之后 setO(obj) 传回同一个引用，effect 不重跑——因为 === 认定「没变」。这也是 02 章 === 陷阱的进阶版。
• 解法之一是每次都造新引用（setO(o => ({ ...o, n: o.n + 1 }))）；嵌套结构更推荐用 createStore（见 06 章），它在字段级拦截，不看整体引用。

用 equals 定制判定

• createSignal(v, { equals: false })：关掉相等性检查，每次 set 都通知——lab 里即便传回同一个对象引用，effect 也照样重跑。适合「就是要强制刷新」的场景。
• createSignal(v, { equals: (a, b) => … })：自定义「算不算变」。返回 true 表示「相等、别通知」。

memo 也能定制 equals

• createMemo(fn, 初值, { equals }) 第三个参数同样收 equals。lab 里给 memo 配 (a, b) => Math.floor(a) === Math.floor(b)：源从 0 变到 0.5 时 floor 没变，memo 判定「不变」，下游 effect 不跑；变到 1.2 才跑。用它可以把「无意义的小抖动」挡在下游之外。

属性与内容

事件

命名空间前缀

use: 的两个硬要求：指令函数签名是 (el, accessor) => void；指令名必须在当前文件里被静态引用，否则会被打包器摇掉（TS 项目还要做模块增强声明，10 章）。

lab 验证

• 一个 Counter 在函数体里 runs++，点两次按钮把数字从 0 加到 2 之后，runs 仍然是 1——更新只改了那个文本节点，函数一次都没重跑。
• 所以你可以放心在组件体里做「只该做一次」的事（建信号、订阅、算初值），不用像 React 那样担心它每次渲染都重来。

和 React 到底差在哪

编译成了什么

• React——<button>{c}</button> 变成 createElement("button", null, c)，产出虚拟 DOM 节点，更新时 diff 新旧虚拟树再打补丁。
• Solid——同样的 JSX 被编译成创建真实 DOM 元素的代码，把 {c()} 这类动态表达式单独包成一个响应式绑定。信号一变，就直接改那个绑定对应的 DOM，没有虚拟 DOM、没有 diff。

是谁在编译

• 裸 Vite 项目里是 vite-plugin-solid，它内部用 babel-preset-solid 把 JSX 转成上面那种 DOM 指令。所以 .jsx/.tsx 文件必须经过这个插件——用别的 JSX 转译器（比如默认的 esbuild JSX）会把它当 React 处理，整套响应式就废了。

这决定了那些规则

• 因为动态部分是编译期就分析出来的绑定，{count()} 必须直接出现在 JSX 里，编译器才能把它接进响应式图。这也是「解构 props 会断响应」的底层原因——解构发生在组件体里，编译器看不到，接不进图。

把产物真打出来看（本机 babel-preset-solid 实跑）

源码：

function Counter(props) {
  const [n, setN] = createSignal(0);
  return <div class="box">
    <span>{n()}</span>
    <button onClick={() => setN(n() + 1)}>{props.label}</button>
  </div>;
}

编译产物（原样，未删减）：

var _tmpl$ = _$template(`<div class=box><span></span><button>`);

function Counter(props) {
  const [n, setN] = createSignal(0);
  return (() => {
    var _el$ = _tmpl$(),                    // 克隆模板，不是 createElement
      _el$2 = _el$.firstChild,
      _el$3 = _el$2.nextSibling;            // 位置在编译期就定死了
    _$insert(_el$2, n);                    // 传进去的是「函数 n」，不是 n()
    _el$3.$$click = () => setN(n() + 1);
    _$insert(_el$3, () => props.label);    // props 读取被包成 thunk
    return _el$;
  })();
}
_$delegateEvents(["click"]);                // 事件委托到根，不是逐元素绑定

• 整个静态结构变成了一个 HTML 字符串模板，运行时只做一次 clone 再取几个节点引用——没有虚拟 DOM，也没有 diff；
• _$insert(_el$2, n) 这一行是全页最值得记住的一行：编译器把 {n()} 里的调用剥掉，把信号函数本身交给了运行时。所以「更新」是运行时以后自己去调 n()——这就是细粒度更新的实现方式，也是组件体只跑一次的原因；
• () => props.label 那层 thunk 解释了「别解构 props」：编译器保住的是「读取这个动作」，你一解构就变成了「当时那个值」，thunk 里再也没有读取可追踪；
• _$delegateEvents(["click"]) 说明事件是委托到根节点的，所以 onClick 不是真的绑在那个 button 上。委托只对一张 22 个事件的白名单生效，名单外的（onFocus、onChange 等）编译器会自动退回真正的 addEventListener，不用你操心；真正需要手写 on: 前缀的场合另有其事，见本章的「命名空间前缀」卡。

逐条对照

一个形态差异：JSX 求值出来就是真 DOM

• const node = <div class="x">hi</div>：node 的构造器是 HTMLDivElement，node instanceof HTMLElement 为 true，node.outerHTML 直接就是 <div class="x">hi</div>。React 里同一行拿到的是一个待渲染的描述对象。
• <>…</> 求值出来是一个普通数组（两个子元素就是长度 2 的数组），没有任何包装节点。
• 好处是你可以直接 node.focus()、document.body.append(<div />)；代价是这些节点已经建好了——把 JSX 放在会被反复求值的地方，就是在反复建 DOM，这正是 children() 助手存在的原因。

连默认值也别用解构写

• React 习惯的 function C({ size = "m" }) 在 Solid 里同样断响应。给默认值请用 mergeProps，拆分请用 splitProps（见本章后面），它们专门设计成保持响应。

怎么写才对

• 在 JSX、createMemo、createEffect 这些响应式上下文里读 props.x——读取被追踪，父层一变就更新。
• 需要把某个 prop 传进普通函数时，传访问方式（() => props.x）而不是当前值（props.x），保住那层「读取时机」。

为什么解构就断了：编译产物里能直接看到

• 01 章那张卡打出了真实产物，其中一行是 _$insert(_el$3, () => props.label)——编译器给每处 props 读取都包了一层 thunk，把「读取」推迟到运行时、每次更新重新执行；
• 而 const { label } = props 是在组件体里、组件体只跑一次的时候执行的：那一刻就把当前值取出来存成了普通变量，thunk 里读到的是这个死值，再也不会去问 props 要新的；
• 所以这不是「Solid 的怪规矩」，而是编译期绑定这套机制的必然结果——凡是把「读取」变成「取值」的写法都会断响应：解构、提前赋给局部变量、传参给普通函数，三种都是同一件事；
• 确实需要解构时用 splitProps / mergeProps，它们返回的仍然是带 getter 的代理对象，读取照样被追踪。

mergeProps：合并 / 默认值

• mergeProps(默认对象, props) 返回一个合并后的响应式对象：props 里给了就用 props 的，没给就用默认的。
• lab 验证：Button 用 mergeProps({ variant: "primary" }, props)，一开始没传 variant 时类名是 primary；父层把 variant 设成 danger 后，类名实时跟着变成 danger。比 { ...defaults, ...props } 展开安全——展开会一次性求值、丢掉响应。

splitProps：拆分

• splitProps(props, ["a", "b"]) 返回 [local, rest]：local 是你点名的那几个，rest 是剩下的，两边都保持响应。
• lab 验证：把 label 拆给自己用、rest（含 placeholder）用 {...rest} 转发给 <input>；父层改 label 和 placeholder，两处都实时更新。这正是「用了自己关心的、其余原样透传」的标准写法。

它解决什么

• 直接反复读 props.children，可能触发多次求值、甚至重复创建 DOM 元素，行为难料。
• children() 把结果记忆下来：多次调用返回的是同一批已解析节点，安全又稳定。

lab 验证

• 传入两个 <span> 作为 children，用 const resolved = children(() => props.children) 拿到访问器；resolved() 返回的是数组，长度为 2，把它放回 JSX 渲染出的文本是 ab。说明它确实解析成了可操作的节点集合。

什么时候用 / 不用

• 只是原样透传 children（<div>{props.children}</div>）——不用助手，直接放进 JSX 即可。
• 要读 / 遍历 / 加工 children（给每个子项包一层、读它的属性、统计数量）——用 children()，先拿到稳定结果再操作。

classList：条件切多个类

• 写法 classList={{ 类名: 布尔 }}：值为 true 就加上这个类、false 就去掉。适合「激活态 / 错误态 / 主题类」这种按条件开关的场景。
• lab 验证：classList={{ tag: true, active: active() }}，点击把 active 从 false 翻到 true——active 类被加上，静态的 tag 类始终保留，再点一下 active 又移除。切换精准，不影响其它类。

style：对象写内联样式

• style={{ color: … }} 用对象，属性名用 CSS 原名（"background-color" 这类连字符名要加引号或写成字符串键）。
• lab 验证：style={{ color: on() ? "green" : "gray" }}，信号从 false 变 true 时，元素颜色实时从 gray 变 green。

class vs classList

• 只有一个、或整串由信号算出的类名，用 class={…} 就行。
• 要同时按多个独立条件开关多个类，用 classList 最清爽，省去手工拼字符串。

六个前缀

onClick 和 on:click 到底差在哪

• onClick 走事件委托：监听器挂在 render 的根节点上，元素本身干干净净——一个只写了 onClick 的按钮，outerHTML 就是 <button id="del"></button>，一个属性、一个监听器都没有。列表长了很省。
• 委托只对一张22 个事件的白名单生效（源码里的 DelegatedEvents：click / input / keydown / keyup / pointer* / touch* / focusin / focusout 这类）。名单外的比如 onFocus、onChange、onSubmit、onMouseEnter，编译器自动退回真正的 addEventListener——这件事不用你操心。
• onclick 全小写和 onClick 的编译产物完全一样，大小写不敏感（React 里必须精确写 onClick）。

处理器还能收一个数组

• onClick={[handler, data]} 编译成 el.$$click = handler 加 el.$$clickData = data，运行时把 data 作为第一个参数、事件对象作为第二个传进去。onClick={[(d, e) => …, "带过来的数据"]} 里 d 拿到的就是那个字符串。
• 好处是列表里每一行不必各造一个闭包。

组件与属性

为什么不能用三元和 map

例外：静态的、不会变的条件（比如只依赖 props 里某个常量）用三元没有问题，因为它本来就只求值一次。

根子上是同一条主线

• 「组件只跑一次」意味着：凡是需要随信号变化而重新决定「渲染什么」的地方，都得交给一个自身是响应式的东西去管——控制流组件就是干这个的。
• 它们内部把「条件 / 列表」接进了响应式系统，信号一变，它们就精确地增删 / 复用对应的 DOM，而不必重跑整个组件。

裸三元 / map 的代价

• 把 {cond() ? <A/> : <B/>} 写在 JSX 里也能跑，但每次 cond 变化，Solid 只能整块替换那段结果，里面的组件被销毁重建、内部状态丢失。
• <For> / <Index> 则会按策略复用已有节点，只动该动的行，性能和状态保持都更好。

基本用法

• lab 验证：when 从 false 变 true，内容从 fallback 切到子节点。当成「响应式的 if / else」用即可。

回调形式：把 when 收窄成非 null

• 当 when 是「可能为 null 的对象」时，把子节点写成函数 {(u) => …}：这时回调参数 u 是一个收窄后的访问器，调用 u() 拿到保证非 null 的值，TypeScript 类型也随之收窄。
• lab 验证：when={user()} 为 null 时显示 fallback；置为 { name: "Ann" } 后，回调里 u().name 正常读出 Ann，不会碰到「读 null 的属性」。

keyed：要不要重建整棵子树

• 默认（不加 keyed）时，when 从一个非空值换成另一个非空值，子树不重建——只是回调里那个访问器发出新值。lab 子组件函数体在挂载时跑 1 次，把 when 换成另一个对象后累计仍是 1 次。
• 加上 keyed 后，when 的值一变就销毁旧子树、重建新的，回调参数也从访问器变成值本身（写 u.name 而不是 u().name）。同一实验里子组件体累计跑了 2 次。
• 怎么选：想让子树跟着数据「重新开始」（重置内部 signal、重放入场动画）用 keyed；只是换个数据、想保住子树状态和 DOM，用默认。这和本章 <For> 与 <Index> 的取舍是同一类问题——身份换没换。

直接读 vs 回调读

• 直接读（when 真时子节点里再 user().name）：写起来短，但 TS 里 user() 仍可能被推断成可空。
• 回调读（{(u) => u().name}）：拿到已收窄的访问器，配合 TypeScript 更安全，处理「登录用户 / 选中项」这类可空对象时首选。

lab 验证「引用稳定就复用」

• 让每行组件在创建时把 id 记进一个数组。初始 [a, b] 记下 ["a", "b"]；把数组换成 [b, a]（交换的是同两个引用）后，记录仍是 ["a", "b"]——没有新建行，只是把已有的两行换了位置；而 DOM 文本顺序确实变成了 ba。
• 这正是 <For> 的价值：增删、排序、拖拽时，未变的行连同它们的内部状态（输入框内容、展开态）都原样保留。

为什么 index 是信号

• 因为行会被移动，同一行的下标是会变的。把 index 做成信号（index()），行移动时序号能自动更新，而不必重建整行。
• 反过来，item 是值不是信号——<For> 认为「一个引用对应一行」，引用在整行不变，所以直接给你值。

lab 验证「下标稳定不重建」

• 让每行创建时把下标记进数组。初始 ["a", "b"] 记下 [0, 1]；把数组改成 ["a", "c"]（下标 1 的内容变了）后，记录仍是 [0, 1]——没新建行，只是下标 1 那格的 item() 更新成了 c，DOM 文本变为 ac。

对照表

lab 验证「第一个真」

• 两个条件按 n() > 5、n() > 0 顺序排。n 为 0 时都不满足，走 fallback；n=3 命中第二条显示 small；n=9 时两条都真，取最上面那条显示 big。
• 另一组测试：两个 when={true} 并列，渲染的是第一个。所以顺序很重要——把更具体 / 优先级更高的条件放上面。

什么时候用它

• 互斥的多态状态：加载中 / 成功 / 失败 / 空——每种一个 <Match>，比嵌套一堆 <Show> 清楚得多。
• 只有两个分支时，用 <Show> 的 when + fallback 就够，不必上 <Switch>。

细节

• 每个 <Match> 的 when 都是响应式的，条件里的信号一变，<Switch> 就重新从上往下挑一遍，切到新命中的分支。
• fallback 可省——都不匹配时就渲染空。分支本身也能嵌套 <Show> / <Switch>，但层数别堆太深，太深就该考虑拆组件了。

lab 验证

• 切标签：component={tag()}，tag 从 "h1" 变 "h2" 后，页面里 <h1> 消失、<h2> 出现——旧标签被移除，不是留着藏起来。
• 切组件：component={comp()} 在两个组件间切换，内容随之从 A 变 B。

它替你省掉什么

• 本来要写一长串 <Switch> / <Match> 去枚举「是标题就渲染 h1、是段落就渲染 p……」，用 <Dynamic> 一行搞定，尤其适合「按配置 / 数据字段决定标签或组件」的场景（如富文本渲染、可配置表单控件）。

属性怎么传

• 除了 component，你在 <Dynamic> 上写的其它属性会原样传给被渲染的标签 / 组件——<Dynamic component={tag()} class="x"> 里的 class 就落到实际那个标签上。
• 属性也是响应式的，component 和其它 prop 各自的信号变化都会精确更新，不必因为切标签就手动搬属性。

lab 验证：DOM 搬走了，组件树没动

• 在 <div id="in"> 里放一个 <Portal><span id="p">，渲染后 host.querySelector("#p") 是 null——挂载容器里查不到它；#p 的父元素是一个 <div>，这个 div 挂在 <body> 下。
• 注意它多包了一层容器元素，不是把子节点裸塞进 body。容器的 outerHTML 就是 <div><span id="p"…>弹窗</span></div>。要给这层容器加类名或读它，用 ref 属性（.d.ts 里 ref 拿到的就是这个 HTMLDivElement）。

只搬 DOM，不搬所有权

• Context 照穿：Portal 里的组件 useContext 拿到的仍是外层 Provider 的值，不是默认值——因为 Provider 关系是在组件树上，不在 DOM 树上。
• 生命周期照旧：把 Portal 外面的 <Show> 关掉，body 里的 #p 连同那层容器 div 一起消失，里面的 onCleanup 也跑了。不会漏节点。
• 事件同理——写在 Portal 里的 onClick 仍按组件树的层级被上层接住，「点弹窗触发了外面容器的处理器」是预期行为，不是 bug。

几个属性（据 .d.ts）

• mount（Node）：换落点。mount={某个 <section>} 后节点就落在那个 section 里。
• useShadow：把内容放进容器的 Shadow DOM，隔离外部样式。isSVG：落点在 SVG 里时用，容器换成 <g> 而不是 <div>。

setter 路径写法

三个配套函数

读像对象，写走 setter

• createStore(初值) 返回 [state, setState]。读取不加括号——state.user.name 就是普通属性访问，Proxy 会在读取的那一处悄悄登记依赖。这一点和信号要写 count() 正相反，别混。
• 但 state 是只读的：直接写 state.user.name = "Bob" 不生效——值不变、也不抛异常，但开发构建会打印告警 Cannot mutate a Store directly 提醒你走 setState。这一读一写的不对称，正是它能做到细粒度的关键。

路径式更新的三种末段

• setState("user", "name", "Bob")：前面几段是路径，最后一个参数是新值。
• 末段传函数基于旧值算：setState("user", "age", a => a + 1)。
• 路径中间放谓词函数按条件定位数组项：setState("todos", t => t.id === 1, "done", true) 只改命中的那一项。

细粒度到字段

• 把 a.b 与 a.c 分别绑到两个 effect，执行 setState("a", "b", 5)，只有读了 a.b 的那个 effect 会重跑——这就是 store 相对信号的核心红利。
• 对照 React 的 setState({...state, user:{...state.user, name}})，路径式写法既短又精确，还不用手动铺开每一层。

路径能有多深，整体怎么合

• 路径想多深有多深：setState("a", "b", "c", 值) 一路点到底，只更新最末那个字段。数组下标也是路径的一段——setState("todos", 0, "done", true) 改第一项。
• 偶尔想「一次改好几个顶层字段」，可以直接传一个对象：setState({ loading: false, error: null })。这是浅合并顶层（lab 没提到的顶层键原样保留），不是把整个 store 换掉。
• 所以 setState 一身两用——给路径就精确改某字段，给对象就浅合并顶层。两种都不会像信号那样「整体替换、丢掉细粒度身份」，这也是它比信号更适合嵌套结构的原因。

那到底怎么用

• 就地访问：需要哪个字段就在用的地方写全路径 state.user.name，别提前拎出来存变量。
• 确实想要「短名字」时，用 createMemo(() => state.user.name) 包一层——memo 是响应式的访问器，读它 name() 保持追踪。
• 把 store 当 props 往下传时同理：子组件里写 props.data.name，别在函数顶部解构。

和解构 props 是同一条规则

• store 和 props 都是 Proxy，「解构等于拍快照、快照断响应」这条对两者一模一样——04 章讲 props 时踩的就是同一个坑。记住一条，两处都记住了。
• 嵌套解构照样断：const { user: { name } } = state 是快照；哪怕只解构中间一层 const { user } = state，之后读 user.name 也已脱离原 store 的响应链。
• 唯一安全的「拆」是官方给的 splitProps（针对 props）和 createMemo（针对任意响应式读取）——它们把响应性接着往下传，而不是在解构那一刻掐断。

增、删、改

• 增：末段传函数返回新数组 setState("todos", t => [...t, item])。
• 删：同样返回过滤后的新数组 setState("todos", t => t.filter(x => x.id !== id))。
• 改某项：谓词路径 setState("todos", t => t.id === id, "done", d => !d)——只更新命中项的那个字段，其它行的 DOM 一动不动。

produce：可变式草稿

• setState(produce(draft => {...})) 把一个可变草稿交给你，在回调里直接 draft.todos.push(...)、draft.todos[0].done = true，就像改普通对象。
• 它就地改（lab 里 push 后长度 +1、改的字段生效），底层仍走细粒度更新，不用你手写一长串 [...spread]。
• 适合一次改多处或深层嵌套；只改一两个字段时，直接路径式反而更清爽。

谓词路径省在哪

• 改一项走谓词路径 setState("todos", t => t.id === id, "done", d => !d)，Solid 只更新命中项 done 字段对应的 DOM——列表里其它行连碰都不碰。
• 要是图省事整体 map 出一个新数组再 set，等于告诉框架「整条数组都换新了」，每行都可能被当成新对象，细粒度优势就白费了。能定位到具体项就别替换整段。
• 增删（结构变了）才返回新数组，改字段（结构没变）走谓词路径——按「动的是结构还是值」来选，最不容易出错。

reconcile 干的事

• setState("items", reconcile(nextSnapshot))：用新快照去比对合并当前 store，没变的项保留原有细粒度身份，变了的字段就地更新。
• lab 把 [{id:1,n:"a"},{id:2,n:"b"}] reconcile 成 [{id:1,n:"a2"},...]，只有第一项的 n 变成 a2，长度、第二项都稳定——正是「整段服务端数据塞回来」想要的效果。
• 可给它配 key（默认按 id）帮助按身份匹配，列表增删重排也能对上号。

unwrap：拿回原始对象

• unwrap(store) 剥掉 Proxy，返回底层原始对象（lab 里就是普通数组/对象）。
• 用途：要把 store 数据交给不认识 Proxy 的外部代码（序列化、发给第三方库、深拷贝）时，先 unwrap 拿干净对象。
• 注意 unwrap 出来的是引用，直接改它不会触发响应也可能污染 store，只读着用。

什么时候用它

• 典型场景：一个 createResource 拉回列表，createEffect 里 setState("list", reconcile(data())) 合并进本地 store，既拿到服务端最新，又保住了行的身份、不闪。异步取数详见 08 章。

按什么匹配，什么时候别用

• reconcile 默认按 id 字段认领每一项；主键不叫 id 时用 reconcile(next, { key: "uid" }) 指定。匹配得上，行的身份才稳、才不会整列重建。
• 它的价值在「同一份数据的增量刷新」——列表轮询、重新拉取当前页。若拿到的是另一份完全不同的数据（形状差很多），别硬 reconcile，直接整体 set 更直白也更快。

一句话判据

• 问自己：这份状态会不会只改其中一个字段？会 → store（细粒度到字段）。总是整体换 → signal。
• 再问：读取时要加括号吗？signal 要 count()，store 不要 state.x——这也是两者最直观的区别。

不确定时的默认

• 先用 signal，简单直接；等发现「每次更新都在手写 {...spread} 铺开嵌套」或「改一个字段却触发一大片重算」，就是该换 store 的信号。
• 两者能共存：外层用几个 signal 管开关，一处复杂表单用 store，不必二选一到底。

生命周期

Context

ref 的三种写法

它解决什么

• 组件体里直接摸 DOM 是空的（还没挂载）。onMount(fn) 把 fn 推迟到挂载完成后，此时 ref 已指向真实节点（lab onMount 里读 el.tagName 拿到 "DIV"）。
• 只跑一次、不追踪任何信号——它就是「初始化钩子」，类比 React 的 useEffect(fn, [])。lab 里被调用次数正好 1。

为什么强调「只在客户端」

• SSR 时组件在服务端渲染成 HTML 字符串，那里没有 DOM。onMount 不会在服务端执行，只在浏览器水合后跑——所以摸 window/document、启动定时器这类只该发生在浏览器的事，放这里最稳。
• 反过来，纯数据的初始化（不碰 DOM）用 createEffect 或直接写在组件体里即可，不必都塞进 onMount。

和 createEffect 的分工

• onMount = 只跑一次、不追踪依赖的 effect。要「随某个信号变化反复做事」是 createEffect 的活，别指望 onMount 会再跑第二次。
• 顺序上，onMount 的回调在挂载后触发，此时 ref 已就位、子组件也已渲染，适合做「读真实布局」这类必须等 DOM 齐了的事。

典型用途

• 接需要真实节点的第三方库——图表、地图、富文本编辑器，都在这里 new 出实例、挂到 ref 指的元素上。
• 读初始布局：el.clientWidth、滚动位置、聚焦第一个输入框。
• 启动只该在浏览器发生的东西：window 监听、requestAnimationFrame 循环——记得配 onCleanup 收尾。

两个触发时机

• 组件卸载：组件从 DOM 移除时，其内所有 onCleanup 依次执行——清 setInterval、解绑监听就靠这个。
• 作用域重跑前：把 onCleanup 写进 createEffect，effect 每次因依赖变化重跑之前，会先跑上一轮登记的清理。lab 信号从 0→1→2，清理依次收到 0、1，dispose 时再收到 2。

为什么这个设计很顺手

• 「订阅 / 取消订阅」天然成对：在 effect 里根据当前信号建立订阅，再 onCleanup 取消——切换目标时，框架自动先退订旧的、再订新的，不用你手写 diff。
• 清理逻辑就近写在建立副作用的地方，读代码时一眼看到「起」和「收」，不会各写一处对不上。

一次注册多个清理

• 同一个作用域里可以多次 onCleanup，各自登记、按注册顺序执行——不用把所有清理硬塞进一个函数。谁起的副作用，就紧跟着登记谁的清理，读起来最清楚。
• 它和 onMount 常成对出现：onMount 里 new 出第三方实例，onCleanup 里 instance.destroy()，一起一收，生命周期闭环。

它是「反做」清单，不是终止钩子

• 别把它当成「组件要没了」的那种一次性终止信号——它更像一张反做清单：谁起了副作用，就登记怎么撤。既能在卸载时统一撤，也能在 effect 每轮重跑前撤掉上一轮，用途比「卸载钩子」宽得多。

三步走

• createContext(默认值) 造一个 Context 对象。
• 用 <Ctx.Provider value={...}> 包住子树，value 里放你要共享的东西。
• 后代任意深度 useContext(Ctx) 取回那个 value，无需逐层传递。

value 里放信号本身

• 想让共享的状态可变又响应，往 value 里放信号或 store（连同它们的 setter），而不是当前的值快照。
• 消费端拿到信号后照常 theme() 加括号读——响应性一路保持，Provider 里改了，所有用到的后代都更新。

无 Provider 走默认值

• createContext(默认值) 的参数，就是在找不到任何 Provider 时 useContext 的返回。lab 没包 Provider 时拿到构造时的默认值；包了就拿 Provider 的 value。
• 所以给一个合理的默认值，能让组件在没被 Provider 包裹时也不至于炸——尤其做可复用组件时。

惯用封装

• 常见做法是把「造信号 + 提供 Provider」收进一个 XxxProvider 组件，再导出一个 useXxx() 小函数（内部就是 useContext）。用的人不必知道 Context 对象长什么样，只 const s = useXxx()。
• Context 更适合读多写少、跨多层的状态（主题、当前用户、语言）。要在很多不相干组件间频繁读写一份复杂状态，模块级 store 往往更直接（见 06）。

普通变量式

• let el; 声明空变量，<div ref={el}> 绑上去。Solid 在挂载时把真实节点写进这个变量（lab onMount 里 el.tagName 拿到 "INPUT"）。
• 组件体里此刻还是 undefined——要用它得等挂载后，通常放进 onMount。

函数式 ref

• 也能传函数：ref={(e) => ...}，挂载时框架把节点作为参数 e 调用它。适合当场做点处理、或把节点存到别处（lab 里函数 ref 拿到 "BUTTON"）。
• 想把 ref 转发给子组件时也用得上：父层传函数下去，子层绑到内部元素。

转发 ref 给子组件

• Solid 里 ref 就是普通 prop，没有 React 那套 forwardRef。父层把变量或函数当 ref 传给自定义组件，子组件内部接住 props.ref 再绑到真实元素上，父层就拿到了里层的 DOM。
• 因为父层传下来的 ref 可能是变量式也可能是函数式，子组件直接把 props.ref 原样绑到元素上最稳——两种形式框架都会正确处理。

两种写法怎么挑

• 只是「拿到留着后面用」（聚焦、接库、测量）→ 普通变量式最省事。想在挂载那一刻当场处理、或要把节点塞进数组 / 转发出去 → 函数式更顺手。
• 两种在同一组件里混用完全正常，绑法上没有优劣，按「什么时候需要这个节点」来选即可。

lab 复现：清理函数到底跑没跑

• 在 createRoot 里起一个异步函数，await 之后调 getOwner()——拿到的是 null（同一个 root 的同步位置拿到的是有效 owner）。
• 紧接着在那里注册 onCleanup，再手动 dispose() 掉 root：这个清理函数一次都没跑。定时器不会被清、订阅不会被退、事件监听器留在那里——这就是内存泄漏的来源。
• 把同一句用 runWithOwner(owner, () => onCleanup(…)) 包住，dispose() 时它跑了。差别只在有没有把 owner 带过来。

正确姿势：同步时先把 owner 存下来

• 在组件体里（同步位置）const owner = getOwner()，异步回调里再 runWithOwner(owner, () => { … })。getOwner / runWithOwner 都来自 solid-js。
• 能避开就避开：订阅类的清理尽量写在同步位置——在 onMount 里建订阅、当场 onCleanup 退订，就完全不必碰 owner。只有「异步拿到句柄之后才知道要清理什么」时才需要 runWithOwner。
• 同一条规则也解释了另一个常见困惑：await 之后 useContext 会读到默认值而不是 Provider 的值——因为 Provider 关系也挂在 owner 上。

怎么快速定位

• 直接父子：能用 props 就用 props，最简单直白。
• 子要通知父：父把回调函数当 prop 传下去，子在合适时机调用——这就是「子传父」。
• 隔了好几层：别硬穿 props，用 Context 把中间层解放出来。
• 好几个不相干的组件共享一份状态：抽成模块级 store，各自 import，天然全局又保持细粒度。

一条主线

• 这四种其实是一个梯度：关系越近越用 props，越远越靠共享容器（Context / store）。先想清楚组件间的关系，再对号入座，别一上来就上全局状态。

一个小例子串起来

• 一个「待办列表」页：外层 App 用模块级 store 存 todos（store 共享）；每个 <TodoItem todo={t}> 靠 props 拿到自己那条；用户勾选时 TodoItem 调 props.onToggle(t.id) 把动作抛回去（事件回调）；而当前主题由顶层 Provider 提供、任意深处的按钮 useContext 取用（Context）。四种手段在一屏里各司其职。

createResource

编排组件

返回什么

• const [data, { mutate, refetch }] = createResource(fetcher)。fetcher 是个返回 Promise 的函数。
• data 既是访问器也挂着状态：data() 取值、data.loading 是布尔、data.error 是错误对象——三态都在这一个东西上（OLAB 事实 20，lab 里）。

三态怎么读

• 加载中：请求未完成时 data.loading === true、data() 为 undefined。
• 数据到了：Promise resolve 后 data.loading 变 false、data() 是结果。
• 出错了：Promise reject 后 data.error 拿到错误对象（lab 里读到 error.message 为 "boom"）。

两个把手

• refetch()：手动再请求一次（按钮「刷新」）。
• mutate(v)：不发请求，本地直接改资源当前值（lab 里改成 "local"）——常用于乐观更新，先把 UI 改了，再让请求跟上。

为什么值得用它

• 没有它，你得手动维护三个信号（data / loading / error）、在请求前后一个个 set，还要提防竞态。createResource 把这套样板收进一个对象，三态天然同步、不会互相打架。
• 它还和本章后面的 <Suspense>、<ErrorBoundary> 打通——加载态能被 Suspense 接管、错误能被 ErrorBoundary 兜住，不必自己在 JSX 里写一堆条件分支。这几张卡讲的就是这条链。

怎么接

• createResource(source, fetcher)：source 是个访问器（信号 / memo），fetcher 收到的第一个参数就是当前源值。
• 源变化 → 框架自动用新值再调一次 fetcher（OLAB 事实 21，lab setId(2) 后 fetcher 收到的调用序列正好是 [1, 2]）。

源为假值时会跳过

• 当源求值为 false / null / undefined 时，createResource 不会触发 fetcher——这正好用来做「依赖就绪才请求」：userId() 还没有值时不发请求。
• 所以把「是否该请求」的条件塞进源信号，比在 fetcher 里写一堆 if 判断干净。

心智：声明依赖，不是命令

• 你不是「监听 id 变化再手动发请求」，而是声明「这份数据由这个源决定」。剩下的重取时机交给框架——这和 02 章 effect 自动追踪是同一套思想。

竞态它替你挡了

• 快速连续切换源（id 从 1 跳到 2 再到 3），老请求可能后回来、把新数据盖掉——这就是经典的请求竞态。createResource 内部按最新一次源值对齐，过期请求的结果会被丢弃，你不用自己记「哪次是最新的」。
• 配合 <Suspense>，源变化时还能保持上一份数据显示、只在边界上转圈，切换体验更顺（详见后面 Suspense 卡）。

自动之外，手动重取仍在

• 源驱动是自动的，但需要「数据没变、就想重拉一次最新」时，解构出 refetch 手动调即可。两条路不冲突：源变触发自动重取，用户点刷新触发手动重取，一份资源两种刷新入口。

怎么用

• <Suspense fallback={加载占位}> 包住内部会读资源的组件。内部任一 createResource 在加载，就显示 fallback（OLAB 事实 22，lab 加载时页面是「加载中」，resolve 后变成内容且不再有「加载中」）。
• 它捕获的是边界内所有资源的加载态——不用给每个组件单独判断 loading。

好在哪

• 少写模板分支：组件里直接 user().name 当数据已就绪那样写，加载态交给外层 Suspense，代码干净很多。
• 协调多块：几块数据放同一个 Suspense 里，就等它们都好再一起显示，避免「东一块西一块先后蹦出来」的跳动。要各自独立加载就拆成多个 Suspense。

和三态的关系

• Suspense 接管的是「加载中」。「出错了」交给下一张的 <ErrorBoundary>，两者常套着用——外层兜错、内层兜加载。

边界该放多大

• 放太大：整页共用一个 Suspense，任一小块慢就整页卡在占位，体验差。放太小：每个字段一个，又回到「满屏转圈」的碎片感。
• 务实的粒度是按内容区块——头部一个、侧栏一个、主内容一个，各自独立加载、互不拖累。区块内部「要一起出现才不突兀」的几项，再共用一个 Suspense。

不用逐个判 loading

• 有了 Suspense，边界内的组件可以假设数据已就绪那样直接写 user().name，不必每个都套一层 user.loading ? ... : ...。判断加载态的活集中到边界一处，模板一下子干净很多。

怎么用

• <ErrorBoundary fallback={(err, reset) => ...}> 包住可能出错的子树。
• 子树里抛错时，fallback 被调用，第一个参数就是那个错误对象（OLAB 事实 23，lab 读到 err.message 是 "渲染炸了"），第二个 reset 用来清除错误、重新渲染子树。

它能抓什么、抓不到什么

• 能抓：子组件渲染期间抛出的错误，也包含读取一个 error 态资源时抛出的错（配 Suspense 时资源的错误会冒到这里）。
• 抓不到：事件回调里的异步错误、setTimeout 里的错——那些不在渲染流程里，得自己 try/catch。它不是万能捕获。

和 Suspense 搭配

• 常见组合是外层 ErrorBoundary + 内层 Suspense：加载时 Suspense 显示占位，出错时 ErrorBoundary 显示错误 UI，数据到了显示内容——三态各归其位。

放在哪一层

• ErrorBoundary 会捕获它子树里的错误，所以放得越靠上，兜的范围越大、但错误 UI 越粗（整块换成报错）。放得越靠近出错点，越能做「只有这一小块显示重试、其余照常」的精细降级。
• 常见分层：外层放一个「兜底大网」防白屏，关键区块内再各放一个小 ErrorBoundary 做局部降级——一处崩了不连累整页。

给用户一条退路

• 好的 fallback 不只是「把错误打印出来」，而是给一条可操作的退路——一句人话的提示，加一个调 reset 的「重试」按钮。比一片红字或白屏友好得多，也不至于让整个应用卡死在一个局部错误上。

怎么用

• const Page = lazy(() => import("./Page"))：传一个返回动态 import 的函数。打包器据此把 ./Page 切成单独 chunk。
• 把 <Page /> 放进 <Suspense>；首次渲染到它时才下载那段代码，下载期间显示 Suspense 的 fallback。
• lazy 返回的是普通组件，用法和别的组件没差（这里按 lazy 的 API 契约描述；lab 里用一个立即 resolve 的模块工厂验证过「Suspense 包着能正常渲染出内容」）。

用在哪最划算

• 路由级：每个页面 lazy 一下，只下载当前路由那页——最典型、收益最大的用法。
• 重而不常用的块：富文本编辑器、图表、弹窗里的复杂表单，进来不一定用到，按需加载。
• 反过来，小组件、首屏一定要用的东西别 lazy——徒增一次网络往返，得不偿失。

它和 Suspense 是天生一对

• lazy 组件在下载那段时间「没有内容可渲染」，正是 <Suspense> 兜加载态的场景——所以两者几乎总一起出现：lazy 负责切包、Suspense 负责下载期间显示占位。
• 切分粒度别太碎：把整个应用拆成几十个微 chunk，反而带来一堆小请求。按路由、按重模块切几处，收益最实在。

首屏体积的直接杠杆

• 不切分时，用户打开首页就得把所有页面的代码一并下下来。lazy 把「现在还用不到的」推迟到真正访问时再下——首屏 JS 变小、可交互更快，这是它最直接实在的收益。

lab 对比：同一次切换，两种观感

• 裸 set：setTab("b") 之后立刻读页面文本，得到的是 "fallback"——旧内容被卸掉了。
• 包进 transition：start(() => setTab("b")) 之后读到的仍是 "A 页"（旧内容），同时 pending() 为 true；等新数据的 Promise resolve，文本变成 "B 页"、pending() 回到 false。
• 换句话说，transition 把「fallback 闪一下」换成了「旧内容 + 一个进行中的标志」。数据没到之前，用户手上一直有可读的东西。

两个入口，选哪个

• const [pending, start] = useTransition()——要在界面上显示「加载中」时用它，pending 是个信号，可以直接绑到按钮的 disabled 或加个 .loading 类。必须在组件的响应式上下文里调用。
• startTransition(() => …)——不需要 pending 标志时的简写，任何地方都能调，返回一个 Promise，可以 await 到切换完成。
• 两者都只对包在里面的那些 set 生效，且必须真的有 Suspense 边界在等异步；纯同步的更新包不包都一样。

它和 Suspense 的分工

• <Suspense> 管的是「第一次没有数据时显示什么」——首屏、进入详情页，这时除了骨架屏也没别的可显示。
• transition 管的是「已经有一份旧数据时的切换」——这时退回骨架屏是倒退。经验做法：首屏交给 Suspense，之后所有由用户操作触发的重新取数都包进 transition。

各类控件怎么绑

用 onInput 而不是 onChange：前者逐字符触发，后者要等失焦——这与 React 的命名习惯相反，React 的 onChange 实际就是原生的 input。

四种写法

校验与提交的固定结构

接线只有两根

• 读：value={name()}——注意信号要调用，name() 带括号。
• 写：onInput={(e) => setName(e.currentTarget.value)}——每次敲键都把最新文本写回信号。
• 因为组件只跑一次（这是 Solid 的根，见 04 章），这里的 value={name()} 会被编译成对该属性的精确绑定：信号一变，只更新这个 input 的 value，不重跑组件。

label 的 id 用 createUniqueId，别手写

• 输入框要能被点标签聚焦、要能被读屏软件念对，就得有 <label for="x"> + <input id="x"> 这对绑定。写死一个 id="email" 在这个框只出现一次时没问题，一旦这个组件被用了两次，页面上就有两个同 id 元素，for 只会命中第一个。
• createUniqueId()（来自 solid-js）每次调用给一个全站唯一的字符串——lab 里连调两次拿到 cl-0、cl-1。在组件体里调一次、同时用给 for 和 id 即可。
• 它真正的价值在 SSR：服务端和客户端按同一顺序生成同一串 id，水合时对得上。用 Math.random() 或计数器自己造，两端结果不一致，水合会出问题（13 章）。aria-describedby 指向错误提示时同理。

受控换来了什么

• 值只有一处，程序改信号、界面立刻跟上（清空、预填、格式化都只是 setName(...)）。
• 校验、联动、字数统计都能直接读同一个信号，不用再去 DOM 里捞。

什么时候不受控

• 一次性读取：登录框、搜索框，只在按下按钮时要值，输入过程里没有联动。
• 不想每键重跑逻辑：受控会让每次输入都写信号、触发依赖；不受控则完全不碰响应式系统。
• 文件输入 <input type="file"> 只能非受控——它的值不能用代码设。

ref 就是个普通变量

• Solid 不需要 createRef：声明 let el;，写 ref={el}，元素挂载后 el 就指向真实 DOM（细节见 07 章）。
• 提交时 el.value 直接读当前输入。要设默认显示值用 value="..." 或 <input value="初始">，它不会再被信号接管。

受控 vs 非受控，一句话选

• 值中途要联动（禁用按钮、实时校验、字数统计）→ 受控，接信号。
• 值只在提交时读一次、过程里没人管 → 非受控，用 ref 提交时捞。
• 拿不准就先非受控，等真需要联动了再升级成受控——反过来把受控改回非受控反而费劲。

最直接：还是 value + onInput

• 九成场景直接写 value={x()} + onInput={e => setX(...)} 就够了，清清楚楚，没有隐藏魔法。
• 嫌重复，就把这段抽成一个指令，在多个框上复用。

自定义 use: 指令（本页已在实验台验证）

• use:model={signal} 会调用你写的 model(el, accessor) 函数，el 是 DOM、accessor() 返回你传进去的那个 [get, set] 信号元组。
• 指令里做两件事：用 createEffect 把信号写进 el.value（信号变→框变），再 addEventListener("input") 把输入写回信号（框变→信号变）。这就是一个真正的双向绑定，实验台里验过它能跑通。

一个 store 装下整张表

• const [form, setForm] = createStore({ name: "", address: { city: "" } })：嵌套结构也能一把管住。
• 读：form.name、form.address.city——像普通对象，不加括号（store 不是信号）。
• 写：setForm("name", 值)、setForm("address", "city", 值)——路径一层层点进去，最后给新值。store 的完整玩法见 06 章。

细粒度到字段

• 改 city 只会更新绑了 form.address.city 的那个框，name 那个框不重算。这一点本页在实验台里验过。
• 比 React 的 setForm({...form, address:{...form.address, city}}) 既短又准——不用手动铺展开整棵对象。

字段多了可以泛化

• 顶层扁平字段可以写一个通用回调：onInput={e => setForm(e.currentTarget.name, e.currentTarget.value)}，靠 name 属性对上 store 的键。

三样东西

• 值 store：[form, setForm]，装 email、pwd。
• 错误 store：[errors, setErrors]，每个字段一条错误字符串，空串表示没错。
• 校验函数：逐字段判断，用 setErrors 写结果，返回「是否全通过」。

提交流程

• 表单 onSubmit 里先 e.preventDefault() 拦住浏览器默认跳转，再跑校验；通过才把数据交出去。
• 错误信息直接在 JSX 里读 errors.email 显示——它是 store 字段，改了就只更新那条提示。

提交按钮的收尾

• 真正提交是异步的（发请求）：提交时把一个 submitting 信号置真、禁用按钮防重复点，请求回来再置假。
• 服务端也可能返回错误（邮箱已注册）：把它写回同一个错误 store 的对应字段，前端校验和后端校验共用一套展示位置。

响应式相关

组件相关

配置与对照

tsconfig 就两行是关键

• "jsx": "preserve" 让 tsc 别自己转 JSX——转换要留给 vite-plugin-solid 的 babel 去做；"jsxImportSource": "solid-js" 告诉它去 solid-js/jsx-runtime 找 JSX 命名空间，属性检查才认得 class、classList 这些。
• 这两行是 create-vite 的 solid-ts 模板原文（对着 create-vite 9.1.1 的 template-solid-ts/tsconfig.app.json 核过，同文件还带 "moduleResolution": "bundler"、"types": ["vite/client"]、"verbatimModuleSyntax": true）。
• 从 React 项目迁过来最常见的错是留着 "jsx": "react-jsx"——那会让 tsc 按 React 运行时转换 JSX，Solid 的编译器就拿不到原始 JSX 了。

类型名对照

五个空接口：自定义前缀要自己补声明

• Directives（use:）、ExplicitProperties（prop:）、ExplicitAttributes（attr:）、ExplicitBoolAttributes（bool:）、CustomEvents（自定义事件的 on:）在 jsx.d.ts 里都是空接口，靠你用 declare module "solid-js" 往里加键。
• 补完声明后 use:model / attr:data-x / prop:value / bool:disabled / on:my-event 全部通过；不补则报「属性不存在」。标准 DOM 事件的 on:click 已经被逐个枚举好，不用声明。

两种写法

• 套组件类型：const Card: Component<CardProps> = (props) => ...。Component<P> 的真实定义就是 (props: P) => JSX.Element，标了它 props 就自动是 P、返回值也被约束。
• 标参数：function Plain(props: CardProps) { ... }。更朴素，普通函数组件常用。

要不要 children，选不同类型

三个类型的真身

什么时候要手写

• 显式泛型：初值推不出你要的类型时，createSignal<string[]>([]) 把类型钉死，否则空数组会被推成 never[]。
• 把访问器当参数传：函数收一个 value: Accessor<number>，比写 () => number 更达意。

store 的两个类型

• Store<T> 在 .d.ts 里其实就是 T 本身——读的时候形状和原对象一模一样，所以 form.address.city 类型自然正确。
• SetStoreFunction<T> 是那个路径式 setter，重载覆盖到七层深，替你把每层的键名和值类型都对上：setForm("address", "city", ...) 里第三个参数只能是 string。

resource 的类型

• Resource<T> 是个联合类型，既能当函数调用（data() 返回 T | undefined），又带 .loading: boolean、.error: any、.state。
• 取数函数的返回类型就是 T：createResource(id, fetchUser) 里 fetchUser 返回 Promise<User>，data() 就是 User | undefined。