一、从一把辛酸泪说起

很多前端开发者第一次接触 ClojureScript 时，都会为它的简洁语法和不可变数据结构感到惊喜。可一旦开始写真实界面，状态管理就成了绕不开的坎。起初我用一个 atom 就能玩得很开心，后来页面变多，组件之间开始共享数据，问题就一个接一个冒出来。今天想结合自己的实际经历，把那些踩过的坑、用的药，以及最后的架构思路都摊开来讲，希望对你有帮助。

1.1 一个 atom 打天下，爽过之后全是债

ClojureScript 搭配 Reagent 时，最直接的做法就是创建一个全局 atom，然后在组件里读它、改它。写起来非常顺手，因为 Reagent 会自动追踪 atom 的变化，然后重新渲染用到它的组件。这种感觉就像拿了把万能钥匙，什么锁都能开。

可是项目一大，这把万能钥匙就变成了潘多拉魔盒。什么东西都往里塞，购物车、用户信息、页面配置、临时弹窗状态……时间一长，你自己都不记得哪里改了什么。最可怕的是，两个组件共同依赖同一块数据，你在一个地方用了 swap! 更新，另一个地方却因为没订阅到那个原子变量，直接不刷新，页面数据就对不上了。

1.2 手动同步是条不归路

给你看一个典型的悲剧。假设我有一个购物车，还想同时维护一个订单列表。刚开始我脑子很清醒，告诉自己“加购物车的时候一定要同步订单”。可是需求一变，优惠券、库存、运费全搅和进来，总有那么一次忘记同步，线上就出了 bug。代码大概长这样：

;; 技术栈：ClojureScript + Reagent
(ns demo.core
  (:require [reagent.core :as r]))

;; 一个全局 atom，既放购物车又放订单
(defonce app-state (r/atom {:cart [] :orders []}))

;; 往购物车里加东西
(defn add-to-cart! [item]
  (swap! app-state update :cart conj item))

;; 用户点击“立即购买”
(defn buy-now! [item]
  (add-to-cart! item)
  ;; 糟糕，这里忘了同时更新 :orders
  ;; 订单页面因此永远少一条记录
  (js/console.log "购买了" item))

这段代码的问题一眼就能看出来：状态被拆成了两个“半独立”的字段，但我只有一双手，没有办法保证每次操作都能同时更新它们。更麻烦的是，就算我这次记得，下次别人接手代码，也未必会记得。这个 bug 迟早会重演。

二、痛点的根源在哪里

我不是来骂 atom 的，它本身没有错。错的是没有规则。当状态管理只依赖“自觉”的时候，复杂度一起来，人脑就撑不住了。

2.1 一切皆 atom 带来的自由与代价

atom 的优点是自由、简单、无需学习成本。代价是自由过了头，状态可以出现在任何地方，可以由任何人随意修改。没有统一的入口，没有明确的数据流，代码里到处都是 swap!、reset!，排查问题的时候就像在玩“找不同”。

2.2 渲染控制的无力感

Reagent 的 atom 追踪机制确实聪明，但它只保证“用到的 atom 变了，组件会重新渲染”，并不保证“只有需要的组件重新渲染”。如果你在一个很顶层的组件里读取了整个 app-state，那么底下任何小字段更新，整个大组件都会重跑一遍。页面一旦复杂起来，卡顿感就来了，尤其是在低端手机上。

这个时候你会明白：状态管理不只是“存数据”，更是“控制数据如何流动”、“控制谁该更新”。而 atom 显然没有给我们提供足够的抓手。

三、用 re-frame 把状态管起来

后来我接触了 re-frame，突然有种“终于有组织了”的感觉。它把数据流分成几个明确的环节，每个环节只做一件事，彼此不越界。你可以把它理解成一套餐饮管理体系：服务员收单（事件），后厨做菜（处理逻辑），传菜员送菜（订阅），客人吃饭（视图）。每个人都知道自己的位置，出错也容易定位。

3.1 re-frame 的核心循环

re-frame 的数据流是这样的：

  1. 用户在界面上触发一个事件。
  2. 事件处理器拿到当前 app-db，计算出新的 app-db。
  3. 订阅函数从 app-db 中提取视图需要的数据。
  4. 视图组件订阅这些数据，自动更新。

