高并发下的列表乱序与文档同步

一、整体工作概述今天主要完成了一点bug修复高并发点击的时候列表会乱序以及ai coding实现文档的CRUD同时文档列表要同步渲染。这一大块是ai写的我只是看懂了代码整体技术难度不高而且一部分实现方式比较简单粗暴后面还有优化空间。简单记录一下开发过程作为个人学习与复盘。二、列表顺序随机跳变 bug 修复服务端非确定性行为与前端过度请求交织产生的 Bug服务端存在非确定性行为导致前端频繁点击时骨架屏上的列表顺序会突然打乱出现数据顺序随机跳变的 bug。问题的本质是后端数据库查询时没有显式指定排序例如按照什么sort所以数据库返回数据的顺序没有强制保证在高并发多次连接或缓存刷新时顺序就会随机跳变。bug解决方案是是把下列useEffect删掉就好了。useEffect((){if(currentId){fetchDocs(false);}},[currentId,fetchDocs]);为什么删除那个 useEffect 之后选中文档列表的高亮还在但乱序消失了高亮逻辑的真相 isActive doc._id currentId。这里的 currentId 来自 URLuseParams。当点击 Maps 时URL 变了React 会触发 WikiList 组件重新渲染。此时 docs 数组依然存在于内存中State 未变React 只需要重新计算每个 Item 的 isActive 布尔值并刷新 DOM 即可。根本不需要重新拉取数据。乱序消失的真相 既然不再触发 getAllDocuments也就没有了后端随机排序的干扰前端始终持有第一次加载时第一个 useEffect拿到的那份数据。也就是说前端连击触发 map导致 current ID 改变没法正常拿到后端数据后端又重新返回一遍列表数据把顺序打乱了。我每次都会触发全量数据拉取后端又没有强制排序数据顺序本身就不可靠再加上 useEffect 频繁监听请求拿到新顺序后重新渲染最终导致列表顺序错乱。这里我用 Network 面板验证看了名为 documents 的请求响应联机时能观察到同一个 ID 的元素位置在变化。删掉这个 useEffect不再触发 getAllDocuments 请求不重新拉取数据避开后端随机排序的影响直接保留第一次加载的数据就行。三、删除文档功能实现与疑问在这之后我做了第二个功能这个功能是 AI 实现的我只是把代码看了一遍看懂后做了删除相关的操作。我最初理解的全栈开发思路首先在前端 API 服务层新增一个删除文档的接口供调用前端 UI 事件触发时在 onClick 里绑定这个 API 服务向后端发请求。后端收到请求后在 controller 层执行删除文件的指令并新增对应的删除路由。简化流程即前端 UI 绑定事件 → 事件触发请求 → 请求经前端 API 服务层发给后端 → 后端 controller 响应 → 路由分发 → 对数据库做 CRUD 操作。这里我有个疑问为什么后端新增路由就能直接操作数据库是怎么直接连上数据库的为什么现在后端的 POST、PUT、DELETE 这些路由都能直接操作数据库经过梳理完整的全栈开发思路是前端 UI 绑定事件并触发 API 请求请求经网络到达后端由 “预设” 好的路由进行分发并指派给对应的控制器Controller控制器调用 “启动时已建立” 的数据库连接借助.env 配置加载最终完成对数据库的 CRUD 操作。1. 前端层定义与触发API 服务层定义先在前端 src/api 里写好“删除文档”的接口函数比如用 axios.delete明确告诉浏览器我们要去哪个 URL、带哪个 id、用什么姿势DELETE 方法发请求。UI 事件绑定在 React 组件的按钮 onClick 里直接绑定这个 API 函数。当用户一点封装好的请求就带着数据“起飞”穿过网络直奔后端。2. 后端层接线与派发路由分发 (Routing)这里要注意后端是预先埋伏好路由的。请求一到路由就像个“接线员”看一眼方法DELETE和路径立刻把这个请求“踢”给对应的 Controller。Controller 响应Controller 才是真正的大脑。它负责把请求里的 id 摘出来检查用户有没有权限删然后下达最终的“处决指令”。3. 持久层指令执行数据库 CRUDController 调用数据库工具比如 Mongoose 或 Prisma利用早已建立好的连接管道对数据库执行真正的删除动作。Q1为什么后端“配个路由”就能直接操作数据库路由只是“门牌号”不是“推土机”。你之所以觉得“配了路由就能删”是因为你在写 router.delete() 的时候紧跟着在回调函数里写了操作数据库的代码。路由负责确定“哪个接口对应哪个功能”。Controller 负责在这个功能里真正去改数据库。Q2后端是怎么“直接”连上数据库的连接发生在服务器启动的一瞬间而不是请求来的时候。当你运行后端项目比如 npm run dev时程序会立刻读取 .env 里的数据库地址和密码跟数据库建立一个持久的连接池。平时连接管道是通的处于待命状态。请求来时Controller 只是顺着这个现成的“水管”发了一条指令速度极快。Q3为什么现在的 POST、PUT、DELETE 路由都能操作数据库这是一种语义化约定 (RESTful)而不是物理限制。从技术底层看它们都是 TCP 数据包本质没区别。但为了让代码好维护DELETE约定用来删逻辑上直观。POST/PUT约定用来增和改因为它们可以往请求体Body里塞进复杂的 JSON 结构方便 Controller 拿到完整的数据去更新数据库。四、细节优化与体验改进还有一个细节问题新增和删除文件时左侧 wiki list 整个文档列表没有跟着数据动态更新。当前处理方式是在 window 上挂载事件监听器定义 DOCUMENTS_CHANGED_EVENT 处理文档变化。exportconstDOCUMENTS_CHANGED_EVENTdocuments:changed;exportconstnotifyDocumentsChanged(){window.dispatchEvent(newEvent(DOCUMENTS_CHANGED_EVENT));};useEffect((){consthandleDocumentsChanged(){fetchDocs();};window.addEventListener(DOCUMENTS_CHANGED_EVENT,handleDocumentsChanged);return(){window.removeEventListener(DOCUMENTS_CHANGED_EVENT,handleDocumentsChanged,);};},[fetchDocs]);我觉得这个方式虽然清晰但直接操作 DOM、挂载到 window 上跳出了 React 框架算不上优雅实现简单但有点粗暴后面可能会再改想想怎么放到现有框架里方便调试和维护。另外还有 UX 细节比如删除当前文件后不想显示空白占位 UI希望自动打开列表里下一个文档。这里用了 if 判断定义了 remainingDocs逻辑大概是如果还有数据就从数组里依次读 ID 做路由跳转constremainingDocsawaitgetAllDocuments();if(remainingDocsremainingDocs.length0){navigate(/wiki/${remainingDocs[0]._id});}else{navigate(/wiki);}只有数据全空时才展示空白占位 UI。还有一些警示弹窗就是调用组件库组件Modal再配合国际化没什么难度。五、小结今天做的工作难度不算大解决问题的一些方案也比较粗暴不够优雅。后面我会再想想更合适的实现方式对架构的理解要更多一些加油加油参考文档使用 Fetch - Web API | MDNString.prototype.localeCompare() - JavaScript | MDNArray.prototype.sort() - JavaScript | MDNEventTarget.dispatchEvent() - Web API | MDN​