好消息，最近React 官方 正式 推出了Canary 版本发布渠道。小编把Canary 版本发布渠道定义为“应急绿色通道”。如果React 正式发布Beta 的时候，结果经过开发者社区紧急反馈出现了Bug之类的，那这个时候React 研发团队会第一时间进行积极处理解决。
React 团队希望给 React 社区提供一个选项，使其可以在新功能的设计接近完成时就可以选择使用这些功能，而不必等到它们发布为稳定版本，因此引入了一个新的官方支持的 Canary 发布渠道，这个渠道将使用单独的 React 功能与 React 发布计划解耦。
概述：
- React 团队为 React 引入官方支持的 Canary 发布渠道。由于它得到官方支持，如果出现任何回归，将像对待稳定版本中的错误一样紧急处理。
- 使用 Canary 可以在它们被发布为稳定的语义化版本之前开始使用单独的新 React 功能。
- 与实验功能不同，React Canaries 仅包含有理由相信可以采用的功能，鼓励框架考虑捆绑固定的 Canary React 版本。
- 将在 React 官方博客上宣布 Canary 版本中的重大更改和新功能。
- React 将在每个稳定版本中继续遵循语义化版本（Semver）。
全文大纲
- React 介绍
- React 功能通常是如何开发的？
- React 可以做更多的次要版本吗？
- React 为什么不使用实验版本呢？
- React 提前宣布重大变更和新功能
- 必须固定 Canaries
- 示例：React 服务器组件
- 同时针对稳定版本和 Canary 版本进行测试
React 介绍
官网：https://react.dev/
Github：https://github.com/facebook/react
现在最热门的前端框架，毫无疑问是 React。
React 起源于 Facebook 的内部项目，因为该公司对市场上所有 JavaScript MVC 框架，都不满意，就决定自己写一套，用来架设 Instagram 的网站。做出来以后，发现这套东西很好用，就在2013年5月开源了。
由于 React 的设计思想极其独特，属于革命性创新，性能出众，代码逻辑却非常简单。所以，越来越多的人开始关注和使用，认为它可能是将来 Web 开发的主流工具。
这个项目本身也越滚越大，从最早的UI引擎变成了一整套前后端通吃的 Web App 解决方案。衍生的 React Native 项目，目标更是宏伟，希望用写 Web App 的方式去写 Native App。如果能够实现，整个互联网行业都会被颠覆，因为同一组人只需要写一次 UI ，就能同时运行在服务器、浏览器和手机。
react特性
- 专注于视图层
- 虚拟dom，最大程度减少直接与dom的交互
- JSX 是js的扩展
- 组件化 使得代码更容易复用
- 单向响应式的数据流
React的优点
- React速度很快：它并不直接对DOM进行操作，引入了一个叫做虚拟DOM的概念，安插在javascript逻辑和实际的DOM之间，性能好。最大限度减少DOM交互。
- 跨浏览器兼容：虚拟DOM帮助我们解决了跨浏览器问题，它为我们提供了标准化的API，甚至在IE8中都是没问题的。
- 一切都是component：代码更加模块化，重用代码更容易，可维护性高。这样当某个或某些组件出现问题是，可以方便地进行隔离。每个组件都可以进行独立的开发和测试，并且它们可以引入其它组件。这等同于提高了代码的可维护性。
- 单向数据流：Flux是一个用于在JavaScript应用中创建单向数据层的架构，它随着React视图库的开发而被Facebook概念化。减少了重复代码，这也是它为什么比传统数据绑定更简单。
- 同构、纯粹的javascript：因为搜索引擎的爬虫程序依赖的是服务端响应而不是JavaScript的执行，预渲染你的应用有助于搜索引擎优化。
- 兼容性好：比如使用RequireJS来加载和打包，而Browserify和Webpack适用于构建大型应用。它们使得那些艰难的任务不再让人望而生畏。
React 的缺陷
- React 只是一个视图库，而不是一个完整的框架。
- 对于 Web 开发初学者来说，有一个学习曲线。
- 将 React 集成到传统的 MVC 框架中需要一些额外的配置。
- 代码复杂性随着内联模板和 JSX 的增加而增加。
- 如果有太多的小组件可能增加项目的庞大和复杂。
React 官网
React 功能通常是如何开发的？
通常，每个 React 功能都经历以下阶段：
- 首先，开发一个最初版本，并在 API 名称前添加 experimental_ 或 unstable_ 前缀。该功能仅在实验发布渠道中可用。此外，预计该功能将发生重大变化。
- 在 Meta 找到一个团队帮助测试此功能并提供反馈，随着功能变得更加稳定，与 Meta 的更多团队合作进行试用。
- 从 API 名称中删除前缀，并默认情况下将该功能置于 main 分支上。此时，任何 Meta 团队都可以使用此功能。
- 随着信心的增加，还会发布新功能的 RFC。此时，该功能适用于广泛的案例，但可能会在最后一刻进行一些调整。
- 当接近发布开源版本时，为该功能编写文档，并最终在稳定的 React 发布中发布该功能。
这个流程对迄今发布的大部分功能都很有效。然而，通常存在一个功能一般可用（步骤3）和在开源中发布该功能（步骤5）之间存在显著差距。React 团队希望为 React 社区提供一个与 Meta 相同的选项，可以在早期采用单个新功能（在可用时），而无需等待 React 的下一个发布周期。和以前一样，所有 React 功能最终都会成为稳定版本。
React 可以做更多的次要版本吗？
通常，确实使用次要版本来引入新功能。然而，这并不总是可行的。有时，新功能与其他尚未完全完成且仍在积极迭代的新功能相互关联。就无法单独发布它们，因为它们的实现是相关的。不能单独对它们进行版本控制，因为它们会影响相同的包（例如，react 和 react-dom）。需要保持对未准备好的部分进行迭代的能力，而不需要进行大量的主要版本发布，这是 semver 所要求的。
在 Meta，通过从 main 分支构建 React，并每周手动更新到特定的固定提交来解决了这个问题。这也是 React Native 在过去几年中一直遵循的方法。每个稳定版本的 React Native 都固定在 React 存储库的 main 分支中的特定提交。这使得 React Native 可以包括重要的 bugfixes，并在框架级别逐步采用新的 React 功能，而不会与全局 React 发布计划耦合。
React 团队希望将此工作流程提供给其他框架和策划设置。例如，一个基于 React 的框架可以在这个框架将此重要变更纳入一个稳定的React发布之前，包含与 React 相关的重大变更。这特别有用，因为一些重大变更仅会影响框架集成。这允许框架在不破坏 semver 的情况下在其自己的次要版本中发布此类更改。semver。
通过 Canaries 频道进行滚动发布将在社区内拥有更紧密的反馈循环，并确保新功能得到全面测试。这个工作流程更接近于 TC39，即 JavaScript 标准委员会，处理编号阶段中的变化的方式。新的 React 功能可能在基于 React 构建的框架中可用，然后才进入 React 稳定版本，就像新的 JavaScript 功能在正式批准为规范的一部分之前在浏览器中发布一样。
React 为什么不使用实验版本呢？
尽管在技术上可以使用实验版本，但建议不要在生产中使用它们，因为实验 API 在稳定的过程中可能会经历重大的破坏性更改（甚至可能完全删除）。虽然 Canaries 也可能存在错误（与任何版本一样），但 React 团队计划今后在博客上宣布 Canaries 中的任何重大突破性更改。Canaries 是最接近 Meta 内部运行代码的版本，因此通常可以预期它们相对稳定。但是，在更新固定提交之间，需要保持版本固定并手动扫描 GitHub 提交记录。
预计大多数在策划设置（如框架）之外使用 React 的人将希望继续使用稳定版本。但是，如果正在构建一个框架，可能需要考虑将 React 的 Canary 版本捆绑到一个特定的提交，并按照自己的节奏更新它。这样做的好处是，它可以让我们更早地为用户并按照自己的发布时间表发布单独完成的 React 功能和错误修复，类似于过去几年 React Native 一直在做的事情。缺点是将承担额外的责任来审查哪些 React 提交被拉入，并与用户沟通哪些 React 更改包含在发布中。
React 提前宣布重大变更和新功能
Canary 版本代表了在任何给定时间内进入下一个稳定 React 发布的最佳猜测。
以前只在发布周期结束时（进行主要发布时）宣布重大变更。现在，由于 Canaries 是官方支持的一种使用 React 的方法，React 团队计划转向在它们落地时就宣布重大变更和重要的新功能。例如，如果合并了一个将在 Canary 中发布的重大变更，就会在 React 博客上撰写一篇文章，包括代码重构和迁移说明（如果有必要）。最后，当稳定的 React 主要版本准备就绪时，将链接到已经发布的博客文章。
React 团队计划在 API 登陆 Canaries 时记录它们，即使这些 API 在 Canaries 之外尚不可用。仅在 Canaries 中可用的 API 将在相应页面上以特殊注释标记。这将包括像 use 这样的 API，以及其他一些 API（如 cache 和 createServerContext），将为其发送 RFC。
必须固定 Canaries
如果决定为应用或框架采用 Canary 工作流程，需要确保始终固定正在使用的 Canary 版本。由于 Canary 是预发布版，因此它们可能仍包含重大更改。
示例：React 服务器组件
React 服务器组件约定已经完成，预计不会对其面向用户的 API 约定进行重大的破坏性更改。然而，现在还不能在 React 的稳定版本中发布对 React 服务器组件的支持，因为仍在研究几个相互交织的仅限框架的功能（例如资源加载），并且预计还会有更多的重大变更。
这意味着 React 服务器组件已准备好被框架采用。然而，在下一个主要的 React 发布之前，框架采用它们的唯一方法是发布一个固定的 React Canary 版本。（为了避免捆绑两个 React 版本，希望这样做的框架需要强制将 react 和 react-dom 解析到他们发布自己的框架所附带的固定 Canary 版本，并向其用户解释。例如，Next.js App Router 就是这样做的。）
同时针对稳定版本和 Canary 版本进行测试
React 团队不希望库作者测试每个 Canary 版本，因为这会非常困难。然而，就像三年前介绍 React 不同预发布渠道时一样，鼓励库针对最新的稳定版本和最新的 Canary 版本运行测试。如果发现未经公布的行为变化，可以在 React 存储库中报告错误，以便能够帮助诊断问题。预计随着这种做法越来越普遍，它将减少将库升级到 React 新主要版本所需的工作量，因为意外回归会在它们登陆时被发现。
