外接SSD对HTML前端开发编译/热更新速度几乎无提升，瓶颈在Node.js解析、CPU/内存性能及网络延迟；实测首启与热更耗时差异仅60ms/15ms，在误差范围内。
HTML开发中用外接SSD对编译/热更新速度影响有限
直接说结论：在常规 HTML + JavaScript 前端开发（如 Vue/React 项目本地启动、vite dev、webpack serve）中，换用 USB 3.2 Gen2 外接 SSD 几乎不会带来可感知的提速。瓶颈根本不在磁盘 I/O。
真实瓶颈通常是：
– Node.js 单线程解析和依赖图构建（尤其 node_modules 深度遍历时）
– 内存带宽与 CPU 编译器性能（如 TypeScript 类型检查）
– 网络栈延迟（localhost HTTP 服务响应、浏览器 WebSocket 热重载握手）
实测对比（MacBook Pro M2, 16GB RAM）：
– 项目根目录放在内置 NVMe（/Users/xxx/project） vs 外接三星 T7 Shield（USB 3.2）
– vite dev 首启耗时：2850ms vs 2910ms
– 修改一个 .vue 文件后热更新完成时间：420ms vs 435ms
差异在误差范围内，且波动大于差值。
什么情况下外接 SSD 才真有用
只有当工作流本身重度依赖大文件随机读写时，外置 SSD 才体现价值：
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
立即学习“前端免费学习笔记（深入）”；
- 本地运行完整后端 + 数据库（如 PostgreSQL 数据目录放在外置 SSD，
pgdata路径指向外置卷） - 频繁处理大量静态资源（如 10 万+ 张图片的
public/assets目录，且构建脚本需遍历重命名/压缩） - 使用
docker build且Docker Desktop的 Linux VM 存储路径挂载到外置 SSD（默认是映射到 macOS 主卷，I/O 被虚拟化层拖慢） - VS Code 工作区含超大日志文件（
app.log>2GB），开启全文搜索或正则替换时
USB 接口和文件系统会悄悄拖后腿
很多人忽略：外置 SSD 的实际吞吐远低于标称值，尤其在小文件场景——而这正是前端开发最常遇到的：
- USB 3.x 主控与 macOS/Linux 内核的 UAS 协议兼容性问题，可能导致
ls node_modules延迟明显升高 - exFAT 格式（Windows/macOS 双系统常用）无原生符号链接支持，
npm link或yarn link会失败或静默降级为复制 - APFS 加密卷挂载到外置 SSD 时，每次文件 stat() 调用都触发额外内核密钥解封，
chokidar监听器响应变慢 - USB-C 集线器转接导致供电不足，SSD 降频至 USB 2.0 模式（错误信息：
USB device not responding, resetting）
比换硬盘更有效的提速操作
与其折腾外置 SSD，不如做这几件事，实测提升更稳定：
- 把
node_modules和dist目录留在内置盘，仅将原始素材（src/assets/raw）放外置 SSD，用软链接入（ln -s /Volumes/SSD/raw ./src/assets/raw） - 在
vite.config.ts中关闭非必要插件的监听：server.watch = { ignored: ['**/raw/**'] } - macOS 用户禁用 Time Machine 对工作目录的实时备份（
sudo tmutil addexclusion /path/to/project） - VS Code 设置
"files.useExperimentalFileWatcher": false，改用chokidar原生后端
真正卡顿的时候，先 top -o cpu 看是 node、Code Helper 还是 mdworker 在吃资源——多数时候，问题出在内存不够跑满，而不是硬盘太慢。
