必须通过环境变量实现配置隔离，否则易引发生产事故；需为开发、测试、生产环境分别创建独立的.env.development、.env.testing、.env.production文件，Docker Compose或Kubernetes通过env_file或Secret精准加载，且DEBUG=true严禁在生产环境启用。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
要在Dify中让开发、测试和生产环境互不干扰，必须通过环境变量实现配置隔离，否则数据库连接错写成生产地址、调试模式未关闭、API密钥混用等事故随时可能发生。
准备多套独立的环境变量文件
在项目根目录下创建三个文件：.env.development、.env.testing、.env.production，每个文件只保存对应环境的变量，禁止交叉引用或注释掉其他环境的配置行。
这一步不能偷懒——如果把所有环境变量堆在一个.env里再靠注释开关，Dify启动时会全部加载，注释无效，【.env文件没有条件加载机制，所有键值对都会被读取】。
以.env.development为例，内容应类似：
DATABASE_URL=postgresql://dev:dev@localhost:5432/dify_dev
DEBUG=true
LOG_LEVEL=DEBUG
OPENAI_API_KEY=sk-dev-xxxxxxxxxxxxxxxx
按环境选择加载哪个.env文件
方法一：Docker Compose中指定env_file
在docker-compose.yml中为不同环境维护独立的编排文件，例如docker-compose.dev.yml里写：
services:
dify-api:
image: langgenius/dify-api:latest
env_file:
- .env.development
而docker-compose.prod.yml则指向.env.production。启动时用docker-compose -f docker-compose.prod.yml up即可精准加载。
方法二：Kubernetes中通过Secret挂载
将.env.production内容转为Kubernetes Secret：
kubectl create secret generic dify-prod-env \
--from-file=.env=.env.production
然后在Pod spec中通过envFrom引用，这样敏感变量不会出现在YAML明文里，【Secret挂载的变量优先级高于.env文件，能覆盖本地配置】。
验证环境变量是否生效
第一步：进入运行中的容器
docker exec -it dify-api bash
第二步：检查关键变量值
echo $DATABASE_URL
第三步：确认是否为预期环境的地址（比如开发环境应看到localhost，生产环境应看到pg-prod-cluster之类）
第四步：检查DEBUG值是否与当前环境匹配——开发环境为true，生产环境必须是false，若为true则立即停止服务，【DEBUG=true在生产环境会导致敏感日志泄露和性能下降】。
