code指定启动类名，archive指定依赖JAR包；二者分工强制，缺一导致ClassNotFoundException；code值须与JAR内路径严格一致，archive路径受codebase影响，JAR结构错误是加载失败主因。
code 和 archive 不是可选搭配，而是强制分工：code 告诉浏览器“启动哪个类”，archive 告诉浏览器“从哪把整个依赖包拉下来”——漏掉 archive，哪怕 code 写对了，也必然报 ClassNotFoundException 或资源加载失败。
code 属性只认类名，不负责找路径
浏览器不会扫描目录、不会递归查找、也不会按包名自动拼路径。你写 code="com.example.MyApplet.class" 或 code="com.example.MyApplet"，它就只尝试加载这个类名对应的字节码；如果该类不在 classpath 里（而 archive 没提供），直接失败。
-
code值必须与 JAR 内实际路径严格一致：比如类声明为package com.example;，那 JAR 中必须有com/example/MyApplet.class，不能是src/com/example/MyApplet.class或build/classes/com/example/MyApplet.class - 不要写成文件系统路径（如
code="./classes/com/example/MyApplet.class"），code是逻辑类名，不是 URL - 常见错误：本地编译后直接拿
.class文件丢进 web 目录，用code="MyApplet.class"—— 这只在极简单例中偶然成功，一加包名或依赖立刻崩
archive 必须指向 JAR，且路径解析受 codebase 暗中影响
archive 的值不是独立生效的，它默认相对于 codebase 解析；没写 codebase 时，才退回到 HTML 文件所在目录。很多人调试时死磕 archive 路径却忽略 codebase 的存在，结果 HTTP 请求发到了错误地址。
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 若
codebase="https://cdn.example.com/app/"且archive="lib/utils.jar,applet.jar"，真实请求的是https://cdn.example.com/app/lib/utils.jar和https://cdn.example.com/app/applet.jar -
archive支持多个 JAR，用英文逗号分隔，但顺序无关；浏览器会一次性并行下载所有 JAR，再统一构建 classpath - 别指望 JAR 里的
META-INF/MANIFEST.MF中Class-Path:条目生效——主流浏览器（包括当年的 Firefox/IE 最后几个支持版本）完全忽略它 - HTTP 状态码 200 不代表加载成功：JAR 下载成功但内部结构错，仍会触发
NoClassDefFoundError
验证 JAR 结构比检查 HTML 更关键
绝大多数 ClassNotFoundException 根源不在 HTML 写错，而在 JAR 打包方式不对。浏览器只认 JAR 内部路径，不认你本地文件夹怎么组织。
- 用
jar -tf myapp.jar看顶层内容：正确结构应直接看到com/、images/、META-INF/，而不是src/com/或build/com/ - 资源文件（如
images/icon.png）必须放在 JAR 内对应路径，代码中要用getClass().getResource("/images/icon.png")（注意开头的/） - 如果用了构建工具（Ant/Maven），确认打包插件没把 class 输出路径嵌套进 JAR —— Maven 的
maven-jar-plugin默认行为是干净的，但自定义assembly或shade时容易多套一层目录
现在没人再用 <applet>，但维护老系统时，最卡人的从来不是语法，而是你以为路径对了、URL 返回 200、控制台没报 404，结果类就是死活找不到——问题十有八九藏在 JAR 包 zip 层里，或者被 codebase 静默改写了请求地址。
