ClojureScript 异步编程新姿势：用 core.async <p! 宏实现同步风格

在 ClojureScript 项目中对接现代 JavaScript 库时，异步处理是绕不开的话题。多数主流 JS 库已全面转向 Promise 与 async/await 语法，而 ClojureScript 官方始终坚持自己的 channel 风格异步模型。这种设计理念的差异并不意味着 ClojureScript 无法优雅地与 JS 生态集成 —— 通过 core.async 提供的 <p! 宏，开发者完全可以在 go 块中写出近似同步代码的异步逻辑，同时保持与 JavaScript Promise 的无缝互操作。

核心问题：Promise 链的可读性困境

当直接使用 JS Promise 的 .then、.catch、.finally 方法时，ClojureScript 代码会迅速陷入嵌套回调的泥潭。以 Puppeteer 自动化场景为例，等效的 JavaScript async/await 代码在 ClojureScript 中若不做处理，会呈现如下形态：

(-> (.launch puppeteer)
    (.then (fn [browser]
             (-> (.newPage browser)
                 (.then (fn [page]
                          (-> (.goto page "https://clojure.org")
                              (.then #(.screenshot page #js{:path "screenshot.png"}))
                              (.catch #(js/console.log %))
                              (.then #(.close browser))))))))

这种层层嵌套的线程式写法虽然功能正确，但可读性随异步步骤数量线性下降。代码的缩进层级迅速膨胀，逻辑意图被语法结构淹没，阅读者难以快速识别主流程。与 JavaScript 中 async/await 的线性写法相比，劣势明显。

解决方案：<p! 宏的同步语法糖

ClojureScript 官方推荐的解决方案是利用 core.async 的 <p! 宏。该宏接受一个返回 Promise 的表达式，将其挂起直至 Promise resolve，然后返回解析后的值。整个过程发生在 go 块内部，看起来就像普通的同步赋值：

(:require
   [cljs.core.async :refer [go]]
   [cljs.core.async.interop :refer-macros [<p!]])

(def puppeteer (js/require "puppeteer"))

(go
  (let [browser (<p! (.launch puppeteer))
        page (<p! (.newPage browser))]
    (try
      (<p! (.goto page "https://clojure.org"))
      (<p! (.screenshot page #js{:path "screenshot.png"}))
      (catch js/Error err (js/console.log (ex-cause err))))
    (.close browser)))

这段代码的核心优势在于：它完全保留了 JavaScript async/await 的线性表达特性，同时不需要引入任何新的语法扩展。每个 <p! 调用都对应一个 await 表达式，异常处理也沿用 Clojure 风格的 try/catch 块。代码结构从上至下依次执行，阅读体验与同步代码无异。

工程落地的关键参数

在实际项目中采用该方案时，有几个实践要点值得关注。首先是依赖配置：确保项目中包含 org.clojure/core.async 依赖，这在大多数现代 ClojureScript 脚手架中已是默认选项。其次是宏导入方式：<p! 作为一个宏需要使用 refer-macros 引入，而非普通的 refer。

错误处理层面，<p! 会在 Promise reject 时抛出异常，因此必须在外层使用 try/catch 包裹。如果希望实现类似 JavaScript 中 .catch 的分支处理，可以将多个 <p! 调用分别 wrap 进独立的 try/catch 块，或者使用 clojure.core/try 的多 catch 子句区分异常类型。对于需要清理资源的场景，可在 go 块末尾添加 finally 逻辑，确保资源释放不依赖于成功路径。

性能方面，go 块内部采用轻量级协程模型，不会阻塞线程。每个 <p! 调用都会创建一个临时 channel 用于接收 Promise 的结果，Promise resolve 后值被推送至 channel，go 块继续执行。这一机制的 overhead 在大多数业务场景下可忽略不计，但在高频调用的热路径中建议进行基准测试。

与其他方案的对比

社区中还存在其他几种处理 Promise 互操作的路径。直接使用 .then 链式调用无需额外依赖，但如前所述，可读性随复杂度显著下降。Promesa 库提供了更函数式的 Promise 包装，API 设计接近 Clojure 风格，但会引入额外依赖且与现有 core.async 代码风格不一致。对于已深度使用 core.async 的项目，<p! 宏是成本最低的集成方案，因为它不需要引入新的抽象层。

若项目完全没有使用 core.async 的需求，直接调用 JS Promise 方法配合线程 - first 宏也是合理选择。ClojureScript 官方文档建议根据团队现有技术栈选择路径，而非强行统一。

监控与调试要点

生产环境中使用 <p! 时，有两个监控维度值得注意。第一是 Promise 的超时控制：<p! 本身不提供超时参数，需要在调用前使用 js/Promise.race 包装目标 Promise 与超时 Promise，以防止无限等待。第二是错误追踪：由于异常在 go 块内部抛出，传统的堆栈信息可能不够完整，建议在 catch 块中显式记录上下文信息。

REPL 调试时需要留意，go 块内部的代码执行机制与普通代码不同。<p! 调用后的代码不会立即执行，而是在 Promise resolve 后由 go 块调度器异步执行。这种行为在调试时可能造成时序上的困惑，建议配合 cljs.core.async/>! 或日志打印确认执行顺序。

资料来源：本文代码示例与核心概念参考 ClojureScript 官方 Promise interop 指南，该指南由 Filipe Silva 编写，展示了 <p! 宏在处理 Promise 互操作中的典型用法。ClojureScript 官方当前版本为 1.12.134，core.async 库提供了稳定的 channel 与宏支持。

compilers