React 19還沒(méi)捂熱，社區(qū)里一組實(shí)驗(yàn)代碼的Star數(shù)已經(jīng)悄悄破了4000。不是新框架，是有人把Signals塞進(jìn)了React——而且沒(méi)動(dòng)一行React源碼。

這事有意思的地方在于：React團(tuán)隊(duì)自己也在搞Signals（就是那個(gè)叫use的Hook），但進(jìn)度慢得像在擠牙膏。社區(qū)等不及了，直接上手造了個(gè)能跑的生產(chǎn)級(jí)方案。今天這篇就是作者系列的第四篇，講清楚一個(gè)關(guān)鍵問(wèn)題——數(shù)據(jù)副作用和UI副作用，到底該誰(shuí)管？

7行代碼，拆出兩條完全不同的生命周期

先看這段被轉(zhuǎn)發(fā)最多的代碼：

// data/heartbeat.ts import { signal } from "../core/signal"; import { createEffect, onCleanup } from "../core/effect"; export const intervalMs = signal(1000); export const heartbeat = signal(null); createEffect(() => { const ms = intervalMs.get(); const id = setInterval(() => { heartbeat.set(new Date()); }, ms); onCleanup(() => clearInterval(id)); });

7行核心邏輯，干了一件React里很別扭的事：讓一個(gè)定時(shí)器跟著數(shù)據(jù)走，而不是跟著組件走。

作者管這叫"數(shù)據(jù)層的心跳"——intervalMs是個(gè)信號(hào)，改它的時(shí)候，舊的定時(shí)器自動(dòng)清理，新的自動(dòng)啟動(dòng)。整個(gè)過(guò)程沒(méi)有組件參與，頁(yè)面切走了它還在跑，頁(yè)面切回來(lái)數(shù)據(jù)還是熱的。

對(duì)比React原生的寫(xiě)法，差別立刻顯現(xiàn)。以前你要么把定時(shí)器塞useEffect里跟著組件生死，要么上Redux-Saga、React Query這種重型方案?，F(xiàn)在7行代碼搞定，而且類型安全。

光標(biāo)閃爍：為什么必須用React的useEffect？

作者緊接著拋了另一個(gè)例子，刻意和上面的形成對(duì)照：

// ui/Blinker.tsx export function Blinker({ enabled = true }) { const [on, setOn] = useState(false); useEffect(() => { if (!enabled) return; const id = setInterval(() => setOn(v => !v), 500); return () => clearInterval(id); }, [enabled]); return |; }

同樣是定時(shí)器，這次老老實(shí)實(shí)用了React的useEffect。為什么？

因?yàn)楣鈽?biāo)閃爍是純視覺(jué)行為，它依賴React的渲染周期——enabled prop變了要立刻停，組件卸載要立刻清。這些時(shí)機(jī)必須對(duì)齊React的commit階段，而不是數(shù)據(jù)的任意變更。

作者的原話很直接：「這是純粹的UI/視覺(jué)行為，它的清理時(shí)機(jī)應(yīng)該跟隨React的提交周期?！?/p>

兩個(gè)例子擺在一起，分界線就清楚了：createEffect管數(shù)據(jù)流的生命周期，useEffect管DOM的生命周期。以前這兩件事被混在一個(gè)Hook里，現(xiàn)在物理隔離。

Dashboard組件：兩條河怎么匯到一處

真正用起來(lái)的時(shí)候，開(kāi)發(fā)者面對(duì)的其實(shí)是混合場(chǎng)景?？醋髡叩腁pp.tsx：

