咱们先直接抓核心问题：从报错日志能明确看出来，NiFi在扫描./work/nar/extensions目录加载NAR扩展时，把Mac系统自动生成的隐藏文件.DS_Store当成了一个NAR目录来处理，试图读取它内部的META-INF/MANIFEST.MF，但.DS_Store本质是个文件而非目录，所以触发了这个异常。

下面分两步彻底解决问题：

1. 紧急修复：先移除干扰的.DS_Store文件 #

• 先确保NiFi处于停止状态（如果还在反复启动尝试的话）
• 进入NiFi的work/nar/extensions目录，删除所有.DS_Store文件，用命令行更稳妥：

  find /path/to/your/nifi/work/nar/extensions -name ".DS_Store" -type f -delete
  

• 同时检查你之前放到NiFilib目录的文件，确认没有把Mac自动生成的.DS_Store也一并拷贝进去了

2. 规范NAR包的构建与部署（针对你的POM配置） #

你当前的POM同时混用了nifi-nar-maven-plugin和maven-shade-plugin，这其实不符合NiFi的扩展包规范——NiFi不需要你手动打fat jar，而是依赖NAR包机制来做依赖隔离和加载。

调整POM配置 #

• 移除maven-shade-plugin的全部配置：NiFi的NAR插件会自动处理依赖打包，不需要手动做shade
• 把nifi-nar-maven-plugin的版本和你的NiFi版本对齐（你用的是NiFi 1.4.0，插件版本不能用1.0.0-incubating），修改后的插件块：

  <plugin>
    <groupId>org.apache.nifi</groupId>
    <artifactId>nifi-nar-maven-plugin</artifactId>
    <version>1.4.0</version>
    <extensions>true</extensions>
  </plugin>
  

• 清理POM里重复的测试依赖：比如你重复引入了两次cassandra-unit-spring和不同版本的cassandra-unit，保留一套即可，避免潜在的依赖冲突

正确部署NAR包 #

• 执行mvn clean package后，在target目录下会生成后缀为.nar的标准NiFi扩展包（而不是fat jar）
• 将这个.nar文件放到NiFi安装目录的extensions文件夹下，不是lib目录——lib是放NiFi核心依赖的，扩展包要放extensions
• 重新启动NiFi即可

额外预防：避免后续再踩.DS_Store的坑 #

• 在Mac的Finder中关闭“显示隐藏文件”，防止误拷贝.DS_Store
• 在项目的.gitignore中添加.DS_Store，避免把这个文件提交到版本库
• 部署包时尽量用命令行拷贝，比如：

  cp target/nifi-project-1.0.nar /path/to/your/nifi/extensions/
  

  不要用Finder拖拽，减少误操作的概率

内容的提问来源于stack exchange，提问作者AbtPst