system.getenv() 在 docker 容器中可读取环境变量，但需确保变量在 jvm 启动前通过 docker run -e 或 docker-compose.yml 注入；构建时 env 会被镜像继承，运行时变量优先级更高；敏感信息应使用 docker secrets 或 kubernetes secret 而非明文暴露。
System.getenv() 在 Docker 容器中能正常读取环境变量，但必须确保变量在容器启动时已正确注入，而不是仅在构建阶段或宿主机 shell 中设置。
环境变量必须在容器运行时生效
Docker 构建阶段（Dockerfile 中的 ENV）设置的变量对 Java 应用可见，但更常见、更灵活的方式是通过 docker run -e 或 docker-compose.yml 的 environment 字段传入。这些变量会在容器启动时注入到进程环境，Java 的 System.getenv("KEY") 才能获取到。
- 构建时写死的 ENV（如
ENV DB_URL=jdbc:h2:mem:test）会进入镜像，所有基于该镜像的容器都继承它 - 运行时动态传入（如
docker run -e "DB_URL=jdbc:postgresql://db:5432/app"）优先级更高，可覆盖构建时的值 - 如果变量名含特殊字符或空格，建议用引号包裹，且避免在 Dockerfile 中用
ENV KEY=value with space这种写法（易出错）
Java 应用需主动调用 System.getenv()
System.getenv() 返回的是 JVM 启动时捕获的环境快照，不是实时监听。只要变量在 JVM 启动前已存在，就能读取；JVM 运行中修改环境变量（如用 export）对 Java 进程无效。
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- Spring Boot 用户注意：
@Value("${env.var}")或@ConfigurationProperties默认也依赖System.getenv()或 Spring 的 Environment 抽象，底层仍走环境变量机制 - 推荐在应用初始化阶段（如
@PostConstruct或 main 方法中）检查关键变量是否为空，避免运行时报 NPE - 不要在静态块中过早调用
System.getenv()—— 虽然通常可行，但若依赖其他初始化逻辑，可能造成顺序问题
敏感配置建议用 Docker secrets 或外部配置中心
密码、密钥等敏感信息不应明文写在 docker run -e 或 docker-compose.yml 中，因为命令历史、日志、版本库都可能泄露。
- Docker Swarm 环境可用
docker secret，挂载为文件（如/run/secrets/db_password），Java 读文件而非环境变量 - Kubernetes 下推荐用
Secret挂载为环境变量或 volume，配合envFrom或valueFrom.secretKeyRef - 通用做法：用启动脚本读取 secret 文件，再 export 为临时环境变量，最后 exec java 命令（注意权限和生命周期）
调试技巧：确认变量是否真的到达容器内
别只信配置文件，动手验证最可靠。
- 进容器执行
env | grep -i your_key，看变量是否存在且拼写正确（区分大小写！） - 加一行临时代码：
System.out.println("DB_URL = " + System.getenv("DB_URL"));，观察日志输出 - 注意变量名是否被 Docker 或 Shell 自动转成大写（某些平台会标准化），Java 里必须用原始定义的大小写去 get
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
