1. 启动参数Spring Boot 灵魂里的“遥控器”很多同学跑 Spring Boot 项目基本就是java -jar app.jar一键启动或者点一下 IDEA 里的绿色三角。但等你真正上了生产、接了运维、开始排查线上问题就会发现启动参数不是“会不会写”的问题而是“会不会用”的问题。同一个 jar 包凭什么在测试环境跑 8080、在生产环境跑 8081凭什么开发时日志满屏飞、生产时只输出 WARN凭什么人家 2G 内存的机器能跑得很稳你的 4G 机器动不动 OOM答案基本都藏在“启动参数”这四个字里。这篇文章我打算把 Spring Boot 启动参数从 JVM 层、应用命令行层、配置文件层一次性拆透捋清楚它们之间的优先级关系、常见配置项的取舍思路以及基于 Java 21 Spring Boot 3.5 这类新组合怎么用启动参数做虚拟线程、Tomcat 内嵌调优。文章会带具体的命令模板、参数表格和排障实录适合刚接触 Spring Boot 的新手也适合写过一段时间但一直没把启动参数当回事的人。先抛出我个人的一个观点Spring Boot 的启动参数就是整个应用的“遥控器”。你不需要改代码就能切换环境、控制日志级别、调整内存行为、甚至替换注册中心地址。搞清楚这套东西不夸张地说能省掉你日后大量的“重启试错”时间。2. 到底什么是 Spring Boot 启动参数先搭个框架2.1 三类参数三种生效位置很多教程一上来就甩--server.port8081新手往往一脸懵这个参数到底传给谁跟-Dserver.port8081有什么区别跟application.yml里的server.port又是什么关系不把这层窗户纸捅破后面全是浆糊。从参数生效的位置看Spring Boot 启动参数可以分成三大类。第一类是 JVM 参数。典型的比如-Xmx512m、-Xms256m、-XX:UseG1GC它们必须放在-jar之前作用对象是 Java 虚拟机本身。这类参数和 Spring Boot 没有任何直接关系你跑任何一个 Java 程序它都吃这一套Spring Boot 只是“恰好跑在 JVM 上的一个 Java 程序”而已。如果你用 IDEA 启动就是在VM options里填的东西。第二类是应用命令行参数。典型的就是--server.port8081、--spring.profiles.activeprod这种。它们放在-jar后面Spring Boot 的SpringApplication会把它们解析成PropertySource然后灌进 Spring 的Environment里。所有ConfigurationProperties、Value都能读取到它们。注意这类参数是以双横杠--开头的这是 Spring Boot 识别命令行参数的标准姿势。第三类是配置文件里的参数。application.properties、application.yml以及通过--spring.config.location或--spring.config.additional-location额外引入的配置文件。这三个来源最终会汇入同一个Environment只是优先级不同。我用一个生活化的类比来说明JVM 参数好比“房子的地基”决定房子能盖多高命令行参数是“屋主拿着喇叭喊的指令”优先级最高、谁都不能不听配置文件是“贴在墙上的使用手册”只有没人喊话时才轮到它来兜底。2.2 优先级顺序记住这张表就够了Spring Boot 的Environment里参数来源非常多我这里挑实际开发中最常见的几个按从高到低排列优先级参数来源示例说明1命令行参数--server.port8081通过java -jar app.jar --xxx传入2Java 系统属性-Dserver.port8081放在-jar前通过System.getProperty()读取3操作系统环境变量SERVER_PORT8081在部署脚本、Docker 容器中非常常用4application-{profile}.ymlapplication-prod.yml指定 profile 时生效5application.yml默认配置文件优先级最低但最常用的就是它注意一个坑-Dserver.port8081和--server.port8081长得像但行为不完全一样。前者是系统属性会被 Spring Boot 读取并映射到Environment中但如果你把SpringApplication.setAddCommandLineProperties(false)关掉了命令行参数就会失效而系统属性不一定受影响。我在项目里见过有人把一堆-D参数放在启动脚本里后来排查配置不生效问题时发现是优先级被命令行参数压过了折腾了很久。2.3 为什么我建议你优先记命令行参数我个人的习惯是日常开发用配置文件部署和调优用命令行参数。理由很简单配置文件写在代码库里一旦改了就要走 Git 提交、CI 构建流程而命令行参数写在启动脚本或 Dockerfile 里改完重启就生效。生产环境的端口、内存、日志级别大概率不适合写死在application.yml里因为不同环境要求不一样。用命令行参数就能做到“一个 jar 包走天下参数随环境走”。这也是《第 1 关第一个 Spring Boot 程序》这类入门任务里不太会强调、但真实项目里非常重要的一点。3. 命令行参数实战从单机到多环境部署3.1 最简单的启动命令但很多人没用对先看最基础的形态java -jar app.jar --server.port8081 --spring.profiles.activedev这条命令干了三件事启动应用、把端口切到 8081、激活devprofile。如果你的application-dev.yml里连了本地数据库那这个应用跑起来读的就是开发库配置。再扩展一下java -jar app.jar \ --server.port8081 \ --spring.profiles.activedev \ --spring.application.namelecture-system \ --logging.level.com.exampleDEBUG \ --spring.main.banner-modeoff这里我顺便把--spring.main.banner-modeoff加上了作用是关掉启动时那个大大的 Spring Boot ASCII 图案日志文件里干净很多。别小看这个参数CI 日志收集时它对解析是有帮助的。3.2 多环境切换同一个 jar不同玩法拿热搜词里那个“基于 Spring Boot 的校园讲座预约系统”来举个例子。这个系统开发时数据库是本地 MySQLRedis 也是本地的但到了生产环境数据库在云上、Redis 是主从架构、文件存储换成了 MinIO。没有启动参数之前你怎么办改配置、重新打包、发一个生产专用 jar这非常不优雅而且风险极大——你没法保证“改配置的过程中没有手滑把测试地址泄露进生产包”。有了启动参数一切就简单了。项目里只保留三份配置# application.yml server: port: 8080 spring: profiles: active: dev# application-prod.yml spring: datasource: url: jdbc:mysql://prod-db-server:3306/lecture username: prod_user password: ${DB_PASSWORD}# application-dev.yml spring: datasource: url: jdbc:mysql://localhost:3306/lecture_dev username: root password: 123456部署时java -jar lecture-system.jar --spring.profiles.activeprod --server.port8080你甚至可以连端口都不写server.port留在application-prod.yml里。这样整个部署过程就是“把 jar 拷过去跑一条命令”不会有任何代码仓库里的敏感信息泄露。3.3 值得收藏的命令行参数清单我把 Spring Boot 3.x 里最常用、也是我最依赖的一批命令行参数列在下面方便你直接查参数作用示例--server.port修改 Web 服务端口--server.port0随机端口--spring.profiles.active激活环境配置--spring.profiles.activeprod--spring.application.name设置应用名称--spring.application.nameorder-api--spring.config.location指定外部配置文件位置可指定目录或文件--spring.config.additional-location追加外部配置优先级较高放在config/目录外--logging.level.root设置日志级别--logging.level.rootWARN--logging.level.com.example指定包级别日志--logging.level.com.exampleDEBUG--spring.main.banner-mode控制启动横幅off/console/log--spring.main.allow-bean-definition-overriding允许 Bean 定义覆盖在集成测试中比较常用--debug开启自动配置调试报告输出CONDITIONS EVALUATION REPORT--spring.threads.virtual.enabled启用虚拟线程Spring Boot 3.2 支持这里多说一句--debug。很多老手排查自动配置为什么没生效时第一反应不是翻源码而是先带--debug启动一下控制台会打印一份详细的条件评估报告告诉你哪个自动配置类匹配了、哪个没匹配、为什么没匹配。这比瞎猜高效太多。3.4 实操心得IDEA 里怎么传命令行参数开发阶段没必要反复敲命令IDEA 里可以直接配。打开Run/Debug Configurations找到你的 Spring Boot 启动类在Program arguments里填--server.port8081 --spring.profiles.activedev在VM options里填-Xms256m -Xmx512m。别把这两栏填反了这个是我见过的新手高频错误把-Xmx填到 Program arguments 里JVM 根本不认应用照样按默认内存跑。4. JVM 启动参数调优内存、GC 与 Java 21 虚拟线程4.1 先搞清楚 JVM 参数的前置位置JVM 参数必须放在java命令的-jar之前这是 Java 命令行的硬性规定。例如java -Xms256m -Xmx512m -XX:UseG1GC -jar app.jar --server.port8081如果你写成java -jar app.jar -Xmx512mJVM 会直接报“Unrecognized option: -Xmx512m”因为-jar之后的参数会被当成应用参数传给main方法而不是 JVM 自己消费。这个规则看起来简单但实际部署时很多深层问题都跟它有关。比如你在 Dockerfile 里写ENTRYPOINT [java, -jar, app.jar]然后想加内存参数下意识在-jar后面追加-Xmx512m结果容器启动失败。正确的写法应该是ENTRYPOINT [java, -Xmx512m, -Xms256m, -jar, app.jar]4.2 从“Tomcat 启动设置 JVM 参数”聊起热搜词里有“tomcat 启动设置 jvm 参数”这一条我不确定你是指传统独立 Tomcat 部署 WAR 包还是指 Spring Boot 内嵌 Tomcat。两种情况都得讲。传统 Tomcat 的 JVM 参数在catalina.sh里通过JAVA_OPTS设置比如JAVA_OPTS-Xms512m -Xmx1024m -XX:MetaspaceSize256mSpring Boot 内嵌 Tomcat 的做法就简单了因为整个 Tomcat 就跑在你这个 JVM 进程里。你想控制 Tomcat 的工作线程数、连接数也不需要单独去改 Tomcat 的server.xml直接用应用参数就行java -Xms512m -Xmx1024m -jar app.jar \ --server.tomcat.threads.max200 \ --server.tomcat.threads.min-spare20 \ --server.tomcat.max-connections10000 \ --server.tomcat.accept-count100这是 Spring Boot 3.x 的写法注意参数名跟 2.x 略有差异。这些配置以前是改server.xml的Connector标签现在全被 Spring Boot“参数化”了。对于习惯传统 Tomcat 的运维同学来说这会是一个比较大的迁移点但好处是你再也不用为了调整线程池去改 XML 重启整个 Tomcat 实例了。4.3 给应用一个合理的“起步内存”JVM 内存调优最常被人忽视的是-Xms很多人只设置了-Xmx觉得最大内存限制住就行了。实际上-Xms是 JVM 启动时申请的初始堆大小如果-Xms和-Xmx相差很悬殊JVM 在运行过程中就要不断地做堆扩容缩容引入不必要的 GC 压力。我一般建议如果服务器内存足够把-Xms和-Xmx设成一样。比如-Xms1024m -Xmx1024mJVM 起步就是 1G 堆不会在运行中突然又申请一大块内存。这样做的一个附加好处是堆大小稳定后GC 行为更好预测排查线上问题时的参考基线也更可靠。给一个生产环境模板java \ -Xms2g -Xmx2g \ -XX:MetaspaceSize256m -XX:MaxMetaspaceSize256m \ -XX:UseG1GC \ -XX:MaxGCPauseMillis200 \ -XX:HeapDumpOnOutOfMemoryError \ -XX:HeapDumpPath/opt/app/logs/heapdump.hprof \ -jar app.jar这里特别说明一下-XX:MaxGCPauseMillis200它不是硬性保证而是 G1 的一个软目标意思是让 JVM 尽量把 GC 停顿控制在 200 毫秒以内。如果业务对响应时间很敏感这个参数可以帮你压制长停顿的出现频率。4.4 Java 21 Spring Boot 3.5 启用虚拟线程的正确姿势Java 21 正式支持了虚拟线程Spring Boot 3.2 开始就可以通过spring.threads.virtual.enabledtrue开启。到 Spring Boot 3.5虚拟线程已经是非常成熟的能力了。启用方式有两种一种是参数一种配置文件。java -jar app.jar --spring.threads.virtual.enabledtrue或者spring: threads: virtual: enabled: true开启后内嵌 Tomcat 处理请求时会使用虚拟线程而不是传统的平台线程。我之前在压测环境试过一个RestController接口里模拟 200ms 的 IO 等待查 Redis 调远程 API之前配置server.tomcat.threads.max200平台线程模式下一路飙升到接近线程上限切到虚拟线程后同样的并发量线程数几乎不怎么增长因为虚拟线程是轻量级的JDK 自己调度开销远小于平台线程。虚拟线程模式下server.tomcat.threads.max这个参数基本就没多大意义了因为虚拟线程没有“池化”的概念。你反而要注意的是别在代码里用synchronized或ThreadLocal的一些老套路来“省线程”虚拟线程不省这个。另外-XX:UseZGC在 Java 21 里已经可以作为生产选项用了配合虚拟线程跑高并发 IO 密集型服务效果属于“谁用谁知道”。如果想看虚拟线程是否真的生效可以加一个启动参数--logging.level.org.apache.tomcatINFO日志里会打印 Tomcat 的初始化信息或者直接写一段代码在运行时拿请求线程名看看是不是virtual开头。4.5 容器环境下的 JVM 参数别照抄物理机现在绝大多数 Spring Boot 应用都跑在 Docker 或 K8s 里。有个常见的坑容器设置了limits: memory: 1Gi但你在启动参数里写了-Xmx4g。JVM 会认为自己可以随便用 4G 内存最终结果就是容器被 OOM Killer 杀掉。JVM 有一个很贴心的特性在容器环境中如果不显式设置-Xmx它通常会根据容器的内存限制自动算出一个合理的堆大小。但你要是显式写了-Xmx它就会“无条件信任你”然后翻车。我在很多企业现场见到过这种问题所以必须提醒容器环境内要么不写-Xmx让 JVM 自适应要么严格按容器限额来写并且留出一定余量。比如容器限额 2G堆顶到 1.5G 是安全的剩下的留给元空间、线程栈和堆外内存。Java 10 开始默认开启-XX:UseContainerSupportSpring Boot 3.5 Java 21 已经能很好地识别容器内存限制但还是建议你在启动脚本里明确打出下面这两个参数java \ -XX:MaxRAMPercentage75.0 \ -XX:InitialRAMPercentage75.0 \ -jar app.jarMaxRAMPercentage75.0的意思是JVM 最多使用容器可用内存的 75%剩下的留给 JVM 之外的开销。这类参数在 K8s 环境里比写死-Xmx靠谱得多。5. 配置文件里的“启动参数”从 YAML 到外部化配置5.1 配置文件柜Spring Boot 的配置加载是有套路的前面讲的多是命令行和 JVM 参数但实际项目里配置文件的地位反而更高。因为大部分配置——数据源地址、Redis、MinIO、缓存策略——是不适合放在启动命令里的那样命令会变得巨长无比。Spring Boot 的配置加载有默认的搜目录规则当前目录下的config/子目录当前目录classpath 根目录下的config/包classpath 根目录如果你有application.yml和application-prod.ymlSpring Boot 会先加载application.yml再加载application-prod.yml后者会覆盖前者。这个“profile 覆盖默认配置”的机制是 Spring Boot 3 配置迁移中最稳定、也最值得沿用的一点。5.2 配置迁移实战Spring Boot 3 里哪些参数悄悄变了我见过很多从 Spring Boot 2.x 升 3.x 的项目升级后启动时报各种绑定失败或参数不生效。这跟启动参数直接相关因为 Spring Boot 3 对很多配置项做了重命名和梳理。几个典型的server.tomcat.max-threads在 2.x 里是server.tomcat.max-threads3.x 里虽然兼容但推荐用server.tomcat.threads.max。如果你从 2.x 直接升 3.x旧参数还能用但日志会有 deprecation warning。spring.redis.*变成spring.data.redis.*很多团队在 2.4 之后就遇到过这个问题升 3.0 的时候更是大规模踩坑。spring.datasource.*相关参数组基本都归入了spring.datasource下整体改动不大但如果你用了spring.datasource.type指定连接池类型3.x 下要确认 DriverManager 的兼容性。再往细里说Spring Security 的配置迁移热搜词里有“spring boot 3中spring security配置迁移”这一条也跟启动参数有关系。Spring Boot 3 里spring.security.oauth2.client相关的参数路径有调整比如 provider 配置从spring.security.oauth2.client.provider.{id}.authorization-uri到实际注入ClientRegistration之间的距离变了需要你仔细核对版本迁移文档。我的建议是升级之前先用--debug启动一次把CONDITIONS EVALUATION REPORT导出来对比升级前后哪些条件匹配结果不一样再动手改代码。5.3 自定义配置项MinIO、WebSocket、Caffeine 怎么接进 EnvironmentSpring Boot 启动参数能做的远不止改端口和激活 profile。任何自定义配置项都可以通过--自定义前缀.属性名值的方式在启动时覆盖application.yml里的对应值。比如你集成了 MinIOminio: endpoint: http://localhost:9000 access-key: minioadmin secret-key: minioadmin bucket: lecture-bucket对应的配置类ConfigurationProperties(prefix minio) public class MinioProperties { private String endpoint; private String accessKey; private String secretKey; private String bucket; // getters / setters }部署时如果生产环境的 MinIO 地址不一样不需要改 yml直接命令行传java -jar app.jar \ --minio.endpointhttp://minio-prod:9000 \ --minio.access-keyprod-key \ --minio.secret-keyprod-secret \ --minio.bucketprod-bucket同理WebSocket 集成时你可以通过--server.tomcat.threads.max调整 Tomcat 用于 WebSocket 长连接的线程资源Caffeine 缓存可以通过--spring.cache.typecaffeine以及自定义前缀参数比如--caffeine.specmaximumSize500,expireAfterWrite10m在启动时动态决定缓存策略。这类“自定义参数 ConfigurationProperties”的玩法把硬编码配置彻底从代码里剥离了。企业里常见的“企业办公用品管理系统”“电商商城系统”这类项目数据库、OSS、消息队列的地址基本都是这么传进来的。5.4 Bean 注入控制参数启动时的隐藏开关热搜词里有一条“spring boot bean注入控制”它其实涉及一个启动参数级别的开关spring.main.allow-bean-definition-overriding。Spring Boot 默认情况下不允许 Bean 定义覆盖。如果你有两个配置类都定义了同名的Bean启动时会直接报BeanDefinitionOverrideException中断启动。这个设计是好的它能帮你及时发现重复定义。但有些老项目里日志框架、第三方 SDK 自动配置和你自己的配置就是会撞名短期内又没法全量重构于是可以通过启动参数开这个开关java -jar app.jar --spring.main.allow-bean-definition-overridingtrue这个参数我在一些历史遗留系统的迁移中帮过大忙但你心里要清楚打开它用的是后定义的 Bean 覆盖先定义的顺序不一定是直觉上的“后来者赢”有可能会掩盖真正的问题。所以我的建议是这是“临时拐杖”不是“长期拐杖”。等有空了还是要把重复 Bean 定义捋清楚然后关掉它。5.5 用外部配置文件替代“长命令”命令行参数虽好但参数一多命令就变成一个噩梦。比如java -jar app.jar \ --spring.profiles.activeprod \ --server.port8080 \ --spring.datasource.url... \ --spring.datasource.username... \ --spring.redis.host... \ --minio.endpoint...我相信没人愿意维护这种命令。更优雅的方案是利用--spring.config.additional-location把外部配置目录挂进来java -jar app.jar \ --spring.profiles.activeprod \ --spring.config.additional-location/etc/lecture-system/然后在/etc/lecture-system/目录下放一份application-prod.yml专门写生产相关的配置。这个附加位置的配置文件优先级高于 jar 内部的application.yml但低于命令行参数。这样你既能做到“配置不入代码包”又能减少命令行参数的数量运维同学看了也欣慰。6. 常见问题与排查技巧实录6.1 端口冲突最典型的启动失败现场现象启动日志报Web server failed to start. Port 8080 was already in use.。这个基本是每个 Spring Boot 开发者的必经之路。排查步骤# 找到占用 8080 的进程 lsof -i :8080 # 或者 netstat -tunlp | grep 8080拿到 PID 后看是什么进程如果是你自己跑挂了的旧实例直接 kill如果是别的服务那就换端口java -jar app.jar --server.port8081如果只是想快速验证功能还有个冷门的妙招--server.port0。Spring Boot 会随机挑一个可用端口启动日志里会打印实际的端口号。这在本地跑测试、不想跟别人抢端口时非常实用。6.2 内存参数没生效先查三个地方我在帮别人排查“为什么-Xmx2g不起作用”时通常先去查三件事。第一参数位置是不是放到了-jar后面。第二IDEA 里是不是填进了Program arguments而不是VM options。第三容器环境下-Xmx是否被外部脚本覆盖。第三点值得展开。很多部署平台比如某些企业自研的发布系统会自己拼启动命令你写在配置文件里的JAVA_OPTS可能根本没用上。遇到这类问题先别急着怀疑参数本身直接看进程的实际启动参数# Linux 下查某个 Java 进程的完整启动命令 ps aux | grep java # 或者 jcmd pid VM.command_linejcmd是 JDK 自带的排查神器比ps显示的信息更准确、更结构化。它能直接打印出 JVM 实际收到的所有参数一眼就能看出-Xmx到底有没有进去。6.3 配置文件被“意外覆盖”的问题命令行参数优先级最高所以很容易出现“我以为用 yml 里配的端口但实际上被命令行参数盖掉了”的情况。比如你启动脚本里写了--server.port8080然后想在临时测试中改成application.yml里的server.port9090结果发现怎么改 yml 都没用——因为命令行参数的优先级更高yml 根本没机会生效。排查这类问题最快的办法是关掉一些干扰项用--debug启动打印完整配置来源报告。或者更直接一点在代码中用Environment查看Autowired private Environment env;然后临时加个 Controller 或 CommandLineRunner打印env.getProperty(server.port)的值以及它的来源。Spring Boot 的Environment里参数的来源是可以用PropertySource名称看到的这就是“配置溯源”学会这一招能少走很多弯路。6.4 启动慢、频繁 Full GC怎么用启动参数自证启动慢不一定是 JVM 参数的问题但你可以先加几个参数把过程“看”清楚java \ -Xlog:gc*:file/opt/app/logs/gc.log:time,uptime,level,tags \ -Xlog:classloadinfo:file/opt/app/logs/classload.log \ -jar app.jar --debugJava 21 里的-Xlog已经替代了老旧的-XX:PrintGCDetails等参数。-Xlog:gc*的意思是记录所有 GC 相关日志输出到指定文件带时间戳、运行时间和级别。启动慢如果发生在类加载阶段classload日志会告诉你到底加载了多少个类、每个类花了多久。遇到频繁 Full GC 的线上问题先抓heapdumpjava -XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/opt/app/logs/ -jar app.jar进程 OOM 时会自动把堆快照写到指定目录。之后用 MAT 或 JProfiler 分析大对象引用链通常能定位到是缓存没限制大小、批量查询一次性加载了太多数据还是连接池配置过大。这类问题不是启动参数本身能解决的但没有启动参数你连分析素材都拿不到。6.5 常见启动问题速查表现象可能原因处理方案端口被占上一进程没关闭/端口分配给其他服务lsof -i :端口查找占用进程kill 或换端口启动很快但马上退出缺少某些条件配置自动配置失败用--debug启动查看条件评估报告内存参数不生效参数位置错误/被容器或外层脚本覆盖用jcmd pid VM.command_line查看实际参数配置项没生效被高优先级参数覆盖检查命令行参数、环境变量、外部配置Bean 冲突启动失败重复定义 Bean临时加--spring.main.allow-bean-definition-overridingtrue日志不输出到文件配置缺失或路径不可写配置logging.file.name并用--logging.level.root验证随机端口需求多个实例并行测试--server.port0应用无法分配足够内存容器限额与-Xmx不匹配使用-XX:MaxRAMPercentage75.0替代写死堆大小6.6 实测心得Dockerfile 里的启动参数为什么老被忽略最后分享一个我在容器化改造中踩过的坑。最初我写的 Dockerfile 是这样的FROM openjdk:21-slim COPY app.jar /app.jar ENTRYPOINT [java, -jar, /app.jar]然后在 K8s deployment 里通过args传启动参数spec: containers: - name: app image: app:latest args: [--spring.profiles.activeprod]这个方式能传应用参数但传不了 JVM 参数。因为在 Docker 的机制里ENTRYPOINT和args是拼在一起执行的最终命令是java -jar /app.jar --spring.profiles.activeprodJVM 参数没地方放。后来我改成脚本方式FROM openjdk:21-slim COPY app.jar /app.jar COPY start.sh /start.sh RUN chmod x /start.sh ENTRYPOINT [/start.sh]start.sh里留一个可配置的口子#!/bin/bash JAVA_OPTS${JAVA_OPTS:-} exec java $JAVA_OPTS -jar /app.jar $然后在 K8s 里通过环境变量JAVA_OPTS注入 JVM 参数env: - name: JAVA_OPTS value: -Xms1g -Xmx1g -XX:UseZGC - name: SPRING_PROFILES_ACTIVE value: prod顺便一提SPRING_PROFILES_ACTIVE这个环境变量名是 Spring Boot 的“环境变量映射配置”机制SPRING_前缀 PROFILES_ACTIVE。Spring Boot 会把SPRING_PROFILES_ACTIVEprod自动映射为spring.profiles.activeprod。这意味着你在容器平台里很多时候完全不用写启动参数直接设同名环境变量就行效果完全等价。这也解释了为什么网上很多部署文档会看到SPRING_APPLICATION_JSON、SERVER_PORT这种大写环境变量。7. 我对启动参数管理的几点个人总结写了这么多最后分享几个我这些年沉淀下来的习惯不一定都对但至少是踩过坑以后长出来的教训。第一个习惯是把常用启动命令写成脚本纳入项目仓库的deploy/目录。里面分环境放置比如start-dev.sh、start-prod.sh脚本内容就用我前面提到的JAVA_OPTS--spring.profiles.active模式。好处是团队成员之间不用口口相传“你加个参数试试”一看脚本就知道当前环境是怎么拉起来的。第二个习惯是上线前一定花 10 分钟跑一遍参数核对。用jcmd pid VM.command_line看 JVM 参数用/actuator/env看 Spring 配置来源确认每个关键配置端口、profile、数据源地址、缓存类型都来自预期的地方。有一次我帮一个项目排查生产问题最后发现测试环境的一套 Redis 配置通过环境变量渗透到了生产进程里如果不是用/actuator/env逐一核对根本不知道是哪里冒出来的。第三个习惯是尽量少用-D传应用参数。很多人习惯java -Dserver.port8081 -jar app.jar虽然也能生效但它的语义是“JVM 系统属性”不是 Spring Boot 的应用级参数。用--server.port8081更符合 Spring Boot 的解析链路也不会在第三方库中使用System.getProperty()时引起混乱。我在“为什么这个配置在某个第三方 SDK 里读不到”这类问题里有好几次最后都追溯到了-D和--的混用。启动参数这个主题说浅可以很浅说深可以很深。它没有高深的理论门槛但胜在每一个细节都和线上行为直接挂钩。今天我讲的这些要是能帮你少加一次班、少踩一个坑、少丢一个线上窗口那这篇就值了。