前端数据层重构实战：从localStorage到IndexedDB的状态管理优化

这个30天轻量项目系列写到第6天Day06算是让我真正感受到“重构比新写更费脑子”的一天。前5天我已经把一个用于收集碎片链接的书签小工具从空白HTML文件做到了能增删改查的可用状态但第5天晚上自己试用几轮之后还是觉得它距离“每天主动打开”差得很远数据刷新靠手动、搜索筛选排序的逻辑散落在各种函数里、键盘彻底没法用。于是Day06那天我砍掉了原计划里“加标签云”这个新功能把一整天都砸在了数据层梳理和交互打磨上。这篇文章就把这天的思路、代码实现、踩坑记录都摊开来讲给同样在按日推进小项目的朋友一个参考。1. 项目复盘前5天做了什么Day06为什么选这条路1.1 30天挑战的背景与项目范围我给自己定的挑战是30天内只用一个原生前端技术栈做出一套能真的天天用的效率工具。选这个方向的原因很简单日常我们收藏文章、链接都是往浏览器书签栏一丢时间一长就变成乱葬岗存了等于没存。所以这个项目的目标很具体——做一个离线的、可以打标签、快速筛选、支持全文搜索的书签管理面板。项目范围被刻意压得很小界面就三个区域左侧是筛选栏中间是书签列表底部是一个收集输入条。不做登录、不做服务端同步、不做浏览器插件先保证本地体验足够好。30天听起来很宽裕实际上前3天搭完基础功能之后第4、5天基本都在处理各种边角问题到Day06才真正有机会把“能跑”和“好用”之间的差距补上。1.2 前5天做到哪儿了前5天的技术选型和完成情况大致是技术栈原生JavaScript Vite 手写CSS没有引框架就是想借这个项目把原生DOM操作重新练扎实。已完成功能添加链接、删除、编辑标题、一键收藏、归档。数据层一开始偷懒直接用localStorage存数组加一两百条数据时还挺顺畅到第5天塞了几百条测试数据之后每次操作都要序列化整个数组明显能感觉到卡顿。交互状态搜索框、状态筛选、排序方式这3个维度各自独立改变然后直接改DOM结果就是“输入一个关键词之后刚才选好的排序又乱了”。说白了前5天是把一个原型搭出来了但它还是一个“只能自己看着办”的样子距离“可以推荐给身边人用”还差一轮结构性的整理。1.3 Day06的任务拆解从“能跑”到“好用”Day06我给自己定了三个小目标按优先级排把数据层从localStorage迁到IndexedDB并封装成一个可复用的异步数据仓库把状态统一收敛到一个简单的全局Store里所有UI渲染都从状态推导而不是到处散落着直接操作DOM的语句补上搜索防抖、筛选排序组合、键盘快捷键这类“用了就回不去”的交互细节。这三个目标本质上都指向同一件事让项目在数据量变大、交互变复杂之后心智负担不会跟着失控。我见过太多小工具死在“功能不多但代码乱成一团麻”的阶段Day06的核心价值就是把混乱的部分提前拆掉而不是继续往上叠功能。事实证明这个选择是对的因为后面做批量编辑和数据导出时我基本没有返工。2. 核心设计数据结构、状态管理与持久化选型2.1 书签对象的数据结构设计动手写代码之前先把数据模型定清楚。这个步骤看着基础但很多人就是懒得做最后所有混乱都从这里来。我定义的书签对象长这样// link 对象结构 { id: 1, // 主键自增 title: MDN Web Docs, url: https://developer.mozilla.org/, description: 前端开发参考资料, tags: [reference, frontend], status: unread, // unread | starred | archived createdAt: 1737456000000, // 时间戳创建时生成 updatedAt: 1737456000000 // 时间戳每次修改后更新 }几个有意的设计决定这里说清楚为什么用自增数字id当主键而不是直接用url。原因很实际同一个链接你可能想存两次一次是“工作相关的重要参考”一次是“周末的灵感来源”两者的标签和批注完全不一样。如果用url做主键数据会互相覆盖损失很大。tags用数组不用逗号分隔字符串。数组在展示和筛选时都不用再拆解配合IndexedDB还能很方便地做索引查询。createdAt和updatedAt都用数字时间戳不用日期字符串。字符串日期在排序时会按字典序排列很容易在“1月”和“2月”之间翻车时间戳则是纯数值比较稳妥得多。status就三种unread待读、starred标星、archived归档。不搞复杂的状态机够用即可。2.2 状态管理为什么不能靠“随手改DOM”前端项目一开始写起来最快的方式确实是哪里需要变化就直接操作DOM。比如搜索结果变了就去清空列表容器再循环插入新行。但这种做法的问题是当搜索、筛选、排序这三个维度同时存在时“现在应该展示哪些数据”这个问题的答案散落在各个函数和临时变量里很容易互相覆盖。Day06我做了一个很小的全局状态对象配合发布订阅模式所有UI都从一份数据推导出来// store.js const store { links: [], filterStatus: all, // all | unread | starred | archived keyword: , sortBy: createdAt, // createdAt | title sortDir: desc, // asc | desc _listeners: new Set(), }; export function getState() { return store; } export function setState(patch) { Object.assign(store, patch); store._listeners.forEach((listener) listener()); } export function subscribe(listener) { store._listeners.add(listener); return () store._listeners.delete(listener); }这个模式虽然只有十几行但价值非常大。页面上的搜索输入框、筛选按钮、排序下拉框都只做一件事调用setState更新状态。唯一订阅状态的函数则统一负责渲染列表。从此之后“UI为什么显示成这样”这个问题永远有唯一答案——去看store里的状态就行。这是Day06最简单也最值得抄走的一段代码。2.3 持久化选型localStorage还是IndexedDB前5天用localStorage到了第6天决定迁移到IndexedDB。我知道很多读者会问几百条数据localStorage明明也能跑为什么非要换我把两者的对比列一下维度localStorageIndexedDB存储上限通常5MB左右远大于这个量级数百MB没问题数据结构只能存字符串需要自己序列化可以直接存对象、数组、Blob查询能力读取后全量遍历支持索引、游标、范围查询API形态同步API简单异步API回调风格比较难用适合场景配置项、短字符串结构化数据、附件、大量记录换成IndexedDB不仅仅是“存得下”的问题更重要的是搜索和排序可以按索引取数。后面几天我还计划加数据导出和批量编辑功能如果数据层还是localStorage这种“一次性全量读取”的方案后面操作会越来越吃力。所以这个迁移早晚都要做Day06做刚刚好。2.4 把IndexedDB封装成好用的异步仓库IndexedDB本身API设计确实啰嗦直接裸写的话每次操作都要处理onupgradeneeded、onsuccess、onerror三套回调。为了让Day06后面几天能写得舒服我在storage/db.js里做了一层Promise封装const DB_NAME daily-link-db; const DB_VERSION 1; let dbInstance null; function openDB() { return new Promise((resolve, reject) { if (dbInstance) { resolve(dbInstance); return; } const request indexedDB.open(DB_NAME, DB_VERSION); request.onupgradeneeded (event) { const db event.target.result; if (!db.objectStoreNames.contains(links)) { const store db.createObjectStore(links, { keyPath: id, autoIncrement: true, }); store.createIndex(createdAt, createdAt, { unique: false }); store.createIndex(status, status, { unique: false }); store.createIndex(tags, tags, { unique: false, multiEntry: true }); } }; request.onsuccess (event) { dbInstance event.target.result; resolve(dbInstance); }; request.onerror (event) { reject(event.target.error); }; }); }在openDB里特别注意两点一是把dbInstance缓存起来避免每次操作都重新打开数据库二是只在onupgradeneeded里创建对象仓库和索引索引的维护由浏览器在写数据时自动完成不需要业务代码额外处理。接着封装CRUD和查询方法// storage/linkRepository.js import { openDB } from ./db.js; export const LinkRepository { async add(link) { const db await openDB(); return new Promise((resolve, reject) { const tx db.transaction(links, readwrite); const store tx.objectStore(links); const request store.add(link); request.onsuccess () resolve(request.result); request.onerror () reject(request.error); }); }, async getAll() { const db await openDB(); return new Promise((resolve, reject) { const tx db.transaction(links, readonly); const store tx.objectStore(links); const request store.getAll(); request.onsuccess () resolve(request.result); request.onerror () reject(request.error); }); }, async update(id, patch) { const db await openDB(); return new Promise((resolve, reject) { const tx db.transaction(links, readwrite); const store tx.objectStore(links); const getRequest store.get(id); getRequest.onsuccess () { const data getRequest.result; if (!data) { reject(new Error(Item with id ${id} not found)); return; } const updated { ...data, ...patch, updatedAt: Date.now() }; store.put(updated); resolve(updated); }; getRequest.onerror () reject(getRequest.error); }); }, async remove(id) { const db await openDB(); return new Promise((resolve, reject) { const tx db.transaction(links, readwrite); const store tx.objectStore(links); const request store.delete(id); request.onsuccess () resolve(); request.onerror () reject(request.error); }); }, };这段代码看起来“土”但真的很可靠。事务的commit由浏览器自动管理我不需要显式调用只要确保所有request都在事务里完成即可。实际用下来这套封装应付Day06到Day10的迭代绰绰有余。3. Day06实操记录搜索、筛选、排序与键盘交互3.1 搜索防抖、分词与命中逻辑搜索是“每天打开”这个动作里最常触发的一个入口。Day06我给搜索框接上了250毫秒防抖避免每敲一个字就立刻触发一次全量筛选。function debounce(fn, delay 250) { let timer null; return (...args) { clearTimeout(timer); timer setTimeout(() fn(...args), delay); }; } const handleSearch debounce((value) { setState({ keyword: value.trim() }); }, 250);有人会觉得250毫秒太久但实际测试下来连续输入时每40毫秒左右就会触发一个输入事件不防抖的话一次“前端开发”四个字能触发六七次搜索而且在数据量大时还可能出现旧结果覆盖新结果的错乱问题。250毫秒在感知上几乎没有延迟又能把触发次数压到最低。输入后的命中逻辑我做了关键词分词和AND匹配。也就是说用户输入“前端 设计”会同时要求标题、URL或者标签里既包含“前端”又包含“设计”而不是把它们当成一个完整字符串去匹配。这样搜出来的结果更符合“我记得有一篇讲前端的好像还提到设计”这种模糊记忆场景。export function queryLinks(links, params) { const { keyword , filterStatus all, sortBy createdAt, sortDir desc } params; let result [...links]; if (filterStatus ! all) { result result.filter((item) item.status filterStatus); } if (keyword.trim()) { const words keyword.toLowerCase().split(/\s/).filter(Boolean); result result.filter((item) { const haystack ${item.title} ${item.url} ${(item.tags || []).join( )}.toLowerCase(); return words.every((word) haystack.includes(word)); }); } result.sort((a, b) { if (sortBy title) { const diff a.title.localeCompare(b.title, zh-Hans-CN, { sensitivity: base }); return sortDir asc ? diff : -diff; } const diff a.createdAt - b.createdAt; return sortDir asc ? diff : -diff; }); return result; }这里所有匹配都统一转成小写再做比较避免“JavaScript”和“javascript”被视为不同关键词。标签数组在拼接时用空格隔开这样分词逻辑就不用区分标签边界了处理起来很省事。3.2 筛选和排序状态组合决定渲染结果筛选和排序不是彼此独立的功能它们共同决定“最终展示哪些数据”。Day06之前我踩过的坑就是筛选函数里处理了状态过滤排序函数里又单独处理排序两个函数各做各的结果先筛选后排序和先排序后筛选在数据量变大时会出现不一致。现在所有读取列表的路由都只有一条store发生变化 - 调用queryLinks - 拿到结果渲染DOM。这样筛选和排序的优先级就非常明确先过滤再排序。不管用户先点“已归档”还是先改排序方式最终结果都由同一段代码算出。更关键的是筛选按钮的UI状态也存到store里了document.querySelectorAll([data-filter]).forEach((btn) { btn.addEventListener(click, () { setState({ filterStatus: btn.dataset.filter }); }); });按钮的选中态同样由状态渲染不偷懒直接改class。这样做的好处是下次刷新页面后想恢复筛选条件甚至可以顺手存进sessionStorage整个UI和状态严格对应排查问题极其方便。3.3 键盘快捷键从“能用”到“愿意用”一个自己天天用的工具鼠标点来点去很快就会烦。Day06我加了一组键盘快捷键按我这个“效率工具党”的习惯来设计快捷键动作/聚焦搜索框Alt A把当前选中项归档Alt S给当前选中项标星Esc清空搜索关键词并恢复全部列表?显示快捷键帮助第一个踩坑点是如果不加判断在搜索框里打字时按/会变成输入内容而不是聚焦搜索框。所以我写了一个工具函数来判断当前焦点是否在可输入元素上function isTypingTarget(target) { return target.tagName INPUT || target.tagName TEXTAREA || target.isContentEditable; } document.addEventListener(keydown, (event) { if (event.isComposing) return; // 输入法组合态忽略 if (event.key / !isTypingTarget(event.target)) { event.preventDefault(); searchInput.focus(); } if (event.key Escape isTypingTarget(event.target)) { searchInput.value ; setState({ keyword: }); } });我特别把event.isComposing的判断放到了最前面这个细节后面在踩坑部分会详细说。快捷键不一定要多但每个都得稳定触发如果按下去没反应或者误触还不如不放。3.4 空状态与加载状态被低估的体验细节数据列表在“有数据”和“无数据”之间的过渡很多时候被当成边角料处理。但实际用下来空状态做得不好会让人怀疑数据是不是丢了。Day06我给列表区分了三种空状态收藏夹本身为空时显示“还没有保存任何链接”和一句提示筛选条件导致为空时显示“当前筛选条件下没有内容”并给出清除筛选的按钮搜索关键词没有命中时显示“没找到匹配结果”并提醒可以试试更短的关键词。第2、3种状态特别重要。用户搜索之后一无所获如果界面直接变成空白第一反应往往是“我是不是操作坏了”。加上这种有引导性的提示工具就给人“靠谱”的感觉。这个细节虽然不涉及复杂技术但对工具的日常使用体验相当加分。4. 踩坑实录Day06修的5个问题4.1 数据库一直用的旧数据版本号升级的坑第一天把IndexedDB接好之后我在代码里给links对象仓库加了一个tags索引然后怎么调试都查不到新索引读出来的数据永远是老的。折腾了半天发现indexedDB的版本号还停在1。浏览器判断“要不要触发onupgradeneeded”的标准不是看你的代码有没有变化而是看你传入的版本号变大没有。所以我改数据结构之后必须把DB_VERSION从1改成2const DB_VERSION 2;升级版本后onupgradeneeded里除了创建对象仓库还要判断旧仓库是否需要迁移request.onupgradeneeded (event) { const db event.target.result; if (!db.objectStoreNames.contains(links)) { const store db.createObjectStore(links, { keyPath: id, autoIncrement: true }); store.createIndex(createdAt, createdAt, { unique: false }); } else { const store event.target.transaction.objectStore(links); if (!store.indexNames.contains(tags)) { store.createIndex(tags, tags, { unique: false, multiEntry: true }); } } };这个教训给我最大的启发是IndexedDB的版本号是给“数据结构迁移”用的不是随便写个数字就完事。以后每次改字段、加索引第一件事就是把版本号往上加不然你面对的问题会非常隐蔽。4.2 搜索结果被旧请求覆盖异步竞态把IndexedDB封装成Promise之后我用了一个很自然的方式去绑定搜索事件每输入一次就执行一次异步查询然后渲染结果。看起来逻辑没问题但实测连敲“前端设计”四个字时页面上有时会闪出旧的关键词搜索结果。原因我想了一会儿才反应过来异步操作的返回顺序由内部耗时决定不一定和发送顺序一致。第一次搜索“前”可能因为数据库稍忙返回比第二次搜索“前端”还晚晚返回的旧结果就把新结果覆盖了。解决办法是给每次查询带一个自增的请求序号只有最新一次请求的结果才允许渲染let querySeq 0; async function refreshLinks() { const currentSeq querySeq; const all await LinkRepository.getAll(); if (currentSeq ! querySeq) return; // 已经过期丢弃 const result queryLinks(all, getState()); renderList(result); }这种方式在带异步操作的前端交互里很常见也让Day06之后的批量编辑功能少踩了很多坑。4.3 输入法打字时按下快捷键isComposing键盘快捷键刚上线时我用中文输入法在搜索框里打字按/希望输入一个“/”符号结果页面焦点直接跳走了。这个问题的根源是中文输入法打字时会有一段“组合输入”过程在组合态里按键事件代表的不是最终字符而是输入法的中间状态。解决方案就是本章前面提到的event.isComposing判断。它在支持组合输入事件的现代浏览器里非常可靠document.addEventListener(keydown, (event) { if (event.isComposing) return; // 正常快捷键逻辑 });另外我还把所有快捷键在isTypingTarget时直接跳过只有Esc这种“清空”操作例外。这个组合判断一出中文用户输入时的心情简直好了十倍。4.4 初始化函数被重复调用事件重复绑定Day06做到一半我发现自己写了一个init()函数用来绑定搜索、筛选按钮和键盘事件。本来是好事但在调试刷新时我先调了一次init()又手动调了一次结果键盘事件被绑定了两次按一次Esc清空一次搜索页面要闪烁两下才正常。这类“重复初始化”问题在原生JS项目里太容易出现了。解决办法是给init加一个简单幂等标记let initialized false; export function init() { if (initialized) return; initialized true; bindEvents(); loadInitialData(); }如果你用模块化开发这个标记放模块级再合适不过整个生命周期只初始化一次。后来我把这个思路也带到了其他工具项目里非常有效。4.5 排序时英文大小写和中文混排乱序筛选排序做好以后我按标题排序时发现一堆以“go”和“Go”开头的条目没有排在一起英文大小写挨着中文时排序结果也不符合直觉。原因是我用普通的a.title.localeCompare(b.title)没有指定语言和灵敏度。修正后的代码顺便解决了中文拼音排序的问题result.sort((a, b) { const titleA a.title || ; const titleB b.title || ; return titleA.localeCompare(titleB, zh-Hans-CN, { sensitivity: base }); });sensitivity设为base时比较会忽略大小写和音标差异这样“Go”和“go”就被当成同一个顺序级别旁边“指南”这类中文会按照拼音去排。这个设置对中文用户真的友好。5. 第7天开工计划与这天的个人体会5.1 第7天要做的数据导出/导入Day07我计划给工具加数据导出/导入功能这是本地工具最后的保命索。思路很简单把所有数据从IndexedDB读出来序列化成JSON文件下载导入时读取用户选择的JSON文件清空现有仓库后批量写入。技术难点主要在“批量写入IndexedDB时的进度控制”不能一次性无脑发起大量事务否则浏览器会卡顿。考虑用分批chunk的方式每批50条写入完成后再处理下一批。这样既能看到导入进度也避免主线程长时间无响应。为什么把导出导入放Day07而不是更早因为Day06完成了store的统一导出时的数据来源非常清楚直接从state.links序列化就行。要是放在Day05之前做还要面对“列表展示的数据和库里真实的数据不一致”这种混乱局面反而更难写。5.2 连写6天之后我最想提醒自己的三件事连续写到第6天我对自己这个项目的推进方式有了更清楚的判断。这里分享三句实在话第一状态统一得越早后面几天越轻松。Day06做store的整理虽然花了大半天但当天晚上我加“标签点击筛选”功能时只写了几行代码因为只需要更新filterStatus和filterTag这两个状态渲染逻辑完全不用动。如果继续沿用之前到处改DOM的方式这个功能又要零散写一堆。第二IndexedDB的封装值得花时间做好。很多教程把IndexedDB的README贴一贴就完事但真正好用的是Promise封装和将异常、竞态都收口在一起的数据访问层。Day06把这部分做扎实之后之后无论是批量编辑还是导出都只是在这个Repository上继续加方法。第三做工具类项目体验细节和功能本身同样重要。搜索防抖、快捷键、空状态提示这些单看都不起眼合在一起决定了用户到底会不会每天打开它。Day06让我重新理解了什么叫“完工度”——不是所有按钮都存在而是常用路径润得足够顺滑。我期待Day07实测完批量导入后再回来更新踩坑记录应该比这一篇还多。