Breaking change 概念：
"Breaking change"（翻译为“破坏性变更”）是指在软件开发中对现有功能或接口进行的修改，这种修改可能导致现有的代码、功能或者接口无法与之前的版本兼容。这种变更可能会打破依赖于原有行为的代码，因此称之为“破坏性变更”。
Breaking change可能包括以下几个方面：
- API变更： 修改了现有的应用程序编程接口（API），可能会导致之前依赖于该API的代码无法正常运行。
- 功能变更： 对现有功能进行了修改，可能导致依赖于这些功能的代码无法正常工作。
- 配置项变更： 对配置项的修改，可能需要用户重新配置应用程序或服务。
- 数据模型变更： 对数据模型或数据库结构的修改，可能导致之前的数据不再兼容，需要进行迁移或转换。
Breaking change 是需要谨慎处理的，因为它可能引起现有系统的不稳定性和不可预测的行为。为了最小化对用户和开发者的影响，开发者在引入 breaking change 时通常需要进行以下操作：
- 文档更新： 更新相关文档，明确说明变更内容、影响以及可能的迁移步骤。
- 版本升级： 如果是库或框架的发布，通常需要发布一个新版本，并在发布说明中清晰地标明 breaking change。
- 向后兼容性： 尽量在可能的情况下保持向后兼容性，提供过渡期，以便用户和开发者能够逐步迁移。
- 通知： 向用户、开发者或团队成员提供足够的通知，提前告知即将发生的变更，以便做好准备。
在敏感的环境中，特别是在大型项目或开发者社区中，引入 breaking change 需要慎之又慎，以确保最小化对系统的影响，同时提供清晰的迁移路径。
Breaking change需要重点注意事项：
引入 breaking change 需要特别注意一些事项，以确保最小化对系统和用户的影响，提供清晰的迁移路径。
- 文档更新： 及时更新相关文档，包括发布说明、API文档、使用手册等，详细描述 breaking change 的内容、原因和可能的迁移步骤。清晰的文档可以帮助用户和开发者更好地理解变更，减少困惑和错误的发生。
- 版本管理： 使用合适的版本管理规范，例如语义化版本（Semantic Versioning，SemVer）。在 SemVer 中，breaking change 通常对应主版本号的增加，这有助于用户清晰地了解到引入 breaking change。
- 向后兼容性： 在可能的情况下，尽量保持向后兼容性。如果无法避免 breaking change，考虑提供适配层或兼容性桥接，使得老版本的代码仍能够在新版本中正常运行。
- 发布前通知： 提前向用户、开发者或团队成员发出发布通知，明确指出即将引入的 breaking change，提供充分的时间供用户准备迁移。可以通过邮件、博客、社交媒体等渠道进行通知。
- 测试覆盖： 在引入 breaking change 前，进行充分的测试覆盖，确保变更不会引入新的错误，并验证迁移步骤的正确性。自动化测试是确保稳定迭代的重要手段。
- 迁移指导： 在文档中提供详细的迁移指导，包括对旧版本的用户或开发者的建议、示例代码和可能的陷阱。帮助他们顺利完成迁移过程。
- 社区反馈： 在开发者社区或用户群体中，主动征询反馈，了解他们对 breaking change 的看法和可能遇到的问题。及时回应并解决用户的疑虑。
- 监控和回滚计划： 在引入 breaking change 后，监控系统的运行状况，密切关注可能出现的问题。同时，准备好回滚计划，以便在需要时能够快速回退到旧版本。
- 记录历史变更： 维护一个清晰的变更历史记录，包括每个版本引入的 breaking change，这有助于用户跟踪系统的演进，并更好地理解新版本的变更。
- 团队协作： 在团队内部加强沟通和协作，确保所有成员了解 breaking change 的计划和实施，避免因为沟通不畅而引发问题。
