用tasklist查Notepad++进程级内存占用，Memory Usage值（KB）即私有工作集，反映插件实际开销；需配合-noPlugin和插件目录重命名交叉验证。
用 tasklist 查 Notepad++ 进程级内存占用
Notepad++ 本身不提供插件粒度的内存监控，所有插件都运行在主进程内，所以必须从系统层观测整个 notepad++.exe 的私有工作集（Private Working Set）。这是最接近“插件实际吃掉多少内存”的指标。
直接在命令提示符中运行：
tasklist /fi "imagename eq notepad++.exe" /fo list | findstr "Memory"
输出中的 Memory Usage 值（单位 KB）就是当前进程总内存，含所有插件、缓存、Scintilla 渲染缓冲。开一个文件 vs 开同一个文件 + 启用 JSON Viewer，差值基本就是该插件的内存开销。
- 必须在插件已加载且处于活跃状态（比如 JSON Viewer 已展开树、FTP 插件连过服务器）时测量
- 避免同时打开多个大文件，否则干扰判断
- 32 位 Notepad++ 的私有工作集上限约 2GB，超过就容易触发
std::bad_alloc或假死
禁用插件后对比 tasklist 数值变化
插件是否真导致内存暴涨，不能只看“已启用”列表——有些插件（如 Python Script）会在后台预编译脚本、监听文档事件，即使没手动调用也持续占内存。
验证方法是隔离法：
- 先记下当前
Memory Usage值 - 插件→ 插件管理器 → 全部取消勾选 → 重启 Notepad++
- 用相同方式打开同一文件，再跑一次
tasklist对比 - 若下降 >30MB，说明插件群是主要内存贡献者
更彻底的做法是临时重命名插件目录：%PROGRAMFILES%\Notepad++\plugins → plugins.bak，再启动测试。注意：部分插件（如 NppExec）的配置可能残留于 %APPDATA%\Notepad++\config.xml，需一并清理含 <pluginentry></pluginentry> 的行。
命令行启动 + -noPlugin 参数快速定位
当界面已卡死或不确定哪个插件作祟时，-noPlugin 是最快捷的诊断开关。
在 CMD 中执行：
notepad++.exe -noPlugin "D:\logs\bigfile.log"
路径必须加英文引号，否则空格会截断。如果此时秒开、滚动流畅、tasklist 显示内存稳定在 80MB 左右，而正常启动时飙到 1.2GB，那基本可断定是插件引发的内存泄漏或全量解析。
-
-noPlugin会跳过所有插件 DLL 加载，包括自动启动的脚本 - 它不修改任何配置，只是本次启动生效，适合快速验证
- 某些插件（如 Explorer）会修改
shortcuts.xml，若卡死复现，建议一并清空该文件
为什么不能依赖插件自带的“内存显示”功能
少数插件（如某些 Python Script 扩展）会在状态栏显示“已分配内存”，但这类数值往往只是 Python 解释器内部堆统计，和 Windows 实际分配给 notepad++.exe 的私有工作集无关。Scintilla 引擎大量使用原生内存池、GDI 对象、UTF-16 缓冲区，这些都不会被脚本层感知。
更关键的是：插件无法报告自己触发的 Scintilla 全量操作——比如 JSON Viewer 调用 SCI_SETTEXT 加载整份数据，或 Function List 调用 SCI_FINDTEXT 扫描百万行，这些行为会让内存瞬间上涨数百 MB，但插件自身日志里可能只写一行“parsing done”。
真正要盯住的，永远是 tasklist 输出的 Memory Usage，配合 -noPlugin 和插件目录重命名，三者交叉验证才可靠。
