system.getenv() 返回 null 主因是 jvm 启动时未继承目标环境变量：ide 默认不传递完整环境、大小写/拼写错误、docker shell form 截断、.env 文件需专用库解析，而非 system.getenv()。
System.getenv() 返回 null？检查是否在 IDE 里直接运行
Java 的 System.getenv() 读取的是 JVM 启动时继承的系统环境变量，不是运行时动态修改的 shell 环境。IDE（如 IntelliJ、Eclipse）默认启动 JVM 时不会把当前终端的完整环境传进去，尤其是 macOS/Linux 下用图形界面打开 IDE 时，PATH、HOME 可能被精简，自定义变量干脆不存在。
- 验证方法：在终端中执行
env | grep YOUR_VAR确认变量确实存在 - IntelliJ 解决方案：Run → Edit Configurations → Environment variables 栏手动添加，或勾选 “Include system environment variables”
- Eclipse：Run Configurations → Environment 标签页 → New 添加
- 命令行运行无此问题：
YOUR_VAR=abc java MyApp或先export YOUR_VAR=abc再java MyApp
getenv(String key) 找不到变量？大小写和拼写必须完全匹配
Windows 下环境变量名不区分大小写，但 Java 的 System.getenv(String) 在所有平台都严格区分大小写。Linux/macOS 本身变量名就是大小写敏感的，所以跨平台代码里一旦写成 System.getenv("Path") 或 System.getenv("HOME") 拼错，就返回 null。
- 安全做法：先用
System.getenv()（无参）获取全部映射，打印 key 集合确认真实名称：System.getenv().keySet().forEach(System.out::println);
- 常见陷阱：
PATH不是Path，JAVA_HOME不是java_home，USER在 macOS 是USER，但在某些容器里可能是USERNAME - 不要依赖“应该有”，始终做非空判断：
String val = System.getenv("DB_HOST"); if (val == null) throw new IllegalStateException("DB_HOST not set");
为什么 getEnv() 在 Docker 容器里总为空？ENTRYPOINT 启动方式影响环境继承
Docker 默认使用 shell form（如 CMD ["java", "-jar", "app.jar"]）启动进程时，会通过 /bin/sh -c 包裹，导致 JVM 无法直接继承 docker run -e VAR=xxx 设置的变量——除非变量在镜像构建时用 ENV 指令固化，或运行时显式传入。
- 正确做法：用 exec form 启动，并确保变量已注入容器环境：
docker run -e DB_URL=jdbc:h2:mem:test -it myapp - 避免 shell form 的 CMD/ENTRYPOINT；如果必须用 shell，改写为
ENTRYPOINT ["sh", "-c", "java -jar /app.jar"]，否则sh -c会截断环境传递 - Kubernetes 中同理：检查
env:是否在 Pod spec 里正确定义，而不是只写在 Deployment 的template.spec.containers.env外层
想读取 .env 文件？System.getenv() 做不到，别硬套
System.getenv() 只读操作系统级环境变量，对项目根目录下的 .env 文件完全无感知。很多开发者试图用它加载本地配置，结果永远返回 null——这不是 API 问题，是用错了场景。
立即学习“Java免费学习笔记（深入）”；
- 替代方案：用第三方库如
dotenv-java，或手写简单解析（注意等号分割、引号处理、注释跳过） - Spring Boot 用户直接用
@Value("${my.prop}")或@ConfigurationProperties，底层已自动合并.env和系统环境 - 如果坚持手撸：读取文件后调用
System.setProperty()是无效的——JVM 属性 ≠ 环境变量，System.getenv()仍看不到
null，优先怀疑启动上下文，而不是代码写错了。 
