本文深入探讨了react router dom在ci/cd流程中部署到s3/cloudfront时，browserrouter导航功能异常的现象。当应用通过ci构建并部署时，url会更新但页面不刷新，而手动部署或本地运行则无此问题。研究发现，此问题主要与react-router-dom的特定版本（6.12.1）有关，并提供了降级版本和关注官方github问题的解决方案。
1. 问题现象与背景
在使用React Router Dom构建单页应用（SPA）时，开发者通常会选择BrowserRouter来实现客户端路由。然而，在某些特定的部署场景下，尤其是通过持续集成/持续部署（CI/CD）流程将应用部署到如AWS S3配合CloudFront这样的静态托管服务时，可能会遇到一个奇怪的导航问题：尽管浏览器地址栏的URL已正确更新，但页面的实际内容并未随之改变，用户界面（UI）保持不变。此时，只有通过手动刷新页面，才能显示出正确的视图。
值得注意的是，在本地开发环境（npm start）或通过手动构建并上传到S3的方式部署时，导航功能一切正常。这表明问题并非出在React Router的配置或应用代码本身，而是与CI/CD构建和部署过程中的某个环节紧密相关。
2. 典型的部署环境配置
为了更好地理解问题，我们首先回顾一下典型的S3/CloudFront静态SPA部署配置：
托管服务：AWS S3 Bucket（用于存储静态文件）与AWS CloudFront（内容分发网络，提供CDN加速和SSL）。CI/CD工具：GitHub Actions或Terraform等自动化工具，负责应用的构建、测试和部署。错误页面处理：为了支持SPA的客户端路由，CloudFront通常会配置一个自定义错误响应，将404错误重定向到index.html并返回200状态码。这确保了当用户直接访问非根路径时，CloudFront仍能返回SPA的入口文件，由客户端路由来处理具体的路径匹配。应用栈：Node.js (例如16.10.0), React (例如18.2.0), React Router Dom (例如6.12.1)。
以下是相关的Terraform配置示例，展示了CloudFront如何处理错误页面：
resource "aws_cloudfront_distribution" "app_distribution" { // ... 其他配置 ... default_root_object = "index.html" // 默认根对象 custom_error_response { error_code = 404 response_code = 200 response_page_path = "/index.html" // 404错误重定向到index.html error_caching_min_ttl = 0 } // ... 其他配置 ...}
Terraform部署S3对象的部分通常如下，它将build目录下的文件上传到S3：
resource "aws_s3_bucket_object" "app_files" { for_each = fileset("${path.module}/app/build", "**/*.*") bucket = aws_s3_bucket.app_bucket.id key = each.value source = "${path.module}/app/build/${each.value}" etag = filemd5("${path.module}/app/build/${each.value}") content_type = lookup(var.mime_types, split(".", each.value)[length(split(".", each.value)) - 1], "application/octet-stream")}
这些配置在大多数情况下都能正常工作，并被广泛应用于SPA的部署。因此，当出现导航问题时，排查的重点往往不在这些基础设施配置本身。
3. 问题根源分析：React Router Dom 版本特定问题
经过深入排查和社区反馈，发现此导航问题并非由基础设施配置或CI/CD流程本身引起，而是与react-router-dom库的一个特定版本更新有关。
关键发现：
问题在react-router-dom 6.12.1 版本中被引入。在 6.11.2 和 6.12.0 版本中，导航功能是正常的。
这意味着，当CI/CD流程在构建阶段安装了react-router-dom 6.12.1 版本时，部署后的应用就会出现导航异常。而如果手动构建时使用的版本是6.12.0或更早版本，或者CI/CD部署的是一个预先在本地使用旧版本构建好的build文件夹，则不会出现问题。这解释了为何手动部署和CI部署行为不一致。
社区已在GitHub上报告了此问题，例如在remix-run/react-router/issues/10579中可以找到相关的讨论和进展。
4. 解决方案与建议
鉴于问题是由react-router-dom的特定版本引入，最直接有效的解决方案是降级其版本。
4.1 降级 React Router Dom 版本
将项目中的react-router-dom版本降级到已知稳定且无此问题的版本，例如6.12.0。
修改 package.json：将react-router-dom的依赖版本修改为”react-router-dom”: “6.12.0”。
{ "name": "your-app", "version": "0.1.0", "private": true, "dependencies": { // ...其他依赖 "react-router-dom": "6.12.0", // 修改为稳定版本 // ... }}
重新安装依赖并构建：在项目根目录执行以下命令，清除旧的node_modules并重新安装依赖，然后重新构建应用。
rm -rf node_modules package-lock.json # 或 yarn.locknpm install # 或 yarn installnpm run build
重新部署：将新构建的应用通过CI/CD流程重新部署到S3/CloudFront。
4.2 关注官方GitHub问题
由于这是一个库层面的bug，官方团队通常会发布修复版本。建议关注remix-run/react-router在GitHub上的相关issue（例如#10579），以便及时获取修复信息，并在修复版本发布后升级到最新稳定版本。
4.3 临时性替代方案（不推荐）
在等待官方修复期间，如果降级版本不可行或存在其他兼容性问题，一个临时但通常不推荐的替代方案是：
在本地构建应用： 在本地开发环境中执行npm run build生成build文件夹。将build文件夹提交到代码仓库： 将生成的build文件夹添加到Git版本控制中。CI/CD仅负责部署： 修改CI/CD流程，使其不再执行npm run build，而是直接将已提交的build文件夹内容部署到S3。
这种方法绕过了CI环境中的构建步骤，从而避免了版本问题。然而，它打破了“代码仓库只存源代码”的良好实践，增加了仓库体积，并可能导致版本管理混乱，因此仅应作为短期应急措施。
5. 总结
React Router Dom在CI/CD部署中导航失效的问题，是一个典型的由库版本更新引入的兼容性问题。其核心在于react-router-dom 6.12.1 版本在特定场景下导致BrowserRouter无法正确触发UI更新。通过将react-router-dom降级到6.12.0或更早的稳定版本，可以有效解决此问题。同时，建议持续关注官方GitHub仓库的更新，以便在修复版本发布后及时升级，享受最新的功能和性能改进。在进行任何库升级时，始终建议在受控环境中进行测试，以避免引入新的问题。
以上就是解决React Router Dom在CI/CD部署中导航失效的问题的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1535019.html
微信扫一扫 
支付宝扫一扫 
