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

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

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è)過程沒有組件參與，頁面切走了它還在跑，頁面切回來數(shù)據(jù)還是熱的。

對(duì)比React原生的寫法，差別立刻顯現(xiàn)。以前你要么把定時(shí)器塞useEffect里跟著組件生死，要么上Redux-Saga、React Query這種重型方案。現(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)閃爍是純視覺行為，它依賴React的渲染周期——enabled prop變了要立刻停，組件卸載要立刻清。這些時(shí)機(jī)必須對(duì)齊React的commit階段，而不是數(shù)據(jù)的任意變更。

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

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

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

真正用起來的時(shí)候，開發(fā)者面對(duì)的其實(shí)是混合場景。看作者的App.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)建和銷毀。而Blinker組件里的光標(biāo)，該閃還是閃，該停還是停，兩條線互不干擾。

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

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

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

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

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

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

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

React官方的Signals實(shí)現(xiàn)還在RFC階段，具體語法變了好幾稿。社區(qū)方案的優(yōu)勢是現(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)寫到第四篇，每一篇都在補(bǔ)全邊緣場景的處理。

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

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

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

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

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

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

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

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

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