我来帮你拆解下你遇到的问题——你想直接通过JVM启动参数禁用jdk.InitialEnvironmentVariable和jdk.InitialSystemProperty这两个JFR事件，省得事后再去 scrub 录制文件，但用JDK25测试后发现参数没效果，怀疑是版本或者Docker语法的问题，对吧？

下面给你梳理可能的原因和对应的排查、解决办法：

一、先排除版本兼容性疑虑 #

JDK17之后就支持通过-XX:StartFlightRecording参数直接配置单个事件的启用状态，JDK25作为后续版本，理论上完全支持这个特性，版本大概率不是核心问题。不过你可以先确认下这两个事件在JDK25里的名称有没有变化：

• 在容器里执行jfr list events | grep -E "InitialEnvironmentVariable|InitialSystemProperty"，如果能输出对应的事件名称，说明事件存在且名称正确；如果没输出，那可能是事件名在JDK25里有变更，需要用新名称配置。

二、检查启动参数的语法细节 #

你当前的参数写法是：

-XX:StartFlightRecording:jdk.InitialEnvironmentVariable#enabled=false,jdk.InitialSystemProperty#enabled=false

这里有个容易踩坑的点：参数里的逗号前后绝对不能加空格，你现在的写法是对的（逗号后没空格），但如果Docker-entrypoint脚本里不小心在逗号后加了空格，就会导致参数被拆分，JVM无法正确解析。

另外也可以试试拆分写法，有时候能避开shell解析的坑：

-XX:StartFlightRecording:jdk.InitialEnvironmentVariable#enabled=false -XX:StartFlightRecording:jdk.InitialSystemProperty#enabled=false

三、Docker-entrypoint的参数传递验证 #

Docker的entrypoint脚本里，exec java后面的参数很容易因为shell解析规则出问题，比如参数被意外拆分，JVM会把后面的事件配置当成独立参数处理，自然不会生效。

你可以在exec java前面加一句调试输出：

echo "Executing command: java $@"
exec java \
...

启动容器时就能看到实际传递给java的参数是什么，确认你的JFR配置参数是不是作为一个完整选项被传递了。

四、更稳妥的替代方案：自定义JFC配置文件 #

如果启动参数的方式始终有问题，试试用自定义JFC配置文件的方式，步骤很简单：

1. 从JDK25导出默认配置模板：jfr configure --default > myconfig.jfc
2. 编辑myconfig.jfc，找到对应事件的配置项，把enabled改成false：

   <event name="jdk.InitialEnvironmentVariable" enabled="false"/>
   <event name="jdk.InitialSystemProperty" enabled="false"/>
   

3. 在Docker-entrypoint里把这个配置文件挂载到容器中，然后指定使用该配置：

   exec java \
   ...
   -XX:StartFlightRecording=config=/path/to/myconfig.jfc \
   ...
   

这种方式更直观，也能避免启动参数的语法解析问题，适合多事件自定义的场景。

五、验证禁用是否生效的方法 #

不管用哪种方式，最后都要验证下效果：

1. 启动容器后，用jcmd <pid> JFR.dump filename=recording.jfr生成录制文件（替换<pid>为你的JVM进程ID）
2. 用jfr print --events jdk.InitialEnvironmentVariable recording.jfr查看录制内容，如果没有任何输出，说明这个事件已经被成功禁用；同理检查另一个事件。

按照上面的步骤排查下来，应该能解决你遇到的问题，如果排查过程中有具体的异常输出，随时告诉我，我再帮你进一步分析~