1. 项目思路与方案选型先交代一下这个项目的来龙去脉。有一次我为个人项目做数据整理想把几十条任务、状态、负责人、截止日期这些信息管理起来。第一反应是用飞书多维表格或者在线表格但发现为了这么点数据要么得注册账号、建团队空间要么得下载客户端数据还要传到别人服务器上。我当时的诉求其实很简单就是一个本地运行的、长得像多维表格的工具双击就能用数据不出电脑最好还能按自己的需要改功能。于是就有了这个项目——用 AI 辅助开发一个纯前端的多维表格技术栈就是 HTML CSS JavaScript没有任何后端所有数据都存在浏览器本地。你把它部署到任意静态托管平台或者干脆在自己电脑上双击打开 HTML 文件就能跑起来。整个过程里AI 承担了一大部分编码工作我主要做架构设计、需求拆分和代码审查。1.1 为什么选纯前端而不是带后端这个问题我在动手前认真考虑过。带后端意味着更完整的多用户协作、权限管理、云端同步但这些对我来说都不需要。我的使用场景是单人、单机、快速启动一个纯前端方案就能覆盖而且优势非常明显零部署成本不需要准备服务器、数据库、域名任何一个静态托管服务都能跑甚至双击本地 HTML 文件就能打开。数据主权在自己手里所有数据存浏览器本地没有第三方服务隐私安全天然可控。开发周期大幅缩短纯前端可以不写接口、不跑数据库、不考虑鉴权把所有精力聚焦在表格交互本身。当然纯前端方案不是没有代价。浏览器本地存储有容量上限不同浏览器的 IndexedDB 配额不一样一般能存几百 MB 到上 GB对文本型数据完全够用。另外数据只存在于当前浏览器里换个电脑数据不会跟着走所以我会在后面加导入导出功能把数据以文件形式备份出来。1.2 AI 开发与传统写代码的差别这个项目最大的特点是代码的很大一部分不是我逐行敲的而是我和 AI 对话“聊”出来的。我负责给出功能描述、数据结构、交互细节AI 负责把需求翻译成代码。这么说有点抽象举两个直观的感受传统方式写一个表格渲染逻辑要去操作 DOM、处理事件绑定、兼顾各种边界情况可能要花一到两天。AI 辅助下我用一段自然语言描述字段类型、渲染要求、编辑方式它能直接生成一个可运行的雏形我再在这个基础上修改完善。遇到 bug不用再像以前那样到处 console.log 打日志排查直接把报错信息复制给 AI它能快速分析可能的原因很多时候第一版答案就能解决问题。但这里有个必须要说清楚的坑AI 能写出看起来能跑的代码但不代表代码一定正确。尤其是涉及异步逻辑、状态同步、数据一致性这类问题时AI 生成的东西经常是“表面对、实际错”。所以整个开发过程我把 AI 定位成一个非常高效的程序员但不是项目负责人项目的设计思路、模块划分、代码审查仍然由我来掌控。1.3 整体功能范围在动手前我列了一个功能清单经过取舍后确定了第一版的范围支持多张数据表每张表可以自定义字段字段类型包括文本、数字、单选、多选、日期、勾选复选框、附件。支持记录的增删改查行内点击可直接编辑单元格内容。支持视图的筛选、排序、搜索做到基本的“表格想怎么看就怎么看”。支持数据导入导出至少要有 CSV 和 JSON 两种格式方便备份和迁移。整体界面风格参考多维表格的桌面端布局左侧是表列表中间是数据区域右侧是字段信息顶部是功能按钮。这些功能的实现难度不算太大但涉及的细节特别多。下面我把每一步的实现过程拆开来讲包括具体的代码思路、踩过的坑、以及如何用 AI 高效推进这个项目。2. 数据结构设计与核心场景建模多维表格之所以叫“多维”是因为它不是简单的二维表格而是由“数据表 → 字段 → 记录”三层结构构成的。把这个数据模型想清楚后面的功能才有实现的根基。2.1 三层数据模型我一开始就确定了这样的基础数据结构// 一个完整的数据库文件 const database { tables: [ { id: table_001, name: 项目任务, fields: [ { id: field_001, name: 任务名称, type: text, options: null }, { id: field_002, name: 负责人, type: singleSelect, options: [张伟, 李娜, 王强] }, { id: field_003, name: 优先级, type: singleSelect, options: [高, 中, 低] }, { id: field_004, name: 截止日期, type: date, options: null }, { id: field_005, name: 完成, type: checkbox, options: null } ], records: [ { id: record_001, cells: { field_001: 开发登录页面, field_002: 张伟, field_003: 高, field_004: 2025-03-15, field_005: true } } ] } ] };这个结构借鉴了 Notion 和飞书的数据设计思路。每个表有独立的字段定义每一条记录用 record_id 加 cells 对象存储单元格数据单元格的值由对应字段的 id 来索引。这样设计的好处在于字段与记录解耦以后新增字段时老记录不需要同步加数据未填写的字段返回空值即可。易于扩展如果以后要加“创建时间”这种系统字段只需要在字段列表里加一条定义不影响已有数据。序列化简单整个 database 对象可以直接 JSON.stringify 存到浏览器本地也可以导出成 JSON 文件再导入。2.2 字段类型怎么设计字段类型是整个表格系统的灵魂。我给这个项目设计了 7 种字段文本、数字、单选、多选、日期、勾选、附件。每种字段背后对应不同的数据存储方式和渲染交互逻辑。文本字段简单直接用字符串存储即可。但数字字段我做了特殊处理——存储时保留原始数字类型而不是字符串。这样以后做求和、平均值统计时不需要再 parseFloat 转换能在数据层面保证类型正确性。单选字段和多选字段都需要先在字段定义里配置选项列表。单选字段的实际值是一个字符串多选字段则是一个数组。这里有个实用细节当选项列表被修改时老数据里可能还留着旧选项值所以读取单元格时要做一层容错处理不存在的选项值可以原样显示不能直接丢弃。日期字段我建议存储成YYYY-MM-DD这种纯字符串格式不要存时间戳。原因很简单日期选择器给出的就是这种格式展示时不需要再次格式化对用户更友好。如果以后需要按日期排序字符串格式的 ISO 日期也能直接比较排序不影响功能。附件字段是最特殊的后面专门展开讲。2.3 视图层的筛选、排序与搜索多维表格的“多维”感很大程度来自视图功能。我实现了筛选和排序逻辑其实都是在 records 数组上做过滤和重排再渲染到界面上。筛选条件的结构是这样的// 筛选配置 const filterConfig { fieldId: field_003, // 针对哪个字段 operator: is, // 操作符: is / isNot / contains / greaterThan / lessThan / isEmpty value: 高 };渲染数据时先遍历所有筛选条件逐条过滤再对结果做排序。排序则支持多个字段的优先级实现了一个简单的多级排序器records.sort((a, b) { for (const sortItem of sortConfig) { const aVal getCellValue(a, sortItem.fieldId); const bVal getCellValue(b, sortItem.fieldId); if (aVal bVal) return sortItem.order asc ? -1 : 1; if (aVal bVal) return sortItem.order asc ? 1 : -1; } return 0; });搜索功能也值得讲一下。多维表格的搜索通常是对整行做全文搜索不是针对单个字段。我用了最简单粗暴的方式——遍历所有字段的所有单元格把值拼成一条字符串再用 indexOf 判断是否包含关键词。对于几千条数据来说这种方案性能完全够用代码还极其简洁。2.4 数据流的单向设计这个项目我没有引入 Vue、React 这类框架用的是原生 JavaScript所以状态管理要自己处理。我采用了一个类似单向数据流的模式// 所有修改都走这个统一入口 function updateDatabase(mutator) { mutator(database); saveToLocalStorage(database); renderAll(); }所有的新增记录、修改单元格、删除记录、调整字段类型最终都统一走 updateDatabase 这个函数。先修改数据再持久化到本地存储最后触发重新渲染。这样做的好处是逻辑链路清晰永远不会出现界面状态和内存数据不一致的情况。用 AI 辅助写这类代码时方向性的设计一定要自己把控AI 生成的代码往往是一个一个孤立的功能函数中间没有统一的数据流管理。如果我直接照搬 AI 的代码很快就变成“这里改一下那里改一下”调试起来非常痛苦。3. 核心功能的实操实现细节设计方案定下来后真正的开发就是一场硬仗。下面我从表格渲染、单元格编辑、附件处理、持久化和导入导出几个维度把核心代码思路和踩坑经验分享出来。3.1 表格渲染方案选型表格区域的渲染主要有三种常见方案原生 HTML table、Canvas 绘制、虚拟滚动表格。我最终选择了 HTML table 虚拟滚动的混合方案。用 HTML table 的好处非常明显浏览器原生支持表格的语义化结构单元格的点击事件、键盘事件都很好绑定而且开发调试时可以直接看到 DOM 结构对 AI 生成的代码也很友好。 Canvas 画表格在渲染大量数据时性能好但交互做起来很痛苦——单元格的点击命中测试、文本选中、滚动重绘全都要自己实现收益不划算。我的实现思路是表格头部用单独的thead渲染字段名表体用tbody渲染数据行。表体只渲染当前视口范围内的行滚动时动态更新渲染内容。这样即使表里有一万条数据屏幕上实际渲染的 DOM 节点也就几十个性能不会崩。3.2 单元格编辑与中文输入法的坑这一节是整个项目里我踩坑最多的部分。多维表格的核心交互是“点一下单元格就能编辑”这个需求看起来简单细节却非常多。我的实现思路是当用户点击某个单元格时把该单元格的内容替换成input或textarea并自动聚焦。编辑完成后通过 blur 事件或回车键把内容写回数据。但这里隐藏着一个非常经典的问题——中文输入法的 composition 事件。如果用户在输入框里用拼音输入中文按回车时输入法会先触发compositionend事件随后才可能触发 keydown 事件。如果我在 keydown 里直接禁止回车提交并把内容写回那么输入“你好”时按空格选字、按回车确认拼音都可能被误判为“编辑完成”导致只写入了拼音字母。解决办法是监听compositionstart和compositionend在输入法组合期间挂起回车确认的逻辑let isComposing false; input.addEventListener(compositionstart, () isComposing true); input.addEventListener(compositionend, () isComposing false); input.addEventListener(keydown, (e) { if (e.key Enter !isComposing) { commitEdit(); } });这个问题不亲手做一遍真的发现不了至少在最初版本里我完全没意识到结果用中文测试时出了各种诡异问题。3.3 附件字段文件转 base64 还是用 IndexedDB附件字段是另一个大坑。多维表格允许在单元格里上传图片、文档那这些数据存哪里有两种思路我用的是“小文件转 base64 存内存大文件用 IndexedDB 存二进制”。把图片转成 base64 数据 URI 的代码非常简短function fileToBase64(file) { return new Promise((resolve, reject) { const reader new FileReader(); reader.onload () resolve(reader.result); reader.onerror reject; reader.readAsDataURL(file); }); }这样存到数据对象里JSON.stringify 之后可以直接保存非常简单。但副作用是base64 编码会让文件体积膨胀约 33%每 3 个字节变成 4 个字符如果附件比较大整个 database 对象序列化之后会很臃肿每次操作都重新保存一遍性能会越来越差。所以我的建议是小于 1MB 的文件走 base64 存 localStorage大于 1MB 的文件存 IndexedDB数据库只保存一个引用 ID。IndexedDB 原生支持存储 Blob 和 File 对象读取效率远高于把大字符串塞进 JSON。具体实现这里不展开但只要涉及附件功能建议一开始就把这个架构想清楚。3.4 数据持久化的三种策略浏览器端的数据持久化方案主要有 localStorage、sessionStorage、IndexedDB 三种。sessionStorage 关掉标签页就没了不考虑。localStorage 和 IndexedDB 是主要选择。localStorage 的 API 极其简单只有 getItem、setItem、removeItem但它有一个重要限制——大部分浏览器单个域名下只有 5MB 左右的存储空间。所以我做了一层封装默认优先用 localStorage一旦检测到要存储的 JSON 字符串超过 3MB就自动切换到 IndexedDB。保存操作我做了防抖处理。用户在表格里连续编辑时如果每改一个字符就执行一次 stringify localStorage.setItem既卡顿又频繁写入。我设置了一个 800ms 的防抖延迟用户停止操作 800ms 后再保存。let saveTimer null; function scheduleSave() { clearTimeout(saveTimer); saveTimer setTimeout(() { localStorage.setItem(multiTableDB, JSON.stringify(database)); }, 800); }这里有个小细节值得注意在页面关闭前防抖定时器可能还没触发数据就丢了。所以我监听beforeunload事件在关闭页面时强制保存一次。3.5 CSV 导出的编码问题CSV 导出功能是我和 AI 协作开发时返工最多的地方。CSV 文件本质上是一个用逗号分隔的纯文本文件用最简单的思路就是把每行记录拼成字符串然后用\n拼接所有行function exportCSV() { const headers fields.map(f f.name).join(,); const rows records.map(r { return fields.map(f formatCellValue(r.cells[f.id])).join(,); }); const csvContent \uFEFF [headers, ...rows].join(\n); const blob new Blob([csvContent], { type: text/csv;charsetutf-8 }); const url URL.createObjectURL(blob); const a document.createElement(a); a.href url; a.download table.name .csv; a.click(); URL.revokeObjectURL(url); }那个\uFEFF是 UTF-8 BOM是这次任务最重要的收获。如果直接用 Excel 打开不带 BOM 的 UTF-8 CSV 文件Excel 会默认按 GBK 编码解析中文全部变成乱码。加上 BOM 后Excel 会自动识别为 UTF-8中文才能正常显示。这个细节网上虽然很多资料提过但自己不踩一遍永远记不住。另外单元格内的值如果包含逗号、换行符或双引号直接拼进 CSV 会导致列错位。正确的做法是对每个值用双引号包裹内部的双引号转义成两个双引号function escapeCSVField(value) { if (value.includes(,) || value.includes() || value.includes(\n)) { return value.replace(//g, ) ; } return value; }3.6 从 CSV 导入的反向处理导入 CSV 时又遇到另一个坑。CSV 文件可能是 GBK 编码Windows 上常见也可能是 UTF-8。浏览器用 FileReader 的 readAsText 默认按 UTF-8 解码GBK 文件会直接乱码。解决办法是检测文件开头有没有 BOM没有 BOM 就尝试用 TextDecoder 指定 gbk 编码解码async function parseCSVFile(file) { const buffer await file.arrayBuffer(); const bytes new Uint8Array(buffer); // 检查是否带 UTF-8 BOM if (bytes[0] 0xEF bytes[1] 0xBB bytes[2] 0xBF) { return new TextDecoder(utf-8).decode(bytes); } // 尝试按 gbk 解码如果中文乱码再用 UTF-8 try { const text new TextDecoder(gbk).decode(bytes); if (isReasonableText(text)) return text; } catch(e) {} return new TextDecoder(utf-8).decode(bytes); }当然自动编码检测不是百分百可靠所以我还在界面上加了一个“选择编码方式”的手动选项让用户遇到乱码时可以手动切换 UTF-8 / GBK。这种问题在“教科书”上很少讲但在实际处理国内用户场景时特别常见。3.7 附件导出时的 Blob 处理把附件从 IndexedDB 导出成压缩包是另一个让人头疼的点。浏览器原生的方式如果要打包多个文件成一个 zip需要引入 JSZip 库。既然这个项目是“纯前端”我用的是 CDN 加载第三方库的方式并没有把所有代码都自己写一遍。script srchttps://cdn.jsdelivr.net/npm/jszip3.10.1/dist/jszip.min.js/script导出时遍历所有记录把附件文件从 IndexedDB 取出来用 JSZip 添加到 zip 包然后生成 Blob 触发下载。JSZip 会把二进制内容原样打包不会做额外压缩所以这一步其实相当直接。但如果在纯离线环境使用比如内网部署CDN 可能加载不了需要把 JSZip 库文件下载到本地和 HTML 放同一目录。这也是我后来优化时改的一个点—— 把第三方依赖工具全部本地化确保双击 HTML 文件时不需要联网也能用。4. AI 辅助开发的实操全记录接下来讲大家最关心的部分我是怎么利用 AI 来辅助完成这个项目的。准确地说是对 AI 代码生成和人工审查的边界如何划分以及各个开发阶段怎么给 AI 下指令。4.1 准备一个可执行的高质量需求文档我一开始没有直接让 AI“写一个多维表格”而是花了近两个小时整理了一版详细的需求文档。内容包括功能模块清单、每个字段类型的定义、界面布局描述、数据存储方案、操作交互细节。这些需求描述不是一次性的对话记录而是整理成一份结构化的文档再分模块喂给 AI。比如“单选字段”这个需求我这样描述实现单选字段的编辑。点击单元格时显示一个下拉列表列表项的来源是字段定义里的 options 数组。选中后立即写入记录单元格显示选项文本。如果选项文本为空则显示一个占位符“未设置”。这样清晰描述后AI 生成的第一版下拉选择器基本就能用了。相反如果我只说“实现单选字段”它可能会做出一个非常难用的组件——比如在下拉列表中塞了输入框或者选中后需要二次确认。4.2 分阶段开发而不是一口气全部生成我的开发顺序是这样的第一阶段搭好 HTML 基础布局左侧表列表 右侧表格区域实现表格渲染和新建记录。第二阶段实现单元格编辑和所有字段类型的处理。第三阶段加上排序、筛选、搜索。第四阶段实现本地存储自动保存。第五阶段做 CSV/JSON 导入导出、附件功能。第六阶段整体样式美化和各种交互细节打磨。每个阶段都是一个独立的对话AI 在上下文里只需要关注当前阶段的目标生成质量会高很多。如果一口气让它输出所有代码对话上下文过长它很容易遗漏前文的需求细节生成的代码要来回改好几遍。4.3 让 AI 帮你写“一次性代码”而不是核心逻辑我在这个项目里慢慢摸索出一个经验AI 最适合做那些重复度高、思路固定、但写起来繁琐的代码。比如生成所有字段类型的渲染函数、写 CSV 解析器、写日期格式化的工具函数、做正则表达式匹配。这类代码描述清楚就能一键生成自己写反而浪费时间。而那些需要全局思维的部分比如数据状态管理、生命周期控制、模块之间的耦合关系我不会让 AI 直接输出完整方案而是自己规划好架构AI 用来补细节。比如我定义了updateDatabase作为状态管理的统一入口然后让 AI 在所有编辑函数的代码里都调用这个函数它生成的代码就不会跑偏整体架构也不会被 AI 的自由发挥打乱。4.4 AI 调试问题的技巧把报错连同上下文一起贴给它实际开发中肯定会遇到报错。我发现最高效的调试方式是把报错信息、相关代码片段、预期行为、实际行为一起贴给 AI。例如点击“新增记录”按钮后表格没有刷新控制台报错 TypeError: Cannot read properties of undefined (reading cells)。相关代码是[粘贴代码]。预期是新增一条空记录并立即显示。请分析原因并给出修复。模型只看报错信息往往不知道上下文但有了代码片段和预期行为它就能快速定位问题。按照这个方式整体调试速度比传统方式快了很多。4.5 一些包装层面的人工打磨AI 生成的代码最后还要做几件收尾工作。一个是格式化保持统一的缩进风格并清理无用代码方便自己后面看代码另一个是代码审查重点关注是否有内存泄漏特别是有 setInterval 或事件监听器的地方、是否有 XSS 漏洞比如用 innerHTML 插入未转义的用户输入、是否有逻辑漏洞比如筛选后无法恢复原始数据。这里有件事让我印象很深。AI 生成的渲染函数里单元格的值直接用了innerHTML。如果我把附件信息或者用户输入的那段文字直接插进去其中包含 HTML 标签时就会被浏览器解析成 HTML。比如我想在表格里存一段带有script标签的笔记文本就可能被当成脚本执行从而带来安全风险。后来我把所有“纯文本展示”的位置都改成了textContent只有明确需要渲染富文本的位置才用innerHTML。这个审查如果交给 AI 来做它往往会忽略。5. 常见问题与排查技巧实录这部分我整理一些这个项目在开发、使用过程中真实遇到的典型问题做成一个速查清单希望后面的人少走一点弯路。5.1 表格渲染两三秒后卡死原因基本都出在“一次性渲染了所有行”。我一开始图省事直接在渲染时把一万条记录全部生成tr塞进 DOM结果页面卡成幻灯片。排查思路是打开浏览器开发者工具选择 Performance 面板录制一段操作看耗时集中在哪个函数。后来我改成虚拟滚动只渲染可视区域内的几十行页面就流畅了虽然滚动条仍然代表全量数据。具体做法是监听表格容器的 scroll 事件动态计算当前滚到的行号然后更新 tbody 内容。5.2 筛选后新增记录表格却跑到底部这个问题的表现是我在某个筛选视图下新增了一条新记录结果刚加完新记录从界面上消失了。排查后发现问题出在新增记录时是直接 push 到 records 数组末尾的而当前的筛选条件把它过滤掉了导致视觉上看起来是“数据丢了”。解决方法是新增记录后加入一个“高亮定位”逻辑——在数据模型里临时标记这条记录即使它被当前筛选条件过滤也会单独显示在表格顶部并高亮一段时间。这个细节非常重要如果不处理用户会不停地以为自己的数据凭空消失了。5.3 localStorage 满了保存失败前面提到 localStorage 只有 5MB 左右配额。如果是纯文本数据比如几百条任务记录几百 KB 根本没问题。但一旦加了附件哪怕只是几张手机拍的照片就很容易超过配额。保存失败时setItem 会抛一个 QuotaExceededError 异常。我的处理方案是在保存前先估算 stringify 后的体积超过阈值就自动切换存储引擎到 IndexedDB。如果你在本地测试时发现“刷新后数据全没了但控制台有报错”大概率就是死在了这一步。5.4 常见问题速查表我把开发、测试过程中遇到的高频问题整理成一张表问题现象根本原因快速解决方案Excel 打开 CSV 中文乱码文件缺少 UTF-8 BOM导出文本时头部加\uFEFF中文输入法回车误提交未处理 composition 事件监听 compositionstart/endCSV 导入后列错位字段包含逗号但没加引号转义所有字段用双引号包裹并转义内部引号表格大数据量卡顿一次性渲染所有 DOM 节点改成视口内渲染虚拟滚动刷新后数据丢失localStorage 容量超限或未触发保存保存前估算体积、切换 IndexedDB、监听 beforeunload备份文件过大图片等附件以 base64 塞进 JSON用 IndexedDB 存大文件JSON 只存引用手机上布局错乱没有适配窄屏增加响应式布局表格区域允许横向滚动浏览器打开报错 blank本地文件路径下部分 API 受限加 try-catch 并在 localStorage 不可用时报友好提示表格里的每一条都是真实场景里遇到过的不是堆理论。尤其是中文输入法那条做中文互联网应用的人基本都会碰上。5.5 关于代码组织的一个小建议AI 生成的代码如果不做组织最后会变成一个大杂烩所有功能函数写在一个文件里要么不断重构要么干脆重写。我后来花了点时间把最终代码拆分成几个模块storage.js管数据读写render.js管界面渲染fields.js管字段类型的处理逻辑utils.js放各种工具函数。如果希望项目长期维护、后期加功能这个拆分是值得的。如果你只是想临时用一下一个文件几十 KB 也能跑。6. 本地部署、代码使用与后续扩展思路6.1 最简运行方式双击 HTML 文件这个项目最方便的运行方式就是把所有代码保存在一个.html文件里然后双击用浏览器打开。不需要安装 Node.js不需要启动任何服务不需要配置环境变量打开就能用。这是纯前端方案最好的地方。如果你担心本地双击打开时浏览器对 JavaScript 的某些限制其实完全不用。常规的 DOM 操作、localStorage、FileReader、Blob 下载这些 API在 file:// 协议下都能正常工作。唯一需要留意的是如果你通过 CDN 引入了第三方库比如 JSZip双击打开时依赖网络加载离线环境会失败。解决办法是提前下载好对应库文件放到同一个文件夹在 HTML 里引用相对路径。6.2 部署到线上供多人查看如果想跟同事、朋友共享这个工具可以把它部署到任意静态托管平台。前端静态托管的方案很多把 HTML、CSS、JS 文件或单个 HTML 文件丢上去就能得到公网地址。部署后唯一需要注意的是每个人浏览器里的数据是独立的A 用户添加的数据 B 用户看不到。要实现多人共享数据需要把存储层改成后端服务这超出了这个纯前端项目的范围。6.3 后续功能扩展思路这个项目做完之后我列了一些后续想加的功能可以作为参考看板视图单选字段的选项映射为看板列卡片按选项值分列展示。核心也就是对 records 按字段值分组后渲染可以在现有代码上扩展。日历视图按日期字段把记录映射到日历格子里同样是对 records 的过滤和分组。字段统计栏表格底部显示数字字段的求和、平均值、最大值、最小值满足最基础的统计需求。数据同步接入 WebDAV 协议或第三方网盘 API把 JSON 备份文件自动同步到自己的存储空间解决多设备数据迁移问题。多人实时协作用 WebSocket 或 WebRTC 做实时协同编辑但这个改动量非常大对纯前端方案来说优先级不高。我自己实际用下来这个工具最舒服的场景是个人任务管理、读书清单记录、观影列表、旅行计划、以及各种需要“表格但不至于打开 Excel”的场景。它没有飞书多维表格那么重也不需要注册账号数据就在本地随时双击就用用完关掉数据还在那等你。如果你平时也有这类轻量数据管理需求完全可以照着上面的思路自己动手做一个。最后再分享一个小经验在整个开发过程中AI 确实是极高效的编码助手但真正决定项目质量的还是前期的结构设计和后期的代码审查。所谓 AI 写代码更像是一位速度极快但偶尔会开小差的初级工程师你给它拆好任务、划好边界它能把效率拉满你要是把整个项目稀里糊涂丢给它后面有得哭。这个界限想清楚了AI 辅助开发会快得超乎你的预期。 纯前端多维表格开发实战：AI辅助与数据存储全解析
1. 项目思路与方案选型先交代一下这个项目的来龙去脉。有一次我为个人项目做数据整理想把几十条任务、状态、负责人、截止日期这些信息管理起来。第一反应是用飞书多维表格或者在线表格但发现为了这么点数据要么得注册账号、建团队空间要么得下载客户端数据还要传到别人服务器上。我当时的诉求其实很简单就是一个本地运行的、长得像多维表格的工具双击就能用数据不出电脑最好还能按自己的需要改功能。于是就有了这个项目——用 AI 辅助开发一个纯前端的多维表格技术栈就是 HTML CSS JavaScript没有任何后端所有数据都存在浏览器本地。你把它部署到任意静态托管平台或者干脆在自己电脑上双击打开 HTML 文件就能跑起来。整个过程里AI 承担了一大部分编码工作我主要做架构设计、需求拆分和代码审查。1.1 为什么选纯前端而不是带后端这个问题我在动手前认真考虑过。带后端意味着更完整的多用户协作、权限管理、云端同步但这些对我来说都不需要。我的使用场景是单人、单机、快速启动一个纯前端方案就能覆盖而且优势非常明显零部署成本不需要准备服务器、数据库、域名任何一个静态托管服务都能跑甚至双击本地 HTML 文件就能打开。数据主权在自己手里所有数据存浏览器本地没有第三方服务隐私安全天然可控。开发周期大幅缩短纯前端可以不写接口、不跑数据库、不考虑鉴权把所有精力聚焦在表格交互本身。当然纯前端方案不是没有代价。浏览器本地存储有容量上限不同浏览器的 IndexedDB 配额不一样一般能存几百 MB 到上 GB对文本型数据完全够用。另外数据只存在于当前浏览器里换个电脑数据不会跟着走所以我会在后面加导入导出功能把数据以文件形式备份出来。1.2 AI 开发与传统写代码的差别这个项目最大的特点是代码的很大一部分不是我逐行敲的而是我和 AI 对话“聊”出来的。我负责给出功能描述、数据结构、交互细节AI 负责把需求翻译成代码。这么说有点抽象举两个直观的感受传统方式写一个表格渲染逻辑要去操作 DOM、处理事件绑定、兼顾各种边界情况可能要花一到两天。AI 辅助下我用一段自然语言描述字段类型、渲染要求、编辑方式它能直接生成一个可运行的雏形我再在这个基础上修改完善。遇到 bug不用再像以前那样到处 console.log 打日志排查直接把报错信息复制给 AI它能快速分析可能的原因很多时候第一版答案就能解决问题。但这里有个必须要说清楚的坑AI 能写出看起来能跑的代码但不代表代码一定正确。尤其是涉及异步逻辑、状态同步、数据一致性这类问题时AI 生成的东西经常是“表面对、实际错”。所以整个开发过程我把 AI 定位成一个非常高效的程序员但不是项目负责人项目的设计思路、模块划分、代码审查仍然由我来掌控。1.3 整体功能范围在动手前我列了一个功能清单经过取舍后确定了第一版的范围支持多张数据表每张表可以自定义字段字段类型包括文本、数字、单选、多选、日期、勾选复选框、附件。支持记录的增删改查行内点击可直接编辑单元格内容。支持视图的筛选、排序、搜索做到基本的“表格想怎么看就怎么看”。支持数据导入导出至少要有 CSV 和 JSON 两种格式方便备份和迁移。整体界面风格参考多维表格的桌面端布局左侧是表列表中间是数据区域右侧是字段信息顶部是功能按钮。这些功能的实现难度不算太大但涉及的细节特别多。下面我把每一步的实现过程拆开来讲包括具体的代码思路、踩过的坑、以及如何用 AI 高效推进这个项目。2. 数据结构设计与核心场景建模多维表格之所以叫“多维”是因为它不是简单的二维表格而是由“数据表 → 字段 → 记录”三层结构构成的。把这个数据模型想清楚后面的功能才有实现的根基。2.1 三层数据模型我一开始就确定了这样的基础数据结构// 一个完整的数据库文件 const database { tables: [ { id: table_001, name: 项目任务, fields: [ { id: field_001, name: 任务名称, type: text, options: null }, { id: field_002, name: 负责人, type: singleSelect, options: [张伟, 李娜, 王强] }, { id: field_003, name: 优先级, type: singleSelect, options: [高, 中, 低] }, { id: field_004, name: 截止日期, type: date, options: null }, { id: field_005, name: 完成, type: checkbox, options: null } ], records: [ { id: record_001, cells: { field_001: 开发登录页面, field_002: 张伟, field_003: 高, field_004: 2025-03-15, field_005: true } } ] } ] };这个结构借鉴了 Notion 和飞书的数据设计思路。每个表有独立的字段定义每一条记录用 record_id 加 cells 对象存储单元格数据单元格的值由对应字段的 id 来索引。这样设计的好处在于字段与记录解耦以后新增字段时老记录不需要同步加数据未填写的字段返回空值即可。易于扩展如果以后要加“创建时间”这种系统字段只需要在字段列表里加一条定义不影响已有数据。序列化简单整个 database 对象可以直接 JSON.stringify 存到浏览器本地也可以导出成 JSON 文件再导入。2.2 字段类型怎么设计字段类型是整个表格系统的灵魂。我给这个项目设计了 7 种字段文本、数字、单选、多选、日期、勾选、附件。每种字段背后对应不同的数据存储方式和渲染交互逻辑。文本字段简单直接用字符串存储即可。但数字字段我做了特殊处理——存储时保留原始数字类型而不是字符串。这样以后做求和、平均值统计时不需要再 parseFloat 转换能在数据层面保证类型正确性。单选字段和多选字段都需要先在字段定义里配置选项列表。单选字段的实际值是一个字符串多选字段则是一个数组。这里有个实用细节当选项列表被修改时老数据里可能还留着旧选项值所以读取单元格时要做一层容错处理不存在的选项值可以原样显示不能直接丢弃。日期字段我建议存储成YYYY-MM-DD这种纯字符串格式不要存时间戳。原因很简单日期选择器给出的就是这种格式展示时不需要再次格式化对用户更友好。如果以后需要按日期排序字符串格式的 ISO 日期也能直接比较排序不影响功能。附件字段是最特殊的后面专门展开讲。2.3 视图层的筛选、排序与搜索多维表格的“多维”感很大程度来自视图功能。我实现了筛选和排序逻辑其实都是在 records 数组上做过滤和重排再渲染到界面上。筛选条件的结构是这样的// 筛选配置 const filterConfig { fieldId: field_003, // 针对哪个字段 operator: is, // 操作符: is / isNot / contains / greaterThan / lessThan / isEmpty value: 高 };渲染数据时先遍历所有筛选条件逐条过滤再对结果做排序。排序则支持多个字段的优先级实现了一个简单的多级排序器records.sort((a, b) { for (const sortItem of sortConfig) { const aVal getCellValue(a, sortItem.fieldId); const bVal getCellValue(b, sortItem.fieldId); if (aVal bVal) return sortItem.order asc ? -1 : 1; if (aVal bVal) return sortItem.order asc ? 1 : -1; } return 0; });搜索功能也值得讲一下。多维表格的搜索通常是对整行做全文搜索不是针对单个字段。我用了最简单粗暴的方式——遍历所有字段的所有单元格把值拼成一条字符串再用 indexOf 判断是否包含关键词。对于几千条数据来说这种方案性能完全够用代码还极其简洁。2.4 数据流的单向设计这个项目我没有引入 Vue、React 这类框架用的是原生 JavaScript所以状态管理要自己处理。我采用了一个类似单向数据流的模式// 所有修改都走这个统一入口 function updateDatabase(mutator) { mutator(database); saveToLocalStorage(database); renderAll(); }所有的新增记录、修改单元格、删除记录、调整字段类型最终都统一走 updateDatabase 这个函数。先修改数据再持久化到本地存储最后触发重新渲染。这样做的好处是逻辑链路清晰永远不会出现界面状态和内存数据不一致的情况。用 AI 辅助写这类代码时方向性的设计一定要自己把控AI 生成的代码往往是一个一个孤立的功能函数中间没有统一的数据流管理。如果我直接照搬 AI 的代码很快就变成“这里改一下那里改一下”调试起来非常痛苦。3. 核心功能的实操实现细节设计方案定下来后真正的开发就是一场硬仗。下面我从表格渲染、单元格编辑、附件处理、持久化和导入导出几个维度把核心代码思路和踩坑经验分享出来。3.1 表格渲染方案选型表格区域的渲染主要有三种常见方案原生 HTML table、Canvas 绘制、虚拟滚动表格。我最终选择了 HTML table 虚拟滚动的混合方案。用 HTML table 的好处非常明显浏览器原生支持表格的语义化结构单元格的点击事件、键盘事件都很好绑定而且开发调试时可以直接看到 DOM 结构对 AI 生成的代码也很友好。 Canvas 画表格在渲染大量数据时性能好但交互做起来很痛苦——单元格的点击命中测试、文本选中、滚动重绘全都要自己实现收益不划算。我的实现思路是表格头部用单独的thead渲染字段名表体用tbody渲染数据行。表体只渲染当前视口范围内的行滚动时动态更新渲染内容。这样即使表里有一万条数据屏幕上实际渲染的 DOM 节点也就几十个性能不会崩。3.2 单元格编辑与中文输入法的坑这一节是整个项目里我踩坑最多的部分。多维表格的核心交互是“点一下单元格就能编辑”这个需求看起来简单细节却非常多。我的实现思路是当用户点击某个单元格时把该单元格的内容替换成input或textarea并自动聚焦。编辑完成后通过 blur 事件或回车键把内容写回数据。但这里隐藏着一个非常经典的问题——中文输入法的 composition 事件。如果用户在输入框里用拼音输入中文按回车时输入法会先触发compositionend事件随后才可能触发 keydown 事件。如果我在 keydown 里直接禁止回车提交并把内容写回那么输入“你好”时按空格选字、按回车确认拼音都可能被误判为“编辑完成”导致只写入了拼音字母。解决办法是监听compositionstart和compositionend在输入法组合期间挂起回车确认的逻辑let isComposing false; input.addEventListener(compositionstart, () isComposing true); input.addEventListener(compositionend, () isComposing false); input.addEventListener(keydown, (e) { if (e.key Enter !isComposing) { commitEdit(); } });这个问题不亲手做一遍真的发现不了至少在最初版本里我完全没意识到结果用中文测试时出了各种诡异问题。3.3 附件字段文件转 base64 还是用 IndexedDB附件字段是另一个大坑。多维表格允许在单元格里上传图片、文档那这些数据存哪里有两种思路我用的是“小文件转 base64 存内存大文件用 IndexedDB 存二进制”。把图片转成 base64 数据 URI 的代码非常简短function fileToBase64(file) { return new Promise((resolve, reject) { const reader new FileReader(); reader.onload () resolve(reader.result); reader.onerror reject; reader.readAsDataURL(file); }); }这样存到数据对象里JSON.stringify 之后可以直接保存非常简单。但副作用是base64 编码会让文件体积膨胀约 33%每 3 个字节变成 4 个字符如果附件比较大整个 database 对象序列化之后会很臃肿每次操作都重新保存一遍性能会越来越差。所以我的建议是小于 1MB 的文件走 base64 存 localStorage大于 1MB 的文件存 IndexedDB数据库只保存一个引用 ID。IndexedDB 原生支持存储 Blob 和 File 对象读取效率远高于把大字符串塞进 JSON。具体实现这里不展开但只要涉及附件功能建议一开始就把这个架构想清楚。3.4 数据持久化的三种策略浏览器端的数据持久化方案主要有 localStorage、sessionStorage、IndexedDB 三种。sessionStorage 关掉标签页就没了不考虑。localStorage 和 IndexedDB 是主要选择。localStorage 的 API 极其简单只有 getItem、setItem、removeItem但它有一个重要限制——大部分浏览器单个域名下只有 5MB 左右的存储空间。所以我做了一层封装默认优先用 localStorage一旦检测到要存储的 JSON 字符串超过 3MB就自动切换到 IndexedDB。保存操作我做了防抖处理。用户在表格里连续编辑时如果每改一个字符就执行一次 stringify localStorage.setItem既卡顿又频繁写入。我设置了一个 800ms 的防抖延迟用户停止操作 800ms 后再保存。let saveTimer null; function scheduleSave() { clearTimeout(saveTimer); saveTimer setTimeout(() { localStorage.setItem(multiTableDB, JSON.stringify(database)); }, 800); }这里有个小细节值得注意在页面关闭前防抖定时器可能还没触发数据就丢了。所以我监听beforeunload事件在关闭页面时强制保存一次。3.5 CSV 导出的编码问题CSV 导出功能是我和 AI 协作开发时返工最多的地方。CSV 文件本质上是一个用逗号分隔的纯文本文件用最简单的思路就是把每行记录拼成字符串然后用\n拼接所有行function exportCSV() { const headers fields.map(f f.name).join(,); const rows records.map(r { return fields.map(f formatCellValue(r.cells[f.id])).join(,); }); const csvContent \uFEFF [headers, ...rows].join(\n); const blob new Blob([csvContent], { type: text/csv;charsetutf-8 }); const url URL.createObjectURL(blob); const a document.createElement(a); a.href url; a.download table.name .csv; a.click(); URL.revokeObjectURL(url); }那个\uFEFF是 UTF-8 BOM是这次任务最重要的收获。如果直接用 Excel 打开不带 BOM 的 UTF-8 CSV 文件Excel 会默认按 GBK 编码解析中文全部变成乱码。加上 BOM 后Excel 会自动识别为 UTF-8中文才能正常显示。这个细节网上虽然很多资料提过但自己不踩一遍永远记不住。另外单元格内的值如果包含逗号、换行符或双引号直接拼进 CSV 会导致列错位。正确的做法是对每个值用双引号包裹内部的双引号转义成两个双引号function escapeCSVField(value) { if (value.includes(,) || value.includes() || value.includes(\n)) { return value.replace(//g, ) ; } return value; }3.6 从 CSV 导入的反向处理导入 CSV 时又遇到另一个坑。CSV 文件可能是 GBK 编码Windows 上常见也可能是 UTF-8。浏览器用 FileReader 的 readAsText 默认按 UTF-8 解码GBK 文件会直接乱码。解决办法是检测文件开头有没有 BOM没有 BOM 就尝试用 TextDecoder 指定 gbk 编码解码async function parseCSVFile(file) { const buffer await file.arrayBuffer(); const bytes new Uint8Array(buffer); // 检查是否带 UTF-8 BOM if (bytes[0] 0xEF bytes[1] 0xBB bytes[2] 0xBF) { return new TextDecoder(utf-8).decode(bytes); } // 尝试按 gbk 解码如果中文乱码再用 UTF-8 try { const text new TextDecoder(gbk).decode(bytes); if (isReasonableText(text)) return text; } catch(e) {} return new TextDecoder(utf-8).decode(bytes); }当然自动编码检测不是百分百可靠所以我还在界面上加了一个“选择编码方式”的手动选项让用户遇到乱码时可以手动切换 UTF-8 / GBK。这种问题在“教科书”上很少讲但在实际处理国内用户场景时特别常见。3.7 附件导出时的 Blob 处理把附件从 IndexedDB 导出成压缩包是另一个让人头疼的点。浏览器原生的方式如果要打包多个文件成一个 zip需要引入 JSZip 库。既然这个项目是“纯前端”我用的是 CDN 加载第三方库的方式并没有把所有代码都自己写一遍。script srchttps://cdn.jsdelivr.net/npm/jszip3.10.1/dist/jszip.min.js/script导出时遍历所有记录把附件文件从 IndexedDB 取出来用 JSZip 添加到 zip 包然后生成 Blob 触发下载。JSZip 会把二进制内容原样打包不会做额外压缩所以这一步其实相当直接。但如果在纯离线环境使用比如内网部署CDN 可能加载不了需要把 JSZip 库文件下载到本地和 HTML 放同一目录。这也是我后来优化时改的一个点—— 把第三方依赖工具全部本地化确保双击 HTML 文件时不需要联网也能用。4. AI 辅助开发的实操全记录接下来讲大家最关心的部分我是怎么利用 AI 来辅助完成这个项目的。准确地说是对 AI 代码生成和人工审查的边界如何划分以及各个开发阶段怎么给 AI 下指令。4.1 准备一个可执行的高质量需求文档我一开始没有直接让 AI“写一个多维表格”而是花了近两个小时整理了一版详细的需求文档。内容包括功能模块清单、每个字段类型的定义、界面布局描述、数据存储方案、操作交互细节。这些需求描述不是一次性的对话记录而是整理成一份结构化的文档再分模块喂给 AI。比如“单选字段”这个需求我这样描述实现单选字段的编辑。点击单元格时显示一个下拉列表列表项的来源是字段定义里的 options 数组。选中后立即写入记录单元格显示选项文本。如果选项文本为空则显示一个占位符“未设置”。这样清晰描述后AI 生成的第一版下拉选择器基本就能用了。相反如果我只说“实现单选字段”它可能会做出一个非常难用的组件——比如在下拉列表中塞了输入框或者选中后需要二次确认。4.2 分阶段开发而不是一口气全部生成我的开发顺序是这样的第一阶段搭好 HTML 基础布局左侧表列表 右侧表格区域实现表格渲染和新建记录。第二阶段实现单元格编辑和所有字段类型的处理。第三阶段加上排序、筛选、搜索。第四阶段实现本地存储自动保存。第五阶段做 CSV/JSON 导入导出、附件功能。第六阶段整体样式美化和各种交互细节打磨。每个阶段都是一个独立的对话AI 在上下文里只需要关注当前阶段的目标生成质量会高很多。如果一口气让它输出所有代码对话上下文过长它很容易遗漏前文的需求细节生成的代码要来回改好几遍。4.3 让 AI 帮你写“一次性代码”而不是核心逻辑我在这个项目里慢慢摸索出一个经验AI 最适合做那些重复度高、思路固定、但写起来繁琐的代码。比如生成所有字段类型的渲染函数、写 CSV 解析器、写日期格式化的工具函数、做正则表达式匹配。这类代码描述清楚就能一键生成自己写反而浪费时间。而那些需要全局思维的部分比如数据状态管理、生命周期控制、模块之间的耦合关系我不会让 AI 直接输出完整方案而是自己规划好架构AI 用来补细节。比如我定义了updateDatabase作为状态管理的统一入口然后让 AI 在所有编辑函数的代码里都调用这个函数它生成的代码就不会跑偏整体架构也不会被 AI 的自由发挥打乱。4.4 AI 调试问题的技巧把报错连同上下文一起贴给它实际开发中肯定会遇到报错。我发现最高效的调试方式是把报错信息、相关代码片段、预期行为、实际行为一起贴给 AI。例如点击“新增记录”按钮后表格没有刷新控制台报错 TypeError: Cannot read properties of undefined (reading cells)。相关代码是[粘贴代码]。预期是新增一条空记录并立即显示。请分析原因并给出修复。模型只看报错信息往往不知道上下文但有了代码片段和预期行为它就能快速定位问题。按照这个方式整体调试速度比传统方式快了很多。4.5 一些包装层面的人工打磨AI 生成的代码最后还要做几件收尾工作。一个是格式化保持统一的缩进风格并清理无用代码方便自己后面看代码另一个是代码审查重点关注是否有内存泄漏特别是有 setInterval 或事件监听器的地方、是否有 XSS 漏洞比如用 innerHTML 插入未转义的用户输入、是否有逻辑漏洞比如筛选后无法恢复原始数据。这里有件事让我印象很深。AI 生成的渲染函数里单元格的值直接用了innerHTML。如果我把附件信息或者用户输入的那段文字直接插进去其中包含 HTML 标签时就会被浏览器解析成 HTML。比如我想在表格里存一段带有script标签的笔记文本就可能被当成脚本执行从而带来安全风险。后来我把所有“纯文本展示”的位置都改成了textContent只有明确需要渲染富文本的位置才用innerHTML。这个审查如果交给 AI 来做它往往会忽略。5. 常见问题与排查技巧实录这部分我整理一些这个项目在开发、使用过程中真实遇到的典型问题做成一个速查清单希望后面的人少走一点弯路。5.1 表格渲染两三秒后卡死原因基本都出在“一次性渲染了所有行”。我一开始图省事直接在渲染时把一万条记录全部生成tr塞进 DOM结果页面卡成幻灯片。排查思路是打开浏览器开发者工具选择 Performance 面板录制一段操作看耗时集中在哪个函数。后来我改成虚拟滚动只渲染可视区域内的几十行页面就流畅了虽然滚动条仍然代表全量数据。具体做法是监听表格容器的 scroll 事件动态计算当前滚到的行号然后更新 tbody 内容。5.2 筛选后新增记录表格却跑到底部这个问题的表现是我在某个筛选视图下新增了一条新记录结果刚加完新记录从界面上消失了。排查后发现问题出在新增记录时是直接 push 到 records 数组末尾的而当前的筛选条件把它过滤掉了导致视觉上看起来是“数据丢了”。解决方法是新增记录后加入一个“高亮定位”逻辑——在数据模型里临时标记这条记录即使它被当前筛选条件过滤也会单独显示在表格顶部并高亮一段时间。这个细节非常重要如果不处理用户会不停地以为自己的数据凭空消失了。5.3 localStorage 满了保存失败前面提到 localStorage 只有 5MB 左右配额。如果是纯文本数据比如几百条任务记录几百 KB 根本没问题。但一旦加了附件哪怕只是几张手机拍的照片就很容易超过配额。保存失败时setItem 会抛一个 QuotaExceededError 异常。我的处理方案是在保存前先估算 stringify 后的体积超过阈值就自动切换存储引擎到 IndexedDB。如果你在本地测试时发现“刷新后数据全没了但控制台有报错”大概率就是死在了这一步。5.4 常见问题速查表我把开发、测试过程中遇到的高频问题整理成一张表问题现象根本原因快速解决方案Excel 打开 CSV 中文乱码文件缺少 UTF-8 BOM导出文本时头部加\uFEFF中文输入法回车误提交未处理 composition 事件监听 compositionstart/endCSV 导入后列错位字段包含逗号但没加引号转义所有字段用双引号包裹并转义内部引号表格大数据量卡顿一次性渲染所有 DOM 节点改成视口内渲染虚拟滚动刷新后数据丢失localStorage 容量超限或未触发保存保存前估算体积、切换 IndexedDB、监听 beforeunload备份文件过大图片等附件以 base64 塞进 JSON用 IndexedDB 存大文件JSON 只存引用手机上布局错乱没有适配窄屏增加响应式布局表格区域允许横向滚动浏览器打开报错 blank本地文件路径下部分 API 受限加 try-catch 并在 localStorage 不可用时报友好提示表格里的每一条都是真实场景里遇到过的不是堆理论。尤其是中文输入法那条做中文互联网应用的人基本都会碰上。5.5 关于代码组织的一个小建议AI 生成的代码如果不做组织最后会变成一个大杂烩所有功能函数写在一个文件里要么不断重构要么干脆重写。我后来花了点时间把最终代码拆分成几个模块storage.js管数据读写render.js管界面渲染fields.js管字段类型的处理逻辑utils.js放各种工具函数。如果希望项目长期维护、后期加功能这个拆分是值得的。如果你只是想临时用一下一个文件几十 KB 也能跑。6. 本地部署、代码使用与后续扩展思路6.1 最简运行方式双击 HTML 文件这个项目最方便的运行方式就是把所有代码保存在一个.html文件里然后双击用浏览器打开。不需要安装 Node.js不需要启动任何服务不需要配置环境变量打开就能用。这是纯前端方案最好的地方。如果你担心本地双击打开时浏览器对 JavaScript 的某些限制其实完全不用。常规的 DOM 操作、localStorage、FileReader、Blob 下载这些 API在 file:// 协议下都能正常工作。唯一需要留意的是如果你通过 CDN 引入了第三方库比如 JSZip双击打开时依赖网络加载离线环境会失败。解决办法是提前下载好对应库文件放到同一个文件夹在 HTML 里引用相对路径。6.2 部署到线上供多人查看如果想跟同事、朋友共享这个工具可以把它部署到任意静态托管平台。前端静态托管的方案很多把 HTML、CSS、JS 文件或单个 HTML 文件丢上去就能得到公网地址。部署后唯一需要注意的是每个人浏览器里的数据是独立的A 用户添加的数据 B 用户看不到。要实现多人共享数据需要把存储层改成后端服务这超出了这个纯前端项目的范围。6.3 后续功能扩展思路这个项目做完之后我列了一些后续想加的功能可以作为参考看板视图单选字段的选项映射为看板列卡片按选项值分列展示。核心也就是对 records 按字段值分组后渲染可以在现有代码上扩展。日历视图按日期字段把记录映射到日历格子里同样是对 records 的过滤和分组。字段统计栏表格底部显示数字字段的求和、平均值、最大值、最小值满足最基础的统计需求。数据同步接入 WebDAV 协议或第三方网盘 API把 JSON 备份文件自动同步到自己的存储空间解决多设备数据迁移问题。多人实时协作用 WebSocket 或 WebRTC 做实时协同编辑但这个改动量非常大对纯前端方案来说优先级不高。我自己实际用下来这个工具最舒服的场景是个人任务管理、读书清单记录、观影列表、旅行计划、以及各种需要“表格但不至于打开 Excel”的场景。它没有飞书多维表格那么重也不需要注册账号数据就在本地随时双击就用用完关掉数据还在那等你。如果你平时也有这类轻量数据管理需求完全可以照着上面的思路自己动手做一个。最后再分享一个小经验在整个开发过程中AI 确实是极高效的编码助手但真正决定项目质量的还是前期的结构设计和后期的代码审查。所谓 AI 写代码更像是一位速度极快但偶尔会开小差的初级工程师你给它拆好任务、划好边界它能把效率拉满你要是把整个项目稀里糊涂丢给它后面有得哭。这个界限想清楚了AI 辅助开发会快得超乎你的预期。