React虚拟列表实战：动态行高、Hover展开与精准滚动定位-北京尧图网络

做前端时间长了总会碰到一个绕不开的场景页面要把几百上千条数据塞进一个列表里每条数据高度还不固定鼠标悬停要展开详情从外部点击某个按钮还要能精准滚到某一项容器宽度一变列表还得跟着重新排。直接arr.map(item Row /)最简单可数据量一上来页面肉眼可见地卡顿切 Tab 回来滚动位置还会丢。这篇文章想分享的就是一套我自己在项目里落地过的 React 虚拟列表方案核心能力正好对应标题里的四点动态行高、Hover 展开详情、精准滚动定位、自适应容器尺寸。适合正在被长列表性能问题困扰的 React 开发者也适合想搞懂虚拟列表底层设计、又不满足于只会用现成库的朋友。文章里没有太多花哨封装全是能从零看懂、可以直接抄去改的代码和思路。1. 先把需求讲透这个列表到底难在哪1.1 哪些场景非用虚拟列表不可很多人对虚拟列表有一个误解数据量几百条也要上虚拟列表结果优化了个寂寞。其实虚拟列表解决的是“渲染 DOM 数量过多导致布局和绘制耗时暴涨”的问题。一个页面上同时存在几千个真实 DOM 节点时光是 style 计算和 reflow 就够主线程喝一壶React 的 diff 和 fiber 调度再快也架不住浏览器底层渲染瓶颈。我接手这个需求时列表数据量大概是 5000 到 10000 条左右每条数据展开前是单行摘要展开后是一段详情文本甚至还有一张缩略图。如果直接全量渲染首屏加载时间直接破 3 秒滚动时帧率掉到 20 帧以下。这类场景才是虚拟列表真正的用武之地。那普通分页行不行行是行但产品需求不允许。业务方要求支持“从外部跳转定位到指定条目”还要支持在同一视口里连续浏览相邻数据分页会把这种连续感完全切断。所以虚拟列表成了唯一能满足体验要求的技术方案。1.2 为什么“动态行高 Hover 展开滚动定位”凑在一起很难固定行高的虚拟列表实现思路非常成熟总量固定每个 item 高度已知用scrollTop / itemHeight就能算出可视区起始索引再预留上下 buffer 就能稳定渲染。真正麻烦的是行高不确定。行高一旦变成动态整个计算模型就变了。你没法用简单除法算出当前滚动位置对应哪一行只能维护一个“每一行累积偏移量”的数组查找时要么线性遍历要么二分。更麻烦的是用户 hover 一行行高会突然变大后面所有行的偏移量都要跟着变滚动位置如果处理不当列表会像触电一样上下跳。精准滚动定位和动态行高叠加之后还带来另一个问题你要滚动到的那一行你的页面里可能根本没有对应 DOM 节点。因为虚拟列表只渲染可视区内少量节点你滚动前目标行可能还在“视口外”没有被创建出来。这就意味着你没法简单调用scrollIntoView必须自己算出目标行的高度和它相对列表总高度的偏移量精确设置滚动容器的scrollTop。1.3 一个标准虚拟列表应当具备的基础能力把需求拆开看一个能落地的虚拟列表至少要满足三件事。第一可视区裁剪。只渲染当前视口可见、再加前后一段缓冲的行其他行统统不渲染这是性能的基础。第二总高度仿真。为了让滚动条长度符合内容总量容器内部必须要有一个“撑高占位”的 div它的高度等于所有行真实高度之和否则滚动条会变成一个畸形的小短条。第三滚动状态同步。滚动事件触发后需要快速算出“现在最顶部是哪一行”“这一行的 y 偏移是多少”然后把内容区整体用 transform 平移过去反复循环。这三件事看起来简单但加上动态行高和交互之后细节会变得非常多。下面我按我们项目里的实现顺序一点一点拆。2. 设计取舍为什么我选择自研而不是直接用现成库2.1 现成方案对比开始动手前我专门花时间对比过社区方案。react-window非常知名性能做得好但它默认固定行高动态行高需要额外用VariableSizeList并且它本身不支持“行内 hover 后内容再撑高”这种场景需要自己配合测量逻辑。react-virtualized功能更全但体积大维护状态也不少。还有react-virtuoso动态测量支持不错但在展开动画和自定义滚动定位这块还是需要写不少胶水代码。最终让我决定自研的根本原因不是现成库不够好而是业务需求里有一条从外部跳转定位到某条数据时需要保证定位精准且不闪跳同时 hove r展开后滚动条不能抖动。这些交互细节在通用组件里往往需要覆盖大量配置项一层层改配置不如直接控制核心逻辑来得顺手。另一方面团队当时对虚拟列表的裁剪算法、缓存策略也有定制需求自研反而节省了沟通成本。2.2 核心数据结构测量缓存怎么设计动态行高虚拟列表的根基是一个科学的“行测量缓存”。我设计了两份数据配合使用一份是数组保存行的顺序和对应高度/偏移量一份是 Map用来做 key 到数组索引的快速映射。只用数组不用 Map外部传入一个 id 想定位时需要遍历整个数组找索引数据量一大很容易卡顿只用 Map 不用数组连续遍历生成可视区列表时又不够方便。两者搭配各司其职。这段缓存结构大致长这样type Measurement { height: number; offset: number; }; const measurements: Measurement[] []; const keyToIndex new Mapstring, number();measurements数组的索引和列表数据的渲染顺序保持一致第 i 项的offset表示它距离列表顶部的距离。每次插入、删除或者高度变化只需要从变化位置开始向后重新计算offset即可不需要全表重算。后面滚动定位、二分查找全部基于这份数组进行。2.3 虚拟滚动窗口和滚动容器的分工组件结构上我保持了两个核心容器的分工。外层是一个div它负责接收滚动事件视觉上固定高度内部会放一个高度等于总列表高度的占位 div让滚动条长度变得真实。内层是一个定位为absolute的渲染容器它会随着滚动把当前可视区域的行渲染出来再用transform: translateY(...)把整个内容往下推到正确位置。这样分层有一个现实好处占位 div 不需要渲染具体业务内容它只是一个高度计数器即使几千行也不会让 DOM 爆炸。真正的业务行只存在于可视区附近的十几个到几十个节点中。外层滚动容器往往还承担“挂载 ResizeObserver”的职责容器宽度变化直接清空缓存重算这个后面会详细聊。3. 动态行高虚拟列表实现的第一道坎3.1 先估计再实测测量两步走动态行高不能靠猜但也不能一开始就把几千行全部渲染出来量一遍那样会直接卡死。我采用的是“先估计、后实测”的两步策略。第一步给每条数据一个预估高度。比如视频标题类数据单行大约 60px那缓存里的每一项初始高度就是 60。估算不准不要紧它只影响首屏渲染滚动过程中会被真实测量结果替换。第二步当某一行真实渲染到可视区后通过useLayoutEffectgetBoundingClientRect().height去取它的真实高度一旦真实高度和预估高度偏差超过 1px就更新测量缓存并把该行之后所有行的 offset 全部重算一遍。这里有个容易被忽略的点测量动作要在useLayoutEffect里做不能在useEffect。因为useEffect在浏览器绘制之后才执行更新高度时用户会看到一次“先画错再修正”的闪跳。useLayoutEffect会在浏览器绘制前同步执行布局计算能把这个错位感基本消除掉。3.2 行高缓存如何做增量更新高度更新不是简单改一行的数据就完事它会影响后续所有行的偏移量。假设第 3 行从 60 变成了 100那第 4 行及以后所有 offset 都要加上 40。我第一次实现时暴力重算了全部数组测试时数据量 5000 条表现还行但压测到 10000 条后每次 hover 展开都隐约感觉到卡顿。后来优化成增量计算只从变化行开始向后累加function updateMeasurement(index: number, newHeight: number) { const delta newHeight - measurements[index].height; if (Math.abs(delta) 1) return; measurements[index].height newHeight; for (let i index 1; i measurements.length; i) { measurements[i].offset delta; } }这样每次 hover 展开后段 offset 的更新是连续的数值加法JavaScript 做纯数万次增量加法非常快基本感知不到。3.3 Hover 展开详情的正确打开方式Hover 展开详情这块我踩过一个特别典型的坑一开始我把“是否展开”的状态存在每个列表项组件内部结果行内容一撑大虚拟列表重新计算可视区后那个展开的行如果滑出可视区DOM 就被卸载再滚回来状态全丢了。后来改成把“当前 hover 的 key”统一存在列表最上层并且只允许同时展开一行问题才根治。展开的行高度变化后要认真处理它的测量时机。我采用的方案是hover 后先让这一项重新渲染为“展开态”然后等浏览器真正布局完再拿getBoundingClientRect()获取整行新高度。展开内容如果包含异步图片还需要监听图片加载完成后的高度变化否则会出现“先获取一个旧高度、图片出来后行高又变”的二次跳变。另外有个小建议不要在展开容器上做“height 过渡动画”。CSS transition 在过渡过程中元素高度会持续产生中间值直接测量拿到的永远是不稳定数据滚动定位也会跟着乱跳。想要动效我更推荐用“内容透明度渐入上移几像素”的动画不改变布局高度测量结果始终稳定。3.4 与展开状态配合的滚动偏移算法hover 展开后行高变大总高度变大如果滚动容器刚好在底部会看到滚动条“弹了一下”。要解决这个体验问题需要在展开后做一次滚动偏移修正。具体逻辑是记录展开前的scrollTop和展开后目标行的offset变化量然后补偿回去。当用户滚动位置靠近底部时让scrollTop自动增加一个与高度增量相等的值这样视觉上内容保持不动不会跳动。我用一个 ref 记录当前行展开前后偏移量的差值然后在高度更新后的同一个布局周期内修正滚动位置const offsetDelta newOffset - oldOffset; if (scroller.scrollHeight - scroller.scrollTop - scroller.clientHeight offsetDelta) { scroller.scrollTop offsetDelta; }这段逻辑必须在测量完成且offset更新后的同一帧内执行否则用户会看到一次明显的跳动。4. 精准滚动定位从“找位置”到“滚到位”4.1 定位的本质根据 key 反推偏移量外部页面传入一个数据 id要求列表滚动到这一项并高亮它这就是“精准滚动定位”的典型需求。动态行高下不能直接document.getElementById(id).scrollIntoView()因为目标行可能根本没有被渲染出来。正确做法分三步第一步从keyToIndex拿到目标 key 在缓存数组中的索引第二步从measurements[index].offset拿到该行顶部距离列表最顶端的精确距离第三步把滚动容器的scrollTop赋值成这个 offset 减去一个期望的“安全偏移量”。这个安全偏移量建议设为容器高度的一个比例比如四分之一这样目标行出现后不会死死顶在视口最顶部视觉更舒服。function scrollToKey(key: string) { const index keyToIndex.get(key); if (index undefined || !scrollerRef.current) return; const targetOffset measurements[index].offset; const maxScrollTop totalHeight - viewportHeight; const targetScrollTop Math.min( Math.max(0, targetOffset - viewportHeight * 0.25), maxScrollTop ); scrollerRef.current.scrollTop targetScrollTop; }4.2 二分查找在虚拟列表里的实际应用滚动过程中需要频繁回答“当前 scrollTop 对应第几行”这个问题。线性遍历当然能算但每帧滚动事件都在触发数据量 10000 条时每次滚动都遍历一遍实在浪费。我的做法是使用二分查找因为measurements数组的offset是严格递增的天然满足二分条件。function findStartIndex(scrollTop: number) { let low 0; let high measurements.length - 1; while (low high) { const mid (low high 1) 1; if (measurements[mid].offset scrollTop) { low mid; } else { high mid - 1; } } return low; }这个函数返回的是“滚动位置所在的行索引”拿到它之后再根据可视区高度向后数出需要渲染的行数即可。二分查找里有个细节取中位数时要向上取整否则当目标值在数组最后一项时循环会陷入死循环。这是我在实测中踩过的坑。4.3 自适应容器尺寸ResizeObserver 的接入容器自适应是这类列表最容易忽略、又最影响体验的需求。宽度变了行的文字换行方式可能变行高跟着变高度变了可视区能容纳的行数也跟着变。如果容器来自某个折叠面板尺寸变化更频繁。现代浏览器里监听元素尺寸变化最靠谱的方式是ResizeObserver。需要注意监听的是外层滚动容器的 content box 尺寸而不是 window 的 resize 事件因为很多场景下容器尺寸变化并不伴随窗口大小变化。宽度变化时直接沿用旧测量缓存放着的基本都是废数据因为同一行在窄容器下可能从单行折成两行高度全变。我的策略是宽度变化时清空全部缓存用预估高度重新填充一遍再强制重新渲染可视区。高度变化不需要清缓存只需要重新计算可视区内的结束索引并刷新滚动条总长度。const resizeObserver new ResizeObserver((entries) { const entry entries[0]; const { width, height } entry.contentRect; if (Math.abs(width - lastWidth) 1) { resetMeasurements(); } setViewportSize({ width, height }); });4.4 rAF 节流与渲染优化滚动事件触发频率远超 React 渲染需要的帧率如果不做节流会造成大量无效 setState。我给滚动事件处理加了一层requestAnimationFrame节流同一帧内只执行一次状态计算一帧中多次 offsed 更新都合并到下一次渲染。let ticking false; function handleScroll() { if (ticking) return; ticking true; requestAnimationFrame(() { updateVisibleRange(scroller.scrollTop); ticking false; }); }这只是性能优化的一条线。另外一条线是列表项外层统一包一层memo组件并自定义areEqual比较函数只有 key、hover 状态和数据本身变化时才重新渲染否则直接复用上一次的 React 元素。配合上稳定 key业务 id绝不使用 index整个滚动的渲染压力能大幅下降。5. 完整可落地的代码骨架5.1 主体组件的实现综合上面的设计思路我把核心组件简化保留成一个可以直接运行的版本。注意这个版本去掉了业务样式和部分边界处理但保留了动态行高、hover 展开、滚动定位、自适应尺寸的全部主干逻辑方便大家在此基础上改自己的业务。import { memo, useLayoutEffect, useMemo, useRef, useState } from react; type Item { id: string; title: string; desc?: string }; type Measurement { height: number; offset: number }; const ESTIMATED_ITEM_HEIGHT 60; const OVERSCAN_COUNT 5; function VirtualList({ items, scrollToKey }: { items: Item[]; scrollToKey?: string | null; }) { const scrollerRef useRefHTMLDivElement(null); const [scrollTop, setScrollTop] useState(0); const [viewport, setViewport] useState({ width: 0, height: 600 }); const [hoverKey, setHoverKey] useStatestring | null(null); const measurementsRef useRefMeasurement[]([]); const keyToIndexRef useRefMapstring, number(new Map()); const itemMapRef useRefMapstring, Item(new Map()); const rafRef useRefnumber | null(null); // 初始化或重置缓存 function resetMeasurements() { const measurements: Measurement[] []; const keyToIndex new Mapstring, number(); let currentOffset 0; items.forEach((item, index) { keyToIndex.set(item.id, index); measurements.push({ height: ESTIMATED_ITEM_HEIGHT, offset: currentOffset }); currentOffset ESTIMATED_ITEM_HEIGHT; }); measurementsRef.current measurements; keyToIndexRef.current keyToIndex; itemMapRef.current new Map(items.map((it) [it.id, it])); } function updateMeasurement(index: number, newHeight: number) { const measurements measurementsRef.current; if (!measurements[index]) return; const delta newHeight - measurements[index].height; if (Math.abs(delta) 1) return; measurements[index].height newHeight; for (let i index 1; i measurements.length; i) { measurements[i].offset delta; } } function findStartIndex(scrollTop: number) { const measurements measurementsRef.current; let low 0; let high measurements.length - 1; if (high 0) return 0; while (low high) { const mid (low high 1) 1; if (measurements[mid].offset scrollTop) low mid; else high mid - 1; } return low; } const totalHeight useMemo(() { const measurements measurementsRef.current; if (measurements.length 0) return 0; const last measurements[measurements.length - 1]; return last.offset last.height; }, [scrollTop, hoverKey, items, viewport]); const visibleRange useMemo(() { const measurements measurementsRef.current; if (measurements.length 0) return [0, 0]; const start findStartIndex(Math.max(0, scrollTop - OVERSCAN_COUNT * ESTIMATED_ITEM_HEIGHT)); const end findStartIndex(scrollTop viewport.height OVERSCAN_COUNT * ESTIMATED_ITEM_HEIGHT) 1; return [Math.max(0, start), Math.min(measurements.length, end)]; }, [scrollTop, viewport.height, items, hoverKey]); // 真实高度测量 function handleRowMount(key: string, el: HTMLDivElement | null) { if (!el) return; const index keyToIndexRef.current.get(key); if (index undefined) return; const actualHeight el.getBoundingClientRect().height; updateMeasurement(index, actualHeight); } // 自动滚动定位 useLayoutEffect(() { if (!scrollToKey) return; const index keyToIndexRef.current.get(scrollToKey); if (index undefined) return; const offset measurementsRef.current[index].offset; const maxTop totalHeight - viewport.height; const target Math.min(Math.max(0, offset - viewport.height * 0.25), maxTop); scrollerRef.current?.scrollTo({ top: target }); }, [scrollToKey, totalHeight]); useLayoutEffect(() { const el scrollerRef.current; if (!el) return; const ro new ResizeObserver((entries) { const { width, height } entries[0].contentRect; if (Math.abs(width - viewport.width) 1) { resetMeasurements(); } setViewport({ width, height }); }); ro.observe(el); return () ro.disconnect(); }, [items]); useLayoutEffect(() { resetMeasurements(); }, [items]); const [start, end] visibleRange; const baseY start 0 ? measurementsRef.current[start].offset : 0; return ( div ref{scrollerRef} classNamevirtual-scroll-container style{{ height: 100%, overflowY: auto, position: relative }} onScroll{() { if (rafRef.current) return; rafRef.current requestAnimationFrame(() { setScrollTop(scrollerRef.current?.scrollTop || 0); rafRef.current null; }); }} div style{{ height: totalHeight, position: relative }} div style{{ transform: translateY(${baseY}px) }} {items.slice(start, end).map((item) ( Row key{item.id} item{item} index{keyToIndexRef.current.get(item.id)!} hovered{hoverKey item.id} onHover{setHoverKey} onMount{handleRowMount} / ))} /div /div /div ); } const Row memo(function Row({ item, hovered, onHover, onMount, }: { item: Item; hovered: boolean; onHover: (key: string | null) void; onMount: (key: string, el: HTMLDivElement | null) void; }) { return ( div ref{(el) onMount(item.id, el)} onMouseEnter{() onHover(item.id)} onMouseLeave{() onHover(null)} className{virtual-row ${hovered ? row-expanded : }} div classNamerow-title{item.title}/div {hovered div classNamerow-desc{item.desc}/div} /div ); });5.2 外部接口设计如何通过命令式 API 控制列表上面的组件里用scrollToKey属性自带自动定位但在真实业务中外部往往不只想定位一次还需要再次定位、多次定位所以一个命令式 API 会更顺手。我用forwardRefuseImperativeHandle暴露了scrollToKey和resetCache两个方法。export type VirtualListHandle { scrollToKey: (key: string) void; resetCache: () void; };然后在父组件里通过 ref 调用const listRef useRefVirtualListHandle(null); const handleJump (id: string) { listRef.current?.scrollToKey(id); };相比通过 prop 传 key命令式 API 在处理“连续点击两个不同按钮跳转”的场景时状态更干净不需要额外清理旧 key 导致副作用。5.3 与后端数据结构配合的注意点虚拟列表对数据有一个隐藏要求每条数据必须有一个稳定且唯一的 id。如果后端只返回了 index前端在删除或插入数据时会出现 key 错乱进而影响测量缓存和滚动定位。我建议在前端尽早统一数据层把 id 清洗好再交给列表组件。同时要和后端约定详情数据尽量一次性返回。如果一定要在 hover 时异步请求详情那么这个请求会引入一个不确定性数据未返回时行高是多少返回后行高又变成多少。处理方式我个人比较推荐“先给一个默认展开内容的最小高度等异步数据到了再更新缓存并修正滚动位置”这样至少能保证列表不会因为网络延迟产生大量重排。6. 实战问题排查与避坑清单6.1 hover 抖动为什么展开后列表上下乱跳这个问题的原因非常典型hover 展开后行高变大缓存更新但滚动容器当前scrollTop对应的内容位置产生了偏移视觉上就表现为“列表被推了一下”。解决分两部分一是在高度更新后的同一帧里补偿滚动偏移和前面第 3.4 节一致二是 hover 切换时不要立刻测量等浏览器完成下一帧布局后再测量。我还遇到过一个特殊抖动场景鼠标从展开行移动到详情区域时详情区域刚好在行容器外部触发了onMouseLeave行收起鼠标又回到标题区域又触发onMouseEnter形成“展开-收起-展开”的循环抖动。解决办法是把 hover 判定作用在整个行内容的最外层容器上并且详情区不要脱离这个容器。6.2 滚动跳动高度更新不及时导致滚动跳动常见于滚动速度很快时有些行刚从视口底部进入还没有完成真实测量高度还是预估的 60px。但实际内容高度有 120px于是在滚动过程中不断修正用户会看到内容区域轻微“呼吸”。这个问题只能通过预测量来缓解把可视区结束索引向后多算几个即 bufffer 区域内的行也提前渲染并测量而不只是渲染当前可见行。比如可视区只显示 10 行但实际渲染 15 行其中下面 5 行就是用来“提前测量”的。代价是 DOM 数量略增但滚动稳定性提升非常明显。6.3 图片等异步资源导致行高突变详情区域里有图片时图片加载完成前高度是 0加载完成后突然撑开。由于测量发生在 mount 时这会让缓存里的高度落后于真实高度列表底部内容被推出视口。我采用的方案是给每个行容器本身也挂一个 ResizeObserver只要这行 DOM 的尺寸发生变化就重新执行一次测量和缓存更新。这个方案的覆盖面很广不仅能解决图片加载还能解决详情区内部字体加载、折叠展开等任何导致高度变化的情况。const rowResizeObserver new ResizeObserver(() { const el rowRef.current; if (el) onMount(item.id, el); });6.4 容器宽度变化但列表没重新布局一开始我用window.addEventListener(resize, ...)监听宽度变化结果容器在折叠面板里时窗口没变但容器宽度变了列表没有及时更新。换成ResizeObserver监听滚动容器后问题消失。还需要注意宽度变化会改变文字换行旧测量缓存完全失效如果不清空列表所有行的高度加起来的“总高度”会和实际内容高度偏离巨大滚动条位置也不准。所以宽度变化时除了重测还要把scrollTop按照比例重新映射一遍否则用户会觉得“我在看的内容突然变了”。6.5 快速拖拽滚动条时出现白屏闪烁快速拖动滚动条时可视区索引更新频繁内容区需要频繁重建。我用 index 作 key 的那版代码在这里翻过车拖到一半时 DOM 错乱出现大面积白屏。换成业务 id 作为 key 后问题消失。白屏的另一个来源是渲染内容区时没有保留足够多缓冲行。尤其是在快速滚动时新进入可视区的行如果刚好没有预测量首帧内容为空就会闪白。把 OVERSCAN_COUNT 从 3 改成 5 之后几乎不会再出现这种情况。缓冲行数不是一个固定值行高越高、单屏能显示的行数越少缓冲几行的成本越低行高越矮需要的缓冲行反而越多。实践下来建议缓冲行数在 5 到 10 之间调整。从我自己的经验来看虚拟列表这种组件最忌讳一上来就堆功能。把“测量缓存”“二分查找”“滚动映射”这三块核心算法理清楚其他交互都只是在这套骨架上做文章。如果你也在做一个动态高度、可展开、需要精确跳转的长列表我的建议是先跑通一个最小循环预估高度渲染 - 实测高度 - 修正缓存 - 精确滚动再往上面叠加 hover 和自适应。这样一步步来后面遇到的大多数问题都能在已有的缓存和定位逻辑里找到答案。

React虚拟列表实战：动态行高、Hover展开与精准滚动定位

相关推荐

TurboVLA 实战：0.2B 参数实现 32Hz 实时推理与 0.9GB 显存优化

使用 aws_msk_topic 数据源查询 Amazon MSK Topic：配置、属性与底层实现解析

CANN opbase 的 `aclOpExecutor::AllocFloatArray`：为算子执行器分配 `aclFloatArray` 浮点数组参数

更多资讯

纯前端实现m3u8在线播放：hls.js实战指南

无需安装与打包：markmap-autoloader在任意网页中一键渲染Markdown思维导图

ADK for Kotlin：Android原生AI Agent工程化实践指南

AIAgent全流程技术图谱与2026趋势预测

ADK for Kotlin 实战：Android 开发者如何用 KSP 构建 AI Agent

open-code-review：本地化AI代码审查CLI工具

今日更新

校园网认证计费模式详解：AAA与代拨架构、原理及排障

Spring Boot+Vue垃圾分类毕设：分层、权限与排错实战

把 Cline 的 Base URL 改到 TaoToken 之后，DeepSeek 仍能修调试配置

本周精选

AI驱动的自动化专利分析平台技术解析

LeetCode-Go 题解：1252. Cells with Odd Values in a Matrix（奇数值单元格计数）双解法剖析

在线答疑系统Java毕设实战：Spring Boot前后端分离与状态流转

本月热门

基于YOLO的焊缝缺陷检测：从数据标注到工业部署全流程实践

分布式服务的决策记录

创业产品的首版范围

读完文章，想聊聊您的网站？