把一个已经跑起来的React应用迁到Haskell加Yesod的技术栈上，听起来像是自讨苦吃的决定，但确实有一批团队认真做了这件事，并且拿到了实打实的回报。Yesod是一个基于Haskell的Web框架，最大的卖点不是性能，而是类型安全——路由、表单、数据库查询、HTML渲染，全链路都能在编译期被类型系统兜底。本文把整个迁移过程的思考、方案和踩坑记录整理出来，供想走纯函数式路线的团队参考。
一、为什么要迁移：React技术栈的真实痛点
先说清楚迁移的动机，否则后面的一切都站不住脚。React本身是个优秀的视图库，但围绕它的生态在大型项目中暴露出几个顽固问题。第一是类型边界模糊，即使全面启用TypeScript，运行时的数据校验依然依赖手写的运行时检查或者第三方库，类型系统和实际运行的数据之间始终存在缝隙。第二是安全防护靠自觉，XSS转义、CSRF令牌、SQL参数化这些事情，框架只能提醒不能强制，一旦某处代码疏忽，攻击面就出现了。
Yesod对这两个问题的回答相当激进。它的模板语言Hamlet会在编译期检查HTML结构是否闭合，所有插值默认HTML转义，要输出原始内容必须显式声明类型。路由系统通过类型安全的Link类型保证你根本拼不出一个指向不存在页面的URL，如果删除了某个路由，所有引用它的链接在编译期直接报错。Persistent这个ORM层用模板Haskell生成数据模型，查询代码中的字段名和类型都经过编译器检查，SQL注入在语言层面就不可能发生。
代价也很明显：团队需要学习一门纯函数式语言，Monoid、Functor、Monad这些抽象不是一周能上手的，Haskell的招聘难度也远高于前端工程师。所以迁移决策前，建议先用一个边缘模块做试点，量出真实的开发效率曲线再决定是否全量推进。
二、架构对比：路由、状态与渲染的差异
React应用通常是SPA架构，前端持有路由状态，后端只提供JSON接口。迁移到Yesod后，推荐的架构回归服务端渲染为主，路由由框架统一管理。这不是倒退，而是职责的重新划分：URL路由、权限检查、数据获取都收敛到服务端，前端只保留必要的交互逻辑，可以继续用React挂在局部，也可以换成Elm或者干脆用原生Hamlet模板。
两者的状态管理差异巨大。React里全局状态依赖Redux或Context，状态变更分散在各个reducer中，排查Bug时经常要在浏览器里打断点追踪。Yesod的请求处理是一个纯函数式的管道，每个Handler都在HandlerFor这个Monad中运行，会话、缓存、数据库连接都由框架的类型系统明确传递，不存在隐式的全局可变状态。这种约束初期会让人不适应，写个计数器都要通过modifySession，但换来的是并发场景下的确定性——同样的请求输入，处理逻辑完全可预测。
渲染方面，Hamlet模板的缩进语法一开始看会觉得奇怪，但它的编译期检查确实能省掉不少低级错误。下面是一个典型的路由定义加Handler示例，感受一下风格：
-- 路由定义 routes 文件
/home HomeR GET
/articles/#ArticleId ArticleR GET POST
/api/health HealthR GET
-- 对应的 Handler
getArticleR :: ArticleId -> Handler Html
getArticleR articleId = do
article <- runDB $ get404 articleId
defaultLayout $ do
setTitle $ toHtml $ articleTitle article
$(widgetFile "article")
注意get404这个函数，它把"查不到就返回404"这个常见逻辑封装成了类型明确的操作，不需要在每个接口里手写判断。
三、实战迁移：类型安全路由与Persistent数据层
具体动手迁移时，建议按"数据模型、路由、页面、表单"的顺序推进。先迁移数据模型，Persistent的定义方式如下：
share [mkPersist sqlSettings, mkMigrate "migrateAll"] [persistLowerCase|
Article
title Text
content Html -- 存储经过消毒的HTML
authorId AuthorId
publishedAt UTCTime
deriving Show
Author
name Text
email Text
UniqueEmail email
deriving Show
|]
这段代码会在编译期生成Article实体类型和配套的查询函数，数据库表结构迁移也随之自动管理。与React项目中常见的Sequelize或Prisma相比，Persistent的优势是字段类型直接对应Haskell类型，任何查询中的字段拼写错误都过不了编译这一关。
表单处理是Yesod的强项。它提供的Formine类型组合器可以同时生成HTML表单和解析校验逻辑，一份定义两头复用：
articleForm :: Html -> MForm Handler (FormResult Article, Widget)
articleForm extra = do
(titleRes, titleView) <- mreq textField "标题不能为空" Nothing
(contentRes, contentView) <- mreq htmlField "正文不能为空" Nothing
let articleRes = Article <$> titleRes <*> pure mempty
<*> pure authorKey
<*> lift getCurrentTime
let widget = $(widgetFile "article-form")
return (articleRes, widget)
htmlField会自动对用户提交的HTML做消毒处理，剥离script标签和事件属性，这比在React里手动引入DOMPurify再封装一层要省心得多。CSRF防护也是默认开启的，表单生成时自动嵌入令牌，提交时自动校验，想绕过反而需要显式关闭。
四、踩坑总结与适用场景判断
迁移过程中有几个坑值得提前知道。一是编译时间，项目规模上去之后，全量编译可能要几分钟，增量编译的配置很关键，建议尽早启用ghc的并行编译并把无关模块拆成独立包。二是团队里保留一部分React并非坏事，复杂的前端交互（比如拖拽看板、实时协作）继续用React实现，通过类型安全的JSON序列化（ToJSON和FromJSON类型类）与服务端通信，比强行用Hamlet重写更划算。
三是依赖管理，Stack或Cabal的依赖解析偶尔会遇到版本冲突，锁定一个LTS resolver并且升级节奏放慢一点，能避免大部分麻烦。另外Yesod的文档虽然完整但示例偏少，遇到问题时GHC的错误信息阅读能力就成了硬门槛，建议团队里至少有一人能熟练读懂类型错误。
最后说说适用场景。如果你的应用是内容驱动型网站、后台管理系统或者对安全性要求极高的业务（金融、医疗数据处理），Yesod的类型安全体系收益非常明显，编译通过基本等于一大类Bug不存在。如果产品重心在富交互体验上，前端逻辑复杂而服务端只是薄薄一层API，那么全量迁移的性价比不高，保留React前端、把后端换成Haskell的Servant可能更合适。技术选型没有银弹，关键是想清楚你要用类型系统换取什么，又愿意为此付出多少学习成本。