所有的状态变更都必须经过事件，不能绕过。这样一来，原来的“这里忘了同步”就变成了“事件里统一处理”，可控性大幅提升。

3.2 一个完整的购物车示例

下面我用一个更完整一点的购物车例子，带你看看 re-frame 是怎么工作的。这个例子包含初始化数据、添加商品事件、订阅购物车列表和总价，以及最外层的视图组件。

;; 技术栈：ClojureScript + Reagent + re-frame
(ns cart.core
  (:require [reagent.core :as r]
            [re-frame.core :as rf]))

;; 1. 初始化数据库
(def default-db
  {:cart {:items {}          ;; 商品 id -> 数量
          :total 0}})

;; 2. 注册添加商品的事件
(rf/reg-event-db
 ::add-item
 (fn [db [_ item]]
   (let [id (:id item)
         items (get-in db [:cart :items])
         new-count (inc (get items id 0))]   ;; 数量加一
     (assoc-in db [:cart :items id] new-count))))

;; 3. 注册移除商品的事件
(rf/reg-event-db
 ::remove-item
 (fn [db [_ id]]
   (let [items (get-in db [:cart :items])]
     ;; 如果数量大于 1，就减一；否则直接移除这个商品
     (if (<= (get items id 0) 1)
       (update-in db [:cart :items] dissoc id)
       (update-in db [:cart :items id] dec)))))

;; 4. 订阅购物车里的所有商品
(rf/reg-sub
 ::cart-items
 (fn [db _]
   (get-in db [:cart :items])))

;; 5. 订阅购物车总金额
;; 这里假设每个商品单价是 10，只是演示派生计算
(rf/reg-sub
 ::total-price
 (fn [db _]
   (let [items (get-in db [:cart :items])]
     (reduce + 0 (map (fn [[_ count]] (* count 10)) items)))))

