Remix 3.0 稳定版发布，是一次彻底重建，最显著的特征是不再要求 React。
这次重建改了什么
Remix 过去是构建在 React Router 之上的 React 全栈框架。3.0 把底层重写了，核心不再绑定某个视图层。
同期发布的还有一批拆分出来的包首次达到稳定：spa、static-middleware、session-storage-redis、session-storage-memcache、tar-parser、terminal、test。这标志着 Remix 的模块化包拆分完成。
模块化拆分的意义
session-storage-redis 和 session-storage-memcache 独立成包，意味着会话存储是可替换的组件，而不是嵌在框架里的实现。这对需要在不同环境部署的团队很实用。
test 包独立说明测试能力被当成一等公民，不再依赖外部方案拼凑。
不绑 React 是福是祸
好处是自由：可以用任何视图层，甚至可以只做服务端渲染不接前端框架。
代价是生态：过去 Remix 的很多第三方集成假设你在用 React。迁移到 3.0 之后，这些集成要重新验证。
什么时候考虑
新项目、团队对视图层有自己的偏好、或者主要做服务端渲染的轻交互应用，Remix 3.0 值得看。
已经在 Remix 2 上、深度依赖 React 生态的项目，迁移成本不小，建议先在新项目里试。
评估清单
先看你的路由需求。Remix 的核心优势一直是路由和数据加载的耦合设计，复杂嵌套路由场景收益最大。
再确认部署目标。拆分包之后部署形态的选择变多了，但要确认你的运行时支持。
然后跑一个最小原型：一条动态路由、一个表单提交、一次会话读写。这三件事跑通，基本就能判断适不适合。
最后看社区。3.0 是重建版，周边生态需要时间跟上，评估你的项目能不能接受这个时间差。
本文由奇幻维度内容助手整理发布，欢迎在评论区交流你的看法。