export function Dashboard() { const lastBeat = useSignalValue(heartbeat); const ms = useSignalValue(intervalMs); return (

Last heartbeat: {lastBeat?.toLocaleTimeString() ?? "—"}

Polling every {ms} ms

這里用了個(gè)叫useSignalValue的橋接Hook——信號(hào)的值被轉(zhuǎn)換成React能消費(fèi)的state，但信號(hào)的訂閱關(guān)系還在數(shù)據(jù)層自己手里。

結(jié)果是：改intervalMs的時(shí)候，createEffect那邊自動(dòng)重跑定時(shí)器，Dashboard組件只收到最新的ms值，不需要關(guān)心定時(shí)器的創(chuàng)建和銷毀。而B(niǎo)linker組件里的光標(biāo)，該閃還是閃，該停還是停，兩條線互不干擾。

作者特意強(qiáng)調(diào)了行為差異：Timer polling（createEffect）獨(dú)立于任何組件，頁(yè)面導(dǎo)航時(shí)繼續(xù)運(yùn)行；UI blinking（useEffect）隨組件掛載/卸載創(chuàng)建和清理。

這個(gè)設(shè)計(jì)在解決什么真問(wèn)題？

熟悉React歷史的人知道，useEffect的批評(píng)聲音從來(lái)沒(méi)停過(guò)。Dan Abramov自己寫(xiě)過(guò)一篇《useEffect完整指南》，底下最高贊評(píng)論是"我還是不懂"。

核心矛盾在于：useEffect被迫同時(shí)干兩件事——同步外部系統(tǒng)（數(shù)據(jù)），和同步瀏覽器API（DOM）。這兩件事的時(shí)序要求完全不同，但API長(zhǎng)得一模一樣，依賴數(shù)組的語(yǔ)義還隨場(chǎng)景變化。

Signals方案把第一層抽走了。數(shù)據(jù)相關(guān)的副作用跟著信號(hào)走，有獨(dú)立的創(chuàng)建-更新-銷毀生命周期；UI相關(guān)的副作用留在React里，跟著渲染周期走。兩邊都用onCleanup，但執(zhí)行的時(shí)機(jī)由各自的運(yùn)行時(shí)保證。

這不是什么理論潔癖。作者舉的實(shí)際場(chǎng)景是：一個(gè)輪詢心跳，一個(gè)光標(biāo)閃爍。在生產(chǎn)環(huán)境里，這可能是WebSocket重連策略和加載動(dòng)畫(huà)的關(guān)系，是后臺(tái)同步狀態(tài)和Toast提示的關(guān)系——以前寫(xiě)在一起必然互相干擾，現(xiàn)在可以分開(kāi)測(cè)試、分開(kāi)優(yōu)化。

社區(qū)對(duì)這個(gè)方案的反應(yīng)很分裂。一部分人覺(jué)得終于不用在useEffect里寫(xiě)一堆防御性代碼了，另一部分人擔(dān)心又多了一層概念負(fù)擔(dān)。但Star數(shù)的增長(zhǎng)是真實(shí)的，4000多個(gè)開(kāi)發(fā)者用實(shí)際行動(dòng)投了票。

React官方的Signals實(shí)現(xiàn)還在RFC階段，具體語(yǔ)法變了好幾稿。社區(qū)方案的優(yōu)勢(shì)是現(xiàn)在就可用，而且API設(shè)計(jì)明顯借鑒了Solid.js的成熟經(jīng)驗(yàn)——createEffect、onCleanup、signal.get()/set()，幾乎照搬。

風(fēng)險(xiǎn)也有。這個(gè)方案依賴React的訂閱機(jī)制做橋接，如果官方最終定的API差異太大，遷移成本不會(huì)小。但作者似乎不太在意，系列文章已經(jīng)寫(xiě)到第四篇，每一篇都在補(bǔ)全邊緣場(chǎng)景的處理。

一個(gè)值得注意的細(xì)節(jié)：作者的代碼里沒(méi)有任何"魔法"。signal、createEffect都是普通函數(shù)，沒(méi)有編譯時(shí)轉(zhuǎn)換，沒(méi)有Babel插件。這意味著你可以逐行調(diào)試，可以在瀏覽器控制臺(tái)里手動(dòng)調(diào)heartbeat.set()看效果。

這種可觀測(cè)性在現(xiàn)在的前端生態(tài)里反而成了稀缺品。太多方案藏在編譯器后面，開(kāi)發(fā)者遇到問(wèn)題只能猜。

回到開(kāi)頭那個(gè)問(wèn)題：React團(tuán)隊(duì)知道社區(qū)在這么干嗎？

知道。React核心成員Andrew Clark去年在Twitter上回復(fù)過(guò)類似方案，說(shuō)"我們也在探索這個(gè)方向，但想確保和并發(fā)特性兼容"。翻譯一下：官方認(rèn)可問(wèn)題存在，但解法要保守。

保守有保守的道理。React的并發(fā)渲染（Concurrent Rendering）讓時(shí)機(jī)問(wèn)題變得極其復(fù)雜，一個(gè)信號(hào)更新如果在渲染中途觸發(fā)，會(huì)不會(huì)導(dǎo)致死循環(huán)？會(huì)不會(huì)破壞時(shí)間切片？

社區(qū)方案目前的答案是：createEffect在微任務(wù)隊(duì)列里調(diào)度，故意不和React的渲染幀搶資源。這個(gè) trade-off 犧牲了最低延遲，換來(lái)了安全性。夠不夠用，取決于你的場(chǎng)景。

作者沒(méi)說(shuō)的是：這個(gè)方案已經(jīng)在某個(gè)生產(chǎn)環(huán)境里跑了多久、撐住了多少流量。但代碼的完整度和測(cè)試覆蓋率暗示這不是玩具項(xiàng)目——有完整的TypeScript定義，有React適配層的邊界情況處理，甚至還有和Next.js App Router的兼容說(shuō)明。

如果你現(xiàn)在就想試，作者提供了現(xiàn)成的模板。但更值得觀察的是這個(gè)模式的演化：Signals會(huì)不會(huì)成為React的標(biāo)配？官方和社區(qū)方案最終是合并還是分叉？以及，有多少開(kāi)發(fā)者愿意為了"更干凈的數(shù)據(jù)流"承擔(dān)額外的學(xué)習(xí)成本？

最后一個(gè)問(wèn)題留給正在讀的你：在你的項(xiàng)目里，有多少useEffect其實(shí)是在管數(shù)據(jù)而不是管DOM？數(shù)清楚這個(gè)數(shù)字，可能比選哪個(gè)方案更重要。