;; 6. 视图组件：展示购物车
(defn cart-view []
  (let [items (rf/subscribe [::cart-items])
        total (rf/subscribe [::total-price])]
    (fn []
      [:div
       [:h2 "我的购物车"]
       ;; 遍历所有商品，显示 id 和数量
       (for [[id count] @items]
         ^{:key id}
         [:div
          [:span "商品 " id " x " count]
          [:button {:on-click #(rf/dispatch [::remove-item id])} "移除"]])
       [:p "总价：" @total]
       [:button {:on-click #(rf/dispatch [::add-item {:id (random-uuid)}])}
        "随便加一个商品"]])))

你看，所有操作都走了 rf/dispatch，没有直接修改 db。如果想调整购物车的业务规则，只需要改对应的事件处理器，其他地方不用动。这比之前手忙脚乱地同步两个 atom 字段要省心得多。

3.3 事件流为什么是解药

因为所有的修改都收拢到事件里，所以你永远不会出现“改了购物车，忘了改订单”的情况。就算真的忘了，你也只需要盯住事件里面的处理逻辑，而不是满项目乱翻。数据流是单向的，视图只负责展示，订阅只负责取数，事件只负责更新，调试的时候大脑负担小很多。

四、架构优化的一些实战技巧

理解了 re-frame 的基本用法，接下来我们可以聊一些让代码更健壮的小技巧。

4.1 用规范化数据代替深嵌套

很多初学者喜欢把数据写成“俄罗斯套娃”，比如下单记录里直接嵌套商品详情、用户信息、地址对象。看起来直观，改起来要命。因为只要有一个地方重复嵌套了同一份数据，更新一个副本，另一个副本就不同步了。

建议把数据压平，做成类似数据库表的结构。比如购物车项只存商品 id 和数量，真正的商品详情放在另一个 HashMap 里，按 id 索引。这样修改商品名称时，只需要更新一处。

;; 规范化之前的噩梦
;; {:orders [{:id 1
;;            :product {:name "咖啡" :price 30}
;;            :count 2}]}

;; 规范化之后
;; {:products {1 {:name "咖啡" :price 30}}
;;  :orders   {100 {:product-id 1 :count 2}}}

这样每次只需要通过 id 去查商品信息，数据永远只有一份，不会出现“同一个商品在两个地方显示不同名字”的尴尬。

4.2 让订阅成为“计算缓存”

re-frame 的订阅函数可以是层级式的，也可以组合。当多个组件需要同一份派生数据时，把它提取成一个订阅，既能复用又能缓存。比如下面这个订阅返回“单价大于某个值的商品”，如果基础 items 没变，re-frame 会直接返回上一次的结果，二次计算不会重复执行。

(rf/reg-sub
 ::expensive-items
 :<- [::cart-items]                       ;; 依赖最基础的 items 订阅
 (fn [items _]
   (filter (fn [[_ _]] (> 30 20)) items))) ;; 这里只是演示过滤逻辑

这种写法让计算逻辑独立，视图组件只管消费。

4.3 细粒度订阅，减少无意义渲染

Reagent 的订阅粒度越细，组件重渲染的性能越好。比如不要在购物车页面顶层订阅所有商品，而是让每个商品子组件自己订阅属于自己的那一份数据。下面这个例子，商品组件只订阅它自己的数量：

;; 定义按 id 订阅数量的订阅
(rf/reg-sub
 ::item-count
 (fn [db [_ id]]
   (get-in db [:cart :items id 0])))

(defn single-item [item-id]
  (let [count (rf/subscribe [::item-count item-id])]
    (fn []
      [:div "商品 " item-id " 数量 " @count])))

这样一来，某个商品的数量发生变化，只有那一个商品组件重渲染，其他商品组件完全不受影响。页面再大也不容易卡。

五、应用场景、技术优缺点与注意事项

5.1 适合用 re-frame 的场景

如果你想做的是一个中大型项目，比如管理后台、在线编辑器、数据可视化平台，组件层级深、共享状态多、业务逻辑复杂，那么 re-frame 能给你带来很强的秩序感。它特别适合团队协作，因为规则清晰，大家写出来的代码风格不会差太多。

5.2 技术优缺点

5.2.1 优点

  • 数据流单一，容易追踪，debug 的时候很爽。
  • 订阅机制支持派生数据，把计算逻辑从组件里抽离出来。
  • 事件处理器是纯函数，方便测试。
  • 有官方调试工具 re-frame-10x，可以像看电影一样回放事件。

5.2.2 缺点

  • 学习曲线比单纯的 atom 陡，需要掌握事件、订阅、effect 等概念。
  • 模板代码比较多，小项目里写起来有点“杀鸡用牛刀”。
  • 对于非常简单的界面，强行上 re-frame 会拖慢开发速度。

5.3 注意事项

第一个注意点是：订阅返回的是一个 reaction 对象，不是普通值，在组件里一定要用 @ 去解引用，否则拿不到具体数据。

第二个注意点是：不要把所有副作用都塞进事件处理器。网络请求应该通过 re-frame 的 effect 系统或者单独的逻辑层处理，否则事件函数就变得不可预测。

第三个注意点是：别过度设计。如果你的应用只有三个组件、两个页面，老老实实用 atom 完全没问题。架构是对抗复杂度的，不是用来炫耀的。

六、和裸 atom 的对比总结

如果让我用一句话来概括，那就是：atom 让你自由，re-frame 给你边界。

自由有自由的好处，但真正到了生产环境，边界能救你的命。我不主张所有项目都上 re-frame，但我主张你了解它，并且知道在什么阶段应该做出取舍。当你发现自己在手动同步多个状态、在组件里写了一大坨逻辑、改一个功能要牵连五个地方的时候，就是时候向 re-frame 迈一步了。

前端状态管理没有银弹，任何工具都只是在帮你约束复杂度。重要的不是选最酷的框架，而是让团队里的每一个人都能清晰地回答三个问题：数据从哪来？数据改到哪里去？组件该听谁的？re-frame 给了这三个问题非常体面的答案。

七、文章总结

这篇文章从我对 ClojureScript 状态管理的真实痛点出发，先讲了纯 atom 在复杂场景下的失控，然后介绍了 re-frame 如何通过单向数据流来治理混乱。在这个过程中，我们看了一个完整的购物车示例，聊了规范化数据、细粒度订阅这些实用性很强的优化技巧。最后也认真讨论了 re-frame 的优势、缺点以及适用的项目规模。希望你在读完之后，不需要照搬任何框架，而是能多一种看待前端状态管理的视角。下次再遇到“这里更新了，那里没变”的怪问题时，你能第一时间想到：是不是该给状态立点规矩了。