双击Jar包无反应是因为MANIFEST.MF中Main-Class未正确声明或类名拼写错误；必须显式指定完整类名、结尾空一行，且不可依赖-jar参数自动推导。
jar命令打包时为什么双击没反应？main-class没写对
可执行Jar包必须在META-INF/MANIFEST.MF里声明入口类，光有java -jar xxx.jar能跑，不等于双击或系统默认打开就能启动。常见错误是漏写Main-Class属性，或类名拼错（比如写了com.example.Main却忘了.class文件实际在out/production/下、路径没对齐）。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 用
jar cfm MyApp.jar MANIFEST.MF *.class显式指定清单文件，别依赖-e参数自动推导（它只认顶层public class，且不处理包路径） -
MANIFEST.MF里Main-Class值必须是完整类名（不含.class），结尾要空一行，否则JVM忽略整行 - 验证是否生效：解压Jar后检查
META-INF/MANIFEST.MF内容，或运行jar -xf MyApp.jar && cat META-INF/MANIFEST.MF
jar -cvsf 和 jar -cvfe 的区别在哪？什么时候该用-e
-e参数看似方便，但只适用于“单入口+无依赖+类在默认包”的极简场景；一旦项目有包结构（如src/main/java/com/app/Start.java），-e会直接失败——它要求指定的类名必须能在当前目录下被javac直接编译出同名.class，不查CLASSPATH也不递归扫描子目录。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 有包路径？放弃
-e，老实用-f配META-INF/MANIFEST.MF -
-c（create）、-v（verbose）、-s（generate signature）三者常一起用，但-s仅当需要JAR签名时才加，普通应用没必要 - 如果依赖外部
.jar（如gson.jar），jar命令本身不支持自动合并，得手动解压再重打包，或改用Gradle shadowJar/Maven assembly
打包后运行报错“NoClassDefFoundError”？classpath没被嵌入
jar命令原生不处理依赖传递，Class-Path字段只影响运行时JVM去哪找其他Jar，但不会把那些Jar打进去。所以当你在META-INF/MANIFEST.MF里写了Class-Path: lib/gson.jar，就必须确保运行时lib/gson.jar真在相对路径下，否则立刻崩。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 检查
Class-Path里的路径是相对路径，且以空格分隔（不是冒号或分号），末尾不能有换行符 - 不想管外部依赖？别用
jar原生命令，改用java --module-path+--add-modules（Java 9+模块化），或用构建工具做fat jar - 临时调试可用
java -cp "MyApp.jar:lib/*" com.example.Main绕过Manifest限制（Linux/macOS用:，Windows用;）
Java 17+ 打包要注意什么？模块化和签名机制变了
JDK 17 默认禁用sun.*和com.sun.*内部API，如果你的代码或依赖用了sun.misc.BASE64Encoder这类，打包后运行时不会报编译错，但一调用就NoSuchMethodError。另外，jar -s生成的签名在Java 14+已弃用，改用jarsigner独立工具。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 编译时加
--illegal-access=deny提前暴露内部API调用问题 - 签名不再用
jar -s，改用jarsigner -keystore mykey.jks -storepass pass MyApp.jar alias_name - 模块化项目（
module-info.java存在）必须用jar --file=MyApp.jar --create --main-class=com.example.Main -C out/ .，旧版-cfm不识别模块描述符
真正麻烦的是混合场景：既有老式Class-Path依赖，又想用模块化启动，还得兼容JDK 8到21。这时候jar命令只是个基础工具，边界非常清楚——它不解决依赖管理，也不抽象构建逻辑。手写MANIFEST.MF、反复解压验证、对着java -verbose:class输出查类加载路径，才是常态。
