做后台管理系统的人大概都有过这个瞬间产品经理甩过来一张 Windows 资源管理器的截图说就照这个做我们的素材库/网盘/项目文件管理页要一模一样。于是你打开 Vue左边写一棵树右边写一个列表双击进去点面包屑返回看起来挺顺。然后需求开始加码——要能框选、要按住 Ctrl 挑几个、要拖到文件夹里、右键要出新文件夹、重命名要能校验、文件上万条不能卡。这时候你会发现真正难的不是画界面而是状态怎么放、几何怎么算、事件怎么收口。这篇就围绕VUE 仿 windows 文件夹文件这件事把我在几个素材管理系统里踩过的坑和落地方案摊开讲代码用 Vue 3 组合式 API 写逻辑框架换成 Vue 2 或 React 也一样成立。1. 动手之前先分清楚三种状态混在一起必翻车我见过太多这个功能的实现一开始就是一棵深层嵌套的响应式大树节点上挂着selected、expanded、editing、loading再来一个watch(tree, handler, { deep: true })。前两百个节点跑得好好的导入真实数据后直接白屏——不是因为渲染慢是因为深度侦听一个几千节点的对象树光建立依赖就够呛。1.1 数据域、视图域、交互域必须切开我的划分方式是这样状态域存什么生命周期存放位置数据域节点本体id、name、type、parentId、size、mtime跟随接口数据需要持久化Pinia 的useFsStore视图域当前路径、视图模式图标/列表、排序字段与方向、滚动位置刷新即重置可以存 URL query组件内 ref 或独立 store交互域选中集合、框选矩形、拖拽中的源、剪贴板、重命名编辑 id高频变化一秒可能变几十次shallowRef/reactive(new Set())为什么要切开因为三者的更新频率差了不止一个数量级。数据域一天变几次视图域一次点击变一次交互域鼠标一动就变。把它们塞进同一个响应式对象等于让鼠标划过一个框去触发整棵树重新收集依赖。提示判断某个状态该放哪一域就问一句这个状态刷新页面后还应不应该存在。应该存在的是数据域不该存在的是视图域一秒钟变好几次的是交互域。1.2 路径用数组存不要用字符串D:\\项目\\src\\components这种字符串路径看着直观用起来处处是坑反斜杠在 JS 字符串里要转义、Windows 和类 Unix 分隔符不一致、中文路径遇到大小写比较要额外处理。我改成数组[此电脑, D盘, 项目, src]。好处立刻体现出来面包屑直接v-for渲染上一级就是path.slice(0, -1)判断两个节点是否是同一目录直接pathA.join(/) pathB.join(/)不需要处理任何转义往 URL 里塞的时候join(|)取出来split(|)比编码整个路径字符串干净得多。1.3 嵌套树和扁平表选错一个后面全是补丁这是我认为最关键的一次架构选择。先把两者摊开对比对比维度嵌套树children 数组扁平 Map childrenIds按 id 找节点递归 O(深度)O(1) 直接查表移动一个节点递归找父节点再 splice改两个数组几行代码深层响应式开销高层级越深越明显低Map 是浅层的渲染树组件天然递归直接吃 children需要按需组装一层视图数据移动端 / 大数据量容易炸稳结论很明确存储用扁平渲染时组装。真正的数据结构长这样// 节点本体全部塞进一个 Map // { id, name, type: folder | file, parentId, size, mtime, ext, deletedAt } const nodeMap shallowRef(new Map()) // 父子关系单独索引避免每次都要全表扫 const childrenIndex shallowRef(new Map()) // parentId - id[]拿某个目录下的文件列表就是function listChildren(folderId) { const ids childrenIndex.value.get(folderId) || [] return ids.map(id nodeMap.value.get(id)).filter(Boolean) }这里有两个细节值得说。第一nodeMap用shallowRef意味着我改节点内部字段时要整体替换引用看起来麻烦一点但换来的是 Vue 不会给 Map 里每个节点套 Proxy——上万个节点时这个差别非常明显。第二childrenIndex的数组顺序就是渲染顺序的原始依据排序时只重排这个数组不动节点本体撤销排序也不会有副作用。2. 左侧目录树和右侧文件列表怎么保证永远说的是同一个地方左右联动是这类页面的第一道坎。用户点树上的节点右边要跳用户在右边双击文件夹进去树要展开并高亮用户点面包屑往回走两边都要跟着变。新手最容易犯的错是在每个交互回调里各写一遍同步三件事写着写着就有六七处重复逻辑改一处漏三处。2.1 只保留一个真相currentPath我的做法是所有操作只负责修改currentPath然后由一个watch集中处理副作用。const currentPath ref([此电脑]) watch(currentPath, (path) { // 1. 展开树上对应的所有祖先节点 expandedIds.value new Set([...expandedIds.value, ...getAncestorIds(path)]) // 2. 高亮当前节点由树组件自己根据 currentPath 最后一项判断 // 3. 清空选中与框选 selection.clear() // 4. 重置滚动位置 listScrollTop.value 0 // 5. 写回 URL支持刷新还原 router.replace({ query: { p: path.join(|) } }) }, { flush: post })flush: post这个参数容易被忽略。默认的pre会在组件更新前触发侦听如果回调里依赖了 DOM 尺寸比如重新计算列数拿到的还是旧的。放到post里最稳妥。2.2 树的展开状态别写进节点数据expanded千万别挂在节点对象上。理由有三一是它属于交互域不该跟着接口数据一起被序列化二是展开状态经常批量变化全部收起按钮挂在节点上要遍历整棵树三是你要做只展开到当前路径这种功能时从节点上清理旧状态很恶心。用一个独立的Set就够了判断展开就是expandedIds.has(node.id)。Vue 3 对Set的响应式支持是完整的has()会被正确追踪只要记得用reactive(new Set())或者整体替换shallowRef的写法别用原始Set直接赋给ref后又原地addref包装的 Set 其实也能追踪但团队里统一写法更省心。2.3 前进后退栈存快照并且后退时要清空前进栈地址栏旁边那两个箭头很多人第一版做出来是坏的。正确做法是两个栈const backStack ref([]) // 存历史 path 数组 const forwardStack ref([]) function navigateTo(path) { if (!isSamePath(path, currentPath.value)) { backStack.value.push([...currentPath.value]) forwardStack.value [] // 关键产生新分支旧的前进历史作废 currentPath.value path } } function goBack() { if (!backStack.value.length) return forwardStack.value.push([...currentPath.value]) currentPath.value backStack.value.pop() } function goForward() { if (!forwardStack.value.length) return backStack.value.push([...currentPath.value]) currentPath.value forwardStack.value.pop() }两个注意点。一是存快照浅拷贝的数组而不是索引因为路径数组随时可能被替换存引用会连带被改。二是forwardStack.value []这行绝不能漏否则用户后退两次再点一个新目录再按前进会跳到一个和当前上下文毫无关系的目录这个 bug 在测试阶段很难被发现上线后用户一用就觉得这软件怪怪的。3. 上万条文件不卡的秘密虚拟滚动加上别乱加深响应一个素材库动辄几万个文件全量渲染必然卡。虚拟滚动不是什么新鲜东西但在这个场景里有几个特殊的坑。3.1 定高行是省下 80% 工作量的前提列表视图下我把每行固定成 36px包括内边距图标视图固定成单元格 96×104。定高之后每一行的几何位置就是纯算术不需要任何 DOM 测量。这一点在后面做框选的时候价值巨大。核心逻辑封装成一个组合式函数import { ref, computed } from vue export function useVirtualRows(itemHeight, buffer 6) { const scrollTop ref(0) const viewportHeight ref(0) const total ref(0) const startIndex computed(() Math.max(0, Math.floor(scrollTop.value / itemHeight) - buffer) ) const endIndex computed(() Math.min(total.value, Math.ceil((scrollTop.value viewportHeight.value) / itemHeight) buffer) ) const offsetY computed(() startIndex.value * itemHeight) const totalHeight computed(() total.value * itemHeight) function onScroll(e) { scrollTop.value e.currentTarget.scrollTop } return { scrollTop, viewportHeight, total, startIndex, endIndex, offsetY, totalHeight, onScroll } }模板结构是三层的div classfs-scroll scroll.passiveonScroll div classfs-phantom :style{ height: totalHeight px }/div div classfs-window :style{ transform: translateY(${offsetY}px) } div v-forrow in visibleRows :keyrow.id classfs-row.../div /div /div外层负责滚动中间那层幽灵只提供总高度撑出滚动条真正的窗口层用 transform 位移。用transform而不是top是因为 transform 不参与布局计算浏览器只需合成滚动时不会引发布局回流。buffer给 6 行是我实测比较舒服的值。太小了快速滚动会露白边太大了每帧多渲染几行一万条数据下差别不明显但几十万条时缓冲行就是纯浪费。另外scroll.passive一定要加不加的话滚动监听会被浏览器当作可能调用preventDefault而阻塞合成线程手机上尤其明显。3.2 图标千万不要用字体图标文件类型图标动辄几十种文件夹、txt、pdf、xlsx、mp4、png……我第一版用了某个字体图标库结果项目里引入两三套图标字体首屏字体文件加起来七八百 KB而且字体加载完成前的方块闪烁在这个以视觉为主的页面里非常刺眼。换成 SVG symbol 雪碧图之后一个文件搞定所有图标use引用还能按扩展名做颜色主题。图标映射就是一个普通对象const EXT_ICON { folder: #i-folder, txt: #i-txt, md: #i-txt, log: #i-txt, xls: #i-excel, xlsx: #i-excel, csv: #i-excel, doc: #i-word, docx: #i-word, png: #i-image, jpg: #i-image, jpeg: #i-image, webp: #i-image, gif: #i-image, mp4: #i-video, mov: #i-video, webm: #i-video, pdf: #i-pdf, zip: #i-zip, rar: #i-zip, 7z: #i-zip } function iconOf(node) { if (node.type folder) return #i-folder return EXT_ICON[node.ext] || #i-file }提示图标组件本身用markRaw()包一下或者干脆不封装成组件、直接写svguse//svg。上万个图标组件实例的创建与销毁开销比你想象的大。3.3 选中态一个 Set 打败一万个布尔值最直觉的方案是给每个节点算一个selected: true/false然后在模板里加:class{ active: row.selected }。数据量一大每次选中变化都要重新生成整个列表的视图模型一秒钟框选扫过上百行等于一秒钟重建上百次数组。正确的做法是把选中集合单独放每个行组件自己判断const selection reactive({ ids: new Set(), anchor: null })行组件里const isActive computed(() selection.ids.has(props.row.id))Vue 3 对Set.has()的依赖追踪是精确到 key 的只有has(id)被调用的那个 id 变化时对应的行才会重新渲染。也就是说框选扫过 100 行实际只有这 100 个行组件更新其余几千行纹丝不动。但是这里有个新手 100% 会踩的坑如果你把selection.ids写成普通的new Set()然后赋给ref每次add之后视图不更新你会以为是 Vue 的 bug。原因是ref(new Set())虽然对 Set 的方法调用做了劫持但如果你在别处直接替换了.value指向的 Set或者在某些边界情况下绕开了代理追踪就断了。我现在的习惯是统一用reactive({ ids: new Set() })然后只调方法不换对象稳定得多。3.4 排序用 Intl.Collator别自己写比较函数Windows 资源管理器的排序有个特点新建文件夹2排在新建文件夹10前面这叫自然排序。用普通的字符串比较10 2会得到反过来的结果。const collator new Intl.Collator(zh-Hans-CN, { numeric: true, sensitivity: base }) const sorters { name: (a, b) collator.compare(a.name, b.name), size: (a, b) a.size - b.size, mtime: (a, b) a.mtime - b.mtime } function sortedList(ids) { const list ids.map(id nodeMap.value.get(id)) const cmp sorters[sortField.value] || sorters.name list.sort((a, b) { // 文件夹永远在前这是资源管理器的默认行为 if (a.type ! b.type) return a.type folder ? -1 : 1 const r cmp(a, b) return sortDir.value asc ? r : -r }) return list }sensitivity: base让大小写和重音不参与比较正好符合 Windows 的文件名不区分大小写这一特性——这一点在后面校验重名时会再次遇到。4. 框选、多选、拖拽交互层最费劲的三块硬骨头到这一段页面已经能看了但离像 Windows还差得远。真正区分能用的 demo和能上线的产品的就是这三块。4.1 框选用算术代替 DOM 测量常规写法是mousemove时遍历所有行元素调getBoundingClientRect()判断是否相交。一万行不可能。就算虚拟滚动只渲染了 20 行每帧 20 次布局查询也足以让框选变得黏糊糊的——因为getBoundingClientRect()会强制浏览器做样式计算和布局连续调用就是经典的布局抖动。既然行高固定几何位置完全可以用算的const ROW_H 36 function onMarqueeMove(e) { const box e.currentTarget.getBoundingClientRect() // 转成内容坐标系含 scrollTop不受虚拟滚动影响 const curY e.clientY - box.top scrollTop.value const curX e.clientX - box.left rect.value { top: Math.min(startY.value, curY), bottom: Math.max(startY.value, curY), left: Math.min(startX.value, curX), right: Math.max(startX.value, curX) } // 只算行区间不碰 DOM const firstRow Math.max(0, Math.floor(rect.value.top / ROW_H)) const lastRow Math.min(visibleRows.value.length - 1, Math.ceil(rect.value.bottom / ROW_H)) const hit new Set() for (let i firstRow; i lastRow; i) { hit.add(visibleRows.value[i].id) } selection.ids hit // 整体替换一次更新 }整个mousemove里没有一次 DOM 查询除了起始时拿一次容器的 rect那个可以缓存。实测框选扫过整屏帧率依然稳在 60。有一个细节必须处理鼠标拖出容器外时要继续响应并且向上拖出时要自动滚动。做法是把mousemove和mouseup绑到window上在mousedown时挂载、mouseup时卸载。自动滚动则用一个requestAnimationFrame循环当clientY超出容器上下边界时按超出距离的比例调整scrollTop超出越多滚得越快——这个越界越多滚得越快的手感是 Windows 用户肌肉记忆的一部分少了会觉得怪。4.2 Ctrl 和 Shift 的选择语义三种模式要记清楚操作行为实现要点直接单击清空原有选中只选当前项同时把 anchor 设为该项Ctrl 单击已选中则取消未选中则加入anchor 也更新为该项Shift 单击从 anchor 到当前项的全部选中替换原有选中anchor 不变Ctrl Shift 单击在原有选中基础上增补区间追加而不替换最容易写错的是 Shift 的锚点。很多人写成上一次点击的项结果连续 Shift 点击时区间会黏在一起。正确逻辑是只有非 Shift 的点击才更新 anchorShift 点击永远以当前 anchor 为起点。function handleClick(node, e) { const list visibleRows.value const idx list.findIndex(n n.id node.id) if (e.shiftKey selection.anchor ! null) { const from list.findIndex(n n.id selection.anchor) const [s, t] from idx ? [from, idx] : [idx, from] const range new Set(list.slice(s, t 1).map(n n.id)) selection.ids e.ctrlKey ? new Set([...selection.ids, ...range]) : range } else if (e.ctrlKey) { const next new Set(selection.ids) next.has(node.id) ? next.delete(node.id) : next.add(node.id) selection.ids next selection.anchor node.id } else { selection.ids new Set([node.id]) selection.anchor node.id } }注意selection.anchor存的是id 而不是索引。因为列表随时可能因为排序或筛选而重排存索引会在重排后指向另一个文件。4.3 拖拽内拖和外拖必须分开处理从桌面往浏览器里拖文件外拖和页面内部拖内拖是两套逻辑套在一起必出问题。外拖靠dataTransfer.files判断内拖我建议完全不走 HTML5 的 dataTransfer用自己维护的一个dragState更可控。原因很实在HTML5 拖拽在dragstart里如果同步修改了 DOM 结构比如给被拖元素加一个半透明的克隆类某些浏览器会直接取消这次拖拽。而且dataTransfer在dragover阶段读取数据是受限的判断能不能放下时拿不到数据很别扭。自己的状态长这样const dragState reactive({ active: false, sourceIds: new Set(), overFolderId: null, copyMode: false })放置目标的判定规则直接对齐 Windows放置目标是否按 Ctrl结果某个文件夹否移动进该文件夹某个文件夹是复制进该文件夹文件上 / 空白处否移动到当前目录文件上 / 空白处是复制到当前目录自身或自身的子孙任意拒绝显示禁止光标4.4 移动之前先做环检测否则树会自锁这是我在真实项目里被坑得最惨的一次。用户把一个叫「A」的文件夹拖进它自己的子文件夹「A/B/C」里如果不做检测childrenIndex里就会出现一个循环A 的 children 包含 BB 的 children 里又包含 A。结果是点击展开时组件无限递归页面直接卡死。检测逻辑就是顺着parentId往上爬function isDescendant(folderId, maybeDescendantId) { let cur nodeMap.value.get(maybeDescendantId) while (cur cur.parentId) { if (cur.parentId folderId) return true cur nodeMap.value.get(cur.parentId) } return false } function canDrop(ids, targetFolderId) { for (const id of ids) { if (id targetFolderId) return false const node nodeMap.value.get(id) if (node?.type folder isDescendant(id, targetFolderId)) return false } return true }爬链的时候记得加一个最大深度保护比如 32 层防止历史脏数据里已经存在环导致死循环。这个防御看起来多余真遇到一次就知道值了。真正的移动操作要保证原子性——要么全成功要么全不动function moveNodes(ids, targetFolderId) { const nextNodes new Map(nodeMap.value) const nextIndex new Map([...childrenIndex.value].map(([k, v]) [k, [...v]])) for (const id of ids) { const node nextNodes.get(id) if (!node) continue const from nextIndex.get(node.parentId) || [] nextIndex.set(node.parentId, from.filter(x x ! id)) const to nextIndex.get(targetFolderId) || [] to.push(id) nextIndex.set(targetFolderId, to) nextNodes.set(id, { ...node, parentId: targetFolderId }) } nodeMap.value nextNodes childrenIndex.value nextIndex }先在副本上完成全部改动最后一次性替换两个 ref。好处是渲染层只会看到改完的最终态不会看到中间过程的半成品比如一个文件短暂地同时出现在两个目录里也天然支持撤销——把移动前的两个 Map 快照压进 undo 栈即可。5. 右键菜单、重命名、新建与删除的边界处理菜单和文件操作看起来是最简单的部分实际上最容易出线上事故。因为这些都是写操作写错了用户的数据就乱了。5.1 右键菜单的定位与边界翻转菜单用Teleport tobody挂到 body 上避免被列表容器的overflow: hidden裁掉。定位用position: fixed加坐标同时必须做视口边界处理function placeMenu(x, y) { const MW 184, MH menuItems.length * 32 12 const left x MW window.innerWidth ? x - MW : x const top y MH window.innerHeight ? y - MH : y menuStyle.value { left: ${left}px, top: ${top}px } }翻转而不是夹住clamp是因为菜单贴着鼠标出现更符合直觉。如果强行 clamp 到边界内菜单会和鼠标拉开一段距离用户得重新找一下自己在点哪儿。菜单关闭的触发源有四个少一个都会显得粘手点击菜单外的任意位置、按下 Esc、滚动列表、再次右键另一个目标应该先关旧的再开新的。function closeOnAny(e) { if (!menuRef.value?.contains(e.target)) menuOpen.value false } onMounted(() { window.addEventListener(mousedown, closeOnAny, true) // 捕获阶段先于业务逻辑 window.addEventListener(keydown, onEsc) })用捕获阶段监听mousedown能保证菜单先关闭、再处理点击目标避免点菜单里的删除结果点到了底下的文件这种穿透问题。5.2 重命名用单个 editingId不要每个节点挂布点const editingId ref(null) const editingDraft ref()只允许一个节点处于重命名状态所以用单值就够了。挂在节点上node.editing true会导致两个问题一是要手动保证开启新的重命名时关掉旧的二是这个状态会跟着数据一起被序列化发到后端。进入编辑态后要做的三件小事输入框自动聚焦、选中不含扩展名的部分Windows 的贴心行为、按 Esc 取消。选中不含扩展名的部分是这样实现的function focusInput(el, node) { el.focus() const dot node.type file ? node.name.lastIndexOf(.) : -1 if (dot 0) el.setSelectionRange(0, dot) else el.select() }5.3 文件名校验规则比你想的多这一块必须写全不然用户能造出各种奇怪的名字后面接后端时才炸。Windows 的规则我整理成表格规则示例说明不能为空或全空格 前后空格会自动去掉不含 9 个非法字符\ / : * ? |正则一条搞定不占用保留名CON、PRN、AUX、NUL、COM1~COM9、LPT1~LPT9带扩展名也算CON.txt同样非法不能以点或空格结尾abc.、abc系统会自动去掉所以要提前拦长度不超过 255—按字符数而非字节数同目录不重名—不区分大小写最后一条特别容易漏。Report.xlsx和report.xlsx在 Windows 里是同一个文件很多前端校验用比较导致能建出两个看起来不一样的文件同步到后端后再冲突。校验函数const ILLEGAL /[\\/:*?|]/ const RESERVED /^(con|prn|aux|nul|com[1-9]|lpt[1-9])(\.|$)/i function validateName(name, siblings, selfId) { if (!name || !name.trim()) return 名称不能为空 if (ILLEGAL.test(name)) return 名称不能包含 \\ / : * ? | if (RESERVED.test(name)) return 这是系统保留名称 if (/[. ]$/.test(name)) return 名称不能以空格或句点结尾 if ([...name].length 255) return 名称过长 const lower name.toLowerCase() const dup siblings.some(s s.id ! selfId s.name.toLowerCase() lower) if (dup) return 当前目录下已有同名项 return null }5.4 删除做成软删除回收站才有戏如果产品提到回收站三个字那删除必须是软删除给节点打一个deletedAt时间戳从childrenIndex里摘掉但不从nodeMap里删。回收站就是全表扫一遍deletedAt ! null的节点。还原的时候要处理一个边界原目录可能已经被删了。我的处理是还原时检查parentId对应的节点是否还存在且未被删不存在就退回根目录同时给用户一条提示原位置不存在已还原到根目录。永久删除才是真删而且删文件夹时要连子孙一起清理function purge(id) { const node nodeMap.value.get(id) if (!node) return if (node.type folder) { for (const childId of childrenIndex.value.get(id) || []) purge(childId) } nodeMap.value.delete(id) childrenIndex.value.delete(id) const parent childrenIndex.value.get(node.parentId) || [] childrenIndex.value.set(node.parentId, parent.filter(x x ! id)) }6. 键盘操作把像 Windows这件事做到手感层面功能都通了之后决定用户是否愿意长期使用的是键盘。资源管理器的老用户几乎不用鼠标完成重命名、删除、返回上级这些操作。6.1 方向键导航要先知道列数↑↓ 是上下移动一行在列表视图里就是index ± 1在图标视图里是index ± columns。所以列数是必须的const columns ref(1) function recalcColumns() { const w gridRef.value?.clientWidth || 0 const CELL_W 96 columns.value Math.max(1, Math.floor(w / CELL_W)) }这里有个很隐蔽的坑容器如果有纵向滚动条clientWidth会把它减掉但你在计算时如果用offsetWidth就会得到偏大的值导致算出的列数比实际多一列↑↓ 跳转就错位。统一用clientWidth或getBoundingClientRect().width减掉滚动条宽度。还有一个更隐蔽的列数变化时当前选中项的位置会变用户的肌肉记忆突然失效。我的处理是列数变化时不重新计算选中项只是让它保持选中状态滚动跟随一下即可不做额外跳转。6.2 一套完整的按键映射按键行为备注↑ / ↓上/下一行图标视图按列数位移← / →图标视图左右移一格列表视图下用于收起/展开当前文件夹Home / End跳到首/末项配合 Ctrl 也是一样Enter打开选中项文件夹则进入文件则预览F2重命名选中项单选时可用Delete移入回收站支持多选Backspace返回上一级非常 Windows 的细节Ctrl A全选当前目录—Ctrl C / X / V复制 / 剪切 / 粘贴需要维护剪贴板状态Esc关闭菜单 / 取消编辑 / 清空选中优先级从上到下字母键按名称跳转定位输入累积 500ms 内算一次Esc 的多级语义最容易乱。我的处理是维护一个当前最上层可取消的东西的判断顺序先看有没有打开菜单再看有没有在编辑最后才是清空选中。这样用户不需要思考连按 Esc 就能一层层退出来。6.3 键盘事件绑在容器上不要绑在 window绑在window上最省事但会带来一堆麻烦输入框里打字时按 Delete 会把文件删了按 Backspace 会返回上级。页面里只要有一个搜索框就会出问题。正确做法是给列表容器加tabindex-1把keydown绑在容器上然后在进入页面时或点击空白处时focus()它。同时给一个可见的聚焦样式细边框或高亮让用户知道键盘操作生效了。当重命名输入框获得焦点时因为事件冒泡的关系还是要判断一下但比全局监听干净得多function onKeydown(e) { if (editingId.value) return // 编辑态交给输入框自己处理 const tag e.target.tagName if (tag INPUT || tag TEXTAREA) return // ... 分发按键 }6.4 滚动跟随别直接用 scrollIntoViewscrollIntoView会把元素滚到视口中间或者最小可见位置但它是相对于最近的可滚动祖先的在虚拟滚动里目标元素可能压根还没渲染出来调用无效。我的做法是根据索引手动算function ensureVisible(index) { const top index * ROW_H const bottom top ROW_H const viewTop scrollTop.value const viewBottom viewTop viewportHeight.value if (top viewTop) scrollTop.value top else if (bottom viewBottom) scrollTop.value bottom - viewportHeight.value scrollEl.value.scrollTop scrollTop.value }手动算的另一个好处是可以留出一点边距让选中项不要紧贴容器边缘视觉上更舒服。7. 真的要去读本地磁盘先认清浏览器的边界这一节说点务实的。很多人做这个功能时的第一反应是让它像 Windows 一样能浏览我的电脑但必须明确浏览器出于安全原因不能随意读取本地文件系统。有几条可行的路线适用场景完全不同。7.1 后端目录接口最常用的路线真实的企业素材库、网盘、项目管理系统99% 都是后端提供目录列表接口前端只做展示。接口返回的应该是已经排好序、带好层级关系的扁平结构{ parentId: dir_1024, path: [此电脑, 素材库, 2024], items: [ { id: d_1, name: 字体, type: folder, size: 0, mtime: 1710000000000 }, { id: f_9, name: 封面.png, type: file, size: 248233, mtime: 1710000500000 } ] }前端拿到后直接灌进nodeMap和childrenIndex。这里有个性能上的建议一次请求一层不要一次拉全树。用户点开哪个目录再拉哪个目录把已拉取的节点缓存起来返回上一级时直接用缓存渲染同时静默刷新一次保证数据新鲜。7.2 File System Access API能读能写但限制明确window.showDirectoryPicker()可以拿到用户授权后的目录句柄然后递归读取甚至在用户授权下写回文件。这是最接近真资源管理器的方案。但要注意几点必须由用户手势触发点击事件里直接调用不能放在await之后只能在安全上下文HTTPS 或 localhost下使用不同浏览器的支持程度差别不小必须准备降级方案。递归读取大目录时要控制并发我一般用简单的并发池一次最多 8 个目录同时在读多了反而慢。async function walk(handle, id, depth 0) { if (depth 12) return for await (const entry of handle.values()) { const childId ${id}/${entry.name} addNode({ id: childId, name: entry.name, type: entry.kind directory ? folder : file, parentId: id }) if (entry.kind directory) await walk(entry, childId, depth 1) } }for await...of配合handle.values()是异步迭代器天然是流式的不会一次性把所有 entry 拿回来内存友好。但它是串行的大目录下会慢我上面提到用并发池就是为了解决这个先把当前层的 entry 全部await到数组再对子目录分批并发。7.3 webkitdirectory只读快照适合导入场景input typefile webkitdirectory能一次性拿到整个目录下所有文件每个File对象上都带webkitRelativePath格式是顶层目录/子目录/文件名。按/切开就能重建出目录树。这条路线的定位很明确一次性的导入。没有后续的写回能力也不会有目录变化的通知。做批量上传素材这个场景非常合适做文件管理器就不合适。7.4 纯前端 Mock开发期最省事的方案后端接口没就绪的时候我一般写一个 Mock 生成器按扩展名池随机造几千个节点const EXTS [png, jpg, pdf, xlsx, docx, mp4, zip, txt, md] const NAMES [封面, 合同, 预算表, 会议记录, 需求文档, 原型图, 宣传片] function mockTree(rootId, folderCount, fileCount) { for (let i 0; i folderCount; i) { const id uid() addNode({ id, name: 目录-${i 1}, type: folder, parentId: rootId, mtime: Date.now() - i * 86400000 }) } for (let i 0; i fileCount; i) { const ext EXTS[i % EXTS.length] const id uid() addNode({ id, name: ${NAMES[i % NAMES.length]}-${i 1}.${ext}, type: file, ext, parentId: rootId, size: Math.floor(Math.random() * 5e7), mtime: Date.now() - Math.floor(Math.random() * 3e10) }) } }Mock 生成器有个额外好处它能帮你验证性能边界。我会专门造一个 5 万文件的目录跑一遍看虚拟滚动、框选、排序在极端数据下的表现。这个测试在开发期做比上线后被用户拿真实数据打脸便宜太多。8. 几个我真实踩过的坑以及最后的收尾前面把体系讲完了这一节只讲那些文档里不会写、只有真做过才知道的细节。8.1 用 index 当 key排序后选中全乱v-for里图省事写:keyindex列表看起来没问题一排序就发现选中的是别的文件、重命名框跑到了另一个元素上。原因很直白Vue 复用 DOM 节点时是按 key 匹配的key 用 index 相当于告诉 Vue 第 3 个位置还是同一个东西排序后位置内容变了复用的组件实例却还是旧的内部状态全错位。永远用节点 id 当 key这是硬规矩。8.2 深度侦听整棵树一导入真实数据就卡watch(tree, fn, { deep: true })这个写法在小数据量下毫无问题是它最大的迷惑性。等树有几千个节点任何一次鼠标移动引起的选中态变化都可能触发侦听器重新遍历整棵树。替代方案是按需侦听具体字段或者干脆用事件驱动——所有写操作都走统一的commit()方法在方法里主动触发需要的计算而不是被动侦听。8.3 computed 里调 getBoundingClientRect滚动时抖成筛子我在一个版本里把可见行数写成computed(() Math.ceil(el.getBoundingClientRect().height / ROW_H))结果每次滚动都触发布局查询滚动条一拖就掉帧。任何测量 DOM 的操作都应该放在 resize 监听或者onMounted里算出来存进 ref不要在 computed 里现算。这个原则在列表滚动的场景下尤其重要。8.4 滚动条宽度导致的列数偏差这个坑前面提过值得再强调一次。在 Windows 上滚动条会占 15~17px在 macOS 上默认是浮层不占宽度。同一份clientWidth计算代码在两个系统上得出的列数不同macOS 上多一列导致图标视图最后一行只放一个元素。用 CSS 的scrollbar-gutter: stable或者干脆手动预留一个固定宽度能让两端表现一致。8.5 拖拽取消时状态没清理dragState.active如果在dragend里没清干净下一次鼠标划过去会莫名其妙出现放置高亮。而且dragend在拖拽被浏览器中断时也会触发比drop更可靠。我现在的习惯是dragend、drop、Esc三个地方都做一次状态重置宁可多做也不漏——重置是幂等的多做没有副作用。8.6 一个关于剪贴板的小设计CtrlC 之后如果只是存了 id 列表用户在别的地方把那个文件重命名或者删掉了再粘贴就会出现复制了一个不存在的文件。我的处理是复制时存 id 列表粘贴时逐个校验节点是否还存在、是否还是原来的 parentId如果原节点已不在直接跳过并在提示条里说明有 2 个文件已失效未执行粘贴。这个小提示看起来多余但用户遇到一次就会觉得这软件靠谱。如果你想在这个基础上继续往上做我建议的方向是详情面板 预览右侧加一个可折叠的侧栏单选时展示缩略图、尺寸、修改时间、标签双击文件时用object或img直接预览图片、PDF、纯文本都好办视频用video加URL.createObjectURL就能播。再往下就是标签体系和搜索搜索这块只要在nodeMap上做一次带防抖的全表扫描就够了几千个节点扫一遍也就几毫秒没必要上索引——先跑起来等真的到十万级再谈优化。
Vue 3 仿 Windows 文件管理器：状态、虚拟滚动与拖拽落地
做后台管理系统的人大概都有过这个瞬间产品经理甩过来一张 Windows 资源管理器的截图说就照这个做我们的素材库/网盘/项目文件管理页要一模一样。于是你打开 Vue左边写一棵树右边写一个列表双击进去点面包屑返回看起来挺顺。然后需求开始加码——要能框选、要按住 Ctrl 挑几个、要拖到文件夹里、右键要出新文件夹、重命名要能校验、文件上万条不能卡。这时候你会发现真正难的不是画界面而是状态怎么放、几何怎么算、事件怎么收口。这篇就围绕VUE 仿 windows 文件夹文件这件事把我在几个素材管理系统里踩过的坑和落地方案摊开讲代码用 Vue 3 组合式 API 写逻辑框架换成 Vue 2 或 React 也一样成立。1. 动手之前先分清楚三种状态混在一起必翻车我见过太多这个功能的实现一开始就是一棵深层嵌套的响应式大树节点上挂着selected、expanded、editing、loading再来一个watch(tree, handler, { deep: true })。前两百个节点跑得好好的导入真实数据后直接白屏——不是因为渲染慢是因为深度侦听一个几千节点的对象树光建立依赖就够呛。1.1 数据域、视图域、交互域必须切开我的划分方式是这样状态域存什么生命周期存放位置数据域节点本体id、name、type、parentId、size、mtime跟随接口数据需要持久化Pinia 的useFsStore视图域当前路径、视图模式图标/列表、排序字段与方向、滚动位置刷新即重置可以存 URL query组件内 ref 或独立 store交互域选中集合、框选矩形、拖拽中的源、剪贴板、重命名编辑 id高频变化一秒可能变几十次shallowRef/reactive(new Set())为什么要切开因为三者的更新频率差了不止一个数量级。数据域一天变几次视图域一次点击变一次交互域鼠标一动就变。把它们塞进同一个响应式对象等于让鼠标划过一个框去触发整棵树重新收集依赖。提示判断某个状态该放哪一域就问一句这个状态刷新页面后还应不应该存在。应该存在的是数据域不该存在的是视图域一秒钟变好几次的是交互域。1.2 路径用数组存不要用字符串D:\\项目\\src\\components这种字符串路径看着直观用起来处处是坑反斜杠在 JS 字符串里要转义、Windows 和类 Unix 分隔符不一致、中文路径遇到大小写比较要额外处理。我改成数组[此电脑, D盘, 项目, src]。好处立刻体现出来面包屑直接v-for渲染上一级就是path.slice(0, -1)判断两个节点是否是同一目录直接pathA.join(/) pathB.join(/)不需要处理任何转义往 URL 里塞的时候join(|)取出来split(|)比编码整个路径字符串干净得多。1.3 嵌套树和扁平表选错一个后面全是补丁这是我认为最关键的一次架构选择。先把两者摊开对比对比维度嵌套树children 数组扁平 Map childrenIds按 id 找节点递归 O(深度)O(1) 直接查表移动一个节点递归找父节点再 splice改两个数组几行代码深层响应式开销高层级越深越明显低Map 是浅层的渲染树组件天然递归直接吃 children需要按需组装一层视图数据移动端 / 大数据量容易炸稳结论很明确存储用扁平渲染时组装。真正的数据结构长这样// 节点本体全部塞进一个 Map // { id, name, type: folder | file, parentId, size, mtime, ext, deletedAt } const nodeMap shallowRef(new Map()) // 父子关系单独索引避免每次都要全表扫 const childrenIndex shallowRef(new Map()) // parentId - id[]拿某个目录下的文件列表就是function listChildren(folderId) { const ids childrenIndex.value.get(folderId) || [] return ids.map(id nodeMap.value.get(id)).filter(Boolean) }这里有两个细节值得说。第一nodeMap用shallowRef意味着我改节点内部字段时要整体替换引用看起来麻烦一点但换来的是 Vue 不会给 Map 里每个节点套 Proxy——上万个节点时这个差别非常明显。第二childrenIndex的数组顺序就是渲染顺序的原始依据排序时只重排这个数组不动节点本体撤销排序也不会有副作用。2. 左侧目录树和右侧文件列表怎么保证永远说的是同一个地方左右联动是这类页面的第一道坎。用户点树上的节点右边要跳用户在右边双击文件夹进去树要展开并高亮用户点面包屑往回走两边都要跟着变。新手最容易犯的错是在每个交互回调里各写一遍同步三件事写着写着就有六七处重复逻辑改一处漏三处。2.1 只保留一个真相currentPath我的做法是所有操作只负责修改currentPath然后由一个watch集中处理副作用。const currentPath ref([此电脑]) watch(currentPath, (path) { // 1. 展开树上对应的所有祖先节点 expandedIds.value new Set([...expandedIds.value, ...getAncestorIds(path)]) // 2. 高亮当前节点由树组件自己根据 currentPath 最后一项判断 // 3. 清空选中与框选 selection.clear() // 4. 重置滚动位置 listScrollTop.value 0 // 5. 写回 URL支持刷新还原 router.replace({ query: { p: path.join(|) } }) }, { flush: post })flush: post这个参数容易被忽略。默认的pre会在组件更新前触发侦听如果回调里依赖了 DOM 尺寸比如重新计算列数拿到的还是旧的。放到post里最稳妥。2.2 树的展开状态别写进节点数据expanded千万别挂在节点对象上。理由有三一是它属于交互域不该跟着接口数据一起被序列化二是展开状态经常批量变化全部收起按钮挂在节点上要遍历整棵树三是你要做只展开到当前路径这种功能时从节点上清理旧状态很恶心。用一个独立的Set就够了判断展开就是expandedIds.has(node.id)。Vue 3 对Set的响应式支持是完整的has()会被正确追踪只要记得用reactive(new Set())或者整体替换shallowRef的写法别用原始Set直接赋给ref后又原地addref包装的 Set 其实也能追踪但团队里统一写法更省心。2.3 前进后退栈存快照并且后退时要清空前进栈地址栏旁边那两个箭头很多人第一版做出来是坏的。正确做法是两个栈const backStack ref([]) // 存历史 path 数组 const forwardStack ref([]) function navigateTo(path) { if (!isSamePath(path, currentPath.value)) { backStack.value.push([...currentPath.value]) forwardStack.value [] // 关键产生新分支旧的前进历史作废 currentPath.value path } } function goBack() { if (!backStack.value.length) return forwardStack.value.push([...currentPath.value]) currentPath.value backStack.value.pop() } function goForward() { if (!forwardStack.value.length) return backStack.value.push([...currentPath.value]) currentPath.value forwardStack.value.pop() }两个注意点。一是存快照浅拷贝的数组而不是索引因为路径数组随时可能被替换存引用会连带被改。二是forwardStack.value []这行绝不能漏否则用户后退两次再点一个新目录再按前进会跳到一个和当前上下文毫无关系的目录这个 bug 在测试阶段很难被发现上线后用户一用就觉得这软件怪怪的。3. 上万条文件不卡的秘密虚拟滚动加上别乱加深响应一个素材库动辄几万个文件全量渲染必然卡。虚拟滚动不是什么新鲜东西但在这个场景里有几个特殊的坑。3.1 定高行是省下 80% 工作量的前提列表视图下我把每行固定成 36px包括内边距图标视图固定成单元格 96×104。定高之后每一行的几何位置就是纯算术不需要任何 DOM 测量。这一点在后面做框选的时候价值巨大。核心逻辑封装成一个组合式函数import { ref, computed } from vue export function useVirtualRows(itemHeight, buffer 6) { const scrollTop ref(0) const viewportHeight ref(0) const total ref(0) const startIndex computed(() Math.max(0, Math.floor(scrollTop.value / itemHeight) - buffer) ) const endIndex computed(() Math.min(total.value, Math.ceil((scrollTop.value viewportHeight.value) / itemHeight) buffer) ) const offsetY computed(() startIndex.value * itemHeight) const totalHeight computed(() total.value * itemHeight) function onScroll(e) { scrollTop.value e.currentTarget.scrollTop } return { scrollTop, viewportHeight, total, startIndex, endIndex, offsetY, totalHeight, onScroll } }模板结构是三层的div classfs-scroll scroll.passiveonScroll div classfs-phantom :style{ height: totalHeight px }/div div classfs-window :style{ transform: translateY(${offsetY}px) } div v-forrow in visibleRows :keyrow.id classfs-row.../div /div /div外层负责滚动中间那层幽灵只提供总高度撑出滚动条真正的窗口层用 transform 位移。用transform而不是top是因为 transform 不参与布局计算浏览器只需合成滚动时不会引发布局回流。buffer给 6 行是我实测比较舒服的值。太小了快速滚动会露白边太大了每帧多渲染几行一万条数据下差别不明显但几十万条时缓冲行就是纯浪费。另外scroll.passive一定要加不加的话滚动监听会被浏览器当作可能调用preventDefault而阻塞合成线程手机上尤其明显。3.2 图标千万不要用字体图标文件类型图标动辄几十种文件夹、txt、pdf、xlsx、mp4、png……我第一版用了某个字体图标库结果项目里引入两三套图标字体首屏字体文件加起来七八百 KB而且字体加载完成前的方块闪烁在这个以视觉为主的页面里非常刺眼。换成 SVG symbol 雪碧图之后一个文件搞定所有图标use引用还能按扩展名做颜色主题。图标映射就是一个普通对象const EXT_ICON { folder: #i-folder, txt: #i-txt, md: #i-txt, log: #i-txt, xls: #i-excel, xlsx: #i-excel, csv: #i-excel, doc: #i-word, docx: #i-word, png: #i-image, jpg: #i-image, jpeg: #i-image, webp: #i-image, gif: #i-image, mp4: #i-video, mov: #i-video, webm: #i-video, pdf: #i-pdf, zip: #i-zip, rar: #i-zip, 7z: #i-zip } function iconOf(node) { if (node.type folder) return #i-folder return EXT_ICON[node.ext] || #i-file }提示图标组件本身用markRaw()包一下或者干脆不封装成组件、直接写svguse//svg。上万个图标组件实例的创建与销毁开销比你想象的大。3.3 选中态一个 Set 打败一万个布尔值最直觉的方案是给每个节点算一个selected: true/false然后在模板里加:class{ active: row.selected }。数据量一大每次选中变化都要重新生成整个列表的视图模型一秒钟框选扫过上百行等于一秒钟重建上百次数组。正确的做法是把选中集合单独放每个行组件自己判断const selection reactive({ ids: new Set(), anchor: null })行组件里const isActive computed(() selection.ids.has(props.row.id))Vue 3 对Set.has()的依赖追踪是精确到 key 的只有has(id)被调用的那个 id 变化时对应的行才会重新渲染。也就是说框选扫过 100 行实际只有这 100 个行组件更新其余几千行纹丝不动。但是这里有个新手 100% 会踩的坑如果你把selection.ids写成普通的new Set()然后赋给ref每次add之后视图不更新你会以为是 Vue 的 bug。原因是ref(new Set())虽然对 Set 的方法调用做了劫持但如果你在别处直接替换了.value指向的 Set或者在某些边界情况下绕开了代理追踪就断了。我现在的习惯是统一用reactive({ ids: new Set() })然后只调方法不换对象稳定得多。3.4 排序用 Intl.Collator别自己写比较函数Windows 资源管理器的排序有个特点新建文件夹2排在新建文件夹10前面这叫自然排序。用普通的字符串比较10 2会得到反过来的结果。const collator new Intl.Collator(zh-Hans-CN, { numeric: true, sensitivity: base }) const sorters { name: (a, b) collator.compare(a.name, b.name), size: (a, b) a.size - b.size, mtime: (a, b) a.mtime - b.mtime } function sortedList(ids) { const list ids.map(id nodeMap.value.get(id)) const cmp sorters[sortField.value] || sorters.name list.sort((a, b) { // 文件夹永远在前这是资源管理器的默认行为 if (a.type ! b.type) return a.type folder ? -1 : 1 const r cmp(a, b) return sortDir.value asc ? r : -r }) return list }sensitivity: base让大小写和重音不参与比较正好符合 Windows 的文件名不区分大小写这一特性——这一点在后面校验重名时会再次遇到。4. 框选、多选、拖拽交互层最费劲的三块硬骨头到这一段页面已经能看了但离像 Windows还差得远。真正区分能用的 demo和能上线的产品的就是这三块。4.1 框选用算术代替 DOM 测量常规写法是mousemove时遍历所有行元素调getBoundingClientRect()判断是否相交。一万行不可能。就算虚拟滚动只渲染了 20 行每帧 20 次布局查询也足以让框选变得黏糊糊的——因为getBoundingClientRect()会强制浏览器做样式计算和布局连续调用就是经典的布局抖动。既然行高固定几何位置完全可以用算的const ROW_H 36 function onMarqueeMove(e) { const box e.currentTarget.getBoundingClientRect() // 转成内容坐标系含 scrollTop不受虚拟滚动影响 const curY e.clientY - box.top scrollTop.value const curX e.clientX - box.left rect.value { top: Math.min(startY.value, curY), bottom: Math.max(startY.value, curY), left: Math.min(startX.value, curX), right: Math.max(startX.value, curX) } // 只算行区间不碰 DOM const firstRow Math.max(0, Math.floor(rect.value.top / ROW_H)) const lastRow Math.min(visibleRows.value.length - 1, Math.ceil(rect.value.bottom / ROW_H)) const hit new Set() for (let i firstRow; i lastRow; i) { hit.add(visibleRows.value[i].id) } selection.ids hit // 整体替换一次更新 }整个mousemove里没有一次 DOM 查询除了起始时拿一次容器的 rect那个可以缓存。实测框选扫过整屏帧率依然稳在 60。有一个细节必须处理鼠标拖出容器外时要继续响应并且向上拖出时要自动滚动。做法是把mousemove和mouseup绑到window上在mousedown时挂载、mouseup时卸载。自动滚动则用一个requestAnimationFrame循环当clientY超出容器上下边界时按超出距离的比例调整scrollTop超出越多滚得越快——这个越界越多滚得越快的手感是 Windows 用户肌肉记忆的一部分少了会觉得怪。4.2 Ctrl 和 Shift 的选择语义三种模式要记清楚操作行为实现要点直接单击清空原有选中只选当前项同时把 anchor 设为该项Ctrl 单击已选中则取消未选中则加入anchor 也更新为该项Shift 单击从 anchor 到当前项的全部选中替换原有选中anchor 不变Ctrl Shift 单击在原有选中基础上增补区间追加而不替换最容易写错的是 Shift 的锚点。很多人写成上一次点击的项结果连续 Shift 点击时区间会黏在一起。正确逻辑是只有非 Shift 的点击才更新 anchorShift 点击永远以当前 anchor 为起点。function handleClick(node, e) { const list visibleRows.value const idx list.findIndex(n n.id node.id) if (e.shiftKey selection.anchor ! null) { const from list.findIndex(n n.id selection.anchor) const [s, t] from idx ? [from, idx] : [idx, from] const range new Set(list.slice(s, t 1).map(n n.id)) selection.ids e.ctrlKey ? new Set([...selection.ids, ...range]) : range } else if (e.ctrlKey) { const next new Set(selection.ids) next.has(node.id) ? next.delete(node.id) : next.add(node.id) selection.ids next selection.anchor node.id } else { selection.ids new Set([node.id]) selection.anchor node.id } }注意selection.anchor存的是id 而不是索引。因为列表随时可能因为排序或筛选而重排存索引会在重排后指向另一个文件。4.3 拖拽内拖和外拖必须分开处理从桌面往浏览器里拖文件外拖和页面内部拖内拖是两套逻辑套在一起必出问题。外拖靠dataTransfer.files判断内拖我建议完全不走 HTML5 的 dataTransfer用自己维护的一个dragState更可控。原因很实在HTML5 拖拽在dragstart里如果同步修改了 DOM 结构比如给被拖元素加一个半透明的克隆类某些浏览器会直接取消这次拖拽。而且dataTransfer在dragover阶段读取数据是受限的判断能不能放下时拿不到数据很别扭。自己的状态长这样const dragState reactive({ active: false, sourceIds: new Set(), overFolderId: null, copyMode: false })放置目标的判定规则直接对齐 Windows放置目标是否按 Ctrl结果某个文件夹否移动进该文件夹某个文件夹是复制进该文件夹文件上 / 空白处否移动到当前目录文件上 / 空白处是复制到当前目录自身或自身的子孙任意拒绝显示禁止光标4.4 移动之前先做环检测否则树会自锁这是我在真实项目里被坑得最惨的一次。用户把一个叫「A」的文件夹拖进它自己的子文件夹「A/B/C」里如果不做检测childrenIndex里就会出现一个循环A 的 children 包含 BB 的 children 里又包含 A。结果是点击展开时组件无限递归页面直接卡死。检测逻辑就是顺着parentId往上爬function isDescendant(folderId, maybeDescendantId) { let cur nodeMap.value.get(maybeDescendantId) while (cur cur.parentId) { if (cur.parentId folderId) return true cur nodeMap.value.get(cur.parentId) } return false } function canDrop(ids, targetFolderId) { for (const id of ids) { if (id targetFolderId) return false const node nodeMap.value.get(id) if (node?.type folder isDescendant(id, targetFolderId)) return false } return true }爬链的时候记得加一个最大深度保护比如 32 层防止历史脏数据里已经存在环导致死循环。这个防御看起来多余真遇到一次就知道值了。真正的移动操作要保证原子性——要么全成功要么全不动function moveNodes(ids, targetFolderId) { const nextNodes new Map(nodeMap.value) const nextIndex new Map([...childrenIndex.value].map(([k, v]) [k, [...v]])) for (const id of ids) { const node nextNodes.get(id) if (!node) continue const from nextIndex.get(node.parentId) || [] nextIndex.set(node.parentId, from.filter(x x ! id)) const to nextIndex.get(targetFolderId) || [] to.push(id) nextIndex.set(targetFolderId, to) nextNodes.set(id, { ...node, parentId: targetFolderId }) } nodeMap.value nextNodes childrenIndex.value nextIndex }先在副本上完成全部改动最后一次性替换两个 ref。好处是渲染层只会看到改完的最终态不会看到中间过程的半成品比如一个文件短暂地同时出现在两个目录里也天然支持撤销——把移动前的两个 Map 快照压进 undo 栈即可。5. 右键菜单、重命名、新建与删除的边界处理菜单和文件操作看起来是最简单的部分实际上最容易出线上事故。因为这些都是写操作写错了用户的数据就乱了。5.1 右键菜单的定位与边界翻转菜单用Teleport tobody挂到 body 上避免被列表容器的overflow: hidden裁掉。定位用position: fixed加坐标同时必须做视口边界处理function placeMenu(x, y) { const MW 184, MH menuItems.length * 32 12 const left x MW window.innerWidth ? x - MW : x const top y MH window.innerHeight ? y - MH : y menuStyle.value { left: ${left}px, top: ${top}px } }翻转而不是夹住clamp是因为菜单贴着鼠标出现更符合直觉。如果强行 clamp 到边界内菜单会和鼠标拉开一段距离用户得重新找一下自己在点哪儿。菜单关闭的触发源有四个少一个都会显得粘手点击菜单外的任意位置、按下 Esc、滚动列表、再次右键另一个目标应该先关旧的再开新的。function closeOnAny(e) { if (!menuRef.value?.contains(e.target)) menuOpen.value false } onMounted(() { window.addEventListener(mousedown, closeOnAny, true) // 捕获阶段先于业务逻辑 window.addEventListener(keydown, onEsc) })用捕获阶段监听mousedown能保证菜单先关闭、再处理点击目标避免点菜单里的删除结果点到了底下的文件这种穿透问题。5.2 重命名用单个 editingId不要每个节点挂布点const editingId ref(null) const editingDraft ref()只允许一个节点处于重命名状态所以用单值就够了。挂在节点上node.editing true会导致两个问题一是要手动保证开启新的重命名时关掉旧的二是这个状态会跟着数据一起被序列化发到后端。进入编辑态后要做的三件小事输入框自动聚焦、选中不含扩展名的部分Windows 的贴心行为、按 Esc 取消。选中不含扩展名的部分是这样实现的function focusInput(el, node) { el.focus() const dot node.type file ? node.name.lastIndexOf(.) : -1 if (dot 0) el.setSelectionRange(0, dot) else el.select() }5.3 文件名校验规则比你想的多这一块必须写全不然用户能造出各种奇怪的名字后面接后端时才炸。Windows 的规则我整理成表格规则示例说明不能为空或全空格 前后空格会自动去掉不含 9 个非法字符\ / : * ? |正则一条搞定不占用保留名CON、PRN、AUX、NUL、COM1~COM9、LPT1~LPT9带扩展名也算CON.txt同样非法不能以点或空格结尾abc.、abc系统会自动去掉所以要提前拦长度不超过 255—按字符数而非字节数同目录不重名—不区分大小写最后一条特别容易漏。Report.xlsx和report.xlsx在 Windows 里是同一个文件很多前端校验用比较导致能建出两个看起来不一样的文件同步到后端后再冲突。校验函数const ILLEGAL /[\\/:*?|]/ const RESERVED /^(con|prn|aux|nul|com[1-9]|lpt[1-9])(\.|$)/i function validateName(name, siblings, selfId) { if (!name || !name.trim()) return 名称不能为空 if (ILLEGAL.test(name)) return 名称不能包含 \\ / : * ? | if (RESERVED.test(name)) return 这是系统保留名称 if (/[. ]$/.test(name)) return 名称不能以空格或句点结尾 if ([...name].length 255) return 名称过长 const lower name.toLowerCase() const dup siblings.some(s s.id ! selfId s.name.toLowerCase() lower) if (dup) return 当前目录下已有同名项 return null }5.4 删除做成软删除回收站才有戏如果产品提到回收站三个字那删除必须是软删除给节点打一个deletedAt时间戳从childrenIndex里摘掉但不从nodeMap里删。回收站就是全表扫一遍deletedAt ! null的节点。还原的时候要处理一个边界原目录可能已经被删了。我的处理是还原时检查parentId对应的节点是否还存在且未被删不存在就退回根目录同时给用户一条提示原位置不存在已还原到根目录。永久删除才是真删而且删文件夹时要连子孙一起清理function purge(id) { const node nodeMap.value.get(id) if (!node) return if (node.type folder) { for (const childId of childrenIndex.value.get(id) || []) purge(childId) } nodeMap.value.delete(id) childrenIndex.value.delete(id) const parent childrenIndex.value.get(node.parentId) || [] childrenIndex.value.set(node.parentId, parent.filter(x x ! id)) }6. 键盘操作把像 Windows这件事做到手感层面功能都通了之后决定用户是否愿意长期使用的是键盘。资源管理器的老用户几乎不用鼠标完成重命名、删除、返回上级这些操作。6.1 方向键导航要先知道列数↑↓ 是上下移动一行在列表视图里就是index ± 1在图标视图里是index ± columns。所以列数是必须的const columns ref(1) function recalcColumns() { const w gridRef.value?.clientWidth || 0 const CELL_W 96 columns.value Math.max(1, Math.floor(w / CELL_W)) }这里有个很隐蔽的坑容器如果有纵向滚动条clientWidth会把它减掉但你在计算时如果用offsetWidth就会得到偏大的值导致算出的列数比实际多一列↑↓ 跳转就错位。统一用clientWidth或getBoundingClientRect().width减掉滚动条宽度。还有一个更隐蔽的列数变化时当前选中项的位置会变用户的肌肉记忆突然失效。我的处理是列数变化时不重新计算选中项只是让它保持选中状态滚动跟随一下即可不做额外跳转。6.2 一套完整的按键映射按键行为备注↑ / ↓上/下一行图标视图按列数位移← / →图标视图左右移一格列表视图下用于收起/展开当前文件夹Home / End跳到首/末项配合 Ctrl 也是一样Enter打开选中项文件夹则进入文件则预览F2重命名选中项单选时可用Delete移入回收站支持多选Backspace返回上一级非常 Windows 的细节Ctrl A全选当前目录—Ctrl C / X / V复制 / 剪切 / 粘贴需要维护剪贴板状态Esc关闭菜单 / 取消编辑 / 清空选中优先级从上到下字母键按名称跳转定位输入累积 500ms 内算一次Esc 的多级语义最容易乱。我的处理是维护一个当前最上层可取消的东西的判断顺序先看有没有打开菜单再看有没有在编辑最后才是清空选中。这样用户不需要思考连按 Esc 就能一层层退出来。6.3 键盘事件绑在容器上不要绑在 window绑在window上最省事但会带来一堆麻烦输入框里打字时按 Delete 会把文件删了按 Backspace 会返回上级。页面里只要有一个搜索框就会出问题。正确做法是给列表容器加tabindex-1把keydown绑在容器上然后在进入页面时或点击空白处时focus()它。同时给一个可见的聚焦样式细边框或高亮让用户知道键盘操作生效了。当重命名输入框获得焦点时因为事件冒泡的关系还是要判断一下但比全局监听干净得多function onKeydown(e) { if (editingId.value) return // 编辑态交给输入框自己处理 const tag e.target.tagName if (tag INPUT || tag TEXTAREA) return // ... 分发按键 }6.4 滚动跟随别直接用 scrollIntoViewscrollIntoView会把元素滚到视口中间或者最小可见位置但它是相对于最近的可滚动祖先的在虚拟滚动里目标元素可能压根还没渲染出来调用无效。我的做法是根据索引手动算function ensureVisible(index) { const top index * ROW_H const bottom top ROW_H const viewTop scrollTop.value const viewBottom viewTop viewportHeight.value if (top viewTop) scrollTop.value top else if (bottom viewBottom) scrollTop.value bottom - viewportHeight.value scrollEl.value.scrollTop scrollTop.value }手动算的另一个好处是可以留出一点边距让选中项不要紧贴容器边缘视觉上更舒服。7. 真的要去读本地磁盘先认清浏览器的边界这一节说点务实的。很多人做这个功能时的第一反应是让它像 Windows 一样能浏览我的电脑但必须明确浏览器出于安全原因不能随意读取本地文件系统。有几条可行的路线适用场景完全不同。7.1 后端目录接口最常用的路线真实的企业素材库、网盘、项目管理系统99% 都是后端提供目录列表接口前端只做展示。接口返回的应该是已经排好序、带好层级关系的扁平结构{ parentId: dir_1024, path: [此电脑, 素材库, 2024], items: [ { id: d_1, name: 字体, type: folder, size: 0, mtime: 1710000000000 }, { id: f_9, name: 封面.png, type: file, size: 248233, mtime: 1710000500000 } ] }前端拿到后直接灌进nodeMap和childrenIndex。这里有个性能上的建议一次请求一层不要一次拉全树。用户点开哪个目录再拉哪个目录把已拉取的节点缓存起来返回上一级时直接用缓存渲染同时静默刷新一次保证数据新鲜。7.2 File System Access API能读能写但限制明确window.showDirectoryPicker()可以拿到用户授权后的目录句柄然后递归读取甚至在用户授权下写回文件。这是最接近真资源管理器的方案。但要注意几点必须由用户手势触发点击事件里直接调用不能放在await之后只能在安全上下文HTTPS 或 localhost下使用不同浏览器的支持程度差别不小必须准备降级方案。递归读取大目录时要控制并发我一般用简单的并发池一次最多 8 个目录同时在读多了反而慢。async function walk(handle, id, depth 0) { if (depth 12) return for await (const entry of handle.values()) { const childId ${id}/${entry.name} addNode({ id: childId, name: entry.name, type: entry.kind directory ? folder : file, parentId: id }) if (entry.kind directory) await walk(entry, childId, depth 1) } }for await...of配合handle.values()是异步迭代器天然是流式的不会一次性把所有 entry 拿回来内存友好。但它是串行的大目录下会慢我上面提到用并发池就是为了解决这个先把当前层的 entry 全部await到数组再对子目录分批并发。7.3 webkitdirectory只读快照适合导入场景input typefile webkitdirectory能一次性拿到整个目录下所有文件每个File对象上都带webkitRelativePath格式是顶层目录/子目录/文件名。按/切开就能重建出目录树。这条路线的定位很明确一次性的导入。没有后续的写回能力也不会有目录变化的通知。做批量上传素材这个场景非常合适做文件管理器就不合适。7.4 纯前端 Mock开发期最省事的方案后端接口没就绪的时候我一般写一个 Mock 生成器按扩展名池随机造几千个节点const EXTS [png, jpg, pdf, xlsx, docx, mp4, zip, txt, md] const NAMES [封面, 合同, 预算表, 会议记录, 需求文档, 原型图, 宣传片] function mockTree(rootId, folderCount, fileCount) { for (let i 0; i folderCount; i) { const id uid() addNode({ id, name: 目录-${i 1}, type: folder, parentId: rootId, mtime: Date.now() - i * 86400000 }) } for (let i 0; i fileCount; i) { const ext EXTS[i % EXTS.length] const id uid() addNode({ id, name: ${NAMES[i % NAMES.length]}-${i 1}.${ext}, type: file, ext, parentId: rootId, size: Math.floor(Math.random() * 5e7), mtime: Date.now() - Math.floor(Math.random() * 3e10) }) } }Mock 生成器有个额外好处它能帮你验证性能边界。我会专门造一个 5 万文件的目录跑一遍看虚拟滚动、框选、排序在极端数据下的表现。这个测试在开发期做比上线后被用户拿真实数据打脸便宜太多。8. 几个我真实踩过的坑以及最后的收尾前面把体系讲完了这一节只讲那些文档里不会写、只有真做过才知道的细节。8.1 用 index 当 key排序后选中全乱v-for里图省事写:keyindex列表看起来没问题一排序就发现选中的是别的文件、重命名框跑到了另一个元素上。原因很直白Vue 复用 DOM 节点时是按 key 匹配的key 用 index 相当于告诉 Vue 第 3 个位置还是同一个东西排序后位置内容变了复用的组件实例却还是旧的内部状态全错位。永远用节点 id 当 key这是硬规矩。8.2 深度侦听整棵树一导入真实数据就卡watch(tree, fn, { deep: true })这个写法在小数据量下毫无问题是它最大的迷惑性。等树有几千个节点任何一次鼠标移动引起的选中态变化都可能触发侦听器重新遍历整棵树。替代方案是按需侦听具体字段或者干脆用事件驱动——所有写操作都走统一的commit()方法在方法里主动触发需要的计算而不是被动侦听。8.3 computed 里调 getBoundingClientRect滚动时抖成筛子我在一个版本里把可见行数写成computed(() Math.ceil(el.getBoundingClientRect().height / ROW_H))结果每次滚动都触发布局查询滚动条一拖就掉帧。任何测量 DOM 的操作都应该放在 resize 监听或者onMounted里算出来存进 ref不要在 computed 里现算。这个原则在列表滚动的场景下尤其重要。8.4 滚动条宽度导致的列数偏差这个坑前面提过值得再强调一次。在 Windows 上滚动条会占 15~17px在 macOS 上默认是浮层不占宽度。同一份clientWidth计算代码在两个系统上得出的列数不同macOS 上多一列导致图标视图最后一行只放一个元素。用 CSS 的scrollbar-gutter: stable或者干脆手动预留一个固定宽度能让两端表现一致。8.5 拖拽取消时状态没清理dragState.active如果在dragend里没清干净下一次鼠标划过去会莫名其妙出现放置高亮。而且dragend在拖拽被浏览器中断时也会触发比drop更可靠。我现在的习惯是dragend、drop、Esc三个地方都做一次状态重置宁可多做也不漏——重置是幂等的多做没有副作用。8.6 一个关于剪贴板的小设计CtrlC 之后如果只是存了 id 列表用户在别的地方把那个文件重命名或者删掉了再粘贴就会出现复制了一个不存在的文件。我的处理是复制时存 id 列表粘贴时逐个校验节点是否还存在、是否还是原来的 parentId如果原节点已不在直接跳过并在提示条里说明有 2 个文件已失效未执行粘贴。这个小提示看起来多余但用户遇到一次就会觉得这软件靠谱。如果你想在这个基础上继续往上做我建议的方向是详情面板 预览右侧加一个可折叠的侧栏单选时展示缩略图、尺寸、修改时间、标签双击文件时用object或img直接预览图片、PDF、纯文本都好办视频用video加URL.createObjectURL就能播。再往下就是标签体系和搜索搜索这块只要在nodeMap上做一次带防抖的全表扫描就够了几千个节点扫一遍也就几毫秒没必要上索引——先跑起来等真的到十万级再谈优化。
