如果你最近在使用 ChatGPT 桌面端很可能会有这样一段真实经历打开应用会话列表一直在转圈点进一个历史会话又要等好几秒才看到正文。标题里“线程加载提速超 90%”这句话指的就是这类会话Thread加载过程的优化。但别急着把这个数字当成一次普通版本更新。真正值得深挖的是一个桌面端应用从串行请求几十条会话到页面几乎秒开中间到底发生了什么这个问题对做 Electron 应用、做 AI 客户端产品、做高频列表页面的开发者来说比“ChatGPT 又改了哪里”要有价值得多。本文不会去猜 OpenAI 的内部实现代码那部分信息并没有完整公开猜了也没意义。我会从桌面端应用架构的通用规律出发拆解线程加载提速的三个关键层次并发拉取、本地缓存、渲染虚拟化。每一层都给出可以落地的代码示例和验证方式。读完这篇文章你可以把同样的思路直接搬到自己项目里让会话列表、消息流、任务列表这类高频界面的加载速度明显提升。1. 这篇文章真正要解决的问题先说一个容易被误解的点。很多人看到“线程加载”四个字第一反应是操作系统里的进程线程。但在 ChatGPT 这类 AI 聊天工具里Thread 首先指的是“会话”——你和模型之间的一段连续对话。桌面端里的“线程加载”最直观的场景就是打开应用时左侧密密麻麻的会话列表怎么快速呈现点击某个历史会话时里面的消息怎么快速展开。真正困扰开发者的是两类具体问题第一类是首次加载慢。会话列表往往有成百上千条记录如果每条记录都要单独发一次网络请求或者一次性把所有消息全部同步下来用户等到的就是转圈和空白页。第二类是重复打开慢。很多桌面应用第一次打开还能接受第二次、第三次依然要重新拉取全部数据。明明这些数据本地已经有一份了却因为缺少合理的缓存策略每次都从零开始。这就是典型的“没有把上一次的加载结果用起来”。本文要解决的问题就是针对这两类痛点给出一个从架构层面提速的完整思路。需要说明的是我无法确认 ChatGPT 桌面端 90% 这个数字背后精确的改动清单但以桌面端性能优化的通用规律来判断一次能带来量级提升的优化通常不是某个单一技巧而是“并发 缓存 渲染”三层同时发力的结果。这篇文章会把每一层都拆开讲清楚。适合读这篇文章的读者包括正在用 Electron、Tauri 等框架做桌面端的开发者做 AI 客户端、聊天工具、IM 应用被会话列表性能困扰的前端工程师想系统学习加载性能优化方法论而不是只会用一两个工具的初中级开发者。2. 先分清两个“线程”会话线程与执行线程这一节先澄清概念因为后面所有代码都依赖这个区分。会话线程Conversation ThreadChatGPT 产品语义里的一个概念指一次连续的对话记录集合。一个 Thread 包含标题、消息列表、创建时间、更新时间等字段。在 UI 上它表现为左侧列表里的每一项。执行线程Execution Thread操作系统层面真正干活的执行单元。在桌面端应用里它可以是主进程的 worker_threads也可以是渲染进程里的 Web Worker还可以是语言运行时里的线程池。为什么要把这两个概念放在一起说因为“ChatGPT 桌面端线程加载提速超 90%”这句话本身就横跨了这两个含义要加载的“会话线程”变快了靠的是更合理地使用“执行线程”。换句话说产品体验层面的优化最终要落到执行层面的并发设计上。用一个不太严谨但很好理解的类比假如你是一家餐厅的服务员现在有 20 桌客人同时要点菜。你不会一桌一桌按顺序跑到后厨下单串行而是会先把 20 张点菜单一次性收齐然后同时交给几个传菜员分批送到后厨并发。这里的“点菜单”就是会话数据“传菜员”就是执行线程。在传统思路里很多桌面应用会这样写加载逻辑// 串行加载一次只拉一个会话全部拉完再渲染 async function loadAllThreads(threadIds) { const allData []; for (const id of threadIds) { const data await fetchThread(id); allData.push(data); } render(allData); }这段代码的问题非常典型100 个会话就是 100 次串行网络请求总耗时等于所有请求的耗时之和。即使每次只需要 100ms100 个也要 10 秒。用户体验自然就是“转圈转到怀疑人生”。而优化后的思路是把 100 个请求分给 4 个或者 8 个执行线程并发处理总耗时从“所有请求之和”下降到“单次请求 × 批次数量”。这就是“提速超 90%”在架构上最可能的来源之一。3. 加载链路拆解慢在哪个环节要优化先要定位。一个桌面端应用从启动到显示完整会话列表大致经过下面这条链路应用启动 → 主进程初始化窗口 → 渲染进程加载 HTML/JS/CSS → 前端发起数据请求HTTP / IPC → 数据经过处理、归一化 → 组件渲染 DOM → 用户看到内容每一个环节都可能成为瓶颈。为了不瞎猜我把常见的延迟来源整理成一张表环节延迟来源典型表现应用启动Electron 初始化慢、扩展加载多白屏时间过长网络请求串行请求、无并行、无连接复用列表逐个弹出总耗时长数据传输返回数据过大、未裁剪字段单个请求体几百 KB数据处理前端做大量排序、过滤、归一化CPU 占用高页面卡顿渲染DOM 节点过多、无虚拟滚动滚动掉帧、点击无响应缓存无缓存或缓存策略不当每次打开都重新等待这里想特别强调一个经常被忽略的事实很多“打开慢”并不是慢在网络而是慢在渲染。当你一次性把 500 个会话全部塞进 DOM哪怕网络只花了 50ms浏览器要创建上千个 DOM 节点、绑定事件、计算布局耗时可能轻松超过 1 秒。如果做了虚拟滚动DOM 数量从上千降到几十渲染时间可以下降一个数量级。所以定位瓶颈时不能只看“请求花了多久”还要看“渲染花了多久”。用 Chrome DevTools 的 Performance 面板记录一次完整的加载过程把主线程上的任务时间分布导出来你很快就能发现时间到底被谁吃掉了。4. 第一层优化用线程池把串行请求改成并发拉取明确了瓶颈第一层优化就非常清晰了把串行改并发。在浏览器渲染进程里我们可以用 Web Worker 来创建执行线程在 Electron 主进程里可以用 Node.js 的 worker_threads。核心思路是一样的把耗时的 IO 任务和数据解析任务交给多个 Worker避免阻塞 UI 线程同时缩短总体耗时。但直接 new 几个 Worker 远远不够真正工程化之后你会需要一套线程池。线程池的作用是预先创建固定数量的 Worker把任务放进队列谁空闲谁领取任务。这样既不会因为创建太多 Worker 导致内存暴涨也不会因为只有一个 Worker 而退化成串行。下面是一个可以复制到项目里的最小线程池实现。我以浏览器环境的 Web Worker 为例Electron 渲染进程可以直接使用。// 文件路径src/utils/worker-pool.js export class WorkerPool { constructor(workerScript, size 4) { this.queue []; this.size size; this.workers []; for (let i 0; i size; i) { const worker new Worker(workerScript); this.workers.push({ worker, idle: true, }); } } runTask(data) { return new Promise((resolve, reject) { this.queue.push({ data, resolve, reject }); this.processQueue(); }); } processQueue() { if (this.queue.length 0) return; const available this.workers.find((item) item.idle); if (!available) return; const task this.queue.shift(); available.idle false; available.worker.onmessage (event) { available.idle true; task.resolve(event.data); this.processQueue(); }; available.worker.onerror (error) { available.idle true; task.reject(error); this.processQueue(); }; available.worker.postMessage(task.data); } terminate() { this.workers.forEach((item) item.worker.terminate()); this.workers []; this.queue []; } }这段代码的逻辑很直白构造时创建size个 WorkerrunTask把任务放进队列然后调用processQueueprocessQueue找到一个空闲 Worker把队头任务交给它Worker 返回结果后把该 Worker 标记为空闲继续处理下一个任务。为什么要做队列而不是一次性把所有任务都丢出去因为 Worker 数量是有限的如果同时抛 100 个任务给 4 个 Worker后 96 个任务其实都在排队。用队列统一管理配合“谁空闲谁接活”的调度策略可以避免 Worker 任务分配不均。接下来是这个线程池真正要执行的任务拉取会话数据。// 文件路径src/workers/chat-thread-worker.js self.onmessage async (event) { const { threadIds, apiEndpoint } event.data; const results await Promise.all( threadIds.map(async (id) { const response await fetch(${apiEndpoint}/threads/${id}); const data await response.json(); return { id, data: normalizeThread(data), loadedAt: Date.now(), }; }) ); self.postMessage(results); }; function normalizeThread(raw) { return { id: raw.id, title: raw.title, messageCount: raw.messages.length, preview: raw.messages[raw.messages.length - 1]?.content.slice(0, 80), updatedAt: raw.updated_at, }; }这个 Worker 做了一件很关键的事把原始数据归一化之后再传给主线程。很多聊天接口返回的 Thread 对象嵌套很深直接把原始 JSON 传给 UI 线程后续每次渲染都要做深层属性访问性能会打折扣。在 Worker 里提前裁剪出 UI 需要的字段主线程的渲染压力会小很多。最后是调用方组合使用// 文件路径src/utils/load-threads.js import { WorkerPool } from ./worker-pool.js; const THREAD_IDS [ // ...从本地索引或接口拿到的会话 id 列表 ]; const BATCH_SIZE 4; export async function loadThreadsConcurrently() { const pool new WorkerPool( new URL(../workers/chat-thread-worker.js, import.meta.url), 4 ); try { const batchQueues []; for (let i 0; i THREAD_IDS.length; i BATCH_SIZE) { const batch THREAD_IDS.slice(i, i BATCH_SIZE); batchQueues.push(pool.runTask({ threadIds: batch, apiEndpoint: https://your-api.example.com, })); } const batchResults await Promise.all(batchQueues); const allData batchResults.flat(); return allData; } finally { pool.terminate(); } }代码里的BATCH_SIZE是“每个 Worker 一次处理多少个会话”它和线程池的size是两个不同的参数。线程池的size决定了并发度通常建议设置为当前设备 CPU 核心数减一BATCH_SIZE决定每个任务里的请求数量需要根据单次请求的耗时和响应体大小来调。这里的 4 只是一个演示值实际项目里建议通过性能测试来确定。从串行到并发的效果是什么假设有 100 个会话每个请求耗时 100ms串行是 10 秒并发度 4、每个批次 4 个请求大约 25 批 × 100ms理论上是 2.5 秒提速 75%。如果进一步把单次请求合并为批量接口、加大并发度提速超过 90% 是完全可能的结果。5. 第二层优化本地缓存与 stale-while-revalidate并发拉取解决的是“首次加载慢”但一个成熟的桌面端应用绝不能每次启动都把历史会话重新拉一遍。本地缓存的意义就是让“第二次打开”变成“秒开”。先看一个最简单的缓存读写工具。为了让示例不依赖额外库我用localStorage做演示。如果你的会话数据量很大建议换成 IndexedDB它支持更大的存储空间和索引查询。// 文件路径src/utils/thread-cache.js const CACHE_KEY_PREFIX chatgpt-thread-v1; const CACHE_TTL 5 * 60 * 1000; // 5 分钟 export function readThreadCache(threadId) { const raw localStorage.getItem(${CACHE_KEY_PREFIX}:${threadId}); if (!raw) return null; const cached JSON.parse(raw); const stale Date.now() - cached.fetchedAt CACHE_TTL; return { data: cached.data, stale, }; } export function writeThreadCache(threadId, data) { const payload { data, fetchedAt: Date.now(), }; localStorage.setItem(${CACHE_KEY_PREFIX}:${threadId}, JSON.stringify(payload)); } export function clearThreadCache() { Object.keys(localStorage) .filter((key) key.startsWith(CACHE_KEY_PREFIX)) .forEach((key) localStorage.removeItem(key)); }这个缓存本身不复杂复杂的是缓存和网络请求之间怎么配合。这里要引入一个在 Web 性能优化里非常经典的策略stale-while-revalidate直译是“用旧数据先渲染再在后台验证更新”。它的工作流程是这样的发起请求前先看本地缓存如果有缓存立刻把缓存数据渲染到页面上用户马上看到内容如果缓存已过期则同时在后台发起网络请求拿到新数据后更新页面和缓存用户整个过程无感知最多会看到列表内容“轻微刷新一下”。这个策略的好处是把“等待网络”这个动作从用户可见的路径里移除了。页面不是先转圈再显示内容而是先显示内容再静默更新。用户感知到的加载时间无限趋近于 0。下面是组合了缓存和网络请求的完整调用逻辑// 文件路径src/utils/load-thread-with-cache.js import { readThreadCache, writeThreadCache } from ./thread-cache.js; export async function loadThreadWithSWR(threadId) { const cached readThreadCache(threadId); // 第一层有缓存就直接先渲染 if (cached) { renderThread(cached.data); // 第二层缓存过期才后台刷新 if (cached.stale) { refreshThreadInBackground(threadId); } return; } // 没有缓存只能走网络 const data await fetchThreadFromNetwork(threadId); writeThreadCache(threadId, data); renderThread(data); } async function refreshThreadInBackground(threadId) { try { const data await fetchThreadFromNetwork(threadId); writeThreadCache(threadId, data); renderThread(data); } catch (error) { // 后台刷新失败保留旧数据即可不打断用户 console.warn([thread-cache] refresh failed: ${threadId}, error); } }在实际项目里实现这个策略时最容易踩的坑有三个第一个是缓存和 UI 状态的一致性。如果先用缓存渲染又在后台刷新后直接替换页面部分 DOM很容易出现 React、Vue 这类框架里“状态已经被替换但页面没重新渲染”的奇怪现象。更稳妥的做法是把缓存读取和网络刷新都放进同一个状态管理流程里让框架的响应式机制去决定什么时候更新 UI。第二个是缓存更新策略不能一刀切。会话列表这类数据的更新频率并不高用 5 分钟甚至 1 小时的 TTL 都没问题。但如果是当前正在编辑的会话消息就不应该使用长时间缓存否则会出现“自己发出去的消息被旧缓存覆盖”这种严重 bug。第三个是存储空间的管理。localStorage 有 5MB 左右的限制IndexedDB 虽然空间大但也需要清理。建议对缓存设置一个总条数上限比如只保留最近 200 个会话的缓存当超过上限时优先淘汰最久没有访问的项。6. 第三层优化虚拟列表与增量渲染并发和缓存都做完了如果页面依然卡顿问题大概率出在渲染层。说到这里就不得不提绝大多数桌面端聊天工具的通病会话数量多DOM 节点更多。一个只显示 20 条的会话列表页面如果真实数据有 1000 条传统的写法会一次性渲染 1000 个列表项。每增加一个列表项就意味着多一个 DOM 元素、多一份样式计算、多一份事件监听。浏览器再快也扛不住这种无意义的消耗。虚拟列表Virtual List的思路非常简单不管数据有多少条只在屏幕可见区域内渲染列表项滚动时动态替换内容。视口外面那些用户根本看不到的项是不需要真实存在的。下面是一个简化版的可运行虚拟列表组件用 React 写的但核心思路可以迁移到任何框架// 文件路径src/components/VirtualThreadList.jsx import { useState, useLayoutEffect, useRef } from react; const ITEM_HEIGHT 64; const OVERSCAN 5; export default function VirtualThreadList({ threads, containerHeight }) { const [scrollTop, setScrollTop] useState(0); const containerRef useRef(null); const totalHeight threads.length * ITEM_HEIGHT; const startIndex Math.max(0, Math.floor(scrollTop / ITEM_HEIGHT) - OVERSCAN); const visibleCount Math.ceil(containerHeight / ITEM_HEIGHT) OVERSCAN * 2; const endIndex Math.min(threads.length, startIndex visibleCount); const visibleThreads threads.slice(startIndex, endIndex); const offsetY startIndex * ITEM_HEIGHT; return ( div ref{containerRef} style{{ height: containerHeight, overflowY: auto }} onScroll{(e) setScrollTop(e.currentTarget.scrollTop)} div style{{ height: totalHeight, position: relative }} {visibleThreads.map((thread, index) { const absoluteIndex startIndex index; return ( div key{thread.id} style{{ position: absolute, top: 0, transform: translateY(${offsetY index * ITEM_HEIGHT}px), height: ITEM_HEIGHT, boxSizing: border-box, borderBottom: 1px solid #eee, padding: 8px 12px, }} div style{{ fontWeight: 600 }}{thread.title}/div div style{{ fontSize: 12, color: #888 }} {thread.messageCount} 条消息 · {thread.preview} /div /div ); })} /div /div ); }这个组件最核心的代码其实是两行const startIndex Math.max(0, Math.floor(scrollTop / ITEM_HEIGHT) - OVERSCAN); const endIndex Math.min(threads.length, startIndex visibleCount);它根据当前滚动位置计算应该渲染哪些数据。OVERSCAN是“额外多渲染几项”的容错值用来保证快速滚动时不会出现空白区域。translateY用来把每一项放到它在整个列表中的正确位置这样外层容器的高度依然是totalHeight滚动条的尺寸和位置完全正常。用虚拟列表之后1000 条会话的页面实际渲染的 DOM 节点数量可能只有 20 个左右渲染时间下降一个数量级是常态。这一步对“打开应用后立即滚动会话列表”这个高频操作尤其重要。需要提醒的是虚拟列表的收益很大但代价是代码复杂度上升。如果项目里的会话数量长期在 100 条以内直接用普通列表完全没问题不需要过早引入虚拟滚动。优化的第一原则永远是先量数据规模再决定是否优化。7. 运行结果与性能对比验证优化做完了怎么证明它真的有效不能凭感觉说“好像变快了”要用数据说话。一个最朴素的方法是在页面加载的关键节点打上时间戳对比优化前后的耗时。// 文件路径src/utils/perf-monitor.js export function perfStart(key) { performance.mark(${key}:start); } export function perfEnd(key) { performance.mark(${key}:end); performance.measure(key, ${key}:start, ${key}:end); return performance.getEntriesByName(key).at(-1).duration; } // 使用示例 perfStart(thread-list-render); renderThreadList(data); const renderCost perfEnd(thread-list-render); console.log([perf] 会话列表渲染耗时: ${renderCost}ms);建议在你的开发环境里做一组这样的小实验实验一首次加载对比清空本地缓存分别用串行加载和线程池并发加载 100 条会话数据记录从发起请求到页面渲染完成的总耗时对比得出并发的提速比例。实验二二次打开对比第一次完整加载后不清理缓存刷新应用或退出重进再次加载同样的 100 条会话对比缓存命中前后的耗时。实验三渲染层对比固定 1000 条数据分别用普通列表和虚拟列表渲染用 Performance 面板记录渲染耗时、DOM 节点数量、滚动时的帧率变化。通过这些测试你会更清楚地知道你的项目里到底是网络层、缓存层还是渲染层拖了后腿然后把资源投入到收益最大的方向。如果优化后的效果不理想也先别急着改代码。请按下面的顺序检查网络层确认并发请求真的发出去了而不是被浏览器的同源连接数限制卡住Worker 层确认线程池里的 Worker 全部创建成功没有因为脚本路径错误而静默失败缓存层确认读取缓存后真的走了“先渲染”分支而不是因为 key 或字段名不一致导致每次都 miss渲染层确认虚拟列表的滚动容器有明确高度否则外层高度为 0列表可能不显示或直接退化成普通列表。8. 常见问题与排查思路在实际开发和维护过程中桌面端应用会遇到很多和加载、线程、启动相关的问题。我把一些出现频率较高的问题整理成了一张表每条都按照“现象 → 原因 → 排查 → 解决”的结构来写。问题现象可能原因排查方式解决方案桌面端打开后一直白屏或转圈渲染进程启动失败、JS 资源加载异常打开 DevTools查看 Console 和 Network 面板检查入口 HTML 引用路径确认构建产物是否完整提示failed to start或找不到某个 CLI 二进制应用依赖的命令行工具路径未配置或未安装看完整报错信息检查工具是否在 PATH 中按官方文档安装对应依赖或在配置文件中显式指定路径提示无法加载config.toml或配置解析失败配置文件格式错误、字段名不匹配用 TOML 解析器校验文件内容对照配置模板逐项检查备份后修正错误字段会话列表滚动时明显卡顿DOM 节点过多未做虚拟滚动Performance 面板录制滚动操作看图层占用引入虚拟列表控制可见 DOM 数量二次打开依然很慢像第一次一样缓存未命中或缓存策略无效检查缓存 key 是否一致TTL 是否合理统一缓存读写逻辑用调试日志打印命中情况npm 脚本无法执行提示“禁止运行脚本”Windows PowerShell 执行策略限制查看报错中的执行策略错误以当前用户身份放开策略见下面命令线程池任务一直不执行Worker 数量为 0 或队列被阻塞在 Worker 内部和processQueue打印日志确认 Worker 脚本能被正确加载检查 pool 初始化逻辑其中 PowerShell 执行策略是 Windows 开发者最常见的环境问题之一。出现下面这类报错时npm : 无法加载文件 C:\Program Files\nodejs\npm.ps1因为在此系统上禁止运行脚本。可以在 PowerShell 里先查看当前策略Get-ExecutionPolicy然后执行以下命令把当前用户的执行策略调整为RemoteSigned它允许运行本地脚本只要求从网络下载的脚本有签名是相对安全的选择Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser修改后重新打开 PowerShellnpm 命令就能正常执行了。这个操作影响的是当前用户不需要管理员权限适合在开发机上使用。9. 最佳实践与工程建议把前面几节的内容整合成一个完整的工程方案时有几点经验是踩过坑之后才真正理解的这里依次说明。第一性能优化必须“先测量再动手”。我曾经见过一个团队花了大量时间做并发改造结果用 Performance 面板一测发现真正的瓶颈是图片资源和字体加载。优化方向错了代码改得再漂亮都是白费。建议项目里常备一套性能标记工具每次改动前后都跑同一组实验用数字说话。第二并发度不是越高越好。CPU 核心数是有限的Worker 开多了线程上下文切换的开销反而会拖慢速度。主流的做法是把 Worker 数量设置为navigator.hardwareConcurrency - 1留一个核心给 UI 线程。如果你的桌面端应用还承担着很多其他任务这个值还可以再保守一些比如设置为 2 到 4。第三缓存策略要区分数据类型。简单把所有数据都塞进 localStorage或者统一用一个 TTL都会在真实场景里出问题。更合理的做法是数据类型缓存位置推荐 TTL说明会话列表元数据IndexedDB10 分钟数据量大需要索引查询会话详情IndexedDB5 分钟内容可变不宜过长用户偏好设置localStorage永久量小无一致性问题正在编辑的会话内存缓存实时必须保证一致性第四任何后台刷新操作都要有失败兜底。后台刷新请求失败时应该保持用户当前看到的旧数据不变最多在某个角落提示“更新失败”。绝对不能因为后台刷新失败就清空页面上的数据这是对用户非常不友好的行为。第五安全边界不能因为缓存而放松。本地缓存的内容涉及到用户会话数据时要关注数据脱敏和存储安全。不要在缓存里写明文 token 或密钥敏感信息应该放在 Electron 主进程的 safeStorage 机制里管理渲染进程的 localStorage 不适合存放高敏感凭据。对缓存数据的读取和清理也要具备明确的权限控制逻辑。第六给用户一个“可感知的反馈”。即使你的优化已经把加载时间压缩到几百毫秒用户点击一个会话后依然需要一点反馈来确认“操作已经生效”。最自然的做法是先用缓存数据秒开页面同时显示一个轻量的加载动画表示“正在更新”等网络数据回来后静默替换。这比让用户看着空白页面转圈要舒服得多。10. 总结与后续学习方向回到开头的问题ChatGPT 桌面端线程加载提速超 90%背后的核心到底是什么从桌面端性能优化的通用规律来看这个结果几乎可以确定不是单一技巧的功劳而是并发拉取、缓存复用、渲染虚拟化三层一起发力的结果。本文把这套方法论完整拆解了一遍并给出了可以直接落地的代码示例用线程池把串行请求改成并发拉取用 stale-while-revalidate 策略让二次打开秒开用虚拟列表把千级数据的渲染成本降到可控范围。这套思路不仅适用于 ChatGPT 桌面端这类 AI 客户端也适用于任何以列表和详情为主要交互形态的桌面应用、中后台系统甚至是移动端 H5。建议你找一个自己项目里最慢的列表页面先跑一遍性能基线再按本文的做法逐层优化你会亲身体验到“从 10 秒到 1 秒”的完整过程。如果你想继续深入下面这几个方向值得花时间去研究多级缓存架构内存缓存 本地持久化 服务端增量同步、Electron 主进程与渲染进程的 IPC 性能优化、Web Worker 与 SharedWorker 在不同场景下的选型以及 IndexedDB 索引设计对大数据量查询的影响。最后提醒一句性能优化的终点不是把某个指标压到极限而是找到“开发复杂度”和“用户体验”之间的平衡点。如果你的会话列表只有几十条普通列表完全够用如果已经卡到用户无法忍受再按本文的路径一步步优化也不迟。建议把这篇文章收藏起来下次遇到桌面端加载性能问题时直接对照执行。