Flask中os.getenv()读不到环境变量主因是环境未生效：.env修改后需重启服务，IDE运行需手动配置环境；生产禁用.env，应系统级设置；密钥须动态注入，推荐config.from_mapping()结合os.getenv()，并严格区分多环境密钥。
Flask 里 os.getenv() 为什么总读不到环境变量
不是代码写错了，大概率是环境变量根本没生效。Flask 启动时只读取启动那一刻的环境，改了 .env 文件不重启服务就白搭；更常见的是用 IDE 直接点运行，它默认不加载系统环境或 .env，得手动配置运行环境。
- 本地开发用
python-dotenv：pip install python-dotenv，然后在应用入口（比如app.py开头）加from dotenv import load_dotenv; load_dotenv() - 生产部署别依赖
.env文件——它容易被误提交、权限失控；直接在系统级设置，比如 systemd service 的Environment=SECRET_KEY=xxx，或 Docker 的-e SECRET_KEY=xxx -
os.getenv('KEY', 'default')的默认值只是兜底，生产环境绝不能留默认密钥，建议改成os.getenv('KEY') or exit('MISSING KEY')或抛异常
Flask config.from_mapping() 和 config.from_object() 选哪个
关键看密钥是否要动态注入。from_object() 适合从类里读静态配置，但类属性写死密钥就等于把密钥编译进代码；from_mapping() 是运行时传 dict，能结合 os.getenv() 实现“配置即代码+凭据外置”。
- 推荐模式：
app.config.from_mapping(SECRET_KEY=os.getenv('SECRET_KEY'), DATABASE_URL=os.getenv('DATABASE_URL')) - 如果要用
from_object()，类里只放非敏感配置，密钥字段必须用os.getenv()动态获取，例如class Config: SECRET_KEY = os.getenv('SECRET_KEY') - 注意
from_mapping()不会覆盖已存在的 config 键，所以调用顺序很重要：先from_object()加基础配置，再from_mapping()注入密钥
gunicorn/uWSGI 启动 Flask 时环境变量丢失怎么办
Web 服务器常以独立用户身份运行，不继承你的 shell 环境。直接 gunicorn app:app 基本等于裸奔，os.getenv() 全是 None。
- gunicorn 显式传：用
--env SECRET_KEY=xxx，或通过--env-file .env（但生产慎用.env） - uWSGI 在配置里写
env = SECRET_KEY=xxx，多条就重复写env =行 - 最稳的方式：让 Web 服务器继承系统环境变量，比如 systemd service 中设
EnvironmentFile=/etc/default/myapp，文件里只放SECRET_KEY=...等几行，权限设为600
测试环境误用生产密钥的隐蔽风险
很多人用 FLASK_ENV=development 就以为安全了，其实只要 SECRET_KEY 没换，session cookie 就能被生产环境解密——测试站 XSS 漏洞可能直接拖走生产用户 session。
立即学习“Python免费学习笔记（深入）”；
- 不同环境必须用不同密钥：至少区分
development/production/testing三套SECRET_KEY和JWT_SECRET_KEY - CI/CD 流水线里，测试阶段用固定密钥（如
test-secret），但禁止任何地方硬编码；密钥应由 CI 平台注入环境变量 - 检查
app.secret_key是否为None或空字符串，Flask 不报错但会降级用 insecure fallback，加一行assert app.secret_key and len(app.secret_key) > 32防低级失误
环境变量本身不加密，它的安全性完全依赖于宿主机权限控制和部署流程隔离。密钥一旦泄露，重置成本远高于改代码——所以别省那一步 chmod 600，也别图方便把密钥塞进 Git history 里。
