Spring Boot环境差异核心在于配置、JVM参数、部署方式三方面：配置需按profile分离且敏感信息加密；生产JVM须调优堆内存与GC策略；部署须显式指定profile并剥离开发依赖。
开发环境和生产环境的配置差异最直接体现在 application.properties 或 application.yml 中
Java 项目（尤其 Spring Boot）靠 spring.profiles.active 切换环境，比如设为 dev 或 prod，对应加载 application-dev.yml 或 application-prod.yml。关键不是“环境名”，而是里面的内容是否匹配场景：
-
spring.datasource.url：开发用jdbc:h2:mem:testdb或本地 MySQL；生产必须指向高可用、带连接池、启 SSL 的远程数据库 -
logging.level.root：开发常设DEBUG，生产严禁，应设为WARN或ERROR，避免日志刷爆磁盘 -
management.endpoints.web.exposure.include：开发可开*，生产必须严格限制，如只留health,metrics，且需网关鉴权 - 敏感配置（如数据库密码、API 密钥）绝不能硬编码在 yml 里——开发可用
spring.cloud.config或本地bootstrap.yml模拟；生产必须走 Vault、K8s Secret 或云平台参数管理
JVM 启动参数在生产中必须显式调优，开发通常默认就行
开发时用 IDE 直接运行，JVM 参数基本是默认值（如 -Xmx 可能只有 1G）；生产部署必须根据机器资源和压测结果定制：
- 堆内存：避免用
-Xms和-Xmx差距过大（如-Xms512m -Xmx4g），易触发频繁 GC；推荐设为相等（-Xms2g -Xmx2g） - GC 策略：JDK 8 常用
-XX:+UseG1GC；JDK 17+ 可考虑-XX:+UseZGC，但需确认 OS 支持 - 禁用 JMX 远程暴露（
-Dcom.sun.management.jmxremote）——开发调试可能开着，生产若未隔离网络，等于裸奔 - 添加
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/log/myapp/，但路径必须有写权限，否则 dump 失败不报错
打包与部署方式决定环境行为是否可控
开发阶段 jar 包可能带内嵌 Tomcat、H2 数据库、Swagger UI；生产镜像必须剥离这些干扰项：
- 使用
spring-boot-maven-plugin的excludeDevtools和excludeGroupIds移除spring-boot-devtools依赖 - Dockerfile 中不要
COPY target/*.jar /app.jar后直接java -jar，而应通过java -Dspring.profiles.active=prod -jar app.jar显式指定 profile - 禁止在生产容器中挂载开发用配置文件（如把本地
application-dev.yml绑定进容器），容易覆盖真实配置 - K8s 环境下，
ConfigMap和Secret应按 namespace 隔离，devnamespace 的 ConfigMap 不能被prodpod 加载
常见错误：用开发思维查生产问题
线上出问题，第一反应不是改代码，而是确认「当前到底跑的是哪个环境逻辑」：
立即学习“Java免费学习笔记（深入）”；
- 看启动日志第一行：
The following profiles are active: prod—— 如果显示dev或空，说明 profile 没生效或被覆盖 - 检查
System.getProperty("spring.profiles.active")和Environment.getActiveProfiles()运行时值，别只信配置文件名 - HTTP 返回头里出现
X-Application-Context: application:dev:8080？说明 Spring MVC 自动加了 dev 标识，生产必须关闭server.add-application-context=false - 用
jps -l+jstat -gc看真实 JVM 参数，别信部署文档里写的“已调优”
环境差异从来不在名字上，而在每一行配置、每一个启动参数、每一次部署动作里。最容易被忽略的，是不同环境共用同一套 CI 脚本却没做 profile 注入校验——上线前最后一步，永远该是确认 spring.profiles.active 的最终来源。
