fread/fwrite比fscanf/fprintf更稳，因其减少系统调用、避免格式化解析开销，适合机械硬盘或老化ssd；htmlq/pup比beautifulsoup更高效，依赖mmap单次读取；编辑器需关闭实时索引；cp/rsync -a优于cp -r。
磁盘慢时，fread/fwrite 比 fscanf/fprintf 更稳
机械硬盘或老化 SSD 的随机读写能力弱，fscanf 和 fprintf 这类格式化函数每次都要解析/生成文本结构，额外消耗 CPU 且触发更多小块 I/O，容易卡在磁盘寻道上。而 fread/fwrite 直接搬运内存块，系统调用次数少、缓冲更可控，对低 IOPS 环境更友好。
- 若工具需批量读取 HTML 模板文件（如静态站点生成器），优先用
fread一次性载入整个文件到 buffer，再用strtok或memchr做轻量解析 - 写入渲染结果时，避免逐行
fprintf(fp, "%s", line)，改用setvbuf(fp, NULL, _IOFBF, 8192)启用 8KB 全缓冲，再集中fwrite - 注意：
fread/fwrite处理的是二进制流，若 HTML 文件含 UTF-8 BOM 或换行符不统一，需自行跳过或补全，不能直接当字符串用
Linux 下用 htmlq 或 pup 替代 Python 解析，减少磁盘反复打开
Python 的 BeautifulSoup 每次运行都要加载解释器、导入模块、构建树结构，启动快但冷执行开销大；而 htmlq 和 pup 是单二进制，mmap 映射 HTML 文件后直接解析 DOM，省去多次 open()/read() 调用，对 HDD 友好。
-
htmlq适合简单提取：htmlq -f index.html "title"—— 它只读一次文件，不缓存也不重建树 -
pup支持属性提取和管道：cat page.html | pup 'a[href] attr{href}'，避免临时文件落盘 - 别用
python3 -c "from bs4 import BeautifulSoup; ..."在循环里反复调用，这会为每个 HTML 文件重新打开、解析、释放，HDD 上延迟成倍放大
VS Code / Sublime Text 等编辑器要关掉实时索引，否则 readdir + stat 飙高
编辑器后台的文件监视（尤其是 node_modules 或 .git）会高频调用 readdir 和 stat，在机械硬盘上表现为磁头疯狂抖动、保存延迟明显。这不是函数选错的问题，而是 I/O 模式本身与硬件不匹配。
- VS Code 中禁用：
"search.followSymlinks": false、"search.useRipgrep": false、"files.watcherExclude": {"**/node_modules/**": true} - Sublime Text 设置里加：
"index_files": false，彻底停掉语法索引线程 - 别信“后台扫描能提速跳转”——在 HDD 上，它让首次保存从 200ms 拖到 1.3s，得不偿失
构建工具链中，cp 和 rsync -a 比 cp -r 更适合 HDD
HTML 构建常涉及大量小文件复制（如 dist/ 输出）。默认 cp -r 是递归+同步模式，每复制一个文件都 open+read+write+close，磁盘寻道压力极大。cp（无参数）或 rsync -a 在处理同分区文件时会尝试 reflink 或 sendfile 系统调用，绕过用户态拷贝，显著降低 I/O 次数。
- 同一磁盘内复制：用
cp source/ dest/（注意结尾斜杠），而非cp -r source/ dest/ - 跨设备或需增量：用
rsync -a --delete src/ dst/，它内部做文件差异比对，跳过未变更项 - Node.js 脚本里慎用
fs.copyFileSync循环——它等价于多次cp -r，HDD 上比 shell 命令慢 3–5 倍
fread 的缓冲控制、htmlq 的 mmap 行为、编辑器里关掉 stat 扫描，这些点才是真正影响“保存即生效”的关键。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
