从事开发工作时, 你是否碰到过这般困扰: 将数据 库密码以及 API 密钥径直写入代码里, 提交至仓库担心泄密开发环境与生产环境存在差异, 每次展开部署都得手动去修改代码?今儿个就要为大伙推荐一款必备工具, 去掌握其核心运用方法以及进阶窍门, 能够达成配置跟代码完全分离, 使得项目管理变得更具安全性, 更加让人省心。一、先了解-到底能干嘛简约而言, 存在这样一个用于专门帮你展开「项目配置」管理的工具, 它能够促使你将全部敏感信息诸如密码、密钥、环境参数像端口、运行模式书写于一个单独的文件内, 而无需再往代码里进行硬编码操作。有着两个核心优势, 其一为安全, 即敏感信息不会暴露于代码之中, 其二是灵活, 也就是切换环境时无需修改代码所以部署更为轻松。不管是进行爬虫工作, 还是开展Web开发, 又或是从事数据分析, 该工具均能够得以应用。二、第一步安装-只要直接运用pip去进行安装就行, 该工具具备轻量的特性, 并且不存在冗余的依赖情况, 其安装命令, 经复制好后就能够使用。pip install python-dotenv核查是不是安装成功了: 在安装完毕之后, 去执行pip show -, 要是能够看到工具版本以及相关信息, 那就表明安装成功了。三、核心操作两步搞定环境变量配置那整个流程总共就两步, 先是创建配置文件, 而后就是在代码里进行加载读取, 下面会逐步去拆解操作的细节。3.1 创建.env配置文件关键一步于你项目的根目录之处, 此根目录与主脚本文件处于同一层级, 在该位置新建一个文件, 该文件的名称即为 .env的名称, 请注意此文件名前含有一个小数点, 并无文件名, 仅存在后缀这一部分。这份文件即为你的「配置中心」, 将所有需配置之内容顺着下述规则嵌入进去:给大家一个现成的示例直接复制到你的.env文件里就能用# 数据库配置敏感信息放这 DB_HOST127.0.0.1 DB_PORT3306 DB_USERroot DB_PASSWORDMyPass123! DB_NAMEmy_project # API密钥 API_KEYabcdef1234567890 JWT_SECRETmy_secret_key # 运行配置 ENVdevelopment # development开发环境production生产环境 DEBUGTrue APP_PORT8000 # 带空格的配置 APP_TITLEPython环境管理实战3.2 代码中加载并读取配置于配置文件被写好之后, 通过-将其加载至代码当中, 核心所运用的是具备两个工具的情况: 其一为函数, 其二乃是内置的os模块。除此之外, 存在可供选择的函数, 针对两种方式而言, 它们能够适配不同场景, 对此咱们要分别予以说明。建立一个新的主脚本, 像是称呼为main.py的那个, 其代码如下, 每一个步骤都标记了注释, 依照着写就是的:# 导入需要的模块 import os from dotenv import load_dotenv # 加载.env文件把配置注入到系统环境变量 load_dotenv() # 这行是核心必须写在读取配置之前 # 读取配置推荐带默认值防止配置缺失报错 if __name__ __main__: # 读取数据库配置 db_host os.getenv(DB_HOST) # 直接用KEY读取 db_pwd os.getenv(DB_PASSWORD) # 读取数字、布尔值注意读取的都是字符串要手动转换 app_port int(os.getenv(APP_PORT, 8000)) # 默认8000 debug_mode os.getenv(DEBUG, False) True # 转换为布尔值 # 读取带空格的配置 app_title os.getenv(APP_TITLE) # 打印验证结果 print(项目标题, app_title) print(数据库密码, db_pwd) print(运行端口, app_port) print(是否调试模式, debug_mode)运行此脚本, 便能够确切成功读取到.env之中的配置了。此外为大家增添第二种加载方式, 即函数, 其适用于那些不愿对系统环境变量造成污染的场景。# 导入函数 from dotenv import dotenv_values # 直接读取.env文件返回字典不注入系统环境变量 config dotenv_values(.env) if __name__ __main__: # 像操作普通字典一样读取配置 print(数据库用户, config[DB_USER]) print(API密钥, config[API_KEY])两相比较之下, 有一种方式适宜用于全局共享配置, 还有一种方式适合局部使用, 依据需求进行选择就行, 如此这般即可。四、常见问题处理安全提醒.env文件当中所容纳的全部都是敏感信息, 绝对不可以提交至Git、Gitee等代码仓库在项目根目录的那个.文件当中, 添加一行.env, Git自己将会自动忽略此文件, 为的是防止密码等信息出现泄露情况。常见的问题在于读取配置全都是None , 其原因在于, 要么是没有去执行括号当中存在的内容 , 要么是.env文件的路径不正确 , 这里默认是读取项目根目录的情况。可以先去检查括号里存在的内容是否被执行了 , 要是并非根目录的话能够指定路径 , 就像(.//.env)这样。关于布尔值判断出现失效是怎么回事呢 , 原因是从.env读取出来的True/False仅仅是字符串 , 并非布尔值 , 要是直接使用if DEBUG:这种形式的话它会永远呈现为真。遵循上面代码之中的写法, 借助 True 来进行转换, 达到兼容大小写的目的可添加.upper(), 也就是说os.(DEBUG) TRUE。中文配置冒出乱码状况? 其缘由为: 早期版本存有编码兼容方面的问题, 又或者.env文件的编码并非UTF - 8。支持给定编码, 例如(utf - 8), 与此同时需要保证.env文件保存成UTF - 8编码。配置项遭受覆盖? 原因在于: 系统环境变量的优先级高于.env文件, 相同名称的配置会率先读取系统环境变量。要是需要进行强制覆盖的话, 能够添加参数(True), 在这个时候, .env配置将会对系统环境变量实施覆盖。五、进阶用法: 多环境切换开发/生产环境于实际开展开发工作之际, 开发所处之环境, 即本地环境, 与生产运行之环境, 也就是线上环境, 二者的配置并非相同, 举例而言, 在本地运作时使用的是自身所拥有的数据库, 而在线上运转期间所使用的则是服务器所配备的数据库。当面临此种情形的时候, 能够借助多配置文件达成快速切换之目的。构造两个全新的配置文件, 分别是: .env.dev, 此为开发环境的.env.prod, 代表生产环境的, 将适配的对应配置写入其中, 开发环境采用本地数据库, 生产环境运用线上数据库在代码里, 能够手动进行切换, 也能够借助系统环境变量实现自动切换, 示例展示如下:import os from dotenv import load_dotenv # 方式1手动切换适合本地开发 # env_type dev # 切换环境只改这里 # 方式2自动切换适合部署场景通过系统环境变量控制 env_type os.getenv(RUN_ENV, dev) # 优先读取系统环境变量默认开发环境 # 加载对应配置文件 if env_type dev: load_dotenv(.env.dev) elif env_type prod: load_dotenv(.env.prod) # 读取配置和之前一样 print(当前环境, os.getenv(ENV))如此这般, 进行环境切换的时候, 是不需要去对业务代码作出修改的。当部署到线上环境时, 仅仅只需要将系统环境变量设置成prod便可实现该情况了, 这显得极为灵活。另外还要补充说明一点, 倘若配置文件的路径是固定不变的, 那么就能够将其绝对路径写死, 就好像是(os.path.join(os.path.(file).env.dev))这个样子, 以此来提高项目的移植性。六、总结使用起来简单, 然而实用性非常强, 是项目工程化所需必备工具, 其核心知识点包含加载方式、配置规则、优先级控制、多环境管理等, 它借助.env文件对配置进行集中管理, 达成配置与代码相分离, 既能防止敏感信息因硬编码而泄露, 又能够灵活地适配不同运行环境, 进而提升项目可维护性。核心逻辑清晰且明确, 采用.env文件来存储配置, 选择通过或进行加载, 再结合os.予以读取, 掌握优先级规则以及多环境切换的技巧, 就能够应对各类场景下的环境变量管理需求。