纯HTML在线环境无法访问真实文件系统，所谓“虚拟文件系统”实为用JavaScript对象硬编码的静态结构，配合DOM渲染模拟目录交互。
不能在纯 HTML 在线运行环境（如 CodePen、JSFiddle、StackBlitz 的预览 iframe 或浏览器直接打开的 file:// 页面）中访问真实文件系统，也就不存在“虚拟文件系统”的底层挂载能力——所谓“模拟”，本质是用 JavaScript 对象硬编码或预置一组结构化的数据，再配合 DOM 渲染和事件控制，做出像在操作目录一样的交互效果。
为什么不能真建虚拟文件系统
浏览器安全模型禁止前端代码读取本地磁盘路径、遍历目录、获取文件元信息（大小、修改时间等）。即使使用 FileSystem API（已废弃）、showDirectoryPicker()（需用户手动授权且仅限现代 Chromium），也要求页面运行在 https:// 或 localhost 下，而绝大多数在线运行环境不满足该条件，或直接禁用该 API。所以“虚拟”不是抽象层，而是彻底的假数据 + 假逻辑。
用 JS 对象定义静态目录结构最可靠
所有可运行的在线环境都支持 JSON 数据和 DOM 操作，这是唯一不依赖后端、不触发权限弹窗、开箱即用的方案：
- 结构必须扁平化描述层级，例如用
children数组表示子项，用type: "folder"或"file"区分类型 - 避免递归深度过大（>8 层），否则在线环境可能因栈溢出或渲染卡顿直接崩溃
- 文件名不要含
/、..、./等路径字符，否则容易被误判为路径遍历尝试，部分沙箱环境会静默拦截 - 示例结构：
{ "name": "project", "type": "folder", "children": [ { "name": "index.html", "type": "file", "size": 1240 }, { "name": "css", "type": "folder", "children": [ { "name": "style.css", "type": "file", "size": 892 } ] } ] }
渲染时必须用 <ul> 嵌套，别碰 transform
在线环境常禁用或限制 CSS transform、will-change 等属性，且打印预览、截图工具对这类样式兼容极差。正确做法是：
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
立即学习“前端免费学习笔记（深入）”；
- 每个节点用
<li>包裹，子目录塞进该<li>内部的<ul>，严格遵循 HTML 语义嵌套 - 缩进统一靠
margin-left（如16px每级），不用padding-left（旧版 Safari 计算不准） - 展开/折叠状态通过切换
class="expanded"控制<ul>的display，而不是 visibility 或 opacity - 图标用
::before伪元素生成（如content: "?"），不插<img>或外部字体，防止跨域或加载失败导致布局塌陷
搜索与路径跳转只能模拟，不能真解析
用户输入 /src/js/main.js 并点击“进入”，你无法调用 fs.stat() 或类似接口验证路径是否存在。实际逻辑只能是：
- 把输入路径按
/切分成数组，如["src", "js", "main.js"] - 从根节点开始逐级匹配
children中的name，任一环节没找到就返回“路径不存在” - 匹配成功后，滚动到对应
<li>元素并高亮，但不会改变 URL hash 或 history（除非你主动 pushState） - 不实现
cd ..类命令行逻辑——没有进程上下文，所谓“当前路径”只是你维护的一个字符串变量，容易和 UI 状态不同步
真正难的不是画出树形，而是让每级缩进在 CodePen 的编辑器预览区、StackBlitz 的内置浏览器、手机 Safari 的分享页里都对齐；也不是让搜索能命中，而是当用户粘贴一个带空格的路径时，你的分割逻辑不崩。这些细节一旦写错，调试成本远高于重写整个结构。
