参数化查询是防止SQL注入最有效的方法，它通过预编译语句实现数据与代码分离，确保用户输入仅作为参数绑定而非SQL指令执行，从根本上杜绝拼接式漏洞。
环境变量本身不防SQL注入，但错误使用会直接导致SQL注入防线失效。 真正起防御作用的是应用层的参数化查询、ORM约束或中间件过滤；环境变量只是配置载体——它若把明文密码、拼接式连接字符串直接塞进应用，等于给攻击者递了钥匙。
为什么 DATABASE_URL 不能拼接用户名密码
很多项目在 DATABASE_URL 中写成 postgresql://$DB_USER:$DB_PASSWORD@host/db，再用 shell 替换。问题在于：
- 如果
DB_USER或DB_PASSWORD含特殊字符（如@、/、:），URL 解析会出错，应用可能降级到直连或报错后暴露堆栈 - 更危险的是，某些 ORM（如旧版 SQLAlchemy）在未开启
url.parse安全解析时，会把恶意构造的DB_PASSWORD=xxx%40host%2Fdb%3Bselect%201当作合法值传入底层驱动 - 日志或监控系统若记录完整
DATABASE_URL，敏感信息就留在磁盘上
docker run -e 传参时必须避开的三个坑
用 docker run -e 启动容器时，这些操作看似方便，实则高危：
- 不要在命令行里直接写密码：
docker run -e DB_PASSWORD=123456 ...—— 进程列表（ps aux）和容器元数据（docker inspect）都能看到明文 - 避免用
sudo+ 环境变量组合：sudo DB_PASSWORD=... docker run -e DB_PASSWORD ...——sudo会清空用户环境，变量根本传不进去，但你可能误以为传成功了 - 别让
-e和--env-file混用且同名变量冲突：Docker 以-e为准，但应用读取顺序不可控，容易引发认证失败却不报错
docker-compose.yml 中 environment 和 env_file 的分工逻辑
正确分层能降低泄露面：
- 非敏感配置（如
LOG_LEVEL、NODE_ENV）可写在environment块里，便于版本控制和快速调试 - 中敏感项（如
DB_PASSWORD、REDIS_URL）必须走env_file，且该文件需加进.gitignore，权限设为600 - 高敏感项（如
SECRET_KEY、JWT_PRIVATE_KEY）应彻底移出环境变量体系，改用 Docker secrets 或挂载只读文件（volumes）
示例片段：
version: '3.8'
services:
api:
image: myapp:latest
environment:
- LOG_LEVEL=warn
- TZ=Asia/Shanghai
env_file:
- ./prod.env # 包含 DB_PASSWORD、REDIS_URL
secrets:
- jwt_key
<p>secrets:
jwt_key:
file: ./secrets/jwt_private.key应用启动前必须校验的环境变量完整性
环境变量缺失不会总抛异常，而是静默降级——比如用默认 SQLite 覆盖生产 PostgreSQL 配置，这比报错更危险。
建议在入口脚本中强制检查：
#!/bin/sh if [ -z "$DB_HOST" ] || [ -z "$DB_NAME" ] || [ -z "$DB_USER" ]; then echo "ERROR: missing required env vars: DB_HOST, DB_NAME, DB_USER" >&2 exit 1 fi # 不检查 DB_PASSWORD —— 它应该来自 secrets 文件或密钥管理服务 exec "$@"
注意：DB_PASSWORD 这类字段不该出现在校验列表里，它的存在性应由密钥注入机制保障，而非靠环境变量“有没有”来判断。
最常被忽略的一点是：环境变量只是配置传递通道，真正的 SQL 注入防御永远发生在数据库驱动层或 ORM 初始化阶段——确保你用的是 psycopg2 而不是 pg8000 的非安全模式，确认 Django 的 settings.DATABASES 启用了 OPTIONS: {"prepare_statement": True}，或者 SQLAlchemy 显式禁用了 connect_args={"autocommit": False}。
