HTML本身无运行时和函数，硬盘灯狂闪源于浏览器加载、解析、缓存、渲染资源时的底层磁盘I/O，如HTTP缓存写入、IndexedDB持久化、Service Worker更新扫描及WebAssembly临时文件存储等。
HTML 本身没有“运行时”概念，更不存在 HTML 函数——硬盘灯狂闪绝不是因为写了 <div> 或调用了 <code>document.getElementById。真正触发磁盘 I/O 的，是浏览器背后加载、解析、缓存、渲染资源时的底层行为。
为什么打开一个 HTML 页面会引发大量磁盘读写
浏览器启动后并非只读取 HTML 文件：它要同步加载并检查本地缓存（CacheStorage、HTTP 缓存目录）、读取扩展脚本、解析 localStorage / IndexedDB 数据库文件、写入新缓存块、甚至刷写渲染进程的临时内存映射文件。这些操作在 Windows 上常表现为 chrome.exe 或 msedge.exe 持续发起小块随机读写。
- 首次访问某站点时，浏览器需解压并写入压缩资源（如
.br或.gz响应体），触发密集磁盘写入 - 启用
Service Worker后，每次更新会扫描整个Cache API存储目录，Windows Defender 可能同步扫描新写入的 JS 文件 - 使用
localStorage.setItem频繁写入大字符串（>1MB）时，Chromium 会将变更刷到磁盘文件，而非仅保留在内存
哪些前端操作真会显著增加磁盘压力
多数 DOM 操作或事件处理完全不碰磁盘；但以下场景会直接关联文件系统调用：
-
fetch()加载未缓存的资源（尤其是大图片/视频）→ 触发 HTTP 缓存写入（路径类似%LocalAppData%\Google\Chrome\User Data\Default\Cache） - 调用
indexedDB.open并执行大量put()→ Chromium 将数据持久化到 LevelDB 文件（每个数据库对应多个*.ldb文件） - 使用
FileSystem API（仅 Chromium 支持）或showDirectoryPicker()→ 显式读写用户选择的本地路径 - WebAssembly 模块通过
WebAssembly.instantiateStreaming加载 → 浏览器需先将流式响应暂存为临时文件再编译
如何快速判断是否异常：看进程 + 看缓存策略
用任务管理器（Windows）或 htop（Linux）观察具体进程的磁盘活动：若只有浏览器主进程（chrome）I/O 高，且持续时间 chrome_crashpad_handler 或渲染子进程也高负载，则可能有扩展在后台轮询或内存泄漏导致频繁 GC + 写 swap。
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
- 检查 Network 面板：所有资源状态码是否多为
200（未命中缓存）？如果是，Cache-Control: max-age=31536000能大幅减少重复读取 - 运行
chrome://discards查看各标签页内存与磁盘缓存占用，确认是否有标签页被标记为 “Eligible for discarding” 却仍在后台活跃 - 禁用所有扩展后重试：某些广告拦截插件（如 uBlock Origin）会在页面加载时解析数 MB 的过滤规则，首次加载即写入
rules.dat
真正该监控的不是硬盘灯，而是 Chrome 的磁盘缓存路径
硬盘灯闪烁本身无害，但持续狂闪超过 2 分钟，且伴随页面卡顿，说明磁盘 I/O 成为瓶颈。此时应直接定位缓存目录：
- Windows：
%LocalAppData%\Google\Chrome\User Data\Default\Cache（注意：此目录禁止手动删除，需用chrome://settings/clearBrowserData） - macOS：
~/Library/Caches/Google/Chrome/Default/Cache - Linux：
~/.cache/google-chrome/Default/Cache
如果该目录下出现大量 _CACHE_* 文件且总大小 >20GB，或存在孤立的 data_0 文件（Chromium 缓存损坏常见迹象），就该清理了。不过别用第三方“加速工具”清 Chrome 缓存——它们常误删 Local Storage 或 Extensions 目录，反而引发更多重写。
