任务管理器性能页签是判断CPU和内存瓶颈的直接依据：若CPU或内存峰值持续超80%且响应延迟，即表明已成瓶颈；此时应禁用插件、关闭后台轮询进程，并优先选用Notepad++等轻量工具。
组装机配置差异大，关键不是“选哪个工具”，而是“按硬件特征分层匹配”——CPU弱就砍后台、显卡多就防DPR错判、内存小就禁插件、系统旧就绕WebView2。
Windows组装机怎么看CPU和内存瓶颈
别猜，直接看任务管理器性能页签：持续占用超80%且响应延迟，说明CPU或内存已成瓶颈。此时任何依赖Node.js或Electron的工具（如默认VS Code）都会卡顿；而Notepad++启动后常驻内存仅30–60MB，不触发GC、无后台更新进程，适合单核2.0GHz以下或内存≤4GB的老旧组装机。
- 打开任务管理器 → “性能” → 观察“CPU”和“内存”的“峰值”值
- 若内存“已使用”长期超3.5GB（总4GB），禁用所有编辑器插件和预览服务
- 若CPU在空闲时仍维持30%+，说明有工具在后台轮询（如Live Server的文件监听器），需关闭
多显卡/高分屏组装机要防devicePixelRatio错判
很多HTML预览工具（包括Brackets旧版、部分HTA封装器）只读window.screen.width，一拖到副屏就模糊或布局崩塌。真正可用的工具必须监听resize和screenchange事件，并动态重设canvas.width与ctx.scale(dpr, dpr)。
- 测试方法：将编辑器窗口从笔记本屏（2x DPR）拖到外接4K显示器（1x DPR），打开含Canvas的HTML，观察是否清晰
- VS Code + Live Server组合默认不处理跨屏DPR切换，需手动在开发者工具中执行
document.querySelector('iframe').contentWindow.devicePixelRatio验证 - Brackets 1.14+已修复该问题，但仅限Chrome浏览器；Firefox下Live Preview会失效
Win7/Win10 LTSC等老系统必须绕过WebView2依赖
Windows 7 SP1或Win10 LTSC（无Edge更新通道）无法安装WebView2 Runtime，所有基于Chromium内核的HTML渲染功能（如VS Code内置预览、某些插件的弹出面板）会白屏或报错Failed to create WebView2 environment。此时只能退回MSHTML（Trident）路径。
立即学习“前端免费学习笔记（深入）”；
- Notepad++的
Ctrl + Shift + X内置浏览器调用的是IE COM接口，Win7原生支持，无需额外安装 - 若系统已卸载IE，改用Firefox ESR 115：在
about:config中启用media.mediasource.enabled和dom.webcomponents.enabled - 绝对避免使用标有“Requires WebView2 SDK ≥1.0.1518.46”的工具——这类工具在Win7上连进程都拉不起来
主板集成显卡+低功耗CPU慎用实时渲染类工具
Intel HD Graphics 4000、AMD Radeon R5等老集显缺乏WebGL 2.0支持，Brackets的Live Preview或VS Code的Canvas预览会降级为软件渲染，CPU占用飙升。这时候“保存→双击打开浏览器”仍是最快路径。
- 检查方式：打开
chrome://gpu，确认“WebGL”和“WebGL2”状态是否为“Hardware accelerated” - 若显示“Software only, hardware acceleration unavailable”，立即停用所有实时预览功能
- Notepad++搭配Firefox ESR 115是唯一稳定组合：前者零GPU依赖，后者对老集显做了大量软加速适配
组装机最麻烦的不是配置高，而是混搭——比如Win10 21H1系统配Win7驱动的独显，或新主板刷了旧BIOS导致DPR报告异常。这种情况下，工具链里只要有一个环节依赖未满足的API，整条预览流就断掉。宁可多一步手动双击，也不要赌某个“自动同步”功能能跨过硬件残缺。
