Notepad++ v7.9+ 要求插件必须采用 plugins\<插件名>\<插件名>.dll 的两级结构，子文件夹名与 DLL 主文件名须完全一致（大小写敏感），依赖文件须同目录存放，且需明确标注版本与架构兼容性。
插件目录结构必须严格匹配 Notepad++ v7.9+ 的加载规则
Notepad++ 从 v7.9 开始不再扫描 plugins\ 根目录下的 DLL，而是只认 plugins\<插件名>\<插件名>.dll 这种两级结构。你打包自制插件时若忽略这点，用户安装后菜单里根本不会出现你的插件——不是代码有问题，是路径被直接跳过。
关键约束有三个：子文件夹名必须与 DLL 主文件名完全一致（大小写敏感）、DLL 必须放在该子文件夹内、不能有额外嵌套或错位路径。比如你的插件叫 MySnippetTool.dll，那合法结构只有一种：
plugins\
└── MySnippetTool\
└── MySnippetTool.dll常见错误包括：
- 把
MySnippetTool.dll直接丢进plugins\根目录 - 建了
plugins\MySnippetTool\bin\MySnippetTool.dll（多了一层bin） - 文件夹名用了下划线或空格，如
My_Snippet_Tool，但 DLL 名是MySnippetTool.dll - 打包时混入了调试符号文件（
.pdb）或临时文件（.tmp），Notepad++ 不报错但可能干扰加载
多文件插件必须保持完整子目录结构
如果你的插件依赖配置文件（config.ini）、语言资源（lang.xml）、图标（icon.png）或外部工具（helper.exe），这些文件必须和 DLL 放在同一子文件夹内，不能分散到其他位置。Notepad++ 加载插件时只读取该子文件夹，不会向上或向下跨级查找。
例如 JSON Viewer 类插件通常需要：
plugins\
└── NPPJSONViewer\
├── NPPJSONViewer.dll
├── config.ini
├── lang.xml
└── icons\
├── expand.png
└── collapse.png注意：icons\ 是子文件夹里的子文件夹，完全合法；但如果你把 icons\ 放在 plugins\ 根目录下，它就永远不会被加载到。
验证方式很简单：用资源管理器打开你的插件发布包，确认解压后第一层只有 <插件名>\ 这一个文件夹，且里面包含且仅包含运行必需的文件。
离线分发时要明确标注架构与版本兼容性
用户拿到你的插件 ZIP 包，无法自动判断它是否适配自己的 Notepad++。你必须在 README.md 或安装说明里写清两件事：
-
Supports Notepad++ v8.5.x (API v0.97+)—— 版本范围不能模糊写“v8.x”，因为 v8.0 和 v8.9 的插件接口有细微差异 -
x64 only或x86 only—— 不能写“32/64 位通用”，Notepad++ 的插件是原生 ABI 绑定的，混用会导致静默失败（菜单空白，无任何错误提示）
更稳妥的做法是在 DLL 文件名里体现架构，比如：
-
MySnippetTool-x64.dll+plugins\MySnippetTool-x64\ -
MySnippetTool-x86.dll+plugins\MySnippetTool-x86\
这样用户解压时一眼就能选对，避免因架构错配导致反复重启却始终不生效。
打包脚本里别省略清理步骤
开发过程中生成的中间文件（obj\、bin\Debug\、.vs\）如果被误打进发布 ZIP，不仅增大体积，还可能让 Notepad++ 尝试加载非 DLL 文件而产生不可预测行为。建议在构建流程末尾加一条清理命令：
Get-ChildItem -Path . -Include "*bin*", "*obj*", ".vs", "*.user", "*.suo" -Recurse | Remove-Item -Recurse -Force
另外，C# 插件若使用 DllExport（如 3F 版本），务必确认最终输出 DLL 中确实导出了 getName、getFuncsArray 等必要函数——可用 dumpbin /exports MyPlugin.dll 验证。漏掉任一导出函数，Notepad++ 就会直接跳过整个插件文件夹。
最易被忽略的一点：插件子文件夹名和 DLL 文件名之间的大小写一致性，在 Windows 上看似不敏感，但 Notepad++ 内部加载器是按字节逐个比对的。哪怕只是首字母小写（mysnippettool\mysnippettool.dll），也会加载失败。
