插件管理器不适用于安全校验，因其忽略TLS证书、不验证文件哈希与数字签名、下载过程无审计；安全校验须离线完成三步：确认官方GitHub发布页、certutil比对SHA256哈希、验证DLL数字签名有效性。
Notepad++ 插件不能靠“点开看看”来校验——尤其在安全环境里，必须跳过 GUI 层、直读字节、比对可信源。
为什么插件管理器（Plugin Admin）不适用于安全校验
Plugin Admin 是个在线 UI 工具，它从 https://github.com/notepad-plus-plus/nppPluginList/raw/master/plugins.xml 拉取元数据，再调用 Windows API 下载 ZIP 或 DLL。整个过程：
• 不验证服务器证书（默认忽略 TLS 证书错误）
• 不校验下载后文件的哈希或签名
• 不检查 DLL 的数字签名（即使官方插件带 Authenticode 签名，它也不做验证）
• 下载路径默认是临时目录，文件落地前无审计点
换句话说：你点「安装」那一刻，就已把网络请求、解压、写入 plugins/ 目录的控制权交给了未沙箱化的进程。在断网、高权限受限或审计要求强的环境里，这一步本身就是风险源。
校验插件 DLL 的三个硬性动作
真正可落地的安全校验，只依赖三件事：来源可信、字节一致、签名有效。全部可在离线或受限网络下完成：
- 确认插件原始发布页是否为官方 GitHub Release 页面（如
https://github.com/bruderstein/nppxmltools/releases），且版本号与plugins.xml中记录一致 - 用
certutil -hashfile "NppXMLTools.dll" SHA256计算本地 DLL 哈希，与 Release 页面的.sha256文件内容逐字符比对（注意：不是看网页描述文字，是下那个同名的NppXMLTools.dll.sha256文件） - 右键 DLL → 属性 → 数字签名 → 选中签名 → 详细信息 → 确认「此数字签名正常」且颁发者为
Bruderstein, Christian或Don HO等已知维护者（不是“Unknown”或自签名）
绿色版插件目录结构本身是第一道校验关
很多安全流程卡在“插件放进去但没生效”，结果回头重装主程序——其实问题早在第一步就埋下了。v8.0+ 的插件加载器会静默跳过所有结构不合格的子目录，不报错、不记录、不提示。你必须手动确认：
- 插件 DLL 必须放在
plugins\NppXMLTools\NppXMLTools.dll（目录名与 DLL 主文件名完全一致，大小写敏感） - 该目录下**不能有其他 DLL**（比如
NppXMLTools_v2.dll或libxml2.dll），否则整个目录被跳过 - 路径中不能含全角空格、零宽空格、中文括号等不可见字符（可用 PowerShell 检查：
Get-ChildItem "plugins\" -Directory | ForEach-Object { if ($_.Name -match "[\u3000\u200b\uFF08]") { Write-Host "⚠️ $($_.Name) contains invisible char" } }）
别让 VC++ 运行库成为隐性信任链漏洞
部分插件（如 PythonScript、HexEditor）依赖特定版本的 Visual C++ Redistributable。它们不打包运行库，而是动态链接 msvcp140.dll 或 vcruntime140.dll。这意味着：
- 你校验过的 DLL，一旦运行时加载了被篡改过的系统级
msvcp140.dll，行为就不可控 - 安全环境应优先选用静态链接版插件（如 NppFTP 提供的
NppFTP-static.dll），或使用Dependencies.exe查看其导入表，确认无非必要外部依赖 - 若必须用动态链接版，应在同一台机器上用
sigcheck -i msvcp140.dll（Sysinternals 工具）验证该 DLL 是否由 Microsoft 签名且时间戳有效
最常被忽略的一点：插件校验不是一次性动作。只要 plugins/ 目录存在写权限，任何后续进程（包括 Notepad++ 自身的自动更新逻辑）都可能覆盖或注入文件。真正的安全闭环，是把校验步骤固化进部署脚本，而非依赖人工点击。
