dotenvx
View All Tags
Stela是Python生态中一个非常流行的配置管理框架，让管理明文和加密的配置变得非常简单。 Stela的一些设计理念还是非常不错的，主要包括：
这些和Dotenvx的设计也是一致的，profile优先，.env或者application.properties文件中，未加密的配置项基本都是非敏感数据，如应用名称等，
而加密的主要是敏感数据，如数据库密码等。
Nacos和Apollo（阿波罗）是国内Java开发人员在开发Spring Cloud应用时，
常用的配置中心和服务注册发现解决方案，当然之前我也是其用户之一，主要是用来管理Spring Cloud应用的配置。
但是伴随着Dotenvx的出现，我们还有必要使用Nacos和Apollo的配置中心功能吗？ 当然Nacos和Apollo还有服务注册发现的功能，如Nacos目前非常关注MCP注册发现，
这里我们不讨论花毛一体的设计和AI的能力，这里我们着重讨论一下配置中心的功能，对于服务注册发现的能力，这个也有很多的候选产品，如Eureka等。
配置(Config)是应用非常核心的部分，也是Spring Cloud的核心部分，很多开发人员都在应用中集成过Config Server，也包括Vault这款KMS产品。
Josh Long在This Week in Spring - September 2nd, 2025推荐了dotenvx-spring-boot, 在文中还有一篇非常好的ppt，就是12-Factor Apps with Spring Boot，
this is really cool - a mechanism to load configuration into Spring Boot using Dotenvx Andrew Fawcett gave a nice talk looking at building 12-factor applications with Spring Boot at Spring I/O 2025.
所以我们来看一下如何在Spring Boot中集成Dotenvx。
Andrew Fawcett的演讲中谈到，12-Factor App的Config配置项，在Spring Boot中也非常容易实践，如下：
至少我个人也是遵循这样的做法，有条件的话就上Vault或者其他Config Server，没有条件的个人项目，就使用.env文件进行环境变量暴露。
dotenvx-rs非常轻巧，大小目前在4M左右，鉴于使用Rust编写，虽然功能多，但是编译后体积还是比较小巧的， 在Ops运维、脚本集成等方面，优势都非常明显。
但是在日常开发中，大家还是比较喜欢实用SDK方式，如dotenv，基本上都是通过SDK集成的方式来加载配置的。
.env文件格式非常简单，基本上就是KEY=VALUE的格式，所以其对应各语言SDK也都非常轻巧，基本上都在20K以下。
但是dotenvx就有些不同啦，除了要解析.env文件外，还要进行解密操作，所以各语言SDK的体积就大非常多，
这里列举一下各语言Dotenvx SDK的体积，供大家参考：
.env文件在Node.js和Python等语言中被广泛使用，主要用于存储应用程序的配置参数，如数据库连接信息、API密钥等。
目前dotenvx已经支持这些语言的SDK，可以非常方便地集成dotenvx的加密特性，但是这种方式还是有一些不便之处，
如会让Node.js和Python的项目增加额外的依赖包，导致应用变大，内存消耗增加，这点对Node.js尤为明显，
为了解密一个.env文件，然后加载为环境变，但是要付出这么多的代价，似乎不太划算。
此外做一些demo项目时，也有些偷懒，还需要增加额外的开发包，还是觉得有点麻烦，那么能否有一种更简单的方式呢？
这个可能就要从语言的SDK着手啦，能否让语言SDK天生就支持dotenvx特性呢？就像一些SDK，天生就支持.env一样，这样岂不是更方便一些。
那么能否做到让语言SDK天生支持dotenvx呢？从语言层面来说，可能有点麻烦，但是我们可以通过外部的管理工具做到这一点。
目前来说，Python的项目管理工具为uv，不但可以管理Python SDK，虚拟环境，开发包等，基本上涵盖了Python项目的方方面面， 可以说uv是Python社区标准的项目工具。 Node.js也有相关的SDK工具，那就是Volta，Volta可以管理Node.js的版本，工具等。 接下来我们就看一下如何结合uv和Volta来实现让Python和Node.js天生支持dotenvx特性。
在日常开发中，开发人员都会将测试用到的配置提前写好，如在.env中设置对应的数据库连接信息等，
如你使用Bun SQL特性，你已经在.env中设置好了数据库连接信息，如下：
MYSQL_URL="mysql://root:this_is_long_password@localhost:3306/test"
但是有时你需要连接其他的数据库进行测试，这个时候你需要输入mysql -u root -p123456 -h localhost -P 3306 test，然后再输入密码，
这样有时比较麻烦，尤其是密码比较复杂时，你也不能将--password=xxx直接写在命令行中，毕竟有些命令行会被记录到~/.bash_history中，会有安全隐患。
Dotenvx你既然已经管理了.env文件中的敏感信息，那么你能否帮我连接到MySQL上？
在做Dotenvx JetBrains IDE插件时，遇到一个Python和Dotenvx集成的问题，其实JetBrains IDE是支持该扩展的， 但是该API是内部的，并没有公开，导致插件兼容性的问题，所以审核比较麻烦，该特性一直都没有上线。
但是大家不用担心，还有一个简单的方式，就是通过调整Python SDK的命令行方式来集成Dotenvx。
假设你使用uv管理Python项目，你使用Python 3.13.7最新版本，uv会创建对应的virtualenv环境，
对应的python解析器为.venv/bin/python，该命令行其实是软连接到具体的Python版本目录下的。
代码和配置分离，这是软件开发的一个重要原则，如果你还不早知道道这个原则，那么请移步到12 Factor - Config。 配置文件通常包含应用程序的各种参数和设置，如数据库连接信息、API密钥、Base URL等。
在AI编程时代，我们的一些开发习惯可能要改变，典型的就是文档现行。我看过不少团队的项目，产品都上线有一年多，但是项目的README.md文件还是空的。 也不能说完全没有文档，如架构设计等，这些文档都保存在外部系统中，如语雀等，可以说很好地"实践"了代码和文档的隔离。
但是在AI的场景下，这种Demo先行、文档和代码分离的做法，可能就不太适用啦。 大家在项目创建完毕后，或者直接让AI帮助你创建项目框架。
项目创建后，你马上要做的事情就是编辑CLAUDE.md, AGENTS.md，.cursor/rules/xxx.md等文件，当然也可以是README.md文件。
这些文件的内容主要是告诉AI你项目的全部上下文，包括项目的目标、功能、技术栈、依赖、数据库结构、配置等等，这样AI才能更好地帮助你完成代码的编写工作。
对的，我们在项目的上下文中明确了配置，对比项目的目标、功能、技术栈等，配置的重要性也非常重要，因为这些配置直接影响到代码的生成。
我们都知道.env文件中的变量通常会加载到环境变量中，但是有一些例外，如Java，dotenv-java不会覆盖环境变量，主要是Java不允许覆盖环境变量。
但是对于大多数语言来说，.env文件中的变量会融合到环境变量中，如果环境变量中已经存在同名变量，那么该如何处理呢？
目前主流的做法采取的是环境变量优先原则，也就是如果环境变量中已经存在同名变量，那么.env文件中的变量将被忽略，除非你在加载.env文件时，
明确指定覆盖环境变量，如Python的python-dotenv库，提供了override参数，设置为True即可覆盖环境变量。
dotenvx的秘钥之前都是保存在项目目录下的.env.keys文件中，其格式如下：
DOTENV_PRIVATE_KEY=c4e79fecc6bfeb1fe3bf4d783ddf3303xxx
DOTENV_PRIVATE_KEY_TEST=82056174ece6e87e76084c224ayyyy
DOTENV_PRIVATE_KEY_PERF=fc9067f0a82c022fedbc221a169zzzzz
但是考虑到当下的AI编程大潮下，将.env.keys文件放在项目目录下，会被AI Agent或者AI IDE扫描，容易造成秘钥泄露，
所以个人决定接入全局秘钥存储文件，并且将其放在$HOME/.dotenvx/.env.keys.json文件中，这样就不再需要.env.keys文件，
私钥的查询都是走全局的.env.keys.json文件。 此外dotenvx命令行还提供了dotenvx --seal命令，对次文件进行加密保存，保证安全。