PureScript是一门编译到JavaScript的强类型纯函数式编程语言，语法类似Haskell，类型系统包含高阶类型、类型类、Row类型等高级特性。对于已经积累了大量React代码的团队来说，把部分业务迁移到PureScript，可以获得编译期更强的保障，尤其是对 null 处理、副作用隔离和数据建模的严格要求，能从源头上消灭一大类隐蔽的线上Bug。本文围绕迁移的整体思路、框架选型、互操作方案和落地步骤展开，帮助你在不完全推翻现有系统的情况下平稳过渡。
一、为什么值得迁移：PureScript类型系统的实际收益
TypeScript的类型系统在严格模式下已经相当强大，但它终究是JavaScript之上的一个可选层，任何 any、类型断言或不安全的强转都可能让类型检查形同虚设。PureScript则不同，它从语言设计之初就是强类型的，没有 null 和 undefined，所有可能失败的操作都强制要求通过 Maybe 类型表达，所有异步操作通过 Aff 或 Effect 表达，编译器不允许你在纯函数中悄悄发起一次网络请求。
这种严格性带来的直接收益是：大量在TypeScript中需要靠单元测试或人工Code Review才能发现的问题，在PureScript里直接变成了编译错误。比如接口返回字段缺失、状态机的非法状态转移、忘记处理错误分支等，都是典型的"能跑但有坑"的场景。举个数据建模的例子，在TypeScript中我们常这样写：
// 类型正确，但null风险依然存在
interface User { name: string; email: string | null }
const greeting = (u: User) => `Hello, ${u.name} (${u.email.toLowerCase()})`;
而PureScript要求显式处理缺失的情况，这段代码在编译期就会被拦截：
type User = { name :: String, email :: Maybe String }
greeting :: User -> String
greeting u = "Hello, " <> u.name <> " (" <> fromMaybe "no email" u.email <> ")"
当然，收益的另一面是学习成本。PureScript没有类继承，副作用需要通过Monad管理，团队需要一段时间适应Point-free风格和不可变数据的思维。建议在迁移前先在一个独立模块里做小规模试点，评估团队的真实接受度。
二、前端框架选型：Halogen还是React Basic
PureScript生态中有两个主流的前端方案，选择哪一条路线会直接影响迁移的工作量。第一个是Halogen，它是PureScript社区最成熟的组件化框架，采用自研的虚拟DOM，组件模型基于输入输出查询，非常适合从零构建新页面。Halogen的组件有自己的状态容器和求值器，写法上和React的类组件有几分神似，但整体更加函数化。
第二个方案是react-basic，它直接绑定React本身，你可以继续使用React的生态和现有组件库，只是用PureScript来写组件逻辑。如果你的迁移策略是渐进式的，react-basic通常是更务实的选择，因为它允许PureScript组件和TypeScript组件混在同一个React应用里，不需要一次性切换整套渲染体系。
module App.Component where
import React.Basic.DOM as R
import React.Basic.Hooks as React
counter :: React.Component {}
counter = React.component "Counter" \_ -> React.do
count <- React.useState 0
pure
$ R.button
{ onClick: React.handler_ $ void $ React.modifyState (_ + 1) count
, children: [ R.text ("Clicked " <> show (React.read count) <> " times") ]
}
简单对比一下两个方案的取舍：Halogen胜在纯粹和类型安全边界完整，react-basic胜在与现有React代码的无缝混合。如果团队打算长期投入PureScript，最终目标是用它承接全部前端，Halogen更值得押注；如果只是想把核心业务逻辑做成强类型库，让视图层继续留在React，react-basic加Foreign Function Interface的方式会更轻量。
三、与现有JavaScript代码的互操作
渐进式迁移的核心是互操作。PureScript通过Foreign Function Interface（FFI）与JavaScript通信，任何现有的npm包、内部SDK都可以被包装成PureScript模块使用。FFI的写法是在PureScript侧声明类型签名，在JavaScript侧提供实现：
-- PureScript侧声明 foreign import formatDate :: String -> String -> Effect String
// 对应的JavaScript实现
exports.formatDate = function (template) {
return function (dateStr) {
return function () { // Effect 的延迟执行包装
return dayjs(dateStr).format(template);
};
};
};
需要注意的是，FFI是类型安全的盲区。编译器会无条件信任你在签名里写的类型，一旦声明和实际行为不一致，错误只会在运行时暴露。因此建议为每一个FFI封装都编写QuickCheck或单元测试，并且尽量用 Maybe、Either 把可能为空的JS返回值包起来，而不是直接使用 unsafeCoerce 这类逃生舱口。
反方向上，编译产物本身就是普通JavaScript模块，可以通过spago构建后在React项目中直接import。实践中常见的做法是：把表单校验、状态机、权限计算这类纯逻辑抽成PureScript包，视图层不动，这样迁移的风险被压缩到最小。
四、分阶段迁移的完整路线图
第一阶段是环境搭建。在现有React项目的monorepo里新增PureScript包，配置spago作为包管理器和构建工具，通过npm script把spago build接入现有的打包流程。这个阶段不改任何业务代码，只验证工具链能跑通，包括热更新、产物引用和CI集成。
第二阶段是逻辑层试点。挑选一个边界清晰、测试覆盖较好的模块（比如表单校验或数据处理），用PureScript重写并通过FFI暴露给React调用。这一步的重点是建立FFI封装的规范模板，同时让团队熟悉PureScript的调试方式，比如用spago repl做交互式验证。
第三阶段是组件层迁移。如果选择react-basic路线，可以按页面逐个替换组件；状态管理方面，传统的Redux或Context可以逐步换成PureScript的 Aff 加 Ref 组合，副作用全部收口到 Aff 的错误通道里，配合类型类约束保证副作用不会被随意调用。路由可以继续用现有的 history 方案，通过FFI桥接即可，不必强行替换。
第四阶段是收尾和固化。移除过渡期的兼容层，把PureScript的编译警告当作错误处理，在CI里加入类型检查门禁，并为团队沉淀FFI封装的编码规范。这个阶段还要评估包体积的变化，PureScript核心运行时很小，通常体积增量可控，但引入Halogen后需要做一次完整的bundle分析。
五、常见坑与应对建议
迁移中最常遇到的问题有三个。第一是生态缺口，某些React组件库没有现成的PureScript绑定，解决办法是用react-basic直接消费JSX，或者自己写一层薄薄的FFI封装。第二是编译错误信息的学习曲线，PureScript的报错经常涉及类型类约束和Row类型，初期读起来比较吃力，建议从约束最少的简单类型开始逐步加深。第三是团队招聘和维护成本，PureScript开发者远比TypeScript稀少，代码可读性和文档投入必须跟上，否则后期容易变成少数人的"祖传代码"。
总体来说，React应用迁移到PureScript是一次收益与成本都很明确的技术决策。用react-basic做渐进式混合是风险最低的起点，让强类型系统先在纯逻辑层发挥价值，再根据实际效果决定是否推进到视图层。只要路线图切分得当，这条迁移之路并不像想象中那么陡峭。
PureScriptReact迁移函数式编程修改时间：2026-09-15 06:10:36